40 篇博文 含有标签「infrastructure」

我在上个季度交谈过的一个团队在财务伙伴指出 AI 账单时陷入了短暂的恐慌。他们原以为，像大多数团队一样，昂贵的支出项会是生成——即聊天、总结和智能体推理背后的 GPT 级调用。事实并非如此。他们的每月 Embedding 支出在 1 月悄然超过了生成支出，到 3 月翻了一番，并有望在年中翻两番。没有人为此建模，因为 Embedding 模型的每 Token 定价看起来就像舍入误差：小型模型每百万 Token 2 美分，大型模型 13 美分。按照这个费率，谁会为此做预算？

答案是：任何产品度过了原型阶段并开始大规模索引内容的团队。在不断增长的语料库上进行语义搜索、重复检测、分类、聚类、更换模型时的重新索引——每一个工作负载消耗的 Embedding Token 都是以十亿计，而不是以百万计。与受用户请求限制的生成不同，Embedding 的吞吐量仅受你决定索引的内容限制。而这一决定很少经过成本审查。

本篇文章将探讨 Embedding 支出升级的具体机制、改变成本曲线的架构杠杆，以及从托管 API 转向自建服务的盈亏平衡计算。

你的仪表板很干净。昨天的部署也已干净地回滚。模型版本已锁定。提示词没有更改。但你的 TTFT p99 刚刚翻了一倍，客户成功渠道已经炸锅了，而你唯一能给出的诚实回答是“这是提供商的问题”。这个答案显得很苍白——就像耸耸肩一样——它通常会引出一个团队中没人能回答的后续问题：证明它。

这是托管 LLM 推理中营销页面不会讨论的部分。当你调用前沿模型 API 时，你正在与你看不见的负载共享 GPU、PCIe 结构、连续批处理和 KV 缓存预算。你的 p99 是这些负载突发的函数。大规模推理的经济性取决于租户的多路复用是否足够紧密，以使硬件利用率保持在 60-70% 以上，这意味着你的尾部延迟在结构上与同一分片上最大、最不规整、最不稳定的租户耦合。你购买的不是容量；你购买的是一个别人也排在其中的队列切片。

这种天真的算法是这样的。我们的主供应商拥有 99.3% 的可用性。增加第二个具有类似独立性的供应商，同时故障的概率就会降至大约 0.005%。成本翻倍，风险降至两百分之一。工程负责人批准了双倍预算，轮值报警在供应商宕机时也不再响起。电子表格显示，这是路线图上性价比最高的可靠性投资。

六个月后，电子表格错了。评估套件（eval suite）的运行时间变成了三倍，提示词（prompt）修改需要提交两个 PR，每周的回归报告中有两列内容相互矛盾，而且没人记得预发布环境的备选方案当前路由到了哪个供应商。一旦团队核算了用于保持两条路径校准的人力工时，双倍预算实际上更接近 4–5 倍。第二个供应商在技术上仍在提供流量，但一半的功能已被悄悄锁定在其中一方，因为保持两者同步已经变得不再划算。

这就是多模型成本陷阱。可靠性算法是正确的；但团队搞错的是运营层面的算法。接下来是对引入多供应商后的成本分解、大多数团队应该首先尝试的“单供应商加降级模式”方案，以及真正证明这种非线性复杂性合理性的少数准则。

当检索质量回退（retrieval quality regression）第一次出现在你的值班频道（on-call channel）时，调试路径几乎总是指向一些令人意外的地方。不是嵌入模型（embedding model），不是重排序器（reranker），也不是提示词（prompt）。罪魁祸首通常是对分块器（chunker）的一行改动——比如更换了分词器、调整了边界规则或步幅（stride）——而这行代码是三个冲刺（sprint）前有人合并进预处理 notebook 的。这次修复没有触及任何生产代码。它在夜间重建了索引。而现在，所有租户的准确率都下降了四个百分点。

分块器就是数据库 Schema。你提取的每个字段、划定的每个边界、选择的每个步幅，都定义了存入向量索引的“行”的形状。修改其中任何一项，你就在改变索引的 Schema。而你系统的其他部分——检索逻辑、重排序特征、评估框架、下游提示词——都依赖于这个索引，并假设它是稳定的。但由于分块器通常存在于 notebook 或一个没人将其视为“基础设施”的小型 Python 模块中，这些改动在上线时往往只被当作配置微调，但其爆炸半径却相当于执行了一次 ALTER TABLE。

黑色星期五的流量峰值来了。传统 API 服务的应对方式是启动更多容器。60 秒之内，你的容量就扩充到三倍。自动扩缩容器做了它一贯的事，你安然入睡。

但如果用同一个自动扩缩容器跑 LLM，结果就大相径庭了。新的 GPU 实例要在四分钟的模型权重加载之后才能上线。等那时候，你的请求队列已经塞满，现有 GPU 在半途生成的请求的内存压力下颠簸挣扎，用户盯着转圈圈的加载动画发呆。增加更多算力没有任何帮助——瓶颈根本不在你以为的地方。

AI 推理负载打破了让响应式自动扩缩容在传统服务中奏效的大多数假设。理解其中的原因，是构建能够扛住流量峰值的系统的前提。

你的 GPU 监控面板正在欺骗你。利用率显示 60%，推理集群看起来健康无虞。用户却在经历 8 秒的首 Token 时间（TTFT）。值班工程师检查内存——正常。计算——正常。然而队列在增长，延迟在飙升。这就是将传统容量规划应用于 LLM 工作负载时会发生的事：你信赖的指标指向了错误的地方，真正的瓶颈在用户开始抱怨之前一直不可见。

