现在，推理速度已经快过你的数据库了

打开任何 2024 年时代的 AI 功能链路追踪 (trace)，模型调用就像是一头巨鲸。八百毫秒的生成时间，包裹在检索、鉴权和数据库查询组成的薄壳中，后者的时间几乎可以忽略不计。那一年的每一个架构决策——缓存、预取、流式 UX——都是为了隐藏那头“巨鲸”。

现在，查看运行在 2026 年推理栈上的相同功能的链路追踪。那头巨鲸已经变成了一只海豚。缓存后的预填充 (prefill) 在 180ms 内返回第一个 token。解码 (decode) 以每秒 120 个 token 的速度流式传输。模型不再是慢节点。你自己的基础设施才是，而且大部分基础设施还没有意识到这一点。

这种顺序重排是今年最重要的性能转变，也是各团队一直反应不足的一个。现在，AI 请求的 p99 底限是由特征存储 (feature store) 调用、鉴权中间件以及那些一直都很慢的 Postgres 查询决定的——在模型占据九成预算时，没人关心这些。

顺序是如何反转的

在过去的 18 个月里，三种力量共同作用，其中任何一种都能产生显著影响。它们共同作用，使大多数交互式工作负载的端到端延迟中模型的占比缩减了一半以上。

提示词缓存 (Prompt caching) 成为主流。 与冷推理相比，缓存预填充将首个 token 响应时间 (TTFT) 降低了高达 80%。在冷路径上需要 4.3 秒才能完成预填充的 10,000 token 提示词，现在只需 600ms 即可返回第一个 token。供应商侧的缓存已成为准入门槛；每一个主要的推理栈——vLLM、SGLang、TensorRT-LLM——都支持前缀缓存 (prefix-cache)，而 llm-d 风格的分布式 KV 缓存正在将这些收益带入多副本部署中。

投机采样 (Speculative decoding) 从论文走向生产。 草稿模型投机采样现在作为 vLLM 的默认功能发布，在通用工作负载上能提供 1.4–1.6 倍的加速，在特定领域的工作负载上提升更多。在 gpt-oss 级别的模型上，投机采样在基准测试中将每个 token 的延迟降低了约 40%；专门的代码合并模型速度可达每秒 10,000+ token。解码，这个曾经无法逃避的串行瓶颈，现在已经变成了一个在以前产出一个 token 的时间内可以产出三个 token 的赛道。

API 价格崩盘，供应商在延迟上展开竞争。 API 价格在 2024 年到 2026 年间下降了约 80%。供应商不再仅仅在模型质量上竞争，而是开始在 TTFT 上竞争。如今在主要供应商中，同类模型在类似条件下的 TTFT 差异可达 3–5 倍——这意味着在不改动任何代码的情况下，更换供应商就能将用户可见的底限延迟缩减整整一秒。

实际结果是：对于缓存的交互式工作负载，LLM 调用在链路追踪中的占比已从端到端延迟的 70–90% 缩减到了更接近 30–50% 的水平。而其他一切都保持原样。

新的长尾效应

查看当今实际交互式 AI 功能的延迟栈，其构成与去年基础设施团队仪表板上的截图截然不同。

针对托管检索器的向量搜索会为响应流水线增加 50–300ms。针对已配置的 DynamoDB 表的特征存储查询，在 p50 时每个特征运行 15–40ms，而在限流情况下 p99 可能飙升至数百毫秒。由于产品层面要求反规范化输出而连接了三张表的 Postgres 查询，其 p50 延迟可能为 80ms，p99 延迟为 600ms。鉴权中间件——那种验证 JWT、检查会话缓存并刷新个人资料的中间件——如果缓存未命中，会增加 50–150ms。然后模型才开始运行。

这些组件都没有变慢。它们保持不变，而模型在它们周围缩小了。这些组件所处的架构在设计时假设模型是最昂贵的部分，并将其他一切视为“免费”的。这个假设不再成立，每一个体现这一假设的地方——串行顺序、缺乏并行性、为旧概况设置的资源池——现在都是一个延迟漏洞。

这种失效模式既是技术上的，也是文化上的。仪表板仍然显示“模型：90%”，因为它们是基于三个架构版本前构建的，而且没人重新进行过分析。当 p99 警报触发时，值班工程师仍然习惯性地将“模型变慢了”作为默认假设。团队负责人仍然会说“我们无法让它更快，模型就是这样”——而模型正是栈中今年变快了 2 倍的那一部分。

当模型缩小，并行化的障碍是什么

这种转变最重要的架构后果是，许多 AI 功能的延迟图 (latency graph) 在拓扑结构上对旧模型是正确的，但对新模型来说已经坏掉了。

这是经典的形状：请求进入；鉴权和会话查找串行发生；针对向量库运行检索步骤；检索到的上下文被组装成提示词；模型调用触发；响应流式回传。那个 DAG（有向无环图）是合法的，但效率不高。当模型占据 80% 的执行时间时，它是高效的，因为并行化一个占比 20% 的片段并不能显著改变现状——阿姆达尔定律（Amdahl）胜出，没人费那劲，生活照旧。

将模型的占比翻转到 30%，计算方式就变了。将鉴权和检索相互并行化（对于大多数查询，两者都独立于用户的消息），可以在模型仅耗时 400ms 的请求中削减 100–300ms。基于上一个助手回合预取检索，使其在用户发送下一条消息时已经处于热状态，可以再赢得 100–300ms。将频繁读取的上下文提升到提示词缓存边界，使缓存预填充在各回合之间保持热状态，将原本的冷路径惩罚变成了稳态下的“免费午餐”。

