这就是 2026 年选型最常见的错误:把"哪个模型最强"当成了"我该用哪个模型"。

这两个问题根本不是一回事。GPQA、SWE-bench、ARC-AGI-2 这些榜单告诉你的是天花板,而你大部分的线上请求,离天花板远着呢。一个分类、一段摘要、一次格式化抽取——这些活儿,旗舰模型是高射炮打蚊子。选型不是选最强,是给每一类任务配一个"刚好够用、且最便宜"的模型。

这篇不排名。给你一套按场景拆的决策框架。

先认清:2026 年的模型是分梯队的

2026 年 5 月,前沿模型大概是这么个格局——记住具体版本号意义不大,它们每两三个月就跳一次,记住梯队就行:

这张表里藏着一个关键事实:旗舰和"快而省"之间,输出价格差了几十倍。 DeepSeek V4-Flash 的输出大约 $0.28,GPT-5.5 是 $30——一百多倍。这个差距不是边角料,它会直接决定你的产品能不能规模化。

而梯队之间的能力差距,这两年反而在缩小。2024 年你能明显感觉到旗舰和主力不是一个物种;2026 年,在很多具体任务上,主力模型只比旗舰差几个百分点,有时候你压根测不出来。能力在收敛,价格还拉得很开——这就是"按梯队选型"能省钱的根本原因。

所以第一条原则:默认从主力梯队起步,只在它确实顶不住时才往上抬。 不要反过来,从旗舰往下砍——那样你永远不知道下面那一档是不是早就够了。

维度一:能力够不够,要按"任务类型"问

“够用"不是一个模糊的感觉,它可以拆。把你的任务大致归到三类:

确定性任务——分类、实体抽取、格式转换、敏感词过滤。这类任务有标准答案,对错可量化。结论很直接:用快而省梯队,甚至小开源模型。 旗舰在这里没有任何优势,它多出来的"智商"在一个三选一的分类题上无处发挥。我前面说的那个翻车案例,就是这一类。

生成与改写任务——写文案、做摘要、客服话术、翻译。这类没有唯一答案,但对"质量"敏感。主力梯队是甜区。值得一提:Claude 系列在中长文写作上的语感明显更自然,一次能稳定输出十几万 token 不塌;如果你的产品核心就是"写得像人”,这个差异值得你多花那点钱。

推理与 Agent 任务——多步代码、需要调工具、长链路规划、“自己想办法完成”。这是 2026 年唯一真的需要旗舰的地方。一个 Agent 要连续做二三十步,每一步的小错误会累积,中间某一步判断失误,后面全废。这种场景下,旗舰多出来的几个点,放大到整条链路就是"能跑通"和"跑不通"的区别。GPT-5.5、Claude Opus 4.7 这一档,贵有贵的道理——但前提是,你的任务真的是 Agent,而不是被包装成 Agent 的一次性问答。

一个实操建议:别用一个模型扛所有任务。 成熟的做法是按任务路由——一个便宜模型做分流和简单活儿,难的才转交旗舰。这比"全程旗舰"省一大笔,也比"全程便宜"靠谱。

维度二:成本不是单价,是「单价 × 调用量 × 输出长度」

很多人看 API 价格,只瞄一眼那个"每百万 token 多少钱"。这是不够的。真正的账是三个数相乘:

• 单价——尤其是输出单价,通常是输入的 3 到 5 倍,而且 Agent 类任务输出占比高。
• 调用量——一天一千次还是一千万次,差四个数量级。
• 平均输出长度——让模型"先想再答"(reasoning)能提质量,但思考链本身也是要付费的 token。

把这三个乘起来,你常会得到一个反直觉的结论。举个例子:一个日活几万的客服机器人,绝大多数对话是"查物流"“改地址"这种,真正复杂的咨询可能只占 5%。如果你全程用旗舰,等于为了那 5% 的复杂场景,给 95% 的简单场景也付了旗舰价。把 95% 切到主力或快省梯队,月成本可能直接砍掉七八成,用户一点感知都没有。

两个几乎免费、却经常被忘掉的省钱手段,务必用上:

• Prompt Caching(提示缓存)——固定不变的前缀(system prompt、长文档、few-shot 例子)缓存住,命中后这部分输入便宜约 90%。多轮对话、RAG、批量同模板任务,收益巨大。
• Batch(批处理)——不要求实时返回的任务,走批处理接口,普遍五折。离线打标、夜间报表、内容审核这类活儿,没理由不用。

记住:选型省下的钱,常常比换一个"更便宜的模型"省得还多。 因为它省的是结构性的浪费。

维度三:延迟、上下文——被场景一票否决的硬约束

有些维度不参与"性价比"的权衡,它们是门槛:不过线,这个模型直接出局,多强多便宜都没用。

延迟。 如果你做的是实时语音对话,用户说完到 AI 出声的预算只有几百毫秒(这个我在上一篇里专门拆过)。这种场景,你要盯的是首 token 延迟(TTFT),不是模型聪不聪明。一个慢半拍的旗舰,体验上输给一个快的主力模型。反过来,如果是离线批处理,延迟根本不在你的考虑范围里——这时候为"快"付的溢价就是纯浪费。

上下文长度。 2026 年长上下文已经不稀缺:Gemini 3.1 Pro 和 DeepSeek V4 都是 1M token 窗口,Llama 4 甚至把 10M 带进了开源世界。但有窗口不等于会用。把 50 万 token 一股脑塞进去,模型对中间段落的注意力会明显下降——业内说的 “lost in the middle” 没有消失。所以长上下文是个二元的资格题:你的单次任务真需要塞进一整本书、一个大代码库,那 1M 窗口是硬指标;如果你的输入本来就几千 token,纠结谁的窗口更大毫无意义,该花力气的是 RAG 的检索质量,而不是模型的窗口数字。

判断方法很简单:先问"这个场景能不能容忍 X”,不能就直接划掉一批模型,再在活下来的里面比性价比。 别把硬约束和软偏好混在一起算。

维度四:闭源还是开源,2026 年这道题变简单了

两年前这是个艰难抉择,因为开源模型确实差一截。2026 年不一样了。

DeepSeek V4-Pro 在 SWE-bench Verified 上能摸到 80% 出头,和顶级闭源模型只差零点几个点,而且是 MIT 许可证。Qwen 3.5 / 3.6、Llama 4 也都在各自的领域逼近前沿。开源和闭源的能力差距,现在是用单个 benchmark 上的几个点来衡量,不再是"差一代"。 同时,主流开源模型现在发布即附带官方量化版本(Q4/Q5/Q8),部署门槛大幅下降。

所以这道题的判据,从"谁更强"变成了别的:

• 选闭源 API:你要的是省心。不碰 GPU、不管扩缩容、要最新最强、出了事有人兜底。绝大多数从 0 到 1 的产品,该走这条路——你的精力应该花在产品上,不是运维推理集群。
• 选开源:你有三个理由之一——量足够大(自己跑的边际成本能把闭源 API 打下去)、需要深度微调(让模型长出领域知识)、或者数据不能出门(下一节细说)。

还有个容易被忽视的点:开源是一份保险。 用闭源 API,你绑定了对方的定价、限流和模型下线节奏——它说某个版本退役,你就得连夜迁移。把一部分负载放在能自己掌控的开源模型上,是对供应商风险的对冲。

维度五:要不要私有化部署——这题先于选模型

如果你的数据是病历、银行流水、未公开的财报、核心代码——这一条会推翻上面所有结论。 它不是一个性价比维度,它是法律和信任的红线。

判断私有化部署需求,问三个问题:

1. 数据能不能离开你的网络? 受监管的医疗、金融、政务,答案常常是"不能"。
2. 合规要求审计闭环吗? 欧盟 AI 法案 2026 年 8 月全面生效,高风险系统要求可追溯、可解释、有人类监督。这些在一个黑盒 API 后面很难自证。
3. 数据主权有没有硬约束? 某些行业、某些地区,要求推理全程在境内、在自有设施内完成。

只要有一个答案指向"必须自己掌控",那就只能选能私有化的开源模型——Qwen、Llama、DeepSeek 这一类,把权重下载下来,跑在自己的 VPC 或机房里。这时候"GPT-5.5 更强"是一句正确的废话,因为它根本不在你的候选集里。

要提醒的是,私有化不是"省钱"的同义词。算上 GPU 采购或租赁、运维、扩缩容、安全加固,很多时候它比 API 更贵。 选它的理由是控制权和合规,不是成本。如果你既没有合规硬约束、量也撑不起一个推理集群,却因为"感觉更安全"去自建,那大概率是给自己挖坑。

把这套框架连起来

选型不是从一张排行榜里挑第一名,而是带着你的场景,依次过几道闸门:

flowchart TD
  A[一个具体任务] --> B{数据能否出本网络?}
  B -- 不能/强合规 --> P[私有化部署
开源模型: Qwen / Llama / DeepSeek]
  B -- 可以 --> C{任务类型?}
  C -- 确定性
分类·抽取·路由 --> D[快而省梯队
Haiku / Flash-Lite / 小开源模型]
  C -- 生成改写
文案·摘要·翻译 --> E[主力梯队
Sonnet / Flash / DeepSeek V4-Pro]
  C -- 推理 Agent
多步·调工具·规划 --> F[旗舰梯队
GPT-5.5 / Opus 4.7 / Gemini 3.1 Pro]
  D --> G{有延迟或上下文硬约束?}
  E --> G
  F --> G
  G -- 有 --> H[在满足约束的模型里
重新筛一遍]
  G -- 没有 --> I[按规模决定
闭源 API or 自建开源]

注意几个细节。第一道闸是数据合规,不是能力——合规一票否决,放在最前面,免得你比了半天性价比最后发现这个模型根本不能用。任务类型决定的是梯队,不是具体型号——型号每季度都变,梯队的逻辑稳定得多。延迟和上下文是筛选器,不是打分项——它们只负责把不合格的划掉。最后才轮到闭源还是开源,而这一步主要由调用量决定:量小走 API,量大到自建更划算时,再考虑迁。

最后

2026 年大模型这块,缺的从来不是好模型,缺的是"清楚自己要什么"。

榜单天天有人更新,排名天天有人吵,但你的客服机器人需要的可能只是一个稳定、便宜、够快的主力模型;你的代码 Agent 才真的吃旗舰那几个点的智商;你的合规系统压根不在公开榜单的讨论范围里。

把"哪个最强"这个问题放下。换成一串具体的问题:这个任务是什么类型?能容忍多少延迟?一天调用多少次?数据能不能出门?——这几个问题答完,该选哪个,基本也就清楚了。

选型的功夫,九成在想清楚需求,一成在看模型。顺序别搞反。

这是 2026 年做过几轮项目后,业内基本形成的共识。但凡你想让一个通用大模型「答对你自己的事」——公司的产品文档、内部规章、某个客户的历史订单——你大概率会在三条路里纠结:RAG(检索增强)、微调、长上下文(直接把材料塞进 prompt)。

这三条路经常被拿来对比,但很多对比都在装中立,列个表说「各有优劣,看场景」。这篇不装。它们不是平级的选项,它们解决的根本不是同一个问题。选错那条,代价不是「效果差一点」,而是要么每个月烧掉本不该烧的钱,要么半年后你的数据全过期、整个系统没人敢碰。

它们到底各自在解决什么

把这件事想清楚,后面就不纠结了。

• RAG:模型不知道答案,你临时把答案找出来递给它。模型本身不变,变的是每次喂给它的上下文。
• 微调:你改的是模型本身的权重。让它换一种说话方式、固定输出某种格式、养成某种行为习惯。
• 长上下文:你不做检索、不做训练,直接把所有相关材料一次性塞进 prompt,让模型自己在里面找。

注意区别:RAG 和长上下文都是在「给模型补知识」,区别只是补的方式——一个精挑细选地补,一个一股脑全塞。而微调压根不是在补知识,它在补能力和行为。这是最常见的认知错位:有人想让模型「记住公司有 300 条规章」,跑去微调,结果训完发现模型还是答不准,因为微调不是用来塞事实的。

一句话记牢:知识用 RAG,行为用微调,长上下文是知识量小到不值得搭管道时的偷懒办法。

RAG:知识会变、要溯源,就选它

RAG 是 2026 年绝大多数团队的默认起点,理由很硬:它便宜、上线快,而且能干那件最常见的事——让模型回答关于你自家数据的问题。

它的真正杀手锏是另外两个:

知识能随时更新。 产品改了价、规章出了新版,你只要更新向量库里那几条,模型下一秒就用新的了。不用重训、不用重新部署。对任何一个数据会变的业务,这一条几乎是决定性的。

答案能溯源。 模型说「退款政策是 7 天」,你能指着它后面挂的那条文档说「依据在这」。金融、医疗、法律这类场景,「答得对」还不够,你得能证明它为什么这么答。微调和长上下文都给不了这种可追溯性——微调把知识熬进了权重里,你根本说不清它从哪学的。

但 RAG 不是免费午餐,2026 年的现实是:当 RAG 出错,73% 的锅在检索,不在生成。 模型没胡说,是你压根没把对的文档捞给它。所以现代 RAG 早就不是「embedding + 余弦相似度」那么简单了,一条能上生产的管道长这样:

flowchart LR
  A[文档] --> B[语义切块]
  B --> C[向量库]
  D[用户提问] --> E[混合检索
向量 + BM25]
  C --> E
  E --> F[Rerank
取 Top 5-10]
  F --> G[LLM 生成]

几个关键点,踩过坑的都懂:

• 切块是默默崩掉 RAG 的地方。 切得太碎,一个 chunk 答不全一个问题;切得太大,塞进去全是噪音。语义切块(按 embedding 相似度找话题边界)比固定字数切块靠谱得多。
• 混合检索基本是标配了。 纯语义检索会漏掉「精确匹配」——比如某个型号编号、某个专有名词。把向量检索和 BM25(关键词)拼起来,准确率明显更稳。
• Rerank 是那勺秘制酱。 先用混合检索捞 100 条候选,再用一个 cross-encoder 重排序模型(Cohere Rerank、BGE-Reranker 这类)精筛出 5-10 条真正喂给大模型。这一步加上,系统会从「有时有用」变成「能上生产」。

代价是:你得维护一整套数据管道——切块、embedding、向量库、rerank,每一环都能出问题。RAG 上线快,但养着它不轻松。

微调:改的是行为,不是知识

如果你的痛点是这些,那才轮到微调:

• 模型语气不对——你要它像个严谨的客服,它偏要活泼。
• 输出格式不稳——你要它每次都吐严格的 JSON,它三次里有一次加段废话。
• 某种固定行为——特定领域的术语习惯、固定的处理流程、某类问题的标准应对。

这些 RAG 救不了。 你没法靠「检索」让模型改性格。微调改的是模型权重本身,它学的是「怎么说」「按什么格式说」「遇到这类输入该怎么反应」,不是「记住哪些事实」。

2026 年微调内部其实分三种,选哪种取决于你要改多深:

LoRA / QLoRA 是 2026 年的事实默认。 LoRA 只训练总参数量的 0.1%–1%,却能拿回全量微调 90%–95% 的效果。QLoRA 再加上 4-bit 量化,显存需求砍掉约 75%——一张 A100 80GB,大概 6 小时、十几美元,就能在 5 万条样本上微调完一个 8B 模型。这个成本低到,微调不再是大厂专属了。

全量微调 2026 年反而成了少数派选择。除非你的改动深到 LoRA 那层适配器装不下,而且你手里有海量高质量数据,否则没必要——花十倍的钱,换那 5%–10% 的边际效果,多数时候不划算。

DPO 已经基本取代了传统 RLHF 来做对齐。它更便宜、更稳定,效果相当。典型用法是「微调之后的精修」:先用 LoRA 把基本能力训出来,再用 DPO 拿成对偏好数据校一遍「这种答法好、那种不好」。

微调最反直觉的一条:数据质量碾压数据数量。1000 条手工精挑的样本,经常打得过 10 万条带噪声的。 学习率给个参考——普通 LoRA/QLoRA 从 2e-4 起步,DPO 这类强化学习类的要小得多,5e-6 左右。

微调真正的代价不在训练那几个小时,在之后:基座模型升级了,你的适配器要不要跟着重训?业务行为变了,数据要重新标、模型要重新跑。微调是一笔持续的维护承诺,不是训完就完事。

长上下文:知识量不大时,最省事的那条

2026 年的上下文窗口已经大得有点离谱了:

• Gemini 3 Pro 标准 1M–2M token,实验档摸到了 10M。
• GPT-5.2 支持到 400K。
• Claude Sonnet 4 给到 tier 4 的组织开了 1M beta(标准档 200K)。
• Llama 4 Scout 标称 10M。

窗口大到这份上,一个很自然的想法冒出来:还要 RAG 干嘛?把所有文档一股脑塞进去不就完了?

知识量真的小,这招确实成立。你只有一份 50 页的产品手册,与其搭一整套切块、向量库、rerank 的管道,不如直接把整份手册塞进 prompt。零维护、零基建,模型还能看到全局上下文,不会因为「检索只捞了相关那几段」而丢掉跨章节的关联。原型阶段,长上下文几乎永远是最快的验证方式。

但它有两个绕不过去的硬伤:

第一,标称窗口 ≠ 可用窗口。 这是最大的误区。一个模型标 200K,不代表它在 200K 上还好用。RULER 这类基准反复验证:模型的有效容量通常只有标称值的 60%–70%。还有那个老问题「迷失在中间」(lost in the middle)——材料放在 prompt 开头和结尾时模型找得最准,夹在中间 10%–50% 深度的内容,准确率明显塌方。2026 年各家表现也不一样:Claude Sonnet 4 在 200K 全程的衰减能压在 5% 以内,GPT-5.2 在 256K 内保持接近满分的检索,而 Gemini 3 Pro 一过 128K 在多目标检索上就掉得挺快。你塞进 1M token,别真指望它每个角落都看得清。

第二,贵。而且是规模化之后致命地贵。 你每问一个问题,那一大坨上下文就要重新算一遍 token 钱。在规模上,长上下文比 RAG 或微调贵 20–24 倍。更糟的是计费门槛:OpenAI 超过 272K token 之后单价翻倍,Gemini 超过 200K 翻倍。原型阶段长上下文很香,生产高并发场景它会把你账单点着。

所以长上下文的定位很清楚:知识量小、又不想搭基建,就用它;一旦知识量大起来、或者要扛量,老老实实回去做 RAG。

别再二选一了:2026 年是分层

把这三条路当成单选题,是最常见的错。

2026 年那些真正做出好产品的团队,没有谁在「选一个」。他们在分层叠加:RAG 负责事实,微调负责风格、策略和决策行为。 一个典型的成熟架构是——一个不算大的基座模型,挂一层薄薄的 LoRA 适配器把语气和格式调到位,再配一套 RAG 管道实时喂事实。微调和检索不是互相替代,是各管一段。

落地的推进顺序也有共识,别跳步:

Prompt → RAG → 微调 → 蒸馏

先把 prompt 写好,不行再上 RAG,RAG 解决了知识、但行为还不对再上微调,最后量大到一定程度、想把成本压到底,才考虑蒸馏成小模型。绝大多数团队走到第二步就够了,根本不需要碰微调。

成本上还有一条值得记:低并发场景 RAG 赢,因为没有前期训练投入;高并发场景(每天 10 万+ 次查询)微调过的小模型赢,因为单次推理便宜。 量,是决定天平往哪边倒的关键变量。

一张图替你决策

不想读上面那一大堆,看这张图就够了:

flowchart TD
  Start[你想让模型答对自己的事] --> Q1{需要补充的是
知识还是行为?}
  Q1 -->|行为/风格/格式| FT[微调
默认 LoRA/QLoRA
再用 DPO 精修]
  Q1 -->|知识| Q2{知识量大不大?
会不会变?}
  Q2 -->|量小 + 基本不变| LC[长上下文
直接塞进 prompt]
  Q2 -->|量大 / 会变 / 要溯源| RAG[RAG
混合检索 + Rerank]
  FT --> Hybrid[多数生产系统:
RAG 管事实 + 微调管行为]
  RAG --> Hybrid
  LC -.量涨上来.-> RAG

最后留一句话,这是这篇唯一想让你记住的:先问自己「我缺的是知识还是行为」。 想清楚这一个问题,三条路自己就排好队了。剩下的纠结,多半是因为这个问题没问清。

参考资料:

• LLM Context Window 2026 — TokenMix
• Context Length Comparison: Leading AI Models in 2026 — elvex
• Fine Tuning AI Models in 2026 — Kumar Gauraw
• LLM Fine-Tuning Best Practices 2026 — hjLabs
• RAG vs Fine-Tuning for LLMs (2026): What Actually Works in Production — DEV
• RAG vs Fine-tuning vs Long Context — Preksha Dewoolkar, Medium
• Building Production RAG: Architecture, Chunking, Evaluation & Monitoring (2026) — PremAI
• RULER: Benchmark for Long-Context Modeling

朴素 RAG 会怎么做?它把这一整句话拿去向量库里查一次,取回 5 个最相似的片段,塞进 prompt,让大模型生成。结果大概率是:它检索到了"今年的退款政策",但没检索到"去年 Q3 的",因为这句话作为一个整体,语义上离"今年的政策文档"更近。于是模型用今年的政策,回答了一个关于"变化"的问题——而且它不会告诉你它只看到了一半。

这就是朴素 RAG 的根本毛病。它把检索当成一个一次性的、无脑的前置步骤:查一次,查到什么算什么,然后生成。它不会判断"我查到的东西够不够",不会发现"这个问题其实要查两次",更不会在检索失败时重来。它失败的时候不会报错,会编。

2026 年,生产环境里真正能扛住复杂问题的,已经不是这条流水线了。这篇讲清楚它怎么一步步长成 Agentic RAG,以及——这是重点——多出来的延迟和成本,什么时候值,什么时候是浪费。

朴素 RAG 到底卡在哪

先把它失败的几类问题说具体,不然后面所有"改进"都是空的。

多跳问题。“写《三体》的作者还写过哪些小说?"——这要先查”《三体》的作者是谁"(刘慈欣),再用这个答案去查"刘慈欣的其他作品"。一次检索拿不到第二跳需要的关键词,因为第二跳的查询词(“刘慈欣”)根本不在原始问题里。

**模糊 / 措辞错位。**用户问"那个会自动重试的配置项叫什么",知识库里写的是"retry_policy 重试策略"。用户的口语和文档的术语对不上,向量相似度也救不回来。

问题里藏着多个子问题。“对比一下 A 方案和 B 方案的成本和上线周期”——这是四个检索意图揉在一句话里,一次检索只会取回一堆"半相关"的片段,哪个都不深。

需要计算或外部数据。“我们这个季度的获客成本环比涨了多少”——答案不在任何一个文档片段里,它需要先取两个数,再算个除法。文本检索给不了。

这些问题的共同点是:正确答案不是"检索一次就能拿到的那 5 个片段"。要么得检索多次,要么得换个查法,要么检索根本不是最后一步。朴素 RAG 的架构里没有"再来一次"这个动作,所以它只能在第一次的结果上硬生成。

