1. 为什么现在聊开源模型对比时机刚刚好过去一年多我自己的机器上跑过的开源模型少说也有二十几个从最早拿一张消费级显卡硬扛 7B到后来折腾量化档、上下文长度、推理框架踩的坑基本能写一本小册子。LLM 开源模型对比这件事放在今天这个时间点特别有意义闭源模型的能力还在往上走但开源这一侧已经不再是“能跑就行”的玩具很多场景下它已经能顶上来干活了。尤其是做本地知识库、私有化部署、垂直领域微调的朋友选错一个模型后面几周的调优全白费。这篇内容我想干的事很明确把“开源模型对比”这件事从“看榜单排名”拉回到“看你的实际需求”。我会讲清楚对比到底该比什么、哪些指标是营销噪音、哪些参数真正决定你跑不跑得动、以及我自己在选型时的一套判断流程。适合谁看如果你正在纠结“现在开源小模型有好用的么”、想搭本地 RAG、想给团队选一个能私有化部署的底座或者只是想知道 open LLM leaderboard 这类公开榜单该怎么读那这篇就是写给你的。基础不用太深我会把该补的背景都补上。先说一个我反复验证过的结论开源模型没有“最强”只有“最合适”。同一个模型在 A 场景里是神器换到 B 场景可能连及格线都够不到。所以对比的核心不是排座次而是建立一套属于你自己的评估坐标系。2. 对比之前先搞清楚你到底在比什么2.1 参数规模不等于能力但决定了你的硬件下限很多人一上来就问“哪个模型最强”这问题本身就问错了。参数规模7B、13B、32B、70B 这些首先决定的不是智商而是你能不能跑得动。我见过太多人兴冲冲下了个 70B结果发现自己那张卡连加载都费劲。粗略的经验值是这样的FP16 精度下推理显存需求大约是参数量的 2 倍再加一点开销。也就是说 7B 大概要 14-16GB13B 要 26GB 上下70B 直接奔着 140GB 去了。这个数字不是绝对的因为还跟上下文长度、批大小有关但量级不会错。所以选模型的第一步永远是先看自己手里有什么硬件而不是先看榜单。提示如果你只有一张 8GB 或 12GB 的消费级卡别硬上大模型老老实实看 7B 及以下的量化版本体验反而更顺。2.2 量化档让大模型塞进小显存的关键手段量化是我认为最被低估的一环。简单说量化就是把模型权重从高精度比如 FP16压到低精度比如 INT8、INT4用一点点精度损失换取大幅度的显存和速度收益。你可以把它类比成把无损音乐转成高码率 MP3——大部分时候你听不出差别但文件小了一大半。常见的量化档有这么几类INT8 基本无损显存减半INT4 会有可感知的损失但通常还能用再往下还有更激进的 3bit、2bit那就得看具体模型和任务了做知识问答可能还行做代码生成就容易崩。我自己的习惯是能上 INT8 就上 INT8显存实在不够再退到 INT4并且一定要实测任务效果再决定。这里有个坑要提醒不同量化方案GPTQ、AWQ、GGUF 等的实测表现差异不小同一个模型同一个 bit 数换个量化方法可能效果差一截。所以看“开源模型量化档排名”的时候一定要看清楚它用的是哪种量化格式别把不同格式的分数混着比。2.3 榜单怎么读open LLM leaderboard 的正确打开方式open LLM leaderboard 这类公开榜单是很好的起点但绝对不是终点。它测的多是通用能力常识推理、阅读理解、数学、代码这些。问题是你的任务大概率不在它的测试集里。我读榜单的习惯是三步第一先看它测了哪些维度找到跟你任务最接近的那一列第二看模型大小和量化档把跑不动的直接划掉第三把剩下的两三个候选拉下来用我自己的数据实测。榜单只负责帮你把候选从几十个缩到三五个剩下的活必须自己干。把榜单当圣旨的人最后往往发现“榜上很强”的模型在自己的场景里平平无奇。2.4 中文能力很多榜单测不出来的短板这一点必须单独拎出来说。不少在英文榜单上表现亮眼的开源模型中文能力其实很一般尤其是涉及中文语义理解、成语、专业术语的时候。如果你的场景是中文为主——比如中药处方审核、公立医院相关的文本处理、本地 ERP 的中文产品检索——那英文榜单的参考价值要打不少折扣。我的做法是准备一套自己的中文测试题覆盖几个维度基础问答、长文本理解、专业术语、指令遵循。同一套题跑所有候选模型横向对比。这套题不用多复杂二三十条就够但一定要是你真实业务里会遇到的问法。3. 主流开源模型横向拆解与选型逻辑3.1 按使用场景分档而不是按名气排队我把常见的开源模型按使用场景分成几档这样对比起来更有针对性。第一档是通用对话与轻量助手代表是各种 7B、8B 级别的模型。它们的优势是跑得快、显存友好适合做本地助手、简单问答、文本润色。缺点是复杂推理和长链条任务容易掉链子。第二档是知识库与 RAG 底座这类场景对模型的要求很特别它不需要多强的创造力但需要准确地理解检索回来的内容并忠实作答。这时候模型的“幻觉倾向”比“智商”更重要。我实测下来有些参数不大的模型在 RAG 场景里反而比大模型更稳因为它不太会自己加戏。第三档是代码与结构化输出代表是各种代码专精模型。这类模型在生成 JSON、SQL、代码片段时格式稳定性明显更好做 LLM 网关、工具调用tool payload这类任务时优势很大。第四档是垂直领域微调底座比如医疗、法律、金融。这类场景通常需要你有自己的数据做微调所以选底座时更看重“可微调性”和“生态支持”而不是开箱即用的分数。3.2 上下文长度被严重低估的选型指标上下文长度这个参数很多人选型时一扫而过但它对实际体验的影响巨大。做 RAG 的时候你要把检索到的多段内容塞进 prompt上下文不够就直接截断答案质量断崖式下跌。做长文档分析、会议纪要、代码库理解更是吃上下文。现在的开源模型上下文从 4K 到 128K 都有但要注意标称上下文和有效上下文是两回事。很多模型标 32K实际用到 16K 之后就开始“忘记”前面的内容。我一般会做个“大海捞针”测试把一条关键信息埋在长文本中间看模型能不能准确捞出来。能捞出来的长度才是它真正可用的上下文。3.3 推理框架的选择模型跑得好不好一半看框架同一个模型换个推理框架速度和显存占用可能差出一大截。常见的框架各有侧重有的主打吞吐量适合服务化部署有的主打低显存适合个人机器有的对量化格式支持更全。我的经验是个人本地玩优先选对 GGUF 和低比特量化支持好的框架团队服务化优先选并发吞吐强的框架。别小看这个选择我见过有人抱怨模型慢结果换了个框架直接快了三倍模型根本没换。3.4 一张表看懂选型决策路径你的情况优先考虑建议参数档关键指标单卡 8-12GB个人玩7B/8B 量化版INT4/INT8显存占用、响应速度单卡 24GB做知识库13B/14BINT8中文理解、幻觉率多卡或大显存做服务32B/70BFP16/INT8吞吐、并发、上下文代码/工具调用为主代码专精模型按显存定格式稳定性、指令遵循垂直领域微调生态好的底座按数据量定可微调性、社区支持这张表不是标准答案但它能帮你快速把候选范围缩小。选型最怕的就是漫无目的地试有个决策路径会高效很多。4. 实操从零搭一套自己的模型对比流程4.1 准备一套属于你的评测集这是整个流程里最重要的一步也是最容易被跳过的一步。别人的榜单再权威也不如你自己的一套题。我的评测集一般包含四类基础能力题常识问答、简单推理用来筛掉明显不行的。业务场景题直接抄你真实业务里的问法20-30 条。边界测试题故意问一些模型不该答的、模糊的、超纲的看它会不会胡编。格式测试题要求输出 JSON、表格、特定结构看格式稳定性。每道题我都准备一个“及格线”答案不追求完美只判断“能不能用”。这样评起来快也不容易被模型的华丽措辞带偏。4.2 统一环境控制变量对比最忌讳的就是环境不一致。我一般会固定这几样同一台机器、同一个推理框架、同一套量化格式如果要比量化档就固定其他变量、同样的温度和 top_p 参数。温度我通常设 0.1-0.3做知识问答要的是稳定不是创意。注意不同模型的推荐采样参数不一样有的模型官方建议温度 0.7你硬用 0.1 可能反而效果差。所以严格来说应该先用官方推荐参数跑一遍再用统一参数跑一遍对比两次结果。4.3 记录与打分别凭感觉我见过太多人对比模型全凭“感觉这个好”结果过两天就忘了为什么好。我的做法是建一张表每个模型每道题记录回答内容、是否及格、耗时、显存峰值。跑完一轮横向一拉谁强谁弱一目了然。打分我用三档能用、勉强、不能用。不做精细的 1-10 分因为精细打分的主观性太强反而不可靠。三档足够做决策了。4.4 一个可复现的对比脚本骨架下面这段是伪代码思路具体 API 按你用的框架调整。核心是“批量跑、统一记录”。# 伪代码批量对比多个模型 models [model_a, model_b, model_c] test_cases load_test_cases(my_eval_set.json) results [] for model in models: for case in test_cases: start time.time() answer run_inference(model, case[prompt], temperature0.2) elapsed time.time() - start results.append({ model: model, case_id: case[id], answer: answer, elapsed: elapsed, passed: judge(answer, case[expected]) }) save_results(results, comparison_result.csv)跑完之后按模型聚合一下及格率和平均耗时基本就能看出谁适合上场了。4.5 显存与速度的实测方法显存峰值我一般用框架自带的监控或者系统层面的显存查询工具跑推理的时候盯着看。速度分两个指标首 token 延迟和每秒生成 token 数。前者影响“感觉快不快”后者影响“长回答要等多久”。做交互式应用首 token 延迟比吞吐更重要做批处理吞吐才是关键。这两个指标一定要在你的目标上下文长度下测。很多模型短上下文飞快一上长上下文就拉胯这个差异只有实测才知道。5. 常见问题与避坑经验实录5.1 为什么榜上很强的模型我用起来很一般这是最高频的困惑。原因通常有三个一是榜单任务和你的任务不匹配二是你没用对采样参数三是你的 prompt 写法不适合这个模型。我遇到过同一个模型换个 prompt 模板效果从“不能用”变成“挺好用”。所以模型效果差的时候先别急着换模型先调 prompt 和参数往往能救回来。5.2 量化之后效果崩了怎么办先确认是不是量化档太低。INT4 崩了试试 INT8还崩可能是这个模型的量化版本本身做得不好换个量化方案或换个来源。另外有些任务对量化特别敏感比如数学和代码这类任务尽量用高精度。我的原则是关键任务不用最低量化档。5.3 中文场景下模型“答非所问”多半是模型的指令遵循能力在中文上打了折扣。解决办法把指令写得更明确、更结构化少用委婉表达把关键约束放在 prompt 开头和结尾中间容易被忽略必要时用 few-shot 给一两个例子。我实测下来加两个中文示例很多模型的中文表现能明显提升。5.4 长上下文“记不住”前面的内容这是通病。除了选真正长上下文能力强的模型还可以用一些技巧把最关键的信息放在 prompt 最前面或最后面用明确的分隔符标记不同段落把长任务拆成多轮。别指望模型能完美记住 32K 里的每一个字那不现实。5.5 常见问题速查表现象可能原因排查方向回答很慢模型太大/量化档太高/框架不合适换小模型、降量化、换框架显存爆了上下文太长/批太大减上下文、降批大小、量化中文答非所问指令不清晰/模型中文弱改 prompt、加示例、换模型格式不稳定模型指令遵循弱换代码专精模型、加格式约束长文本丢信息有效上下文不足换模型、调整信息位置量化后变笨量化档太低升到 INT8、换量化方案5.6 几个我踩过的坑第一个坑盲目追新。新模型发布节奏很快但不是每个新模型都适合你。我现在会等一两周看看社区实测反馈再决定要不要试。第二个坑忽略推理框架的版本。同一个框架不同版本对同一个模型的支持可能差很多。升级框架前先看更新日志别手贱直接升。第三个坑拿单条测试下结论。一条题答得好不代表模型好答得差也不代表模型差。一定要跑完整套评测集。第四个坑忘了算总成本。大模型不只是显存贵电费、时间、维护都是成本。有时候一个小模型加好的 RAG整体效果和成本都优于硬上大模型。6. 把模型接进真实系统时的几个关键点6.1 RAG 场景下模型和检索要一起调做本地知识库的时候很多人只调模型忽略检索。实际上 RAG 的效果是“检索质量 × 模型理解”的乘积。检索回来的内容不对再强的模型也白搭。我的做法是先固定一个中等模型把检索调好检索稳定了再换模型对比。这样能避免把检索的问题误判成模型的问题。6.2 工具调用与结构化输出对模型的要求如果你要做 LLM 网关、让模型调用工具、输出结构化 payload那模型的“格式稳定性”比“知识量”重要得多。这类任务我强烈建议用代码专精或经过工具调用训练的模型普通对话模型经常在 JSON 格式上翻车。实测下来格式稳定性好的模型能省掉大量后处理代码。6.3 私有化部署时的模型选择私有化部署要考虑的不只是效果还有授权、可维护性、社区活跃度。授权不清晰的模型商用要谨慎社区不活跃的模型遇到问题没人帮你。我选私有化底座时会优先看它的更新频率、issue 响应速度、有没有成熟的微调工具链。这些“软指标”在长期使用中比一时的分数更重要。6.4 微调前先想清楚值不值得微调不是万能药。很多问题用 prompt 工程和 RAG 就能解决硬上微调反而费时费力。我的判断标准是如果问题是“模型不知道某个知识”优先 RAG如果问题是“模型知道但输出风格不对”才考虑微调。微调需要高质量数据数据不好微调出来的模型还不如原版。7. 我个人的选型心得折腾了这么多模型我最大的体会是别追求一步到位要追求快速迭代。先用一个能跑起来的小模型把整个流程打通再逐步替换升级。很多人卡在“选哪个最好”上迟迟不动手结果一个月过去什么都没搭起来。另一个心得是建立自己的评测资产。那套评测集、那张对比表、那些踩坑记录才是你真正的护城河。模型会过时但你的评估能力不会。每次新模型出来你都能快速判断它值不值得试这个能力比记住任何榜单都有用。最后分享一个小技巧我会给每个试过的模型写一句话备注比如“中文稳但慢”“快但格式爱崩”“适合 RAG 不适合创作”。攒到几十条之后再选型时翻一翻比重新测一遍快得多。这个习惯帮我省了大量重复劳动也让我对每个模型的特点越来越有手感。
