LLMOps 与 Agent 部署架构

难度：中级 分类：Production & Deployment​

简短回答​

LLMOps 是专门为 LLM 驱动应用设计的运维实践体系，是 MLOps 在大语言模型时代的演进。与 MLOps 的核心区别：MLOps 以训练模型为核心（数据→特征→训练→部署），LLMOps 以使用模型为核心（Prompt→RAG→评估→部署），主要成本从训练 GPU 转移到运行时推理 API，迭代周期从周/月级缩短到小时/天级，核心产物从模型文件变为 Prompt、向量索引、工具配置、护栏规则，评估方式从精确指标（AUC/F1）转为 LLM-as-Judge + 人工评估。​

生产级 Agent 部署架构包含五个核心层：(1) 接入层——API Gateway 负责认证、限流、路由，支持 WebSocket/SSE 流式响应；(2) Agent 编排层——Agent 运行时（LangGraph、自研框架）管理推理循环、工具调用、状态管理；(3) 模型网关层——LLM Gateway（LiteLLM/Portkey）统一多模型 API、故障转移、Prompt 缓存；(4) 数据与工具层——向量数据库（RAG）、工具服务（MCP）、持久化存储；(5) 可观测性层——Trace 追踪（Langfuse）、指标监控（Prometheus）、告警。2025 关键趋势：Context Engineering 成为核心学科、Plan-then-Execute 优于 ReAct、MCP 协议成工具集成行业标准。部署策略推荐：先用 Serverless 快速上线，按需迁移到 K8s。​

LLMOps 不替代 MLOps，而是在其基础上扩展，企业通常需要两者协同工作。​

详细解析​

Part A：LLMOps vs MLOps​

核心差异对比​

​

#gQPwbgKRITMR text { white-space: pre; }#gQPwbgKRITMR .fb0 { stroke: var(--N900-FG, 0.15); }#gQPwbgKRITMR .fb0 {stroke: rgba(31,35,41, 0.15)}#gQPwbgKRITMR .fx0 { stroke-miterlimit: 10; }#gQPwbgKRITMR .fx0 {stroke-miterlimit: 10}#gQPwbgKRITMR .fa1 { fill: rgb(187, 191, 196); }#gQPwbgKRITMR .fa1 {fill: rgb(187, 191, 196)}#gQPwbgKRITMR .fx1 { font: 400 12px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; }#gQPwbgKRITMR .fx1 {font-style: normal}#gQPwbgKRITMR .fx2 { text-anchor: middle; }#gQPwbgKRITMR .fx2 {text-anchor: middle}#gQPwbgKRITMR .fx3 { dominant-baseline: central; }#gQPwbgKRITMR .fx3 {dominant-baseline: central}#gQPwbgKRITMR .fx4 { stroke: none; }#gQPwbgKRITMR .fx4 {stroke: none}#gQPwbgKRITMR .fc0 { fill: var(--text-caption); }#gQPwbgKRITMR .fc0 {fill: #646a73}#gQPwbgKRITMR .fa2 { fill: var(--text-link-disabled); }#gQPwbgKRITMR .fa2 {fill: rgb(187, 191, 196)}#gQPwbgKRITMR .fx5 { font: 400 13px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; }#gQPwbgKRITMR .fx5 {font-style: normal}#gQPwbgKRITMR .fx6 { text-anchor: start; }#gQPwbgKRITMR .fx6 {text-anchor: start}#gQPwbgKRITMR .fx7 { dominant-baseline: alphabetic; }#gQPwbgKRITMR .fx7 {dominant-baseline: alphabetic}#gQPwbgKRITMR .fc1 { fill: rgb(0, 0, 0); }#gQPwbgKRITMR .fc1 {fill: rgb(0, 0, 0)}#gQPwbgKRITMR .fb1 { fill: var(--N900-FG, 0.15); }#gQPwbgKRITMR .fb1 {fill: rgba(31,35,41, 0.15)}#gQPwbgKRITMR .fb2 { fill: rgb(209, 217, 224); }#gQPwbgKRITMR .fb2 {fill: rgb(209, 217, 224)}#gQPwbgKRITMR .fa3 { fill: var(--bg-body); }#gQPwbgKRITMR .fa3 {fill: #fff}ABC1234567891011维度核心模型数据类型主要产物迭代周期主要成本评估方式版本管理可观测性部署模式安全关注MLOps自训练模型结构化数据模型文件、特征周/月级训练（GPU 时间）AUC/F1/MSE模型+数据版本模型漂移模型服务器数据隐私LLMOps预训练 LLM（API）非结构化文本Prompt、向量索引小时/天级推理（API 调用）LLM Judge/人工Prompt+配置版本Prompt 漂移+TraceAPI GatewayPrompt Injection

​

LLMOps 的核心组件​

​

代码块​

JSON