演进的主线:从「流水线」到「控制循环」

把朴素 RAG 和 Agentic RAG 摆在一起看,差别不是"加了几个模块",是控制权交给了谁。

朴素 RAG 是一条固定流水线:检索 → 生成,顺序写死,模型只负责最后那步生成,没有决策权。

Agentic RAG 是一个控制循环:大模型坐在中间当指挥,它拿到问题后自己决定下一步干什么——要不要检索、检索什么、查到的东西够不够、要不要换个查询词再来一次、还是已经可以回答了。检索从"前置步骤"变成了模型手里的一个工具,跟计算器、SQL 查询、API 调用平级。

flowchart TB
  subgraph naive[朴素 RAG:固定流水线]
    direction LR
    Q1[问题] --> R1[检索一次] --> G1[生成] --> A1[答案]
  end
  subgraph agentic[Agentic RAG:控制循环]
    direction LR
    Q2[问题] --> AG{Agent
决策}
    AG -->|要查| R2[检索/改写/计算]
    R2 --> EV[评估结果
够不够?]
    EV -->|不够| AG
    EV -->|够了| G2[生成] --> A2[答案]
  end
  style AG fill:#fde7c2,stroke:#e8b23c
  style EV fill:#fde7c2,stroke:#e8b23c

橙色的两块——决策和评估——是朴素 RAG 里完全没有的。整个演进,本质上就是把这两个能力一点点加进来。下面拆成四个阶段讲。

第一步:查询改写,别拿用户的原话去检索

最便宜、收益最直接的一步,是不再把用户的原始问题直接丢给向量库。

用户的话是口语、是模糊的、是给人听的;文档是书面语、是术语。中间这道坎,用一个改写步骤填上。常见的几种做法:

• 同义改写(Rewrite-Retrieve-Read):先让一个小模型把"那个会自动重试的配置项"改写成检索友好的"重试策略 retry 配置 自动重试机制",再去查。RQ-RAG 这类方法甚至专门训了一个小模型来干这件事。
• 查询分解:把"对比 A 和 B 的成本和上线周期"拆成四个独立子查询,各查各的,最后合并。
• HyDE(假设性文档):先让模型"瞎编"一段它觉得答案应该长什么样的文字,再用这段编出来的文字去检索。听起来反直觉,但编出来的文字在语义空间里离真实文档更近——因为它和文档一样是书面语。

注意:到这一步,系统还不是 Agent。改写是固定加进流水线的一环,模型还是没有"要不要再查一次"的决策权。但它是个分水岭——从这里开始,检索的输入不再等于用户的输入了。

第二步:多轮检索,让多跳问题能跑通

查询改写解决"查得准",多轮检索解决"查得够"。

对多跳问题,做法是让流程循环起来:检索一轮 → 看看拿到的信息能不能支撑回答 → 不能就根据已知信息生成下一个查询 → 再检索。"《三体》作者还写过什么"就变成:第一轮查到"刘慈欣",第二轮用"刘慈欣"作为新查询词,查到《球状闪电》《流浪地球》。

这里的关键设计是谁来决定停。两种思路:

• 固定轮数:简单粗暴,查 3 轮就停。问题是简单问题被迫查 3 轮(浪费),复杂问题 3 轮可能还不够。
• 模型自己判断:每轮检索后让模型回答一个问题——“现在的信息够回答用户了吗?” 够了就停,不够就继续。这就开始有 Agent 的味道了:停止条件是动态的。

到这一步,系统已经能处理多跳问题。但它还有个隐患:它默认每个问题都要检索。“你好"“帮我把这段话翻译成英文"这种根本不需要查知识库的请求,它也老老实实查一遍——白花钱、白加延迟。

第三步:Adaptive RAG,让 Agent 决定「要不要查、查几次」

这一步把决策权真正交出去:检索不再是默认动作,而是 Agent 评估后才触发的选择。

Adaptive RAG 的典型做法是训一个轻量级路由器(router),它先给问题分个级:

它的价值在于按需付费:简单问题走快车道,省下来的延迟和成本,留给真正难的问题。SELF-RAG 是同一思路的另一种实现——它不靠外挂路由器,而是训练模型在生成过程中吐出特殊的"反思 token”,由模型自己在每一步决定"这里该不该插入一次检索”。

把检索当工具,意味着它旁边还能摆别的工具。“这季度获客成本环比涨多少"这种问题,Agent 会先调"检索工具"取两个季度的原始数字,再调"计算工具"做除法。检索从此只是 Agent 工具箱里的一格,不是全部。2026 年 2 月的 A-RAG 框架走得更彻底:把关键词检索、语义检索、按片段检索当成三个不同的工具直接暴露给 Agent,让它自己挑用哪个,QA 准确率比一刀切的扁平检索高了 5%–13%。

第四步:自我纠错,Self-RAG 与 Corrective RAG

前面三步解决"查得准、查得够、该不该查”。最后一步解决一个更难的问题:查回来的东西是错的、是噪音,怎么办。

朴素 RAG 在这里是裸奔的——检索到什么就用什么,哪怕取回的 5 个片段全是不相关的,它也照样塞进 prompt 生成。自我纠错就是在"检索完"和"生成"之间,硬插一个质检环节。

两条主流路线:

• Corrective RAG(CRAG):检索之后,用一个轻量评估器给每个片段打分——相关、不相关、还是模棱两可。如果片段质量够高,正常生成;如果一堆是噪音,就触发纠正动作,典型的是把查询词改写后重新检索,甚至 fallback 到联网搜索;模棱两可的就两边的信息都用上。评估器是外挂的,不依赖主模型。
• Self-RAG:把评估能力训进模型本身。模型生成时会同步产出"反思 token",自己评判"我刚引用的这段资料,真的支撑我这句话吗"。如果不支撑,它会自己回退、重检索。

两者的区别值得记住:CRAG 是"外挂一个质检员",改造成本低、能套在现有系统外面;Self-RAG 是"让模型自带质检能力",效果更深入但需要专门训练模型。生产里 CRAG 更常见,因为不用动模型。

不管哪条路,目的是同一个:让系统在给出答案之前,先对自己手里的证据有个判断。一个会说"我没查到足够信息"的 RAG,比一个永远自信乱编的 RAG,有用得多。

代价:这一切都不是免费的

把上面四步全堆上,你得到的不是"更好的 RAG",是"更慢更贵更难维护的 RAG"。这个账必须算清楚。

延迟。 朴素 RAG 是一次检索 + 一次生成。Agentic RAG 每多一轮"决策 → 检索 → 评估",就多一组大模型调用和向量查询。一个跑三轮的 Agentic 流程,延迟翻几倍很正常。有实测数据:在 FIQA 这类金融问答任务上,Agentic 方案的平均延迟是增强型 RAG 的约 1.5 倍;做同样一件事,一条 Agentic 流水线可能比朴素 RAG 多花 5 秒。

成本。 每一轮决策和评估都是真金白银的 token。一个朴素 RAG 查询大约 $0.001,功能相当的 Agentic 流程能到它的 10 倍。生产环境里实际的单次查询成本,从简单查找的 $0.02 到复杂多源推理的 $0.31 不等。

复杂度。 这是最容易被低估的一项。固定流水线的 bug 好查——就那么几步。一个会循环、会自己改查询、会自己决定停的 Agent,出错的时候你得问:是路由判错了?改写改歪了?评估器误判了?还是循环该停没停?调试和监控的难度,跟朴素 RAG 不是一个量级。还有个隐蔽的坑:有研究发现,RAG 的精度调参没调好,会悄悄把检索准确率拉低 40%,而这个误差在 Agentic 的多轮循环里会被一路放大。

那到底什么时候该上 Agentic RAG

我的判断很直接:Agentic RAG 不是朴素 RAG 的升级版,是另一个东西,按场景选,不是按"先进程度"选。

如果你的产品主要是文档查找、信息抽取、单轮问答——客服查个政策、员工查个手册——朴素 RAG 就是最优解。它简单、便宜、好调试,给它叠 Agent 是纯浪费,用户还得多等几秒。2026 年企业里的生产基线,其实是混合检索(向量 + 关键词)这种"增强型朴素 RAG",而不是 Agentic。

什么时候该上 Agentic:当你的问题里经常出现多跳、模糊、多子问题、需要计算这几类——比如做研究型助手、做需要跨多个数据源交叉验证的分析、做法律 / 医疗这种"答错代价很高、宁可多查几轮也要确认证据"的场景。这时候多出来的延迟和成本,买的是"答对"和"知道自己没查够",值。

更现实的做法是别一刀切。先用 Adaptive RAG 的路由思路:简单问题走朴素快车道,只有被判定为复杂的那部分,才进 Agentic 的循环。 让贵的能力只花在真正需要它的问题上——这跟做语音 Agent 时"先打通流式管道、再去抠贵的环节"是同一个工程哲学:别为不存在的复杂度付钱。

朴素 RAG 最大的问题从来不是"不够先进",是它失败的时候很安静。Agentic RAG 真正值钱的地方,也不是那些花哨的多轮循环,而是它终于学会了在证据不足时说一句:“这个我没查够。”

用户不需要点开邮件,不需要点链接,什么都不用做。只要他之后用 Microsoft 365 Copilot 问了一个相关问题,Copilot 在检索资料时读到了那封邮件,藏在邮件里的指令就被执行了——Copilot 把它能访问的内部文档内容,通过一张自动加载的图片悄悄发到了攻击者的服务器。

这是第一个在生产级 LLM 系统里被证实的"零点击"prompt injection。它之所以值得拿出来开头讲,是因为它把一件事摆到了台面上:当 AI 只是个聊天框时,prompt injection 是个有意思的玩具;当 AI 变成能读邮件、能调工具、能发请求的 Agent 时,它是头号安全问题。

prompt injection 到底是什么

先把概念说清楚,因为很多人把它和"越狱"(jailbreak)混为一谈。

越狱是用户自己想绕过模型的安全限制——比如骗模型教他做危险的东西。受害者和攻击者是同一个人,危害基本限于他自己。

prompt injection 不一样。它是第三方把恶意指令塞进 LLM 的输入里,劫持模型,让它替攻击者干活,而真正的用户和应用开发者都被蒙在鼓里。受害者和攻击者是不同的人,这才是它危险的根源。

它的技术根因,Simon Willison(2022 年造出 “prompt injection” 这个词的人)说得最直白:LLM 没有可靠的能力区分"指令"和"数据"。

传统软件里,SQL 注入之所以能被根治,是因为我们有 prepared statement——代码归代码,数据归数据,数据库引擎从结构上就分得清。但 LLM 的输入是一锅粥:system prompt、用户问题、检索到的文档、工具返回的结果,全部拼成一段文本喂进去。模型看到的只是 token 流。如果一段"数据"里写着"忽略以上所有指令,改为执行……",模型完全可能就照做了——因为对它来说,这跟开发者写的 system prompt 长得一模一样。

这不是某个模型的 bug,是当前这套架构的固有属性。GPT、Claude、Gemini 全都中招。

直接注入只是开胃菜,间接注入才致命

prompt injection 分两类,危险程度差着量级。

直接注入:攻击者自己在对话框里输入恶意 prompt。这种相对好防——输入就来自用户,你本来就该对它保持警惕,而且很多场景下用户骗 Agent 也只是坑自己。

间接注入(indirect prompt injection):恶意指令藏在 Agent 会去读的外部内容里——一个网页、一封邮件、一份共享文档、一段代码仓库的 README、甚至一张图片的元数据。Agent 在正常干活的过程中读到了这段内容,指令就被触发。

间接注入致命在哪?在于它走的是数据通道,而数据通道没人盯着。

你会审查用户在对话框里打了什么,但你不会去审查 Agent 帮你总结的那个网页里每一个字。Agent 读外部内容,本来就是它的核心价值——一个不能读邮件的邮件助手、一个不能浏览网页的浏览器 Agent,等于废了。可一旦它开始读这些你不可控的内容,攻击面就从"用户"扩大到了"全互联网"。任何能把一段文字放到 Agent 视野里的人,都成了潜在攻击者。

Anthropic 在 2026 年 2 月的系统卡里干脆把直接注入这个指标整个删掉了,理由是:过去一年里每一起高影响的生产环境安全事件,涉及的都是间接注入。

flowchart LR
  A[攻击者] -->|把恶意指令
埋进外部内容| B[网页 / 邮件
文档 / 代码库]
  B -->|Agent 正常检索时读到| C[LLM]
  D[真实用户] -->|发出正常请求| C
  C -->|被劫持后调用工具| E[读私有数据 / 发外部请求]
  style B fill:#fde7c2,stroke:#e8b23c
  style C fill:#fde7c2,stroke:#e8b23c

橙色那两块——被污染的外部内容和分不清指令与数据的 LLM——就是整条攻击链的命门。

致命三要素:三个都凑齐才会出事

Simon Willison 提出了一个特别好用的判断框架,叫致命三要素(the lethal trifecta)。一个 Agent 系统真正危险,需要同时满足三个条件:

三个全凑齐,系统就一定可被攻击;缺任何一个,这条路就断了。

EchoLeak 就是教科书般的三要素齐活:Copilot 能读公司内部文档(私有数据)、会检索用户收到的邮件(不可信内容)、能渲染 Markdown 里的外部图片(外传通道——图片 URL 一加载,数据就跟着 query 参数发出去了)。攻击者要做的,只是用一个图片链接把偷来的数据"驮"出去。

这个框架的价值在于:它把"要不要担心 prompt injection"这个模糊的问题,变成了一个可以逐项打钩的清单。2026 年 1 月那一周,安全研究者接连披露了四款主流 AI 生产力工具的漏洞,攻击模式如出一辙,全都踩中了这三要素。

真实攻击长什么样

把抽象的东西落到地面。2025 到 2026 年被公开证实的攻击,大致是这几种形态:

数据外泄。 最主流。EchoLeak 是代表——让 Agent 把它能访问的敏感数据,通过图片、链接、API 调用送到攻击者手里。浏览器类 Agent 在"总结这个网页"时被网页里的隐藏文字骗着泄露了凭据,也是这一类。

劫持工具调用。 2026 年 5 月,微软安全团队披露了一类远程代码执行漏洞:攻击者控制的内容从一份被检索的文档里,一路流到了一次工具调用的参数里,绕过了栈上所有 prompt 层面的防护。Agent 能调的工具越强(执行命令、改文件、发邮件、转账),这类攻击的破坏力就越大。

污染持久记忆。 这个最阴。OWASP AppSec USA 2025 上演示过一种攻击:注入的指令让 Agent 往自己的长期记忆库里写了一条恶意记录。于是一次性的注入变成了常驻后门——攻击早就结束了,但那条记录留在记忆里,在未来每一个会话里、满足特定条件时静默触发。

绕过 AI 审核。 2025 年 12 月有一起真实案例:有人用间接注入绕过了一个基于 AI 的广告审核系统——在送审的内容里埋指令,让审核 AI 自己判定"这条广告没问题"。

CrowdStrike 的 2026 威胁报告记录了针对 90 多家机构的 prompt injection 攻击。这已经不是 PoC 阶段了。

为什么没有彻底解法

讲到这里得说句扫兴的:prompt injection 至今没有、短期内也不会有根治方案。

OpenAI 自己发文承认这是一个"前沿安全挑战"。多个研究团队的结论一致:这是个尚未解决的根本性问题,而靠过滤、靠分类器去拦截恶意 prompt 的尝试,基本都失败了。

原因有两层。

第一,用 AI 防 AI 防不住。最直觉的做法是训一个分类器,专门识别"这段输入里有没有注入"。但 EchoLeak 恰恰绕过了微软专门干这事的 XPIA(Cross Prompt Injection Attempt)分类器。这是一场不对称的攻防:防守方要拦住所有攻击,攻击方只要找到一个漏网的措辞。自然语言的表达空间无穷大,分类器永远有缝。有篇论文标题起得很到位——《攻击者后手出招》(The Attacker Moves Second)。

第二,这是架构层面的、不是参数层面的问题。只要"指令"和"数据"还在同一个 token 流里、还由同一个模型处理,模型就有可能把数据当指令。除非从根上改掉这套架构,否则你做的所有事情都是在降低概率,而不是消除可能。

所以正确的心态是:别想着"解决"它,要想着像管理其他安全风险一样去"管理"它。 你不会指望彻底消灭 SQL 注入的"可能性",你是用 prepared statement、最小权限、审计日志把它的风险压到可接受。prompt injection 也一样。

工程上能做什么:把它当系统设计问题

既然模型本身靠不住,防线就必须建在模型外面。2026 年比较成型的实践,核心就一句话:不要相信 LLM 的输出,在它造成实际后果之前用确定性的代码挡一道。

第一,拆掉致命三要素中的一个。 这是性价比最高的动作。回到上面那张表——你不需要同时防住三件事,只要在架构上让其中一个不成立:处理外部不可信内容的 Agent,就不给它私有数据的访问权;能读私有数据的 Agent,就掐掉它一切外传通道(不许渲染外链图片、不许自由调网络)。把"能读敏感数据"和"能接触外部内容"这两种能力,放进两个不同的 Agent、用代码隔开。

第二,权限隔离 / 最小授权。 多个安全团队的共识是:权限隔离是单项收益最高的防御。给 Agent 的每个工具都按最小必要授权——只读的就别给写权限,能查订单的就别让它能改订单。这样即使注入成功,攻击者拿到的也是一个被关在笼子里的 Agent。

第三,高危操作必须人确认。 转账、删文件、发对外邮件、改生产配置——这类不可逆的操作,不能让 Agent 自己拍板。在工具调用和真实执行之间插一道人工确认。注意:确认界面要展示真实要执行的动作和参数,不能只展示 Agent 自己的"我打算做 X"的自然语言描述——因为那段描述本身也可能是被注入的。

第四,把不可信内容明确标成数据。 检索到的文档、工具返回的结果,在拼进 prompt 时用清晰的边界包起来,并明确告诉模型:这部分是数据,不是给你的指令。这不能根治(模型还是可能被骗),但能拉高攻击成本,是廉价的加固。

第五,输出侧做确定性校验。 在 Agent 的输出真正变成行动之前,用普通代码检查它的结构——工具调用的参数在不在白名单里、要访问的 URL 域名可不可信、数据流向合不合规。再配上 canary token(在敏感数据里埋诱饵,一旦它出现在外发流量里就说明发生了泄露)。

值得关注的一个方向是 Google DeepMind 的 CaMeL:它用两个 LLM——一个"特权 LLM"负责编排任务、能调工具但只看可信输入,一个"隔离 LLM"专门处理不可信数据、完全没有工具调用能力。然后用传统软件安全里的控制流完整性、信息流控制那一套,给每个数据值打上能力标签,从结构上限制数据能流到哪去。它的思路很对——不靠 AI 去猜,靠确定性的工程机制兜底。

flowchart TD
  A[Agent 想执行一个动作] --> B{是高危操作吗?}
  B -->|是| C[人工确认
展示真实参数]
  B -->|否| D{参数 / 域名
在白名单内?}
  C --> D
  D -->|否| E[拒绝执行]
  D -->|是| F[最小权限工具执行]
  F --> G[canary 检测 + 日志审计]
  style C fill:#fde7c2,stroke:#e8b23c
  style E fill:#f8c9c4,stroke:#d9534f

最后:这是 Agent 落地绕不开的一关

我想强调的一点是:prompt injection 不是"等以后再说"的问题,它就是现在决定你的 Agent 能不能上生产的那道关。

OWASP 连续三年把 prompt injection(LLM01)列为大模型的头号风险,这不是凑热闹。一个能力越强的 Agent——工具越多、权限越大、越自动、越深地嵌进关键流程——它的价值越高,被注入后的破坏力也越大。这两件事是同一枚硬币。

所以做 Agent,安全不能等功能做完了再"加固"。它得在架构设计的第一天就在场:这个 Agent 要不要同时持有私有数据和外传能力?哪些操作必须人来拍板?外部内容进来时怎么被隔离?

把它当成系统设计问题,而不是模型问题——因为模型短期内不会帮你解决它。你能依靠的,是权限边界、人工确认、输出校验这些老派但确定的工程手段。在一个分不清指令和数据的模型外面,亲手画好那条它自己画不出的线。

2026 年 4 月有一篇论文,标题直接叫《When More Thinking Hurts》(想多了反而坏事)。里面有个例子我印象很深:让一个大推理模型算"9900 加 1",它居然烧掉了几千个思考 token,中途还一度把正确答案推翻又改回来。一道小学一年级的题,被它想成了奥数。

这就是推理模型这一年的缩影。o1 出来的时候,大家的第一反应是"哇,会思考了";到了 2026 年,大家学到的是另一句话——思考是要花钱的,而且大部分时候,你根本不需要它想那么多。

推理模型到底改了什么

先把概念说清楚。

传统 LLM 的算力几乎全花在训练上。模型训完,推理(inference)时就是一次前向计算,吐 token,快进快出。你给它一道难题,它"脱口而出"——答得对不对,基本取决于训练时见过没见过类似的东西。

推理模型动的是另一处:test-time compute,推理时算力。它在真正回答你之前,先在内部生成一长串"草稿"——拆解问题、试不同思路、自我检查、推翻重来。这串草稿就是所谓的思考过程(chain-of-thought)。你看到的最终回答可能只有三句话,但背后它可能写了一万五千个 token 的内心戏。

flowchart LR
  Q[你的问题] --> A{普通模型}
  A --> A1[直接吐答案]
  Q --> B{推理模型}
  B --> B1[内部草稿
拆解·试错·自检] --> B2[最终答案]
  style B1 fill:#fde7c2,stroke:#e8b23c

这个改动的意义在于:模型的能力第一次变成了可以用算力买的。同一个模型,让它多想,它在数学、代码、逻辑题上的准确率就实打实地往上走。OpenAI 当初说 o3 在真实世界的难题上比 o1 少犯约 20% 的重大错误,靠的不是换了更大的底座,很大程度上就是想得更久、更会想。

从 o1 到 o3、o4-mini,再到 Gemini 2.5 的 thinking、Claude 的 extended thinking、DeepSeek R1、Qwen 3 的思考模式——2026 年你能叫得出名字的主力模型,基本都带"会思考"这一档。test-time compute 从一个研究概念,变成了产品标配。

这一年学到的:思考不是免费的

如果故事到这里就结束,那这篇文章没什么好写。问题恰恰在于——让模型多想,代价大得超出很多人的预期。

代价有三笔,都很实在。

第一笔是 token,直接对应钱。 思考过程里的每一个 token,几乎都按输出价计费。一次普通的 extended thinking 请求,思考部分烧掉五千到两万 token 很常见,加上最终回答,单次成本可能从几分钱跳到三四毛人民币。你界面上看不到这些草稿,但账单上看得到。2026 年有个被反复引用的说法:前沿模型那个"推理强度"旋钮,从低档拉到高档,准确率大概能涨 8 到 22 分,但费用会膨胀 4 到 17 倍。

