567 篇博文 含有标签「llm」

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

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

模型路由是大多数团队首先采用的优化手段：将简单查询路由到小型廉价模型，复杂查询路由到大型强力模型。它在控制成本和吞吐量方面效果良好。但当云端推理的物理限制与 100ms 以内的延迟需求发生碰撞时，路由便无能为力了。从中间层数据中心发出的一次网络往返，在生成第一个 token 之前就已消耗 30–80ms。此时路由毫无意义——你要么需要将模型运行得更靠近用户，要么需要运行一个规模大幅缩减的模型。这两条路都需要压缩决策，而大多数团队对此并没有清晰的框架。

本文是一份做出这些决策的指南。量化、知识蒸馏和端侧部署这三种技术解决的问题有所重叠，但它们的成本结构、质量表现和运营影响各不相同。

当你在多个区域运行无状态 HTTP API 时，路由问题基本上已经解决了。在前面放一个全球负载均衡器，按地理位置分配请求，最糟糕的情况也不过是缓存项稍微过时。任何副本都可以处理任何请求，并获得相同的结果。

LLM 推理打破了每一个假设。一旦你添加了提示词缓存（Prompt Caching）——你肯定会加，因为缓存命中和未命中的成本差异大约是 10 倍——你的服务就会以大多数基础设施团队预料不到的方式变得有状态，直到他们在第二个区域看到延迟数据退化。

你的 SaaS 产品以十个设计客户的规模上线，一切运转完美。随后你陆续接入了一百个租户，其中一个——一位在复杂研究工作流中使用 20 万 token 上下文窗口的重度用户——导致了所有其他客户的延迟飙升。支持工单开始涌来。你查看监控面板，却看不到任何明显异常：模型健康，API 返回 200，p50 延迟看起来正常。而你的 p95 已经悄悄翻了三倍。

这就是嘈杂邻居问题，它对 LLM 基础设施的冲击比几乎任何其他共享系统都要剧烈。以下是它为何比数据库场景更难解决——以及真正有效的应对方案。

你的单次请求错误率看起来很正常。延迟在 SLO 范围内。LLM 裁判对输出的评分是 87%。接着，一位用户提交了支持工单：“我把账号告诉了机器人三次，它却一直重复问我。”另一位用户说：“它先是同意退款，两轮对话后又否认该政策的存在。”

单轮失败是显而易见的。请求进来，模型出现幻觉或拒绝回答，你的评估 (eval) 捕捉到了它，然后你修复提示词。反馈循环很紧密。多轮失败则完全不同：会话开始时表现良好，随后逐轮恶化，而你的监控从未报警，因为每个单独的回复在技术上都是连贯的。问题出在整个会话上——而几乎没有团队为此建立观测机制。

对主要前沿模型（Claude 3.7 Sonnet、GPT-4.1、Gemini 2.5 Pro）的研究显示，从单轮转向多轮对话时，平均性能会下降 39%。这个数字掩盖了真相：只有大约 16% 的下降是由于能力损失。另外 23 个百分点则是一场可靠性危机——随着对话长度增加，模型在同一任务上的最佳表现与最差表现之间的差距翻了一番。你得到的不仅是质量更差的输出，还有极不稳定的输出。

你的 p99 延迟刚刚飙升到了 12 秒。警报在凌晨 3:14 响起。你打开运维手册 (runbook)，看到如下指令：检查数据库连接池、验证负载均衡器、重启服务。你三样都做了。延迟依然居高不下。服务并没有宕机——它正在运行且有响应。但有些地方不对劲。事实证明，由于最近的一次提示词 (prompt) 变更无意中开启了“啰嗦”模式，模型生成的响应比平时长了三倍。运维手册里没有关于这一条的说明。

这是工程团队尚未准备好应对的新一类值班事故：系统正在运行，但模型表现异常。传统的 SRE 运维手册假设的是二进制的故障状态。AI 系统是以概率方式失效的，其症状看起来不像停机，而更像“漂移”(drift)。

