LLM Ops（LLMOps）

• Comet LLM 功能
• Opik LLM 功能
• 组合价值

Comet 是 ML 实验跟踪平台，提供 LLM 实验跟踪（prompt、模型、参数、评测、可视化）、数据集管理、与 LLM 框架集成；Opik 是 Comet 的开源 LLM 评估/观测工具，提供 LLM 评估（评测集、指标）、trace 追踪、prompt 管理、在线评估。组合价值：Comet 做实验管理与可视化，Opik 做 LLM 评估与 tracing，二者结合覆盖"实验-评测-观测"闭环。价值：跟踪 LLM 实验（prompt/模型/评测结果）、评估质量、观测 trace，支撑 LLM 应用开发与迭代。

Comet 重实验管理，Opik 重 LLM 评估与观测，组合覆盖 LLM 开发全流程。价值是"实验可追踪、评估可量化、trace 可观测"。运维上用于 LLM 应用的质量门禁与迭代支撑。

• DeepEval 功能
• Patronus AI 功能
• 选型

DeepEval 是开源的 LLM 评估框架，提供多种评估指标（G-Eval、Answer Relevancy、Faithfulness、Contextual Precision 等）、合成数据、评估流程、与 CI 集成，开源可自托管；Patronus AI 是商业的 LLM 评估与安全平台，提供 RAG 评估、幻觉检测、安全评估、领域专用评估，企业级。价值：DeepEval 开源灵活做评估，Patronus 商业企业级评估与安全。选型：开源自建评估用 DeepEval，企业级/安全评估用 Patronus。

两者都做 LLM 评估，DeepEval 开源可集成 CI，Patronus 商业企业级。评估是 LLM 质量门禁的关键。运维上把评估接入 CI/CD 做质量门禁。

• Galileo 功能
• Confident AI 功能
• 价值

Galileo 是 LLM 评估与可观测平台，提供 RAG 评估、幻觉检测、生成质量评估、数据与监控，提供开源评估库（如 RAG 评估指标）；Confident AI 提供 LLM 评估与改进平台，提供测试集管理、评估、反馈回路、可观测。价值：为 LLM 应用提供系统化评估（质量、幻觉、RAG）与观测，帮助迭代。选型：侧重 RAG/幻觉检测用 Galileo，侧重评估与反馈闭环用 Confident AI。

两者都是 LLM 评估/观测的商业与开源结合平台，价值在"评估质量 + 观测线上"。运维上用它们建立 LLM 质量基线、幻觉检测与反馈闭环。

• 在线指标类型
• 采集与告警
• 多维度联动

LLM 在线指标监控：延迟（TTFT/TPOT/端到端）、吞吐（token/s、请求数）、token 成本（输入/输出 token 计费）、错误率（超时、4xx/5xx、空输出）、安全拦截率（注入/越狱被拦截比例）。采集：引擎/网关 metrics + 日志 + 计费；告警：延迟 P99 超阈值、吞吐下降、错误率突增、token 成本超配额、安全拦截率异常（过低可能漏拦截）。多维度联动——成本与吞吐、安全与质量关联，全面反映 LLM 服务健康。

LLM 在线指标是"质量+成本+安全"三合一。监控要覆盖性能、成本、安全，且联动告警。安全拦截率是 LLM 特有指标。运维上建立统一 LLM 监控大盘，分层告警。

• 三版本解耦
• 灰度策略
• 回滚

三版本解耦发布：模型版本（registry 管）、Prompt 版本（Prompt 平台管）、代码版本（Git 管）是独立发布单元。发布时各维度独立灰度——改 Prompt 只动 Prompt 版本，改模型只动模型版本，改代码只动代码版本。灰度策略：按维度分别切流量（如先切 Prompt 5% 验证，再切模型）。每个请求携带三者版本信息，可独立回滚。用"版本矩阵"管理组合，避免耦合隐患。

解耦的核心是"三个版本独立可回滚"，避免"改代码连带模型"的大爆炸。任一维度变更可单独灰度、单独回滚。运维上把版本信息纳入请求元数据与 trace，支持按版本定位。

• 联动治理需求
• 治理设计
• 成本联动

联动治理：提示词版本、模型更新与 token 成本三者相互影响——改 Prompt 可能改变输出长度（成本）、换模型可能改变质量与成本。治理设计：统一版本管理（Prompt/模型版本关联），变更时评估成本影响（token 数变化）；成本治理——按 Prompt/模型/业务线统计 token 成本，设配额与告警；变更审批——Prompt/模型变更走评审，含成本与质量评估。建立"版本+成本+质量"联动看板，变更即评估三方面影响。

挑战是"三者联动"——一处变更影响其他。治理核心是"变更时同时评估质量与成本"。运维上把版本、成本、质量统一观测，变更走审批与灰度，避免"改 Prompt 导致成本暴涨"或"换模型质量下降"。

• 各工具定位
• 功能差异
• 选型

