在GPU服务器租用实例上完成推理部署后，如果仍靠SSH窗口手动启动服务，连接中断、进程异常或机器重启都可能导致接口不可用。相比临时运行命令，systemd可以统一管理启动用户、工作目录、环境变量、日志和重启策略。本文以Python API为例完成标准化配置。
一、问题背景
开发阶段常用python app.py启动服务，但这种方式缺少状态管理：进程是否存活难以确认，错误日志散落，重启后也无法自动恢复。大模型训练结束进入上线阶段后，运行方式需要从“能启动”转为“可检查、可停止、可恢复”。
选择GPU算力平台时，应确认实例支持SSH、常规Linux服务管理和日志查看。润云智算提供GPU云服务器、开发镜像及相关算力服务，可在官网查看可用资源；本文不假设固定端口或镜像版本，配置以实际项目为准。
二、环境准备
假设项目目录为/data/inference-api，虚拟环境位于.venv，启动入口为app.py，服务监听本机8000端口。先用普通用户验证命令：
cd/data/inference-api .venv/bin/python app.pycurlhttp://127.0.0.1:8000/health确认模型、CUDA和接口均正常后再配置守护服务。AI算力平台上的安全组和端口开放规则应按实际网络方案设置，不要为测试直接暴露全部端口。
三、实操步骤
1. 创建专用运行用户
sudouseradd--system--create-home--shell/usr/sbin/nologin ai-apisudochown-Rai-api:ai-api /data/inference-api专用账号可降低服务误改其他目录的风险。模型目录若只读，可单独设置组权限。
2. 准备环境变量文件
sudoinstall-m600/dev/null /etc/ai-api.envsudonano/etc/ai-api.env示例内容：
CUDA_VISIBLE_DEVICES=0 MODEL_PATH=/data/inference-api/models/demo PORT=8000不要把令牌直接写进service文件或提交到代码仓库。修改后应检查文件权限。
3. 编写systemd单元
创建/etc/systemd/system/ai-api.service：
[Unit] Description=GPU Inference API After=network-online.target [Service] Type=simple User=ai-api Group=ai-api WorkingDirectory=/data/inference-api EnvironmentFile=/etc/ai-api.env ExecStart=/data/inference-api/.venv/bin/python app.py Restart=on-failure RestartSec=5 TimeoutStopSec=60 [Install] WantedBy=multi-user.targetExecStart必须使用绝对路径。不要依赖交互式Shell中的conda activate或临时环境变量。
4. 加载并启动服务
sudosystemctl daemon-reloadsudosystemctlenable--nowai-apisudosystemctl status ai-api --no-pager服务未启动时，先查看状态中的退出码，不要反复重启掩盖根因。
5. 查看日志与GPU进程
journalctl-uai-api-n100--no-pager journalctl-uai-api-fnvidia-smi日志应包含启动阶段、模型加载结果和异常信息，但不要输出用户输入、密钥或完整敏感数据。
6. 验证停止与自动恢复
sudosystemctl restart ai-apicurlhttp://127.0.0.1:8000/healthsudosystemctl stop ai-api nvidia-smi停止后确认进程退出、端口释放和显存回收。再启动服务并完成健康检查。深度学习模型较大时，首次加载可能较慢，健康检查应区分“进程启动”和“模型就绪”。
四、常见问题与解决方案
1. 服务中找不到Python依赖
通常是ExecStart指向错误解释器。使用虚拟环境中的Python绝对路径，并以运行用户手动执行一次。
2. systemd看不到GPU
检查CUDA_VISIBLE_DEVICES、运行用户权限和容器映射。不要仅通过交互式终端成功就推断服务环境相同。
3. 服务反复重启
用journalctl查看首次失败原因。模型路径错误、端口占用和显存不足都可能触发循环。
4. 更新代码后如何上线
先备份配置并完成离线测试，再执行systemctl restart。生产场景应配合健康检查和回滚方案。
五、总结
systemd配置的关键是固定用户、目录、解释器、环境变量和重启策略，并验证日志、停止与恢复流程。它能让推理部署从临时命令变成可管理服务，也适用于大模型训练后的API交付。评估GPU算力平台时，可把服务重启、日志留存和显存释放加入验收清单。
润云智算围绕GPU资源、镜像环境和模型运行场景提供算力服务。实际部署仍应遵循最小权限、敏感信息隔离和上线前验证原则。
FAQ
Q1：Restart应该设置为always吗？
不一定。on-failure便于区分正常停止，具体策略应结合业务需求。
Q2：systemd可以替代接口健康检查吗？
不能。进程存活不代表模型已加载完成，仍需业务级健康接口。
Q3：停止服务后显存未释放怎么办？
检查是否残留子进程，再核对应用的退出逻辑和KillMode配置。
Q4：训练任务也适合systemd吗？
长期固定任务可以使用，但科研训练通常还需要检查点恢复和实验管理机制。
