LLMOps CI/CD流水线，模型版本管理
模型上线最怕的是新版本效果不好却无法快速回退。
LLMOps 下的 CI/CD 流水线，本质上就是把模型版本像代码一样管理：每次发布打一个版本标签，流水线自动构建镜像并更新服务，切换模型只需改一个版本号。
本文以 Kubernetes 部署环境为例，从零开始讲解模型版本管理、流水线触发和验证方法。
写清前置条件与版本命名
准备一台能访问 Git 仓库和镜像仓库的服务器，安装好 Docker、kubectl 和 CI/CD 工具（如 GitLab CI、Jenkins 或 Argo Workflows）。
建议先给当前模型文件建立版本命名规则：模型名-主版本.次版本.修订号，例如 qwen-2.1.0。
在 Git 仓库中，模型权重和推理服务代码放同一项目，用 git tag 标记每次发布版本：
git tag -a qwen-2.1.0 -m "release qwen 2.1.0"
git push origin qwen-2.1.0这样每个版本都有唯一的代码快照，后续流水线可以直接引用。
流水线自动构建镜像
CI/CD 流水线的核心是把版本号注入镜像。
下面是一个 GitLab CI 的 .gitlab-ci.yml 片段：
build:
stage: build
only:
- tags
script:
- docker build -t registry.example.com/llm/inference:$CI_COMMIT_TAG .
- docker push registry.example.com/llm/inference:$CI_COMMIT_TAG推送新 tag 时自动触发构建，镜像 tag 与 Git tag 保持一致。
这样每个模型版本都有可追溯的镜像，不会出现“改了代码却不知道是哪个版本”的问题。
一键升级切换模型
在 Kubernetes 部署文件中，将镜像版本作为环境变量引用。
推荐使用 Kustomize 或 Helm 管理不同版本的配置，避免手动改 YAML。
使用 kubectl set image 可以直接切换：
kubectl set image deployment/llm-inference inference=registry.example.com/llm/inference:qwen-2.1.0 -n llm执行后 Deployment 会滚动更新，新模型自动上线。
如果想做得更稳，可以在流水线中集成 Argo Rollouts，定义蓝绿策略或金丝雀策略：
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: llm-inference
spec:
strategy:
canary:
steps:
- setWeight: 20
- pause: {duration: 5m}
- setWeight: 100发布时执行 kubectl apply -f rollout.yaml，系统会按比例放量，并自动检查模型服务健康指标，比如 token 延迟和错误率，不达标则自动回滚。
避坑指南
不要用 latest 作为镜像版本，否则无法区分模型版本，回滚时也找不到旧镜像。
切换前先备份旧模型配置，回滚时直接执行：
kubectl rollout undo deployment/llm-inference -n llm注意模型文件一致性：新版本上线前确认向量库索引、prompt 模板与模型版本匹配，否则容易出现输出质量下降。
模型验收建议在预发环境先跑一轮：调用几条典型问题，对比新旧版本的响应质量和 token 消耗，再决定是否切换生产。
效果验证与回退检查
切换后执行以下验证：
kubectl get pods -n llm
kubectl logs deployment/llm-inference -n llm | grep "model version"
curl http://llm-service:8080/v1/chat -d '{"model":"qwen-2.1.0"}'确认 Pod 状态为 Running，日志输出模型版本信息，接口返回正常。
如果出现超时或错误率高，执行 kubectl rollout undo 回到上一个版本。
最后，在流水线中增加 Webhook 通知，让团队实时知道模型是否升级成功。
LLMOps 的 CI/CD 流水线并不复杂，核心是把版本管理做扎实，升级切换自然可控。
