778 篇博文 含有标签「llm」

你的 CI 流水线固若金汤。容器镜像在部署前经过签名和验证。每个 npm 和 PyPI 依赖项都根据带有固定哈希值的锁文件进行解析。提交需要签名标签。然后，在你模型服务启动脚本的某个地方，有一行代码从模型中心或 S3 存储桶下载数 GB 的二进制大对象（blob）并将其加载到内存中——没有签名检查，没有哈希验证，也没有生产者的记录。这个对你产品实际功能起决定性作用的唯一制品，偏偏是你的供应链工具从未听说过的那个。

这并非虚构的漏洞。安全研究人员已经从公共中心撤下了数百个恶意模型——这些模型在你加载它们的瞬间就会执行攻击者代码，它们是专为绕过中心运行的扫描器而精心设计的。弥补这一漏洞的工具现已存在：安全序列化格式、行业签名规范、以及拒绝未签名权重的准入控制器。大多数团队只是还没意识到，“模型文件”与“来自互联网且未经审计的二进制文件”在本质上是同一类东西。

在你的代码库中的某个地方，有一个配置文件，在 test 配置下写着类似 model: small-and-cheap，而在 production 下写着 model: frontier。当有人添加这一行时，感觉是很负责任的做法 —— 为什么要为了每天运行 20 次的 CI 任务去消耗 frontier 模型的 token 呢？但那一行代码悄无声息地废除了一项你的团队十五年来一直在不假思索遵循的规则：你测试的环境应该表现得和你上线的环境一致。

“十二要素应用宣言”（Twelve-factor methodology）称之为开发环境与生产环境等同（dev/prod parity），我们在这方面已经做得非常出色，以至于我们开始忽略它的存在。Docker 为我们提供了位级一致的运行时环境。基础设施即代码（Infrastructure-as-code）为我们提供了完全一致的拓扑结构。然后，我们在请求路径中间加入了一个语言模型，重新引入了我们花了十年时间才弥合的差距 —— 只不过这一次，产生差异的组件不再是数据库版本。而是系统中负责做决策的部分。

在你的代码库中的某个地方，存在一个网关，让你只需更改一个字符串就能将 claude-sonnet 替换为 gpt-5。你的架构评审对此赞不绝口。你的 CTO 因此睡得更香。然而，它正在悄悄让你付出代价：损失了 90% 的缓存折扣、Schema 强制输出，以及那些区分优秀生产模型与平庸模型的推理努力（reasoning-effort）调节旋钮。

这就是统一 LLM API 未被宣传的代价。每一个承诺“一行代码切换供应商”的抽象层，都是通过将每个供应商的功能投射到它们共有的子集来实现的——而那些落在这个子集之外的功能，恰恰是供应商竞争最激烈的地方。Prompt 缓存语义、结构化输出强制、扩展思考预算、服务端工具执行：这些才是决定你实际成本和质量曲线的关键杠杆，而你的网关可能正在默默地将它们弃之不用。

打开你的 Token 仪表板，针对其中的每一个工作负载问一个问题：是否有真人在等待这个响应？对于大多数在生产环境中运行智能体（Agent）的团队来说，诚实的回答是：至少有一半以上的账单并非如此。评估套件（Eval suites）、向量回填（embedding backfills）、每日报告生成、批量分类、隔夜代码迁移、昨日工单总结——这些任务都没有用户在盯着进度条。然而，几乎所有这些任务都流经交互式端点，以全额价格支付，并与那些真正对延迟敏感的请求竞争同样的容量。

每个主流供应商都会以一半的成本运行这些可延迟的工作。OpenAI 的 Batch API、Anthropic 的 Message Batches 以及 Gemini 的 batch 模式都为异步作业提供统一的 50% 折扣，以换取 24 小时的完成窗口。这种折扣不需要谈判，不需要承诺消费，也不需要工程上的壮举。它只要求你在架构中承认，某些工作是可以等待的——而大多数团队从未做出过这种让步，因为没有人将“延迟交付”作为一个设计决策。

