14 篇博文 含有标签「llm-infrastructure」

合规审计总是从同一个问题开始，而你的团队也总是以同样的方式回答：“客户数据在哪里处理？”在欧盟（EU）地区。幻灯片是这么说的，SDK 配置截图证实了这一点，DPA（数据处理协议）也做出了承诺。接着，审计员提取了上个季度的请求日志样本，将其与服务商的每请求区域头信息（per-request region header）进行比对，房间里顿时安静了下来。在大约 40 分钟的容量事件期间，大约 4% 的欧盟企业 Prompt 由美国区域的推理节点提供服务，而团队对此一无所知。保存可重用前缀（prefixes）的缓存位于全球池中。支持团队查询的追踪存储（trace store）位于 us-east。DPA 成了幻灯片。合同成了一个路由提示（routing hint）。

这种事件不会出现在事后分析（postmortem）中，因为没有任何服务降级。模型返回了答案，用户得到了响应，延迟图表保持平稳。出故障的是仪表盘从未监测到的东西：请求穿过服务商基础设施的地理路径。那些绝不会将 us-east-1 的 URL 与“请求实际上在 us-east-1 执行”混为一谈的工程师，在 LLM API 层级却经常犯同样的错误，因为服务商的区域参数看起来像 AWS 的参数，在正常路径（happy path）下表现也像 AWS，但一旦首选区域的 GPU 耗尽，它就会静默降级为“尽力而为（best effort）”模式。

你的重试逻辑在遇到 429 时会退避。当延迟上升时，你的队列深度告警会触发。在这两个信号之间，存在一个供应商负载区间，此时正确的做法是“减速 20%”——而供应商唯一会告诉你的是那个姗姗来迟的二进制限流信号。对于智能体集群协作来说，最有用的信号恰恰是没有任何推理 API 真正公开的那个。

429 是墓碑，而不是警告。当你收到它时，供应商已经认定你的流量过载，你已经浪费了一次请求的 Token 计数，而且——如果你与其他消费者共享租户——他们可能也收到了。有趣的故障模式不是 429 本身；而是它发生前的几秒钟，那时全世界的客户端都在“一切正常”和“你被切断”之间盲目飞行。

传统的容量规划（capacity planning）建立在一个默认的假设之上：请求在大体上是可以互换的。Web 服务器处理登录、搜索、结账 —— 尽管这些操作有所不同，但它们的差异都在一个范围之内。你衡量每秒请求数（RPS），观察 p50 和 p99 延迟，乘以安全系数，然后进行资源配置。这个模型之所以有效，是因为工作的基本单位 —— 单个请求 —— 具有稳定的成本。

Agent（智能体）的工作负载从根本上打破了这个假设。你对 Agent 的一个查询可能通过一次简单的生成就解决了：300 个 token 输入，200 个输出，两秒钟搞定。但下一个查询，表面上看起来一模一样，却可能触发一个规划步骤，分发出 40 个工具调用（tool calls），在每一轮对话中重新读取不断增长的上下文，并在四分钟内消耗掉 120 万个 token。同样的端点（endpoint），同一个用户，同一条代码路径。单个请求的成本差异可能达到三个数量级，而且请求中没有任何信息能预先告诉你接下来会遇到哪种情况。

关于 AI 网关是自研还是购买的决策，几乎从来不是基于某种决策框架做出的。它往往在第一周由一位对该问题感兴趣的工程师凭直觉决定，然后在第九个月由一位厌倦了账单的总监重新审视。这两个时刻都不是做决策的最佳时机，而且双方都没有站在未来 18 个月的关键维度上来衡量这一选择。

自研路径的诱人之处在于第一个月非常便宜。在 OpenAI 前面加一个 200 行代码的代理，写一个 switch 语句将“claude”请求路由到 Anthropic，再加上一个重试循环，团队就交付了一个看起来像网关的东西。到了第九个月，那个代理变成了 1.2 万行代码，充斥着写了一半的重试逻辑、失效机制混乱的 Prompt 缓存、没人敢相信的成本统计、在上次事故中触发方式错误的备用路由、与技术栈其他部分脱节的可观测性模式，以及在第一个企业客户提出要求后强行加入的租户限流。每一个功能都是“购买路径”在第一天就能交付的功能的拙劣复制。而当初写那 200 行代码的工程师已经离职了。

