开源大模型选型实战：从参数规模到量化部署的避坑指南

开源大模型这两年变化太快了，快到什么程度？我去年年初整理过一份选型对照表，到年中再看，一半的结论已经过时了。新模型一个接一个放出来，榜单排名每周都在洗牌，昨天还觉得某个模型是"小钢炮"，今天就被另一个同尺寸的按在地上摩擦。所以这篇不打算给你一份"终极排名"，那种东西保质期太短，我更想聊的是：面对一堆开源模型，到底该怎么看、怎么选、怎么用，以及我自己踩过的那些坑。

这篇内容适合几类人：一是刚接触 LLM、想本地跑个模型试试水的新手；二是手里有具体任务（比如做知识库问答、做文档处理、做代码辅助），需要在开源模型里挑一个落地的开发者；三是已经在用某个模型、但总觉得效果不对劲、想搞清楚问题出在哪的人。核心关键词就一个——开源模型对比，但我会把它拆成"参数规模怎么选""量化档怎么权衡""榜单怎么看""实际任务怎么测"这几个具体问题来讲，尽量让你看完能直接上手做决策，而不是又多收藏一份没用的清单。

1. 先搞清楚你要对比的到底是什么

很多人一上来就问"哪个开源模型最好"，这个问题本身就问错了。模型没有绝对的好坏，只有"在你的任务上、你的硬件上、你的预算下，哪个更合适"。所以在做任何对比之前，得先把对比的维度定下来，不然就是瞎比。

1.1 参数规模不是越大越好，而是要匹配你的显存

开源模型最常见的分类方式就是按参数量：0.5B、1.5B、3B、7B、8B、13B、14B、32B、70B，再往上还有几百B的 MoE 架构。新手容易有个误区，觉得参数越大越聪明，直接冲最大的。结果下载下来发现根本跑不动，或者跑起来了但慢得像蜗牛。

这里有个粗略的估算方法，你可以直接拿去用。推理时显存占用大致等于：参数量 × 每参数字节数 + 上下文缓存开销。以 FP16 精度为例，每个参数占 2 字节，那么 7B 模型光权重就要 14GB 左右，加上 KV Cache 和框架开销，实际得准备 16GB 以上的显存才比较稳。如果是 4-bit 量化，每参数约 0.5 字节，7B 模型权重降到 3.5GB 左右，8GB 显存的消费级显卡就能跑得比较舒服。

我自己的经验是，先看手头硬件，再倒推能跑多大的模型，而不是反过来。下面这张表是我整理的常见规模与硬件的大致对应关系，注意是"能跑起来"的底线，不是"跑得爽"的配置：

提示：这张表里的数字是经验值，不同框架（比如 llama.cpp、vLLM、Ollama）的实际占用会有差异，上下文长度开得越大，KV Cache 吃掉的显存越多，长上下文场景要额外留余量。

1.2 通用能力和专项能力是两回事

榜单上排名靠前的模型，通常是通用能力均衡的"六边形战士"。但你的任务可能很专一，比如只做中文摘要、只做代码补全、只做结构化信息抽取。这种情况下，一个通用榜单排名稍低、但在你任务上专门优化过的模型，往往比通用大模型更好用。

举个我实际遇到的例子。做中文长文档摘要时，我一开始用的是某个通用榜单排名很高的模型，结果它老是"发挥"，把原文没有的结论加进去。后来换了一个在中文语料上训练更充分、指令遵循更严格的模型，虽然通用榜单排名低了几位，但摘要的忠实度明显更好。所以别迷信单一榜单，要看你任务对应的细分能力。

1.3 许可证和商用限制必须提前看

这一点特别容易被忽略。有些开源模型权重是开放的，但许可证对商用有限制，或者对月活用户数有门槛。如果你是要做产品，选型第一步就该把许可证看清楚，别等做完了才发现不能用。常见的开源许可证有 Apache 2.0、MIT 这类宽松的，也有自定义的社区许可证，条款差异很大。我的建议是，商用场景优先选许可证宽松、社区活跃、有明确商用授权的模型，省得后面扯皮。

2. 量化档位：省显存和保效果之间的那根线