我们以前看过这类戏码。多年来，抢占式实例（Spot instances）为云计算提供了 60–90% 的折扣，但大多数团队仍将所有业务保留在“按需（on-demand）”模式下。这并非因为节省的费用不真实，而是因为使用它们被迫面对一个令人不安的问题：我们哪些工作负载可以容忍中断？回答了这一问题的团队构建了检查点（checkpointing），并将计算账单削减了一半以上。没回答的团队则继续支付“凡事皆紧急”税。批处理层级是同样的岔路口，只不过坐标轴从“中断容忍度”变成了“延迟容忍度”——而且智能体工作负载每项任务消耗的 Token 是聊天机器人的 5 到 30 倍，这使得不作选择的代价要昂贵得多。

五十年来，数据管道通过“宕机”来强制执行它们的契约。上游团队重命名了一个列，下游解析器抛出异常，任务崩溃，有人在凌晨 2 点收到告警，到了早上，契约要么被修复，要么被正式重新协商。没有人将其设计为一种治理机制。它只是源于这样一个事实：僵化的代码无法处理它预期之外的输入。崩溃就是执行。告警器就是审计追踪。


接着，我们让 LLM 坐上了消费者的位置，于是破损不再导致崩溃。

模型在读取格式错误的数据记录时不会抛出解析错误。它会“自适应”。缺失的字段变成了看似合理的猜测。重命名的字段变成了略微错误的解读。单位的变化——从分到元，从 UTC 到本地时间——变成了一个自信的答案，而其偏差倍数模型从未提及。管道端到端显示为绿色，仪表盘保持静默，而破碎的契约在三周后才浮出水面，表现为一种谁也无法进行二分定位（bisect）的弥散性质量投诉。我们没有消除故障。我们消除的是“信号”。

大多数企业级 LLM 合同的谈判逻辑都是倒置的。法务部门会花三周时间研究“责任限制”条款——这一条款几乎永远不会被触发——而决定你的产品明年能否存活的条款，却在格式条款中被草草通过：供应商有权弃用你所依赖的模型，而通知义务仅定义为“尽商业上的合理努力通知你”。

问问那些在模型退役日期截止前仍有生产流量的人吧。迁移不是一次法律事件，而是一场工程“消防演习”——重新运行评估套件，重新调整那些表现已经悄然发生变化的提示词 (Prompts)，还要向客户解释为什么助手的语气一夜之间变了。任何赔偿条款都无法涵盖这种损失。但是，如果在前期谈妥“弃用通知”条款，就能将这场消防演习转化为一个有计划的项目。

这是一份针对 AI 买家、真正能转移风险的条款清单，大致按它们对你造成负面影响的频率排序。同样重要的是，它还评估了哪些杠杆是供应商真正会愿意让步的，而哪些条款只会让你白白浪费谈判筹码。

询问基础设施团队，如果主数据库宕机会发生什么，你会得到一个演练过的答案：副本、故障转移运行手册、某人签字确认的 RTO 和 RPO 指标。询问同一个团队，如果模型 API 宕机会发生什么，你通常只会得到一个耸肩和指向供应商状态页面的链接。这种不对称性在 2023 年是有道理的，那时 LLM 只是驱动一个实验性的侧边栏。但在你的支持流程、搜索排名、代码审查机器人和入职助手都开始通过单一供应商的推理端点路由的那天起，这种不对称就不再合理了。

模型 API 现在是许多产品的 Tier-0 依赖项——对营收至关重要，且与数据库一样位于请求路径中——但大多数灾难恢复计划仍将其视为可有可无的集成。其结果是一种熟悉的故障形态：供应商服务降级，产品中的每个 AI 功能都显示相同的加载图标，值班人员盯着一个他们无法影响的状态页面，没人能回答唯一重要的问题：这个产品现在应该做什么？

在某处，此时此刻，一个 AI 助手正在向潜在客户解释你的产品。它引用的价格是你 18 个月前修改过的，推荐的集成是你上个季度停止支持的，并建议一个返回 410 Gone 的 API 端点。你永远不会看到这段对话。没有分析事件被触发。没有会话录像。潜在客户要么相信了错误答案并提交了一份困惑的支持工单，要么相信了错误答案，转而悄悄购买了模型随口提到的竞争对手的产品。

这不是一个假设的未来问题。AI 推荐已经占据了可观的流量 —— 对于某些技术和电子商务网站，这一比例高达 5–8% —— 而这些推荐背后的答案，是模型在任何时候吸收的关于你的任何信息生成的。你的营销团队花了十年时间学习如何监控品牌搜索、评论网站和社交媒体提及。几乎没有人正在监控增长最快的表面：当有人询问关于你的信息时，模型是怎么说的。

