Serving and LLMOps

条目状态与系统位置

本图位于 Serving / API / LLMOps，承接推理引擎，向上服务应用和 Agent，向下依赖 GPU、KV 和调度。可点击条目是独立文章；其余是平台能力清单，未单列不等于断链。

从请求到 SLO 的闭环

流量/租户
→ gateway 与 admission
→ model-aware routing
→ engine batch/KV
→ response + trace
→ metrics/evaluation
→ autoscale、灰度、回滚

平台层的核心不是把引擎包进容器，而是把延迟、成本、质量、版本和故障恢复连接起来。任何扩缩容策略都要说明触发指标、冷启动代价和回滚条件。

引擎与平台边界

推理引擎回答“怎样高效生成 token”：vLLM、SGLang、TensorRT-LLM。
本地/边缘推理引擎：llama.cpp（GGUF 核心运行时）。
本地模型平台：Ollama（管理 + API，底层 llama.cpp）——它有 serving 面，但不是集群级 platform。
Serving platform 回答“怎样把一个或多个引擎变成可部署、可扩缩、可管理的服务”。
Inference Engine Selection DEPENDS-ON 本页给出的 SLO、流量、路由和故障恢复边界；引擎跑分不能替代平台约束。

请求路径

client → gateway/auth/rate limit
→ router/admission control
→ model or engine replica
→ batching/scheduler/[KV Cache](/2026/07/13/llm-note-kv-cache-28707f541b/)
→ response and trace

Serving

API Gateway、认证、限流和租户隔离（未单列）
model-aware routing、load balancing、backpressure（未单列）
multi-model loading/unloading 与 multi-LoRA（待建）
autoscaling：队列、请求、KV 和 GPU 指标（未单列）
灰度、回滚和故障恢复（未单列）

LLMOps

model / prompt / dataset version（未单列）
trace：retrieval、model call、tool call、agent step（未单列）
offline/online evaluation 与 regression（未单列）
TTFT、TPOT、throughput、P95/P99、error rate、SLO（未单列）
token、GPU-hour、cache hit rate 与成本（未单列）

工具边界

MLflow/W&B：实验和模型生命周期（待建工具笔记）。
Langfuse/Phoenix/Opik：trace、评测与观测（待建工具笔记）。
promptfoo：测试与回归（待建工具笔记）。
这些工具观察和管理系统，通常不直接执行模型训练或 token 生成。

运维闭环应从一个请求展开

一条线上 trace 至少要能把业务请求 id 对齐到模型版本、引擎副本、队列等待、prefill/decode、KV 命中、工具/检索步骤和最终 token usage。没有这个关联，看到 P99 变差时无法判断是 gateway 排队、某副本 KV 快满，还是模型本身变慢。

request id + tenant
→ admission / rate limit decision
→ model revision + engine replica
→ queue + prefill/decode + KV metrics
→ stream/cancel/error
→ quality/eval/cost record
→ capacity or rollout action

关键指标要按租户、模型、输入/输出长度分桶：TTFT、TPOT、P95/P99、排队时间、active sequences、KV 使用/命中、抢占重算、错误/取消率、输入输出 token、GPU-hour 和成本。全局平均数会把长上下文租户和短聊天租户混在一起，不能直接驱动扩缩容。

扩缩容和发布的实际顺序

扩容触发后，先判断是瞬时队列、KV 容量、GPU 算力还是副本故障；如果新副本要下载几十 GB 权重并 warmup，扩容动作可能在峰值之后才生效。生产策略应给出预热副本/本地权重缓存、admission backpressure、优雅 drain 和回滚阈值。灰度时同时比较质量与 SLO：新模型可能 tokens/s 更高，却因输出变长、tool call 增多或 prefix 命中下降导致成本和 P99 变差。

故障恢复要明确谁重算

gateway 断开、engine OOM、Pod 驱逐和 KV transfer 超时的恢复语义不同。已经发送部分 token 的请求通常不能无缝迁移；平台必须选择重试、返回明确错误或从可验证 checkpoint 重算，并避免把有副作用的 tool call 重复执行。验收时注入副本失联、模型加载失败、客户端取消和长请求滚动更新，记录恢复时间、重复 token/tool、容量释放和最终用户错误。

一个 SLO 失败如何定位

先把请求按 request_id 串起 gateway、router、engine、retrieval、tool 和 model version。TTFT 变差时，trace 要能区分排队、冷启动、prefill 和 KV transfer；TPOT 变差时要看到 decode batch、KV 使用率和 GPU/网络等待；答案质量变差时要保留 prompt、检索证据、模型版本和输出校验，而不是只看 HTTP 200。这样 LLMOps 才是可行动的回归系统，而不是日志仓库。

发布门槛不是一个指标

灰度新模型或新引擎时，同时设置质量、可靠性和成本门槛：任务/引用正确率不得下降，错误率、OOM、重复副作用和 P99 不得越界，单位 token/GPU-hour 也不能无界上升。若只用平均 tokens/s 触发扩容，可能让长请求挤压短请求；若只用 GPU 利用率回滚，可能错过检索或工具层的质量回归。每次回滚都应能由 trace 指向具体版本和配置。