这种说辞听起来很负责任。“我们别在各处硬编码 OpenAI —— 我们在前面加一层薄薄的抽象，这样以后如果需要，我们可以随时更换供应商。”两年后，那个“薄薄的抽象”变成了一项拥有自己部署流水线、SRE 值班表、拦截糟糕 Prompt 的评估门控、每年节省七位数资金的语义缓存、带有针对特定供应商退避机制的重试策略、所有仪表盘都依赖的可观测性架构，以及一个存放着六家模型厂商凭证的密钥库的服务。公司里的每一个 AI 功能最终都汇聚于此。

它也几乎是在无意间，成为了整个技术栈中爆炸半径最大的单点故障（SPOF）。当主要 LLM 供应商宕机时 —— 2025 年，OpenAI 自 1 月以来被记录了 294 次停机事件，而 Anthropic 仅在 12 月就记录了 184.5 小时的总客户影响 —— 网关会自动绕过它，大多数用户甚至察觉不到。而当网关本身挂掉时，每个产品中的每个 AI 功能都会同时停止工作，原本应该触发的故障转移根本没有机会执行，复盘报告的开头往往是：“我们为了隔离供应商宕机影响而构建的抽象层，本身成了那场宕机。”

提示词缓存（Prompt caching）是一种只要开启就能立即获益的优化手段。长系统提示词仅需哈希一次，KV 状态驻留在 GPU 显存中，随后任何复用该前缀的请求都能跳过预填充（prefill）成本。供应商报告称，对于缓存的请求，延迟降低了 80%，输入成本降低了 90%。在大规模应用中，这种经济效益是无法抗拒的：摊销到数百万次调用中的单一共享前缀，将一项支出变成了几乎可以忽略不计的尾差。

实现这种节省的机制本质上是一种共享资源，其命中或未命中的状态可以通过延迟来观察。这种可观察性就是侧信道（side channel）。在网络外部可以清晰分辨缓存命中与缓存未命中，这种差异巨大且具有确定性。这项在成本看板上占有一席之地的优化方案，还兼任了一份无人预料的工作：泄露同一供应商下其他租户当前正在进行的活动信息。

大多数关于AI延迟的讨论都搞错了方向。团队痴迷于GPU利用率、模型量化和批处理大小。与此同时，真正让用户感到烦躁的延迟——AI开口说话前的那段停顿——几乎完全由推理开始前发生的事情决定。瓶颈在于上下文，而非算力。

首Token时间（TTFT）是决定AI功能感觉灵敏还是迟钝的关键指标。而TTFT主要由预填充阶段主导：在生成任何输出Token之前，处理完整输入上下文所需的时间。对于128K Token的上下文，预填充可能耗时数秒。GPU在努力工作，但用户什么也看不到。

解决方案不是更好的GPU，而是在用户提问之前就预先加载好上下文。

多租户 SaaS 在十年前就解决了数据隔离问题。Postgres 中的行级安全性（Row-level security）、每个租户的加密密钥、范围限定为租户前缀的 S3 存储桶策略——到 2018 年，这套方案已经非常成熟，以至于当审计员询问“向我展示客户 A 的数据如何无法触及客户 B 的数据”时，只需要提供一份一页纸的回答，并在每一层附上引用即可。AI 功能悄然重新引入了这个问题，而现在的答案不再只有一页纸。

有趣的部分并不是 AI 破坏了隔离。有趣的是它在 哪里 破坏了隔离：不是审计团队守卫了十年的数据层，而是没有人画在图表上的四个新层级。提示词缓存前缀（Prompt cache prefixes）以跨请求共享 KV 状态的方式，将首字生成时间（time-to-first-token）变成了一个侧信道。在聚合客户数据上训练的微调模型会记住特定租户的措辞，并将其反馈给错误的客户。当威胁模型要求物理分离时，嵌入索引（Embedding indexes）却通过查询过滤器进行逻辑分区。跨请求的 KV 缓存重用创建了时间信道，而当“共享推理没问题”被视为一种合理的捷径时，没有人对此进行过威胁建模。

