LLM

去年我们一个内部项目,用 Claude Opus 跑一个意图分类:输入一句用户的话,输出三个标签之一。上线两周,有人去看账单,愣住了——这个分类任务,一个 14B 的开源模型在自己的卡上跑,效果差不了几个点,成本是它的几十分之一。 这就是 2026 年选型最常见的错误:把"哪个模型最强"当成了"我该用哪个模型"。 这两个问题根本不是一回事。GPQA、SWE-bench、ARC-AGI-2 这些榜单告诉你的是天花板,而你大部分的线上请求,离天花板远着呢。一个分类、一段摘要、一次格式化抽取——这些活儿,旗舰模型是高射炮打蚊子。选型不是选最强,是给每一类任务配一个"刚好够用、且最便宜"的模型。 这篇不排名。给你一套按场景拆的决策框架。 先认清:2026 年的模型是分梯队的 2026 年 5 月,前沿模型大概是这么个格局——记住具体版本号意义不大,它们每两三个月就跳一次,记住梯队就行: 梯队 代表模型(2026.05) 典型 API 价格(输入/输出,每百万 token) 该干什么 旗舰 GPT-5.5、Claude Opus 4.7、Gemini 3.1 Pro $5 / $25 量级 复杂推理、Agent 编排、难代码 主力 Claude Sonnet 4.6、Gemini 3 Flash、DeepSeek V4-Pro $1–3 / $3–15 量级 绝大多数生产任务 快而省 Claude Haiku 4.5、Gemini 3 Flash-Lite、DeepSeek V4-Flash $0.1–1 / $0.3–5 量级 分类、抽取、路由、简单问答 这张表里藏着一个关键事实:旗舰和"快而省"之间,输出价格差了几十倍。 DeepSeek V4-Flash 的输出大约 $0.28,GPT-5.5 是 $30——一百多倍。这个差距不是边角料,它会直接决定你的产品能不能规模化。 而梯队之间的能力差距,这两年反而在缩小。2024 年你能明显感觉到旗舰和主力不是一个物种;2026 年,在很多具体任务上,主力模型只比旗舰差几个百分点,有时候你压根测不出来。能力在收敛,价格还拉得很开——这就是"按梯队选型"能省钱的根本原因。 ...

先说一个反直觉的数字:80% 喊着「我们要微调」的需求,换个更好的检索就解决了。 这是 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 上线快,但养着它不轻松。 ...

给你的知识库问一个问题:“我们去年 Q3 的退款政策,跟今年比有什么变化?” 朴素 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 里完全没有的。整个演进,本质上就是把这两个能力一点点加进来。下面拆成四个阶段讲。 ...

2025 年 6 月,安全公司 Aim Security 披露了一个叫 EchoLeak 的漏洞(CVE-2025-32711,CVSS 9.3)。攻击方式简单得离谱:给目标发一封普通邮件。 用户不需要点开邮件,不需要点链接,什么都不用做。只要他之后用 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 在正常干活的过程中读到了这段内容,指令就被触发。 ...

让模型回答之前先"想一会儿",这件事确实有用。 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 从一个研究概念,变成了产品标配。 这一年学到的:思考不是免费的 如果故事到这里就结束,那这篇文章没什么好写。问题恰恰在于——让模型多想,代价大得超出很多人的预期。 ...

去年这时候,你给 AI 一句"猫在厨房打翻牛奶",它给你一段四秒、猫的爪子有六根、牛奶往上流的诡异片段。 今年同一句话,Veo 3.1 能给你一段八秒的画面:猫跳上台面,牛奶盒倒下,液体顺着桌沿往下淌,落地有声——连"啪嗒"那一下都对上了。 进步是真的。但如果你由此以为"AI 已经能拍片了",那是被发布会的精选片段骗了。2026 年 5 月的真实情况是:AI 视频在 10 秒以内的单镜头里已经接近以假乱真,但只要你想讲一个完整的故事,它立刻露馅。 这篇把这条分界线划清楚。 四家主流,各打各的算盘 先把牌摊开。2026 年第一梯队基本是这四家加一个 Runway,但他们的定位差得很远。 工具 最新版本 时长 / 分辨率 强项 你该知道的坑 OpenAI Sora 2 Sora 2 10–25 秒 / 1080p 物理真实感、多镜头跟随、原生音画同步 Sora 独立 App 已于 2026 年 4 月下线,API 计划 9 月停服 快手可灵 Kling 可灵 3.0 长片段 / 原生 4K 人物自然动作、复杂多主体交互、中文生态 估值已冲到 200 亿美元,产品在快速商业化收紧免费额度 字节 Seedance Seedance 2.0 4–15 秒 / 1080p 多模态输入(图/音/视频混合)、多语言对口型 上线 100+ 国家但不含美国 Google Veo Veo 3.1 8 秒为主 / 1080p 原生音频、镜头运动、和 Google 工具链打通 基础款时长短,长片要靠拼接 Runway Gen-4 / Gen-4.5 最长可达分钟级 / 4K 角色一致性、Aleph 视频内编辑、可接 API 混管线 偏专业工具,上手门槛比前几家高 几个观察值得说。 ...

