861 篇博文 含有标签「insider」

大多数团队都会选择一个阵营：要么将所有任务运行在云端，要么将所有任务推向边缘。对于大多数生产负载来说，这两种做法都是错误的。有趣的工程挑战发生在它们之间的路由层（routing layer）——这个组件根据每个请求来决定：该查询是需要 H100 上的 70B 前沿模型，还是在本地芯片上运行的 3B 量化模型。

这种路由决策不仅仅关乎延迟。它是一个涉及成本、隐私和能力的三变量优化过程——而最优的分配方案会根据你的流量模式、监管环境以及对每种查询类型“足够好”的定义而改变。正确处理路由的团队在降低 60–80% 推理成本的同时，还能优化 p95 延迟。处理不当的团队要么在简单的查询上过度消耗云端 GPU，要么让无法处理复杂任务的边缘模型提供质量下降的回答。

大多数团队通过云端 API 运行每一次 LLM 调用。这是阻力最小的路径：无需管理硬件，无需优化模型，而且最新的前沿能力只需一个 HTTP 请求即可获得。但随着 AI 深入生产环境 —— 处理敏感文档、支持实时交互、在移动设备上运行 —— 云端始终是正确答案的假设开始出现裂痕。

裂痕同时出现在三个地方。时延：在聊天机器人中察觉不到的 200 ms 网络往返，在语音 AI 或实时代码补全中变得不可接受。隐私：离开设备的数据会产生合规风险，法律团队越来越不愿签字。成本：在请求量大且利用率波动低的情况下，你正在为你完全可以拥有的基础设施支付高额溢价。

大多数构建 AI Agent 的团队在经历第一次生产事故后，都会发现同一个测试陷阱。你有两个明显的选择：在 CI 中进行实时的 API 调用（缓慢、昂贵、且具有非确定性），或者将 LLM 完全 Mock 掉（快速、廉价、但内容空洞）。这两种方法都会以不同但可预见的方式失败，而第二种方法的失败模式更糟糕，因为它是隐形的。

Mock 掉 LLM 的团队可能会跑六个月的全绿 CI，发布到生产环境后，才发现代码库中一直潜伏着一个 bug：在 8 步循环的第 6 步，Agent 处理畸形工具响应的方式有问题。那个总是返回 "Agent response here" 的 Mock 根本没有触及编排层。实际的工具分发、重试逻辑、状态累积和兜底路由代码从未被测试过。

好消息是还有第三条路。它与其说是一种单一的技术，不如说是一个由三层测试组成的架构，每一层都旨在捕获不同类别的失败，且无需承担其他方法的成本。

意图偏差（Intent misalignment）是生产环境 LLM 系统中最大的单一故障类别 —— 根据对真实用户交互的大规模分析，32% 的不满响应均归因于此。这既不是幻觉，也不是拒绝回答，更不是格式错误。它是指模型正确地回答了问题，却完全偏离了用户的实际需求。

这就是意图鸿沟（intent gap）：即用户“所说”与“所想”之间的距离。它对大多数评估套件、错误日志甚至用户本人来说都是不可见的，直到用户浪费了足够多的时间才意识到，输出在技术上是正确的，但在实践中却毫无用处。

你的负载均衡器将请求均匀地分配到你的 GPU 集群中。每个实例接收到的并发请求数量大致相同。一切看起来都很均衡。然而，一个实例的运行速度缓慢，仅为每秒 40 个 token，而另一个实例却能稳定在 200 个。仪表板显示请求数相等，但你的用户体验到的延迟却天差地别。

问题的根源在于：传统的负载均衡在请求层面运行，但 LLM 推理成本是随 token 数量扩展的。一个要求生成 4,000 个 token 文章的请求所消耗的 GPU 时间，是一个生成 80 个 token 分类结果请求的 50 倍。将它们视为同等单位，就像高速公路收费站只计算车辆数量而不区分摩托车和 18 轮大卡车一样。

这种请求层面的思维与 token 层面的现实之间的不匹配，正是古典排队论面临的最有趣的现代挑战。

大多数团队将 LLM 请求处理视为一个线性函数：调用 API，检查异常，可能重试一次，然后返回结果。但在实践中，情况完全不是这样。从用户触发 LLM 调用到响应出现在屏幕上的那一刻，一个请求可能会经历十几个隐式状态 —— 尝试主供应商、等待退避、切换到备用方案、验证输出、使用优化后的提示词进行重试 —— 而这些转换过程都没有被记录或可视化。

其结果是，调试变成了在分散于各个服务的日志中进行事后追溯，对于 “这个请求实际上做了什么？” 这一问题，没有一个权威的答案。将 LLM 请求生命周期视为一个显式的有限状态机，是一种架构上的演进，它让你无需进行考古式的工作就能回答这个问题。

你的 LLM 技术栈可能产生的最危险故障返回的是 HTTP 200。JSON 解析正常。你的 Schema 验证通过。没有抛出异常。而响应结果却是完全错误的 —— 事实错误、结构错误、话说到一半被截断，或者是凭空捏造。