本篇文章讨论了发生了哪些变化，以及当你认真对待这个问题时，这种规范看起来是什么样子的。

一个每步成功率为 95% 的智能体并不是一个 95% 可靠的智能体。将 20 个步骤串联起来，端到端的完成率就会下降到 36%。这是大多数团队在智能体上线生产环境后才发现的算数逻辑，也是为什么这么多“运行良好”的原型在真实流量涌入的瞬间就会陷入停滞。解决方法不是更好的提示词或更大的模型，而是一个乏味的分布式系统基础设施，大多数 AI 团队在第三次宕机被迫应对之前都会试图避开它。

这种基础设施就是“持久化执行”（durable execution）——这是一种让多步骤工作流在崩溃、重启和局部故障中幸存且不丢失进度的准则。这并不是什么新鲜主意。Temporal、Restate、DBOS、Inngest 和 Azure Durable Task 已经为此推销多年。2026 年的新变化是，每个严肃的智能体框架都已悄然承认持久化执行是入场券：LangGraph 现在内置了 PostgresSaver 检查点，OpenAI Agents SDK 暴露了 resume（恢复）原语，Anthropic 的 Managed Agents 运行在内部的持久化基座上。如果你的智能体架构仍然依赖 Celery 队列和乐观主义，那么你是在 2026 年解决一个整个行业在 2024 年就不再假装视而不见的问题。

本文探讨的是无状态 LLM 与必须包装它的有状态工作流引擎之间的架构接缝。接缝之处正是可靠性所在，也是大多数团队目前编写 Bug 的地方。

这个 Demo 只需 20 分钟就能构建完成。你粘贴一个 URL，大语言模型（LLM）读取 HTML，结构化数据就从另一端输出了。这感觉就像网页数据提取的未来已经到来。

然后，你以每小时 1,000 页的速度运行它。成本飙升，屏蔽不断积累，提取出的字段开始以一种看起来不像错误的方式发生偏移——它们看起来像正常数据，直到你的下游流水线已经默默地摄取了三周的垃圾。“LLM 读取页面”的模式并没有错，只是它的定价更适合原型的吞吐量。

智能体（Agentic）网页提取确实解决了传统爬虫无法解决的问题。但要将其扩展到概念验证（PoC）阶段之后，需要理解一组与大多数团队预期不同的故障模式。

大多数 AI 产品都是为单一用户、单一意图、单一对话线程和单一身份构建的。当产品是个人生产力工具（如写作助手、代码补全引擎、摘要生成器）时，这运作得足够好。但当团队开始协作使用 AI 时，情况发生了变化：产品会以难以诊断且更难修复的方式悄然失效。两个用户同时向 AI 提问，其中一个输入消失了。五个工程师共享的上下文窗口充满了重复的历史记录。AI 使用用户 B 的权限回答用户 A 的问题。没有人为这些情况做过设计，因为交付多用户共享上下文意味着要面对现代 AI 基础设施中最难的分布式系统问题之一。

本篇文章将探讨为什么同步多用户 AI 会话如此困难、生产团队尝试了哪些方案，以及新兴的架构模式是什么。如果你正在构建协作 AI 功能并疑惑为何它感觉复杂得离谱，这就是原因。

两个智能体收到同一条用户消息。一个在 3 秒内用 400 个 Token 完成任务；另一个进入 Reflexion 循环，耗尽 40,000 个 Token，在任务中途触及上下文限制，产出一个半成品答案。两个系统都没有预测到会是哪种结果。这不是边缘情况——这是智能体在没有对任务深度建立任何模型的情况下启动任务时的默认行为。

基于 LLM 的智能体在执行前对任务范围没有天然感知。用自然语言读起来简单的请求可能需要十几次工具调用和多轮规划；听起来复杂的请求可能只需一次查找即可解决。没有执行前的复杂度估算，智能体就会盲目提交资源：随着轮次历史积累，上下文窗口呈二次方填满；规划开销主导执行时间；等到系统检测到问题时，导致问题的早期决策已经无法撤销。