第二笔是延迟。 同一个旋钮,延迟能拉长 5 到 60 倍。好消息是绝对值在变好——2025 年初,思考模型动不动想 30 秒到 2 分钟;到 2026 年初,o4-mini、Gemini Flash Thinking 处理大多数推理任务能压到 3 到 15 秒。但 3 到 15 秒,对一个要"对话感"的产品来说,依然是灾难。你没法让用户盯着转圈等模型憋一道并不难的题。

第三笔最阴险:想多了真的会把答案想错。 这不是玄学。前面那篇论文给的结论很硬:延长推理常常和"放弃了原本正确的答案"绑在一起。模型想着想着,把对的推翻了。在简单任务上尤其明显——标准模型一步到位答对,推理模型绕一大圈,既慢又贵,还更容易错。

把这张表盯久一点你会发现:推理模型不是"更强的普通模型",它是一个取舍完全不同的工具。强在难题,弱在日常。

什么任务该用,什么任务别用

这是这篇文章最想讲的部分,因为踩坑的人太多了。

我的判断很简单:默认用普通模型,只在被证明需要时才升级到推理模型。 顺序别反过来。很多团队上来就把所有请求挂到推理模型上,觉得"反正更聪明",结果账单爆炸、延迟爆炸,用户体验还更差。

具体怎么分?我按"这道题需不需要多步推演"来切。

该用推理模型的:

• 数学、竞赛题、需要严格推导的逻辑题——这是它的主场,22 分的提升花 17 倍的钱也值。
• 复杂代码任务:跨多个文件的重构、根据一段模糊描述推断完整实现、调一个需要顺着调用链想的 bug。
• 多步规划:把一个大目标拆成一串带依赖的子任务,Agent 的"想清楚再动手"那一步。
• 别人会拿你的输出去仔细核对的场景——反正要花人力 review,模型多花几秒想清楚是划算的。

别用推理模型的(普通模型完全够):

• 分类、打标签、情感判断、意图识别——一步到位的判别任务,让它"思考"纯属浪费。
• 信息抽取、格式转换、把一段文本改写成 JSON。
• 闲聊、客服话术、陪伴类对话——这些要的是快和自然,不是深。
• 摘要、翻译这类"理解 + 复述"的活儿。
• 任何高频、对延迟敏感、用户在等你回话的链路。

有个反例特别值得记:实时语音对话。我之前写过语音 Agent 的延迟预算,从用户说完到 AI 出声,及格线是 500 到 900 毫秒。一个动不动想 5 秒的推理模型,直接出局——它不是慢一点,是把整个产品形态打碎了。语音链路上要么用普通模型,要么把推理模型藏到后台异步去跑,绝不能放在用户等待的关键路径上。

flowchart TD
  T[一个请求进来] --> Q{需要多步推演吗}
  Q -->|否:分类/抽取/闲聊/摘要| M1[普通模型
快·便宜]
  Q -->|是:数学/复杂代码/规划| M2{延迟敏感吗}
  M2 -->|是| M3[推理模型·低思考档]
  M2 -->|否| M4[推理模型·高思考档]
  style M1 fill:#d6ebd6,stroke:#5fa55f
  style M3 fill:#fde7c2,stroke:#e8b23c
  style M4 fill:#fde7c2,stroke:#e8b23c

注意这张图最后还分了一档。“该用推理模型"不等于"该拉满”——这就引出下一节。

“思考预算可调"成了标配,然后呢

2026 年最重要的工程变化,不是某个模型又强了多少,而是思考的量,从开发者手里交了一部分回给模型自己。

早期的 extended thinking,你得手动设 budget_tokens,告诉模型"最多想这么多”。这玩意儿很难调:设小了难题想不透,设大了简单题被过度思考反噬。你得对着每一类任务反复试。

新一代的做法变了。Claude 在 4.6 这一代把固定预算的 extended thinking 标成了 deprecated,换成 Adaptive Thinking——模型自己判断这题要不要想、想多深,简单问题秒回,复杂问题才深挖。OpenAI 的 o 系列、Gemini 的 thinking 模式给的是 reasoning_effort 这种"高/中/低"的强度档。Qwen 3 更直接,一个开关切"思考模式"和"非思考模式"。形式不同,内核是一个意思:思考量变成了一个旋钮,而且默认应该让模型自适应。

这件事对工程的影响,我觉得有三点值得说。

第一,选型粒度变细了。 过去选模型是"用 A 还是用 B",现在是"用 A 的哪一档"。一个模型族内部就能覆盖从"便宜快"到"贵而强"的一大段。这意味着你的系统里不该只有一个固定配置,而该有一个按任务路由思考强度的策略层——简单任务走低档甚至关掉思考,难任务才放开。

第二,成本和延迟从"基本固定"变成"高度可变",可观测性必须跟上。 同一个接口,这次请求 800 毫秒、下次 12 秒,这次两分钱、下次三毛,都正常。你必须把思考 token 数单独打点监控,否则某天账单翻五倍你都不知道是哪类请求干的。我的建议是:思考 token 当成一类独立指标,和普通输出 token 分开看。

第三,别太迷信"自适应"。 模型自己决定想多深,方向是对的,但它对"这题难不难"的判断并不总是准——开头那个把加法想成奥数的例子就是证据。所以稳妥的做法是给自适应加一道硬上限:用 max_tokens 卡死最坏情况,既防失控成本,也防它越想越歪。让它自适应,但别让它无限自适应。

写在最后:把"想多久"当成一个设计决策

推理模型这一年,最大的收获其实是一句很朴素的话:思考不是越多越好,是要恰好够用。

o1 刚出来时,行业的潜台词是"模型终于会思考了,以后让它多想就对了"。一年下来,这个叙事被修正得很彻底。多想会变贵、会变慢、在简单任务上甚至会变笨。真正成熟的用法不是"全都拉满",也不是"全都关掉",而是把"这个请求该想多久"当成一个和选模型同等重要的设计决策。

如果你 2026 年在搭一套 LLM 系统,我会建议你这样排优先级:先默认用普通模型,把延迟和成本压在地板上;再把那些真正需要推演的任务挑出来,升级到推理模型;最后给推理那部分配上强度路由和硬上限,让它在"够聪明"和"别失控"之间待着。

会思考是能力,知道什么时候不该思考,才是工程。

今年同一句话,Veo 3.1 能给你一段八秒的画面:猫跳上台面,牛奶盒倒下,液体顺着桌沿往下淌,落地有声——连"啪嗒"那一下都对上了。

进步是真的。但如果你由此以为"AI 已经能拍片了",那是被发布会的精选片段骗了。2026 年 5 月的真实情况是:AI 视频在 10 秒以内的单镜头里已经接近以假乱真,但只要你想讲一个完整的故事,它立刻露馅。 这篇把这条分界线划清楚。

四家主流,各打各的算盘

先把牌摊开。2026 年第一梯队基本是这四家加一个 Runway,但他们的定位差得很远。

几个观察值得说。

Sora 的故事很拧巴。 Sora 2 的技术口碑不差——物理一致性、多镜头世界状态保持都做得用心。但 OpenAI 把消费级 Sora App 砍了,API 也排上了停服日程。一个技术上领先的产品,商业上却在往回收。这说明一件事:纯粹"文生视频"作为一个独立 App,很难单独养活自己。

真正在闷声赚钱的是中国公司。 可灵全球用户冲到 6000 万,快手已经在张罗把它拆出来单独 IPO,Pre-IPO 估值约 200 亿美元。在第三方盲测里,可灵在"自然人物动作"和"提示词遵循"这两项上经常排第一,尤其是多人互动的复杂场景。字节的 Seedance 2.0 走的是另一条路——多模态联合架构,音频和画面在同一次生成里一起算出来,所以对口型和环境音效更准。

Veo 是"水桶型选手"。 它未必每一项都最强,但画质稳、运镜稳、还能直接塞进 Google Vids、Flow 这些工具里。对一个本来就用 Google 全家桶的团队,Veo 的"顺手"本身就是竞争力。

现在真能做好什么

把发布会的滤镜摘掉,2026 年 AI 视频确实已经做扎实的能力有这么几块。

10 秒以内的单镜头,质量过关。 一个固定或简单运镜的镜头——人物特写、产品旋转展示、风景空镜——只要不超过十几秒,现在的输出在画质、光影、材质上已经能用在正式内容里。这不是"凑合能看",是真能上片。

运镜变成了可控参数。 推、拉、摇、移、跟焦,这些以前要靠运气抽卡的东西,现在能在提示词里点名,而且基本听话。可灵 2.6 的运动控制甚至能把一段参考视频的运动轨迹"迁移"到新画面上。

风格化内容是甜区。 动漫、定格、超现实、广告质感——这些本来就不要求"物理绝对正确"的风格,AI 做得比写实更稳。因为写实的破绽肉眼一抓一个准,而风格化本身就给了模型容错空间。

原生音频不再是后期。 Veo 3.1、Sora 2、Seedance 2.0 都能在生成画面的同时生成对白、音效、环境声。Seedance 是音画联合架构,声音和画面同一次算出来,对口型准度明显更好。这一步省掉的后期工作量,比想象中大。

还做不好的那几样,是真做不好

这是这篇文章最想说清楚的部分。下面几个不是"再等几个月就好",是当前路线下的硬骨头。

flowchart TD
  A[一句提示词] --> B{时长 < 10秒?}
  B -->|是| C[单镜头质量过关
可直接用]
  B -->|否| D[长一致性塌房
人物/场景漂移]
  C --> E{需要精确控制?}
  E -->|否| F[甜区:社媒/空镜/风格片]
  E -->|是| G[反复抽卡
不如真拍]
  style C fill:#cdebc5,stroke:#5a9e4a
  style F fill:#cdebc5,stroke:#5a9e4a
  style D fill:#f5c6c6,stroke:#c0504d
  style G fill:#f5c6c6,stroke:#c0504d

长时一致性。 这是最大的坎。绝大多数工具撑到 30–60 秒之后,画面就开始"漂"——人物的脸慢慢变样,衣服的扣子数量对不上,背景里的家具悄悄挪位。这叫身份漂移(identity drift)和误差累积。观众其实两三秒就能察觉到不对劲,信任感一下就没了。所以你看到的所有"AI 生成的两分钟短片",几乎都是十几个短片段剪出来的,不是一气呵成。

复杂物理。 刚性物体的碰撞、抛物线,模型已经学得不错。但液体、布料、烟雾、多个物体互相作用,还是会出"看着合理、物理上错"的画面:水流会有一瞬间往上爬,布料穿过身体,头发像有自己的意志。Sora 2 的篮球反弹是个标志性进步,可那是因为篮球轨迹相对简单。

精确控制。 你能描述一个大概,但没法精确指挥。“让她在第三秒抬左手,手停在下巴下方两厘米”——这种导演级的精度,提示词给不了。结果就是反复抽卡:生成、不对、改词、再生成。当你需要的画面足够具体时,抽卡二十次的时间成本,经常已经超过真拍一条。

人物一致性。 同一个角色出现在不同镜头里还长一个样,依然不稳。Runway Gen-4 靠单张参考图做角色一致性是目前最像样的方案,Sora 2 的"客串"功能能把你本人放进场景。但只要切镜头、换光线、换景别,人物多少会变。对需要主角连续出场的叙事内容,这是致命伤。

哪些场景已经能真金白银落地

说了这么多限制,不是劝你别用。恰恰相反——只要你的需求落在"短、单镜头、容错高"这个区间里,AI 视频今天就能省钱省时间。 已经在规模化落地的有这么几类。

广告和电商的零碎镜头。 产品空镜、氛围片段、转场素材,这些本来就是几秒钟的单镜头,AI 做正合适。一条电商详情页视频里,真人出镜的部分照拍,中间的产品展示、场景氛围用 AI 补,成本结构立刻变了。

分镜和概念验证。 这个被低估了。导演、广告创意想跟客户讲清楚一个镜头长什么样,以前画分镜板,现在直接生成一段动态参考。它不用是最终成片,只要"意思到了",决策效率就上来了。哪怕最后还是真拍,前期沟通的来回少了一大半。

社媒短内容。 抖音、小红书、Reels 上那种十几秒的卡点、转场、视觉奇观,本来就不追求长叙事和物理严谨,容错空间大,正好是 AI 的甜区。可灵、Seedance 在国内创作者里铺得快,就是这个原因。

多语言本地化。 Seedance 2.0 这类带多语言对口型的模型,让一段素材换个语言重新"配音"且对得上嘴,这在出海内容里是实打实的刚需。

离"替代真实拍摄"还差什么

最后回到那个所有人都在问的问题:它什么时候能替代片场?

我的判断是:短期内不会,而且"替代"这个框架本身就提错了。

差的不是画质——画质已经够了。差的是这三样:

一是连续叙事的稳定性。电影是几十个镜头里同一批人、同一个世界,连贯地讲一个半小时。AI 现在连两分钟的连贯都保不住。这不是分辨率问题,是模型对"世界状态"的记忆问题,得有架构层面的突破。

二是精确的可控性。片场里导演说"再来一条,这次慢半拍",演员能立刻调整。AI 的"再来一条"是重新抽卡,你没法精确指挥它改哪里、改多少。创作是控制的艺术,失控的工具再强也只是素材生成器。

三是责任与确定性。一个剧组交付的是确定的、可追溯、可修改的成片。AI 给你的是一次概率采样的结果,改一个细节可能整个画面都变了。商业制作要的是"我要的就是这个,而且下次还能复现",这一点 AI 目前给不了。

flowchart LR
  A[2026 现状] --> B[10秒单镜头
已经能打]
  B --> C[需突破:长一致性]
  C --> D[需突破:精确控制]
  D --> E[真正进片场]
  style B fill:#cdebc5,stroke:#5a9e4a
  style E fill:#fde7c2,stroke:#e8b23c

所以更准确的说法是:AI 视频不会"替代"拍摄,它会先吃掉拍摄里最标准化、最零碎的那部分——空镜、产品镜、氛围片段、分镜预演。这部分本来就不太需要"创作",AI 接手天经地义。而真正考验连续叙事、精确表演、复杂调度的部分,还稳稳地留在人手里。

如果你是创作者,2026 年正确的姿势不是观望,也不是 all in,而是:把它当成一个非常强的"短镜头素材机"和"分镜工具",而不是一个"导演"。 用它擅长的,绕开它做不到的。这一年它能帮你省的钱和时间,已经足够多了。

参考来源:Sora 2 — OpenAI、Veo — Google DeepMind、Veo 3.1 Lite — Google Blog、Runway Gen-4 — Runway Research、Seedance 2.0 — ByteDance Seed、Kling AI 官网、The State of AI Video Generation in 2026 — is4.ai。

第二天客服群里有人说 AI 答得不对劲。你回头去看,发现那三个例子确实变好了,但另外二十种你没试的情况里,有五种悄悄变差了。

这是做 LLM 应用最常见的窘境:你没法靠"看几个例子"判断一次改动是涨还是跌。模型是个高维的黑盒,你改 prompt、换模型、调温度,影响面是发散的——在你盯着的地方变好,在你没盯着的地方变坏。评估(eval)要解决的就是这件事:把"我觉得变好了"换成"我有证据说变好了"。

这篇讲怎么把这套证据系统搭起来,以及一路上的坑。

公开 benchmark:能看排名,不能信分数

打开任何一个模型发布页,都有一排 benchmark 分数:MMLU 多少、GPQA 多少、SWE-bench 多少。这些数字有用,但对你的应用,它的参考价值比你以为的小得多。

第一个问题是饱和。2026 年的前沿模型在 MMLU 上普遍是 92–94%,彼此之间的差距已经掉进噪声里了。一个 93%、一个 94%,你没法据此说后者更强——重跑一次,排名可能就反过来。MMLU 这种榜单现在只能告诉你"这是不是个能用的模型",没法在头部模型之间分高下。后来的 MMLU-Pro 想救场,到 2026 年初头部模型也挤到了 90% 附近,同样在走向饱和。

第二个问题更麻烦:污染。Benchmark 的题目是公开的,公开就意味着它们大概率被爬进了下一代模型的训练数据。模型可能不是"做对了"题,而是"背过"答案。已经被记录的案例不少:MMLU 的题目在 Common Crawl 里能找到原文;HumanEval 的题和 LeetCode 题高度重合;SWE-bench 的 issue 在公开 git 历史里能翻到现成的修复 commit。

污染有多严重?Scale AI 做过一个对照实验:他们照着小学数学题 GSM8K 的风格,重新出了 1250 道全新的题。结果模型在新题上系统性掉分,最差的那个掉了 13 个百分点。同一个模型,题目换成没见过的,能力就缩水一成多——这说明原来那个高分里,有相当一部分是"背"出来的。

所以 2026 年大家转向抗污染的 benchmark:LiveCodeBench、LiveBench 这类按时间切片,只用某个日期之后才出现的新题;FrontierMath 把题目压在手里不公开。这些比静态榜单可信。但即便如此,它们衡量的还是"通用能力",不是"你的任务"。

结论很直接:公开 benchmark 用来粗筛候选模型——把明显不行的排除掉。但"这个模型在我的客服场景里好不好用",它一个字都没回答。这个问题只能你自己回答。

自己的 eval 集:这才是真正的资产

你的应用有一个公开 benchmark 永远覆盖不到的东西:你的真实输入分布。你的用户怎么提问、问什么、用什么语气、夹杂什么错别字和行业黑话,这是你独有的。eval 集就是把这个分布固定下来。

怎么建,有三个我认为不能省的原则。

第一,例子来自真实流量,不要凭空编。 你坐在工位上想象的用户提问,和用户真实打出来的,分布不一样。最好的来源是线上日志:把真实请求捞出来,尤其是那些用户追问、重述、明显不满意的——失败案例的信息密度最高。每修一个线上 bug,就把那个 case 沉淀进 eval 集,它就再也不会悄悄复发。

第二,先覆盖,再追数量。 一个有 50 条、覆盖 15 种场景的 eval 集,比一个有 500 条、全是"查订单状态"的 eval 集有用得多。你要的是把输入空间的不同角落都摸到:正常请求、边界请求(超长输入、空输入、多意图混在一句)、对抗请求(prompt 注入、诱导越权)、还有那些你修过的历史 bug。每加一条都先问:它覆盖了一个新角落,还是只是重复?

第三,每条例子都要能判对错。 一条 eval 数据 = 输入 + 判断标准。判断标准可以是标准答案,可以是一组必须满足的规则(“回复里必须包含订单号”、“不能承诺退款”),也可以是一段评分 rubric。没有判断标准的例子不是 eval,是 demo。

eval 集建起来之后,它会变成你团队最值钱的资产之一——比某一版 prompt 值钱。Prompt 会被改无数次,模型会换代,但 eval 集是持续累积的、关于"什么叫做对"的集体知识。

三种判分方式,以及各自的脾气

有了例子,接下来是怎么自动判分。三种方式,从硬到软排:

优先用硬的。能用精确匹配解决的,绝不上 LLM 判分——它客观、免费、每次结果一样。能拆成规则断言的也尽量拆:“回复里有没有订单号"用一个正则就够了,没必要请一个大模型来读。

真正绕不开的是开放式任务——“这个摘要写得好不好”、“这个客服回复够不够得体”。这种没有唯一答案,只能上 LLM-as-judge:让另一个模型按 rubric 给被测输出打分。这是 2026 年的主流做法,但你得知道它的脾气。

LLM-as-judge 会骗你,而且骗得很有规律

LLM 当裁判的最大问题是:它的偏差不是随机噪声,是系统性的。随机噪声多跑几次能平掉,系统性偏差不会——它会朝一个固定方向把你的判断带偏。

有几个偏差已经被反复测出来,几乎跑不掉:

• 位置偏差。 做两个回答的对比评分时,排在前面的那个赢面更大,跟它质量无关。一篇系统研究跨 15 个裁判模型、约 15 万次评测,确认这个偏差稳定存在,而且两个回答质量越接近,偏差越明显。
• 长度偏差。 更长、更啰嗦的回答倾向于拿更高分,哪怕信息量没多。
• 自我偏好。 裁判模型会偏爱"长得像自己输出"的回答。用 GPT 当裁判,它会高看 GPT 系的生成。

这些偏差有多严重?2026 年 RAND 的一项研究发现,没有任何一个裁判模型在所有 benchmark 上都可靠,前沿模型在高难度的偏差测试上错误率超过 50%。换句话说,你直接拿一个模型当裁判,它的判断有可能跟抛硬币差不多。

但 LLM-as-judge 不是不能用,是要带着纪律用:

1. 位置偏差用双向取平均。 每对回答评两次,A 在前评一次、B 在前评一次,结果平均。一次都不能省。
2. 自我偏好用跨家族裁判。 别用同一家的模型既当选手又当裁判。被测是 GPT,就用 Claude 或 Gemini 当裁判。
3. 长度偏差写进 rubric。 在评分标准里明说"长度不是加分项,只看信息是否准确、完整、相关”。
4. 裁判本身也要被评估。 这步最常被跳过,但最关键:你得人工标一批"金标准"数据——比如 100 条人类专家打过分的样本——然后看你的 LLM 裁判跟人类标注的一致率有多高。一致率太低,这个裁判就不能用。裁判是被测系统的一部分,它没经过验证,它给的所有分数都是空的。
5. 让它做选择题,别做作文题。 LLM 判断"A 和 B 哪个好"比直接打"7.5 分"靠谱得多。能转成两两对比或分类的,就别让它打绝对分。

整套流程串起来大概是这样:

flowchart TD
  A[线上真实流量] --> B[沉淀为 eval 集
输入 + 判断标准]
  B --> C{任务类型}
  C -->|有唯一答案| D[精确匹配 / 规则断言]
  C -->|开放式| E[LLM-as-judge
双向 + 跨家族 + rubric]
  E --> F[用人类金标准
校准裁判一致率]
  D --> G[聚合分数]
  F --> G
  G --> H[CI 里设阈值
低于线就拦住]

eval 也会被过拟合

这是个反直觉但很真实的陷阱:你太频繁地拿同一个 eval 集调东西,迟早会过拟合它。

机制和模型训练里的过拟合一模一样。你改 prompt → 看 eval 分 → 没涨 → 再改 → 再看分……重复几十次之后,你其实是在用 eval 集当训练信号,手动地把 prompt"拟合"到这 50 条例子上。最后 eval 分很漂亮,线上没动静——你优化的是分数,不是真实质量。判分用 LLM 的时候更隐蔽:你可能在不知不觉中专门迎合那个裁判的偏好。

防过拟合有几个具体做法:

留一个 holdout 集,平时锁起来。 把 eval 集切成两份:开发集天天用、随便看;holdout 集藏好,只在准备上线前、或重大版本节点跑一次。如果开发集涨了、holdout 没涨,说明你过拟合了开发集,这次改动是假涨。

让 eval 集持续流动。 eval 集不是建一次就定死的。每周从最新线上流量补新例子进去,旧的、已经被反复优化过的逐步轮换出主力集。一个会更新的 eval 集,你很难持续过拟合它——因为标准在动。