根本问题在于：LLM 消耗的是一种本质上不同的资源。CPU 服务交换的是计算和内存。LLM 服务交换的是 Token——而 Token 的行为与请求截然不同。

12 要素应用（12-Factor App）准则让开发/生产环境一致性（dev/prod parity）变得家喻户晓：尽可能保持开发、预发布和生产环境的相似。对于传统的 Web 服务，这基本是可以实现的。但对于 LLM 应用，这在结构上是不可能的 —— 且其中的差距远比大多数团队意识到的要大。

问题不在于开发者粗心大意。而是在于 LLM 应用依赖于一类特殊的基础设施（缓存计算、实时模型权重、不断演进的向量索引以及随机性生成），在这些设施中，预发布环境（staging）与生产环境之间的差异不仅是令人不便，而是本质上完全不同。一个看起来正确的预发布环境至少会在七个具体方面对你撒谎。

大多数工程团队会花费数周时间来评估 LLM 提供商——对延迟进行基准测试、测试准确性、洽谈价格。然后，他们会在一个下午，仅仅根据一个设计精美的落地页和一篇好评博文，就选定了一个观测工具、一个护栏供应商和一个嵌入提供商。这种不对称性是本末倒置的。你的 LLM 提供商可能是一家资本充足且拥有稳定 API 的公司，但其周围的小众供应商通常并非如此。

AI 服务生态系统已经爆发式地增长到了几十个类别：护栏供应商、嵌入提供商、观测与追踪工具、微调平台、评估框架。每个类别都有十家初创公司在争夺同样的企业预算。其中一些会被收购，更多的会倒闭。少数公司会转型，并在发出 90 天通知邮件后弃用你的关键工作流。在没有经过严格评估的情况下基于这个生态系统进行构建，是一种直到演变成生产事故才会出现在你的待办事项中的技术债务。

大多数在大语言模型（LLM）之上构建 SaaS 产品的团队都是通过惨痛的教训才发现多租户问题的：他们利用单一的共享提示词配置快速出海，然后惊恐地发现一个客户的系统提示词泄露到了另一个客户的响应中，或者某个企业级客户耗尽了所有人的速率限制，亦或是当月 AI 账单寄来时，根本无法确定是哪个客户造成了 40% 的支出。这种失败模式并非停留在理论层面——NDSS 2025 的一篇论文证明，vLLM、SGLang、LightLLM 和 DeepSpeed 中的前缀缓存（prefix caching）可以被利用，仅通过时间信号和精心构造的请求，就能以 99% 的准确率重建另一个租户的提示词。

构建多租户 AI 基础设施与传统数据库的多租户化并不相同。共享组件——推理服务器、KV 缓存、嵌入流水线、检索索引——每一个都面临独特的隔离挑战。这篇文章涵盖了你实际必须解决的四个问题：隔离、定制、成本归因以及单租户质量追踪。

大多数团队决定使用端侧 LLM 推理的方式，就像他们决定重写数据库时一样：冲动行事，仅仅是为了应对原本可以用更廉价方案解决的问题。推介词总是令人心动——无需网络往返、完全隐私、零推理成本——而且初始原型也验证了这一点。然而，在发布六个月后，模型开始悄无声息地输出更差的结果，新的操作系统更新打破了量化兼容性，而那些使用廉价安卓手机的用户正在运行一个你无法推送更新的版本。

本指南旨在让你在看清现实的情况下做出决策。在特定场景下，端侧推理确实是正确的选择，但其成本结构与团队预期的不同，且生产环境中的失效模式与云端 LLM 部署几乎完全不同。

大多数团队在发布第一个可执行代码的智能体（Agent）时，只采取了一种安全控制措施：API 密钥范围限制（API key scoping）。他们给智能体一个具有 repo:read 权限的 GitHub 令牌，以及一个可以访问工作目录的 shell，然后就称其为“已沙箱化”。这种做法是错误的，其弊端只有在发生安全事故后才会变得显而易见。

能够编写和执行代码的智能体的威胁模型与 Web 服务器或 CLI 工具的威胁模型有着本质的区别。攻击面不再是协议边界，而是智能体读取的一切内容。这包括 git 提交记录、文档页面、API 响应、数据库记录以及它打开的任何文件。其中的任何输入都可能包含提示词注入（prompt injection），从而将你的研究型智能体转变为数据泄露管道。

大多数构建 LLM 功能的团队选择流式协议的方式就像选择字体一样：快速、不加思索，然后忍受由此带来的后果多年。这种选择第一次让你踩坑通常是在生产环境中——比如 CloudFlare 524 超时导致你的 SSE 流损坏，WebSocket 服务器在持续负载下发生内存泄漏，或者 gRPC-Web 集成在单元测试中表现良好，但在客户端需要向上游发送消息时静默失败。协议决定了你的故障模式。基于基准吞吐量进行选择是一个错误的切入点。

每个主要的 LLM 提供商——OpenAI、Anthropic、Cohere、Hugging Face——都通过 Server-Sent Events (SSE) 流式传输 Token。这一事实是一个强有力的先验理由，但并不是因为 SSE 快。而是因为 SSE 是无状态的，能与 HTTP 基础设施轻松兼容，且其故障模式是可预测的。问题的关键在于你的应用是否有某些需求迫使你偏离这条路径。