AI 网关可观测体系：让大模型调用看得见、查得到、审得清

企业把大模型接入生产后， “能调通” 解决了可用性， “能兜住” 解决了连续性，但紧接着就是第三道难题—— 看不见 。Token 花在哪了、慢在哪了、出了问题怎么查，这三个问题在大模型场景下没有现成答案。AI 网关把监控、日志、追踪三大支柱沉到网关层统一采集，业务方不需要改一行代码，就能获得 Token 级的用量洞察、请求级的延迟拆解、以及全链路的调用追踪。

一、用户场景：大模型调用 “看不见” 的三种痛

延续金融场景——AI 平台团队把混元、DeepSeek、Claude 多家模型统一接入 AI 网关后，智能路由和业务连续性已经跑起来了，但 运营阶段的新问题接踵而至 。

AI 网关可观测能力的 “使用者” 通常不是单一职能，而是 运维、安全、财务、业务、技术 多个角色使用。大家关注点各不相同，但都指向同一个问题： 大模型上线后能不能像传统应用一样被 “看见、查清、追透” 。

无论是哪个角色，本质诉求一致—— 让大模型调用从 “黑盒” 变成 “白盒” 。AI 网关可观测把 Metrics、Logs、Traces 三大支柱沉到网关层统一采集，让每一笔 Token 消耗、每一秒延迟、每一次调用链路，都必须可观测、可查询、可审计。

二、产品功能：监控 + 日志 + 追踪三位一体

AI 网关可观测体系基于 Metrics / Logs / Traces 三支柱架构 ，针对大模型场景做了深度定制—— 不只看 HTTP 层的 QPS 和延迟，而是下沉到 Token 级、模型级、消费者级 。核心功能包括：

• 监控大盘 ：全局概览 + LLM 模型监控 + MCP 工具监控，支持按模型服务、消费者、时间段等多维度下钻。
• CLS 结构化日志 ：使用 CLS 日志，遵循 OpenTelemetry 语义约定， 一条 CLS 查询即可定位慢请求、错误请求、Fallback 链路 。
• 全链路追踪 ：每个请求进入网关时生成或继承 W3C 标准 TraceId，贯穿日志与监控维度，支持按 TraceId 在 CLS 中精确关联路由命中、模型响应、工具调用和 Fallback 记录。
• 审计日志 ：完整记录调用者、时间、模型/路由、请求体、响应体、Fallback 触发原因与切换路径，支持配置留存周期， 满足金融/政务合规要求 。

三、实战案例：一次从 “账单异常” 到 “链路审计” 的端到端排查

真实运维中，成本、性能、链路三类问题很少孤立出现，往往在同一次故障中交织叠加。下面用一次完整案例展示三件套如何协同闭环。

故障现象： 周三早上同时收到两个告警—— 本周 Token 消耗比上周增长 60%，客服 Agent 响应时间从 3 秒飙到 8 秒以上 。

排查闭环：

从告警到根因、从根因到审计、再到修复验证——整个闭环快速完成 ，这正是三件套协同的价值。

（端到端排查闭环示意图）

四、技术实现

AI 网关 天然处在所有模型和 MCP 流量的必经之路 ，可以在一次请求的不同阶段完成数据采集：请求进入时建立 Trace 上下文；路由转发时记录模型、消费者与策略信息；响应完成时统计 Token、延迟和结果；最后在 Log 阶段生成结构化记录，通过独立采集组件上报。

（可观测体系架构图）

技术难点不是 “多打一行日志” ，而是 同时满足四个要求 ：不改业务代码、尽量不增加请求延迟、不同模型使用同一套数据口径、观测链路异常时不能影响正常调用。下面分别介绍四条采集链路，以及两个关键工程设计。

4.1 四条采集链路

• 指标链路（Metrics） ：请求结束后更新 Prometheus 时间序列（请求数、Token、模型耗时、Fallback 次数、MCP 调用等），使用独立的 ai_llm_* 和 mcp_* 指标族，带有模型、消费者、路由等标签。conf-agent 定时拉取并上报云监控，用户也可接入自建 Prometheus。 指标侧只保留适合聚合的有限维度，高基数内容进入日志链路。
• 日志链路（Logs） ：日志插件在请求结束后汇总路由、代理、响应各阶段上下文，交由 OTel Adapter 做语义转换。LLM 与 MCP 日志按场景隔离，各自拥有独立队列和日志主题。 格式转换失败时生成最简骨架日志并保留原始信息，绝不丢弃。
• Trace 链路（Traces） ：请求进入网关时解析 W3C 标准 traceparent（ 00-{TraceId}-{SpanId}-{Flags} ），继承上游 TraceId 或生成新的，写入日志和监控维度，并通过 traceId 返回调用方。
• 基础设施链路 ：在 AI 指标之外建设基础设施监控，采集底层网络流量、带宽和容器系统指标，按容器标识分片采集。 排查时可逐层收敛 ：端到端延迟 → 模型侧耗时 / TPOT → 网关代理耗时 / CLB 带宽 / 节点负载。