盯波动幅度,别盯小数点。 eval 分从 86% 变成 87%,在大多数 eval 集规模下都落在统计噪声里,不代表任何东西。先估算一下你这个 eval 集的噪声范围(同一个配置跑几次,看分数抖多大),只有改动幅度明显超过噪声,才算数。

eval 过了,不等于线上变好

最后这点是态度问题:离线 eval 永远是真实世界的近似,不是真实世界本身。

eval 集再好,也只是你当下能想到的输入。用户永远会问出你没预料的问题,真实分布永远在漂移。所以离线 eval 全绿,不等于上线就好。真正的裁判是线上。

成熟的做法是把离线和线上接成一条链:

• 离线 eval 当守门员。 接进 CI:每次改 prompt、换模型、动检索,自动跑一遍 eval,分数低于阈值的 PR 直接拦住,不让合。这一步拦的是明确的退步——已知该做对的事别做错了。
• A/B 测线上真实效果。 离线绿灯只是"准你上",不是"它一定好"。新版本上线要灰度,拿一小部分真实流量跑 A/B,比的是真实业务指标:任务完成率、人工转接率、用户重述率、负反馈率。
• 线上当 eval 集的源头。 A/B 里跑出来的新失败 case,回流进 eval 集。这样下次同样的问题就被离线 eval 挡住了。

这是个闭环:线上发现问题 → 进 eval 集 → CI 里防复发 → 新版本 A/B → 再发现新问题。eval 集就在这个循环里越长越厚,你的"证据系统"越来越能覆盖真实世界。

flowchart LR
  A[改动:prompt/模型/检索] --> B[CI 跑离线 eval]
  B -->|低于阈值| A
  B -->|通过| C[灰度 A/B]
  C --> D[看线上指标
完成率/转接率/负反馈]
  D -->|发现新失败| E[回流进 eval 集]
  E --> B

写在最后

把 LLM 评估这件事压成几句:

公开 benchmark 只能粗筛模型,饱和加污染让它的分数当不得真。真正靠谱的是你自己的 eval 集,例子要来自真实流量、先求覆盖、每条都能判对错——这是你团队最该攒的资产。判分能用硬规则就别用 LLM,绕不开 LLM-as-judge 时,位置、长度、自我偏好三个偏差必须主动治,裁判本身要拿人类标注校准过才算数。别在同一个 eval 集上反复磨,留 holdout、让 eval 集持续更新。最后记住离线 eval 只是近似,线上 A/B 和真实指标才是终审。

很多团队做 LLM 应用,功能上得飞快,却始终说不清每次改动是涨是跌——因为他们一直在"看几个例子拍脑袋"。先把这套证据系统搭起来,你才算真的在迭代,而不是在赌博。

参考资料:

• A pragmatic guide to LLM evals for devs — The Pragmatic Engineer
• Evaluation best practices — OpenAI API
• Judging the Judges: A Systematic Study of Position Bias in LLM-as-a-Judge — arXiv
• LLM-as-a-Judge: Why Frontier Models Fail 50%+ Bias Tests — Adaline
• What Is a Contaminated LLM? Detection, Famous Cases, 2026 Guide — llm-stats.com
• What LLM Benchmarks Don’t Measure — benchmarkingagents.com
• What is LLM evaluation? A practical guide — Braintrust

这件事一年前还做不到。

过去这一年,所有头条都给了旗舰大模型:更长的上下文、更强的推理、更贵的订阅。但真正改变"AI 装在哪儿"这个问题的,是另一条没什么人盯着的线——几 B 参数的小模型,和把它们塞进手机、笔电、边缘盒子的工程。这条线今年悄悄拉满了。

我想把这件事讲清楚:小模型现在到底能做好哪些事,为什么端侧值得,量化和蒸馏在中间干了什么,以及——同样重要——它干不了什么。

先说清楚:小模型不是"大模型的劣化版"

很多人对小模型的印象停留在"便宜但是笨"。这个印象在 2024 年大致成立,现在不成立了。

关键的转变是:小模型不再靠"也学一点世界知识"来对标大模型,而是放弃了一部分知识广度,换取在窄任务上的密度。微软的 Phi 系列把这条路走得最直白——靠精心筛选的高质量训练数据,Phi-4 在 MATH 和 GPQA(研究生级科学题)这类基准上能压过体量大得多的模型。它不是"小一号的 GPT",它是另一种东西。

阿里的 Qwen3 把尺寸切得很细:0.6B、1.7B、4B、8B 一路排下来。官方技术报告里有个反直觉的数据——Qwen3 的 4B / 1.7B,在过半数基准上能打过上一代的 Qwen2.5-7B / 3B,尤其在 STEM 和代码题上。新一代的 4B,约等于老一代的 7B。 这就是过去一年小模型走过的距离。

谷歌的 Gemma 也在做同样的事。4 月发布的 Gemma 4,最小的 E2B / E4B 变体用了 Per-Layer Embeddings 这类结构技巧,4-bit 量化后 5GB 内存就能在现代手机上跑起来。

所以判断一个小模型,别再问"它知道的有没有大模型多"——它注定不多。要问的是:在我这个具体任务上,它够不够。

它现在能做好哪些任务

把场景摊开看,小模型今天在这几类任务上已经够用,而且是真的够用,不是"凑合":

文本的搬运和改造。 总结、改写、润色、抽取实体、分类、按格式重排——这类任务不需要模型"懂很多",只需要它"听话且稳"。苹果那个 3B 端侧模型的官方定位就写得很白:它擅长总结、抽取、文本理解、润色、短对话,它明确不是一个用来问世界知识的聊天机器人。这个定位是诚实的,也是对的。

结构化输出和函数调用。 这是过去一年小模型最大的一块进步。Gemma 4 是第一个把"agentic 能力"当成一等设计目标的开源模型族——它不靠语法约束,就能稳定吐出合法的、可解析的 JSON 工具调用。这意味着一个本地小模型可以真的当"调度员"用:理解你的意图,挑对工具,填对参数,剩下的交给确定性代码去做。对很多 Agent 场景,模型本来就不该负责"算出答案",它只负责"派活"。

作为流水线里的快环节。 在我做的实时语音方向,小模型有个特别实在的用法:用一个本地快模型先兜住首句——“嗯"“好的,我看一下”——同时大模型在后台接管真正的内容。用户感知到的延迟一下就下来了。小模型在这里不是主角,是"垫话的人”,但这个角色很值钱。

垂直微调后的专用任务。 有评测把 12 个小模型放在 8 类任务上比,结论是 Qwen3-4B 微调后整体最强,在不少具体任务上能逼近一个 120B 级别的"老师"模型,而它只要一块消费级显卡就能部署。针对单一任务微调过的 4B,常常比通用的大模型更好用——它没有"什么都想说一点"的毛病。

一句话:凡是任务边界清晰、对世界知识依赖不深的活,小模型现在基本能接。

为什么端侧值得——算三笔账

能在端侧跑,和值得在端侧跑,是两件事。值得不值得,得算账。

第一笔,延迟。 端侧推理省掉的是网络往返和服务端排队。一次云端调用,光网络和排队的尾巴就可能几十到几百毫秒,还不稳定——你控制不了用户的网络。端侧模型首 token 不走网络,延迟低且可预测。对实时交互(语音、输入法、补全)来说,可预测比平均值低更重要。

第二笔,隐私。 数据不出设备,这不是宣传话术,是合规上实打实的区别。用户的短信、相册、健康数据、剪贴板——这些东西一旦"为了 AI 功能"传到云端,你就要为它的存储、传输、留存负责。端侧推理把这个责任直接消掉了。这也是苹果整条 Apple Intelligence 叙事的地基。

第三笔,成本。 这笔账最容易被低估。高频调用的场景下,把推理从云端 API 挪到端侧或边缘自托管,成本能降九成以上,高频负载的回本周期常常不到 18 个月。注意前提是高频——一个一天被调用三次的功能,没必要折腾端侧;一个每次输入都触发的补全功能,云端账单会吓到你。

但端侧不是免费午餐,它也有反方向的代价:

flowchart LR
  subgraph 端侧
    A1[延迟低且可预测]
    A2[数据不出设备]
    A3[高频场景成本极低]
    A4[受设备内存/算力封顶]
    A5[模型更新要走发版]
  end
  subgraph 云端
    B1[模型可以很大很强]
    B2[随时热更新]
    B3[网络抖动/排队不可控]
    B4[高频调用账单线性增长]
    B5[数据要出设备]
  end
  style A4 fill:#fde7c2,stroke:#e8b23c
  style A5 fill:#fde7c2,stroke:#e8b23c
  style B3 fill:#fde7c2,stroke:#e8b23c
  style B5 fill:#fde7c2,stroke:#e8b23c

端侧的两个真痛点:算力封顶(用户的旧手机就是跑不动 7B),和更新慢(模型修了 bug 要等 App 发版,不能像云端那样当天热推)。所以现实里成熟团队的做法是混合:简单高频的活落端侧,复杂低频的活路由到云端。

量化和蒸馏:把模型塞进设备的两把钳子

小模型能上端侧,光靠"参数少"还不够。一个 4B 模型用 FP16 存,也要 8GB,塞进手机内存还是紧。真正把它压进去的,是量化和蒸馏。

量化是压"表示精度"。 模型权重原本是 16 位浮点,量化把它降到 8 位、4 位甚至更低。直觉上这会掉精度,但实际上掉得没你想的多——4-bit 的 Q4_K_M 这类方案,跟原始 BF16 比通常只掉 1~3 个百分点的基准分。代价换来的是:一个 Llama 3.2 3B 做 4-bit 后训练量化,体积砍掉约 69%,就能在普通安卓机上顺跑。

这里要分清两种量化:

苹果那个 3B 端侧模型用的就是更狠的一招:2-bit 量化感知训练。在 2-bit 这种极端低比特下,纯后训练量化会崩,只有训练时就让模型"知道自己会被压成 2 位",精度才扛得住。这是用训练成本换部署体积的典型取舍。

蒸馏是压"知识"。 它不动表示精度,而是让一个小模型(学生)去模仿一个大模型(老师)的输出分布。学生学到的不只是"正确答案",还有老师对每个选项的"软概率"——这里面藏着大模型的判断方式。蒸馏过的小模型,在被蒸馏的那个任务域上,表现会明显超过同尺寸从头训的模型。

要点是:量化和蒸馏不冲突,是叠着用的。 典型流水线是先蒸馏出一个能干活的小模型,再量化把它压进设备内存。一把钳子压知识,一把钳子压精度,两把一起上,4B 才进得了手机。

flowchart LR
  A[大模型 / 老师] -->|蒸馏
传递知识| B[小模型 / 学生
4B FP16]
  B -->|量化
压缩精度| C[端侧模型
4B 4-bit]
  C --> D[手机 / 笔电 / 边缘盒子]
  style B fill:#fde7c2,stroke:#e8b23c
  style C fill:#fde7c2,stroke:#e8b23c

硬件这边也在同步补位。今年笔电上的 NPU 终于不只是"参数表上的一行字"了——谷歌的 LiteRT-LM 在 Linux、macOS、Windows 上都能把推理路由到 NPU;AMD 的 Ryzen AI Max+ 这类芯片配上百 GB 级的统一内存,本地跑 7B~13B 已经不费劲。模型在变小,设备在变强,两条线在中间撞上了。

它干不了什么——别被"逆袭"冲昏头

写到这儿得踩一脚刹车。小模型这一年确实猛,但有几件事它现在做不到,而且短期也做不到。

它的世界知识就是浅。 这是参数量的物理限制,不是调教问题。研究里反复出现的一个结论:小模型的幻觉率显著高于大模型。尤其当你拿大模型的输出去微调小模型时,会出现"知识错配"——喂给它的知识超出了它本身装得下的量,反而更容易胡说。所以任何依赖"模型自己知道很多事实"的场景——开放域问答、冷门领域咨询——别指望端侧小模型。要做,就得给它接检索(RAG),让事实从外部来,模型只负责组织语言。

长链条、多步推理它会断。 需要七八步严密推演才能得到的答案,小模型中途容易掉链子。它适合"一两步就能想清"的任务,不适合当复杂推理的主脑。

再小一点就崩了。 别被"参数越小越好"带跑偏。1B 以下的模型(比如 270M、0.5B 这个量级)是真能跑,但质量在除了最简单的分类之外的任务上断崖式下跌。不是所有任务都越小越好,有个下限,过了就是不能用。

我的判断很直接:小模型不是来取代大模型的,这场"逆袭"不是零和的。它做的事是把 AI 能力的下限抬高了——以前必须上云、必须付费、必须联网才能做的一批活,现在一台设备本地就能办。大模型继续往上探能力的天花板,小模型在下面把地基铺宽。这两件事都在发生,而且互不矛盾。

如果你现在要做端侧

给一个落地顺序,和我做语音 Agent 时的优先级思路一致——先想清楚,再动手:

1. 先问任务边界,别先挑模型。 任务边界清晰、不靠深度世界知识,才适合端侧小模型。边界模糊的,先别碰。
2. 按调用频率决定端侧还是云端。 高频(每次输入都触发)优先端侧;低频复杂任务留给云端。混合是常态,不是妥协。
3. 要事实,就上 RAG,别让小模型硬背。 把"知道什么"外置成检索,模型只管"怎么说"。这一步能把幻觉问题压下去一大半。
4. 模型选型从 4B 这一档试起。 今天 4B 是端侧的甜区——Qwen3-4B、Gemma 4 E4B 这一档,能力够、塞得进、微调后很能打。往下到 1B 以下要非常谨慎。
5. 量化按设备定。 手机这种内存紧的,认 4-bit、认 GGUF;有 NPU 的笔电,把推理路由过去,能凉一截也快一截。

端侧 LLM 今年最大的变化,不是某个模型刷新了某个榜单,而是**“在设备上本地跑一个够用的语言模型"这件事,从研究 demo 变成了产品默认选项**。你的手机已经在这么做了。接下来一年,轮到你的产品。

这听起来像偷工减料,其实是过去三年大模型架构最重要的一次转向。到 2026 年,你叫得出名字的开源旗舰里,几乎没有一个还是"老老实实每个参数都算"的稠密模型:DeepSeek V4-Pro(1.6 万亿总参 / 490 亿激活)、Qwen 3.5(3970 亿 / 170 亿)、Llama 4 Maverick(4000 亿 / 170 亿)、Kimi K2(1 万亿 / 约 320 亿)、Mistral Large 3(6750 亿 / 410 亿)。这个架构叫 Mixture-of-Experts,混合专家。

它解决的是一个很具体的矛盾:模型想变聪明,最直接的办法是堆参数;但参数一多,推理就慢、就贵。MoE 的本质,是把"模型有多少知识"和"算一次要花多少钱"这两件事拆开。这篇讲清楚它怎么做到的,以及它换来了什么样的工程代价。

先讲清楚:稠密模型贵在哪

传统的大模型——也就是 GPT-3、早期 Llama 那种"稠密"(dense)模型——有一个朴素的规则:每个 token 经过每一层时,所有参数都要参与计算。

一个 700 亿参数的稠密模型,处理一个 token 就要做大约 700 亿次乘加。处理一句 100 字的话,乘以 100。参数翻倍到 1400 亿,这个账单也跟着翻倍。算力、显存带宽、电费,全是线性涨上去的。

问题是,模型里真的每个参数对每个 token 都有用吗?

直觉上不是。你问它"今天北京天气",和你让它"写一段 Rust 的并发代码",用到的知识完全不同。稠密模型的浪费就在这:不管你问什么,它都把"写代码的脑区"和"聊天气的脑区"全部点亮算一遍。

MoE 想做的事很朴素——该用哪块脑子,就只用哪块。

用一个类比把它讲透

把稠密模型想象成一家公司,每来一个问题,全公司 200 个人都得开会、都得发言,然后把意见汇总。问题再小也这么干。开会效率极低,但好处是没人会漏掉。

MoE 是另一种公司。同样养着 200 个员工(这叫专家,expert),但每来一个问题,门口坐着一个调度员(这叫路由器,router 或 gating network),它扫一眼问题,只挑最对口的 8 个人进会议室,其余 192 人继续待岗。

关键点来了:

• 这家公司"知识总量"还是 200 人份的——养着这么多专业各异的人,什么问题都有人能接。
• 但"开一次会的成本"只有 8 人份——大部分人这次根本没参与。

这就是 MoE 那句听起来矛盾的话——“参数量大,但推理便宜”——的全部秘密。总参数(200 人)决定模型的知识容量;激活参数(8 人)决定你每跑一次推理的算力账单。MoE 把这两个数字解耦了。

DeepSeek V3 就是个标准样本:总参 6710 亿,但每个 token 只激活 370 亿。它每个 token 的计算量,大约相当于一个 370 亿的稠密模型,但它肚子里装的知识,是 6710 亿那个量级的。官方的说法是,它每 token 的有效计算成本,大致是同等总参稠密模型的二十分之一。

路由器:整个架构的开关

MoE 里最精巧、也最容易出问题的零件,是路由器。

它的工作具体发生在模型的每一个 MoE 层里。一个 token 进来,路由器算一个打分,给当前层的每个专家打个分,然后选出得分最高的几个(术语叫 top-K,DeepSeek V3 是 top-8),只把这个 token 送进这几个专家。专家各自算完,按打分加权汇总,再往下一层走。下一层又是一次全新的挑选。

flowchart TD
  T[输入 token] --> R{路由器
给每个专家打分}
  R -->|得分 0.41| E1[专家 1 ✓]
  R -->|得分 0.27| E2[专家 2 ✓]
  R -->|得分 0.02| E3[专家 3 跳过]
  R -->|得分 0.18| E4[专家 4 ✓]
  R -->|得分 0.01| E5[专家 ... 跳过]
  E1 --> M[加权汇总]
  E2 --> M
  E4 --> M
  M --> O[进入下一层]
  style E3 fill:#eee,stroke:#bbb,color:#999
  style E5 fill:#eee,stroke:#bbb,color:#999
  style R fill:#fde7c2,stroke:#e8b23c

这里有几个反常识的点,值得单独说:

专家不是"按学科分工"的。 你不会找到一个"数学专家"或者一个"法语专家"。训练完之后去看,专家学到的分工往往很碎、很说不清——可能某个专家专门处理标点和换行,某个专门管代码缩进。分工是训练里自己涌现出来的,人没法预先指派。

路由是逐层、逐 token 的。 不是一句话进来挑一次专家就定了。一个 token 在 60 层里,可能经过 60 组完全不同的专家组合。所以"激活了哪些专家"是个非常动态的东西。

2026 年的主流是"细粒度专家 + 共享专家"。 DeepSeek 带火的这套设计有两个改动。一是把专家切小切多——与其养 8 个大专家,不如养 256 个小专家,每次激活 8 个。专家越细,组合越多,分工越能专精。二是留一两个共享专家(shared expert)常驻,不参与路由,每个 token 都过——专门负责"标点、语法、常识"这类谁都要用的通用能力,这样路由的那些专家就能腾出来专攻各自的细分领域。

激活参数 vs 总参数:一张表说清楚

这两个数字,是 2026 年看模型参数表时唯一真正要分清的事。它们决定了完全不同的东西:

看这张表,你能立刻得到一条很实用的判断:一个标成 “397B-A17B” 的模型,前面那个数(397B)是你买显存时要看的,后面那个数(17B)是你估推理速度时要看的。两者别搞混——这是 MoE 部署里最常见的认知错误。

它带来的实际效果是反直觉的:Qwen3.5 那个 35B-A3B 的 MoE 版本,占的显存远比 9B 的稠密版大(光权重就 21GB 对 5.8GB),但在同一张卡上,它的吞吐和首 token 延迟反而更好。显存占得多,但跑得快——因为速度只跟那 3B 激活参数有关。

天下没有白吃的午餐:MoE 的工程代价

讲到这你可能觉得 MoE 是纯赚的——同样的算力,能装下大得多的模型。但它把成本从"算力"转移到了别的地方,而且这些地方往往更难搞。

第一笔账:显存。 推理时虽然只算 8 个专家,但你不知道下一个 token 会路由到哪 8 个,所以全部 256 个专家的权重都得待在显存里。MoE 省的是算力,不是显存。Kimi K2 这种 1 万亿参数的模型,FP16 精度下光权重就要 2TB 量级的显存,只能靠多卡集群伺候。“激活参数小"绝不意味着"能在小显卡上跑”。

第二笔账:负载均衡。 路由器是学出来的,它会"偏心"。如果不管,训练到后面会出现"马太效应"——几个专家因为早期表现好,被路由器越选越多,练得越来越强;另一批专家几乎没 token 光顾,等于白养。极端情况下,你那个 256 专家的模型,实际只有几十个在干活,知识容量大打折扣。

早期的解法是加一个辅助损失(auxiliary loss),硬性惩罚"分配不均",逼路由器雨露均沾。但这个惩罚项会和"把 token 送给最对的专家"这个主目标打架,损害模型质量。DeepSeek V3 改用了一个无辅助损失的方案:给每个专家的路由打分加一个可调的偏置项,某个专家最近太忙就把它的偏置调低、太闲就调高——只动路由、不进损失函数。这个细节,正是 DeepSeek 那一代模型训练能又稳又便宜的关键之一。

第三笔账:部署复杂度。 专家太多,一张 GPU 装不下,得专家并行(expert parallelism)——把 256 个专家摊到几十张卡上。这下问题来了:一个 token 路由到的 8 个专家,可能散在 8 张不同的卡上,token 得先被发过去、算完再收回来。这种跨卡通信(all-to-all)是 MoE 推理的头号瓶颈,而且负载是动态的——这一批 token 可能全挤向某几张卡,那几张卡就成了堵点。稠密模型完全没有这套烦恼。

所以 MoE 不是"免费午餐",而是一笔用工程复杂度换计算效率的交易。它假设你有能力搞定多卡集群、搞定专家并行、搞定负载均衡。对个人开发者和小团队,在本地跑一个大 MoE,门槛其实比同等"能力档位"的稠密模型更高——因为卡在显存上。

为什么 2026 年几乎全是 MoE

把上面的账合起来算,结论就很清楚了。

到 2026 年,纯靠堆稠密参数这条路已经走到头:再大的稠密模型,推理成本高到没法规模化服务。而模型厂商面对的需求又是确定的——既要在榜单上有竞争力(要知识容量、要总参数),又要能用可接受的成本服务上亿用户(要推理便宜、要激活参数小)。

MoE 是目前唯一能同时满足这两头的架构。它让厂商可以理直气壮地把总参数推到万亿级,同时把激活参数压在二三十亿到五十亿这个"服务得起"的区间。DeepSeek、Qwen、Llama、Kimi、Mistral——这些团队各自独立地收敛到同一个设计,不是跟风,是因为约束条件相同,最优解也就相同。

但要泼一点冷水:MoE 不是没有代价的银弹。它把模型能力做大了,却把工程门槛也抬高了——显存、通信、负载均衡,每一样都需要专门的基础设施。它真正改变的,不是"模型能多强",而是"多强的模型能被服务得起"。 对 2026 年要做规模化部署的团队来说,这恰恰是最重要的那个问题。

