我在自己的硬件上搭建了Andrej Karpathy的LLM委员会，现在没有任何单一模型能说了算

我和本地LLM的关系一直时好时坏。最初，我尝试了第一代或第二代的8B模型，但它们并不总能达到我的期望。我就弃坑了，重新用回了云端模型。几周前，我再次尝试了本地LLM。我甚至在我的RTX 4070 Ti上并排测试了三个本地LLM，决定把其中一个设为默认。并不是因为那一个模型比另外两个强，而是因为每个提示都同时跑三个模型不太现实。不过，每个模型都有自己的优势，所以我把另外两个保留下来，遇到真正重要的提示时，就会去用它们。这让我开始琢磨：要是三个模型一起用，能不能得到更好的结果？就在那时，我遇到了Karpathy的LLM Council，它最初是为云端API设计的。我喜欢这个想法，决定把它改造成跑在我自己硬件上的本地模型版本。

一个答案还不够

选出了赢家，争论却没结束

来说说几周前我做的那次对比。我的设置很简单。我用RTX 4070 Ti来跑本地LLM。三个本地LLM——DeepSeek-R1 8B、Qwen 3.5 9B和Gemma 4 E4B——通过Ollama运行。界面用的是我熟悉的Open WebUI。我给每个模型用的指令都差不多，想看看哪个最好。我运行了四个不同类别的提示，每个模型的表现都不同。

DeepSeek擅长推理，但在压力下会产生幻觉。Qwen感觉懂得比另外两个多，但它常常冗长，好答案都淹没在长篇大论里。最后，Gemma 4擅长组织和综合信息，但它也不总是对的。所以，最终我选择了Gemma 4，但每当提示真正重要时，我还是会去找不同的模型来做最终判断。我不是在为同一个问题寻找更多答案；我是想对得到的答案更有把握。而且我老是发现，DeepSeek能看到Gemma看不到的东西，有时候Qwen会提到另外两个都忽略的特殊情况。不知不觉，我就开始像个法官一样，比较所有三个答案并做出决定。

每次都要手动对比三个长回复，实在太累了，这才让我转向了 LLM Council。Karpathy 提出的 LLM Council 方案是这样的：与其向每个云模型提出相同的问题，不如把它们凑成一个“委员会”，让每个模型为自己的答案说话，同时挑其他模型的毛病，最后由一个模型撰写最终回复。我一听就觉得这想法太对了，因为我正在做同样的事情：我向所有三个模型提出相同的问题，并手动评判每个长回复。就在那时，我决定至少尝试一下这个想法；如果我能为我的本地 LLM 复制它，那简直是赚大了——隐私有保障、不用花 API 的钱、还跑在自己的硬件上。但让一个本来是为云端设计的软件跑在单张 12GB 的 GPU 上，结果发现，这事儿比看上去有意思得多，也难得多。

三个模型，一个 GPU，心里完全没底，不知道到底能不能跑通

为云端而生，却要跑在单张 GPU 上

Karpathy 的想法其实就三步。第一步，把同一个提示分别发给每个模型，让它们同时各自生成回答。然后，第二步，每个模型匿名地看其他模型的回答，然后给它们打分排名。最后，第三步，被指定为主席的那个模型看完所有内容，写出最终答案，再交给用户。乍一看，这似乎是一个完美的解决方案——不用在几个对话之间来回切标签页，不用分别读三个长回复，也不用自己琢磨哪些部分靠谱。

但实现起来并不是简单的 git clone 然后运行——它没法直接跑起来。Karpathy 的实现要求通过 OpenRouter 或 OpenAI 兼容端点来调用云端 API，并且在第一阶段，它会并行调用每一个模型。但就我而言，由于我使用的是本地模型，我把那些 API 调用换成了 Ollama 的 OpenAI 兼容端点。我没有用云端模型，而是让我本地的三个 LLM 都走这个端点。在原始实现中，设计上已经让主席同时兼任委员，所以我保留了这个结构。Gemma 4 既是委员，也是主席。

整体改起来很直接；代码不需要重大修改，因为 Ollama 提供了兼容的 API。但问题在我运行它时首次出现。原始版本的设计是同时跑云端推理，就是说它是给有专用硬件的云服务商用的。而当我发送第一个请求时，它同时运行了三个模型，每个都有 8B-9B 参数，运行在我的 RTX 4070 Ti 和 12GB 显存上。那根本行不通。一个模型悄无声息地掉线了——没有报错，就是没有响应。然后我改了工作流，让每个模型依次处理，而不是同时发请求。

显然，完成每个阶段需要更多时间，但至少现在我能指望每个模型都给出回应了。一旦整个流程稳定跑起来，真正的问题已经不是它能不能跑了，而是让三个模型辩论，到底是不是真的比直接问 Gemma 更好。

赢家不是任何一个模型

三票，三个赢家，零共识

选择 Gemma 作为主席并非巧合。我选择它是因为 Gemma 已被证明是最擅长综合各方答案的那个。在 Karpathy 的原始实现中，主席模型也是委员会成员之一，所以 Gemma 既全程参与竞争，又兼任主席。Gemma 先在第一阶段独立生成自己的回答，然后在第二阶段把三个回答放在一起比较，最后在第三阶段给出最终答案。

好了，说回真正的测试。其中一项测试涉及Cloudflare Tunnel与Pangolin的提示。而声望排行榜产生了一个意想不到的结果：三方竟然打了个平手。倒不是因为它们意见一致。每个模型都把自己排第一，但在怎么排其他模型上各执己见；这才是真正有意思的地方。

严格来说，它们都失败了，但在第三阶段，这种失败无关紧要。主席压根不在乎排名，只是在看它们各自后面的评审。DeepSeek 提供了最详细的实践部署细节，而 Qwen 用更容易理解的方式把利弊讲清楚了。Gemma 则补上了结构上的清晰感，把前面的一切串了起来。委员会最大的优势压根不在排行榜上，而是能让它们互相看对方的自我评估，然后拿出更好的东西来。

整合才是真正的本事

我从整个实验中吸取了一些教训。整合归纳是一种和生成不一样的技能，跟自我评分更是两回事。我并不是说委员会比任何单个本地模型更聪明。但对于大多数任务，我仍然会打开 Gemma。遇到任何复杂到需要听听别人意见的事，我会去找委员会。它更慢，在单个 12GB GPU 上跑起来也比以前只问一个模型吃力得多。因为评估在我看到最终答案之前就已经发生了，不用我自己去手动比较三个不同的回复。