（请求链路数据流图）

4.2 性能与资源控制：可观测不能成为新的瓶颈

严格来说，任何观测能力都会产生开销，工程目标不是宣称 “零开销” ，而是 让它不进入模型转发的阻塞路径 ，并把 CPU、内存、磁盘和指标基数控制在明确边界内。

第一层：请求路径只做轻量计算，不做同步网络上报

日志处理发生在底层网关的 Log 阶段。此时上游响应处理已经结束，同步部分只完成上下文读取、OTel 字段映射、JSON 编码和内存入队， 不会在这里进行数据上传，也不会逐条同步写磁盘 。日志处理的逻辑限制只提取请求、响应、延迟以及 LLM、MCP 等必要字段，避免为指标生成一份完整访问日志。高频计数优先通过共享内存中的原子自增完成，再由定时器批量汇总。部分聚合使用 “当前周期写入、上一周期读取” 的 epoch 双缓冲 ：请求与刷盘操作使用不同的 Key 空间，既减少锁竞争，也避免边读取边删除造成数据丢失。

第二层：磁盘写入异步化，并为异常设置止损线

日志进入底层网关的异步批量处理队列后，按批次合并写入文件，以减少频繁系统调用。 LLM、MCP 等场景拥有独立的队列和磁盘慢写状态，某一类日志拥塞不会直接阻塞其他场景。 队列本身有容量上限，避免流量高峰无限占用内存。当一次磁盘写入超过慢写阈值——默认 50ms——对应场景会进入默认 10 秒的冷却期，冷却期间快速跳过落盘；打开或写入文件失败时则交由队列按策略重试。这里的取舍非常明确： 当日志完整性与网关可用性发生冲突时，优先保护业务请求 ，并通过错误日志暴露丢弃和磁盘异常。

第三层：让不再活跃的 Prometheus 指标自动退出内存

模型、路由和消费者会持续变化。如果一个模型已经删除，它对应的 Label 组合仍长期留在网关共享内存中，时间一长就会形成大量 “僵尸指标序列” 。因此 AI 网关为动态指标增加了 TTL（Time To Live，生存时间）生命周期管理 ，通过预设时间参数来自动清理、删除或失效过期数据。

每次指标更新时，系统会同步刷新一个上次访问的时间戳。清理定时器只在一个工作线程中运行，找到过期项后不会立即删除，而是先等待一次同步周期，再重新检查访问时间。 如果这段时间有新请求让指标重新活跃，就取消删除 ，从而避免清理任务与请求更新发生竞态。内部状态 Key 使用 __ 前缀，与真实指标隔离：它们既不会被误暴露成 Prometheus 指标，也不会被 TTL 当成业务 Series 清理。需要特别说明， TTL 清理的是网关本地共享内存中长期不活跃的指标序列，不是删除 Prometheus 或云监控已经保存的历史数据 。历史曲线仍按监控系统自身的留存策略保存。

第四层：在源头限制指标基数

TTL 解决 “旧指标何时退出” ，但无法阻止短时间内产生海量新 Label。为此，MCP Server 等动态维度还设置了单节点基数上限； 当前实现最多保留 1000 个真实 Server 维度，超过上限后统一回落到 mcp_server_name="*" 聚合 。已有的细粒度指标序列会在停止活跃后由 TTL 自然清理。这种 “基数上限 + 通配聚合 + TTL 回收” 的组合，牺牲了极端场景下少量维度精度，却能防止 Prometheus Shared Dict、抓取响应和 Barad 上报批次同时膨胀。对网关这类基础设施而言， 这是比无边界记录更可靠的工程选择。

（性能控制四层防护示意图）

4.3 异常请求兜底：模型没有返回 usage，Token 数据也不 “断档”