量化是本地跑开源模型绕不开的话题。简单说，量化就是把模型权重从高精度（比如 FP16）压缩成低精度（比如 INT8、INT4），用一点点效果损失换取大幅的显存和速度收益。但量化档位怎么选，里面的门道比想象中多。

2.1 常见量化格式和它们的实际差别

现在主流的量化格式有 GGUF（llama.cpp 生态用得多）、GPTQ、AWQ、EXL2 等。名字看着眼花，其实核心区别就两点：量化算法不同和运行时框架不同。

GGUF 的好处是格式统一、CPU 和 GPU 混合推理都支持，适合个人电脑本地跑。GPTQ 和 AWQ 更偏向纯 GPU 推理，AWQ 在激活值感知上做了优化，通常同档位下效果比朴素 GPTQ 好一些。EXL2 则支持更灵活的混合精度，可以按层设置不同比特数。

我实测下来的感受是：4-bit 是目前性价比最高的档位。从 FP16 降到 4-bit，显存占用降到约四分之一，而在我做过的多数任务上，效果下降在可接受范围内。再往下到 3-bit 甚至 2-bit，效果就开始明显崩了，尤其是需要推理和长文本理解的任务，会出现答非所问、逻辑断裂的情况。

2.2 量化档位排名的正确读法

网上经常能看到"量化档排名"这类说法，指的是同一模型在不同量化档位下的效果对比。看这类排名要注意几点：

第一，测试集是什么。如果测试集是通用知识问答，那排名靠前不代表在你的专业领域也好。第二，量化方法是什么。同样是 4-bit，不同算法出来的效果能差不少。第三，有没有做校准。好的量化会用一部分校准数据来减少精度损失，粗糙的量化直接一刀切，效果差很多。

我一般会这样操作：先锁定 4-bit 档位，在几个主流量化版本里各跑一遍自己的测试用例，选效果最稳的那个。别嫌麻烦，这一步花的时间，比后面返工省得多。

2.3 一个容易被忽略的坑：量化后的"性格变化"

这个坑我踩过，印象很深。同一个模型，FP16 版本和 4-bit 量化版本，不只是"聪明程度"有差别，输出风格也可能变。我遇到过一个模型，原版回答比较简洁，量化后变得特别啰嗦，还喜欢重复。原因可能是量化过程中某些层的权重被压缩后，模型的输出分布发生了偏移。

所以如果你对输出格式、语气有严格要求（比如要做结构化抽取、要严格控制字数），量化后一定要重新验证，不能默认它和原版行为一致。我的做法是准备一组固定的回归测试用例，每次换量化版本都跑一遍，对比输出差异。

3. 榜单怎么用才不会被带偏

公开榜单是选型的重要参考，但也是最容易让人误判的地方。我见过太多人只看榜单第一名就下手，结果发现根本不适合自己的场景。

3.1 主流榜单各自侧重什么

现在比较有影响力的公开榜单，大致可以分几类。一类是综合能力榜，覆盖知识、推理、数学、代码等多个维度，适合看模型的整体水平。一类是对话能力榜，靠人类或模型投票来排名，更贴近"聊天体验"。还有一类是特定任务榜，比如代码、数学专项。

综合榜的好处是全面，坏处是"平均分高"不等于"你的任务强"。对话榜主观性强，容易受投票人群偏好影响。专项榜针对性强，但覆盖面窄。我的建议是组合着看：先用综合榜圈定一个候选范围，再用专项榜和实际测试缩小范围。

3.2 榜单分数的"水分"在哪

榜单分数有几个常见的失真来源。一是数据污染，如果测试集的内容在训练数据里出现过，分数就会虚高。二是提示词敏感，同一个模型换个提示词模板，分数可能差好几个点。三是评测方式差异，有的用少样本，有的用零样本，有的让模型自己判断对错，标准不统一。

所以看到某个模型分数特别高，先别激动，去翻一下它的评测配置。如果评测细节不透明，或者明显用了对自己有利的设置，那这个分数就要打个折扣。

3.3 我自己的"三层筛选法"

结合上面这些，我总结了一个三层筛选的流程，你可以参考：