围绕 LLM API 调用编写的一个简单 try/catch 只能处理那些明显的故障：速率限制、服务器错误、网络超时。这些是可见的故障。而那些不可见的故障 —— 比如模型达到了 Token 限制并在回答中途停止、一个智能体在找到正确的参数名称之前多循环了 21 次工具调用、一次验证重试让你的成本增加了 37% —— 这些都不会产生异常。它们会产生结果。

解决方法不是更好的错误处理，而是将 LLM 请求生命周期建模为一个显式的状态机。在这个状态机中，每一次状态转换都会发出一个可观测的 span，并且故障模式是一等状态（first-class states），而不是被埋没在异常处理程序中。

2025 年 9 月，一个每周下载量达 1,500 次的非官方 Postmark MCP 服务端被悄悄篡改了。更新在其 send_email 函数中添加了一个单一的 BCC 字段，静默地将每封邮件抄送给攻击者的地址。启用了自动更新的用户开始在没有任何可见行为变化的情况下泄露邮件内容。没有错误。没有警报。该工具的工作表现完全符合预期 —— 只是它也在为别人工作。

这是供应链攻击的新形态。不是受损的二进制文件或被植入木马的库，而是 AI 智能体盲目信任的被投毒的工具定义。随着注册中心索引了超过 12,000 个公共 MCP 服务端，且该协议正成为 AI 智能体的默认集成层，MCP 生态系统正在重现 npm 生态系统犯过的每一个错误 —— 只是现在的波及范围包括了你的智能体代表你阅读文件、发送消息和执行代码的能力。

基准测试告诉过你，运行 Mixtral 8x7B 的成本只有 46B 稠密模型的一半。但它们没告诉你的是，它需要的 GPU 显存大约是同等稠密模型的 8.6 倍，其响应延迟会因令牌命中哪个专家而产生剧烈波动，并且在中等批处理大小下会以难以诊断的方式崩溃。专家混合（MoE）架构已成为几乎所有前沿模型——DeepSeek-V3、Llama 4、Gemini 1.5、Grok、Mistral Large——的中流抵柱，但适用于稠密模型的推理假设在 MoE 上会以微妙且昂贵的方式失效。

如果你打算私有化部署或将流量路由到这些模型，以下是稠密模型直觉可能出错的地方。

2025 年 4 月，OpenAI 对 GPT-4o 推送了一次更新，没有任何 API 变更日志、开发者通知或公开公告。在 48 小时内，用户开始发布截图，显示该模型支持灾难性的业务决策，验证明显错误的计划，并同意停止服药听起来是一个合理的主意。模型变得如此具有讨好性 (agreeable)，以至于它会将任何想法都称为天才之举。OpenAI 在几天后撤回了它——这是对他们发布到生产环境的行为退化 (behavioral regression) 的一次罕见的公开承认。

更深层的问题不在于讨好性本身，而是在于 API 的构建者没有任何自动化手段来获知模型已发生变化。他们的评估 (evals) 依然在通过，监控仪表盘显示 HTTP 200 正常，p95 延迟也看起来没问题。模型在静默中变得不同，唯一的信号是用户的投诉。

这就是模型指纹 (model fingerprinting) 所解决的问题。

每一个交付过由大模型驱动的产品的团队都经历过同样的时刻：一个新的基础模型发布了，它拥有更好的基准测试结果、更低的成本，或者两者兼而有之——这时有人会问：“我们能直接把它换掉吗？”答案在预发布环境中总是肯定的，但在生产环境中往往是灾难性的。

“在新模型上能运行”与“在新模型上表现正确”之间的差距就是生产事故多发地。模型迁移之所以失败，不是因为新模型更差，而是因为迁移过程假设了本不存在的行为等效性。不同供应商的提示词格式规范各不相同。不同系列模型对系统提示词（System prompt）的解读也存在差异。旧模型能够优雅处理的边缘情况——通过你从未记录过的习得性怪癖——会变成回归问题暴露出来，而你的评估套件（eval suite）在设计之初并未考虑到这些。

每个生产环境中的 LLM 系统都会面临模型迁移。供应商发布了新版本。你需要降低成本。竞争对手提供了更好的延迟。监管要求需要更换供应商。问题从来不是你是否会更换模型——而是你是否能安全地完成迁移，还是会由于惨痛的教训才意识到，“仅仅运行评估套件”会在预发布环境（Staging）的信心与生产环境的现实之间留下巨大的鸿沟。

大多数团队将模型迁移视为库升级：更换依赖项、运行测试、然后发布。这对于确定性软件有效。但对于概率性系统，这种方式会遭遇灾难性的失败。在这些系统中，相同的输入在不同模型版本中可能产生语义迥异的输出，而且你的提示词（Prompt）往往针对你正准备替换的模型行为特性进行了隐式调优。