正常情况下，模型服务会在响应中返回 usage，其中包含输入和输出 Token 数。但在真实生产环境中， 这个字段并不总是可靠 ：有的兼容接口没有实现 usage；有的流式接口只有最后一个数据块才返回 usage；如果客户端提前断开、上游异常，或最后一个数据块在传输中丢失，网关可能已经转发了大量内容，却拿不到最终统计。 如果简单地把缺失值记为 0，成本、配额和容量趋势都会被系统性低估。 为此，网关采用 “尽量获取、分片累计、最后补偿” 的三级策略：

第一步 是尽量让上游返回准确数据。对于支持该能力的 OpenAI 兼容流式接口，网关会自动补充 stream_options.include_usage=true 。收到分片后也不会机械相加，而是采用 “最大值胜出” 的方式更新 Token 数：这既兼容 “每个分片返回累计值” 的供应商，也兼容 “只在最后一个分片返回总值” 的供应商，还能避免同一分片被重复处理时造成重复计数。

第二步 是在请求侧提前建立独立的输入 Token 估算。网关会根据请求类型提取真正参与推理的文本，并使用本地 tiktoken 兼容编码器计算 Token 数。 编码器按 Worker 延迟加载，计数时只返回数量，不生成完整 Token ID 数组 ，以减少 CPU 和临时内存开销。该结果写入独立的 estimated_input_tokens 字段，不会覆盖模型实报的 input_tokens ；即使分词器加载或解析失败，也只记录失败原因并放行请求， 不会让观测逻辑阻断模型调用 。

第三步 处理最棘手的情况：流式内容已经返回，但最终 usage 完全缺失。对于非多模态响应，网关会根据实际接收到的文本长度，以 “字符数 ÷ 4” 计算一个保守的输出 Token 近似值，并将 usage_source 明确标记为 estimated 。多模态内容可能包含 Base64 或 URL，按字符估算容易产生数量级偏差，因此这类请求不会强行补偿。

（Token 三级补偿策略示意图）

与此同时，日志还会记录 complete 、 client_disconnected 、 provider_error 或 incomplete 等流状态。这样，即使一次请求因客户端断开而只留下部分数据，使用者仍能判断 “这是供应商精确值、分片累计值、还是网关估算值” ，而不会把不同精度的数据混为一谈。例如，一次流式调用已经向客户端输出正文，却在最后一个 usage 分片到达前发生连接中断。传统日志可能只留下 output_tokens=0 ；网关则会保留本地输入估算、根据已接收正文补偿输出 Token，并同时标记 usage_source=estimated 和实际流状态。这样既避免监控曲线突然归零，也为后续审计保留了数据精度边界。

需要强调的是， 估算值用于异常场景下的趋势分析、容量判断和问题排查，不能替代供应商账单 。模型实报值始终优先，估算结果也始终带有来源标记—— “有数据” 与 “知道数据有多可信” 必须同时成立 。

从工程角度看，这套体系的核心不是某一个指标或插件，而是 五个设计原则 ： 请求上下文统一、指标与明细分流、同步处理与异步投递解耦、观测失败不影响业务主链路、异常数据可补偿且来源可追溯 。正是这些底层设计，让 AI 网关不仅能转发模型请求，也能成为 企业统一治理 AI 流量的数据入口 。

五、总结

监控让大模型调用 “看得见” ——Token 消耗、请求延迟、Fallback 触发，每一个指标都按模型、按消费者、按时间段可下钻。 日志让问题 “查得到” ——OpenTelemetry 标准的结构化日志，一条 CLS 查询语句就能定位慢请求、错误请求、Fallback 链路。 追踪让链路 “审得清” ——TraceId 贯穿完整调用链，审计日志满足金融合规。

三者统一在 AI 网关一个入口里采集，业务方 不需要改一行代码，不需要自建监控体系 。当大模型成为基础设施，这层 “可观测屏障” 就是运营的基石 —— 没有可观测，就没有精细化运营。

如果您正在推进企业 AI 应用建设，欢迎在评论区告诉我们你正在面对的 AI 落地挑战。前往产品页面了解详情：https://cloud.tencent.com/product/cngw

AI 网关能力全景

点击 👇 视频查看 「AI 网关接入演示」

往期推荐

让 Token 消费看得见、管得住、省得下 - AI 网关成本治理能力解析

智能路由与业务连续性保障：AI 网关如何让大模型稳定跑在生产链路上

MCP 网关：让存量接口 “零” 代码改造接入 AI 生态

腾讯云原生智能网关 - AI 网关能力全解：一套网关，统一管住模型、工具和智能体

重磅发布！为 AI 原生应用而生 - TDMQ RocketMQ 轻量主题 Lite Topic！