你把 prompt 改了一版,在三个例子上试了试,看着比之前顺眼,于是上线。 第二天客服群里有人说 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 集就是把这个分布固定下来。 ...

打开你的 iPhone,如果它是 16 或更新的型号,系统里已经常驻着一个约 30 亿参数的语言模型——它在帮你总结通知、改写短信、给照片打标签,全程不联网。你没装它,你也没感觉到它,但它一直在那。 这件事一年前还做不到。 过去这一年,所有头条都给了旗舰大模型:更长的上下文、更强的推理、更贵的订阅。但真正改变"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 场景,模型本来就不该负责"算出答案",它只负责"派活"。 ...

DeepSeek V3 一共有 6710 亿参数。但你每问它一句话,真正参与计算的只有 370 亿——剩下的 95% 在显存里待命,一个 token 都不碰。 这听起来像偷工减料,其实是过去三年大模型架构最重要的一次转向。到 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 的并发代码",用到的知识完全不同。稠密模型的浪费就在这:不管你问什么,它都把"写代码的脑区"和"聊天气的脑区"全部点亮算一遍。 ...

你写了个 prompt,让 LLM 把一段用户评论解析成 JSON:情感、评分、关键词。本地跑了二十次,完美。上线。 三天后告警响了。某条响应里,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"。它的唯一价值是当作其他方案的补充——把字段含义、示例写清楚能提升内容质量。但别拿它当结构保证。如果你现在生产环境还在裸用这个,这篇文章后面的部分就是为你写的。 ...

先说一个很多团队没算过的账。 假设你的 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 的全部精髓。所有的"怎么用对",归结成一句话:让不变的东西待在前面,让变化的东西待在后面。 ...

去年这个时候,如果你跟人说"我们生产环境跑开源模型",对方多半会礼貌地点点头,心里默认你是预算不够。开源模型当时的人设就是"省钱的次选"。 2026 年 4 月 24 日,DeepSeek 把 V4-Pro 的权重直接挂上了 Hugging Face,1.6 万亿参数,MIT 许可证,1M 上下文。它在编程基准上的得分,跟当月最强的几个闭源旗舰之间,差的不是一个段位,是几个百分点。 这件事的信号比"又一个新模型"大得多。它意味着:当你今天选开源,你放弃的不再是能力,而是别的东西。 这篇就来复盘开放权重这一年的格局——谁在领跑、中国开源为什么这么猛、剩下的那点差距到底在哪、许可证这个没人爱看的细节怎么反而成了关键,以及开源那套微调量化部署的生态,现在到底成不成熟。 需要先说清一个词。这篇说的"开源",严格讲是开放权重(open weights):权重能下载、能自己跑、能商用。它和教科书意义上的开源软件不是一回事——绝大多数模型不公开训练数据、不公开训练代码,你拿到的是一个能跑的成品,不是一份能复现的菜谱。后面我还是用"开源"这个习惯叫法,但你心里得清楚,这是个有水分的词。 领跑的三家,其实是三种活法 把 2026 年 5 月的开放权重阵营摊开看,DeepSeek、Qwen、Llama 这三个名字最响,但他们根本不在同一条赛道上。 模型家族 代表版本(2026.05) 架构 / 规模 许可证 它在赌什么 DeepSeek V4-Pro / V4-Flash MoE,1.6T 总参 / 49B 激活;Flash 284B/13B MIT 用前沿能力 + 极宽松许可证,直接当闭源旗舰的平替 Qwen Qwen 3.6 系列,六档尺寸 + 3.6-VL Dense 与 MoE 混编,从手机到集群 Apache 2.0(开放档) 用"全尺寸覆盖 + 最强多语言"做开发者默认底座 Llama Llama 4 Scout / Maverick MoE,17B 激活(16 / 128 experts) Llama 4 社区许可(有条件) 守住最大的部署装机量和生态惯性 Mistral Large 3、Small 4 Large 3:675B/41B;Small 4:119B/6B Apache 2.0 欧洲牌照 + 干净许可证,做合规友好的那一个 这张表里我最想让你看的是最后一列。三家头部各自押的东西完全不同:DeepSeek 押"能力对标 + 许可证无摩擦",Qwen 押"尺寸谱系最全",Llama 押"我已经在几十亿设备和无数教程里了"。 ...