大多数团队上了 LLM 之后，第一个月在写 Prompt，第二个月在数钱，第三个月才意识到：没有一套工程体系，这事根本撑不住。
LLMOps 不是 MLOps 的简单升级，它是一套针对大语言模型生产化挑战而生的工程方法论。读完这篇，你会明白为什么传统的 MLOps 工具在 LLM 面前几乎全部失效，以及 LLMOps 体系到底管什么。
MLOps vs LLMOps：一场认知颠覆
不是升级，是范式转移。
| 维度 | MLOps（传统 ML） | LLMOps（大语言模型） |
|---|---|---|
| 训练成本 | 几十美元到几千美元，团队可自己训练 | 单次预训练数百万美元，基本不训练基座 |
| 版本管理对象 | 模型权重（.pkl / .onnx） | Prompt 模板 + 模型配置 + 调用参数 |
| 核心监控指标 | 准确率、AUC、MAE 等数值指标 | 输出质量（主观）、幻觉率、用户满意度 |
| 主要挑战 | 数据漂移、模型退化、特征一致性 | 幻觉、Prompt 注入、Token 成本、输出不确定性 |
| 部署方式 | 自托管推理服务 | 调用第三方 API 为主，或本地部署开源模型 |
| 迭代粒度 | 重新训练模型（小时~天） | 修改 Prompt（分钟）或换模型（分钟） |
| 评估方式 | 测试集跑指标，自动化 | 需要人工评估或 LLM-as-Judge |
| 故障模式 | 预测错误、服务超时 | 幻觉（不抛异常）、有害输出、格式错误 |
核心矛盾一句话总结：MLOps 的问题是”模型是否准确”，LLMOps 的问题是”模型是否可信、可控、可负担”。
LLMOps 体系全景架构
LLMOps 体系由五层组成：
用户层 → Prompt 管理层（版本控制/A/B测试/模板库）→ LLM 调用层（网关/路由）（模型路由器/负载均衡/速率限制）→ 模型层（GPT-4o/Claude/本地开源模型）
同时，评估层（自动化评估RAGAS/LLM-as-Judge/人工评估）和可观测性层（Trace追踪/延迟监控/幻觉检测）和成本层（Token用量分析/成本分摊/缓存策略）贯穿全链路。
