企业官网建设流程全解析

本地大模型服务栈跑起来之后，最难搞的不是模型推理本身，而是它慢到你发疯的时候，你根本不知道从哪查起。日志里全是200，没有任何报错，但一个请求从2秒变成40秒，翻20倍，你连它是哪个环节慢的都看不出来。我给这套栈做了张115个面板的看板，最终把这类问题从"玄学"变成了可观测，这篇文章就聊聊这整套东西的设计思路和落地过程。

先说清楚一件事：大模型服务栈如果只是偶尔崩一下、报个错，那反而好办，报错就是收敛方向。真正让人抓狂的是"没有报错但慢20倍"——请求返回的HTTP状态码全是200，服务没挂，模型还在出字，但就是慢得离谱。这类问题之所以难查，就是因为它没有产生一个明确的错误信号，慢可能来自入口网关，可能来自推理引擎的排队，也可能来自某个请求悄悄挟带了巨大的上下文，把同一块GPU上的算力全抢走了。这些信息，默认的日志系统里一条都不会有。

这篇文章适合谁看：正在做本地大模型私有化部署、OpenAI兼容API接入、或者基于Ollama/vLLM这类推理引擎搭服务的开发者和运维。你不需要一上来就搞115个面板，但你得知道，把本地大模型栈变成可观测的，到底需要盯哪些东西，以及为什么传统那套只盯HTTP状态码和错误日志的方法在这里会失效。

1. 本地大模型服务栈为什么特别难观测

1.1 三层软件叠加，HTTP状态码掩盖了推理引擎的真实状态

用一句话概括本地大模型服务栈的典型形态：最外面是一层OpenAI兼容的API网关，中间是推理引擎（vLLM、Ollama都是这一类），最底下是GPU和基础设施。用户请求进来，先撞到网关，网关转发给推理引擎，推理引擎把任务排到GPU上真正做推理，然后结果再沿原路返回。

问题在于，这一整个过程中，网关这一层只负责"把请求接过来，再原样返回结果"。只要推理引擎没有进程崩溃、连接断开，网关就会返回200。HTTP的200只能说明"请求被接收了"，完全不能说明"推理过程是健康的"。传统Web服务里，数据库查询慢到10秒会抛超时、会出5xx，你可以顺着错误码查到SQL、查到索引。但大模型推理不是这个逻辑——它执行完一个超长的Prefill计算、然后在Decode阶段一个字一个字往外蹦，整个过程没有超时报错，只有"慢"这个结果。观察点全在链路内部，而链路内部的细节默认情况下是完全黑盒的。

1.2 两阶段推理与共享资源，让慢的问题成倍放大

大模型推理和普通Web请求最大的不同在于，它的计算过程被拆成两个行为模式完全不同的阶段。Prefill阶段要一次性处理你输入的所有Token，是典型的计算密集，会把GPU的算力单元打满；Decode阶段是逐Token生成本文输出，每一小步都依赖上一步的结果，天然串行，延迟敏感。这两个阶段在任何指标上表现都不一样——SM占用率不同、内存访问模式不同、耗时分布不同。如果你只盯着"请求平均耗时"这类单一指标，你会什么都看不出来，因为它们把Prefill和Decode的差异全部平均掉了。

更要命的是资源竞争。同一块GPU上，多个请求共享显存、共享算力单元、共享KV Cache和Page Cache。一个请求如果输入上下文特别长，它在Prefill阶段就会吃掉巨量计算资源，同一时间在这块GPU上做Decode的其他请求就会全部被拖慢。这就是"没有报错但慢"的最常见来源之一：不是你的服务坏了，而是某一个不合理的请求把资源抢走了一大半，剩下的所有请求集体变慢，但每个请求单独看又都没有错误。

1.3 为什么"没有报错但慢20倍"比报错更可怕

报错的可怕在于服务中断，但可恨程度有限，因为它给了你一个明确的排查起点——红色的错误码、崩溃堆栈、异常日志，顺着查就是了。"慢20倍"是另一种灾难：所有服务都活着，指标表面上都正常，你的第一反应甚至不是去查监控，而是怀疑是不是自己改错了什么配置、是不是网络变了。等你怀疑完一圈回来，时间已经浪费了几个小时。

