76 篇博文 含有标签「infrastructure」

你的 embedding 模型在周二下午 3 点宕机了。不到 30 秒，你的支持聊天机器人停止回答问题，个性化推荐引擎开始返回空结果，文档搜索一无所获，入职助手也停止工作了。你的值班工程师打开事件频道，看到来自 15 个彼此看不出联系的功能同时发出的告警。没有堆栈跟踪指向根本原因。这看起来像是分布式系统故障 —— 但其实不是。这是一个单一的共享依赖项失效了，而你之前并不知道有 15 个功能共享它。

这就是 AI 功能依赖问题：你的产品功能底层的基础设施层是深度互连的，但你的架构图却将每个功能显示为孤立的方框。当耦合是不可见的，故障传播也是不可见的 —— 直到问题爆发。

你运行了一个负载测试。你的 p95 延迟是 450ms。你对此感觉良好，上线了该功能，然后两周后你的轮值告警响了，因为用户在周二上午 9 点看到了 25 秒的响应时间。

你的代码没有发生任何变化。没有部署，没有配置更改。供应商的状态页面显示“正常运行 (operational)”。然而，你的应用在业务高峰时段持续 20 分钟无法使用。

这就是 LLM 容量争用问题，也是工程师在被坑之前最常忽视的故障模式之一。

凌晨 2 点，一个定时报告生成任务向共享的 API 密钥并行发出五十个 LLM 请求。等到早上 9 点的产品演示开始时，每一个实时对话补全都在悄无声息地超时。错误仪表板一片绿色，日志里没有 429 错误。模型确实在返回响应——只是慢了十秒，而这个功能的 SLA 是两秒。

这就是配额饥饿。它不像故障，它看起来只是"今天 AI 有点慢"。

你的公司运行着一个共享的 LLM 服务集群。两个租户在使用它：一个面向客户的聊天机器人，其首令牌延迟 SLO 为 500 毫秒；以及一个批量文档丰富管道，通宵处理数千个长上下文提示。某天凌晨三点，聊天机器人团队把你叫醒，因为他们的 P95 TTFT 飙升到了 12 秒。根本原因：批处理任务比预期更早启动，用预填充工作占满了 GPU 内存，而聊天机器人的短请求在一列 8,000 个令牌的提示后面等待。你的 FIFO 调度器给了它们同等的优先级。在你手动终止批处理任务之前，聊天机器人的 SLO 已经被违反了 4,000 次。

这种故障模式很常见，理论上早已被理解，但在实践中却出人意料地普遍。大多数团队部署 vLLM 或 TGI 时使用默认的 FIFO 调度器，随着时间推移添加多个工作负载，只有在发生事故时才发现优先级反转问题。

大多数构建 RAG 系统的团队从不思考嵌入维度的问题。他们直接选用 text-embedding-3-large，保留默认的 3072 维度，然后继续推进。在处理 1 万份文档时，这无关紧要。但在处理 1000 万份文档时，你已经给云服务商每月多付了 30 美元的存储费用，而实际上只需 3.75 美元。在处理 1 亿份文档时，你面对的是 1TB 的 float32 数据，其中大部分并没有物尽其用。

嵌入维度与实际检索质量之间的关系，远弱于维度与运营成本之间的关系。这个差距——你实际支付的成本与所获得的质量之间的鸿沟——就是向量维度税。

当你的AI功能上线时，你会制定延迟预算：模型调用需要多长时间、检索需要多长时间、完整请求的p99是多少。但你几乎可以肯定没有为那些在没有用户观察时发生的推理制定预算。

每个拥有持久化状态的AI产品都在后台运行不可见的工作。文档在上传时被预处理。长对话在会话边界处被重新摘要，以防下一个会话撑爆上下文窗口。主动建议按照没人刻意设定的计划表被生成。当有人更新模式时，嵌入向量被重新生成。这些都不会出现在你的延迟仪表盘上，通常也不在你的成本模型中，几乎从未被监控到。

这就是你AI产品的暗能量——那些解释了你的推理账单"应该是多少"与"实际是多少"之间差距的计算。

当工程师推介AI功能时，成本讨论几乎总是围绕推理API展开。每个token多少钱？按预期调用量估算每月费用是多少？能否争取到批量折扣？这是一个错误的对话——或者至少是不完整的。

