大模型GitOps实践：从零搭建模型部署的自动化流水线

知识分享

2026-10-19 05:40

13 阅读

大模型推理服务上线后，模型权重、镜像版本和推理参数经常一起变动，手工改 YAML 很容易出现环境和配置不一致。
GitOps 的思路是把期望状态全部写进 Git 仓库，由集群内的同步工具自动拉取并应用。
本文用 GitLab 加 Argo CD 演示一套最小可用的模型服务发布流程，适合已经有一个 Kubernetes 集群、想先把发布自动化跑起来的团队。

先理清适用场景和前置条件

这套做法适合模型服务数量不多、但需要频繁更新镜像或配置的场景。
如果只是本地跑单机推理，用脚本或 Docker Compose 更简单。
开始前需要准备：

一个可用的 Kubernetes 集群，能通过 kubectl get nodes 看到节点状态为 Ready。
已安装 Helm 3，用于安装 Argo CD。
一个 Git 仓库，推荐单独建 model-gitops 仓库，存放 Kubernetes 清单和模型服务配置。
集群能访问 Git 仓库；如果仓库是私有的，提前准备只读账号或 Deploy Token。

说明：以下命令和路径以常见的 Linux 跳板机和 Kubernetes 环境为例，版本差异请以实际环境为准。

搭建 GitOps 控制面：安装 Argo CD

先创建命名空间并安装 Argo CD：

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

等待 Pod 就绪：

kubectl get pods -n argocd -w

看到 argocd-server、argocd-repo-server 等组件状态为 Running 后，用端口转发访问 Web 控制台：

kubectl port-forward svc/argocd-server -n argocd 8080:443

浏览器打开 https://127.0.0.1:8080，默认用户名为 admin。
初始密码可通过以下命令获取：

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

登录后建议立即修改密码，并删除初始 secret。

规划仓库结构，把模型服务写进 Git

在 model-gitops 仓库中按环境分目录，例如：

model-gitops/
  apps/
    llm-inference/
      base/
        deployment.yaml
        service.yaml
        kustomization.yaml
      overlays/
        prod/
          kustomization.yaml
          patch-replicas.yaml

base/deployment.yaml 写模型推理容器的基本定义，关键字段包括镜像地址、启动参数和资源限制。
示例片段：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: llm-inference
spec:
  replicas: 1
  selector:
    matchLabels:
      app: llm-inference
  template:
    metadata:
      labels:
        app: llm-inference
    spec:
      containers:
        - name: server
          image: registry.example.com/llm/inference:latest
          args: ["--model", "/models/qwen", "--port", "8000"]
          resources:
            limits:
              nvidia.com/gpu: "1"

overlays/prod/kustomization.yaml 引用 base 并覆盖副本数或镜像标签。
模型权重建议通过 PVC 或对象存储挂载，不要打进镜像，否则每次换模型都要重新构建镜像。

提交并推送到远程仓库后，在 Argo CD 中新建 Application：

Repository URL 填 Git 仓库地址。
Path 填 apps/llm-inference/overlays/prod。
Cluster 选集群内，Namespace 填目标命名空间。
Sync Policy 先选手动同步，确认清单无误后再改为自动同步。

更新模型版本时的完整操作路径

日常发布不需要登录集群改 YAML。
推荐流程是：

在 CI 流水线中构建新推理镜像，打上明确标签，例如 v20250101-1，不要长期依赖 latest。
修改 overlays/prod/kustomization.yaml 中的 newTag 或镜像标签，提交 PR。
合并到主分支后，Argo CD 检测到 Git 变更。如果开启了自动同步，会拉取新清单并滚动更新 Deployment。
用 kubectl rollout status deployment/llm-inference -n <命名空间> 观察发布进度。

如果使用手动同步，在 Argo CD 界面点击 Sync，观察资源状态变为 Synced 和 Healthy。

常见报错和容易踩的坑

镜像拉取失败：先检查 kubectl describe pod 中的 Events，确认私有仓库 Secret 是否配置在正确的命名空间。
模型镜像体积大，节点磁盘不足也会导致拉取中断。

Argo CD 显示 OutOfSync 但集群状态正常：常见原因是 Git 清单中有集群自动生成的字段，或者使用了 latest 标签导致对比差异。
建议固定镜像标签，并避免在清单中写死动态字段。

模型服务启动慢导致探针失败：
大模型加载时间可能较长，initialDelaySeconds 和 failureThreshold 要按实际加载时间调整，
不要直接套用普通 Web 服务的探针参数。

同步后 GPU 资源不足：nvidia.com/gpu 这类资源必须由节点设备插件提供，先在节点上确认 GPU 资源可分配，再提交发布。

怎么验证 GitOps 真的生效了

发布完成后按顺序检查：

在 Argo CD 界面确认 Application 状态为 Synced、Healthy。
执行 kubectl get deployment -n <命名空间>，确认可用副本数等于期望副本数。
调用推理服务健康检查接口，例如 curl http://:8000/health，返回正常状态码。
故意在 Git 中修改一个无害参数并提交，观察 Argo CD 是否自动或手动同步，验证闭环是否通畅。

大模型 GitOps 实践的核心不是工具本身，而是把模型版本、镜像标签和运行参数都变成可审查的 Git 变更。
先从单个推理服务跑通同步和回滚，再逐步扩展到多个模型和环境，排错成本会低很多。

大模型ArgoCD部署配置：从安装到应用同步的完整流程

大模型CI/CD流水线配置：从零搭建自动训练与部署流程