聚焦在线推理运行时、服务链路与统一网关，回答 LLM 怎样真正稳定跑在生产环境里 (2025-2026)
| 层级 | 核心职责 | 典型问题 | 关键关注 |
|---|---|---|---|
| 模型资产 | 提供可运行模型 | 权重版本混乱、量化效果不稳、显存压力大 | 模型版本、量化策略、上下文能力 |
| 推理引擎 | 把模型跑起来 | 吞吐低、显存碎片、并发差、长上下文慢 | Paged Attention、KV Cache、调度策略 |
| 服务运行时 | 处理真实请求流 | 队列堆积、延迟抖动、流式体验差、缓存失效 | Prefill / Decode、Batching、Streaming、重试 |
| 模型网关 | 连接上层应用与多模型后端 | 路由混乱、降级不可控、计费不透明 | 模型路由、Fallback、配额、统一接口 |
| 生产治理 | 让服务长期可运营 | 成本失控、SLA 不稳、问题难归因 | 观测、容量规划、限流、审计与回滚 |
| 层面 | 负责什么 | 典型对象 | 常见失败 |
|---|---|---|---|
| 控制面 | 定义策略、版本和治理规则 | 模型目录、路由策略、租户配额、SLA 等级、灰度规则、供应商优先级 | 策略散落、版本不可追踪、灰度无法回滚、租户权限混乱 |
| 数据面 | 承载每一次真实请求 | 鉴权、限流、队列、路由、缓存、推理调用、流式返回、日志写入 | 队列堆积、超时重试风暴、流式中断、缓存污染、成本归因缺失 |
| 观测面 | 把运行结果变成可复盘证据 | request id、TTFT、prefill / decode、模型版本、route decision、token、成本、错误码 | 只能看到接口失败，看不到模型、上下文、队列和成本的真实根因 |
| 安全面 | 约束谁能调用什么能力 | API key、租户隔离、工具权限、数据域、审计留痕、脱敏策略 | 跨租户数据泄露、工具越权、敏感请求不可追溯 |
没有控制面，网关会退化成一层转发代理；没有稳定数据面，再好的路由策略也扛不住真实流量。成熟模型网关要同时能“改策略不改业务代码”，也能“每个请求都留下可复盘证据”。
在线推理里的延迟、吞吐、显存、成本和稳定性，最终都会落回 token、attention、decode loop、KV Cache 和调度策略这些底层机制。
如果还没有补过模型内部机制，建议先看 Token / Attention / Transformer、训练 / 推理 / Scaling、推理计算 / KV Cache 和 模型评测 / Eval，再回到这一页看生产服务。
| 底层变量 | 影响的服务环节 | 对延迟 / 吞吐 / 成本的含义 | 常见治理动作 |
|---|---|---|---|
| Token 数与上下文长度 | Prefill、队列等待、Prompt Cache | 输入越长，首 token 前需要处理的 attention 计算越多；RAG 和历史对话会直接推高 TTFT 与单位成本。 | 上下文裁剪、摘要压缩、Prompt Cache、RAG Top-K 控制 |
| Attention 与 KV Cache | 显存占用、长上下文调度、批处理容量 | KV Cache 减少重复计算，但会吃掉大量显存；上下文越长、并发越高，越容易被显存而不是算力卡住。 | Paged Attention、KV Cache 管理、长短请求分池、容量水位控制 |
| Decode Loop | 逐 token 生成、Streaming、输出长度 | 输出每多一个 token 都要继续生成一步；总耗时和用户感知体验会被输出长度、首 token 时间和流式平滑度共同决定。 | 限制 max tokens、流式返回、提前停止、模板压缩 |
| Batching 调度 | 吞吐、尾延迟、GPU 利用率 | 批处理能提高吞吐，但不同长度请求混在一起会拉高 P95 / P99，交互式产品不能只看平均吞吐。 | 动态 batching、优先级队列、按请求形态分流、SLA 分层 |
| 量化与模型规格 | 显存、速度、质量边界 | 量化可以降低显存和单位成本，但可能带来质量、稳定性或特定任务能力下降。 | INT8 / INT4 评测、任务分层、灰度发布、回滚策略 |
| 模型路由与网关 | 多模型选择、Fallback、成本归因 | 不同任务不一定该走同一个模型；网关把质量、价格、SLA 和安全策略统一到可治理的入口。 | 规则路由、动态路由、限流配额、降级、请求级审计 |
长 Prompt、RAG 上下文、历史对话和工具输出会先进入 prefill 阶段，消耗大量算力和显存带宽。
每多一个输出 token，就会继续依赖前面生成状态，因此延迟、吞吐和用户感知体验都与生成长度直接相关。
很多团队把问题归因于“模型太慢”，但真正该先看的往往是上下文长度、输出长度和队列调度策略。
缓存已计算过的 attention 状态，可以减少重复计算，但也会显著占用显存并影响调度策略。
批量可以提升吞吐，但也可能拉高尾延迟，尤其是在请求长度差异很大时更容易出现队列抖动。
高吞吐优化通常是在平均吞吐、P95 延迟、显存占用和交互体验之间做权衡，而不是只看单一指标。
复杂推理、低成本分类、长文本分析、多模态处理和高风险审核，往往会对应不同模型或不同服务后端。
认证、配额、路由、Fallback、日志、价格归因和策略限制，都更适合在网关层收束，而不是散落在每个应用里。
当团队开始做模型切换、灰度、降级和成本优化时，网关通常会从“方便封装”升级成“关键底座”。
首 token 时间、流式是否平滑、是否超时、失败后如何降级，常常比理论吞吐更直接影响产品体验。
大模型拥堵时能否切小模型、关闭部分能力、缩短上下文、减少工具调用，决定了服务是否具备韧性。
推理服务的 SLA 通常同时受模型、网关、上下文、流量形态和 GPU 资源状态影响。
| 类别 | 定位 | 典型能力 | 关键关注 |
|---|---|---|---|
| 推理引擎 | 高效运行模型 | vLLM、TGI、TensorRT-LLM、llama.cpp | 吞吐、延迟、显存利用率、兼容性 |
| 模型托管 | 管理部署实例 | 多副本、热更新、自动扩缩容、版本切换 | 冷启动、GPU 调度、资源隔离 |
| 网关层 | 统一模型访问入口 | OpenAI 兼容接口、路由、限流、Fallback、计费归因 | 策略一致性、审计、配额管理 |
| 缓存层 | 减少重复成本 | Prompt Cache、语义缓存、KV Cache 复用 | 命中率、失效策略、正确性 |
| 观测层 | 理解服务健康度 | token、延迟、队列、GPU 利用率、失败率、成本 | P95 / P99、归因粒度、告警质量 |
| 成本治理 | 控制单位请求成本 | 模型分层、流量调度、输出长度控制、上下文压缩 | 质量边界、容量规划、预算策略 |
| 方式 | 强项 | 代价 | 适合场景 |
|---|---|---|---|
| 单模型直连 | 实现简单、故障面小、原型快 | 难做统一路由、降级、成本归因和策略治理 | 单一产品、实验阶段、小规模系统 |
| 模型网关 | 适合统一接入、路由、限流、Fallback 和审计 | 网关本身会成为关键基础设施，需要高可用设计 | 多应用、多模型、组织级平台场景 |
它同样需要面对容量、尾延迟、限流、可用性、回滚和故障定位这些经典生产问题。
平均吞吐很好看，并不代表首 token 时间、P95 延迟和流式体验足够好。
一旦进入多模型、多团队和成本治理阶段，网关很容易成为组织级关键底座。
| 治理点 | 必须定义 | 观测指标 | 和相邻专题的关系 |
|---|---|---|---|
| 鉴权与租户隔离 | 谁能调用哪些模型、工具、数据域和区域后端 | 拒绝率、越权尝试、租户调用分布、敏感请求占比 | 接 AI 治理 / 合规 与安全护栏 |
| 配额与限流 | 按租户、功能、模型、风险等级设置 QPS、并发、token 和预算上限 | 限流率、队列长度、预算命中率、低优先级降级率 | 接 成本 / 性能 |
| 超时与重试 | 入口超时、模型超时、工具超时、最大重试次数和退避策略 | 超时率、重试次数、重试后成功率、重复成本 | 接 一次请求的一生 |
| 熔断与降级 | 供应商故障、模型池拥堵、质量闸门失败时的状态机 | 熔断次数、Fallback 命中率、降级后满意度、恢复时间 | 接 模型路由 / Fallback |
| 缓存与复用 | Prompt Cache、语义缓存、检索缓存、模型预热和节点权重缓存的边界 | 命中率、误命中率、节省 token、缓存失效原因 | 接推理计算、RAG 和成本治理 |
| 流式与取消 | 首 token SLA、客户端断开、用户取消、部分输出和恢复策略 | TTFT、stream 中断率、取消率、已生成未消费 token | 接 AI 产品 UX 与推理计算 |
| 审计与 Trace | 记录 prompt 版本、模型版本、路由决策、工具调用、token、成本和风险标签 | trace 完整率、字段缺失率、事故可复现率 | 接 LLMOps、发布治理和反馈闭环 |
| 版本与灰度 | 模型、prompt、路由、缓存、护栏和供应商策略如何分批上线 | 灰度流量、回滚次数、版本间质量 / 成本差异 | 接 发布变更 / 灰度回滚 |
| SLO 维度 | 建议拆法 | 为什么重要 | 常见动作 |
|---|---|---|---|
| 可用性 | 按模型池、供应商、租户等级、关键功能拆 | 总可用性正常时，核心客户或关键模型可能已经不可用 | 多池隔离、备用供应商、优先级队列 |
| 延迟 | 拆 TTFT、总耗时、prefill、decode、工具往返和后处理 | “慢”可能来自上下文、生成、工具、队列或网关策略 | 上下文瘦身、长短请求分池、输出上限、缓存 |
| 质量 | 按任务切片看格式、引用、事实、拒答和用户采纳 | 模型接口成功不代表业务结果成功 | 质量闸门、评测回归、坏例回流 |
| 成本 | 按租户、功能、模型、输入 / 输出 token 和工具步数归因 | 没有成本 SLO，网关容易成为账单黑箱 | 预算、配额、模型分层、缓存和路由策略 |
| 安全 | 按敏感任务、工具权限、数据域和拦截原因拆 | 高风险请求需要比普通聊天更强的可追溯性 | 输入预检、工具限权、输出审核、人工确认 |
模型网关记录的是路由、限流、成本、缓存和 Fallback 决策，字段口径应能接到 AI 证据包索引，并支持在 请求 Trace / 排障模板 中回放单次请求。
| 网关阶段 | 必须记录的字段 | 用来回答的问题 |
|---|---|---|
| 入口接收 | request_id、tenant_id、user_role、feature、risk_label、region | 这是谁的什么请求，适用哪个数据域、合规边界和服务等级？ |
| 策略裁决 | auth_result、quota_snapshot、rate_limit_bucket、budget_state、policy_version | 系统为什么允许、拒绝、排队、降级或要求更强确认？ |
| 模型路由 | route_id、candidate_models、selected_model、route_reason、fallback_chain | 为什么选这个模型，是否受成本、质量、延迟、风险或供应商状态影响？ |
| 上下文与缓存 | prompt_version、context_pack_id、prompt_cache_hit、semantic_cache_hit、token_budget | 这次请求实际喂给模型的材料是什么，缓存有没有改变成本和答案来源？ |
| 运行时执行 | engine_version、queue_time、prefill_time、decode_time、output_tokens、finish_reason | 慢在哪里，贵在哪里，失败是模型、队列、上下文还是生成阶段造成的？ |
| 审计回流 | trace_id、cost_center、quality_signal、incident_id、feedback_case_id | 坏例、事故、成本异常和发布回滚能否反查到同一次网关决策？ |
多模型网关继续增强: 统一接入、路由、Fallback、计费归因和审计能力会越来越常见。
推理优化继续平台化: KV Cache、调度、缓存、量化和 GPU 资源治理会更像标准化底座能力。
成本与 SLA 一起成为核心指标: 团队会更关注“每次请求值不值得”而不只是“能不能跑出来”。
模型分层与动态路由: 大模型、小模型、专用模型和闭源 API 的组合使用会越来越常态化。
长上下文优化: 更长上下文能力会继续增强，但成本、调度和用户价值的平衡仍值得细抠。
先接能力后补治理: 很多推理系统先把模型跑起来，再补缓存、限流、审计和降级，后期代价往往更高。
GPU 资源黑洞: 没有容量规划和成本归因时，推理层很容易成为组织里的隐形开销中心。
只看离线性能不看在线体验: 本地 benchmark 很好，不代表线上真实流量下的服务稳定性同样好。