你拥有的每一份延迟优化手册（latency playbook）都是为那些单次请求工作量大致恒定的系统编写的。数据库查询耗时相对固定。图像缩放随像素数变化，而这是预先可知的。甚至经典的 LLM 补全也有可预测的成本范畴：输入多少 token，输出有限的 token。推理模型悄无声息地打破了这一假设。当模型在运行时自行决定思考多久——且它是基于问题难度来决定时——响应时间便不再是基础设施的属性，而变成了问题本身的属性。

后果首先体现在你的分位数指标上。在生产环境中运行推理模型的团队报告称，p99 延迟会激增到 p50 的三到五倍，这不是因为主机变慢或缓存失效，而是因为百分之一的请求恰好真的很难。你的自动扩缩容策略、超时策略和 SLO 仪表板都是针对一个“这种差异意味着系统出现故障”的世界而调整的。而现在，这却意味着系统正按设计运行——你用来管理尾部延迟的所有工具都指向了错误的原因。

每个安全团队对拼写抢注 (typosquatting) 都有一个心智模型：攻击者注册 requets 并等待有人误输入 requests。这行得通，但它是对人类粗心大意的一种随机押注。Slopsquatting 则更糟糕，因为这种“拼写错误”并非随机。语言模型会以可预测、可重复的模式虚构出看似合理但并不存在的包名——攻击者可以查询你使用的相同模型，收集它们虚构的名字，并准确地在 PyPI 和 npm 上注册这些包。幻觉变成了预购单。你的编码智能体 (coding agent) 在拥有自主安装权限的情况下运行，就是那个取走包裹的顾客。

这并非假设。关于这一现象的最大规模研究对 16 个模型生成了 223 万个代码样本，发现 19.7% 的推荐包并不存在——涉及 205,474 个独特的虚构名称。当一位安全研究员将其中一个最常被幻觉出的 Python 包注册为一个无害的空壳时，它在三个月内被下载了超过 30,000 次，并最终出现在一家大型科技公司开源仓库的安装说明中。由“氛围编程” (vibe coding) 带来的供应链攻击已经完成了它的概念验证。

当依赖项损坏时，你的构建会失败。当临时规避方案变得不再必要时，什么都不会发生。这种不对称性正是为什么每一个运行超过一年的生产级 LLM 系统都带有它不再需要的脚手架——重试编排、输出修复解析器、强制思维链、复杂的任务分解、分块启发式方法——每一个都是为了弥补特定模型的特定弱点而构建的，而且每一个都在无声无息中比它所补偿的弱点活得更久。

令人不安的是，这不仅仅是一个像过期的特性标志（feature flags）那样的卫生问题。过时的脚手架不仅仅是消耗你的延迟和 Token。在最坏的情况下，它会主动将新模型限制在旧模型的上限内：你的分解逻辑将一个任务切分为六个步骤，是因为 2024 年的模型无法处理整个任务，而 2026 年的模型本可以一次性完成，现在却继承了六个在你构建的缝隙中丢失上下文的机会。

调出你上次遇到持续 429 错误时的请求日志。你可能会发现一些奇怪的现象：错误并不是以稳定的流形式出现的。它们成波浪式出现——一波 429 爆发，接着是一段安静的间隔，然后是更大的爆发，再接着是另一个间隔。服务商的配额在波动期间并没有改变。你的流量也没有激增。你所看到的其实是你自己的重试逻辑在自我同步。每个在第 0 秒失败的客户端都计算了相同的退避（backoff）延迟，睡眠了相同的时长，并在同一瞬间醒来，然后再次共同失败。

这就是“惊群效应”（thundering herd），而最讽刺的是，标准的修复方案——指数退避（exponential backoff）——并不能阻止它。确定性的指数退避“组织”了惊群。它将一群几乎在同一时刻失败的客户端聚集起来，并让他们步调一致地前进：所有人都在 1 秒后重试，然后所有人都在 2 秒后，再然后是 4 秒。负载峰值的间隔变得更远了，但每个峰值的高度依然和第一个一样。如果正是这个峰值触发了你的速率限制，那么你实际上构建了一个永远重新触发它的节拍器。