开源模型对比

你打算挑一个开源模型自己部署，翻了一圈资料，发现每篇都在拿不同任务、不同量化、不同卡说事，比出来的结论根本没法用。这篇不讲哪家强，而是给你一套自己动手比的口径：先定任务，再卡许可证，最后才落到显存和算力，顺带把常见的比错地方列出来。

你打算挑一个开源模型自己部署，翻了一圈资料，发现每篇都在拿不同任务、不同量化、不同卡说事，比出来的结论根本没法用。这篇不讲哪家强，而是给你一套自己动手比的口径：先定任务，再卡许可证，最后才落到显存和算力。

核心思路是把「选型」拆成一条固定顺序的流水线：任务钉死、许可证过筛、能力对齐、成本算清、链路跑通。任何一步没过就别往下走，否则你会在最贵的地方返工。下面逐节说清楚每一步怎么落地、什么情况下不适用。

为什么网上的开源模型对比大多没法直接用

同一模型在不同量化档位、不同推理框架下的表现差别，常比模型之间的差别还大。你看到的对比视频往往只贴一段对话，没交代提示词、温度、上下文长度，甚至没说是哪一档量化，这种结论对你几乎没有参考价值。

• 参数量相近不等于能力相近，训练数据构成和是否续训的影响更大
• 很多对比只测单轮短问答，长上下文和结构化输出完全没覆盖
• 截图里的回答通常是对方挑过的最好一次，稳定性无从判断
• 硬件不同会让同一模型的可用性天差地别，尤其是显存吃紧的时候

第一步：先把任务钉死，再谈选谁

先写清三件事：输入是什么、输出要什么格式、错一次代价多大。这三件事决定了你后面看哪类榜单、卡哪条许可证、留多少余量。任务没钉死就去看模型排行，等于先把答案抄了再做题。

通用问答

看指令跟随和拒答边界，别用代码榜单来选

结构化抽取

只看 JSON 或字段格式合规率，内容对但格式崩就算失败

代码

看补全和改错的通过率，注意是否支持你的语言和框架

长文档

看长上下文下的召回是否衰减，短窗口好不代表长窗口好

多模态

图文输入要先确认权重和推理框架都支持

给任务配一组自己的小测题，二三十条就够，比跑公开榜单省时间也更准。题目要覆盖正常输入、边界输入和最容易出错的格式输入三类，评分标准提前写死，避免事后找补。

不适用的情况：探索性任务、还没想清楚要什么输出的阶段，先别做横向对比。这时候你需要的是快速试错，不是选型决策，过早锁死任务反而会漏掉更合适的路线。

第二步：许可证与商用边界先过一遍

分清权重可下载、可商用、可再分发是三件不同的事，很多限制写在附加条款里而不是主协议。公司内部用和打包进产品卖给客户，适用条款可能不一样，这一步先过筛能省掉后面大量返工。

拿不准就按最严的理解处理，或到站内合规页面核对条款口径。条款会更新，你引用的必须是当时版本，别用两年前别人整理的摘要来下结论。

第三步：能力怎么比才不跑偏

优先看跟你任务同类的专项榜单，综合榜单容易被通用能力拉平，掩盖掉你真正关心的那一项。看榜单时先确认题目是否饱和、是否自评分、评测时间是否过期，这三条任意一条出问题，名次参考价值就大幅下降。

1. 准备盲测集把第一步的小测题复制一份，去掉任何能暗示来源的标记，分发给几个候选模型跑同一批输入。
2. 同参数跑一遍温度、最大输出长度、提示词模板全部保持一致，任何一项不同都要在记录里标明。
3. 人工或模型盲评让评审只看输出不看模型名；人手不够时可以用另一个模型做初筛，但最终结论要人工复核一遍。
4. 记录格式合规率内容对但 JSON 崩、字段缺、多出解释性文字，都算这次失败，统一计入成功率。

把回答长度、格式合规率一起记录，很多模型是败在格式不稳而不是内容不对。这个区别很重要：内容不行是模型选错，格式不稳是提示词或后处理的问题，修后者通常便宜得多。

第四步：算清部署成本，别只看参数量

成本由三块构成：显存占用决定用几张卡、量化档位决定质量损耗、吞吐决定单位请求耗时。参数量只是间接影响这三项，直接拿参数量当成本代理会算歪。

• 按峰值并发算卡数，而不是按平均并发，否则上线就排队
• 把闲置成本算进去：卡租来跑不满的时间，也是钱
• 长上下文请求的显存和延迟是非线性增长的，配额要单独留
• 量化档位每降一档，都要用你的小测题重测一次，不能默认损失可接受

自建与按量调用哪条更划算，取决于你的调用量是否稳定。量小且波动大时，租卡的固定成本很难摊平；量稳定且可预测时，自建的单请求成本优势才会体现出来。具体单价去站内价格追踪页面核对当时的数字，别用记忆里的旧报价做决策。

第五步：部署链路能不能跑通

能力再好、成本再低，跑不起来就是零。这一步按顺序排查，任何一项不通就先别继续往后做容量规划。

1. 查推理框架支持确认你选的框架对目标模型架构是否已适配，新发布的模型常常要等社区或官方分支跟进。
2. 查许可证与平台匹配确认许可证能否用于你选的托管平台，有些平台对特定权重有额外要求或限制。
3. 查卡型与驱动确认目标卡型的显存和驱动版本，国产卡还要单独看是否有可用适配分支。
4. 小流量试跑先用少量真实请求跑一段，观察首字延迟和长上下文下的显存增长，确认没有缓慢爬升的泄漏迹象。

一张对照表该放哪些列

这张表是你选型汇报的底稿，列要固定，行是候选模型。每格只填结论和依据来源，不要把原始数据堆进来，否则表格会失控。

迁移成本这一列容易被忽略：换掉一个模型要改多少提示词、多少下游代码。如果你已经适配过某个模型的输出格式，换模型的真实代价可能比小测题分数差距更大，这一列要单独评估，不能只看得分。

几个最常见的比错地方

• 拿别人量化后的效果和原版比，把量化损失算成模型差距
• 用单轮短问答的体验推断长文档表现
• 忽略上下文长度对显存和延迟的非线性影响
• 把榜单名次当成业务效果，跳过自己的小测题
• 在没确认许可证的情况下先做完技术选型，最后发现不能商用

这几个坑的共同点是：把别人的评测条件当成自己的条件。每次对比前先把条件列出来对照一遍，就能挡掉大部分错误结论。真拿不准的时候，回归第一步——你的任务是什么。

开源模型选型比的不是谁分数高，而是谁在你的任务、你的许可证边界、你的卡上，跑得最稳。