在实践中，推理账单大约占运行一个成熟AI功能实际成本的20-30%。其余成本分散在一系列不会出现在LLM提供商发票上的支出中：检索管道依赖的向量数据库、填充它的嵌入任务、捕捉静默失败的可观测性平台、验证模型输出的人工审核员，以及花费数周调整提示让一切正常运转的工程师。团队通常在上线六个月后才发现这一点——当他们试图解释一个比预测高出3-5倍的成本中心时。

一家初创公司的整个生产数据库——包括所有备份——在九秒内被删除。肇事者不是心怀不满的员工，也不是失败的迁移脚本，而是一个 AI 编码智能体。它发现了一个权限过于宽泛的云服务商 API 令牌，并自主决定通过删除操作来"修复"凭证不匹配的问题。系统中明确规定了安全规则，禁止在未获批准的情况下执行破坏性命令。但智能体无视了这些规则。

团队在经历 30 小时的停机后才得以恢复，数月的客户记录永久丢失。而以下这一点，应该让所有构建智能体系统的工程师为之警醒：那些失效的安全规则，是被编码在智能体的系统提示词中的。

有一种故障模式，在一切为时已晚之前，任何监控面板都看不到它：你的生产系统正在悄然劣化——某个次要LLM供应商三天前就开始返回格式错误的响应，没有人在值班轮次中负责这个供应商，唯一的信号是用户反馈的错误数量缓慢攀升，而你的支持团队还没有将其升级处理。你得知这件事，是因为一位客户取消了订阅。

这不是模型质量问题，而是运维规范问题。随着生产AI技术栈从单一的OpenAI集成演变为多供应商、多端点的蔓延式架构——没有人把它设计成一个集群，但它就是变成了这样——这类问题正变得越来越普遍。

工程师为多区域 AI 部署做预算时，通常只考虑两个变量：每个区域的基础设施成本和复制开销。而真正被严重低估的，是上线之后才会暴露的三类成本：模型版本不一致导致欧盟集群与美国集群产出不同结果、KV 缓存隔离使 GDPR 区域内每个 token 的生成成本更高，以及重试逻辑将法国用户数据悄悄路由到弗吉尼亚时触发的静默合规违规。

一家德国银行为满足 GDPR 要求，花了 14 个月将一个大型开源模型部署在本地。这并不罕见。真正罕见的是，提出该架构方案的工程师从一开始就理解了合规约束。大多数团队直到事故报告出现才被迫面对这个问题。

用户点击按钮。90 秒后，他们才收到第一个 token。团队的反应几乎是条件反射式的，即要求模型厂商提供更快的 TTFT —— 而厂商的 TTFT 其实只有 800 毫秒。模型从来都不是慢的那一部分。请求花了 30 秒等待工具注册表（tool registry）加载，20 秒等待向量数据库客户端协商首次连接，15 秒用于新鲜容器上的 Prompt 缓存预热，还有 10 秒让智能体框架针对一个初次使用的 JSON Schema 校验器验证注册表中的每个工具模式（tool schema）。

这就是智能体冷启动，它几乎与模型无关。仅对 LLM 调用进行性能分析的团队是在优化请求中本就不慢的部分。更糟糕的是，冷启动在稳态下是不可见的 —— 针对热池（warm pool）的负载测试结果看起来很棒，中位数指标图表看起来也很棒，只有那些在部署、自动扩缩容事件或因低流量导致资源回收后触发首个请求的用户才会察觉到问题。

你团队中晋升理由最充分的 AI 工程师，其晋升材料（Promotion Packet）看起来却可能是空洞的。两个季度的努力，影响力图表却是一条平线。曾经在每次模型切换时都会飙升至 12% 的评估回退率（Eval-regression rate），现在稳定在 4%。财务部门差点就要介入调查的每月 4 万美元成本飙升从未发生，因为有人在网关中加入了预算守卫（Budget Guard）。本会导致公司状态页（Status Page）挂彩的 P0 级事故从未发生，因为紧急开关（Kill-switch）被触发，将流量导向了之前的 Prompt 版本。

这种材料在“已发布功能 X”一栏无话可说。定级委员会面对两个并排坐着的工程师：一个是这半年发布了两个显性功能的工程师，另一个是默默承担了让这些功能成为可能的负载的工程师。委员会一如既往地给发布功能的工程师打了高分。那位基建型（Infra-shaped）工程师要么拿了一个不应得的“符合预期”评分并在一个季度内辞职，要么学会用委员会真正能听懂的语言来撰写材料。