第一章 基础：监控大模型推理为何不同寻常

第一章 基础:监控大模型推理为何不同寻常

把模型送上生产,只是长征第一步;真正的考验,是它上线之后你还"看得见"它吗?

设想一个很典型的生产事故开局:你的聊天接口延迟 SLA 写着 P99 ≤ 2 秒,监控面板常年一片绿,某天上午却突然涌入一堆客诉--"回答变慢了""生成到一半卡住"。你打开 Grafana,QPS 没涨、错误率还是 0%、P99 曲线平得像条直线,均值稳稳停在 1.8 秒。你以为系统没问题,直到翻出逐请求日志,才发现那 5% 的超长请求把真实 P99 拉到了 40 秒,而因为默认面板只画了均值和 P50,这 5% 在你的眼睛里"不存在"。更糟的是,其中有十几个请求其实被长度上限截断了,HTTP 状态码是 200,业务上却是彻头彻尾的失败。这就是用传统 Web 监控范式套大模型推理时最经典的一幕:你以为在监视系统,其实系统早就在你看不见的地方劣化了,而面板还在对你微笑。

绝大多数团队在接入 Prometheus 与 Grafana 之前,都以为监控 LLM 推理不过是"给一个普通服务加几个指标"。这个错觉很危险。大模型推理服务表面上看是一个 HTTP 接口,背后却是一整套与传统 Web 服务截然不同的资源模型:它的核心瓶颈是 GPU 显存而不是 CPU,它的响应时间高度依赖输出长度而不是固定的处理逻辑,它的吞吐靠动态批处理放大,却又会被一个超长请求拖垮整池。用一套为"短平快"请求设计的监控范式去套它,结果就是面板祥和、线上静默劣化,事故复盘时你才发现所有关键信号都没采集。

本章是整本教程的"地基"。我们不从怎么配 Prometheus 讲起,而先回答一个更根本的问题:大模型推理到底特殊在哪,以至于你那些顺手的监控指标会系统性失灵?只有把这个"为什么"想透,后面第 2 章的指标设计、第 3 章的架构权衡、第 4 章的看板与告警才能真正落到实处,而不是又一套复制粘贴的 YAML。

学完本章,你能带走什么

在正式开讲之前,先说清这本教程对你到底有什么用。读完并跟着做完,你应该具备以下能力:

• 能一眼看穿现有监控面板的"盲区":面对任何一张 LLM 推理 Grafana 面板,你能判断它遗漏了哪些关键维度,而不是被一片绿色麻痹;
• 能独立设计一套面向推理的指标清单:不抄 Web 模板,而是从显存、算力、排队三个物理约束出发推导出该采集什么;
• 能向团队解释"为什么加机器没用":当老板说"GPU 利用率才 30% 再加两张卡",你能用 compute/memory bound 的区分把话说明白;
• 能为后续看板与告警打好地基:本章建立的认知,正是第 4 章那些能救命的面板背后的设计依据。

换句话说，这一章不教你配一个具体面板，而是给你一副“看穿 LLM 监控”的眼镜。戴上它，后面所有技术细节都会变得顺理成章。

本章与后续章节的衔接

为避免你读到后面迷失在 YAML 与 PromQL 里，先交代全书的递进关系：

• 第 2 章会在本章“三层框架”基础上，给出一份可直接落地的指标清单与抓取接入方式（如何让推理引擎把资源层、生成层、请求层指标暴露给 Prometheus）；
• 第 3 章深入进阶原理，比如指标本身的采样开销、高基数标签陷阱、多副本与多模型路由下的聚合坑——这些是“监控监控者自己”的必修项；
• 第 4 章把指标变成能救命的看板与告警，尤其是分段延迟视图、KV 水位容量告警、软失败率告警；
• 第 5 章收尾，谈从“看得见”到“自治”：基于监控信号的自动扩缩容与降级。

你会发现，第 2、4 章的指标与面板，几乎都能在第 1 章的框架里找到出身。所以请务必把本章的三层框架记牢。

监控度量维度的选择原则

建立框架后，你可能会问：维度这么多，我该先采哪些？给你三条原则，后面选指标时照着筛：

• 优先采“先行指标”而非“滞后指标”：KV 水位、排队时长会在用户感知劣化之前就变化，而端到端延迟、客诉是事后才到的，告警要挂在先行指标上；
• 优先采“物理约束指标”而非“业务汇总指标”：显存带宽、KV 占用这些硬约束不会骗人，QPS 这类汇总容易被请求分布扭曲；
• 每个指标都要能回答一个问题：写指标前先问“它回答‘机器扛得住吗 / 生成健康吗 / 用户好吗’中的哪一个”，答不出的指标要么是冗余，要么是还没想清。

这三条原则会贯穿第 2 章的指标筛选，建议回头对照着看。

一个反例：照搬 Web 模板的代价

最后用一个真实的反例收束本章开头。某团队把现成的 Go 服务监控模板套到推理服务上，面板只有 QPS、HTTP 错误率、以及一条“平均响应时间”。上线头两周一切太平，第三周业务侧接入了一批长文档摘要需求，平均响应时间从 1.2 秒缓慢爬到 1.9 秒，仍在“告警阈值 3 秒”之内，无人察觉。实际上长桶 P99 已经从 2 秒恶化到 45 秒，且约 12% 的长请求被 max_tokens 截断——但因为只画了均值、只算 HTTP 错误率，这两件事在面板上完全隐形。直到用户大规模投诉“摘要生成不全”，事故才暴露。复盘结论是：不是监控工具不行，而是度量维度错了。这也是本书要解决的那个核心问题。

一个关键定位:监控的是"推理"而非"服务"

通用可观测性(Observability)讲三大支柱:日志、指标、链路追踪,目标是回答"系统现在怎样、为何如此"。这套框架对 LLM 推理依然成立,但聚焦点要转移。传统服务你关心"这个请求成功了吗、花了多久";LLM 推理你更该关心"此刻显存还剩多少、批里最长的序列有多长、生成到第几个 token 被截断了"。一句话--你要监控的不是"服务在不在",而是"生成过程健不健康"。这个定位决定了本章乃至全书的指标取向:资源与生成优先,请求动作次之。

上面的图点破了根因:传统指标之所以好用,是因为它们建立在三个假设之上;而大模型推理把这三个假设逐一推翻。理解这一点,比背下任何一张面板都重要。

监控维度的三层框架

为了把"资源与生成优先"落地,我用一个三层框架贯穿全书,你在后面会反复看到它:

• 资源层(Resource):GPU 显存占用、KV Cache 水位、算力与带宽利用率--回答"机器还扛得住吗";
• 生成层(Generation):Prefill 耗时、Decode 每 token 延迟、流式中断率、截断率--回答"生成过程健康吗";
• 请求层(Request):排队时长、端到端延迟分位、软失败率--回答"用户感受到的好吗"。

传统三板斧几乎只落在第三层,而且只看其中最容易采集的子集。本书的工作,就是把它补全成三层贯通的体系。

这张时序图是后面所有讨论的"舞台"。你会看到,延迟不是在一个函数里产生的,而是分布在排队、Prefill、Decode 三段,任何一段卡住,终端用户感受到的"慢"都会叠加。后面章节的指标,本质就是要把这三段"切开"分别度量。

本章的递进逻辑如上:先破(破除旧范式)、再立(立住物理约束认知)、后收(收敛成需求清单)。读到这里,你应当已经接受一个事实--监控大模型推理,不能用监控 Web 服务的老办法。带着这个前提,我们进入 1.1,逐一把三板斧的失灵拆给你看。