1. 第一层，硬性条件过滤：许可证能不能商用、显存跑不跑得动、支不支持中文。这一层直接砍掉一大半候选。
2. 第二层，榜单圈定：在剩下的候选里，看综合榜和专项榜，选出 3-5 个进入决赛。
3. 第三层，实测决胜：用自己真实的测试用例，把这 3-5 个模型跑一遍，看效果、速度、稳定性，选出最终的那个。

这个流程的好处是，每一步都有明确的淘汰标准，不会因为某个模型"看起来很强"就冲动选择。

4. 把模型放进真实任务里测：我的实操方法

前面讲的都是"怎么看"，这一节讲"怎么测"。榜单和参数都是参考，真正决定选型的，是模型在你任务上的实际表现。

4.1 准备一套属于你自己的测试集

这是整个选型过程中最重要的一步，也是最容易被跳过的一步。很多人直接拿网上的评测题来测，但那些题和你的业务场景往往差很远。

我的做法是，从真实业务数据里抽 20-50 条有代表性的样本，覆盖简单、中等、困难三个难度，每条都人工写好"期望输出"。这套测试集不用很大，但一定要真实、有代表性。比如你做的是合同信息抽取，那就抽各种格式的合同片段；你做的是客服问答，那就抽真实的用户提问。

测试集准备好之后，每次换模型或换量化版本，都跑同一套题，这样结果才有可比性。

4.2 评测维度不只是"对不对"

很多人评测只看答案对不对，其实还有几个维度同样重要：

• 忠实度：有没有编造原文没有的信息。这个在摘要、问答任务里特别关键。
• 格式遵循：要求输出 JSON 就输出 JSON，要求分点就分点，不能自由发挥。
• 稳定性：同一个问题问三遍，答案是不是基本一致。有的模型随机性太大，同一输入输出飘忽不定，这种在生产环境很难用。
• 速度：首 token 延迟和生成速度。交互式场景对首 token 延迟敏感，批量处理场景更看重吞吐。
• 长上下文表现：上下文拉长之后，效果会不会明显下降。很多模型标称支持很长上下文，但实际用起来，超过一定长度就开始"忘事"。

我一般会做一个简单的评分表，每个维度打 1-5 分，最后加权算总分。这样选出来的模型，是综合最优，而不是某一项特别突出但其他项拉胯。

4.3 一个真实的对比案例

说个具体的。之前我要做一个中文技术文档的问答系统，候选了三个开源模型：一个 7B 的通用模型、一个 14B 的通用模型、一个 7B 的中文优化模型。硬件是一张 16GB 显存的卡。

第一轮硬性过滤：三个都能跑，7B 的两个用 4-bit 量化后很轻松，14B 的用 4-bit 也能跑但上下文不能开太长。

第二轮榜单：14B 那个综合排名最高，7B 中文优化模型在中文专项上表现不错。

第三轮实测：我用 30 条真实技术文档问答测。结果 14B 模型准确率最高，但速度慢，首 token 延迟明显；7B 中文优化模型准确率略低，但速度快、格式遵循好；7B 通用模型两头不靠，被淘汰。

最后我选了 7B 中文优化模型，因为问答场景对响应速度要求高，准确率的差距在可接受范围内，而且它格式遵循更稳，方便做后续处理。这个结论如果只看榜单，是得不出来的。

5. 部署和推理框架的选择也会影响对比结果

同一个模型，用不同的推理框架跑，效果和速度可能不一样。这一点在对比时经常被忽略，导致"明明是同一个模型，怎么表现差这么多"。

5.1 常见推理框架的适用场景

llama.cpp 适合个人电脑、CPU 或混合推理，GGUF 格式，部署简单，是本地试水的好选择。Ollama 在 llama.cpp 基础上做了封装，一条命令就能拉模型跑起来，适合快速验证。vLLM 主打高吞吐，适合服务端批量推理，PagedAttention 对显存利用效率提升明显。TensorRT-LLM 性能强，但配置复杂，适合追求极致性能的场景。

我的建议是：本地验证用 Ollama 或 llama.cpp，生产部署用 vLLM。前者上手快，后者吞吐高。别一上来就折腾最复杂的框架，先把模型跑通、效果验证好，再考虑性能优化。

5.2 采样参数对结果的影响比你想的大