这么说吧，我见过太多人在群里嚎"为什么我的服务突然这么慢"，大家七嘴八舌猜方向，猜了半天也没结果。最后一看，某个请求带了20万Token的上下文，在Prefill阶段把整卡算力打满，其他所有请求跟着陪葬。这种事情，你在日志里只会看到一行"200 OK"，没有错误、没有异常、没有超时。唯一能救你的，就是先把"整个过程的时间花在哪"记录下来——这就是可观测的核心。

2. 看板分层的设计思路：先弄清要看什么，再谈面板数量

2.1 设计原则：指标先行，面板是长出来的，不是设计出来的

115个面板这个数字听起来很唬人，但我要说，它不是哪次开会拍脑袋定出来的，而是先梳理了整个调用链路里所有值得记录的度量项，再按这些度量项分成集团落，最后才长成这么多面板。凡是面板数量是先定死的，多半是"为了好看强行拼凑"，这种看板上线第二天就会变成没人看的装饰品。

我的做法是先画一条完整链路图：用户 → 入口网关 → 推理引擎排队区 → 模型执行（Prefill + Decode）→ 输出返回，旁边挂着GPU资源、显存、依赖服务（数据库、向量库、缓存）。然后针对链路中的每一个环节问一个问题：这一步出问题的时候，我靠哪个指标能感知到、能定位到、能反推原因？这些问题对应的答案落下来，就是一张指标清单。面板跟着指标走，一个面板承载一组强相关的指标，数量自然就上来了。

2.2 四层指标架构：基础设施、GPU资源、推理引擎、业务API

我在设计时把指标分成四层，每层解决一个层面的问题。

第一层是基础设施，包括CPU、内存、磁盘IO、网络流量、节点温度这一类。它们解决的问题是"机器本身有没有事"。第二层是GPU资源，显存使用率、显存分配量、SM占用率、GPU温度、功耗、NVLink带宽、ECC错误计数。它们回答的是"算力资源够不够、有没有被吃满"。第三层是推理引擎，模型加载状态、在线模型数量、队列深度、Batch Size、KV Cache命中率、显存碎片率、Prefill tokens/s、Decode tokens/s、TTFT、TPOT。这一层回答的是"推理引擎本身是否健康，慢是慢在哪个环节"。第四层是业务API层，请求量、错误率、P50/P95/P99延迟、Token吞吐量、请求体大小、超时次数、重试次数、连接池占用情况。它回答的是"从用户角度看，服务到底表现如何"。

这四层不是并列关系，而是需要互相映射的。API层慢，你要能下钻到推理引擎层，再看GPU层。每层都有自己独立的观察面，但排查问题时必须能串起来，否则就是四个孤岛。

2.3 别忘了依赖服务：数据库、向量库、缓存

大模型服务栈从来不是孤零零一个模型进程。常见的配套还有PostgreSQL存会话历史、向量库做知识库检索、Redis做缓存，有些场景连对象存储都要掺一脚。这些依赖服务挂在主链路的旁边，看着不起眼，但它们出问题时同样不会在你的模型日志里留下任何痕迹。

举个例子：检索增强生成（RAG）场景下，一个请求进来要先去向量库做相似度检索，向量库的索引没建好，查询从几毫秒变成几百毫秒甚至几秒，然后这段结果再喂给模型做Prefill，直接把完整响应拉长。你从API层看，就是慢；从推理引擎看，只看到PreFill阶段之前有一段空白；实际情况是向量库背锅。所以这层依赖服务的延迟、连接池数量、队列堆积情况，都必须纳入看板体系。做115个面板的时候，我把这层单拎了出来，大概占了15个左右。

3. 115个面板是怎么拆出来的：按板块算细账

3.1 基础设施与GPU层：别让散热、磁盘IO和显存碎片变成隐形瓶颈

先拆基础设施层，这部分看着最"传统"，但最容易翻车。我用大概20个面板覆盖：每个节点的CPU使用率、负载、内存剩余、磁盘吞吐、磁盘延迟、网络吞吐、网络重传率、温度曲线。很多本地部署的机器是几年前的旧服务器，散热本来就堪忧，GPU一旦吃满，温度飙到85度以上，显卡会自动降频，推理速度直接掉一大截。这种问题如果你不看温度曲线，你会以为是模型变笨了，其实是显卡在"自我防爆"。