llmops_components = {​

"Prompt 管理": {​

"内容": "Prompt 版本控制、A/B 测试、模板管理",​

"工具": "LangSmith, Humanloop, PromptLayer",​

"类比": "MLOps 中的特征工程",​

},​

"模型网关": {​

"内容": "API 路由、负载均衡、故障转移、成本控制",​

"工具": "LiteLLM, Portkey, Kong AI Gateway",​

"类比": "MLOps 中的模型服务器",​

},​

"RAG 基础设施": {​

​

LLMOps 工作流​

​

代码块​

Python

class LLMOpsWorkflow:​

"""LLMOps 的典型工作流"""​

​

def development_cycle(self):​

"""开发迭代循环"""​

return [​

"1. Prompt 设计与迭代",​

" - 编写/修改 System Prompt",​

" - 在 Playground 中测试",​

" - 版本化保存",​

​

"2. RAG 配置（如需要）",​

" - 文档处理和分块",​

" - 向量索引构建",​

" - 检索策略调优",​

​

​

企业协同：MLOps + LLMOps​

​

代码块​

Plain Text

实际企业 AI 系统中 MLOps 和 LLMOps 的协同：​

​

保险行业示例：​

├── MLOps 管理：​

│ ├── 定价模型（结构化数据 → 风险评分）​

│ ├── 欺诈检测模型（交易数据 → 欺诈概率）​

│ └── 客户分群模型（行为数据 → 用户画像）​

│​

└── LLMOps 管理：​

├── 智能客服（用户问题 → 自然语言回答）​

├── 保单解释助手（保单文档 → RAG 回答）​

└── 理赔报告生成（结构化数据 → 文本报告）​

​

​

Part B：Agent 系统部署架构​

五层架构全景​

​

​

生产 Agent 是五层堆叠：接入、编排、模型网关、数据工具、观测——LLM 调用必须过网关层。​

各层详解​

​

代码块​

Python

# 1. 接入层​

api_layer = {​

"API Gateway": {​

"职责": "认证、限流、路由、CORS",​

"选择": "Kong / AWS API Gateway / Nginx",​

},​

"流式响应": {​

"协议": "SSE（Server-Sent Events）用于单向流",​

"场景": "Token 流式输出，用户无需等待完整回答",​

"实现": "FastAPI StreamingResponse / WebSocket",​

},​

"健康检查": {​

"端点": "/health 检查服务状态",​

"内容": "服务可用性 + LLM API 连通性 + DB 连通性",​

},​

}​

​

# 2. Agent 编排层​

orchestration_layer = {​

​

容器化部署方案​

​

代码块​

YAML

# docker-compose.yml — 基础部署配置​

version: '3.8'​

services:​

agent-api:​

build:​

context: .​

dockerfile: Dockerfile​

​

配套 .env 示例：​

​

代码块​

Plain Text

​

部署策略选择​

​

代码块​

Plain Text

你的场景是什么？​

│​

├── 早期/MVP（< 1000 用户）​

│ → Serverless（Cloud Run / Lambda）​

│ → 按用量付费，无需管理服务器​

│ → 注意：冷启动延迟 + 执行时间限制​

│​

├── 中期/增长（1K-100K 用户）​

│ → 容器化（ECS / Cloud Run 持续运行）​

│ → 自动扩缩容 + 健康检查​

│ → 引入 Redis 缓存和 CDN​

│​

​

常见误区 / 面试追问​

误区："LLMOps 就是 MLOps 加个 Prompt 管理" — LLMOps 引入了全新的挑战维度：非确定性输出评估、Prompt Injection 安全、运行时成本控制、向量数据库管理等。这些不是简单地在 MLOps 上"加功能"，而是需要不同的思维方式和工具链。​

误区："用了 LLM API 就不需要 MLOps 了" — 大多数企业的 AI 系统同时包含传统 ML 模型和 LLM 应用。推荐系统、风控模型仍然需要 MLOps。LLMOps 和 MLOps 是互补关系，不是替代关系。​

误区："直接在应用代码里调 LLM API 就行" — 生产系统需要模型网关层来处理故障转移、限流、成本控制和缓存。直接调 API 会导致：单点故障、无法切换模型、成本失控、无法追踪。LiteLLM 或 Portkey 可以一行代码解决这些问题。​

误区："Agent 系统和普通 Web 服务部署一样" — Agent 有独特的部署挑战：(1) 长时间运行（一次任务可能执行数分钟）；(2) 状态管理（多步执行需要检查点）；(3) 高内存需求（上下文窗口占用大量内存）；(4) 不确定的成本（每次请求的 Token 消耗不同）。​

追问："LLMOps 的最大挑战是什么？" — 评估。传统 ML 有明确的量化指标（准确率、F1），但 LLM 输出的质量是主观且多维度的。如何自动化、可靠地评估 LLM 输出质量是 LLMOps 的核心难题，也是 LLM-as-Judge 等技术兴起的原因。​

追问："小团队如何起步 LLMOps？" — 最小可行方案：(1) Prompt 用 Git 版本管理；(2) 用 Langfuse（免费开源）记录所有请求和成本；(3) 维护 50 条 Golden Dataset 做回归测试；(4) 用 LiteLLM 统一多模型 API。这四步一周内可以搭好。​

追问："如何处理 Agent 的长时间运行任务？" — (1) 异步执行：接收请求后立即返回任务 ID，客户端轮询或 WebSocket 推送结果；(2) 检查点机制：每步保存状态，支持断点恢复；(3) 超时保护：设置最大执行时间和最大步数；(4) 流式输出：中间结果实时推送给用户。​

追问："选择框架还是自研？" — 参考原则：如果需求匹配框架能力的 80%+，用框架（LangGraph）；如果需要深度定制或框架是瓶颈，自研核心 Agent 循环但复用社区工具（LiteLLM、Langfuse）。框架选择比模型选择更重要。​