temperature、top_p、top_k 这些采样参数，直接决定输出的随机性。对比模型时，如果采样参数没统一，结果根本没法比。我一般会固定一套参数做对比，比如 temperature=0.1 做确定性任务，temperature=0.7 做创意任务。

还有个细节：不同模型的"最佳温度"不一样。有的模型温度稍高就胡说，有的温度太低就变得死板。所以对比时，除了固定参数，还要给每个模型单独调一下参数，找到它的最佳状态，再公平比较。

5.3 系统提示词要针对每个模型调

系统提示词（system prompt）对输出影响巨大。同一个提示词，在这个模型上效果好，换个模型可能就失灵。所以对比时，别用一套提示词套所有模型，要给每个模型都调一版，让它们各自发挥出最好水平，这样比出来的结果才公平。

这一步很费时间，但很值得。我见过太多对比，因为提示词没调好，把好模型给冤枉了。

6. 那些年我踩过的选型坑

讲了这么多方法，最后分享几个我实际踩过的坑，都是血泪教训，希望能帮你少走弯路。

6.1 盲目追新，忽略了生态成熟度

新模型发布时，往往只有权重，配套的工具链、量化版本、部署文档都不完善。我有次追一个刚发布的新模型，结果发现量化版本要等好几天，部署踩了一堆坑，最后效果也没比老模型好多少。新模型可以关注，但生产环境优先选生态成熟的，工具链完善、社区活跃、有问题能搜到答案，这些隐性成本很重要。

6.2 只看单次效果，忽略了长期稳定性

选型时跑几次测试，效果很好，就定了。结果上线后发现，模型在某些输入上会突然"抽风"，输出完全不可控。后来才知道，那个模型对特定格式的输入特别敏感。所以测试时一定要覆盖边界情况，别只测"正常"输入。

6.3 忽略了 tokenizer 的差异

不同模型的 tokenizer 不一样，同样一段中文，token 数可能差很多。这直接影响上下文长度、推理成本和速度。我有次对比两个模型，一个看起来快，后来发现是它的 tokenizer 把中文切得更碎，实际处理同样内容用的 token 更少。所以对比速度时，要按"处理同样内容"来比，而不是按"生成同样 token 数"来比。

6.4 忘了算总成本

选型不能只看模型效果，还要算总成本：显存成本、推理时间成本、维护成本。一个效果略好但需要双倍显存的模型，可能并不划算。我现在的习惯是，把效果和成本放在一起看，算一个"性价比"，而不是单纯追求效果最好。

7. 给不同场景的选型建议

最后按几个常见场景，给点具体的选型方向。注意这些是方向性的建议，具体还得结合你的实测。

7.1 个人学习和本地试水

硬件有限、想快速上手的话，优先选 7B-8B 的 4-bit 量化模型，用 Ollama 拉下来就能跑。这个规模在消费级显卡上体验比较流畅，通用能力也够用。别一上来就挑战大模型，先把流程跑通，理解模型的行为特点。

7.2 中文知识库问答

这类场景对中文理解、忠实度、格式遵循要求高。建议优先选中文语料训练充分、指令遵循好的模型，规模上 7B-14B 是甜点区。配合 RAG（检索增强生成）使用时，模型的"忠实于给定材料"能力比"自身知识量"更重要，选型时要重点测这一点。

7.3 代码辅助

代码任务对模型的代码能力要求高，建议选在代码专项榜单上表现好的模型。规模上 7B 起步，14B-32B 效果更好。要注意的是，代码任务对上下文长度要求高，选型时要重点测长上下文下的代码理解能力。

7.4 结构化信息抽取

这类任务要求模型严格按格式输出，对格式遵循和稳定性要求极高。建议选指令遵循强、输出稳定的模型，规模不用太大，7B 往往就够。测试时要重点看它在复杂嵌套结构、边界情况下的表现。

选型这件事，没有一劳永逸的答案。模型在变，你的任务也在变，最好的办法是建立一套自己的评测流程，每次有新模型出来，用同一套标准快速过一遍，这样既能跟上节奏，又不会被带偏。我自己现在就是这么做的，一套测试集、一个评分表，新模型来了先跑一遍，几分钟就能有个初步判断，比看十篇评测文章都管用。