LLMOps践行者：Docker+CI/CD+监控，让AI稳定跑在生产线

一、引言：AI应用从“能跑”到“稳跑”的鸿沟

当一个AI应用在本地Jupyter Notebook里跑通时，开发者往往会觉得“已经成功了90%”。然而，真正的挑战往往从这一刻才刚刚开始。

当我们通过Web界面或API与ChatGPT等大模型交互时，看似简单的每一次请求背后，都隐藏着一套复杂而有序的步骤：提示词预处理、模型选择、响应生成，以及负载均衡、监控和持续集成等环节。这套自动化执行的流程，正是LLMOps（Large Language Model Operations）所要解决的问题。

LLMOps并非MLOps的简单重命名。传统ML模型输出的是固定预测——一个概率、一个类别标签或一个数值分数；而LLM生成的是自由形式的自然语言，输出会随输入措辞、上下文和模型版本的变化而变化。这种根本差异决定了LLMOps需要一套全新的实践体系。成本结构是另一大分野——基于Token的计费取代了传统ML中计算密集的重训练经济模式，每一次提示词重新设计都直接关联着成本。

本文将围绕LLMOps的三大核心支柱——Docker容器化、CI/CD自动化流水线和可观测性监控——展开，通过完整代码示例，展示如何将AI应用从“能跑”升级为“稳跑”。

二、Docker：LLMOps的基石

“For LLMOps, Docker is the foundation of everything that comes after.”

在LLMOps体系中，Docker的地位无可替代。一旦LLM服务被容器化，它就可以部署到任何云平台、任何环境、任何机器，无需修改。容器化解决了AI应用部署中最头疼的环境一致性问题——GPU驱动版本、CUDA运行时、Python依赖库，这些“本地能跑、服务器崩了”的经典难题，通过Docker镜像被彻底封印。

2.1 从Docker Run到生产级Compose

许多团队从一条简单的docker run命令开始部署大模型推理服务。然而，当服务需要进入生产环境时，这种单命令方式暴露出诸多局限：配置硬编码、环境隔离缺失、维护成本高、扩展性差。

以下是一个从docker run升级为docker-compose.yaml的完整示例：

Step 1：创建项目目录与环境变量文件

mkdir-p~/vllm-servicecd~/vllm-servicetouchdocker-compose.yaml .env

Step 2：配置.env文件（参数化管理）

# .env COMPOSE_PROJECT_NAME=vllm-service MODEL_NAME=DeepSeek-R1-Distill-Llama-8B_AWQ SERVED_MODEL_NAME=deepseek-r1-8b-awq

通过环境变量将配置抽离，模型路径、模型名称等参数可以动态调整，无需修改Compose文件本身。

Step 3：编写docker-compose.yaml

# docker-compose.yamlversion:'3.8'services:vllm-openai:image:vllm/vllm-openai:v0.12.0ports:-"8001:8000"shm_size:"2g"ulimits:memlock:-1stack:67108864volumes:-/data/models:/modelsenvironment:-MODEL_NAME=${MODEL_NAME}-SERVED_MODEL_NAME=${SERVED_MODEL_NAME}deploy:resources:reservations:devices:-driver:nvidiacount:allcapabilities:[gpu]restart:unless-stoppednetworks:-ai-network# 可选：Nginx反向代理nginx:image:nginx:alpineports:-"80:80"volumes:-./nginx.conf:/etc/nginx/nginx.conf:rodepends_on:-vllm-openainetworks:-ai-networkrestart:unless-stoppednetworks:ai-network:driver:bridge

Step 4：服务管理命令

# 启动服务dockercompose up-d# 查看日志dockercompose logs-fvllm-openai# 停止服务dockercompose down# 重启服务dockercompose restart

2.2 生产级Dockerfile示例

如果需要在自定义镜像中打包AI应用代码，以下是一个生产级Dockerfile模板：

# Dockerfile FROM nvidia/cuda:12.2-base # 设置工作目录 WORKDIR /app # 安装系统依赖 RUN apt-get update && apt-get install -y \ python3.10 \ python3-pip \ && rm -rf /var/lib/apt/lists/* # 复制依赖文件并安装（利用Docker层缓存） COPY requirements.txt . RUN pip3 install --no-cache-dir -r requirements.txt # 复制应用代码 COPY . . # 暴露端口 EXPOSE 8000 # 启动命令 CMD ["python3", "app.py"]

关键注意事项：大模型部署中，需检查requirements.txt中的PyTorch/CUDA版本与Docker基础镜像中的CUDA版本是否冲突——这是实践中最常见的“坑”之一。

三、CI/CD：让AI迭代像传统软件一样可控

“LLMOps offers teams creating AI-powered applications the ability to incorporate workflows and frameworks akin to those used in traditional software development and deployment.”

