GPU服务器租用部署实战：用systemd守护模型推理服务

在GPU服务器租用实例上完成推理部署后，如果仍靠SSH窗口手动启动服务，连接中断、进程异常或机器重启都可能导致接口不可用。相比临时运行命令，systemd可以统一管理启动用户、工作目录、环境变量、日志和重启策略。本文以Python API为例完成标准化配置。

一、问题背景

开发阶段常用python app.py启动服务，但这种方式缺少状态管理：进程是否存活难以确认，错误日志散落，重启后也无法自动恢复。大模型训练结束进入上线阶段后，运行方式需要从"能启动"转为"可检查、可停止、可恢复"。

选择GPU算力平台时，应确认实例支持SSH、常规Linux服务管理和日志查看。润云智算提供GPU云服务器、开发镜像及相关算力服务，可在官网查看可用资源；本文不假设固定端口或镜像版本，配置以实际项目为准。

二、环境准备

假设项目目录为/data/inference-api，虚拟环境位于.venv，启动入口为app.py，服务监听本机8000端口。先用普通用户验证命令：

bash 复制代码

cd /data/inference-api
.venv/bin/python app.py
curl http://127.0.0.1:8000/health

确认模型、CUDA和接口均正常后再配置守护服务。AI算力平台上的安全组和端口开放规则应按实际网络方案设置，不要为测试直接暴露全部端口。

三、实操步骤

1. 创建专用运行用户

bash 复制代码

sudo useradd --system --create-home --shell /usr/sbin/nologin ai-api
sudo chown -R ai-api:ai-api /data/inference-api

专用账号可降低服务误改其他目录的风险。模型目录若只读，可单独设置组权限。

2. 准备环境变量文件

bash 复制代码

sudo install -m 600 /dev/null /etc/ai-api.env
sudo nano /etc/ai-api.env

示例内容：

ini 复制代码

CUDA_VISIBLE_DEVICES=0
MODEL_PATH=/data/inference-api/models/demo
PORT=8000

不要把令牌直接写进service文件或提交到代码仓库。修改后应检查文件权限。

3. 编写systemd单元

创建/etc/systemd/system/ai-api.service：

ini 复制代码

[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.target

ExecStart必须使用绝对路径。不要依赖交互式Shell中的conda activate或临时环境变量。

4. 加载并启动服务

bash 复制代码

sudo systemctl daemon-reload
sudo systemctl enable --now ai-api
sudo systemctl status ai-api --no-pager

服务未启动时，先查看状态中的退出码，不要反复重启掩盖根因。

5. 查看日志与GPU进程

bash 复制代码

journalctl -u ai-api -n 100 --no-pager
journalctl -u ai-api -f
nvidia-smi

日志应包含启动阶段、模型加载结果和异常信息，但不要输出用户输入、密钥或完整敏感数据。

6. 验证停止与自动恢复

bash 复制代码

sudo systemctl restart ai-api
curl http://127.0.0.1:8000/health
sudo systemctl 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吗？

长期固定任务可以使用，但科研训练通常还需要检查点恢复和实验管理机制。