参考来源:

• DeepSeek-V3 Technical Report (arXiv)
• DeepSeekMoE: Towards Ultimate Expert Specialization (arXiv)
• MoE Model Inference on GPU Cloud: Expert Parallelism, Memory, and Cost (2026) — Spheron
• LLM Landscape May 2026: DeepSeek V4 vs Qwen 3.5 vs Llama 4 — QubitTool
• A Review on Load Balancing Strategy in MoE LLMs — Hugging Face

三天后告警响了。某条响应里,LLM 在 JSON 后面多写了一句"希望这个分析对你有帮助!"。你的 json.loads() 当场抛异常,整条链路挂掉。

这不是小概率事件,是结构性问题。只要你还在用"自由文本里夹一段 JSON"的方式跟 LLM 要数据,这种崩溃就是迟早的——区别只是它发生在测试环境还是生产环境。

这篇讲清楚:为什么自由文本提 JSON 天生不可靠,2026 年有哪几种正经方案、各自的代价是什么,schema 怎么设计才不坑自己,以及最难的那块——流式场景下怎么拿到结构化数据。

为什么"让它输出 JSON"本身就是错的

先理解 LLM 在干什么。它做的是一件事:根据前面所有 token,预测下一个 token 的概率分布,然后采样。它没有“我现在要写一个合法 JSON"这种全局意识。

所以当你在 prompt 里写"请只返回 JSON,不要有多余文字”,你是在用一句话,对抗模型训练数据里成千上万条"先解释再给结果"的对话样本。大多数时候它听话,因为你的指令把概率压过去了。但只要某次采样,在该写 } 的位置,“希望"这个 token 的概率偶然爬到了第一,它就会写下去——而且一旦写下去,后面就会顺着"希望这个分析对你有帮助"这条最自然的路径滑下去。

常见的失败长这样:

• JSON 外面套了 ```json 代码块,或者前后有一段自然语言
• 字符串里有没转义的换行、引号
• 该是数字的字段写成了 "4.5"(带引号),或者写成 4.5分
• 嵌套对象少了一个括号,尤其是输出很长的时候
• 枚举字段返回了你没定义的值——你要 positive/negative/neutral,它给你个 mixed

这些都不是模型"笨”,是概率采样的必然结果。你不可能靠把 prompt 写得更恳切来根治它,你只能降低概率,没法归零。要归零,得换思路:不是请求它输出合法结构,而是从机制上让它没法输出不合法的结构。

五种方案,以及它们各自的代价

2026 年,从最弱到最强,实际可用的方案是这五种。关键不是"哪个最好",是搞清楚每个的边界。

flowchart TB
  A["LLM 要输出结构化数据"] --> B{"模型在哪?"}
  B -->|"闭源 API"| C{"要不要 100% 保证 schema?"}
  B -->|"自己部署的开源模型"| D["约束解码
xgrammar / llguidance"]
  C -->|"要"| E["Structured Outputs / strict 工具"]
  C -->|"差不多就行"| F["JSON Mode（已是 legacy）"]
  E --> G["拿到必定合法的 JSON"]
  D --> G
  F --> H["只保证语法合法，schema 靠运气"]
  style E fill:#fde7c2,stroke:#e8b23c
  style D fill:#fde7c2,stroke:#e8b23c

1. 纯 prompt 约束。 就是开头那种"请只返回 JSON"。它的唯一价值是当作其他方案的补充——把字段含义、示例写清楚能提升内容质量。但别拿它当结构保证。如果你现在生产环境还在裸用这个,这篇文章后面的部分就是为你写的。

2. JSON Mode。 OpenAI 最早的尝试,response_format: {"type": "json_object"}。它保证一件事:输出是语法合法的 JSON——不会有代码块包裹,不会有多余文字,括号配对。但它不管 schema:字段名、字段类型、枚举值、必填项,一概不保证。所以你还是得做完整校验。2026 年它基本算 legacy 了,OpenAI 自己的文档也把它标成旧特性,纯 JSON Mode 在生产里早就没人用了。

3. 约束解码 / Grammar(constrained decoding)。 这是真正解决问题的机制,也是后面几种方案底层共用的东西。原理:在每一步采样时,根据"目前已经生成的部分 + 目标 schema",算出下一个 token 哪些是合法的,把所有非法 token 的概率直接屏蔽(mask 成负无穷),只在合法集合里采样。

举例:已经生成到 {"rating":,那么下一个 token 只能是数字、-、空格——模型这一步根本采样不到 " 或者字母。它不是"被劝住了",是那条路被物理封死了。

开源世界里这块 2026 年很成熟。xgrammar 是目前 vLLM、SGLang、TensorRT-LLM 的默认结构化生成后端,支持完整的上下文无关文法(JSON、正则、自定义 CFG),每 token 开销做到了 40 微秒以下,几乎不影响吞吐;llguidance 是另一个主力,OpenAI 2025 年公开说过自家实现的底层借鉴了它。早期的 outlines 用有限状态机思路,开了这个方向,但碰到递归 schema(比如树形结构、嵌套评论)会很吃力,编译能慢到几十秒甚至几分钟,递归类结构现在更推荐用 xgrammar、llguidance 这种 CFG 引擎。

4. Structured Outputs API。 这是闭源厂商把约束解码包装成的产品功能。OpenAI 的 response_format: {"type": "json_schema", strict: true} 就是它——你传一个 JSON Schema,模型底层用约束解码,输出必定符合 schema:每个必填字段都在、类型都对、枚举值都合法。可用模型是 gpt-4o-2024-08-06 之后的版本、GPT-4.1 全系、GPT-5 和 o 系列。2026 年它是数据抽取、Agent 场景的生产默认。

5. Function Calling / Tool Use。 你定义工具,带 input schema,模型返回一个符合 schema 的工具调用。本质上跟 Structured Outputs 是同一套约束解码机制,只是包装成了"调用工具"的语义。它适合两类场景:一是模型真的要去调外部 API;二是你给了多个工具让模型自己选(多 Agent、路由)。Anthropic 的 Claude 走的就是 tool use 这条路,且复杂嵌套 schema 下也很稳;Gemini 这边把 JSON 模式和结构化输出合并成了一个特性。

一句话总结取舍:

选型其实很简单:自己部署模型,上 xgrammar;用闭源 API 且只想要一段数据,用 Structured Outputs;用闭源 API 且模型要决策调哪个工具,用 Function Calling。剩下两个,知道它们存在就行。

schema 设计:决定成败的地方往往不是代码

很多人以为开了 Structured Outputs 就万事大吉了。不是。约束解码保证模型输出符合你的 schema,但如果你的 schema 设计得烂,模型会在"合法"的范围内给你垃圾。

几条我踩过坑后总结的硬规则:

用枚举,别用开放字符串。 情感字段写成 "sentiment": string 模型可能给你 非常正面、positive、POSITIVE 三种花样。写成 enum: ["positive", "negative", "neutral"],约束解码会保证它只能落在这三个里。能枚举的一律枚举。

给每个字段写 description。 schema 里的 description 不是注释,模型会读。"score" 含糊,"score: 1-5 整数,5 表示强烈推荐,严格保守打分" 就清楚得多。约束解码管类型,不管"打分准不准",后者靠 description。

注意 strict 模式的限制。 OpenAI 的 strict 模式有几条硬约束容易绊人:所有字段都必须列进 required(想要可选字段,得把类型写成联合类型带 null);不支持任意的 dict[str, Any],key 不确定的字典它接不了;日期时间得用 ISO 字符串表示。设计前先翻一遍文档的限制清单,别等运行时报错。

给模型一条"我不知道"的出路。 这条最容易被忽略。如果信息缺失,你又强迫模型必须填某个字段,约束解码会逼它编一个——它在合法 token 里硬凑,于是你拿到一个格式完美的幻觉。正确做法是显式留口子:加 confidence 字段,或者让关键字段可空,或者加一个 "status": ["ok", "insufficient_info"]。结构合法不等于内容可信,这是约束解码救不了你的部分。

别一次榨太多。 一个 schema 里塞二十个字段,还层层嵌套,模型质量会肉眼可见地掉。能拆成两次调用就拆。

出错了怎么兜底

上了 Structured Outputs,JSON 解析层面的错确实没了。但还有别的会出问题,得有兜底。

第一类,API 层面的失败:超时、限流、网络抖动。这跟结构化无关,但既然你依赖一个必定返回结构的接口,它一旦不返回,你的下游就断了。退避重试,该做做。

第二类,约束解码碰上 token 上限。约束解码保证"如果生成完成,结构一定合法",但它不保证一定能生成完成。如果 max_tokens 设小了,模型在一个深层嵌套里被强行截断,你拿到的是一段合法但不完整的 JSON。对策:嵌套深、字段多的 schema,把 max_tokens 给足;并且检查 finish reason 是不是 length,是的话当失败处理。

第三类,内容兜底——前面说的幻觉。schema 里留了 confidence 或 status,这里就要用上:低于阈值的结果不直接进库,转人工或走降级逻辑。

一个实战习惯:就算用了 Structured Outputs,落库前也做一次业务校验。 不是不信约束解码,是 schema 只能表达"类型和结构",表达不了"评分必须在 1 到 5 之间且这条订单的金额不能是负数"这种业务约束。两层防线:schema 管结构,代码管语义。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# 闭源 API:Structured Outputs 保证结构,代码补业务校验
resp = client.chat.completions.create(
    model="gpt-4.1",
    messages=[...],
    response_format={
        "type": "json_schema",
        "json_schema": {"name": "review", "strict": True, "schema": SCHEMA},
    },
    max_tokens=800,
)
if resp.choices[0].finish_reason == "length":
    raise TruncatedError("被 token 上限截断,当失败重试")

data = json.loads(resp.choices[0].message.content)  # 这里几乎不会再抛
validate_business_rules(data)  # 评分范围、字段间一致性等,schema 管不到

流式场景:最难啃的一块

到这里都还好。真正难的是这个:你要流式输出,同时要结构化数据。

比如一个 UI,要边生成边把解析结果填进表单——名字一出来就显示名字,地址一出来就显示地址。但 LLM 是一个 token 一个 token 吐的,而 JSON 的任何中间状态都是语法非法的:

flowchart LR
  T1["{"] --> T2["{\"name\""] --> T3["{\"name\":\"张"] --> T4["{\"name\":\"张三\"}"]
  T1 -.->|"json.loads"| X1["报错"]
  T2 -.->|"json.loads"| X2["报错"]
  T3 -.->|"json.loads"| X3["报错"]
  T4 -.->|"json.loads"| OK["成功"]
  style X1 fill:#f8d7da,stroke:#c33
  style X2 fill:#f8d7da,stroke:#c33
  style X3 fill:#f8d7da,stroke:#c33
  style OK fill:#d4edda,stroke:#3a3

你不能等整段 JSON 攒齐——那就退化成非流式,流式的意义没了。也不能拿 json.loads() 去解每个中间态——它每次都抛异常。

可行的有两条路:

一是分隔符切块。 别要一个大 JSON,让模型按 JSON Lines 输出——每行一个独立的小对象,中间用换行分隔。每收到一个完整换行,就解析这一行。这等于把"一个大结构"拆成"很多个小结构",每个小结构一旦完整就立刻可用。简单、稳,适合"一批结果"型的输出。

二是容错增量解析。 用一个能处理残缺 JSON 的解析器,把每个中间态尽力补全成一个带类型的部分对象——{"name":"张 直接解析成 {name: "张"},字段还没出现的就当缺失。这条路上 2026 年比较成熟的是 BAML 这类工具,它内置了一个容错 parser,专门把破碎的部分 JSON 实时转成带类型的对象,既保住流式的体验,又拿到渐进的结构化数据。

选哪条:输出是"一组同类项",用 JSON Lines;输出是"一个有很多字段的大对象",且 UI 要逐字段渐进填充,用容错增量解析。

还有个常被忽略的点:流式 + 约束解码可以同时用。约束解码是逐 token 工作的,本来就和流式天然兼容——vLLM 这类引擎流式吐 token 的同时,xgrammar 在每一步做 mask。所以"用了约束解码就不能流式"是个误解,两者是正交的。难的从来不是生成端,是消费端怎么解析这些中间态。

最后:把它当工程问题,别当 prompt 问题

如果只留一句话:结构化输出的可靠性,不该靠 prompt 写得好,该靠机制保证。

很多团队卡在"再调调 prompt 让它别输出多余文字"。这是把一个工程问题误当成了文案问题。prompt 能把失败率从 5% 压到 0.5%,但压不到 0;而约束解码这类机制能压到 0。你的优先级应该是:

1. 先换机制——自部署上 xgrammar,用 API 上 Structured Outputs 或 Function Calling。这一步把"JSON 语法错"和"schema 不符"两类问题直接归零,收益最大。
2. 再认真设计 schema——枚举、description、给"不知道"留出路。约束解码管不到的内容质量,靠这一步。
3. 最后补业务校验和流式兜底——schema 管结构,代码管语义;流式场景按数据形态选 JSON Lines 或容错解析。

机制定了下限,prompt 和 schema 决定上限。顺序别搞反。

参考: OpenAI Structured Outputs 文档、 Introducing Structured Outputs in the API、 xgrammar、 llguidance、 Structured Outputs in vLLM、 Streaming structured data from LLMs is harder than you think、 When should I use function calling, structured outputs or JSON mode

假设你的 Agent 有一段 4000 token 的 system prompt:角色设定、工具说明、几个 few-shot 例子,雷打不动。用户每轮真正输入的,可能就 30 个字。一天 10 万次请求,这 4000 token × 10 万,就是 4 亿个 token 反复进入模型做同一件事——把固定前缀重新算一遍。

这部分计算,90% 是白烧的。因为前缀一模一样,模型每次算出来的中间结果(KV cache)也一模一样。Prompt caching 就是把这份中间结果存下来,下次直接复用。 它不改你的代码逻辑,不动模型质量,却能把输入侧成本砍掉一大半,顺带把首 token 延迟压下去。

2026 年,它依然是被严重低估的省钱手段。不是因为难,恰恰是因为太简单——简单到大家以为"开了就行",结果断点放错位置,缓存全程没命中,白付一笔写入费还不自知。

它到底缓存了什么

要用对,先得知道模型推理分两个阶段。

Prefill(预填充):把你的整段 prompt 一次性喂进模型,逐 token 算出每一层的 KV(key/value)向量。这一步是并行的、算力密集的,prompt 越长越慢。

Decode(解码):基于 prefill 的结果,一个一个吐出回答 token。

Prompt caching 缓存的,就是 prefill 阶段算出来的那份 KV。注意:它缓存的是前缀,不是"整个 prompt"。模型从第一个 token 开始,一段一段比对——只要某个位置往前的内容和缓存里的完全一致,这段就能复用;一旦遇到第一个不一样的 token,从那里往后全部得重算。

flowchart LR
  A["请求 prompt"] --> B{"逐 token 比对前缀"}
  B -->|"前缀命中"| C["复用 KV
(便宜 + 快)"]
  B -->|"遇到第一个差异"| D["从这里往后重新 prefill"]
  C --> D
  D --> E["Decode 出 token"]

这张图就是 prompt caching 的全部精髓。所有的"怎么用对",归结成一句话:让不变的东西待在前面,让变化的东西待在后面。

为什么前缀的顺序决定一切

各家请求体的拼接顺序是固定的:tools(工具定义)→ system(系统提示)→ messages(对话历史)。模型按这个顺序拼成一条长 prefix,再从头比对。

这意味着排在越前面的内容,越"值钱"——它一旦变化,后面所有东西的缓存全部作废。所以一个合格的可缓存 prompt,结构应该长这样,从稳定到易变排列:

最常见的翻车,是把"变化的东西塞进了前面"。比如有人喜欢在 system prompt 顶部写一句 当前时间:2026-05-05 11:23:07。看着无害,实际是灾难——这个时间戳每秒都不一样,等于把整条 prefix 的第一个字就改了,后面 4000 token 的缓存全程一次都命中不了。同类的坑还有:user ID、请求 UUID、A/B 实验分组标记、随机打乱的 few-shot 顺序。

如果你确实需要给模型当前时间,把它放到对话消息的最后,跟用户输入待在一起。前面那一大坨稳定前缀,该缓存照样缓存。

缓存断点放哪:自动 vs 手动

这里是各家最大的分歧,也是最容易用错的地方。

自动派(OpenAI、Google 隐式缓存、DeepSeek):你什么都不用做。系统自动识别请求之间的公共前缀,命中了就给你折扣。OpenAI 对超过 1024 token 的 prompt 自动启用;DeepSeek 是后端自动复用磁盘上的前缀缓存;Gemini 2.5 及以后的模型默认开启隐式缓存。

自动派的好处是零成本接入,坏处是没有保证。命中是"尽力而为"的——Google 自己也写明,隐式缓存只在系统判定命中时才给折扣,你无法强制。

手动派(Anthropic,以及 Gemini 的显式缓存):你得自己在 prompt 里打一个 cache_control 标记,告诉模型"缓存到这里为止"。这个标记叫缓存断点(cache breakpoint)。Anthropic 一个请求最多打 4 个断点。

手动派麻烦一点,但换来确定性:你明确知道哪一段被缓存了。

手动派最经典的错误,是把断点打在了会变的块上。比如这样的结构——一大段静态知识库,后面跟一个"包含时间戳 + 用户输入"的块,然后断点打在最后这个块上。结果时间戳每次都变,这个块的 hash 每次都不同,缓存永远写入、永远读不到。

正确做法:断点打在「最后一个跨请求不变」的块的末尾,而不是打在变化的块上。把静态前缀和动态后缀切开,断点卡在它们的交界处。

flowchart TB
  subgraph 错误["错误:断点在变化块上"]
    A1["静态知识库 8000 token"] --> A2["时间戳 + 用户输入 ⟵ 断点"]
  end
  subgraph 正确["正确:断点在静态前缀末尾"]
    B1["静态知识库 8000 token ⟵ 断点"] --> B2["时间戳 + 用户输入"]
  end

还有一个多轮对话特有的坑:对话越滚越长,你的断点可能被挤到"上一次写入位置"20 多个块之外,超出回溯窗口,于是又一次踩空。多轮场景里,务必随着对话增长滚动更新断点位置,让它始终贴着最新的稳定边界。

四家的计费和 TTL,差得不小

省多少、贵多少、能存多久——各家规则不一样,接之前一定要看清。

几个要点单独拎出来说。

Anthropic 是唯一对"写入"收钱的。 写一次缓存比正常输入贵 25%(5 分钟档)。这意味着如果你的 prompt 写进去之后根本没被复用就过期了,你是净亏的——多付了 25%,一分钱折扣没拿到。所以 Anthropic 的缓存只对"高频复用同一前缀"的场景划算。读取确实便宜,只要 1/10 输入价。

TTL 是个隐形雷区。 Anthropic 默认 TTL 在 2026 年初从 1 小时悄悄变回了 5 分钟,不少团队因此缓存创建成本涨了 20%~30% 还没察觉。5 分钟意味着:如果你的请求间隔超过 5 分钟,缓存早凉了,每次都是冷启动重新写入。好消息是 TTL 的时钟会在每次命中时重置——只要请求够密,缓存能一直续命。需要长间隔复用的,Anthropic 可以花 2 倍写入价买 1 小时 TTL。

OpenAI 和 DeepSeek 对开发者最省心:不收写入费,自动命中,几乎是"白送的折扣"。DeepSeek 2026 年 4 月把 cache hit 价格再砍到发布价的 1/10,V4-Flash 上缓存命中把输入成本从 $0.14 压到 $0.0028 每百万 token——98% 的降幅。

省钱幅度的体感:输入侧能省 50%~90%。具体看你的 prompt 里"固定前缀占比"有多高——前缀越长、变量越短,省得越狠。一个 8000 token 知识库 + 50 token 提问的 RAG 应用,几乎是为 prompt caching 量身定做的。

别忘了它还能压延迟

省钱是它最出名的好处,但对实时类应用,降延迟才是关键收益。

命中缓存时,prefill 这一步被整段跳过。前面说过,prefill 是算力密集的,prompt 越长越慢。跳过它,首 token 延迟(TTFT)的下降立竿见影——DeepSeek 给过一个数据:128K 的长 prompt 高度命中缓存时,首 token 延迟从 13 秒压到 500 毫秒。

这对语音 Agent、实时对话这种"首 token 延迟就是及格线"的场景,意义比省钱大得多。一个挂着长 system prompt 和工具定义的语音助手,把这部分缓存住,等于每一轮对话都省掉了几千 token 的 prefill 时间。如果你正在为 TTFT 抠毫秒,prompt caching 应该排在优化清单的前列。

不过有个前提:省下来的延迟,得真的有缓存可命中。冷启动那一次(第一次写入)不但不快,Anthropic 那边还更慢更贵。所以 prompt caching 优化的是"稳态延迟",不是"首次延迟"。

一份排查清单:为什么我没命中

如果你接了 prompt caching,但账单没怎么降,大概率是踩了下面某一条。按顺序自查:

1. 前缀里有变量。 时间戳、UUID、user ID、随机数——但凡有一个混进了 system prompt 或工具定义,整条缓存作废。把它们全部赶到 messages 末尾。

2. 断点打错位置(手动派)。 断点要打在"最后一个不变块"的末尾,不是打在变化块上。切开静态与动态的交界。

3. 请求间隔超了 TTL。 Anthropic 默认才 5 分钟。低频请求(比如定时任务、长间隔轮询)很可能每次都冷启动。要么提高请求密度,要么买长 TTL。

4. prompt 太短没够门槛。 OpenAI 要超过 1024 token 才会自动缓存。短 prompt 本来也省不了多少,不用纠结。

5. 工具定义或 system prompt 偷偷变了。 多人协作时,有人调了一下工具描述、改了个标点,排在最前面的 tools 段一变,后面全塌。把可缓存前缀当成发布制品来管理,别让它随手改。

6. few-shot 例子顺序不固定。 有些代码每次随机打乱 few-shot 顺序"增加多样性"——这会让前缀每次都不同。要缓存,就固定顺序。

落地建议

不用一上来就上复杂方案。三步走:

第一步,把 prompt 重新排版。 不管你用哪家,先按"工具 → system → 知识库 → 用户输入"从稳到变重排一遍,把所有变量揪到最后。光这一步,自动派(OpenAI / DeepSeek / Gemini)就能开始命中了,一行代码没动。

第二步,手动派打好断点。 用 Anthropic,就在静态前缀末尾打 cache_control;多轮对话记得滚动更新断点。

第三步,盯住命中率。 各家 API 响应里都会返回 cache 相关字段(命中 token 数、写入 token 数)。把"缓存读取 token / 总输入 token"做成一个监控指标。它要是长期偏低,回到上面那份清单逐条查。

最后提醒一句取舍:prompt caching 不是"开了就一定赚"。对 Anthropic 这种收写入费的厂商,低频、前缀短、变量多的场景,反而可能亏。先搞清楚自己的流量形态——高频复用同一份长前缀,才是它的主场。判断对了,这是你能拿到的、性价比最高的一次优化:不掉质量,不改逻辑,省一半成本,还顺手降了延迟。

参考资料:

• Prompt caching - Claude API Docs
• Cache TTL silently regressed from 1h to 5m · Issue #46829
• Prompt Caching in the API | OpenAI
• Prompt caching | OpenAI API
• Context caching overview | Google Cloud
• Gemini 2.5 Models now support implicit caching - Google Developers Blog
• DeepSeek API introduces Context Caching on Disk

2026 年 4 月 24 日,DeepSeek 把 V4-Pro 的权重直接挂上了 Hugging Face,1.6 万亿参数,MIT 许可证,1M 上下文。它在编程基准上的得分,跟当月最强的几个闭源旗舰之间,差的不是一个段位,是几个百分点。

这件事的信号比"又一个新模型"大得多。它意味着:当你今天选开源,你放弃的不再是能力,而是别的东西。 这篇就来复盘开放权重这一年的格局——谁在领跑、中国开源为什么这么猛、剩下的那点差距到底在哪、许可证这个没人爱看的细节怎么反而成了关键,以及开源那套微调量化部署的生态,现在到底成不成熟。

需要先说清一个词。这篇说的"开源",严格讲是开放权重(open weights):权重能下载、能自己跑、能商用。它和教科书意义上的开源软件不是一回事——绝大多数模型不公开训练数据、不公开训练代码,你拿到的是一个能跑的成品,不是一份能复现的菜谱。后面我还是用"开源"这个习惯叫法,但你心里得清楚,这是个有水分的词。

领跑的三家,其实是三种活法

把 2026 年 5 月的开放权重阵营摊开看,DeepSeek、Qwen、Llama 这三个名字最响,但他们根本不在同一条赛道上。

这张表里我最想让你看的是最后一列。三家头部各自押的东西完全不同:DeepSeek 押"能力对标 + 许可证无摩擦",Qwen 押"尺寸谱系最全",Llama 押"我已经在几十亿设备和无数教程里了"。

DeepSeek 这一年是最猛的。V4 那套混合注意力——把小块 token 压成摘要、新 token 只挑最相关的摘要去看——让 1M 上下文从"标在参数表里的可选项"变成了默认就开的标配。更狠的是它的定位:V4-Pro 不装"小而美",它就是冲着替代闭源旗舰来的,而且配一张 MIT 许可证。MoE 架构让它"总参 1.6T 听着吓人、实际每个 token 只激活 49B",于是这么大的模型,真有团队能在自己的卡上把它跑起来。

Qwen 走的是另一条路:不赌单个旗舰多猛,赌谱系。3.6 系列铺了六档尺寸,从能塞进手机的小模型,到要集群伺候的大模型,外加 3.6-VL 管视觉、Omni 档把音视频也收进同一套架构。它的杀手锏是多语言——连着两代,Qwen 都是中文和小语种覆盖最好的开放模型,没有之一。对一个要做出海、要做多语言产品的团队,这个"全家桶"的吸引力,比榜单上多两个点实在得多。

Llama 现在的位置有点微妙。它仍然是全世界装机量最大的开放权重生态——绝大多数教程、工具链、社区问答默认拿 Llama 举例,这个惯性是真实的资产。但 2026 年 4 月,Meta 发了个叫 Muse Spark 的闭源模型,出自它的超级智能实验室。这个动作基本宣告了"Llama 当旗舰"的时代结束:Meta 把最强的牌收回了闭源的口袋,Llama 4 更像是守着存量生态的那张牌,而不是冲锋的那张。

领跑名单上,为什么大半是中文名字

把今天的开放权重第一梯队列出来——DeepSeek V4、Qwen 3.6、Kimi K2.6、GLM-5——你会发现一个不太能忽略的事实:领跑的大部分是中国实验室。在第三方基准上,DeepSeek V4-Pro 已经能摸到顶级闭源模型的边,跟 GPT-5 系列的差距是一两个点的量级。

这不是巧合,是一条清晰的策略分叉。

美国的前沿实验室,主力打法是闭源 API。 OpenAI、Anthropic、Google 把最强的模型锁在 API 后面卖订阅、卖调用量,这是他们的商业模式核心。开源对他们是副业,甚至是会侵蚀主营收入的事——所以他们要么不开,要么开个上一代的、缩水的版本意思一下。Meta 曾经是个例外,用 Llama 撑开源大旗,但 Muse Spark 一出,这个例外也在收口。

中国实验室的处境正好相反,于是开源成了最优解。 一来,在闭源订阅这条路上,品牌、渠道、先发优势都被美国大厂占住了,正面硬刚很难;开放权重是一条能绕开这堵墙、快速建立全球开发者心智的路。二来,把权重开出去,等于把全世界的开发者变成免费的测试者、布道者和生态贡献者——你在 Hugging Face 上每多一次下载,就多一分行业默认值的分量。三来,这里面有很现实的国际环境因素:开放权重让海外用户可以自己下载、自己部署,不依赖某一家公司的在线服务,这种"可自主掌控"本身就是卖点。

所以中国开源的强势,根子不在"中国工程师更聪明",而在商业模式的逼迫——闭源那条路被堵了一截,开源反而成了能赢的那条路。理解这点很重要,因为它说明这个格局是结构性的、会持续的,不是某一个季度的榜单波动。

一个推论:别把"开源"和"中国"画等号,但你也得承认,2026 年你做开源选型,候选名单上大概率一半以上是中国实验室的模型。这是现实,接受它,然后回到工程问题本身。

差距还剩多少:几个点,但不是均匀分布的几个点

“开源追上闭源了吗”——这个问题问得太粗。正确的问法是:在哪类任务上追上了,在哪类还没。

笼统地说,2026 年开放权重的天花板,跟闭源旗舰的差距是单个 benchmark 上几个百分点的量级。两年前那种"差一代"的体感没有了。但这几个点不是均匀摊开的,它在不同任务上厚薄差很多。

• 知识问答、摘要、改写、翻译——基本追平,很多场景里你盲测分不出来。这些任务对"最后那点智商"不敏感,开源模型在这里就是够用。
• 代码——很近但还没平。DeepSeek V4-Pro 在 SWE-bench 这类编程基准上能进顶级行列,日常写函数、改 bug,体验和闭源旗舰差不多。差距在最难的那一档:大型重构、跨文件的复杂改动,闭源旗舰还稳一点。
• 长链路 Agent——这是缺口最明显的地方。一个 Agent 要连着做二三十步,每步的小误差会累积,中间判断一次失误后面全废。在这种"误差不能累积"的场景里,闭源旗舰多出来的那几个点会被链路放大成"能跑通"和"跑不通"的差别。如果你的产品核心是复杂 Agent,这个差距值得你认真对待。

flowchart LR
  A[任务类型] --> B[问答 / 摘要 / 翻译]
  A --> C[日常代码]
  A --> D[难代码 / 大重构]
  A --> E[长链路 Agent]
  B --> B1[已追平
放心用开源]
  C --> C1[基本追平
开源够用]
  D --> D1[接近
闭源仍稳一点]
  E --> E1[差距最明显
闭源旗舰仍占优]
  style B1 fill:#d6f5d6,stroke:#5fb35f
  style C1 fill:#d6f5d6,stroke:#5fb35f
  style D1 fill:#fde7c2,stroke:#e8b23c
  style E1 fill:#fde7c2,stroke:#e8b23c

我的判断是:对今天 80% 以上的生产任务,开源的能力差距已经不该是你拒绝它的理由。 真正还需要为闭源那几个点掏钱的,是长链路 Agent 和最难的代码——而这恰好和我上一篇选型文章里说的"只有推理 Agent 任务真的需要旗舰"对上了。能力够不够,先按任务类型问,别按"开源还是闭源"这个标签笼统判。

许可证:没人爱看,但能直接判你出局

聊开源模型,大家都盯着 benchmark,几乎没人认真读许可证。这是个错误——许可证决定的不是它强不强,而是你到底能不能用。 一个跑分爆表但许可证不让你这么用的模型,对你来说等于零分。

2026 年开放权重的许可证,大致分两类。

一类是真·宽松许可证:MIT、Apache 2.0。DeepSeek V4 是 MIT,Qwen 的开放档是 Apache 2.0,Mistral 的 Large 3、Small 4 也是 Apache 2.0。这类许可证的意思朴素到几乎没有惊喜:随便商用、随便改、随便闭源分发,不看你用户量多少,不附加奇怪条件。对企业法务来说,这是最省心的一类——基本不用开会。

另一类是带条件的"社区许可证",典型是 Llama 4 社区许可。它对绝大多数人是免费可商用的,但藏着两颗你必须知道的雷:

1. 用户量超过 7 亿月活,要单独找 Meta 谈授权。 对大厂和超级 App 来说这是真实的约束。
2. 欧盟。 截至 2026 年初,Llama 4 的许可证不向欧盟注册的公司开放。如果你的公司在欧洲,这一条直接把 Llama 4 从你的候选名单里划掉——不是"麻烦一点",是"不能用"。

还有更小众的坑:Mistral 的 Leanstral 用的是 CC BY-NC,NC 就是 non-commercial,不能商用。这种你拿来做个 demo、写篇博客没问题,一旦进生产就是合规事故。

所以选开源模型,许可证这一步要前置。我的习惯是:先问许可证,再看 benchmark。 顺序反了,你可能比了三天性价比,最后发现这个模型你公司根本不能用。一句话总结这一节——想省心,优先 MIT / Apache 2.0;碰到"社区许可证",法务必须读一遍正文,尤其你在欧盟、或者你是个大厂。

什么时候开源真的更划算

能力追平了、许可证也看清了,接下来是那个真问题:到底什么场景该上开源? 我给三个判据,满足任意一个,开源就值得认真考虑;一个都不满足,老实用闭源 API。

第一,数据不能出门。 病历、银行流水、没公开的财报、核心代码——这类数据有法律和信任的红线,不能发给外部 API。这种情况下你没得选,只能把权重下载下来,跑在自己的 VPC 或机房里。这时候"某个闭源模型更强"是句正确的废话,因为它压根不在你的候选集里。这是开源最硬的理由,和省钱无关。

第二,调用量大到自建的边际成本能打过 API。 闭源 API 是按 token 付费,用得越多账单越线性地涨。自建推理是一笔固定的前期投入(GPU、运维、扩缩容),之后边际成本很低。存在一个交叉点:量小的时候 API 划算,量大到某个程度,自建的总成本反超。一个每天几千万次调用、且任务相对固定的场景,自建开源模型常常能比闭源 API 便宜一大截。但要诚实——自建不等于省钱。算上 GPU 采购或租赁、运维人力、安全加固,量不够大的时候它比 API 更贵。别因为"感觉自己掌控更踏实"就去自建,那是给自己挖坑。

第三,你要做深度微调。 你想让模型长出你这个领域的知识、你这家公司的话术、你的私有数据训出来的判断——这件事在闭源 API 上要么做不了,要么很受限。开放权重你能做全参微调、LoRA、继续预训练,想怎么改怎么改。如果"领域定制"是你产品的核心壁垒,开源几乎是唯一选项。

反过来说，如果你是个从 0 到 1 的产品,量还没起来,数据也没有合规红线,又不需要深度定制——别折腾,用闭源 API。 你的精力该花在产品上,不是花在伺候一个推理集群上。开源在这种阶段提供的"掌控感"是一种心理安慰,代价是真金白银的运维成本。

但有一点,即使你主力用闭源,也值得在开源上留一手:开源是一份保险。 用闭源 API,你绑定了对方的定价、限流、模型下线节奏——它说某个版本退役,你就得连夜迁。手里捏着一个能自己跑的开源模型作为备份,是对供应商风险最便宜的对冲。

生态:模型只是开头,能不能跑起来看工具链

开源大模型真正成熟的标志,不是又出了个跑分更高的模型,而是围着它的那套工具链已经好用到让自建不再是苦差事。 2026 年,这套生态确实补齐了。

部署推理。 vLLM 仍然是事实标准,生态最厚——观测工具、各种集成、社区问答,出了问题大概率能搜到答案。SGLang 这两年追得很猛,在不少高并发、多轮对话的负载上吞吐已经反超 vLLM。成熟团队现在的常见做法是:默认用 vLLM,对那些高流量的多轮端点单独拿 SGLang 压一遍测试,流量特别大的关键模型才上 TensorRT-LLM。换句话说,“开源模型怎么高效跑起来"这个问题,2026 年已经有成熟的标准答案,不再需要你自己趟。

量化。 这是降低部署门槛最关键的一环。主流开源模型现在发布即附带官方量化版本——FP8、INT4、INT8、GPTQ、AWQ、GGUF,基本你想要的格式都有。在 H100、B200 这类带原生 FP8 张量核的卡上,FP8 量化几乎是"免费的"好处:显存砍一半,吞吐还能涨,精度损失小到可忽略。量化的意义在于,它把"这个 1.6T 的大模型我的卡装不下"这个硬门槛,变成了"装得下,而且跑得不慢”。

微调。 LoRA、QLoRA 这套已经是成熟基建,在消费级或单张数据中心卡上微调一个中等模型,门槛低到个人开发者都能上手。生态里现成的微调框架、数据处理工具一大堆,不用从零搭。

把这三块连起来看:

flowchart LR
  A[下载开放权重
HF / ModelScope] --> B[量化
FP8 / INT4 / GGUF]
  B --> C[微调
LoRA / QLoRA / 全参]
  C --> D[部署推理
vLLM / SGLang / TensorRT-LLM]
  D --> E[上生产]
  style A fill:#fde7c2,stroke:#e8b23c
  style E fill:#d6f5d6,stroke:#5fb35f

这条链路上的每一环,2026 年都有打磨得很顺手的开源工具。这才是开放权重阵营这一年最被低估的进展——不是模型本身变强了多少,而是"把一个开源模型真正跑进生产"这件事,从一个需要专门团队啃的硬骨头,变成了一条有标准答案的成熟流程。 模型再强,跑不起来也是零;生态补齐了,开源才算真的能用。

最后

复盘开放权重这一年,我会这么总结:

能力上,开源和闭源的差距收敛到了几个点,而且这几个点集中在长链路 Agent 和最难的代码这两块——对大多数生产任务,能力已经不该是你拒绝开源的理由。

格局上,领跑的大半是中国实验室,DeepSeek 用"前沿能力 + MIT"做闭源平替,Qwen 用全尺寸谱系做开发者底座,Llama 守着最大的存量生态但旗舰光环已经让给了 Meta 的闭源新模型。这个格局是商业模式逼出来的,结构性的,短期不会变。

决策上,选开源的理由就三个——数据不能出门、量大到自建更便宜、要深度微调。三个都不沾,就用闭源 API,别给自己找运维的麻烦。而真要选开源,先读许可证再看跑分:MIT / Apache 2.0 省心,“社区许可证"必须让法务过一遍,你在欧盟尤其要当心 Llama 那条款。

两年前选开源,你是在能力上做妥协。2026 年不一样了——开源不再是"省钱的次选”,它是一个关于控制权的主动选择。你放弃的不是聪明,是省心;你换来的是数据的掌控、成本的结构、定制的自由。这笔账划不划算,取决于你的场景,不取决于榜单第一名是谁。

但你有没有验证过——它引用的那段需求,是真的从文档第 40 万字的位置取出来的,还是它顺着上下文的语气编了一段听起来很对的话?

这是 2026 年长上下文最尴尬的地方:“放得进"是确定的,“用得好"是不确定的,而大多数人只测了前者。 模型厂商标 1M、2M,你看到的是窗口大小;你真正需要的是这个窗口里有多少 token 是"模型会认真看"的。这两个数字,差得比你想的大。

标称上下文 vs 有效上下文

先把两个概念分清楚。

标称上下文(advertised context)是模型 API 允许你塞进去的最大 token 数,超了就报错。有效上下文(effective context)是模型在性能开始明显掉档之前,真正能可靠利用的 token 数。

RULER 这个 benchmark 当年就是为了量化这件事造出来的。它的结论很扎心:很多号称 32K+ 的模型,在 32K 长度下能维持及格表现的,只有一半。到了 2026 年,百万级窗口普及之后,这个差距并没有消失——多份独立测试给出的经验值是,有效上下文通常只有标称值的 60%~70%,而且性能下滑的方式,简单的 token 计数根本看不出来:漏检的内容、编造的细节、断掉的推理链。

把 2026 年几个主流模型的标称窗口和实测召回放在一起看:

注意 Gemini 1.5 Pro 这一行:它标 2M,是表里窗口最大的,但 1M 长度下的召回反而排在后面。窗口大小和有效质量,不是同一个排行榜。 标称 10M 的 Llama 4 Scout 也一样,过了 1M 之后衰减得很明显,适合做的是"检索式"任务,不是"全局理解"任务。

所以下次看到发布会上"业界最长 2M 上下文"的字样,你心里应该自动换算:能放 2M,能用好的可能就 1.2M 上下。剩下那 80 万 token,是放进去给你心理安慰的。

Lost in the middle:模型其实在"跳读”

为什么有效上下文会缩水?最经典的一个原因叫 lost in the middle。

2023 年那篇同名论文做了个很干净的实验:把同一条关键信息(needle)放在长文档的不同位置,看模型能不能答对。结果画出来是一条 U 形曲线——信息放在开头或结尾,模型答得很好;放在中间,准确率断崖式下跌。

说人话就是:模型读长文档的方式,和一个赶时间的人翻书很像——认真看了前言和结论,中间几百页基本是扫过去的。

这背后是注意力的问题。有研究把它归因为"注意力稀释”:context 越长,softmax 要把有限的注意力权重摊到越多的 token 上,每个 token 分到的"关注"就越薄。再叠加位置编码带来的偏置,中间段就成了被冷落的区域。有些极端的测量甚至说,某些前沿模型的有效注意力区间,比标称窗口短了高达 99%。

要补充一句公平话:这事在 2026 年比 2023 年好了不少。 像 Gemini 2.5 Flash 这种,做简单的事实型问答(needle-in-a-haystack)时,不管 needle 放在哪个位置,基本都能答对——简单检索上的 lost in the middle 已经被很大程度上修掉了。

但别高兴太早。needle 测试本身有个大问题:它太简单了。最近的研究(《Lost in the Haystack》)发现,needle 越小、越像"一行字",越好找;一旦你要找的"目标内容"本身是一大段、需要跨段落拼起来的,定位难度立刻上去。 真实业务里,你要模型做的从来不是"找一句话",而是"把分散在第 3、19、56 章的三处约束综合起来判断"。这种多跳、聚合类的任务,才是中间段塌方的重灾区。needle 测试绿灯,不代表你的任务绿灯。

成本和延迟:长上下文是按复利收费的

就算质量没问题,还有一笔账要算:钱和时间。

标准 self-attention 是 O(n²) 的。这个 n 是 token 数,平方意味着——prompt 翻一倍,attention 的计算量翻四倍。把 1M token 喂进一个标准 Transformer,光 attention 就是 1M × 1M 量级的矩阵运算,接近一万亿次操作。这笔账不是线性涨的,是带复利的。

最直接的体感是 TTFT(首 token 延迟)。模型要先把你的整个 prompt “读"一遍(prefill 阶段),才能吐第一个字。prefill 的耗时随上下文长度加速增长:从 4K 涨到 32K 你可能没什么感觉,从 32K 涨到 128K 就开始难受,而按观测到的幂律曲线(指数约 1.24)外推到 1M,第一个字出来可能要等 60~90 秒。

flowchart LR
  A[4K prompt
TTFT ~1s] --> B[32K prompt
TTFT 数秒]
  B --> C[128K prompt
TTFT 十几秒]
  C --> D[1M prompt
TTFT 60-90s]
  style C fill:#fde7c2,stroke:#e8b23c
  style D fill:#f5b7b1,stroke:#c0392b

对任何交互式产品,这都是致命的。我之前写语音 Agent 的延迟预算时讲过,用户回应超过 800ms 就觉得别扭——你拿一个 prefill 要等一分钟的长上下文方案去做对话,等于直接出局。长上下文是离线批处理的工具,不是实时对话的工具。

钱也一样。虽然到 2026 年部分厂商(比如 Anthropic 的 Opus 4.6 / Sonnet 4.6)取消了长上下文的 2 倍溢价,1M 窗口按标准价 GA,但每次调用你都为整个 prompt 的所有 token 付费。一个 80 万 token 的上下文,你每问一句,这 80 万 token 就重新计一次费。一天问一百次,就是八千万 input token。多轮对话场景下,这个数字会失控。

更隐蔽的是 GPU 内存。多百万 token 的输入,KV cache 能吃掉 80%~90% 的显存。这意味着同样的硬件,长上下文请求能并发的数量大幅下降,单位成本进一步被推高——这部分不一定体现在 API 标价里,但会体现在你自建推理时的账单上。

什么任务真的需要超长上下文

讲了这么多问题,不是说长上下文没用。是说它被滥用了。

很多人把长上下文当成 RAG 的"平替”——“既然能塞进去,我干嘛还搭检索系统”。这个判断在大多数场景是错的。把无关内容大量塞进 context,不只是浪费钱,还会主动加重注意力稀释,把真正相关的那几千 token 淹掉。给模型的信息越精准,它表现越好;喂得越多越杂,反而越差。

那什么任务是长上下文真正不可替代的?我的判断是,符合下面特征的:

• 需要全局视野,且无法预先切片检索。 比如让模型审一份 60 万字的合同,找出所有相互矛盾的条款。你没法提前知道哪两条会冲突,RAG 切片检索这时候帮不上忙——它本质上是个 N×N 的全局比对。
• 跨度大、上下文强耦合的代码理解。 让模型理解一个几十万行的代码库的某个改动会牵连到哪里。调用关系是网状的,切片会切断它。
• 长链多跳推理。 一份侦探小说式的材料,线索分散在几十处,需要全部在场才能推出结论。检索 top-k 很容易漏掉那个"看起来不相关但其实是关键"的片段。
• 多模态长素材。 一段两小时的视频、一本带大量图表的书,本身就是一个不可切分的整体。

发现规律没有?这些都是"信息之间有强关联、无法干净切分“的任务。反过来,如果你的任务是"从一堆文档里找出和问题相关的那部分再回答”——那是检索任务,老老实实用 RAG,又快又便宜又准。长上下文和 RAG 不是谁取代谁,是分工:能切就检索,不能切才全塞。

怎么实测一个模型的长上下文质量

最后给点能落地的。别信发布会,自己测。一个最小可行的验证流程:

flowchart TD
  A[用你自己的真实长文档] --> B[在不同深度埋入可验证事实]
  B --> C[深度: 10% / 30% / 50% / 70% / 90%]
  C --> D[长度档: 32K / 128K / 256K / 1M]
  D --> E[每格跑多次取准确率]
  E --> F[画热力图: 深度 x 长度]
  F --> G{中间段是否塌方?}
  G -->|是| H[砍到有效长度内使用]
  G -->|否| I[再上多跳/聚合任务复测]

几个关键点:

第一,用你自己的文档,别用公开 benchmark 的语料。 主流模型很可能在训练时见过 RULER、LongBench 这些数据,刷分会虚高。拿你业务里真实的合同、文档、代码去埋点,测出来的才作数。

第二,测两类任务,别只测 needle。 needle 检索(找一句话)和多跳聚合(综合好几处信息推结论)要分开测。前者现在大多数模型都能过,后者才是真正区分模型的地方。只测 needle 你会得到一个过于乐观的结论。

第三,把"深度 × 长度"做成热力图。 横轴是上下文总长度,纵轴是关键信息埋入的相对位置(10%、30%、50%、70%、90%)。每个格子跑十几次取准确率。这张图一画出来,模型在哪个长度档开始掉、中间段塌不塌,一目了然。你的"有效上下文"就是这张图上还保持绿色的那个区间。

第四,把延迟和成本一起记进表。 不只记准不准,把每个长度档的 TTFT 和单次调用费用也记下来。很多时候你会发现,128K 档的质量和 1M 档差不了几个百分点,但延迟和成本差了一个数量级——那 1M 就没有用的必要。

我的总结很简单:百万级上下文是个真实的能力,但它的有效区间,要靠你自己量出来,而不是读厂商的标称值。 把整本书塞进去之前,先问自己两件事——这个任务真的不能切片吗?我验证过模型在这个长度下中间段不塌方吗?这两个问题答不上来,那个 1M 窗口,大概率只是个让你安心的数字。

参考资料:

• RULER: What’s the Real Context Size of Your Long-Context Language Models?
• Lost in the Middle: How Language Models Use Long Contexts
• Lost in the Haystack: Smaller Needles are More Difficult for LLMs to Find
• 1M Token Context Reality Check 2026: Gemini vs Claude Latency
• Long-Context Inference at Scale: The Hidden Infrastructure Cost
• The Prefill Bottleneck Problem

这个数字有意思的地方在于:它比 QwQ-32B-Preview 还高。一个 7B 的小模型,在硬核推理题上,打过了一个参数量是它四倍多的模型。

更反常识的是后面这句——DeepSeek 自己说的:直接拿强化学习去训练那个 7B 小模型,效果还不如蒸馏。小模型自己练,练不出这种推理能力;但你拿一个 671B 的大模型当老师,把它的思考过程喂给小模型学,小模型就学会了。

这就是蒸馏。它不是模型压缩里的某种玄学技巧,而是 2026 年几乎每家做小模型的团队都在用的标准动作。这篇把它讲清楚:蒸馏到底搬走了什么,和微调是什么关系,能搬多少,做不到什么,以及一套能落地的流程。

为什么要蒸馏:质量和成本之间那道墙

先说动机。

大模型好用,但贵。一个 400B 参数的旗舰模型,推理延迟高、单次调用成本高、显存吃得狠,你不可能把它塞进每一台手机、每一个边缘设备、每一条高并发的客服管道。可小模型呢?便宜、快、能本地跑,但你直接拿一个 7B 模型出来用,它在复杂任务上的回答质量,和旗舰模型差着一大截。

这就是那道墙:质量在大模型这边,成本和延迟在小模型那边,你想两个都要。

传统的过墙办法有两种。一种是直接训练一个小模型——但小模型受参数量限制,见的数据再多,某些能力(尤其是多步推理)就是练不出来,这是容量天花板。另一种是把大模型剪枝、量化——这能省一点,但省不了数量级,而且剪过头质量就崩。

蒸馏是第三条路,也是目前性价比最高的一条:不让小模型自己悟,而是让大模型手把手教它。Meta 拿 Llama 4 Behemoth 去训 Llama 4 的 Scout 和 Maverick,Google 用 Gemini 去带 Gemma 2 和 Gemma 3,DeepSeek 用 R1 蒸出 1.5B 到 70B 一整个系列——2026 年你能叫得出名字的小模型,背后基本都站着一个大模型老师。

道理很朴素:让一个聪明人把题做一遍、把思路讲给你听,比你自己对着标准答案死磕,学得快得多。

蒸馏到底在传递什么

很多人对蒸馏的第一印象是"用大模型造点数据,拿去训小模型"。这个理解对了一半,但漏掉了最关键的东西。

蒸馏的精髓在于软标签(soft label)。

举个例子。你问模型"这句话情感是正面还是负面",一个普通的训练样本只会告诉小模型一个硬标签:正面。但大模型老师给出的不是一个字,而是一整个概率分布——比如"正面 0.82、负面 0.11、中性 0.07"。

这个分布里藏着硬标签给不了的信息:老师不光告诉你答案是什么,还告诉你它有多确定、它觉得别的选项有多接近。这种"模型对各种可能性的相对判断",业内叫暗知识(dark knowledge)。小模型学的不只是结论,是老师那套打分的体感。

技术上,这通常通过让学生去拟合老师的 logits(输出层的原始分数)来实现,用 KL 散度当损失函数,衡量学生分布和老师分布差了多远。这条路线效果最好,但有个前提:你得能拿到老师的 logits——也就是老师得是个"白盒"。

flowchart TB
  T[教师大模型] -->|完整概率分布
soft label| K[KL 散度损失]
  T -->|生成的答案 + 思维链
hard label| C[交叉熵损失]
  K --> S[学生小模型]
  C --> S
  S -->|采样自己的回答| V[教师/验证器打分]
  V -->|纠正学生的错误| S
  style T fill:#fde7c2,stroke:#e8b23c
  style S fill:#cfe8d8,stroke:#4ca877

如果老师是个只给你返回文字的 API(黑盒),你拿不到 logits,那就退而求其次:让老师大量生成完整的答案和推理过程,再拿这些文本当训练数据去教小模型。DeepSeek 蒸馏 R1 用的就是这条路——他们用 R1 生成了 80 万条样本,然后纯靠监督微调(SFT)把这些样本喂给 Qwen 和 Llama,连强化学习都没加。这条路拿不到暗知识,但胜在简单、不挑老师、谁的 API 都能蒸。

蒸馏和微调,到底什么关系

这是最容易绕晕的一个点,我直接给结论:蒸馏和微调不是对立的,蒸馏的落地往往就是一次微调,只是数据来源不同。

把它们放一起看:

看出来了:微调是"怎么训"的问题,蒸馏是"用什么数据训、为了什么目的"的问题。当你拿 R1 生成的 80 万条数据去 SFT 一个 Qwen,你既在做蒸馏,也在做微调——这两件事在那一刻是同一件事。

实践里常见的组合拳是这样的:先蒸馏,把大模型的通用推理能力搬进小模型,得到一个"底子好"的基座;再拿你自己的业务数据做一次轻量微调,让它贴合具体场景。先蒸再调,各管一段,这是 2026 年成熟团队的标准配方。

它能搬走多少,又搬不走什么

蒸馏不是魔法。说清楚它的边界,比吹它的效果更重要。

搬得动的: 有明确"过程"和"答案"的能力,蒸馏搬运效率最高。数学推理、代码生成、逻辑规划、结构化抽取、指令遵循——这些任务有清晰的思维链可以模仿,有可验证的对错。DeepSeek-R1-Distill 系列在 AIME、MATH-500、代码这些榜单上的大幅领先,就是证据。一个被好好蒸过的小模型,在它擅长的窄领域里,能逼近甚至偶尔超过原始大模型在该领域的表现。

搬不动的,有三类要心里有数:

第一,老师不会的,学生也学不会。蒸馏是能力的转移,不是能力的创造。老师的水平就是学生的天花板,你不可能蒸出一个比老师还强的模型(在老师覆盖的能力上)。

第二,广度会被压缩。小模型参数量摆在那,容量有限。你蒸数学,它数学强;但如果你想让它数学、代码、多语言、长文本、创意写作样样精通,它装不下。蒸馏逼着你做取舍:想清楚这个小模型到底要干什么,然后只蒸那部分。什么都想要,结果是什么都平庸。

第三,泛化能力可能变弱,这是个隐蔽的代价。2026 年有研究指出一个值得警惕的现象:蒸馏(尤其是自蒸馏)会让小模型推理变快、在分布内的题上表现好,但在没见过的、需要灵活变通的题上,泛化反而退步了。原因是学生学的是老师在特定题型上的"套路",套路学得越熟,越容易在新题型上水土不服。这个权衡叫"更快的推理,更弱的泛化"——蒸的时候要盯着分布外的测试集,别只看训练集附近的漂亮数字。

推理蒸馏:2026 年最值得关注的一支

推理模型的兴起,给蒸馏带来一个新麻烦,也催生了一个新方法。

麻烦在于:推理模型动不动就是几千 token 的长思维链。链条越长,误差越会一步步累积——老师在第三步走错一小步,学生照单全收,后面全错。你按传统办法,把老师生成的思维链整段喂给学生去模仿,学生学的是"老师在老师自己的思路上怎么走",可一旦学生自己推到一个老师从没经过的中间状态,它就懵了,因为训练时没人教过它这种情况怎么办。

2026 年的解法叫在线蒸馏(on-policy distillation),现在已经是 DeepSeek-V4、Qwen3、Gemma、Nemotron 这些前沿模型做推理后训练的标配。

它的思路反过来:不让学生模仿老师的轨迹,而是让学生先自己走。学生针对一道题,用自己当前的水平生成一条推理路径;然后老师(或者一个奖励模型、一个验证器)来给这条路径打分、指出哪里错了;学生再根据这个反馈修正。

关键区别在于:学生学的是"在我自己会犯的错误状态下,该怎么爬出来",而不是"老师在它的完美状态下怎么走"。这就解决了前面那个状态不匹配的问题——学生纠错纠的是自己真实会遇到的坑。代价是工程更复杂:你需要一个能在线打分的老师或验证器,训练时还得不断采样,比离线蒸馏重不少。

一套能落地的流程,和几个坑

如果你要真的蒸一个模型出来,我建议按这个顺序走:

1. 先把任务边界划死。这个小模型只干一件事还是几件事?接受多大的质量损失换多少成本?这一步想不清楚,后面全是返工。
2. 选老师和基座。老师选你能力范围内最强、且最好是白盒(能拿 logits)的;基座小模型选参数量匹配你部署预算的。Qwen、Llama 这些开源系列是常见选择。
3. 造数据。让老师在你的目标任务分布上大量生成,带上完整推理过程。数据的覆盖面决定了学生的上限——老师没生成过的题型,学生就是盲区。
4. 训练。黑盒老师就纯 SFT;白盒老师就加上 logits 的 KL 损失,效果更好。资源紧就 LoRA。
5. 评估,而且要评分布外。别只看训练集附近的指标,一定要拿没蒸过的题型测泛化,盯住前面说的"泛化退化"。

几个反复见到的坑:

• 老师数据不验证。大模型也会生成错答案,你不筛一遍就喂给学生,学生连错误一起学。蒸推理任务时,务必用验证器或答案对照过滤掉老师做错的样本。
• 盯着平均分,忽略短板。蒸完看总分涨了就交差,结果某个子能力悄悄崩了。要按子任务分别看。
• 以为蒸馏能省掉数据工程。蒸馏省的是人工标注,不是数据设计。老师生成什么、覆盖哪些分布,仍然得你来设计,这活儿一点不轻。
• 法律和合规边界。用某个商业 API 的输出去蒸自己的模型,可能违反对方的服务条款。蒸之前先看清楚老师那边的许可,这是工程之外、但绕不开的一道坎。

最后回到开头那个 7B 模型。它能打过 32B,不是因为它聪明,是因为它有个好老师,而且有人想清楚了"只让它学推理这一件事"。蒸馏的价值从来不是"免费得到一个强模型",而是让你能在质量和成本之间,精确地选一个你要的点——前提是你真的想清楚了要选哪个点。

参考资料

• On-Policy Distillation — Thinking Machines Lab
• A Survey of On-Policy Distillation for Large Language Models — arXiv
• The paradox of LLM self-distillation: Faster reasoning, weaker generalization — TechTalks
• DeepSeek-R1 — GitHub
• Understanding LLM Distillation Techniques — MarkTechPost
• The Best Open-Source Small Language Models in 2026 — BentoML
• Knowledge Distillation: Teacher-Student Loss Explained — Label Your Data

现在你再试一次。GPT Image 1.5、Nano Banana Pro 这一批模型,能把整段菜单文字清清楚楚画在招牌上,中英文混排都行,连字距都对。

这件事说明了一个变化:2026 年的图像生成,已经过了「拼画质」的阶段。 照片级真实感这道坎,几乎所有头部模型都迈过去了。差异不再在「画得像不像」,而是上移到了——能不能听懂复杂指令、能不能把字写对、能不能精确控制构图、版权干不干净。

这篇不吹也不黑,就把 2026 年这批工具的能力边界,实打实地拆给你看。

主流工具:四个梯队,各有各的活

2026 年的图像生成已经不是「一家独大」,而是按场景分工。我把现在真正能打的工具排成四组。

几个判断:

GPT Image 1.5 是 DALL-E 3 的继任者。它最大的本事是「听话」——你给一段绕口的指令,比如「左边一只戴红围巾的橘猫看向右边,右边窗台上有三盆多肉,从左到右依次是高、矮、高」,它能基本照做。这种精确执行复杂指令的能力,目前没有对手。

Nano Banana Pro 是 Google 基于 Gemini 3 Pro 做的,特点是「带脑子画图」——它能调用 Gemini 的推理和真实世界知识。你让它画一张「解释光合作用的信息图」,它真能把流程画对,文字标注也对。支持上传最多 14 张参考图同时喂一整套品牌规范,这一点对企业用户很关键。

Midjourney V7 仍然是审美的天花板。同样的提示词,Midjourney 出的图就是更「有味道」——光影、质感、构图的高级感,别家追了两年还没完全追上。但代价是它爱自由发挥,你想要精确控制时它常常给你「惊喜」。V7 的 Draft Mode 快了约 10 倍、GPU 成本砍掉一半,适合先大量试方向再精修。

FLUX.2 走的是另一条路:可控、可编程、开放权重。它能用十六进制色值精确指定品牌色不跑偏,能直接控制人物姿势,跨最多 10 张参考图保持角色和风格一致。FLUX.2 有 max / pro / flex / klein 多个档位,klein 是小尺寸开源版,能塞进消费级显卡跑。它是开发者和工作流集成的首选。

国产工具这两年进步很大。字节的即梦(背后是 Seedream 系列)在 LMArena、Artificial Analysis 这类盲测榜上已经能跟 FLUX 同台。Seedream 5 Lite 还做了「深度思考 + 联网搜索」的统一多模态生成。国产工具的真实优势是中文场景——中文海报、电商主图、本土化审美,加上 API 价格更友好。

现在真能做好的事

先说能用的。2026 年,下面这些活,AI 图像生成已经能稳定干好,值得直接放进生产流程。

第一,配图和素材。 博客头图、PPT 插画、社媒配图、占位素材——这类「画质够用、不需要极致精确」的需求,AI 已经完全够用,而且快得离谱。一张图从想法到出图不超过一分钟,成本几分钱。API 价格这一年多跌了 25 到 40 倍,2024 年初 DALL-E 3 一张图要八分到一毛二,现在 FLUX Schnell 一张只要三厘钱。

第二,设计草稿和概念探索。 这是我最看好的场景。设计师不再用 AI 出终稿,而是用它快速铺方向。一个 logo 概念,以前画十版要一天,现在一小时能看一百版。Midjourney 的 Draft Mode 就是为这个设计的——廉价地试,选出赢家再精修。AI 在这里的角色是「灵感加速器」,不是「替代设计师」。

第三,风格化改造。 把一张普通照片转成水彩、油画、赛博朋克、吉卜力风,这件事现在又快又稳。Niji 7(2026 年 1 月发布)在二次元风格上的细节连贯性——眼睛、反光、背景小元素——又上了一个台阶。

第四,局部改图。 这是 2026 年最被低估的能力。给一张现成的图,框出一块区域,告诉它「把这件衬衫改成蓝色」「把背景的车去掉」「这里加一棵树」——它能只改那一块,其余原样保留。这种编辑式生成比「从零生成」实用得多,因为它把 AI 嵌进了已有的素材里,而不是要求你推倒重来。

还做不好的事:别在这些地方踩坑

能力的另一面是边界。下面这几件事,2026 年的 AI 还做不好,你硬要它干,就是给自己挖坑。

精确文字,尤其是 logo 和品牌字体。 注意,我说的不是「能不能写字」——短标语、甚至整段段落,Nano Banana Pro 这类模型已经写得很准了。问题在精确:你公司 logo 那个特定字体、那个字母间距、那个注册商标小圆圈的位置,AI 复刻不了。它能画一个「看起来像 logo 的东西」,但不是你的 logo。品牌资产,老老实实用矢量软件。

像素级的精确控制。 「这个按钮往左移 12 像素」「这条线必须正好 2pt 粗」——扩散模型是从概率分布里采样的,它没有「像素坐标」这个概念。你能引导大方向,但要不了像素级精度。UI 终稿、技术图纸、需要严丝合缝的版式,AI 给你出草稿可以,出终稿不行。

跨多张图的角色一致性。 这是漫画、绘本、品牌 IP 最头疼的。你定好一个角色,想让它在二十张图里长得一模一样——目前做不到「完全一样」。参考图、Omni Reference、姿势控制能把「漂移」压到很小,但扩散模型的本质决定了:小扰动就可能把输出推到另一个「身份」上。换个画幅比例,角色还可能变脸。 2026 年的现实是:能做到「高度相似」,做不到「完全同一人」。

复杂的手部和肢体交互。 单只手现在基本没问题了。但复杂手势、多只手互相交叠、手里捏着小物件、再加上透视压缩——还是会冒出第六根手指或者扭曲的关节。人多的拥挤场景尤其容易翻车。

一句话总结边界:AI 擅长「生成一个合理的东西」,不擅长「生成那个精确指定的东西」。

可控性:把「碰运气」变成「下指令」

既然纯文字提示词控制不住,2026 年成熟的玩法是叠加多种可控性手段。把它们想成给模型套的「缰绳」。

flowchart TB
  P[文字提示词
定大方向] --> M((图像模型))
  R[参考图
定风格/角色/品牌] --> M
  C[结构控制
ControlNet:边缘/深度/姿势] --> M
  I[局部重绘
蒙版圈定改哪里] --> M
  M --> O[可控的输出]
  style P fill:#fde7c2,stroke:#e8b23c
  style R fill:#fde7c2,stroke:#e8b23c
  style C fill:#fde7c2,stroke:#e8b23c
  style I fill:#fde7c2,stroke:#e8b23c

参考图(Reference / Style Reference)。 最常用的一招。喂一张图进去,告诉模型「按这个风格来」「保持这个角色」「用这套配色」。FLUX.2 能跨 10 张参考图保持一致,Nano Banana Pro 能吃 14 张——足够塞进 logo、配色板、角色三视图、产品照一整套品牌规范。

结构控制(ControlNet 这一类)。 这是精确控制构图的核心手段。它不靠文字,而是直接给模型一张「结构骨架」:用 Canny 边缘图锁轮廓,用深度图锁空间关系,用姿势图(OpenPose)锁人物动作。模型在这个骨架上「填肉」。想让生成的人物摆出某个特定姿势?给它一张姿势骨架图,比写一百个字的提示词都管用。

局部重绘(Inpainting)。 前面提过的编辑式生成,背后就是它。流程是:原图 + 一张蒙版(白色=要改、黑色=保留)+ 描述新内容的提示词。这里有个关键参数叫 denoise(去噪强度):设 0.4–0.5 是「微调」,比如只改衬衫颜色;设 0.75–0.85 是「整个换掉」,比如把蒙版区域的物件彻底替换。新手最容易在这个值上栽跟头——想微调却设太高,结果整块区域面目全非。

实战建议:别只靠一种。 真正可控的工作流是叠加的——文字定大方向,参考图定风格,ControlNet 锁构图,最后用局部重绘抠细节。在 ComfyUI 里把这套流程搭成可复用的节点图,你就从「碰运气抽卡」变成了「下达精确指令」。这中间的差距,就是业余和专业的差距。

落地场景:哪些值得做,哪些先别碰

把上面的能力边界翻译成「该不该用」,我的判断是这样。

值得现在就上的:

• 电商详情页与营销素材——产品换背景、换场景、批量生成不同风格的主图。即梦、通义万相在中文电商场景上已经很成熟。
• 内容创作配图——博客、公众号、自媒体的头图和插图。画质够用,成本几乎可以忽略。
• 设计前期的概念探索——海报、logo、包装的方向铺陈。出草稿,不出终稿。
• 影视游戏的概念设定图——场景气氛图、角色概念图。这类「不要求精确、要求有想象力」的活,AI 是真帮手。

先别碰的:

• 需要精确版式的终稿——画册排版、UI 交付稿、含精确品牌资产的物料。AI 出草稿,人来定终稿。
• 强一致性的连续内容——长篇漫画、绘本、需要同一角色反复出现的 IP 内容。现在勉强能做,但要花大量人工修,算下来不一定省。
• 任何需要事实精确的图——医学示意图、工程图、地图。AI 画得「像那么回事」,但细节经不起推敲,误导风险高。

一个反复有效的判断标准:这张图允不允许有「合理的偏差」? 允许,AI 能帮你;不允许,差一点都不行,那就别指望 AI 出终稿。

版权与水印:绕不开的合规题

最后这一节,做商用的人必须看。

版权归属仍然模糊。 多数司法辖区的基本态度没变:纯 AI 生成、没有充分人类创作介入的图,很难获得版权保护。 这意味着你公司用 AI 生成的营销图,理论上别人也能拿去用,你未必告得了。想拿到版权,得有实质性的人类创作贡献——这也是「AI 出草稿、人来精修定稿」这个工作流在法律上更稳妥的原因之一。另外,训练数据的版权诉讼这两年一直没断,选模型时,优先考虑明确声明训练数据来源干净、或提供商用赔付条款的产品。

水印和溯源现在是默认配置。 2026 年,所有主流模型的输出都会被打标:

• C2PA Content Credentials——2025 年定为 ISO 标准(ISO/IEC 22144),一段签了名的元数据,记录这张图由哪个模型生成、经过哪些编辑。它现在是互联网事实上的「溯源语言」。
• SynthID——Google 的隐形水印,直接嵌进像素里,人眼看不见。关键是它抗造:截图、裁剪、压缩、重新上传到 Instagram,水印还在。

这里有个现实的坑你得知道:社交平台会剥掉 C2PA 元数据。 2026 年,Instagram、X、LinkedIn、TikTok、Facebook 在上传处理时基本都会清掉 C2PA manifest。所以光靠 C2PA 不够——元数据型水印一进社交平台就没了,只有 SynthID 这种嵌进像素的隐形水印能扛住。Google 同时上 C2PA 和 SynthID,目前是业界标杆做法。

对你的实际意义:别假设「AI 生成」这件事能藏住。 你发出去的 AI 图,大概率带着可被检测的水印。该标注的标注,该走合规的走合规——尤其是新闻、广告、政务这些场景,别赌。

写在最后

2026 年的图像生成,我的总体判断是:它是一个成熟、好用,但有明确边界的工具——不是魔法。

它真正改变的,是创意工作的前半段:探索方向、铺草稿、试风格、改局部,这些以前耗时的环节,现在快了几十倍、便宜了几十倍。它没有、短期也不会替代的,是后半段的精确收尾——精确版式、精确品牌、精确一致性,以及最重要的,人对「这张图到底要传达什么」的判断。

用对地方,它是杠杆;用错地方,它是个会自信地画错六根手指的实习生。分清楚这两者,你就已经领先大多数人了。

两个团队,同样要做一支 30 秒的产品宣传片。A 团队拿最强的文生视频模型,写了一段漂亮的 prompt,十分钟出片,画质惊艳——然后发现主角的衣服在第二个镜头变了颜色,客户不要。B 团队画质明显糙一截,但每个镜头的相机怎么推、主角长什么样、最后一帧停在哪,全都对得上。客户选了 B。

这件事说明一个被低估的事实:AI 视频生成早就过了"画得好不好看"的阶段,现在卡在"画得跟不跟你想的一样"。 2026 年发布的模型——Veo 3.1、Runway Gen-4.5、Kling O1、Pika 2.5——画质都够用了,真正的竞争发生在控制层。这篇不横评工具,只讲一件事:怎么让 AI 视频听话。

为什么"可控"比"画质"更卡落地

画质是个连续变量,差一点也能用;可控性是个二元变量,要么对要么废。

商业视频的本质是"带着约束的创作"。客户给你一张产品图,主角的脸不能变,品牌色是固定的 RGB 值,这个镜头要从左往右摇,下个镜头要接得上。这些都不是"建议",是硬约束。一个画质 95 分但主角换了张脸的镜头,商业价值是 0,不是 95。

文生视频的根本问题在这:prompt 是个低带宽的接口。 你想说的是"相机以每秒 15 度的速度向右平摇,主角始终在画面左三分之一",你能写的是"镜头缓缓摇过,主角在一侧"。中间丢掉的信息,模型用它训练数据里的先验给你补——补出来的东西好不好看是一回事,是不是你要的,完全是另一回事。

所以可控视频生成这两年的所有进展,本质上是在干同一件事:给模型加上 prompt 之外的、带宽更高的控制信号。 参考图、相机轨迹、首尾帧、mask,都是这个东西。

flowchart TB
  P[文字 prompt
低带宽] --> M[视频生成模型]
  R[参考图
锁身份/风格] --> M
  C[相机轨迹
锁运镜] --> M
  K[首尾帧
锁起止] --> M
  K2[局部 mask
锁编辑范围] --> M
  M --> V[可控的视频]
  style P fill:#fde7c2,stroke:#e8b23c
  style R fill:#cfe8d5,stroke:#4f9d69
  style C fill:#cfe8d5,stroke:#4f9d69
  style K fill:#cfe8d5,stroke:#4f9d69
  style K2 fill:#cfe8d5,stroke:#4f9d69

橙色那条是大多数人唯一在用的接口,绿色那几条才是 2026 年真正在拉开差距的地方。下面逐个拆。

运镜:从形容词到轨迹

运镜是最早被"控制化"的环节,因为它的需求最刚硬。

早期文生视频控制运镜靠形容词——“dolly in"“pan left"“crane shot”。这套东西的问题是,模型对这些词的理解是统计意义上的:它见过一万个标着 “pan left” 的片段,给你生成一个"平均的左摇”。速度多快、摇多少度、什么时候开始,你说了不算。

2026 年成熟的做法分两个层次。

第一层是离散的相机指令,Runway 的 Director Mode 是代表:你不是写形容词,而是在面板上选"水平移动 +30、垂直 0、变焦 -10”,给的是数值。这比形容词强,但还是预设档位的拼装。

第二层是连续的相机轨迹控制,这是研究界正在往产品里推的方向。学术上像 I2VControl-Camera 这类工作,把相机位姿表达成一条可调的三维轨迹,还能单独调"运动强度"——同一条轨迹,你可以要它走得猛一点或者收一点。ATI 这类工作更进一步,把相机运动、物体平移、局部形变统一成一套"轨迹指令",用户在图上画几条线,模型照着线动。

这里有个工程上的判断值得说:别期待一个模型既会高质量生成、又会精确听轨迹。 目前实践里更靠谱的是分层——先用大模型出基础画面和运动,相机轨迹作为一路独立的控制信号注入,而不是指望它从 prompt 里"悟"出来。运镜控制做得好的产品,基本都把"画什么"和"相机怎么动"解耦成了两路输入。

一致性:三个不同的问题,别混为一谈

“一致性"是个被说烂的词,但它其实是三个独立的问题,解法完全不同。混在一起谈,是新手最大的认知误区。

时序一致性是镜头内部的事:一段 5 秒的视频,主角的手不能忽然多一根指头,背景的招牌字不能一帧一个样。这个问题主要靠模型自身的时序建模能力,2026 年主流模型在 5–10 秒的片段内基本解决了。它不是你能控制的,是模型出厂带的。

角色一致性是跨镜头的事,这才是你要操心的。同一个人物,镜头一在咖啡馆、镜头二在街上,得是同一张脸、同一身衣服。2026 年的标准答案是参考图(reference image):Veo 3.1 的 “Ingredients to Video” 让你一次传最多四张参考图,分别锁主体、风格、构图;Runway Gen-4.5、Pika 2.5 都把参考图做成了一等接口。这里要建立的关键认知是——图生视频(image-to-video)在可控性上几乎总是优于文生视频。 一张参考图从第一帧就把身份、风格、构图全锁死了,模型只需要负责"动起来”。能用图起手,就别用纯文字起手。

跨镜头风格一致性最难,因为它没有单一的技术开关。十个镜头,每个都单独生成,哪怕都用了同一张角色参考图,光线方向、色温、颗粒感还是会飘。这个问题在 2026 年没有被模型解决,它是个工作流问题,后面专门讲。

首尾帧:把"生成"变成"补全"

如果只能推荐一个提升可控性的技巧,我会选首尾帧。

标准图生视频只锁第一帧,后面让模型自由发挥——你不知道它会停在哪。**首尾帧控制(first-last-frame)**把这件事反过来:你给定开始的图 A 和结束的图 B,模型的任务从"自由生成"降级成"在 A 和 B 之间补出中间帧"。Runway 叫 Keyframe,Kling 叫起止帧,Kling O1 把双关键帧做成了核心能力,Luma 叫 Keyframes,叫法不同,是同一个东西。

为什么这招好用?因为它把一个开放问题变成了闭合问题。开放问题"生成一段视频"有无数个解,模型挑哪个你管不着;闭合问题"从 A 走到 B"的解空间被两头夹死了,模型只能在中间这段动脑筋。 解空间小,可控性自然高。

对叙事尤其关键——一个镜头要"结束在某个特定画面"上,好接下一个镜头,首尾帧是唯一可靠的办法。LTX 2.3 这类工作甚至支持首、中、尾三个锚点,中间再插一帧,等于把一个长镜头的运动轨迹钉了三个点。

代价是你得先有 B 这张图。所以现实工作流常常是:先用文生图模型把每个关键画面的"起"和"止"都画出来,再用首尾帧让视频模型去连。画面设计和运动生成被拆成了两步——这恰恰是它可控的原因。

局部编辑:不要重生成整段

视频做到 90% 时,客户说"主角的杯子换成蓝色,别的不动"。

最糟的做法是改 prompt 重新生成整段——你会得到一段哪儿都不一样的新视频,杯子是蓝了,但运镜变了、表情变了,客户更不满意。局部编辑(local editing) 要解决的就是这个:只改你圈出来的地方,其余每一帧像素级不动。

技术上这是视频 inpainting 的活儿,2026 年的研究重点是怎么兼顾"局部干净"和"全局不漂"。视频 inpainting 有个老毛病:逐帧补会闪烁(局部不平滑),整段一起补又容易让被编辑区域慢慢偏离原意(全局漂移)。EditCtrl 这类工作的思路是只在被 mask 的 token 上做计算,算力开销跟编辑区域大小成正比——你只改一个杯子,就别为整个画面付费。OmniPainter 这类则用"自回归分数管局部平滑、层级分数管全局连贯"的混合引导来平衡这对矛盾。

落地建议很直接:把局部编辑当成跟生成同等重要的能力去选工具。 一个只会从头生成、不能精确局部改的视频模型,在真实商业流程里是残废的——因为客户的修改意见永远是"这里改一下",不是"全部重来"。

prompt 能控到哪,控不到哪

说点得罪人的。prompt 在视频生成里,是个被高估的控制手段。

它能控的:画面里有什么(主体、场景、大致风格、氛围)。这部分 prompt 是合格的,而且不可替代——你总得用语言说清楚要画什么。

它控不动的:任何需要精度的东西。精确的相机速度、物体在第几秒到达画面哪个位置、两个角色的相对站位、光线的具体方向——这些用文字描述,模型只能给你一个"差不多"。原因前面说过,自然语言对几何和时序的描述带宽太低,你写得再细,信息也在"文字→模型理解"这一步被压扁了。

所以一条实践原则:prompt 负责"内容",专门的控制信号负责"精度"。 想控运镜就上轨迹/相机面板,想控身份就上参考图,想控起止就上首尾帧,想控局部就上 mask。指望把这些全塞进一段 prompt 里"写清楚",是在跟模型的接口带宽较劲,较不赢的。

判断一个视频产品成不成熟,看一个指标就够:它除了 prompt 框,还给了你几个真正的控制接口。 只有一个 prompt 框的,是玩具;有参考图、有相机控制、有首尾帧、有 mask 编辑的,才是生产工具。

把碎片拼成叙事:可控性的终极考题

前面所有控制手段,都是为了一个镜头。但一支片子是几十个镜头。单镜头可控,不等于整片可控——这是 2026 年 AI 视频离"真能用"最后、也最硬的一道坎。

现在没有任何模型能一次生成一支风格统一的三分钟片子。能稳定输出的上限是 5–10 秒的单镜头。所以做长片只有一条路:生成一堆短片段,再拼起来。 而拼接的连贯性,完全是个工作流问题,不是模型问题。

一套 2026 年实战可行的流程是这样:

flowchart TB
  S[1. 文字脚本
分镜表] --> KF[2. 文生图
画出每个镜头的关键帧]
  KF --> REF[3. 锁定角色参考图
风格参考图]
  REF --> GEN[4. 逐镜头生成
首尾帧 + 参考图 + 运镜]
  GEN --> CHK{5. 逐镜头验收}
  CHK -- 不对 --> EDIT[6. 局部编辑修补]
  EDIT --> CHK
  CHK -- 通过 --> CUT[7. 剪辑台拼接 + 调色统一]
  style REF fill:#cfe8d5,stroke:#4f9d69
  style GEN fill:#cfe8d5,stroke:#4f9d69
  style CUT fill:#fde7c2,stroke:#e8b23c

几个关键点。第一,关键帧先行——先用文生图把每个镜头的画面定下来,这是整片风格统一的锚。第二,参考图全程复用——角色参考图和风格参考图,从第一个镜头用到最后一个,这是跨镜头一致性唯一能抓住的绳子。第三,最后一定有一道调色:哪怕前面控制得再好,十个片段的色调还是会有细微差异,在剪辑台上统一拉一遍 LUT,是目前抹平"拼接感"最有效的手段——这一步反而不靠 AI。

我的判断是:2026 年做 AI 长视频,真正的核心能力不是"会写 prompt",是"会做工作流"。 模型只是流水线上的一个工位。谁能把分镜、关键帧、参考图、首尾帧、局部编辑、调色这套流程串顺,谁就能稳定产出能交付的片子。盯着"哪个模型画质最强"的人,做不出连贯的三分钟。

最后:可控性才是这场竞赛的下半场

把这篇的判断收一下。

画质的竞赛基本结束了,2026 年主流模型都够用。下半场的全部看点在控制:谁的参考图锁身份锁得更死,谁的相机轨迹更跟手,谁的局部编辑能像素级不动,谁能让十个片段拼起来不露馅。

对要落地的人,优先级很清楚:

1. 能用图生视频,就别用文生视频——参考图是性价比最高的可控性。
2. 叙事镜头一律上首尾帧——把开放生成变成闭合补全。
3. 选工具看控制接口的数量,不只看画质 demo——能局部编辑的才是生产工具。
4. 把功夫下在工作流上——长片的连贯性是流程问题,不是模型问题。

一句话:别再问"哪个模型画得最好看",该问的是"哪套流程让我最说了算"。

2026 年我不会这么干了。我现在的默认动作是反问一句:你的业务数据是不是已经在 Postgres 里了? 如果是,那大概率你不需要再多一个数据库——装个 pgvector 扩展就够了。

这不是图省事。这两年向量检索这个领域发生了一件挺反常识的事:专用向量数据库的护城河,被"在已有数据库里加一个向量列"这件事填掉了一大半。 这篇就讲清楚这件事是怎么发生的,以及——什么场景下你还是真的需要一个专用的。

向量检索这两年变了什么

先说结论:向量检索从"一项需要专门系统的黑科技",退化成了"一种索引类型"。

2022、2023 年的时候,向量检索确实特殊。HNSW 索引怎么建、近似最近邻(ANN)怎么调参、召回率和延迟怎么权衡,这些都是新东西,通用数据库根本不支持。你想做语义检索,除了上专用向量库没有别的选择。专用向量库的价值,很大程度上来自于"别人还做不了"。

到 2026 年,情况倒过来了。HNSW 这种图索引已经是成熟、公开、被反复实现的算法,不再是谁家的秘密。pgvector 作为 Postgres 扩展,把 HNSW 和 IVFFlat 索引、多种距离度量、半精度存储这些都做齐了;0.8 版本之后还补上了"迭代索引扫描"(iterative index scan),专门解决带过滤的向量查询里那个老大难问题——后面会细讲。

换句话说,“做向量检索"这件事本身,已经不构成开一个新数据库的理由了。 它现在更像是"我需要一个 JSON 字段"或者"我需要全文检索”——你的现有数据库基本都能干,只是早几年还不行。

专用向量库不是没价值了,而是价值的位置变了:它不再赢在"能不能做",而是赢在"做到什么规模、做得多快、过滤多复杂"。这是一个量变到质变的边界问题,而不是一个有无问题。

pgvector 为什么吃掉了大半场景

把向量检索塞进 Postgres,带来的好处不是"少装一个软件"这么肤浅。真正值钱的是下面三件事。

第一,数据不用搬,事务是一致的。 绝大多数 AI 功能不是孤立的——一段文档的 embedding,总是挂在某个用户、某个项目、某个权限边界下面。如果向量在专用库、业务数据在 Postgres,你就得自己维护两套数据的同步:文档删了,向量要跟着删;权限变了,检索结果要跟着变。这套同步逻辑写起来不难,但它是一类永远会出 bug 的胶水代码——双写失败、顺序错乱、补偿任务追不上。向量和业务数据待在同一个 Postgres 事务里,这一整类问题直接不存在。

第二,过滤就是普通的 SQL WHERE。 “找语义相近的文档,但限定这个用户、这个时间段、状态是已发布”——这种带元数据过滤的检索是 RAG 里的常态,几乎没有哪个真实业务是纯粹的全库 ANN。在 pgvector 里,这就是一条 SQL,WHERE 子句和向量排序写在一起,还能直接 JOIN 业务表。在专用向量库里,过滤得靠它自己那套 payload/metadata 过滤机制,表达能力通常比 SQL 弱,跨"表"的关联更是做不了。

第三,运维你已经会了。 你的团队大概率已经在跑 Postgres——有人会调参,有备份,有监控,有高可用方案。pgvector 只是这台已有机器上的一个扩展,不增加任何新的运维面。而 Milvus 是一套认真的分布式系统,etcd、对象存储、查询节点、数据节点分开,通常得跑在 k8s 上,得有人专门盯着。这个运维成本,小团队最容易低估。

再加上一个关键事实:大多数 RAG 业务的数据量,比你以为的小得多。 一个 B2B SaaS 产品,把所有客户的所有文档切块做 embedding,常常也就几十万到几百万条向量。公开的评测和生产经验里有个反复出现的数字——1000 万条向量以下,pgvector 在端到端延迟、成本、运维复杂度上,综合体验是最好的。 单节点 Postgres 配置得当能撑到接近 5000 万条向量,这个区间覆盖了绝大部分企业级 RAG 产品。

所以"默认 pgvector"不是保守,是 2026 年对大多数场景最合理的工程判断。

那专用向量库什么时候才真的需要

把 pgvector 夸完了,得诚实地说它的天花板在哪。三个信号,出现任何一个,你就该认真考虑专用向量库了。

信号一:规模真的大。 这里说的"大"是几千万到十亿级的向量,而且还在涨。pgvector 的硬上限是单节点 Postgres 的上限——内存装不下索引、HNSW 索引构建时间长到离谱、单机扛不住并发。pgvectorscale 这个扩展能用 StreamingDiskANN 把索引下放到磁盘,把这个上限往后推一截,值得先试。但如果你的向量是亿级、要分布式分片、要水平扩容,那就是 Milvus 的主场——它在生产里被部署到几亿乃至十亿级向量是常规操作,搜索公司、电商、基因研究都在这个量级用它。

信号二:过滤又重又刁钻。 注意,这跟前面说 pgvector 过滤强不矛盾。pgvector 的强项是过滤的表达能力(SQL 想怎么写怎么写);它的弱项是高过滤率下的检索性能。近似索引的本质矛盾是:先扫索引拿候选,再套过滤条件——如果过滤条件只命中全库 1% 的行,HNSW 默认 ef_search 才 40,扫出来平均可能一条都不剩。pgvector 0.8 的迭代索引扫描缓解了这个问题(不够就继续扫,直到够数),但它是"打补丁",不是"原生为过滤设计"。Qdrant 走的是另一条路:payload 感知的索引,让带过滤的检索性能接近不带过滤。如果你的核心场景就是在一个大库的某个过滤子集上做高 QPS 检索,Qdrant 是 2026 年的默认答案。

信号三:延迟和吞吐被压到极限。 公开评测里,Qdrant 在 100 万向量、召回率 95% 以上时能做到约 1840 QPS,p99 延迟约 12ms,是开源里最快的一档;Milvus 约 18ms,Weaviate 约 16ms。pgvector 在 1000 万以下做得也不错,但当你的检索 QPS 很高、又卡着严格的 p99,专用库用 Rust/C++ 写的查询引擎、更精细的索引控制,确实能再榨出一截。这是个"边际收益"问题:大多数业务感知不到这一截,少数高频检索的业务很在意。

把这三个信号反过来说:如果你的向量在千万以下、过滤用 SQL 能舒服表达、对延迟没有极端要求——你三个信号一个都没踩中,那就别折腾,pgvector。

flowchart TD
  A[要做向量检索] --> B{数据已经在
Postgres 里?}
  B -- 是 --> C{向量量级?}
  B -- 否 --> D{团队已有
关系型数据库?}
  C -- 1000 万以下 --> E[pgvector
默认选择]
  C -- 1000 万-5000 万 --> F{过滤重 / 延迟苛刻?}
  C -- 亿级以上 --> G[Milvus
分布式专用库]
  F -- 否 --> H[pgvector + pgvectorscale]
  F -- 是 --> I[Qdrant]
  D -- 是 --> E
  D -- 否 --> J[Qdrant
轻量专用库起步]
  style E fill:#cfe8d5,stroke:#4c9a6a
  style G fill:#fde7c2,stroke:#e8b23c
  style I fill:#fde7c2,stroke:#e8b23c

混合检索:专用库重新拿回的一分

前面说专用库护城河被填了一大半,混合检索是它们守住的那一小半。

纯向量检索有个真实的弱点:它擅长"意思相近",但对"必须精确出现的词"反而不灵。用户搜一个产品型号 SKU-7741X、一个错误码 ERR_0x80、一个人名,语义相似度模型很可能给你一堆"意思差不多但型号不对"的结果。这种场景下,老派的关键词检索(BM25)反而准。

混合检索就是把两者揉在一起:稠密向量负责"语义",稀疏的 BM25 负责"精确词命中",再用一个排序融合(比如 RRF)把两路结果合并。2026 年这基本是 RAG 检索质量的标配,而不是加分项。

这件事上,各家差距很明显:

pgvector 在这一项上是"能做但不优雅":两套排序、两套分数,RRF 融合得自己写在 SQL 或应用层。能跑,但不如 Weaviate 那种"一条查询返回融合结果"省心。

所以如果检索质量是你的产品核心、混合检索要做得讲究——这是天平往专用库(尤其 Weaviate)倾斜的一个实打实的理由。如果混合检索对你只是"锦上添花",pgvector 自己拼一套也能用。

托管还是自建

选完"哪个数据库",还有一道正交的题:托管云服务,还是自己部署。

参考一下 2026 年的大致价位,1000 万向量量级:Pinecone Serverless 约每月 70 美元,Qdrant Cloud 约 65 美元,Weaviate Cloud 约 135 美元,而 pgvector 跑在 RDS 上大约 45 美元。这个区间里,差价是噪音,不值得为省几十美元纠结。

真正拉开差距的是两个极端:

• 量级很小、又不想多维护一个系统:数据已经在托管 Postgres(RDS、Aurora、Supabase)里的话,pgvector 几乎零边际成本——你连"选型"都不用做。
• 量级很大(上亿向量):托管和自建的成本差会放大到很夸张的程度。同样的亿级负载,Pinecone 这类全托管的账单能到自建 Qdrant 或 Milvus 的 3 到 5 倍。这个量级,自建省下的钱足够养一个专门运维的人。

中间地带的判断很简单,就一句话:算清楚你那个专门维护数据库的工程师,一年值多少钱。 Pinecone 这种全托管的卖点从来不是便宜,是"你完全不用管它"——没有节点、没有索引调参、没有半夜被叫起来。对一个还没有专职 DBA、工程师时间比服务器贵得多的小团队,多付的托管费通常划算。反过来,已经有成熟基础设施团队、规模又上来了,自建 Qdrant/Milvus 的性价比会明显反超。

我的经验法则:早期一律托管(包括直接用托管 Postgres 的 pgvector),把精力留给产品;等规模和团队都长起来了,再谈自建。 别在第一天就为一个还不存在的扩容问题,提前背上运维负担。

一张表收尾:按规模和场景怎么选

把上面所有判断压成一张可以贴在工位上的表:

最后留一句话。三年前"做 AI 检索就得上专用向量库"是对的,因为别人确实做不了。2026 年这句话已经过期了——专用向量库依然优秀,但它现在要靠规模、过滤、混合检索这些具体的硬指标来赢得你,而不是靠"向量检索"这四个字本身。 选型的第一步不再是"挑哪个向量库",而是先诚实地问自己:我真的到了需要它的那条线了吗?

大多数人,还没到。