CI/CD流水线将模型从开发环境带到生产环境的步骤自动化，确保每次变更都经过验证、可追溯、可回滚。

3.1 基于GitHub Actions的LLM服务CI/CD流水线

以下是一个完整的GitHub Actions工作流配置：

# .github/workflows/llm-deploy.ymlname:LLM Service CI/CDon:push:branches:[main,develop]pull_request:branches:[main]env:REGISTRY:ghcr.ioIMAGE_NAME:${{github.repository}}jobs:# Stage 1: 代码质量检查lint:runs-on:ubuntu-lateststeps:-uses:actions/checkout@v4-name:Set up Pythonuses:actions/setup-python@v5with:python-version:'3.10'-name:Install dependenciesrun:|pip install black isort pylint-name:Run code formatting checkrun:|black --check . isort --check-only .-name:Run lintingrun:pylint app/--fail-under=8.0# Stage 2: 构建与测试build-and-test:runs-on:ubuntu-latestneeds:lintsteps:-uses:actions/checkout@v4-name:Set up Docker Buildxuses:docker/setup-buildx-action@v3-name:Build Docker imageuses:docker/build-push-action@v5with:context:.load:truetags:${{env.IMAGE_NAME}}:testcache-from:type=ghacache-to:type=gha,mode=max-name:Run container testsrun:|docker run --rm ${{ env.IMAGE_NAME }}:test python -m pytest tests/# Stage 3: 构建并推送镜像build-and-push:runs-on:ubuntu-latestneeds:build-and-testif:github.ref == 'refs/heads/main'permissions:contents:readpackages:writesteps:-uses:actions/checkout@v4-name:Log in to Container Registryuses:docker/login-action@v3with:registry:${{env.REGISTRY}}username:${{github.actor}}password:${{secrets.GITHUB_TOKEN}}-name:Extract metadataid:metauses:docker/metadata-action@v5with:images:${{env.REGISTRY}}/${{env.IMAGE_NAME}}tags:|type=sha,prefix= type=raw,value=latest-name:Build and pushuses:docker/build-push-action@v5with:context:.push:truetags:${{steps.meta.outputs.tags}}labels:${{steps.meta.outputs.labels}}cache-from:type=ghacache-to:type=gha,mode=max# Stage 4: 部署到生产环境deploy:runs-on:ubuntu-latestneeds:build-and-pushif:github.ref == 'refs/heads/main'environment:productionsteps:-name:Deploy to production serveruses:appleboy/ssh-action@v1.0.3with:host:${{secrets.DEPLOY_HOST}}username:${{secrets.DEPLOY_USER}}key:${{secrets.DEPLOY_SSH_KEY}}script:|cd /opt/llm-service docker compose pull docker compose up -d --force-recreate docker system prune -f

3.2 流水线核心价值

这条流水线实现了：

• 代码质量门禁：Black/Isort自动格式化检查，Pylint评分门槛
• 镜像构建与缓存：利用GitHub Actions缓存机制加速构建
• 自动化测试：容器启动后自动运行单元测试
• 镜像版本管理：基于Git SHA生成唯一标签，支持精准回滚
• 一键部署：通过SSH远程执行docker compose up -d完成滚动更新

四、监控与可观测性：AI生产环境的“眼睛”

“Observability is non-negotiable. Production failures often trace back to pipeline and retrieval gaps, not the model itself, making end-to-end tracing critical.”

LLM应用的监控远不止基础设施层面的CPU和内存——它需要深入到每一次模型调用的Token消耗、延迟、输出质量和成本。

4.1 Langfuse：LLM可观测性的利器

Langfuse是一个开源的可观测性和分析平台，专为LLM驱动的应用而设计。它能自动采集Prompt、模型输出结果、Token消耗、错误信息、延迟等数据，并通过Trace和Span展示完整调用链。

Python集成示例：

