我最近半年一直在折腾各种开源推理模型。从最早在笔记本上跑7B的小模型，到后来租云GPU试72B的大块头，踩过不少坑。写这个系列，就是想把我自己对比、评测、部署的经验整理出来。如果你也在选模型，或者准备把模型放到本地跑，这些内容应该能帮你省点时间。
1.1 什么是开源推理模型：定义、能力边界与常见代表
开源推理模型，我理解就是权重公开、允许下载、可以本地跑、还能自己改的模型。它跟那种只能调API的闭源模型不一样。你拿到的是实实在在的文件，可以塞进自己的服务器，也可以断网运行。推理这个词，重点在“想”的过程。这类模型通常会在数学题、逻辑题、代码生成上花更多力气，有的还专门训练了思维链，输出前先自己嘀咕一段。
不过，开源推理模型不是万能药。参数规模摆在那里，7B的模型再强，也难在复杂多步推理上干过70B的。上下文长度也有限制，有的支持128K，有的只有8K。我试过用一个小模型做长文档问答，前面聊得好好的，到后面就忘了开头说了啥。能力边界还跟训练数据有关，中文强的模型英文未必好，代码强的模型写诗可能一塌糊涂。
常见代表我列几个自己用得多的。DeepSeek-R1系列，有满血版和蒸馏版，蒸馏版把推理能力塞进小模型里，效果挺惊喜。Qwen系列里的QwQ，专门做推理，开源策略也大方。Llama和Mistral是通用底子，社区微调多。Gemma、Phi走轻量路线，适合边缘设备。这些模型各有各的脾气，后面章节我会一个个拆开聊。
1.2 为什么需要对比：开源推理模型对比评测与本地部署对比的双重视角
模型多了，选择就成了麻烦事。我经常在群里看到有人问：“到底哪个开源推理模型最好？”这个问题没法一句话回答。得看你想干嘛。做评测对比，是为了知道模型的能力上限和短板。做本地部署对比，是为了知道它在你手头的硬件上能不能跑、跑多快、花多少钱。两个视角缺一个，选型就容易偏。
拿我自己举例。我想搭一个本地代码助手。光看评测榜单，某个模型HumanEval得分很高，我兴冲冲下载下来，结果发现我的显卡只有8G显存，量化后跑起来慢得像蜗牛。这就是只看评测不看部署的后果。反过来，只盯着部署成本，选了个小模型，代码补全老是出错，用起来更闹心。开源推理模型对比，得把这两条线拧在一起看。
从企业角度，双重视角更明显。评测看模型能不能满足业务精度，部署看能不能过合规、能不能私有化、长期维护成本高不高。我接触过一些团队，他们先跑一遍公开基准，筛出三五个候选，再在目标硬件上实测吞吐和延迟，才确定下来。这个过程本身就是开源推理模型对比评测与本地部署对比的结合。
1.3 对比范围与方法论：模型版本、任务类型、评测基准与硬件条件
对比范围得先划清楚。模型版本这一块，同一个名字下面可能有好几个变体。基础版、指令微调版、蒸馏版、量化版，表现差很多。我一般会记录具体版本号，比如DeepSeek-R1-Distill-Qwen-7B，而不是笼统说DeepSeek-R1。任务类型也要分，数学推理、代码生成、事实问答、长上下文、安全对齐，不同任务考的是不同能力。评测基准我常用GSM8K、MATH、HumanEval、MMLU、C-Eval这些。硬件条件包括GPU型号、显存大小、CPU、内存、甚至电源。这些东西不写清楚，对比就没有意义。
方法论上，我尽量控制变量。提示词固定，温度设成0或者0.6，随机种子固定，每个测试跑三次取平均。本地部署测试更麻烦，要测首token延迟、每秒输出token数、并发请求下的表现。我自己的做法是写一个脚本，把模型加载、提问、计时、记录结果全自动化。这样换模型的时候，只需要改个路径。
有个坑得提醒你。模型更新很快，今天测的版本，下周可能就变了。复现结果的时候，最好把模型文件哈希、推理框架版本、CUDA版本都记下来。我吃过亏，同一个模型在不同框架下，输出质量能差出一截。开源推理模型对比，不是一次性的活，得持续做。
1.4 本文结构说明：从能力评测到本地部署再到场景选型
这篇文章是一个系列。我打算从主流开源推理模型盘起，聊聊它们的特点、参数、许可协议。有了这个底子，再进入能力评测，看看数学、代码、知识、安全这些维度上，各家的表现怎么样。评测之后是本地部署对比，硬件要求、推理框架、量化影响、成本核算，都会涉及。收尾部分落到场景选型，个人开发者、企业私有化、科研复杂推理，分别怎么挑模型。
具体来说，第2章会全景盘点DeepSeek-R1、Qwen、Llama、Mistral、Gemma、Phi、Yi、InternLM、GLM这些系列。第3章讲评测方法论和公开基准，给出我自己的测试结果和结论。第4章聚焦本地部署，对比llama.cpp、Ollama、vLLM、TensorRT-LLM、SGLang这些框架，还有不同参数规模的成本。第5章按场景给选型清单。第6章聊聊趋势，比如模型小型化、评测标准化、工具链演进。
不同读者可以跳着看。如果你只想快速选一个模型，直接翻到第5章的选型清单。如果你关心技术细节，第3章和第4章有大量实测数据。如果你在做长期技术规划，第6章的展望可能更有用。我尽量把每章都写得能独立阅读，但连起来看，你会对开源推理模型对比这件事有更完整的理解。
我平时折腾模型有个习惯，先看它属于哪个家族，再看具体版本号。同一个系列里，不同参数规模、不同蒸馏来源，表现能差出一大截。这一章我把手头用过、测过的开源推理模型捋一遍。不搞参数堆砌，主要聊我自己的感受和它们各自的脾气。
2.1 DeepSeek-R1 系列及蒸馏模型：特点、参数规模与生态影响
DeepSeek-R1 刚出来那阵子，我身边搞推理的朋友都在讨论。满血版是 671B 的 MoE 架构，推理能力确实猛。我通过 API 试过几轮数学题和代码题，思维链拉得很长，答案质量比很多闭源模型还稳。它开源得很彻底，权重、技术报告都放出来了。这种做法直接拉高了开源推理模型的天花板，也让更多人开始认真考虑本地跑推理模型这件事。
真正让我觉得有意思的是蒸馏系列。DeepSeek 把 R1 的推理能力蒸馏到了 Qwen 和 Llama 的小模型上，参数从 1.5B 一路铺到 70B。我本地跑过 7B、14B 和 32B 三个版本。7B 在简单逻辑题上已经能给出像样的推理步骤，14B 写代码补全够用，32B 做多步数学题正确率明显高一截。这些蒸馏模型对硬件要求友好，一张 24G 显存的卡就能跑 32B 的量化版。
生态影响这块，我感受很深。以前小模型做推理任务，基本靠提示词硬掰。R1 蒸馏版出来后，社区微调版本冒得特别快。llama.cpp、Ollama、vLLM 这些框架很快就支持了。我甚至见过有人用 1.5B 的蒸馏版做边缘设备上的逻辑判断，效果虽然有限，但思路打开了。R1 系列给开源社区打了个样，推理能力可以拆开、可以传递、可以塞进小模型里。
2.2 Qwen、QwQ 与通义千问推理系列：能力定位与开源策略
Qwen 系列我接触得早。从 Qwen 1 到 Qwen 2.5，再到后来的 Qwen 3，通义千问团队更新节奏很快。我拿 Qwen 2.5 的 7B 和 14B 做过中文问答和代码生成，中文理解很顺，长上下文处理也稳。QwQ 是专门做推理的版本，32B 参数，思维链风格跟 R1 有点像，数学和逻辑题上表现突出。我试过用 QwQ 解一道概率题，它自己跟自己辩论了好几轮，最后给出的答案比我预想的准。
开源策略上，Qwen 系多数版本用 Apache 2.0 许可，商用门槛低。这对个人开发者和中小企业很友好。我认识几个做垂直应用的团队，直接拿 Qwen 做底座微调，省了不少法律层面的麻烦。QwQ 的定位更偏研究和复杂推理，本地部署需要 32B 左右的显存，量化后能压到 24G 卡上跑。通义千问的生态工具链也全，从微调脚本到部署示例都有。
能力定位这块，我觉得 Qwen 走的是通用加推理双线。通用版本覆盖对话、翻译、摘要这些日常任务。QwQ 和后续推理版本负责啃硬骨头。开源策略大方，社区反馈也积极。我经常在 GitHub 上看到基于 Qwen 的推理微调项目，有的专门做医疗问答，有的做法律条文推理。这种生态活力，是模型能长期活下去的关键。
2.3 Llama、Mistral、Mixtral 等通用开源模型：推理表现与社区支持
Llama 系列我算是老用户了。从 Llama 2 到 Llama 3.1、3.2、3.3，每个版本我都下载过。Llama 3.1 的 8B 和 70B 我用得最多。8B 跑在本地做英文对话和简单推理还行，复杂多步推理就容易掉链子。70B 表现好很多，但硬件要求高。Llama 系列的优势不在原生推理，而在社区支持。你几乎能找到任何语言的微调版、任何任务的适配版。Hugging Face 上搜 Llama，结果多到翻不完。
Mistral 和 Mixtral 走的是另一条路。Mistral 7B 当年以小巧能打出名，推理速度很快。Mixtral 8x7B 是 MoE 架构，激活参数少，推理成本比同规模稠密模型低。我拿 Mixtral 8x7B 做过代码补全和逻辑题，表现中规中矩，不算惊艳但够用。Mixtral 8x22B 更强一些，可本地部署门槛也上去了。Mistral 系列用 Apache 2.0 许可的版本多，社区微调也很活跃。
通用开源模型做推理，我的感受是需要更多提示工程。Llama 和 Mistral 不会像 R1 或 QwQ 那样自动展开思维链。你得在提示词里明确要求它一步步想。有时候管用，有时候它还是会跳步。社区支持弥补了这部分短板。各种推理提示模板、少样本示例、微调数据集，随手就能找到。如果你不想被某个特定推理模型绑死，Llama 和 Mistral 的生态广度是实打实的优势。
2.4 Gemma、Phi、Yi、InternLM、GLM 等模型：轻量化与垂直化路线
Gemma 和 Phi 是我在低资源设备上试得比较多的两个系列。Gemma 2 的 2B 和 9B 版本很轻，跑在笔记本上没什么压力。Gemma 3 增加了多模态能力，参数规模也控制得不错。Phi 系列更极端，Phi-3 mini 只有 3.8B，推理能力在同类小模型里算拔尖的。我拿 Phi-3 mini 在树莓派上跑过简单逻辑问答，速度能接受，答案偶尔有惊喜。这两个系列适合边缘计算、离线助手、教育类应用。
Yi 系列我主要用它的中文能力。Yi-1.5 的 6B 和 34B 版本，中文事实问答和写作任务表现挺好。InternLM 是上海 AI Lab 出的，偏垂直化路线。InternLM2.5 在数学推理和工具调用上有专门优化。我试过它的数学版本，解方程和数列题步骤清晰。GLM 系列来自智谱，GLM-4 的中文对话和知识问答很稳，开源版本参数规模覆盖也广。这几个模型各自守着一块地盘，有的做轻量，有的做中文，有的做数学。
轻量化路线的好处是部署成本低。我出门带一台 16G 内存的笔记本，就能跑 Gemma 2B 或 Phi-3 mini 做离线笔记整理。垂直化路线的价值在特定任务上。InternLM 的数学版本做微积分题，比同参数通用模型强不少。GLM 的中文知识问答，幻觉控制也相对好。这些模型可能不会出现在通用榜单的前排，但在具体场景里，它们往往更顺手。
2.5 许可协议、参数规模、上下文长度与工具链兼容性对比
许可协议这事，我踩过坑。Llama 社区许可不是标准开源许可，商用有一定限制。Gemma 的许可也有自己的条款。Qwen 和 Mistral 的 Apache 2.0 版本用起来最省心。DeepSeek-R1 蒸馏系列多数用 MIT 或 Apache 2.0。我现在的习惯是，先把许可协议读一遍，确认能商用、能修改、能再分发，再决定要不要投入时间做微调。不然做了一半发现协议不允许，白忙活。
参数规模跨度很大。小到 0.5B 的 Qwen，大到 671B 的 DeepSeek-R1。本地部署常见的是 7B、8B、14B、32B 这几档。上下文长度从 4K 到 128K 都有，Gemma 3 和 Qwen 2.5 的部分版本支持到 128K 甚至更长。我实测过长上下文，32K 以上对显存要求明显增加。工具链兼容性方面，llama.cpp 和 Ollama 对主流模型支持最好，vLLM 适合高吞吐服务，TensorRT-LLM 性能强但配置麻烦。
我列一个粗略的对比感受。DeepSeek-R1 蒸馏版工具链支持最全，Ollama 一条命令就能拉下来。Qwen 系在 vLLM 上跑得很顺。Llama 和 Mistral 的 GGUF 量化文件最多。Gemma 和 Phi 在 llama.cpp 上表现稳定。InternLM 和 GLM 的官方部署脚本更完善。选模型的时候，工具链兼容性往往比榜单分数更影响日常体验。一个模型再好，你的框架不支持，或者量化版本缺东少西，用起来就费劲。
2.6 模型选择初判：哪些模型适合评测，哪些模型适合本地部署
做评测对比，我倾向于选满血版或大参数版本。DeepSeek-R1 671B、Qwen 72B、Llama 70B、Mixtral 8x22B，这些模型能代表当前开源推理的上限。评测它们需要租云 GPU 或者用多卡服务器。成本不低，但能拿到干净的基准分数。我一般会跑 GSM8K、MATH、HumanEval 这几套题，每个模型跑三次取平均。大模型评测周期长，我通常一个月集中做一次。
本地部署选型，思路完全不一样。个人开发者优先看 7B 到 14B 的蒸馏版或量化版。DeepSeek-R1-Distill-Qwen-7B、Qwen 2.5 7B、Llama 3.1 8B、Phi-3 mini，这些在 8G 到 16G 显存的卡上都能跑。企业私有化部署可以看 32B 到 70B 的中等规模模型，配 vLLM 做高吞吐。我认识一个团队用 QwQ-32B 做内部代码审查，量化后跑在两张 4090 上，延迟能接受。
选择初判可以简单点。想深入了解推理能力上限，选大参数满血版做评测。想马上跑起来用，选蒸馏小模型或量化版做本地部署。想兼顾成本和效果，选 14B 到 32B 的中等模型，先跑通流程再逐步升级。我自己的路线是，先用小模型验证场景，再根据瓶颈决定要不要换大模型。这样试错成本低，也不容易一开始就被硬件劝退。
上一章我把主流模型捋了一遍。模型特点清楚了，怎么比较它们的真实能力，得靠评测。我平时评测模型有个原则，公开榜单看趋势，自己动手跑任务看细节。这一章聊我怎么做开源推理模型对比评测，从方法论到各个能力维度，再到最后的结论。
3.1 评测方法论：基准选择、提示词设计、温度设置与结果复现
我选基准会按任务分。数学推理看GSM8K和MATH，代码看HumanEval和MBPP，综合知识看MMLU和BBH。长上下文用LongBench和RULER，中文任务用C-Eval和CMMLU。安全对齐看TruthfulQA和ToxiGen。每个基准测什么，我心里有数，不会拿一个MMLU分数就下结论。公开榜单像Open LLM Leaderboard、OpenCompass、LMSYS Chatbot Arena，我都会参考。榜单有局限性，有些模型可能在测试集上过拟合。
提示词设计和温度设置特别影响结果。同一个模型，zero-shot和few-shot CoT能差十几个点。我跑评测时固定提示词模板，比如数学题统一加“Let's think step by step”。温度一般设0或0.1，保证结果可复现。生成任务温度设0.7，看多样性。top_p、top_k、max_tokens这些参数都记录在案。我试过用不同温度跑GSM8K，温度0.8时答案波动明显。
结果复现要管好细节。模型版本、量化等级、推理框架、硬件型号、随机种子，一个都不能少。我用lm-evaluation-harness和OpenCompass比较多。复现时注意数据污染，有些模型训练时见过测试集。我习惯自己出几道新题交叉验证，比如改数字的应用题。复现不了的结果，我一般不写进对比表。
3.2 推理与逻辑能力：数学、常识、多步推理与因果判断
数学能力是我最看重的维度。DeepSeek-R1满血版和QwQ-32B在MATH上表现很强，思维链完整，步骤清晰。Qwen 2.5 72B也能打。小模型里R1蒸馏32B在GSM8K上能到80%以上，Llama 3.1 8B只有60%左右。我实测过一道二元一次方程应用题，R1蒸馏14B能列出方程并求解，Llama 3.1 8B直接给个错误答案。参数规模对数学推理的影响很直接。
常识和多步推理是另一回事。常识题用HellaSwag、ARC、Winogrande。Mixtral 8x22B常识表现不错，多步推理遇到复杂链条容易断。Qwen 2.5 14B在中文常识上很稳。我拿BBH测多步推理，模型需要把多个条件串起来。R1和QwQ能一步步推，Llama和Mistral需要明确提示。小模型在反事实推理上错误率高，经常忽略前提。
因果判断我单独测过。给一段事件描述，问原因和结果。R1和QwQ能理清因果链，Llama和Mistral有时把相关当因果。我试过用因果图题测模型，大模型表现明显好于小模型。推理能力跟训练数据质量、思维链训练方法关系很大。开源模型里，专门做推理的版本在这个维度优势明显。
3.3 代码能力：生成、补全、调试、跨语言迁移与工具调用
代码生成和补全我常用HumanEval、MBPP、LiveCodeBench。DeepSeek-R1和Qwen 2.5 Coder在HumanEval上分数很高。R1蒸馏32B写Python函数很顺，边界条件也考虑到了。Llama 3.1 70B代码能力可以，8B就勉强。补全任务看FIM能力，Qwen和DeepSeek的代码模型支持好。我试过在VS Code里用本地Qwen 2.5 Coder 7B做补全，响应快，准确率够日常用。
调试和跨语言迁移是我实际工作中常做的。拿一段有bug的代码让模型修，R1和QwQ能指出问题并给修复方案。跨语言迁移，比如Python转Rust，大模型语法错误少，小模型经常漏掉类型声明。我试过把一段Java排序改成Go，Qwen 2.5 14B一次通过，Llama 3.1 8B改了三次还有编译错误。代码能力上，专门代码模型比通用模型强，推理模型在复杂算法题上更有优势。
工具调用测ToolBench和API-Bank。Qwen和InternLM的工具调用格式更规范，能按JSON schema输出。Mixtral和Llama需要少样本示例，格式容易错。我试过让模型调用天气API，Qwen 2.5 14B一次成功，Llama 3.1 8B经常多输出解释文字。工具调用能力对Agent应用很关键，开源模型里Qwen系和InternLM系表现靠前。
3.4 知识与语言能力：事实问答、长上下文、多语言与领域适应
事实问答我用MMLU和TruthfulQA。Llama 3.1 70B知识面广，幻觉也存在。Qwen 2.5中文事实问答好，GLM-4中文知识稳。小模型事实问答容易编，问它一个不存在的历史事件，它能编出细节。我一般用选择题和开放题结合，选择题看知识覆盖，开放题看表达和准确性。开源模型在事实性上跟闭源顶尖模型有差距，但头部开源模型已经够用。
长上下文用LongBench和RULER。Gemma 3和Qwen 2.5支持128K，有效上下文可能打折扣。我实测32K以上，模型对中间位置的信息检索下降，这叫“迷失在中间”。Llama 3.1 128K版本也类似。长文档问答我建议分段检索加模型总结，不要一股脑塞进去。Qwen 2.5的长上下文表现在开源里算好的，R1蒸馏版上下文窗口小一些。
多语言和领域适应看实际需求。Qwen多语言支持好，Llama社区微调版覆盖语种多。领域适应看医疗、法律、金融。InternLM和GLM有垂直版本。我试过医疗问答，通用模型需要领域微调才能给出靠谱答案，不然幻觉多。中文领域里，GLM和Qwen的微调生态更丰富。多语言任务上，Llama的社区微调版几乎覆盖所有主要语种。
3.5 对齐与安全：指令遵循、拒答边界、幻觉控制与偏见表现
指令遵循用IFEval和MT-Bench。Qwen和Llama指令遵循好，小模型容易忽略格式要求。我测试要求输出JSON，7B模型经常加解释文字，大模型遵循率更高。指令遵循影响实际部署体验，格式错了后面流程就断了。开源模型里，Qwen 2.5和Llama 3.1的指令遵循在第一梯队。
拒答边界和幻觉控制是安全重点。模型拒答边界不同，有的过度拒答，有的该拒答不拒。我试过问敏感话题，Qwen拒答比较干脆，Llama有时绕弯子。幻觉控制上，R1和QwQ思维链长，也会自信编造。问不存在的论文，多个模型都会编出作者和期刊。需要外部验证。TruthfulQA分数能反映一部分，实际使用要加事实核查。
偏见表现用BBQ和WinoBias。模型在性别、种族偏见上程度不同。开源模型可以通过微调减轻。我观察到中文模型在中文语境偏见表现跟英文模型不同。安全对齐是持续过程，评测要结合人工审核。开源模型的安全能力参差不齐，企业用之前最好做一轮自己的安全测试。
3.6 开源推理模型对比评测结论：优势区间、短板与适用任务
从评测结果看，各模型有各自优势区间。DeepSeek-R1满血版推理上限高，蒸馏版性价比高。QwQ-32B复杂推理强。Qwen 2.5通用和中文好。Llama生态广。Mistral轻量快。Gemma和Phi边缘友好。InternLM和GLM垂直领域有积累。没有哪个模型在所有维度都领先。
短板也很明显。小模型多步推理和事实问答弱。大模型硬件要求高。开源模型工具调用和长上下文还有提升空间。幻觉普遍存在，安全对齐参差不齐。我评测时经常发现，同一个模型在不同基准上排名变化很大。选型要看任务匹配度。
适用任务可以按场景分。数学和代码选R1、QwQ、Qwen Coder。中文知识问答选Qwen、GLM。边缘设备选Gemma、Phi、Qwen 0.5B。企业私有化选32B到70B。评测结论只是参考，实际选型要跑自己的任务集。我一般会拿业务数据做小规模评测，再决定用哪个模型。下一章聊本地部署对比，那是另一个维度的挑战。
上一章聊完评测，模型能力有了大致画像。把模型放到自己机器上跑，是另一回事。我平时既在云端测，也在本地折腾。本地部署的变量多，硬件、框架、量化、并发，每个环节都能卡住人。这一章我把自己踩过的坑和实测数据整理出来，供你参考。
4.1 本地部署前置条件：显存、内存、算力、存储与量化等级
我装模型之前先看显存。7B模型FP16要14GB左右，4bit量化压到4到6GB。14B模型4bit量化大概8到10GB。32B模型4bit量化需要20GB以上，单张4090 24GB勉强能跑。70B模型4bit量化要40GB左右，得双卡或者Mac Studio统一内存。内存也不能忽视，模型加载时先读进内存再转显存，我一般留出模型文件两倍的内存空间。存储方面，一个7B的GGUF文件约4GB，70B的Q4文件约40GB，仓库里多放几个模型，硬盘很快就满。
量化等级直接影响硬件门槛。Q8_0精度高，显存占用接近FP16。Q5_K_M平衡好，Q4_K_M最常用。我试过在16GB显存的机器上跑Qwen 2.5 14B的Q4_K_M，留出上下文空间后刚好够。CPU推理用llama.cpp也能跑，速度慢但能应急。我有一台M2 Max的MacBook，64GB统一内存，跑70B Q4大概5到8 tokens/s，日常问答够用。企业部署要考虑多卡互联，NVLink对吞吐提升明显。
算力不光看GPU型号，还要看内存带宽。消费级显卡带宽有限，跑大模型时瓶颈常在带宽上。我测过RTX 4090和A100，同样跑7B模型，A100吞吐高出一截，价格也高出一截。边缘设备用核显或者NPU，只能跑1B到3B的小模型。我建议先明确自己的场景，再倒推硬件配置。不要先买卡再选模型，容易浪费。
4.2 主流推理框架对比：llama.cpp、Ollama、vLLM、TensorRT-LLM、SGLang等
我本地玩模型主要用llama.cpp和Ollama。llama.cpp轻量，编译简单，支持CPU和GPU混合推理，GGUF量化格式生态好。Ollama在llama.cpp基础上封装，一条命令就能拉模型跑起来，适合快速验证。我平时用Ollama试新模型，用llama.cpp做自定义参数调整。Ollama的并发能力弱，适合个人用，不适合多人同时请求。
生产环境我更倾向vLLM。vLLM的PagedAttention对显存管理做得好，吞吐量比llama.cpp高好几倍。我试过在单张4090上跑Qwen 2.5 7B，vLLM批处理能到每秒上千token，llama.cpp单请求只有几十token。TensorRT-LLM是NVIDIA的优化方案，速度最快，配置也最麻烦，编译引擎要花不少时间。SGLang适合结构化生成和复杂工作流，对JSON输出支持好。我选框架看团队维护能力，小团队用Ollama，有运维的用vLLM。
框架版本冲突是常见问题。vLLM对CUDA版本敏感，我装错过一次，折腾半天。llama.cpp编译时要注意CUDA架构参数。Ollama省心，但自定义程度低。我建议先在Docker里试，跑通了再上物理机。TensorRT-LLM适合有NVIDIA企业支持的团队。SGLang社区活跃，文档还在完善。
4.3 不同参数规模模型的部署成本：吞吐、延迟、并发与能耗
我记录过几组实测数据。7B模型在4090上，vLLM单请求首token延迟约0.2秒，吞吐约50 tokens/s。32B模型Q4量化，首token延迟升到0.8秒，吞吐降到15 tokens/s。70B模型双卡4090，首token延迟2秒以上，吞吐约8 tokens/s。并发增加时，延迟上升，吞吐先升后降。vLLM在并发16时吞吐达到峰值，再高就排队。我一般按业务峰值并发选硬件，留出30%余量。
能耗也是成本。4090跑7B模型功耗约200W，跑32B模型满载350W。A100 80G跑70B模型功耗400W以上。企业机房还要算散热和电费。我算过一笔账，本地部署70B模型，一年电费可能比云API还贵。边缘设备功耗低，Jetson Orin跑7B量化模型约30W，速度慢但省电。我建议个人开发者用消费级显卡，企业用数据中心卡，边缘用低功耗模块。
延迟和吞吐要平衡。在线对话看重首token延迟，离线批处理看重吞吐。我调过vLLM的max_num_seqs和gpu_memory_utilization，不同参数下表现差异大。TensorRT-LLM在固定batch下延迟最低。SGLang在结构化输出场景吞吐高。我一般用真实请求压测，不用理论值做决策。
4.4 量化、蒸馏与微调版本对本地推理效果和速度的影响
量化对精度有影响。我对比过Qwen 2.5 7B的FP16和Q4_K_M，在GSM8K上FP16正确率约75%，Q4_K_M掉到70%左右。Q5_K_M能到73%。Q2量化损失更大，数学题错误明显。我建议至少用Q4_K_M，有条件上Q5或Q8。量化对速度提升明显，Q4比FP16快2到3倍，显存占用减半。社区有现成的GGUF文件，我优先选官方或高信誉作者发布的。
蒸馏模型是小硬件的好选择。DeepSeek-R1蒸馏32B在推理任务上接近更大模型的表现。我试过R1蒸馏14B，跑数学题比同尺寸通用模型强不少。蒸馏模型速度更快，显存需求更低。微调版本针对特定任务，比如医疗、法律，通用能力可能下降。我一般先用基座模型测，再决定是否用微调版。LoRA微调后合并权重，速度不变，效果提升。
我试过在Ollama里同时加载蒸馏模型和量化模型，对比响应速度。蒸馏14B Q4比原版32B Q4快一倍，效果差10%左右。微调版加载后要重新测指令遵循，有些微调会破坏格式输出。我建议保留一个基座模型做通用任务，微调模型做专项任务。量化、蒸馏、微调三者可以叠加，但要逐项验证效果。
4.5 隐私、离线可用性、可维护性与企业合规能力对比
本地部署最大的好处是隐私。数据不出内网，不用担心API泄露。我帮企业部署时，客户最看重这点。离线可用性也重要，工厂、野外、保密单位没有稳定网络，本地模型能持续工作。可维护性看框架文档和社区活跃度。llama.cpp和Ollama文档全，vLLM更新快。TensorRT-LLM依赖NVIDIA生态，版本升级要谨慎。
企业合规要关注模型许可协议。Llama社区协议有商用限制条款，Qwen和DeepSeek的协议相对宽松。我见过企业用Llama做商用产品，法务审核花了很久。Apache 2.0协议的模型商用最省心，比如Qwen 2.5部分版本。企业还要做内容安全过滤，本地模型不会自动拒答敏感内容，需要额外加一层审核。我建议企业建立内部模型仓库，统一管理版本和许可。
可维护性还包括监控和日志。vLLM支持Prometheus指标，Ollama日志简单。我一般给企业配一个简单的监控面板，看显存、吞吐、错误率。权限管理要自己开发，开源框架不提供用户体系。离线更新模型也麻烦，要手动拷贝文件。我试过用rsync同步模型仓库，小规模够用。
4.6 开源推理模型本地部署对比评测：实测指标、常见问题与优化建议
我做过一组对比测试。硬件是单张RTX 4090，框架用vLLM和Ollama。模型选Qwen 2.5 7B和DeepSeek-R1蒸馏14B。vLLM跑7B，并发16时吞吐约1200 tokens/s，首token延迟0.25秒。Ollama跑同模型，单请求吞吐约40 tokens/s，首token延迟0.5秒。R1蒸馏14B在vLLM上吞吐约600 tokens/s，首token延迟0.4秒。llama.cpp跑Q4量化，单请求吞吐约30 tokens/s，显存占用最低。
常见问题我列几个。显存溢出最常见，调小max_model_len或换更低的量化。量化不兼容，有些GGUF文件在特定框架加载失败，换llama.cpp或Ollama试。框架版本冲突，vLLM和CUDA版本要匹配，我建议用官方Docker镜像。模型下载慢，用国内镜像源或者手动下载。我踩过最大的坑是vLLM的PagedAttention和某些量化格式冲突，换FP8或AWQ格式解决。
优化建议我总结几条。用vLLM时开启continuous batching，吞吐提升明显。调整gpu_memory_utilization到0.9左右，留一点给系统。用TensorRT-LLM时提前编译引擎，节省启动时间。SGLang适合JSON输出，加grammar约束。我一般先用小模型验证流程，再上大模型。压测用locust或wrk，模拟真实并发。监控显存和温度，防止过热降频。下一章聊场景化选型，把部署和评测结合起来做决策。
上一章把本地部署的硬件、框架、性能拆开聊了。实测数据有了，坑也踩了。选型不是找最强模型，是找最合适的组合。我做过个人项目、企业内网、科研协作三类场景。每个场景的约束条件不同，选型逻辑差别很大。这一章把我自己的决策路径写出来，供你参考。
5.1 个人开发者与边缘设备：低资源模型、量化部署与交互体验
个人开发者预算有限，机器通常是笔记本或者单张消费级显卡。我给自己选模型时，优先看显存占用和响应速度。7B到14B的量化模型是甜点区。Qwen 2.5 7B的Q4_K_M在16GB显存上跑得很顺，llama.cpp或者Ollama都能带起来。DeepSeek-R1蒸馏7B适合做推理小任务，数学题表现比同尺寸通用模型好一截。我试过在M1 MacBook Air 16GB上跑Qwen 2.5 3B的Q4，速度大概10 tokens/s，写代码补全够用。
边缘设备更受限。树莓派5 8GB跑1B到3B模型，量化到Q4，响应慢，胜在离线可用。Jetson Orin Nano跑Phi-3 mini或者Gemma 2 2B，功耗低，适合嵌入式问答。我做过一个智能家居原型，用Qwen 2.5 1.5B做本地意图识别，识别率一般，胜在不用联网。交互体验要看首token延迟。个人聊天场景，延迟超过1秒就难受。我把max_tokens调小，用流式输出，体感好很多。量化到Q4或者Q5，速度提升明显，精度损失可以接受。
个人选型我遵循一个简单规则：先定硬件，再定模型尺寸，再挑量化等级。16GB显存选14B Q4，8GB显存选7B Q4，4GB显存选3B Q4。内存至少留模型文件两倍。交互场景用Ollama，需要自定义参数用llama.cpp。边缘设备选GGUF格式，兼容性好。我还会在本地存一份小模型做兜底，大模型跑不动时切换过去。
5.2 企业私有化部署：高吞吐、长上下文、安全隔离与权限管理
企业场景我参与过几次。客户最关心数据不出内网，其次是并发能力。一家做客服系统的公司，峰值并发200左右，要求长上下文处理工单。我推荐了Qwen 2.5 32B，vLLM部署，双卡A100 80G。吞吐测试下来，并发64时首token延迟0.6秒，吞吐约800 tokens/s。长上下文用Yarn或者NTK插值扩展，32K上下文够用。安全隔离靠VLAN和防火墙，模型服务只在内网暴露。
权限管理要自己开发。开源框架不带用户体系，我一般加一层API网关，做鉴权和限流。审计日志记录每个请求的输入输出，满足合规。内容安全过滤用敏感词库加小模型审核。企业选模型先看许可协议。Apache 2.0的模型商用最省心，Qwen 2.5部分版本和DeepSeek-R1都是。Llama社区协议有条款限制，法务要提前审。我见过一家公司遇到许可问题临时换模型，项目延期两周。
高吞吐场景选vLLM或者TensorRT-LLM。vLLM的PagedAttention对显存碎片管理好，支持continuous batching。TensorRT-LLM速度更快，编译引擎麻烦，适合有NVIDIA支持的团队。长上下文场景注意显存占用，KV cache随长度线性增长。我通常把max_model_len设成业务需要的最大值，留20%余量。权限管理用RBAC模型，跟公司LDAP对接。企业部署还要考虑模型更新和回滚，我建议用容器镜像管理版本。
5.3 科研与复杂推理：高精度模型、多模型协作与可验证工作流
科研场景对精度要求高，对速度容忍度大。我参与过一个材料科学项目，用DeepSeek-R1 671B的API做假设生成，本地用蒸馏32B做初步筛选。高精度模型选FP16或者Q8量化，Q4在复杂推理上损失明显。我测过R1蒸馏32B在MATH数据集上，Q8比Q4高5个百分点。科研预算通常能负担双卡或者四卡A100，跑70B模型Q8问题不大。
多模型协作是常用模式。我用一个规划模型拆解问题，一个推理模型执行，一个验证模型检查结果。比如Qwen 2.5 72B做规划，DeepSeek-R1蒸馏32B做推理，Gemma 2 27B做验证。可验证工作流要求每一步有中间输出和置信度。我写了一个简单框架，记录每个模型的调用和输出，方便复现。科研场景还看重可复现性，温度设0，随机种子固定，提示词版本管理。
复杂推理任务选模型看基准分数，也看实际表现。我一般先用公开基准筛出候选，再用自己的任务集测。MATH、GPQA、HumanEval这些基准有参考价值，污染问题也要注意。科研团队可以自己构建评测集，覆盖领域问题。多模型协作增加延迟和成本，换来准确率提升。我建议先单模型跑，达不到要求再加协作。验证环节不能省，大模型幻觉在科研场景代价高。
5.4 成本与效果权衡：本地自托管、云 API 与混合架构对比
成本要算总账。本地自托管有硬件采购、电费、运维人力。我算过一台双卡4090的工作站，跑32B模型，一年电费约2000元，硬件投入3万，折旧三年。云API按token收费，轻量使用更划算。我有个个人项目，每月调用量500万token，云API费用约100元，本地跑电费都不够。企业高并发场景，本地部署单token成本更低，前期投入大。
云API的优势是弹性。业务峰值来了，加钱就能扩容。本地部署要提前买卡，峰值过了资源闲置。混合架构是折中方案。日常请求走本地，峰值溢出到云API。我帮一家电商做客服，平时本地Qwen 2.5 14B，大促时切到云API。延迟增加一点，成本可控。混合架构要处理数据同步和路由逻辑，我写了一个简单网关，按并发数切换。
效果权衡看任务容忍度。创意写作、闲聊，小模型加量化够用。代码生成、数学推理，大模型或者高精度量化更稳。我一般先用云API测效果上限，再用本地模型逼近。本地模型效果达到云API的90%，成本降一半，就值得切换。许可协议影响长期成本，Apache 2.0模型可以商用，省去授权费。我建议每季度重新评估一次，硬件价格和模型能力都在变。
5.5 选型清单：按任务类型、硬件预算、维护能力与合规要求匹配模型
我整理了一份自己的选型清单。任务类型分四类：对话、代码、推理、领域问答。对话任务选Qwen 2.5 7B到14B，量化Q4，Ollama部署。代码任务选DeepSeek-Coder或者Qwen 2.5 Coder，14B到32B，vLLM部署。推理任务选DeepSeek-R1蒸馏32B或者QwQ 32B，Q8量化。领域问答用微调版或者RAG，基座选Llama或者Qwen。
硬件预算决定模型上限。5000元以内选二手3090 24GB，跑14B Q4。1万到2万选4090，跑32B Q4。3万以上选双卡4090或者A6000，跑70B Q4。Mac Studio统一内存适合安静环境，M2 Ultra 128GB跑70B Q4速度可以。边缘设备选Jetson Orin或者树莓派，跑3B以下模型。维护能力弱的团队用Ollama，有运维的用vLLM。合规要求严的选Apache 2.0模型，避免Llama社区协议。
选型清单我做成表格，每次新项目过一遍。模型版本要锁定，不要用latest标签。量化等级至少Q4_K_M。上下文长度按业务需求设，不要盲目开最大。我还会准备一个降级方案，大模型不可用时切到小模型。监控显存和延迟，设置告警。选型不是一次性工作，业务变化、模型更新、硬件降价都要重新评估。下一章聊趋势展望，把选型逻辑放到更长时间维度看。
前五章把评测、部署、选型拆得很细。走到这里，我想把视线拉长一点。开源推理模型变化太快，半年不更新，知识就过期。我自己的选型表每季度都要重做一遍。这一章不聊具体参数，聊我看到的几个趋势，还有我准备怎么持续跟下去。
6.1 推理能力开源化：模型小型化、蒸馏技术与训练方法演进
我明显感觉到，推理能力正在从大模型往小模型迁移。去年7B模型做数学题基本靠猜，今年DeepSeek-R1蒸馏7B已经能解不少初中竞赛题。Qwen 2.5 7B在逻辑推理上也比前代强一截。这种进步不是偶然。蒸馏技术把大模型的推理链压缩到小模型里，训练方法也在变。GRPO、过程奖励模型、拒绝采样这些手段，让中小模型学会一步步想问题。我自己在本地跑R1蒸馏14B，复杂推理任务能达到大模型七八成水平。硬件成本降了，可用性高了。
模型小型化对本地部署是大利好。以前想跑推理任务，至少得32B起步，显存要求高。现在7B到14B的蒸馏模型，量化后消费级显卡就能带。我试过在RTX 4060 8GB上跑Qwen 2.5 7B Q4，数学题和代码补全都能应付。边缘设备也在受益。Jetson Orin跑Phi-3 mini做推理，功耗低，响应可接受。未来我猜会出现更多1B到3B的推理专用小模型，专门给端侧用。训练方法继续演进，小模型的能力边界还会往外扩。
训练方法这块，我关注两个方向。一个是强化学习更高效，不用海量标注数据。另一个是推理链的自动生成和筛选。开源社区贡献了很多工具，让个人开发者也能微调小模型。我做过一次LoRA微调，用几千条数据提升特定任务表现，效果不错。模型小型化不等于能力缩水。特定任务上，小模型加好的训练方法，能超过通用大模型。我的选型逻辑跟着变，不再盲目追大，先看任务匹配度。
6.2 评测标准化：公开榜单、复现协议与污染控制的发展方向
评测这件事，我踩过不少坑。公开榜单分数高的模型，实际用起来可能一般。污染问题很常见，测试集进了训练数据，分数虚高。我遇到过某个模型在MATH上得分漂亮，换一套新题就露馅。LMSYS Arena、Open LLM Leaderboard、LiveBench这些榜单在改进，动态更新题目，减少污染。复现协议也在规范。模型卡里写清楚温度、提示词、采样参数，别人才能重跑。我自己的评测流程也在标准化。固定随机种子，记录每次调用的输入输出，方便对比。
未来评测会往动态化和私有化走。公开榜单提供参考，不能全信。我习惯自己建一个小测试集，覆盖我的实际任务。数学、代码、长上下文、多语言，每个维度几十道题。新模型出来先跑一遍，跟旧模型比。社区也在推复现协议，要求提交完整配置。污染控制靠题目保密和定期换题。我参与过一个小型评测项目，题目不公开，只公布分数和模型输出。这种方式更可信。评测标准化对选型帮助大，减少试错成本。
我期待看到更多领域专用榜单。通用榜单看不出模型在医疗、法律、金融上的表现。领域评测集需要领域专家参与构建。开源社区可以协作，像维基百科那样众包题目。污染控制可以结合水印技术，追踪训练数据来源。评测标准化不是一家的事，需要模型方、评测方、用户方一起推动。我作为用户，会持续关注榜单，但更相信自己的测试集。榜单看趋势，实测定选型。
6.3 本地部署工具链演进：更易用、更高效、更适配异构硬件
本地部署工具链这两年进步飞快。我刚玩本地模型时，编译llama.cpp要折腾半天。现在Ollama一行命令拉模型跑起来。vLLM、SGLang、TensorRT-LLM各有优势。vLLM的PagedAttention和continuous batching，让吞吐上了一个台阶。SGLang在结构化生成和前缀缓存上做得好。TensorRT-LLM速度最快，编译麻烦。我日常用Ollama做快速测试，生产环境用vLLM。工具链的易用性提升，让更多人可以本地跑模型。
异构硬件适配是下一个重点。以前主要支持NVIDIA显卡。现在Apple Silicon、AMD ROCm、Intel Arc、NPU都在跟进。我在M2 Mac上跑llama.cpp，Metal加速效果不错。AMD显卡用ROCm跑vLLM，性能接近同价位N卡。边缘NPU如瑞芯微、寒武纪，也有对应的推理框架。未来工具链会自动识别硬件，选择最优后端。量化格式也会统一，GGUF、AWQ、GPTQ互相转换更方便。我期待一键部署脚本，自动测硬件、选模型、调参数。
工具链演进对个人开发者最友好。以前部署模型要懂CUDA、懂编译。现在Docker镜像开箱即用。我帮朋友部署本地问答，用Ollama加Open WebUI，半小时搞定。企业场景需要更多控制，vLLM加Kubernetes，弹性伸缩。工具链在往两个方向走。一个极简，一个极灵活。我选工具看场景。个人项目求快，企业项目求稳。未来可能出现模型路由层，根据请求自动切换本地模型和云API。我写过一个简单路由，按并发数切换，效果还行。
6.4 结论：如何持续开展开源推理模型对比、评测与本地部署选型
走到结论，我想说选型不是一锤子买卖。开源推理模型迭代快，硬件降价快，工具链更新快。我给自己定了一个节奏。每季度做一次全面评估。新模型出来先看许可协议，再看参数规模，再跑我的测试集。测试集覆盖我的核心任务。分数达标就进候选池。本地部署测试跑一遍，看显存占用、首token延迟、吞吐。都过关才切换。旧模型不急着删，留作降级方案。我本地常备两个模型，一个主力，一个兜底。
持续开展对比评测，需要一套轻量流程。我维护一个表格，记录模型版本、量化等级、硬件配置、评测分数、部署方式。每次新模型加一行。评测脚本自动化，减少手工操作。污染控制靠定期换题。复现协议写清楚，方便回溯。本地部署选型看任务类型、硬件预算、维护能力、合规要求。个人开发者优先易用性，企业优先吞吐和安全。科研优先精度和可复现。我的经验是，没有万能模型，只有匹配场景的组合。
未来我会继续关注几个信号。小模型推理能力有没有突破，评测榜单有没有新方法，部署工具链有没有支持新硬件。开源社区的力量在放大，个人开发者也能参与贡献。我建议你建自己的评测集，哪怕只有几十道题。定期跑一遍，比看榜单更靠谱。本地部署先跑通小模型，再逐步升级。许可协议提前审，避免法律风险。开源推理模型的下一站，是更小、更准、更易用。我会一直跟下去，把新发现写进下一版选型表。
