59 篇博文 含有标签「infrastructure」

你的 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 基础设施轻松兼容，且其故障模式是可预测的。问题的关键在于你的应用是否有某些需求迫使你偏离这条路径。

每个正在基于LLM构建系统的工程团队，都在做基础设施决策时忽视了一项隐性成本。你会追踪token数量、延迟和API开支，但几乎没有人追踪其运行的推理工作负载的碳排放——而这个缺口正在迅速收窄，来自监管和市场两个方向的压力都在增加。

AI系统现在占全球温室气体排放的2.5–3.7%，已正式超过航空业2%的贡献，且每年增长15%。仅2024年，运行AI专用服务器的美国数据中心就消耗了53–76 TWh的电力——足以为720万户家庭供电一年。这种规模已不再是假设，工程团队需要了解自身贡献的预期正成为真实的组织压力。

当工程师评估向量数据库时，他们通常会加载 ANN 基准测试，并选择在 recall-at-10 排行榜上名列前茅的产品。三个月后，他们就开始提交迁移工单了。这些基准测试是在单一客户端、静态且索引完美的索引数据集上测量查询吞吐量的。但生产环境完全不是这样。

本指南涵盖了预测向量数据库在实际工作负载下能否撑住的五个维度，以及一个将这些维度与你的技术栈进行匹配的决策框架。

团队调度循环 AI Agent 任务最常见的方式，也是最危险的方式：一个每隔 N 分钟触发一次 REST 调用的 Cron 条目，它启动一个 LLM 工作流，任务要么完成，要么悄无声息地失败。这个模式在预发布环境看起来没什么问题，但在生产环境中，它会制造出一类极难发现、难以恢复、难以推理的故障。

Cron 诞生于 1975 年，最初是为运维脚本设计的。它所内建的假设——运行时间短、无状态执行、触发即忘——在每一个维度上都与 LLM 工作负载的现实相悖。循环 AI Agent 任务是长时运行的、有状态的、成本高昂的，其失败方式会在多次重试中不断叠加。用 Cron 来调度它们，不只是可靠性风险，更是可见性风险：出问题时，你往往浑然不知。

你的 AI 产品有两个功能面：一个面向用户的聊天功能和一个后台报告生成任务。两者在同一个 Key 下调用同一个 LLM API。一个下午，你收到了一张工单：“聊天回复在中途被截断了。”没有触发任何警报。日志中也没有 429 错误。API 在整个过程中一直返回 HTTP 200。

发生了什么：报告生成任务逐渐消耗了你大部分的共享 Token 配额。聊天请求虽然能完成，但仅达到了你的 max_tokens 限制——在语义上被截断，在语法上有效，却在无声无息中出错了。你的标准监控从未察觉到这一点，因为在 HTTP 层面上没有任何异常。

这并不是一种边缘情况。当工程师将 LLM 速率限制视为简单的节流问题，而不是意识到它们实际上属于分布式系统失效类别时，就会发生这种情况。

大多数工程团队认为自己已经对 LLM 供应商锁定做了充分防护：用 LiteLLM 统一 API 调用、避免在托管平台上做微调、把原始数据存在自己的存储里。他们感到安全。然后某天提供商宣布弃用某模型，或竞争对手降价 40%，团队才发现，自己搭建的抽象层大概只处理了约 20% 的实际迁移成本。

另外 80% 藏在没人仔细看过的地方：围绕模型格式怪癖写成的系统提示词、按照某个模型的拒绝阈值校准的评估套件、一旦换模型就会失效的嵌入索引，以及建立在某种行为模式上却根本无法迁移的用户预期。