# app/llm_service.pyfromlangfuseimportLangfusefromopenaiimportOpenAIimportos# 初始化Langfuselangfuse=Langfuse(public_key=os.getenv("LANGFUSE_PUBLIC_KEY"),secret_key=os.getenv("LANGFUSE_SECRET_KEY"),host=os.getenv("LANGFUSE_HOST","https://cloud.langfuse.com"))client=OpenAI(api_key=os.getenv("OPENAI_API_KEY"))defchat_with_tracking(user_query:str,system_prompt:str=None):"""带完整可观测性追踪的LLM调用"""# 创建Trace（一次完整的用户会话）trace=langfuse.trace(name="chat_session",metadata={"user_id":"anonymous","environment":"production"})# 创建Span（单次模型调用）withtrace.span(name="llm_call")asspan:try:# 记录输入span.update(input={"query":user_query,"system_prompt":system_prompt})# 调用模型response=client.chat.completions.create(model="gpt-4",messages=[{"role":"system","content":system_promptor"You are a helpful assistant."},{"role":"user","content":user_query}],temperature=0.7,max_tokens=2000)# 提取结果output=response.choices[0].message.content usage=response.usage# 记录输出和Token消耗span.update(output={"response":output},usage={"input":usage.prompt_tokens,"output":usage.completion_tokens,"total":usage.total_tokens})# 记录成本（以GPT-4为例）span.update(metadata={"cost":(usage.prompt_tokens*0.03+usage.completion_tokens*0.06)/1000,"model":"gpt-4","latency_ms":response.created# 简化示例})returnoutputexceptExceptionase:# 记录错误span.update(level="ERROR",status_message=str(e),metadata={"error_type":type(e).__name__})raisefinally:# 确保数据上报langfuse.flush()# 使用示例if__name__=="__main__":result=chat_with_tracking("请解释一下什么是LLMOps？",system_prompt="你是一位AI运维专家，请用简洁清晰的语言回答。")print(result)

4.2 Prometheus + Grafana：基础设施监控

除了LLM调用层面的可观测性，基础设施监控同样不可或缺。以下是一个集成Prometheus指标暴露的示例：

# app/metrics.pyfromprometheus_clientimportCounter,Histogram,Gauge,start_http_serverimporttime# 定义指标llm_requests_total=Counter('llm_requests_total','Total number of LLM requests',['model','status']# 按模型和状态分类)llm_request_duration=Histogram('llm_request_duration_seconds','LLM request duration in seconds',['model'],buckets=[0.1,0.5,1.0,2.0,5.0,10.0,30.0,60.0])llm_tokens_consumed=Counter('llm_tokens_consumed_total','Total tokens consumed',['model','type']# type: input/output)llm_active_requests=Gauge('llm_active_requests','Number of active LLM requests')deftrack_llm_call(model:str):"""装饰器：自动追踪LLM调用指标"""defdecorator(func):defwrapper(*args,**kwargs):# 增加活跃请求计数llm_active_requests.inc()start_time=time.time()status="success"try:result=func(*args,**kwargs)returnresultexceptExceptionase:status="error"raisefinally:# 记录持续时间duration=time.time()-start_time llm_request_duration.labels(model=model).observe(duration)# 记录请求总数llm_requests_total.labels(model=model,status=status).inc()# 减少活跃请求计数llm_active_requests.dec()returnwrapperreturndecorator# 启动Prometheus指标服务（端口8000）start_http_server(8000)

Grafana告警规则示例：

# alerting-rules.ymlgroups:-name:llm_alertsrules:# 高错误率告警-alert:HighLLMErrorRateexpr:|rate(llm_requests_total{status="error"}[5m]) / rate(llm_requests_total[5m]) > 0.05for:2mlabels:severity:criticalannotations:summary:"LLM服务错误率超过5%"# 高延迟告警-alert:SlowLLMResponseexpr:|histogram_quantile(0.95, rate(llm_request_duration_bucket[5m]) ) > 10for:3mlabels:severity:warningannotations:summary:"LLM服务P95延迟超过10秒"# Token消耗突增告警-alert:TokenCostSpikeexpr:|rate(llm_tokens_consumed_total[5m]) > 10000for:5mlabels:severity:warningannotations:summary:"Token消耗速率超过10000/分钟"

五、LLMOps全流程实践：从代码提交到生产稳定运行

将以上三个支柱串联起来，完整的LLMOps工作流如下：

关键实践要点：

1. 环境隔离：通过COMPOSE_PROJECT_NAME确保不同项目（开发/预发布/生产）的网络和容器互不干扰
2. 配置外部化：所有可变参数（模型名称、端口、资源限制）通过.env文件管理
3. 镜像版本化管理：每次构建使用Git SHA作为镜像标签，支持秒级回滚
4. 端到端追踪：从用户请求到LLM调用的完整链路可追溯，快速定位RAG检索失败、Prompt设计缺陷等问题
5. 成本可观测：每次调用的Token消耗和成本清晰可见，支撑Prompt优化决策

六、结语

“部署不是终点，而是价值交付的起点。”

将AI应用部署到生产环境，绝不意味着工作的结束。相反，它标志着持续运营的开始。

Docker提供了环境一致性的基石，CI/CD赋予了快速迭代的能力，监控与可观测性则让系统变得透明、可诊断。三者共同构成了LLMOps的铁三角，让AI应用不仅“能跑”，更能“稳跑”、“持续跑”。

正如LLMOps领域的实践者所言：“It is not a single tool or a one-time setup — production software must be versioned, monitored.”在这个模型能力日新月异的时代，LLMOps不再是可选项，而是让AI真正创造业务价值的必修课。