567 篇博文 含有标签「llm」

你将昂贵的 LLM 换成了更快、更便宜的蒸馏模型。延迟增加了，成本上升了，质量下降了。你感到困惑并回滚了版本，因为你刚刚花了三周时间做的优化工作反而让一切变得更糟。

这并非假设。这是生产环境 AI 系统中最常见的失败模式之一，它源于一个诱人但错误的心理模型：优化某个组件就能优化整个系统。

你正在运行一个由 LLM 驱动的应用，你的 p99 延迟为 4 秒。你已经优化了提示词，减少了输出长度，并切换到了流式传输。但这个数字几乎没变。问题不在于你的代码——而是在你无法控制的黑盒内部运作的物理学和排队论。

每个推理服务商在你的第一次 API 调用之前，就已经通过数十项架构决策决定了你应用的性能上限。KV 缓存淘汰策略、连续批处理（continuous batching）调度、分块预填充（chunked prefill）块大小——文档中没有提到这些，你也无法配置，但它们决定了你不得不面对的延迟和成本曲线。

这篇文章将解释推理基础设施内部究竟发生了什么，为什么它会产生不可避免的延迟底线，以及你真正能做的少数几件事。

周一你的提示词还运行正常。周三，用户开始抱怨响应感觉不对劲——答案变短了，下游的 JSON 解析时不时崩溃，原本准确率 94% 的分类器现在徘徊在 79% 左右。你没有部署任何新代码，配置文件里调用的模型名称还是那个。但某些东西变了。

这就是隐形模型漂移：LLM 供应商在不作任何公告的情况下推送静默的、未记录的行为变更。这是 AI 工程中讨论最少的运营风险之一，它会打击那些"做了所有正确事情"的团队——有评估集、有监控、有稳定的提示词工程。模型就在他们脚下悄悄地变了。

一个拥有 7.7 亿参数的模型在它擅长的任务上击败了一个拥有 5400 亿参数的模型，这听起来似乎是不可能的。但这正是经过蒸馏的 T5 模型在对抗 few-shot PaLM 时所取得的成就——仅使用了 80% 的训练样本，模型尺寸缩小了 700 倍，且每次推理成本仅为几分之一美分，而不再是数美元。这其中的秘诀并非更好的架构或更巧妙的训练方案。而是利用大模型生成标注数据，并用这些数据来训练小模型。

这就是知识蒸馏（Knowledge Distillation）。而且，你并不需要通过微调教师模型来使其生效。

在一个运行时间足够长的 AI 项目中，几乎都会出现一种模式。团队构建了一个原型，演示效果看起来不错，但在生产环境中，输出结果不够一致。有人建议切换到最新的前沿模型——用 GPT-4o 代替 GPT-3.5，用 Claude Opus 代替 Sonnet，用 Gemini Ultra 代替 Pro。有时这会有所帮助，但最终这种方法会不再奏效。团队发现，他们为每次推理支付了 5-10 倍的费用，延迟增加了一倍，而任务准确率仍然停留在 78%，而不是他们需要的 90%。

这就是潜在能力上限（latent capability ceiling）：即你所使用的语言模型的原始规模不再是限制因素的临界点。这是一个有经验数据支持的真实现象，大多数团队在遇到它时却浑然不觉——因为“使用更大的模型”这一反射动作成本低、速度快，并且在项目早期往往非常有效。

每个事件流系统最终都会将同一条消息投递两次。网络抖动、Broker 重启、偏移量提交失败——至少一次投递不是 Bug，而是契约。传统消费者能够优雅地处理这种情况，因为它们是确定性的：处理同一事件两次，得到相同的结果，写入相同的记录。第二次写入是一个空操作（no-op）。

LLM 不是确定性处理器。相同的提示词加上相同的输入，每次运行都会产生不同的输出。即使设置了 temperature=0，浮点运算、批次组合效应以及硬件调度的差异也会引入方差。针对"确定性" LLM 设置的研究发现，在自然发生的多次运行中，准确率差异高达 15%，最优与最差性能之间的差距甚至达到 70%。至少一次投递加上非确定性处理器，并不会给你带来至多一次的行为，只会带来不可预测的行为——这是一场蓄势待发的生产环境危机。

关于生产环境中的 LLM，大多数讨论都围绕着聊天界面、Copilot 和自主代理。但如果你审计企业 LLM Token 的实际消耗去向，你会发现一个完全不同的景象：绝大多数的使用都发生在批处理数据管道（batch data pipelines）中 —— 从文档中提取字段、对支持工单进行分类、规范化混乱的供应商记录、为原始事件添加语义标签。没有人为这个层级编写会议演讲，也没有人认真地对其进行基准测试。而这种沉默正让团队付出真金白银和准确性的代价。

这是从业者最先构建、最后辩护、且监控最少的 ETL 层级。对于大多数组织来说，这也是 LLM 支出杠杆率最高的一层，同时也是产生隐形失败潜力最高的一层。

一个团队在 GPT-4 上构建了一个生产环境功能。几个月后，出于成本考虑，他们决定评估 Claude。他们花了两周时间进行“迁移”——但核心的 API 替换只花了一个下午。剩下的十天都花在了修复损坏的系统提示词（system prompts）、重新测试拒绝服务的边缘情况、调试由于意外文本而崩溃的 JSON 解析器，以及重新调整在不同供应商之间表现迥异的工具调用模式（tool-calling schemas）。原本以为只是简单的连接器更换，结果迁移预算膨胀成了多层重构。

这就是现实中的 LLM 供应商锁定问题。那些受挫的团队并不是因为选错了供应商——而是因为他们没有意识到锁定存在于多个维度，且每个维度都有不同的风险画像。

当一个用户的 80 轮支持对话突然开始与其 60 轮前的建议相矛盾时，团队最初将其归咎于 Bug。其实并没有 Bug，只是模型“迷失”了。在所有主流的前沿模型中，多轮对话在相同任务上的表现平均比单轮交互下降了 39%。大多数团队从未衡量过这一点。他们假设上下文窗口的效力大致等同于其 Token 限制所暗示的程度，并据此构建产品。

这种假设在无声无息中出现了错误。长会话不仅仅是变得更慢或更昂贵 —— 它们变得不可靠，而这种不可靠性在用户感到沮丧之前几乎无法被察觉。

在AI工作中遇到困难的工程师，最常见的问题不是缺乏技术知识，而是他们一直在问错误的问题。他们想知道的是："这能用吗？"但他们真正应该问的是："这个系统的失败率是多少，这个失败率对于这个使用场景来说是否可以接受？"

这一转变——从二元正确性转向可接受的失败率——是有经验的AI工程师思考问题的核心差异。听起来简单，其实不然。由此延伸的一切都是不同的：你如何调试、如何测试、如何部署、监控什么、以什么为信心基础。没有完成这一转变的工程师会一直在与工具对抗并且不断失败。

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

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

大多数构建AI智能体的团队在投产三个月后都会发现同一个问题：他们精心设计的评估套件——围绕文本输入和JSON输出构建——当智能体遇到模糊的发票、扫描合同或从未见过的UI截图时，毫无参考价值。纯文本评估通过了，但用户提交了工单。

多模态输入不仅仅是另一种需要接入的模态，它们引入了一类截然不同的故障，需要不同的架构决策、不同的成本模型和不同的评估策略。将视觉能力视为对现有文本智能体的即插即用扩展的团队，无一例外地低估了所需的工作量。