大多数团队只有在亲身碰壁后，才会发现云端运行 AI 推理的棘手之处：追溯到个人健康信息（PHI）跨越 API 边界的 HIPAA 审计；在预发布环境中表现良好，直到处于不稳定连接环境下的用户反馈“一直在转圈”的延迟数据；或者是每天 10,000 次请求时看似合理，但在 1,000 万次请求时却变成灾难的单次推理 API 账单。设备端推理通常是正确的答案 —— 但团队选择它的原因以及他们遇到的问题，很少与博客文章对比中提到的相同。

这是一个关于该决策的实用指南：本地执行何时优于云端 API、哪些小模型真正具备交付能力，以及在基准测试演示结束后，部署生命周期是什么样的。

大多数构建 AI 功能的团队认为，一旦产品发布，用户反馈就会成为后续可以利用的资源。记录点赞和点踩信号，积累足够的量，最终进行微调。现实情况更为棘手：一年的反应记录并不等同于一年的对齐质量训练数据。这两者之间的差距，正是对齐技术——RLHF、DPO、RLAIF——要么拯救你，要么令你措手不及的地方。

这篇文章不是对对齐研究的综述。它是一份面向工程师的决策指南，旨在帮助你从数据收集的角度理解这些技术的需求，从而确保你今天部署的埋点确实能够支持你计划在六个月后进行的微调。

你的团队花了三个迭代周期标注了5万条领域样本。你在前沿模型上运行了LoRA微调。评估指标提升了。然后一位同事稍微改变了提示词的措辞，模型又回到了你以为已经抑制的行为。这不是数据集问题——这就是预训练的阴影。

实践者不断重新发现的核心洞察是：微调教会模型如何在新语境中说话，但无法改写模型根本知识或倾向。在预训练期间编码的行为、偏见和事实先验是一个引力场——微调只能在其周围轨道运行，很难真正逃脱。

Cursor 在 2025 年实现了 10 亿美元营收，却亏损了 1.5 亿美元。客户支付的每一分钱都直接流向了 LLM API 供应商，工程、支持和基础设施开销无从覆盖。这不是一个规模化问题——而是一个单位经济学问题，在酿成危机之前始终隐而不见。

大多数构建 AI 功能的工程团队都在犯同一个错误：把推理成本当作一个无关紧要的小项，上线固定费率订阅，然后假设经济账迟早会算对。但它永远不会自己算对。可变推理成本的行为方式与软件中任何其他 COGS 都截然不同——一旦你最重度的用户发现了你最昂贵的功能，那些适用于传统 SaaS 的定价架构就会让你流血不止。

Prompt 缓存听起来是一个稳赢的方案：Anthropic 和 OpenAI 都宣传缓存命中可享受 90% 的折扣，且文档中展示了令人印象深刻的成本削减图表。团队实施了它，观察着缓存命中率计数器不断上升，并理所当然地认为自己在省钱。但实际上，有些团队支付的费用比完全不使用缓存时还要 多。

问题在于“写入溢价”（write premium）。每当你缓存一个前缀时，你都需要支付额外的费用——在 5 分钟的缓存窗口内是 1.25 倍，在 1 小时的窗口内是 2 倍。如果你的命中率太低，这些写入溢价的累积速度会超过读取折扣所节省的费用。缓存并不是免费的保险；它是你对自己流量模式下的一场赌注。

2025 年 4 月，全球使用最广泛的 AI 产品之一更新了系统提示词。错误率保持平稳。延迟表现正常。部署仪表盘显示一切正常。然而在三天内，数百万用户发现了一些严重的问题：模型变得异常谄媚，附和错误的想法，验证糟糕的推理，并对用户说的任何话都表现出虚假的热情。回滚公告发布时，该事件已经席卷社交媒体，用户纷纷晒出截图作为证据。在一段时间内，Twitter 成了生产告警系统。

当你把提示词和模型的变更当作配置更新，而不是行为部署时，就会发生这种情况。那些在代码金丝雀基础设施上投入多年的团队，却仍在以单一原子级切换的方式发布 AI 变更——瞬间全球化、瞬间不可逆，没有分级发布，除了用户投诉外也没有自动回滚信号。

LLM 行为的金丝雀部署并非可有可无。它是缺失的基础设施层，区分了那些能在内部捕捉退化的团队，和那些只能通过支持工单发现问题的团队。