我最近把几台机器上的小模型翻出来重跑，桌面端、边缘盒子、云上容器各放了一版。跑完一圈的感受是，聊“小参数模型”不能只看参数量，模型家族、训练数据、量化方式、推理框架都会把体验拉出差距。我做这份对比，想先把讨论范围、评测口径和实验纪律摆清楚，后面的排行榜解读和速度显存数据才有可比性。
1.1 小参数模型的定义、参数范围与典型应用场景
我先把小参数模型理解成参数量在10B以下、常见落在0.5B到8B之间的一类模型。行业里也有把13B以内算进来的说法，做端侧部署时我更倾向看3B以内，做私有化服务会放到7B到8B。这个范围不是硬边界，模型结构、词表大小、上下文长度都会影响实际资源占用。我常提醒团队，参数只是入口标签，真正决定能不能落地的是内存、时延和任务效果。沟通项目时我会先问一句“你说的小模型大概多大”，把范围对齐，后面选型少走弯路。
典型场景我分几类来看。端侧助手、离线翻译、会议纪要摘要、工单分类、客服知识库问答、代码补全，这些任务对时延和隐私更敏感，小模型有天然优势。边缘盒子做视觉语言联动时，1B到3B模型能留出更多显存给其他模块。在线服务里，小模型常被用来做路由、意图识别、草稿生成，把大模型调用留给复杂请求。我接触的私有化项目里，7B级模型在单卡或双卡上就能跑，运维负担比大模型轻不少。
从产品经理视角看，小参数模型是“够用就好”的选项；从开发者视角看，它是可微调、可量化、可快速迭代的底座；从运维视角看，它是能塞进现有资源池的组件。我写这段定义，想让后面的对比有共同语言，避免把不同量级的模型混在一张表里硬比。
1.2 综合表现对比的核心维度：能力、效率、部署成本与可用性
核心维度我习惯拆成四块：能力、效率、部署成本、可用性。能力看知识问答、指令遵循、数学代码、长文本和多语言；效率看首token时延、单token时延和吞吐；部署成本看显存、硬件价格、量化损失和运维人力；可用性看稳定性、工具调用、结构化输出、生态和许可证。四块放在一起看，才接近真实选型。
我跑评测时会先问任务最怕什么。客服场景怕答错和超时，端侧场景怕内存爆和发热，私有化场景怕许可证和升级困难。能力分数高不等于可用性好，一个模型在榜单上很漂亮，接入业务系统后JSON输出不稳定，团队就要花时间补规则。效率也不是越快越好，量化到很低比特后输出质量掉下来，用户会立刻感知。
部署成本里我特别看隐性开销。模型权重只占一部分，KV Cache、批大小、上下文长度会把显存推高。可用性还涉及推理框架支持、社区更新频率、文档完整度。我的判断是，四个维度没有固定权重，任务不同权重就变，评测框架要允许读者按场景调整。
1.3 小参数模型评测基准与排行榜的选取原则
评测基准的选取，我倾向于“公开基准打底，业务样本校准”。公开基准覆盖通用知识、中文理解、数学、代码、指令遵循、长文本和多语言，方便横向比较。业务样本用几十到几百条真实请求，检查格式遵循、拒答边界和领域术语。只靠公开榜单容易高估，只靠业务样本又缺少外部参照。
排行榜我会看版本和口径。同一个模型名，量化版、对话版、基座版差别很大；评测时的提示词模板、少样本数量、解码参数、是否用工具，都会改变分数。我常做一张小表，记录榜单名称、更新时间、评测集版本、模型版本、硬件和推理框架。缺少这些信息的榜单，我只会当线索，不会当结论。
我把选取原则写成几句口语：任务覆盖要够宽，评测脚本要能复现，模型版本要写清楚，硬件和量化条件要一致，刷榜风险要留神。中文场景要多看C-Eval、CMMLU这类基准，代码看HumanEval和MBPP，数学看GSM8K和MATH，对话体验看MT-Bench、AlignBench一类。多语言和长文本要单独补测，短榜单很难反映这两块。小参数模型综合表现对比里，基准选得松，结论就容易飘。
1.4 对比实验设计中的变量控制与可复现性要求
对比实验设计里，我先把变量分成“模型侧”和“环境侧”。模型侧包括参数量、训练阶段、量化方式、上下文窗口、词表；环境侧包括GPU型号、驱动、推理框架版本、批大小、并发数、评测脚本版本。做速度对比时，我会固定输入输出长度和批大小，记录预热次数和重复次数。做能力对比时，我会固定提示词模板、少样本示例、温度、top_p和最大输出长度。
可复现性靠记录，不靠记忆。我习惯把每次实验的配置文件、随机种子、模型哈希、容器镜像、原始输出都存档。团队复现时，先跑一遍冒烟测试，确认分数和时延落在预期区间，再扩到全量。量化模型要额外记录校准数据、量化工具和精度设置，这些细节会直接影响结果。
我还建议把“失败样本”保留下来。看一个模型哪里答错、哪里超时、哪里格式崩掉，比只看平均分更有用。实验设计不需要追求绝对完美，透明和一致更重要。读者拿到我的记录，能按同样条件重跑，也能按自己的硬件调整，这份对比才有长期价值。
我把主流小模型拉出来跑了一轮通用能力评测，桌面上摊着几份榜单截图。同一个小模型，在MMLU上排中游，在C-Eval上蹿到前面，换个指令遵循基准又掉下去。这种起伏让我警觉，能力评测不能只看一个总分，得拆开看它到底强在哪、弱在哪、榜单口径又怎么定的。
2.1 通用能力基准对比：知识问答、语言理解与指令遵循
知识问答这块，我主要看MMLU和C-Eval。Qwen2.5系列在7B档的知识覆盖明显扎实，3B版本在中文常识题上也不虚，错得比较集中，基本都落在特别偏门的领域知识。Llama 3.2的3B版本英文知识面宽，中文语境下偶尔会给出似是而非的答案。Gemma 2的2B模型知识密度不低，可它回答风格偏简略，采分点上容易吃亏。我在评测时发现一个细节：同一道题，提示词里加一句“请分点作答”，得分能差出三到五个百分点。这件事提醒我，知识问答的分数不完全等于知识量，也包含了模型对答题格式的理解。
语言理解我重点看HellaSwag、PIQA和ARC这几项。小模型在这类任务上的差距没有知识问答那么夸张。Phi-3-mini的语言推理表现相当稳，1B到4B档里算一股清流。MiniCPM在中文语义理解上做得细，涉及歧义句和指代消解时表现比同量级模型干净。我个人体感是，3B以上的小模型在基础语言理解上已经够用，真正拉开差距的是指令遵循——能不能听明白“用表格输出”“不要超过五十字”“先列条件再给结论”这类约束。
指令遵循我拿IFEval和自建的任务模板做交叉验证。这一块结果最让我意外。部分在知识榜单上很能打的模型，一旦要求严格遵循格式，崩得很快。Qwen2.5-7B在结构化输出上比较靠谱，JSON和Markdown表格基本不跑偏。Llama 3.2的1B版本轻量灵活，复杂多条件指令偶尔会漏掉其中一条。我拿十条真实业务指令测了一圈，发现“指令遵循”和“模型大小”不是线性关系，训练数据的指令配比和微调策略影响更大。有个3B模型在IFEval上咬了7B模型一口，查了一下，它的SFT数据里指令多样性做得特别足。
2.2 专项能力基准对比：数学、代码、推理、长文本与多语言
数学这块我盯GSM8K和MATH两个基准。小学应用题级别，7B档的几个主力模型都能跑到八成以上，3B档在六到七成之间浮动。Qwen2.5-Math系列单独做了数学增强，7B版本在MATH上的表现比通用版本高出一截。我拿同一道多步应用题测几个模型，发现错误类型很不一样：有的模型列式对了计算出错，有的模型读题就偏了。纯看总分看不出这些，得看错题分布。Phi-3-mini在数学推理上的表现超出它这个体量该有的水平，训练数据里数学语料占比应该不低。
代码能力我主要看HumanEval和MBPP。这一块的梯队分化比数学还明显。7B档的Qwen2.5-Coder和DeepSeek-Coder在Pass@1上能摸到六十分上下，3B档普遍在四十多分徘徊。我实际拿来写Python脚本，小模型处理单函数补全问题不大，涉及多文件上下文或库版本兼容时就开始犯迷糊。Gemma 2的2B在代码任务上表现中规中矩，生成风格偏保守，不太敢用新语法。
推理能力我拆成常识推理和逻辑推理两块看。常识推理靠HellaSwag这类基准，小模型之间差距有限。逻辑推理我用自建的多步演绎题测，结果相当分散。有些模型看着聪明，一到需要严格传递关系的题目就乱。长文本我拿LongBench和“大海捞针”测试做参考，7B模型在8K上下文内基本能保持检索准确率，超过16K就开始衰减。多语言我重点看中文、英文、日文和西班牙文，Qwen2.5的多语言覆盖在小模型里算广的，Llama 3.2的官方多语言支持也不错，冷门语种上大家普遍偏弱。我自己的经验是，多语言能力别信榜单总分，按目标语种单独测，花不了多少时间。
2.3 公开排行榜的横向解读方法与梯队划分
公开排行榜我每周刷一遍，Open LLM Leaderboard、LMSYS Chatbot Arena、C-Eval榜单、CMMLU榜单，还有几个中文社区维护的聚合榜。看榜第一件事是核对版本。榜单上写“Qwen2.5-7B”，我得点进去看是Instruct版还是Base版，是FP16还是GPTQ量化版。这几个版本之间的分数差，有时候比相邻两名模型的差距还大。我吃过一次亏，拿量化版分数跟人家全精度版比，结论直接翻车。
横向解读我有一套土办法：先把同参数档的模型拎出来排一排，再看它跟上一档的差距有多大。7B档内部的分数咬得很紧，前三名之间往往只差零点几分。这种时候我不看排名，看分项。一个模型总分排第五，但代码和指令遵循两项排第二，那它在特定场景里的价值就比排名高。梯队划分我按用途来：3B以下算轻量梯队，适合端侧和路由任务；3B到5B算中间梯队，能扛一些复杂指令；6B到8B算主力梯队，私有化部署和在线服务的主力。这个划分不是官方标准，是我自己用着顺手的切法。
榜单的“含金量”我也看来源。有的榜单更新勤，评测脚本公开，模型提交有审核，可信度高。有的榜单几个月不更新，评测集版本老，模型版本对不上，参考价值就打折。我习惯同时看两三个榜单，交叉验证。一个模型在A榜排前十、B榜掉到二十名开外，我就去翻它的评测配置差异，十有八九是提示词模板或few-shot设置不同。这种偏差不是造假，是口径问题，读者得心里有数。
2.4 榜单结果的局限性、评测偏差与复现注意事项
我越来越觉得榜单分数是个“压缩包”，解压之后信息量有限。基准测试集本身有生命周期，GSM8K刚出来时区分度很高，现在7B档模型普遍刷到八九十分，天花板效应明显。数据污染也是老问题，有些模型的训练数据里混进了测试集，分数虚高。我判断污染程度有个笨办法：看模型在“变体题”上的表现。把原题改个数字、换个问法，分数掉得厉害，污染嫌疑就大。
评测偏差我遇到最多的三种：提示词偏差、解码偏差和硬件偏差。提示词差一个标点，指令遵循类基准的分数就能跳。温度设0和设0.7，生成式任务的得分不一样。硬件偏差在速度评测里更突出，能力评测里相对小，但推理框架版本不同也会影响输出。我复现别人榜单结果时，先对齐模型版本和评测脚本，再对齐提示词和解码参数，最后才看分数。对不上的时候，我把两边原始输出拉出来对比，十次有八次能定位到差异来源。
复现注意事项我总结成几条：模型哈希要记，评测集版本要记，提示词模板要存，解码参数要写，原始输出要留档。量化模型额外记校准集和量化工具版本。我吃过“随便跑跑”的亏，隔了两周想复现，发现当时用的提示词没存，只能重来。现在我的习惯是，跑评测前先把配置文件写好，跑完把输出和分数一起归档。这套流程不复杂，能省掉后面大量扯皮的时间。榜单是路标，不是终点，读者拿这些分数做参考时，最好自己也跑一遍小样本验证，心里才踏实。
说起来有点好笑，我一开始评测小模型只顾着看分数，直到有次在树莓派上跑一个3B模型，风扇嗷嗷转了两分钟才吐出第一个字，我才意识到“能答对”和“能好好答”是两码事。这一章我打算把速度、显存这些工程指标的对比过程摊开讲讲，都是我自己踩过坑的一手记录。
3.1 推理速度评测指标：首 token 时延、单 token 时延与吞吐量
我评测速度的习惯是分三层看：首token时延、单token时延，还有吞吐量。这三个指标对应三种完全不同的用户体感。首token时延决定了你按下回车之后要干等多久才看到反应，单token时延决定了文字往外蹦的流畅感，吞吐量决定了你同时开五个对话窗口时会不会集体卡死。我拿Qwen2.5-3B在RTX 4090上测过，FP16精度下首token时延大概在180毫秒上下，单token时延不到20毫秒，肉眼看不出卡顿。换到一台只有CPU的老笔记本上，同样的模型首token时延直接飙到1.5秒，单token时延接近80毫秒，读起来像被人按了慢放键。
首token时延这块，预填充阶段的计算量跟输入长度强相关。我拿一段两千字的文档做摘要任务，7B模型的填充阶段耗时比空上下文时翻了将近四倍。这个数字在短对话里感觉不到，做文档问答或者RAG场景就会很明显。单token时延主要受解码阶段计算和显存带宽限制，小模型在这项上的优势比预填充阶段更明显，参数量小、每步计算量低，7B和3B之间的单token时延差距有时候能到两倍以上。我测速度时习惯固定输出长度，比如强制生成128个token，把首token时延和后续解码时间分开记，不然数据混在一起没法比。
吞吐量我分两个口径测：单请求生成速度和并发吞吐。单请求看的是tokens per second，并发吞吐看的是不同批大小下的总吞吐拐点。我拿vLLM跑7B模型，批大小设到8的时候总吞吐比单请求高了五六倍，但单请求延迟会略微上浮。小模型在吞吐量上的表现很像轻卡——单趟拉得不多，但可以多跑几趟。3B模型在消费级显卡上开32并发还能稳住，7B模型开到16并发时显存就开始告急，再往上加就得靠量化或者换多卡。这些数字全是实测出来的，换硬件、换框架、换量化版本都会变，我只能保证在我这套配置下是准的。
3.2 显存占用构成：模型权重、KV Cache、批大小与上下文长度
显存占用这件事，我画过一张饼图贴在显示器边上。模型权重是第一大块，7B模型FP16权重约14GB，INT4量化后压到4GB左右，3B模型FP16权重约6GB，INT4后不到2GB。这张饼图第二块是KV Cache，很多人忽略它，但它在长上下文场景下能吃掉一半显存。我用7B模型跑4K上下文、批大小8的配置，KV Cache占了差不多10GB，比模型权重本身还吓人。小模型的KV Cache有个好处，隐藏维度小、层数少，同样上下文长度下单条序列的KV占用比大模型低不少，3B模型在4K上下文下单条序列的KV Cache大概不到1GB。
批大小对显存的影响很直接。我拿3B模型做实验，批大小从1往上加，每加一档显存就往上跳一截，跳的幅度跟KV Cache的扩张基本线性相关。上下文长度的影响更隐蔽，从2K拉到8K，模型权重一点没变，KV Cache翻了四倍，总显存占用能差出两三个GB。我在8GB显存的卡上跑3B模型，2K上下文时批大小能开到8，8K上下文时批大小只能开到2，不然直接OOM。这个限制在实际部署里特别实在，用户不会管你显存多大，对话长了照样往里塞。
还有个很少被提及的显存开销：推理框架自身的运行时占用和中间激活。这部分在FP16下不算大头，但量化模型有时候会额外加载反量化参数，占个几百MB到1GB不等。我用GPTQ和AWQ两种量化格式对比过，AWQ在加载时的额外显存开销略低，但差别不显著。真正让我意外的是FlashAttention版本对显存的影响，换用优化过的attention实现后，长上下文下的KV Cache占用能省10%到15%。这些都是我在nvidia-smi反复盯出来的经验，写出来供读者参考。
3.3 不同硬件、推理框架与量化策略下的速度与显存对比
硬件这块我手头设备有限，但凑了几种典型场景：RTX 4090、RTX 3060 12GB、Jetson Orin Nano、还有一台纯CPU的云服务器。同一款3B模型，4090上跑FP16单token时延15毫秒左右，3060上大概35毫秒，Orin Nano上接近70毫秒，纯CPU上跑到200毫秒开外。7B模型在3060 12GB上用FP16直接装不下，得换INT4量化才能跑起来，单token时延从4090上的20多毫秒涨到60毫秒左右。Jetson Orin Nano跑3B模型INT4量化版，显存够用，速度也能接受，做端侧问答助手没太大问题，但跑7B模型就非常勉强了，我试过一次，发热降频之后延迟直接翻倍。
推理框架的差异比很多人想象的大。我主要用vLLM、llama.cpp和TensorRT-LLM三个框架对比。vLLM在批处理和吞吐上优势明显，PagedAttention对KV Cache的管理确实省显存，适合在线服务场景。llama.cpp在CPU和混合推理上更灵活，GGUF量化格式覆盖的量化档位多，从Q2到Q8都能选，端侧部署很方便。TensorRT-LLM在NVIDIA硬件上的优化最深，编译后速度最快，但部署流程也最重，模型转换、引擎编译每一步都有坑。我拿同一个7B模型测，TensorRT-LLM比vLLM的单token时延低了大概20%，但vLLM的并发吞吐更高，怎么选得看具体场景。
量化策略我测了FP16、INT8、INT4三个档位。INT8量化对速度的增益有限，单token时延跟FP16差不太多，显存省了一半，属于稳妥选择。INT4量化的速度提升因框架而异，llama.cpp的Q4_K_M格式在CPU上速度提升明显，GPU上用GPTQ或AWQ格式，单token时延能降个百分之十几到二十。代价是输出质量波动，数学推理和代码生成这两类任务对量化最敏感，我见过一个3B模型INT4量化后GSM8K分数掉了十几个点。量化不是免费午餐，省显存省算力的同时得盯着精度损失。
3.4 速度、显存、精度与输出质量之间的权衡分析
这四者的关系像一个没法同时拧到最大的四角旋钮。我把自己的经验总结成几句大白话：速度要快、显存要省、精度要高、输出要好，选两个就不错了，想四个全占基本得加钱。实际部署里我先确定显存上限，这是硬约束，消费级卡12GB和24GB差一个档，端侧设备8GB又是一道坎。显存定了之后看精度要求，做数学和代码任务我宁可牺牲速度保精度，用FP16或INT8，不做激进量化。做日常问答和摘要，INT4量化在小模型上的质量损失可以接受，省下来的显存可以换更大的批大小或者更长的上下文。
速度的权衡也很具体。首token时延和吞吐量往往是矛盾的，加大批大小能提升吞吐，但单请求的首token时延会上去。在线服务场景我更看重首token时延，用户等半秒和等一秒的体感差别很大。离线批处理场景我更看重吞吐，首token慢点无所谓，总处理时间短才是王道。我给自己定了个粗糙的阈值：交互式应用首token时延控制在500毫秒以内，单token时延50毫秒以内，用户基本无感。超过这个线就得考虑换小一点的模型或者降量化精度。
输出质量这块最难量化，因为“质量”跟任务强相关。我有个笨办法，拿自己的评测集跑一遍，不看总分，看错题类型。量化导致的错误往往集中在需要精细数值计算或多步逻辑推理的题目上，语言流畅度受影响反而小。如果我的业务场景主要是文本分类和信息抽取，INT4量化的小模型完全够用。如果是数学辅导或者代码生成，我至少用INT8，能上FP16就上FP16。这些判断没有标准答案，我的做法是先跑通，再跑小样本对比，最后用业务指标卡一道线。速度、显存、精度、质量四个维度都得在真实场景里过一遍，光看纸面参数会翻车。
上一章聊完速度和显存，后台有朋友问我：你测了那么多数字，到底哪个模型“综合最好”？这个问题我拖了半个月没答，小参数模型综合表现对比这件事，最怕的就是给一个笼统的排名。同一个模型，放在手机端和放在八卡服务器上，结论能反过来。这一章我把自己的评分表、梯队划分和几个真实场景的踩坑记录都摊开说说。
4.1 多维评分体系与权重设置方法
我最开始做小参数模型综合表现对比的时候，犯过一个特蠢的错：把各项 benchmark 分数直接加总求平均，排出来一个榜单，发给自己团队看。结果做端侧同事当场就笑了，说我推的第一名在他们板子上跑不动。那次之后我学乖了，评分体系里必须带权重，而且权重得跟着场景走，不能一套权重打天下。
我的做法是先列维度再谈分数。能力维度拆成通用问答、指令遵循、数学、代码、长文本、多语言六项，效率维度拆成首token时延、单token时延、并发吞吐三项，部署维度拆成显存占用、量化友好度、框架支持度、冷启动时间四项。每个维度打分用十分制，分数来源是我自己跑的评测集加上公开榜单的归一化结果。权重这块我常用两套模板：交互式应用给能力40%、效率35%、部署25%；离线批处理给能力30%、效率45%、部署25%；端侧设备反过来，部署占40%，效率35%，能力只留25%。
权重设置我没用什么高级算法，就是拉上产品和运维一起拍。拍完再回头验证：拿三五个候选模型按这套权重算总分，看排第一的那个是不是真的能落地。有一次算出来一个模型总分最高，结果它只支持一种推理框架，运维那边直接投反对票，权重表当场改。我的经验是权重别设太细，维度超过十个就容易变成数字游戏，七八个维度、每个维度有明确数据来源，够用了。评分表我一般每季度重算一次，模型更新太快，上季度的权重这季度可能就不合身。
4.2 典型小参数模型的横向对比与能力梯队分析
我手头常测的小参数模型大概有七八个：Qwen2.5的0.5B、1.5B、3B和7B，Llama 3.2的1B和3B，Phi-3.5-mini，Gemma 2的2B和9B，还有MiniCPM的2.4B版本。这些模型我都在同一套评测脚本上跑过，分数不公开引用，只说自己看到的趋势。
通用能力这块，Qwen2.5-7B和Gemma 2-9B基本在第一梯队，中文问答和指令遵循很稳，长文本任务也不露怯。Llama 3.2-3B和Phi-3.5-mini算第二梯队，英文任务表现不错，中文场景偶尔会冒出口语化不足的毛病。1B以下那批模型我归到第三梯队，做分类、抽取、简单改写没问题，开放域问答就明显吃力。数学和代码这两个专项特别能拉开差距，7B级别的模型GSM8K能到七八十分，3B级别掉到四五十分，1B级别经常连题意都读偏。这个梯队划分不是绝对的，量化版本、提示词写法、解码参数一变，模型在梯队里的位置就可能上下浮动半档。
我特意观察过“越级打怪”的现象。有些3B模型在特定任务上能咬住7B模型的尾巴，比如短文本摘要和意图识别，两者分数差距不到三个点。一旦任务需要多步推理或者长上下文记忆，3B模型就露馅了，错误类型从“答得不够好”变成“压根没抓住重点”。小参数模型综合表现对比里，我最看重的不是平均分，是看模型在自己参数档位内有没有明显短板。短板决定它能不能进生产环境，长板决定它值不值得为它单独调优。
4.3 场景化表现对比：端侧部署、边缘推理、私有化与在线服务
端侧部署我主要在高通手机和树莓派5上折腾。这个场景的硬约束是内存和功耗，模型参数量基本卡在3B以内，量化必须上INT4。Qwen2.5-1.5B的INT4版本在手机上首token时延能压到一秒以内，日常问答够用。MiniCPM-2.4B在树莓派上跑起来也还算顺，多轮对话三四轮之后响应会变慢，原因是KV Cache把内存吃紧了。端侧场景我不太看benchmark分数，更看连续对话十分钟会不会发烫降频，这个指标榜单上永远看不到。
边缘推理我拿Jetson Orin Nano当代表。这个场景比端侧多了一点算力余量，能跑3B到7B的量化模型，通常要接一个本地知识库或者做视频流的实时理解。Phi-3.5-mini在这里表现挺均衡，显存占用可控，多语言能力也够用。Gemma 2-2B在边缘设备上的冷启动比Qwen快一些，但长上下文任务明显偏弱。私有化部署是我接触最多的场景，客户内网不能出公网，模型得整包交付。这个场景下框架支持度比模型分数更重要，llama.cpp和vLLM双支持的模型落地最顺，只支持TensorRT-LLM的模型光是引擎编译就能卡住运维两天。
在线服务场景拼的是并发和稳定性。我拿vLLM压过Qwen2.5-7B，32并发下吞吐能到单请求的十几倍，首token时延上浮两成左右，用户基本无感。3B模型在这个场景反而尴尬，单请求延迟低，但并发一上来总吞吐被7B反超，原因是批处理效率不够高。我现在的做法是7B模型扛主力在线流量，3B模型专门处理高并发短请求，比如敏感词过滤和意图分类，两类模型混布，显存和吞吐都能吃满。
4.4 部署成本、运维复杂度与总体拥有成本分析
算总拥有成本这件事，我一开始只算了显卡钱，被财务问了一句“电费和人力呢”才反应过来。拿一台单卡RTX 4090的服务器举例，硬件采购大概两万出头，整机功耗满载四百瓦左右，按商业电价跑一年电费一千多块，这些是明面上的。隐性成本在运维侧：模型版本更新要重新跑评测、量化格式换了要重新编译引擎、推理框架升级可能带来接口不兼容，每一样都得占人天。我粗略估过，一个小模型从上线到稳定运行，头三个月运维投入折算下来能顶半张显卡。
私有化交付的成本结构又不一样。客户现场没有专职算法工程师，模型更新、日志排查、异常重启全靠运维兼着干。这种场景我优先选依赖少、文档全、社区活跃的模型和框架组合，哪怕模型分数低两三分。llama.cpp的GGUF格式在这里优势很大，单文件交付、不依赖CUDA版本、CPU也能跑，运维照着文档就能操作。vLLM虽然吞吐高，部署链路长，Python环境、CUDA驱动、PagedAttention版本对不上就起不来，小团队慎选。
在线服务的成本要按流量算。我用7B模型做在线问答，单卡4090能扛每秒十几路并发，折算到每千次请求的算力成本大概几毛钱。换3B模型成本能降一半，但回答质量下降带来的用户重试和人工兜底成本反而可能把省下的钱吃回去。小参数模型综合表现对比到成本这一层，我的结论很朴素：模型选型省下来的硬件钱，很容易被额外的运维和调优人力花掉。真正省钱的做法是把模型、框架、量化策略当成一个整体来选，选社区验证过的组合，别追最新最炫的单点方案。
前四章把评测、速度、显存、场景和成本都过了一遍，有朋友催我赶紧出个“买哪个”的结论。我一直拖着没写，因为选型这事跟相亲差不多，条件列得再细，见面聊十分钟可能就推翻了。这章我把自己做决策用的那张破旧表格、盯排行榜的习惯，还有对接下来一两年小模型走向的判断都写出来。不一定对，但都是我在项目里真金白银试出来的。
5.1 面向任务需求与硬件条件的选型决策树
我电脑里存着一个叫“选型灵魂三问”的文本文件，每次接新项目先打开它。第一问：任务错一次代价多大？第二问：硬件是已经买好了还是跟着模型配？第三问：团队里有没有人能改推理代码？这三个答案基本能把候选模型砍掉一半。
代价高、硬件固定、没人懂底层代码的场景，我直接锁定7B级别加INT4量化加llama.cpp，慢是慢点，但它不给你整幺蛾子。反过来，任务容错率高、硬件跟着模型走、团队有部署经验，那就可以试试3B模型配vLLM冲吞吐。我最怕碰到“既要又要”的项目：老板想要端侧跑、产品想要GPT-4效果、运维想要零维护。这种时候我会把决策树画出来给他们看，7B模型INT4在手机上首token就要三秒以上，用户早划走了。决策树不是为了选出一个完美模型，是让各方看到自己那个需求在树上对应哪根枝杈，砍掉不现实的期望。
硬件条件这块我加了一条硬规则：显存预算按模型权重的1.5倍算。多出来的0.5倍留给KV Cache和框架开销。有人问我为什么不是1.2倍，我吃过亏。一个客户现场用1.2倍算的，结果上下文拉到8K、并发开到8路，显存直接爆了，半夜被叫起来调批大小。从那以后我宁可按1.5倍甚至1.8倍留余量，硬件多花两千块，比半夜爬起来改配置便宜多了。
任务需求维度我重点看“最短木板”。选型时我会把任务拆成五个子环节，比如一个客服机器人拆成意图识别、知识检索、答案生成、敏感词过滤、多轮改写。每个环节单独评估模型够不够用。经常出现的情况是：7B模型在答案生成上比3B好一大截，但在意图识别和敏感词过滤上两者差距不到两个点。这种时候我就混着用，3B干简单活，7B干难活，显存算下来比纯7B方案还低。选型决策树的终点不是选一个模型，是选一套组合。
5.2 评测复现、排行榜跟踪与持续评估机制
公开排行榜我每周刷两次，但只看三个东西：排名变化幅度、评测集版本号、提交者备注。排名绝对值我基本不信，同一个模型在不同榜单上能差出十名去。我关注的是“谁在涨”和“为什么涨”。上个月有个3B模型在代码榜单上突然冲进前五，我拉下来一跑，发现它训练数据里混了评测集的原题，这种事在开源社区不罕见，但你不复现就永远不知道。
复现这事我做得比较笨。每个准备上生产的小模型，我会抽五十条真实业务数据跑一遍，人工看输出质量，再和公开榜单的分数做对照。有次一个模型在榜单上数学能力排前三，我拿业务里的报价单计算题一测，正确率不到六成。原因是榜单考的是纯数学题，业务数据里混着单位换算和表格理解，模型直接懵了。从那以后我的复现集里固定放二十条“脏数据”，格式混乱、有错别字、带口语重复。榜单分数再高，脏数据上翻车我就不考虑。
持续评估机制我搭得比较简陋，一个定时脚本加一个飞书表格。脚本每周一凌晨跑一遍候选模型在固定评测集上的分数，表格自动画趋势线。分数掉超过三个点就标红，我去看是模型更新了还是评测脚本环境变了。这套东西花了我两天搭，但省下来的时间远不止两天。有次框架升级导致一个模型输出全变成重复循环，脚本标红我当天就回滚了，要是等用户投诉再查，至少丢一周的线上数据。
排行榜跟踪我还有个习惯：看模型背后的团队活跃度。GitHub上issue回复快不快、版本更新频率如何、有没有长期维护计划。小参数模型综合表现对比不能只看当下分数，一个三个月不更新的模型，下个季度可能就掉队了。我吃过一次亏，选了个当时榜单分数很高的模型，结果作者跑去搞大模型了，小模型仓库半年没动，有个推理框架的兼容问题一直没人修，最后只能换模型重来。现在我看模型先看commit频率，再看分数。
5.3 小参数模型优化趋势：量化、蒸馏、MoE 与长上下文
量化这块我感受最深的变化是INT4从“能用”变成“好用”了。去年做INT4量化还得小心翼翼地挑校准集，弄不好某些层精度掉得厉害。今年Qwen2.5和Llama 3.2的官方INT4版本出来，我拿业务集测，和FP16版本的差距已经缩到两个点以内。端侧部署我基本默认上INT4，只要不是做代码生成这种对数值精度敏感的任务，INT4够用了。我最近在试INT3量化，有些模型在分类任务上还能稳住，生成任务就开始胡言乱语了。我的判断是INT4今年会成为小模型部署的默认档位，INT3还得再等等。
蒸馏出来的小模型我持谨慎乐观态度。拿大模型教小模型，通用能力确实提升明显，尤其是指令遵循和格式输出。但我也发现蒸馏模型有个通病：遇到训练分布外的任务，它比原生小模型更容易“自信地胡说”。原生1B模型碰到不会的问题还会支支吾吾，蒸馏出来的1B模型经常一本正经地编。我的做法是蒸馏模型必须配一个拒答阈值，置信度低于某个值就直接回“我不知道”，宁可少答也不能错答。这个阈值我一般设在0.6左右，业务不同再微调。
MoE架构在小参数模型里开始冒头了，我个人很关注这个方向。传统稠密模型参数量翻倍，推理成本跟着翻倍。MoE模型总参数量看着大，但每次推理只激活一小部分，显存占用高、计算量低。这对端侧不友好，显存本来就是瓶颈。但对边缘服务器和私有化部署很合适，花一张卡的显存跑出两张卡的效果。我最近在Jetson上试了一个MoE小模型，吞吐比同参数稠密模型高了四成，显存多占了三分之一。这个 trade-off 在边缘场景是划算的，端侧还得再观察。
长上下文这个趋势我心情比较复杂。模型支持的上下文长度从4K涨到32K、128K，纸面参数很漂亮。实际用下来，大部分小模型在超过8K之后注意力就开始涣散，中间部分的信息经常丢。我做长文档问答时会把文档切块，每块单独检索，而不是一股脑塞进去。小参数模型综合表现对比里，长上下文能力我一般打个七折看。真正能稳住16K以上有效注意力的小模型，目前一只手数得过来。我建议选型时上下文需求按实际用量的两倍来标，别被标称值忽悠。
5.4 综合结论与落地行动清单
回头看这五章写下来，我最想说的结论就一句：没有综合最好的小参数模型，只有和你的任务、硬件、团队最匹配的组合。7B模型在榜单上压着3B打，放到手机端连启动都费劲。1B模型分数不好看，做敏感词过滤又快又稳。我见过太多团队在选型会上争“哪个模型更强”，争到最后忘了自己是要解决什么问题。先定场景和约束，再谈模型排名，顺序反了就是浪费时间。
落地行动清单我按优先级列几条，都是我自己项目里反复用的。第一条：拿真实业务数据建一个五十条的迷你评测集，脏数据至少放两成。这条花半天时间，能帮你省掉后面几周的返工。第二条：显存预算按权重1.5倍起步，硬件采购别卡着刚好够用来买。第三条：候选模型至少跑一遍llama.cpp和vLLM两个框架，哪个顺用哪个，框架支持度比分数重要。第四条：上线前做一次七天稳定性观察，记录首token时延波动和显存峰值，别只看压测那一分钟的数据。第五条：每季度重算一次选型评分表，模型迭代快，上季度的结论这季度可能就反了。
趋势展望我大胆说两个判断。未来一年小参数模型的竞争焦点会从“分数高低”转向“部署友好度”，谁家模型量化包做得全、框架适配做得好、文档写得清楚，谁就能在私有化和端侧市场占住脚。另一个判断是混布会成为常态，7B模型扛主力、3B模型干杂活、1B模型守门，一套系统里跑两三个不同尺寸的模型，按请求难度动态路由。我现在的项目里已经这么干了，显存利用率比单模型方案高了四成，响应质量也没降。
最后说句实在话。小参数模型综合表现对比这件事，榜单和评测只是起点，真正的考验在你自己的业务数据上。我写这五章不是要给你一个标准答案，是想把我踩过的坑、用过的表格、半夜改配置的教训摊开，让你少走两步弯路。模型会过时，选型的思路和方法不会。拿着这套框架去套下一个新模型，比记住哪个模型排第几管用得多。