Langfuse 是开源的 LLM 可观测平台，提供 trace 追踪、Prompt 管理、成本/延迟观测、评测与反馈，开源可自托管，与主流框架集成；Helicone 是 LLM 网关/可观测平台，提供代理、日志、缓存、成本监控、限流，侧重网关与成本；Portkey 是 LLM 网关/路由平台，提供多模型路由、负载均衡、缓存、重试、可观测、成本控制，侧重网关路由。差异：Langfuse 重可观测/评测，Helicone/Portkey 重网关/路由/成本。价值：Langfuse 观测 trace 与质量，Helicone/Portkey 做网关路由与成本控制。选型：重可观测用 Langfuse，重网关路由用 Helicone/Portkey。

LLM Observability 工具分"可观测"与"网关"两类。Langfuse 强可观测，Helicone/Portkey 强网关路由+成本。运维上按需求选型，可组合（网关+可观测）。共同价值是"让 LLM 调用透明、可追踪、可控成本"。

• Phoenix 功能
• 评估与观测
• 价值

Phoenix 是 Arize 的开源 LLM/ML 可观测与评估平台，提供 trace 追踪、评估（LLM 评估指标、RAG 评估）、数据/模型监控、可视化 notebook。工程价值：开源可自托管，做 LLM 应用的 trace 追踪与评估，支持 RAG 评估、幻觉检测、drift 监控，与 notebook 集成便于分析。价值：追踪 LLM 调用、评估质量、监控线上，开源低成本。适用：需要开源可观测+评估的 LLM 应用。

Phoenix 的价值是"开源 + 可观测 + 评估一体"，覆盖 trace、评估、监控。适合开源自建。运维上用其做 LLM 质量评估与监控。与商业平台（Arize 全平台）互补。

• A/B 平台设计
• 样本回流
• 评估闭环

A/B 实验平台：流量切分（按用户/请求/权重把流量分到不同 Prompt/模型版本）、实验管理（记录实验组、版本、指标）、评估（质量指标：反馈、采纳、评审、业务结果）。样本回流——实验期间收集输入输出与用户反馈，回流到评估集/评测系统，用于离线评估与后续实验。评估闭环——线上 A/B 结果（质量/成本/延迟）反馈到版本选择，胜出版本全量，失败回滚；样本持续累积优化评测集。平台支撑"实验→评估→决策"闭环。

闭环核心是"线上实验数据回流 + 评估驱动决策"。A/B 需统计有效（样本量、显著性），样本回流 让评测集贴近真实。运维上把实验平台与评测、监控、registry 打通，形成闭环。

• PromptLayer 功能
• Promptfoo 功能
• 价值

PromptLayer 是 LLM 平台，提供 Prompt 版本管理、日志、评估、实验，重"Prompt 的版本与跟踪"；Promptfoo 是开源的 Prompt 测试/评估工具，提供 Prompt 的单元测试、回归测试、对比评估、CI 集成（prompt 变更跑测试）。价值：PromptLayer 管 Prompt 版本与日志，Promptfoo 做 Prompt 测试与回归（质量门禁）。组合：Prompt 版本化 + 测试评估，保证 Prompt 变更可追踪、可回归。

Prompt 是发布物，需版本管理与测试。PromptLayer 管版本，Promptfoo 做测试回归。价值是"Prompt 变更可追溯、可测试、可回滚"。运维上把 Prompt 测试接入 CI，变更即验证。

• 各工具功能
• RAG 评估指标
• 价值

RAGAS 是开源的 RAG 评估框架，提供 RAG 各维度指标（Faithfulness 忠实度、Answer Relevancy 相关性、Context Precision 上下文精确率、Context Recall 召回率），自动化评估 RAG 质量；ARES 基于 LLM 的 RAG 评估，用少量标注数据训练评估器，提供准确率、忠实度等；TruLens 是开源的 LLM 评估/可观测库，提供 RAG 评估（groundedness、answer relevance、context relevance）与 trace，集成到应用。价值：三者都做 RAG 评估，量化检索-生成链路质量。RAGAS 全面指标、ARES 高效自动、TruLens 可观测集成。

RAG 评估是 RAG 运维的关键——量化"检索相关性+生成忠实度"。RAGAS 指标全面可自动化，TruLens 可观测集成，ARES 高效。运维上用它们做 RAG 质量门禁与监控。

• 三要素
• 统一观测
• 联动告警

三要素统一观测：质量（评测分数、反馈、采纳率、幻觉检测）、成本（token 消耗、每请求成本、按业务线分摊）、安全（注入/越狱拦截率、敏感信息泄漏）。统一观测：建立统一监控大盘与日志，三要素在同一 trace/请求元数据上关联，按业务线/模型版本聚合。联动告警——质量下降、成本激增、安全风险任一恶化即告警，并关联归因（如 Prompt 变更导致质量下降）。统一观测让"好模型+贵+不安全"等矛盾显性化。