GPU层我单独拆了18个面板，比基础设施还细。显存使用率只是最基本的，关键是显存碎片率——你在一个服务里反复加载、卸载模型，显存会被切成大小不一的小块，新模型加载时明明总显存够用，但找不到连续的大块，推理引擎只能先做碎片整理，这个过程极其耗时。还有KV Cache的分配和命中率，它决定的是多轮对话场景下，有多少历史上下文可以直接复用，而不是每次重新算一遍。ECC错误计数也要盯，GPU显存出现比特翻转时，第一个表现往往不是崩溃，而是计算变慢、偶尔输出异常，这类故障不看硬件计数，根本定位不到。

3.2 推理引擎层：115个面板的主体，真正的"慢"来源

推理引擎这一层我拆得最多，差不多32个面板。原因很简单：大模型服务栈里，绝大多数"没有报错但慢"的问题出在这一层。

首先是队列类指标。vLLM这类引擎是异步调度架构，请求进来后先进队列，由调度器决定什么时候把一批请求合并成一个Batch塞给GPU。队列深度、请求排队时长、平均Batch Size，这三个指标直接决定了一个请求从进入引擎到真正开始计算要等多久。如果队列深度常年几十上百，你的P50延迟一定会高，而这份延迟完全不是GPU算出来的，是排出来的。

然后是Spec-Decode类的优化指标。具体来说就是KV Cache命中率。多轮对话或者大量相似上下文的请求，如果Cache命中率高，大部分历史Token不用重新计算，速度会快很多；反之，每次请求都全量计算。这个指标掉下去的话，你的推理时长会成倍增长，但依然不会产生任何报错。

最核心的还是把推理过程拆开看。TTFT（首Token延迟）衡量用户从发出请求到看到第一个字符的时间，这个是用户体感的关键；TPOT（每输出Token耗时）衡量生成阶段逐字吐字的速度。这两个指标一定要单独拆开做面板，因为它们的变化原因完全不同：TTFT暴涨多半是因为Prefill阶段计算量大、排队时间长；TPOT异常则大概率是GPU算力被其他请求抢占或者模型配置问题。混在一起看，等于什么都没看。

3.3 API网关层与依赖服务层：把用户体验与后端资源映射起来

业务API层的20个面板相对常规，请求量、错误率、延迟分位数、Token吞吐量都有。但有两个我特意做了的细节值得提。一个是请求体大小面板，记录每个请求的输入Token数量。你别小看这个指标，我踩过的大坑里有一半都和它有关——某个客户端把几千页的文档全文塞进system prompt，输入Token量从平时的几千涨到几万、十几万，请求量没变，但是服务端计算量暴增，全栈变慢。另一个是连接池状态，OpenAI兼容网关和推理引擎之间、网关和下游依赖之间的连接池一旦耗尽，请求就开始排队，表现也是"没报错但慢"。

依赖服务层的15个面板我按组件拆：PostgreSQL的连接数、慢查询数、锁等待、WAL写入速率；向量库的查询延迟、构建索引进度、队列深度；Redis的命中率、内存碎片、阻塞命令耗时。这些面板平时安安静静没什么存在感，但出事的时候它们就是第一道防线。

3.4 总览页与告警联动页：面板再多，入口只能有一个

115个面板不可能每个都天天看，所以我单独留了10个面板做总览和联动。总览页只放最高层次的判断指标：整体请求量、P50/P99延迟趋势、平均TTFT、平均TPOT、GPU平均利用率、显存平均占用、队列堆积数。一旦有哪个不正常，再从总览页顺着变量跳转到对应层级的详情面板。

Grafana的模板变量在这里非常有用。我把模型名、节点名、网关名都做成了变量，新人上手时只需要在总览页看到一个指标异常，点进去，筛选对应的模型和节点，就能把范围快速缩小。这10个面板的联动设计比单独的100个面板加起来还重要，因为没有入口的看板群，就是一堆积灰的页面。

4. 落地过程中最容易踩的坑：单位、口径与告警风暴