这些都不是新技术。它们被讨论、被忽视、被三心二意地实施了好多年，因为模型是主导成本，而这些优化只是舍入误差。现在，它们成了制胜关键。2026 年赢得延迟竞赛的团队，将是那些愿意再次将请求图视为优化问题的团队，就像后端工程师在 2018 年所有人集体遗忘这件事之前所做的那样。

你的仪表盘中缺失的指标

如果团队的可观测性仍然将 LLM 调用整合为一个仅带有耗时属性（duration attribute）的不透明 span，那么事后分析（post-mortem）将会陷入死循环。真正值得关注的变动性隐藏在 span 内部，而目前的做法完全无法体现这一点。

现在至少需要具备以下层面的追踪能力：

• 将 Prefill（预填充）和 Decode（解码）作为独立事件。 Prefill 是计算密集型且可缓存的；Decode 是带宽密集型且串行的。将它们视为同一个数字会掩盖关于慢请求的所有关键信息，包括这种缓慢是源于冷缓存（cold cache）还是糟糕的批处理位置（batch position）。
• 每个 span 上的缓存命中率。 如果没有这个指标，团队就无法区分延迟退化究竟是由缓存失效引起的，还是由供应商侧的容量事件引起的。这两者需要完全不同的应对措施；在它们之间误判方向会导致数天的调查成本。
• 批处理位置（Batch position）和队列等待时间作为属性。 在共享端点上，用户的请求正在与其他租户竞争 GPU 时间。与批处理位置相关的 p99 峰值是资源配置（provisioning）信号；而不相关的则是 Prompt 结构（prompt-shape）信号。仪表盘必须同时显示这两者。
• 上游供应商的请求 ID。 当延迟发生在供应商侧时，提交有效技术支持工单的唯一方法是将你的追踪 ID 与他们的 ID 进行比对。在 span 中透传他们的请求 ID 只需要几分钟的设置时间，却能在每次事故中节省数小时。

在 2025 年建立起这些基础能力的团队，现在通常会发现他们 AI 功能三分之二的延迟债务存在于模型之外 —— 即那些在模型主导追踪时从未显现的地方。而没有建立这些能力的团队，在模型表现完全稳定时，仍会花费三天时间去调试“模型变慢了”的问题。

架构团队的对话

在 2026 年，大多数 AI 平台团队需要与他们的基础设施（Infra）团队进行一次特定的对话，而大多数团队尚未进行。

基础设施维基上显示的“LLM 推理：占请求预算的 90%”截图截取于 2024 年，且至今未曾更新。许多规划决策仍基于该截图做出 —— 哪些服务获得优化人力、哪些组件被认为“值得缓存”、Prompt 构建路径是应该重新架构还是维持现状。然而，目前的分布情况已经发生了翻天覆地的变化，但组织内部尚未消化这一事实。

具体要提出的论据如下：

1. 运行过去 18 个月的堆叠延迟柱状图。 展示模型的占比正在萎缩，而其他一切保持持平。这是改变内部认知最有效的图表；在团队看到它之前，他们会一直优化那些已经为他们优化过的部分。
2. 重新界定优化积压任务的范围。 之前因为“只能节省 20ms”而被降低优先级的特征存储（feature-store）延迟优化工作，现在节省的是 400ms 预算中的 20ms，而不是 4000ms 预算中的 20ms。在没有任何代码改动的情况下，其相对影响力提升了 10 倍。
3. 挑战“模型是波动源”的假设。 当 p99 报警触发时，首要假设不再应该是“供应商正处于糟糕的一分钟”，而应该是“我们自己堆栈中的某些部分变慢了”。默认假设必须改变，否则故障修复时间（time-to-resolution）将不断突破 SLO。

第一次对话可能会进行得不顺利。它可能会被贴上 AI 团队推诿责任，或者基础设施团队试图抢夺供应商功劳的标签。但无论如何也要坚持推动 —— 最好是用数据说话 —— 这样才能赢回下一年的延迟预算。

这种转变是永久性的，且将持续推进

这一趋势不会停止。推理供应商在投机性解码（speculative decoding）、分布式 KV 缓存和前缀共享（prefix-sharing）方面的迭代速度，比你的数据库团队在查询计划上的迭代速度还要快。模型延迟与基础设施延迟之间的差距将持续扩大，直到你自己的堆栈占据预算的绝大部分。

现在需要采纳的架构准则：

• 将检索（Retrieval）、鉴权（Auth）和特征查找视为热路径（hot path），而非点缀。 它们就是热路径。它们一直都是；而现在的数字迫使团队不得不承认这一点。
• 积极地并行化。 任何不依赖于用户当前消息的操作都可以在消息到达之前或与鉴权并行运行。预取（Prefetching）不再是过早优化。
• 按组件衡量，而非按供应商。 “今天模型很慢”是一个过时的借口。真正的问题是请求图（request graph）中的哪个组件退化了，而答案几乎从不是团队最关注的那个组件。
• 每年重建一次心理模型。 分布情况明年还会再次改变。每两个季度重新进行一次延迟分析的团队，会在下一次转变演变为事故之前捕捉到它。而不做分析的团队，将花费一个季度的时间去追逐“幽灵退化”。

当仪表盘还没回过神来时，模型已经不再是瓶颈了。率先注意到这一点的团队将获得一轮免费的延迟优化红利。而没注意到的团队将在 2026 年费力地解释，为什么他们的 AI 功能在纸面上变快了，但在产品中却变慢了。