三要素是 LLM 应用的"金三角"。统一观测要建立在"同一请求/版本维度"，才能联动归因。运维上以请求元数据（版本、业务线）为轴，聚合质量/成本/安全，形成统一健康视图。

• 数据管道阶段
• 监控指标
• 告警

数据管道监控：数据清洗（处理行数、异常率、成功率）、embedding 生成（embedding 任务成功率、吞吐、耗时、失败率）、检索索引更新（构建任务状态、耗时、数据量、索引一致性）。监控：各阶段成功率、耗时、积压、失败重试；流水线调度（任务触发、失败、重试）。告警：清洗异常率超高、embedding 失败、索引构建失败/超时、数据延迟。监控流水线整体健康状况，保证数据→向量→索引不滞后。

数据管道是 RAG 的"上游"，管道故障导致检索数据陈旧。监控核心是"各阶段成功率/耗时/积压 + 调度失败"。运维上监控数据新鲜度（索引是否跟得上数据），保证检索质量。

• 并发与吞吐关系
• 估算方法
• 容量规划

LLM 容量估算：token 吞吐 = 并发请求数 × 每请求 token 产出速率（受显存 KV cache 限制）。关键约束是显存（KV cache 决定最大并发）与 GPU 算力。估算：先算单卡可承载并发（显存/(权重+KV cache/请求)），再算每请求 token 速率（受 GPU 吞吐），得到卡数。容量规划：按峰值并发与 token 需求，预留 GPU 数与弹性（自动扩缩），并考虑延迟/吞吐权衡。用压测验证估算。

LLM 容量规划的瓶颈是"显存决定并发、算力决定吞吐"。估算需结合权重/ KV cache/并发。运维上按业务峰值做容量预算，配合动态扩缩（HPA）应对波动。精确估算需压测校准。

• 三种形态对比
• 选型依据
• 切换

三种形态：自建推理服务（vLLM/TGI 自部署，成本可控、数据私有、可定制，但需运维 GPU 集群）；托管 API（OpenAI/云厂商，免运维、弹性、成本按用量，但数据出境、vendor lock、成本单价高）；网关路由（统一网关做多后端路由，可切换自建/托管、灰度、限流、成本控制）。选型：数据敏感/高吞吐/成本敏感用自建（规模大时），快速/低量/免运维用托管，混合用网关路由切换。切换：网关统一抽象，按成本/质量/可用性动态切换自建与托管。

选型权衡"成本、数据、运维、弹性"。自建规模经济但需运维，托管免运维但单价高数据外，网关路由提供灵活性。运维上用网关做统一入口与切换，按需移动负载。

• 流量切分
• 评测指标
• 自动回滚

流量切分——按权重/用户/请求维度把流量分到新旧模型，逐步放大（如 5%→20%→50%→100%）。评测指标——质量（反馈率、采纳率、评审、任务正确率）、延迟（TTFT/TPOT）、成本（token 数）、安全（拦截率），与基线对比。自动回滚条件——质量指标显著恶化（反馈率下降超阈值）、错误率突增、延迟超标、安全拦截异常，触发自动回滚到旧版本。设计上回滚条件要基于统计显著与基线，避免误回滚。

A/B 灰度核心是"受控切量 + 指标决策 + 自动回滚"。评测指标要综合质量/延迟/成本/安全。自动回滚是灰度安全护栏，条件基于基线显著差异。运维上把指标、回滚条件接入平台自动执行。

• WhyLabs 功能
• Arthur 功能
• 价值

WhyLabs 是 ML 监控平台，提供数据漂移检测、模型性能监控、数据质量、异常检测，开源自托管（WhyLogs）与 SaaS，支持 ML/LLM；Arthur 是 ML 监控/可观测平台，提供数据漂移、模型性能、鲁棒性、Bias 检测，企业级。价值：都做 ML/LLM 监控（漂移、性能、质量、异常），WhyLabs 开源可自托管、Arthur 企业级。选型：开源自托管用 WhyLabs，企业级完整用 Arthur。

两者都是 ML 监控，价值在"漂移检测 + 性能监控 + 质量告警"，支撑 LLM 质量回归与数据漂移预警。运维上接通线上数据做漂移监控，及早发现模型劣化。

• Prompt 注册
• 变更评审与回归
• 回滚

落地：Prompt 注册——Prompt 在 Prompt 平台登记为不可变版本，含内容、元数据、用途；变更评审——修改走评审（语义、安全、一致性、成本影响）；回归评测——变更前跑评测集（回归测试），对比变更前后质量指标，达标才通过；回滚——线上异常时切回旧 Prompt 版本。请求携带 prompt_version 便于追溯。形成"注册→评审→评测→发布→回滚"闭环。

Prompt 是"代码级"发布物，落地需版本化+评审+回归+回滚。回归评测是关键（防 Prompt 变更引入质量回归）。运维上把 Prompt 版本纳入请求元数据与 trace，支持定位与回滚。