4.1 单位不统一的坑：看着都是数字，实际上差着1024倍

我先讲一个真实翻车案例。本地大模型服务栈部署完，各个Exporter数据都通了，我把内存相关的所有指标拉到一个面板上，结果CPU内存显示的数字和GPU显存显示的数字差距巨大，我还以为显存爆了，后来才发现一个是MB（十进制）、一个是MiB（二进制）。在Linux下，free命令和Prometheus采集到的内存数值经常带着不同的单位基准，一个是实际字节数，一个被Exporter换算成了人类可读的GB。这导致的结果是：面板看起来整整齐齐，但告警阈值根本没法设置，因为你不知道触发告警的那个数字到底代不代表真实情况。

我的建议是：全站统一用字节数或者统一用人类可读单位。Prometheus原生的node_exporter会返回原始字节数，面板上再用Grafana的Unit转换为GiB显示；GPU显存类指标也一样。统一口径之后再来定告警阈值，才有意义。

4.2 告警规则不是越多越好：三条高价值规则胜过三十条噪音

115个面板如果配上115套告警，团队马上就会被告警风暴淹死。我的经验是，告警规则必须围绕"会让人措手不及"的指标来定，比如队列深度暴涨、KV Cache命中率骤降、TTFT P99超过阈值、显存碎片率过高。至于CPU用了80%这种，根本不用告警，占用高了你去面板上看一眼就行。

我踩过的坑是：一开始把告警阈值设得太敏感，某个模型加载的阶段，GPU利用率短暂冲高，告警连着响了十几条，群里的兄弟被狼来了消耗掉耐心，真出事的时候反而不看了。后来我把所有告警都加了持续时间和收敛窗口，利用率持续5分钟超过90%再告，队列深度持续3分钟超过16再告。噪音降下来，告警的含金量才上去。

4.3 面板多了之后的管理问题：JSON模板化与版本管理

115个面板，全部靠手点界面去配置，维护成本高到离谱，哪天面板误删了，你连复制的模板都没有。所以一定要走Infrastructure as Code的路子，把Grafana面板的JSON定义存到代码仓库里，用Grafana的Provisioning机制自动加载。后续任何一块面板的修改，都要走代码变更、走审查流程。

这里有个细节：Grafana面板的JSON是庞大的嵌套结构，手工编辑会疯掉。建议用Jsonnet或者直接Python脚本生成部分重复度高的面板。我在实践中就是写了一个脚本，根据模型列表自动生成每个模型独立面板的基础结构，只改一组参数就批量产出几十个面板，省下大量手工时间。

5. 实测复盘：把"没有报错但慢20倍"完整抓出来的全过程

5.1 现象描述：一切正常，但所有请求都在坐慢车

一个很典型的场景。服务栈跑的是本地部署的推理引擎，OpenAI兼容网关外面套着一层业务接入。正常情况下，单请求的端到端耗时在2秒左右，用户体验良好。某天下午开始，监控显示P99延迟直接飙到40多秒，P50也有8秒，翻了近20倍。但诡异的是，API层错误率始终是0，HTTP状态码全是200。从网关日志看，每个请求都被正常接收、正常返回，没有任何异常堆栈。

这时候你去看什么？平时只会看日志的人会彻底懵掉：日志里根本没有线索。幸好这时候看板已经是齐的，我直接从总览页往下钻。

5.2 排查链路：从总览页一路钻到根源

第一步，打开总览页，看延迟趋势。P99是从下午2点开始陡增的，再看队列深度面板，同一时间点推理引擎的排队队列深度从个位数涨到80以上，说明有大量请求涌入了，但请求量面板显示QPS没有明显变化。这说明不是流量涨了，而是每个请求的处理时间变长了，反过来导致队列排不出去。

第二步，去推理引擎层看Prefill和Decode的耗时分部。Decode的TPOT指标基本正常，问题不大；但Prefill的耗时曲线暴涨，每请求平均Prefill时间从几百毫秒涨到七八秒，翻了10倍。这说明是输入侧出问题了，GPU在花大量时间处理输入内容。

