第一周：造第一个 LLM 产品，前沿模型怎么挑

这个系列第一步不是写代码，是选模型。而选模型最常见的错误是拿排行榜当答案。

排行榜答不了你的问题

公开基准回答的是「在这批题上谁分高」，而你要回答的是「在我的任务上，谁够用且最便宜」。这两个问题的答案经常不一样。

有两个更硬的理由让我不信排行榜。

一是排名里混着别人的脚手架。 有研究提出，在长时程任务上 harness 引起的方差可以超过模型引起的方差，甚至让模型排名反转。

二是那个分数本身就不稳。 2026 年一份工具调用评测审计干了件很朴素的事：把同一个基准原地重跑 23 次，什么都不改。结果分数在 57.9% 到 76.8% 之间晃，标准差 5.4 个百分点，最大跨度 18.9 个百分点。同一份审计还请人逐条复核了 496 个任务，发现评测器判定和人不一致的比例是 18.5%。

把这两条放一起：一个五个点的排名差距，可能既不是模型的差距，也不是真的差距。

所以这一格该做的不是读榜，是搭一个自己的小对比。

一个够用的对比长什么样

不需要复杂。三样东西就够：

一、十到二十道你真实场景里的题。 从生产日志里捞，不要自己编 —— 编的题会不自觉地贴合你对模型的印象。

二、一个能自动判分的判据。 这一格决定了这个对比有没有意义。能程序判死最好（有没有输出这个字段、数对不对），判不死就人工标注一批当基准。

三、同一批题跑所有候选，配对比较。 不要 A 跑一批 B 跑另一批 —— 题目难度的差异比模型的差异大得多，只有相减才能把它消掉。

别只看正确率

同一个任务上，至少要同时记四个数：

维度	为什么
正确率	显然的那个
每次调用的成本	便宜十倍的模型正确率低五个点，可能是划算的
延迟	交互式产品里，慢一倍等于不能用
稳定性	同一道题跑五遍，答案变不变

第四个最容易被忽略，而它对 agent 特别要命：一个每次走不同路径的模型，会让你后面所有的 A/B 都失效。

开源模型的真实成本

「开源模型免费」这句话只在 API 账单那一栏成立。

我自己在一台 32GB 的 Mac 上跑本地模型，实测的几件事：

一、显存是硬约束，而且要和别的东西抢。 我试过一个 19.95GB 的权重，浏览器一开就装不下 —— 而我那个项目天生要开浏览器。这不是调参能解决的，是选型时就要算进去的。

二、慢得超出预期。 27B 的模型处理一张截图，单次调用 85 到 90 秒。跑一条四步的用例是十六分钟。在云 API 上几秒的事，本地要按分钟算。

三、并发会让情况更糟。 两个请求同时打同一块 GPU，两个都变慢。云 API 那种「加并发就更快」的直觉在这里不成立。

所以开源模型的适用场景很具体：数据不能出去、调用量大到 API 账单超过硬件成本、或者你需要改模型本身。「省钱」单独一条，往往算不过来。

一个容易踩的坑：JSON 模式

要结构化输出的时候，第一反应是打开 response_format: json_object。

我在本地服务上实测过一次很有意思的失败：同一份提示词，带这个参数，服务端返回 []，三个 token 就结束；去掉它，同一个模型给出五个状态四条迁移、六百个 token。

原因是这个模式只保证语法合法，而 [] 也是合法 JSON —— 于是它成了最短的合法答案。

教训不是「别用 JSON 模式」，是「别把它当护栏」。 真正的护栏是 schema 校验加重试，而且重试的时候要把具体的错误和一个最小的正确样例带上 —— 只丢一句「解析失败」会把模型带得更偏。

边界与代价

这一篇讲的是方法，不是结论。 我没有给「哪个模型最好」的答案，因为那个答案的保质期以月计，而方法的保质期以年计。

搭对比本身要花时间。 十道题、一个判分器、跑几轮 —— 大概是一两天。这个成本只在你会反复选型的时候才划算；如果你就用一个模型不打算换，直接开始做正事。

我的本地测量是单机数据。 32GB 的 Mac、MLX 推理，换个硬件或者换 vLLM 这类带分页 KV 的服务，数字会完全不同。可以拿它论证「本地推理要先算显存和延迟」，不能拿它推算你的机器。