第三步，去API层看请求体大小的面板。趋势一拉出来，答案就浮出水面了：从下午2点开始，某些请求的输入Token数量从几百涨到十几万甚至二十万。再追一下，发现是某个接入方做了一次升级，在他们那个场景里把一个超大文档全文塞到了system prompt里，做了一个"一次性全量上下文"的改动。

第四步，回GPU层确认根因。Prefill阶段SM占用率打满，显存用量飙升，其他并发请求的Decode阶段只能抢剩下的算力，所以每个人都慢。整个链路没有任何一个环节报错，但大家全部被"那一锅大输入"连累。

5.3 修复与验证：限流、拆分、压缩，一个都不能少

定位到根源之后，修复分了三步走。

第一步，对请求体大小做准入控制。在网关层加一个输入Token数上限，超过阈值的请求直接拒绝或者降级，不让他们进推理引擎。这一步立竿见影，队列深度马上降下去了。

第二步，让接入方把超大上下文改成检索式方案，不要每次都塞全量文档，而是先检索相关片段再拼接。

第三步，在推理引擎侧开启Prefix Caching相关的功能，让相同的历史上下文尽量复用KV Cache，而不是每次重新算一遍。

改完之后，再从面板上看Prefill耗时曲线，立刻回落到几百毫秒，P99延迟回到2到3秒区间。

5.4 复盘：没有这套看板，这个问题会怎么发展

如果还停留在"盯错误日志"的阶段，这类问题至少要排查几个小时甚至一天。因为日志全是200，你会怀疑代码改坏了、网络出问题了、资源分配不合理，方向完全无法收敛。但有了分层的指标之后，我锁定这个根因一共花了不到10分钟。这不是玄学，而是"把慢的过程本身记录下来"带来的确定性回报。

6. 部署这套体系的选型与落地建议

6.1 采集层：Prometheus + 自定义Exporter的组合

聊到具体选型，本地大模型服务栈的可观测性，主干的组合是Prometheus抓取指标、Grafana出面板、Loki收集日志、Alertmanager负责告警。这个组合在本地部署场景下很皮实，资源消耗也不大，Prometheus本身只占几百MB内存。

采集端的细节比较关键。GPU指标一般靠DCGM Exporter，它能给出显存使用率、SM占用率、温度、功耗、PCIe带宽等几十个指标。推理引擎方面，vLLM比较省心，自带/metrics接口，直接暴露了排队时长、TTFT、Token吞吐、KV Cache使用情况等关键指标，配好Prometheus的抓取配置就能用。

6.2 Ollama这类没有原生指标的引擎，得自己想办法

Ollama和vLLM不一样，很长时间里没有暴露完整的Prometheus指标接口。如果你是用Ollama搭的场景，最省事也最可靠的办法是包一层代理服务，在请求进入和返回时记录耗时、Token数、排队时长，然后以自研Exporter的方式暴露出来。如果只想用现成的，也可以解析服务日志，从日志里抓取请求时间和Token数量生成指标。我的建议是：别过度依赖日志解析，日志格式一变你的指标就断供，最稳妥的是在网关层用中间件做埋点，数据质量高，且不依赖引擎版本。

6.3 Grafana配置经验：模板变量、面板JSON和权限管理

落地到最后，几个Grafana实操细节说一下。第一，模板变量一定要配，把模型名、节点、网关名都做成变量，面板之间才能互相联动。第二，所有面板定义全部存到Git仓库里，用Provisioning自动加载，不要在Web UI里手工改完就算。第三，权限分配上，开发、运维、业务方各开只读账号，避免有人误删面板。

其中模板变量这步我多说一句。115个面板看起来多，但如果都配好了【模型】【节点】这类筛选变量，任何一个面板，你只要切换变量，整个面板就在不同模型/节点间切换，实用度会提升一个量级。否则115个面板就是115个死页面，根本看不完。

做完这115个面板之后，最大的心里感受是，本地大模型服务栈终于从一个"黑盒子"变成了一套"透明管道"。每一个请求从进来到出去，到底在排队、在Prefill、在Decode还是在等依赖服务，都有对应的面板能看出状态。下次如果再遇到"没有报错但慢20倍"，我不用再去猜，直接打开总览页，往下钻——这比我在这套体系上投入的几百个小时，值多了。