我做了三年多的开源模型落地把 Llama 2、Qwen、DeepSeek 这些换着花样折腾了个遍今天想认认真真聊一下 LLM 开源模型对比这件事。每次有人问我该选哪个开源模型我发现大家的困惑往往不在模型本身而是根本不知道对比要从哪里入手榜单那么多量化档位那么多RAG 一接就崩。这篇把选型思路、底层概念、实操部署到报错排查一次性理清楚适合正在做模型选型、或准备把开源模型接到自己业务里的朋友照着抄就行。1. 先看清格局开源 LLM 到底在哪些维度上较劲大家看热词里有 llm 开源模型、大模型 llm、开源小模型、jev 模型开源吗 这些高频搜索说明两个问题一是开源模型的声量已经大到绕不开了二是很多人还在这个模型开源吗的阶段打转。我建议先把格局看清楚再谈具体对比。1.1 为什么现在大家集体往开源模型转最直接的原因当然是成本。闭源 API 按 token 计费业务量一大账单直接起飞。我接过一个做客服知识库的项目原来用闭源模型日均调用 3 万次不算向量库光是模型费用一个月小一万换了开源模型部署在内部服务器上电费加折旧一个月几百块这是数量级的差距。数据隐私同样是决定性的。医疗、金融、政务这类场景数据根本出不了内网你连 API 都不好意思调。开源模型可以全链路跑在本地虽然做不到百分之百不出网telemetry 还是要关掉的但至少从架构上保证了核心语料不被第三方留存这是合规审查过不过的一票否决项。还有一个容易被忽略的理由是可控性。闭源模型今天给你升个级明天改个接口你的业务逻辑全挂在别人的版本上。开源模型尤其是 Llama、Qwen 这些社区的版本绑定在自己的容器里版本固定、行为固定、出问题能自己回滚这种确定性对于生产系统太重要了。1.2 主流开源模型家族的定位差异很多人一上来就问哪个模型最强这个问题其实没法答因为各个开源模型家族对强的定义根本不一样。我通常把模型按服务对象分成几大类通用助手、中文优化、推理与代码、多语言与 MoE每个赛道都有扛把子。模型家族代表版本核心定位适合场景要注意的坑Qwen通义千问Qwen2.5-7B/14B/72B-Instruct中文优化、工具调用、指令跟随中文客服、RAG、Function Calling部分分支版本对中文很激进翻译任务别乱用LlamaLlama 3.1 8B/70B生态完善、多语言均衡、资料最多全球社区资源、微调底座中文能力没有专精度需要配词典或微调DeepSeekDeepSeek-R1-Distill-Qwen-14B/32B、DeepSeek-V3推理、数学、代码Agent、复杂推理、编码辅助上下文很长但输出风格有点啰嗦要调 thinking 模式MistralMistral 7B、Mixtral 8x22B欧洲背景、MoE 结构多语言、低于 100B 的 MoE 场景英文资料多中文社区教程相对少Phi 系列Phi-3-mini-4k/128k小参数、高质量数据训练端侧部署、简单任务参数很小但能力边界明显别拿来写代码我个人的经验是如果你做中文业务Qwen 几乎是无脑首选。不是因为它每一项指标都第一而是它的指令跟随和中文语感对齐做得最到位尤其涉及角色扮演、客服话术、产品描述这类场景时Qwen 的输出人味最正。而如果你主攻代码生成和数学推理DeepSeek-R1 系列的蒸馏版本在同等参数下性价比极高。还有个热词是 现在开源小模型有好用的么这个确实很多人问。我的观点是小模型小于 10B现在绝对有可用性但它解决的绝不是越级干掉大模型的问题而是把刚好够用的场景从云端搬到端侧和本地的下位替代。Phi-3-mini 跑在手机推理框架上回答简单问答没问题但你让它写一段完整的多表关联 SQL 它就说胡话。选小模型的核心原则是场景复杂度必须低于模型能力上限的 70%留出容错余量。2. 对比之前先搞懂这三个底层概念很多选型翻车不是模型不行而是对比的前提没建立。热词里有个特别有意思的说法叫 llm 的 token 三个点key 我是谁、query 我在找什么、value 我能提供什么这其实讲的是 Attention 机制里的 K/Q/V很多人拿它当 RAG 的理论基础这个类比是对的但也恰恰说明了 Token 和上下文是你选型的第一道坎。2.1 Token 不搞懂后面全是糊涂账Token 是模型处理文本的最基本单位它不是字符也不是字而是经过分词器切出来的片段。英文一个词大概 1 到 1.5 个 token中文一个汉字大概 0.6 到 1 个 token不同分词器不一样Qwen 的中文 tokenizer 效率高一个常用汉字往往只占不到一个 tokenLlama 的就费一些。中文场景里必须把这个算进去否则你会发现同样 8K 上下文Llama 能装的内容比 Qwen 少一截。上下文窗口的长短直接决定了你的应用架构。128K 和 32K 不是大一点和小一点的区别而是能不能塞一份完整文档、要不要做切片、要不要召回的架构分界线。我的建议是选型表里必须有三列——实际业务文档平均长度、最大单条输入长度、多轮对话累计长度然后对比这些值和你备选模型的上下文上限超了就老老实实走 RAG。2.2 公开榜单的真实分量热词里反复提到 open llm leaderboard 等公开榜单这是好事但榜单被滥用了。Open LLM Leaderboard 用的 MMLU、HumanEval 这些题是静态的模型厂商和社区完全可以针对性调参刷榜是公开的秘密。更关键的是榜单评测的是单轮知识问答而你真正要做的是多轮对话 工具调用 格式约束这完全是另一个层面的事。我判断模型真实水平的顺序是第一看 Arena 类的盲测 ELBO 排名好赖由用户投票比刷题准第二看 LFMLanguage Model Factuality这类幻觉率指标第三才看 MMLU/GPQA 这种知识题。榜单排第一不代表你的场景最好用你最终依赖的还是在自己业务数据上的 AB 测试。2.3 参数量、显存、量化之间的数学关系7B 模型是 70 亿参数每个参数以 FP16 存储占 2 字节所以裸权重就有 14GB落到显存里再算上 KV Cache 和中间激活值16GB 显存根本不够跑24GB 才算宽松。这还没完你要上 8K 上下文KV Cache 又要吃 2 到 4GB一旦换成 128KKV Cache 会膨胀到十几 GB显存瞬间崩塌。这也是为什么先定上下文、再定量化、最后买卡的顺序不能乱。量化就是把权重从 FP16 压缩到更小的数据类型。Q4_K_M 是社区公认的甜点档精度损失很小却能省近 75% 的权重内存。我后面有一个专门的章节细讲量化档位怎么选这里先记住结论能上 Q8 别用 Q4 只是心理安慰实际 Q4_K_M 在绝大多数任务里表现已经足够关键不在档位高低而在有没有做校准。3. 我把市面上几款主流模型挨个跑了一遍说再多理论不如直接把模型拉出来遛一遛。我拿一套固定的测试集20 道混合题中文常识、逻辑推理、代码补全、指令格式遵从、幻觉防御各 4 道在相同的推理框架和量化档位下跑了一圈结果仅供参考但比看榜单实在。你复测时记得用同样的上下文长度和温度我统一设 0.3否则结果不可比。3.1 7B/8B 级别的小钢炮军团这个段位是竞争最惨烈的因为有消费级显卡的开发者最多。我重点测了 Qwen2.5-7B-Instruct、Llama 3.1 8B、Phi-3-mini 三款。Qwen2.5-7B 在中文指令跟随上明显领先我让它以资深客服口吻生成一段安抚话术语气自然不油腻而且能准确遵循不要道歉、直接给方案的指令。Llama 3.1 8B 的英文通用能力很扎实翻译、改写、摘要都稳但中文语境偶尔会冒出英文病句。Phi-3-mini 的优势是体积小量化后能进手机端但代码能力非常一般简单循环都能写错。如果你只能放下一张 8GB 显存的卡首选 Qwen2.5-7B-Instruct 的 Q4_K_M 量化版这是我在穷配置下表现最平衡的组合。而如果你做英文技术文档处理Llama 3.1 8B 的稳定性更让人放心。3.2 20B 到 34B 级别显存和智能的甜蜜点这个段位是目前最被低估的。单卡 24GB 到 48GB 显卡能跑性价比远超高参数模型。我测的 DeepSeek-R1-Distill-Qwen-32B 在逻辑推理题上惊艳一道多步骤的数学应用题它不但算对了还写了两行注释说明思路这种可解释的推理过程是闭源 API 都不一定能稳定给到的。Qwen2.5-14B-Instruct 在长文本萃取上表现突出给我 3 万字产品文档它能按要求产出结构化报告关键数字一个不差。Yi-1.5-34B 我也测了中文能力好但社区资料和生态明显比不过 Qwen 和 Llama不推荐新手入坑。这个级别的模型建议长期跑服务不要在个人笔记本上反复启停太遭罪。vLLM 推理引擎加 Q4 量化24GB 卡能吃到 30 token/s 以上的生成速度足够服务中小并发。3.3 MoE 结构与大模型开源的上限在哪Mixtral 8x22B 是 MoE 类里绕不开的角色虽然它总参数量接近 141B但每次推理只激活 39B所以实际运行开销比同效果稠密模型低不少。不过它在中文上的表现确实没有同级别的 Qwen 系列好词汇丰富度不够这是我实测的体感不是指标能完全看出来的。DeepSeek-V3 和 R1 系列则代表了开源模型能力的天花板尤其在数学和代码领域已经可以在很多 benchmark 上追平甚至反超顶级闭源模型。但我要泼盆冷水超大模型你一个人玩不动。671B 的 DeepSeek-V3光权重量化到 Q8 也要 670GB就算分布到 8 张 80GB 的卡上你自己还不一定搞得定 KV Cache 和通信优化。我的实际建议是对于绝大多数团队14B 到 32B 是落地甜点区超过这个才考虑 MoE 或者蒸馏小模型直接推超大模型不是性价比选择。模型参数级别显存Q4量化中文能力推理能力代码能力推荐指数Phi-3-mini3.8B约3GB一般弱弱2星仅端侧Qwen2.5-7B7.6B约5GB强中上中上5星综合Llama 3.1 8B8B约5.5GB中中上中上4星英文生态Qwen2.5-14B14.7B约10GB强强强5星中文落地DeepSeek-R1-Distill-32B32B约20GB中上极强极强5星推理场景Mixtral 8x22B141B39B激活约55GB中强强3星卡多再玩4. 部署、量化和本地落地的完整实战过程这一节是全文最干货的部分我所有的部署经验都是从这些场景里一遍遍踩出来的。很多人死磕模型选型结果卡在部署环节士气全无其实部署才是真正拉开差距的分水岭。4.1 推理框架怎么选别一上来就跟风 vLLM按场景分个人学习和原型验证首选 Ollama一条ollama run qwen2.5:7b就完事模型管理直观API 兼容 OpenAI 格式生产环境且高并发vLLM 是事实标准PagedAttention 显著提升吞吐但配置复杂资源紧张的服务器llama.cpp 的 server 模式或 LlamaServer 更轻量企业级要带可视化界面Xinference 提供模型管理、向量库对接和 API 一条龙比 dashboard 补丁方案省心得多。我见过最典型的翻车是一上来直接上 vLLM被各种调度参数搞得怀疑人生其实初期用 Ollama 把业务链路验证通再迁移到 vLLM 做压测是最平滑的路径。跑通逻辑比一步到位重要得多。如果要写代码最简单的验证方式是# 先用 Ollama 跑通链路 ollama pull qwen2.5:7b ollama run qwen2.5:7b # Python 里调 OpenAI SDK 兼容接口 from openai import OpenAI client OpenAI( base_urlhttp://localhost:11434/v1, api_keyollama ) resp client.chat.completions.create( modelqwen2.5:7b, messages[{role: user, content: 用一句话说明 RAG 是什么}] ) print(resp.choices[0].message.content)这套代码我几乎每个项目都先跑它验证的不是模型多聪明而是你的调用链路通不通。4.2 量化档位排名与选择的真实依据热词里有 开源模型量化档排名我把结论直接摆出来主流推荐 Q4_K_M显存或带宽受限选 Q3_K_S有余力可选 Q5_K_MQ2 和 Q8 都是性价比洼地。Q2 能力崩塌明显Q8 内存开销大、收益有限测试时你基本感觉不出和 Q4 的差别。量化也要看后端支持。llama.cpp 用 gguf 格式Ollama 也是 ggufvLLM 可以用 AWQ 和 GPTQ这两者校准过程不同AWQ 按通道敏感度做权重缩放GPTQ 做逐层近似实测下来 AWQ 在 vLLM 里的速度抖动更小。同一个模型不同框架加载同一个量化档位的效果也有差异所以别只听别人说Q4 够用得在自己的业务数据上小时级复测。4.3 ONNX 部署 LLM 的操作要点热词里有 onnx 部署 llm 模型这个场景通常出现在端侧或是 Windows 生态里。ONNX Runtime 配合 onnxruntime-genai 可以加载量化后的模型优势是跨平台、高推理效率、还能走 DirectML 调 GPU。实操要点是先用 optimum 把 Hugging Face 模型导出成 ONNX 格式设置合适的外部数据存储路径不然大权重文件会撑爆 protobuf 的 2GB 限制然后做 dynamic_axes 设置把 batch 和 sequence 长度设为动态维度否则换输入长度直接崩最后量化可选 int4 或 int8Windows 上用 DirectML EP 加速。我踩过最大的坑是导出时没设 external data一个 7B 模型导出到一半直接报权重写入失败折腾了两小时才反应是单个权重文件超了 2GB。这个 2GB 限制是 protobuf 的历史遗留问题人人都会撞一次导出前直接配好前车之鉴。4.4 模型网关多模型接入黏合层让我做个比喻网关就是公司前台所有请求先到它这儿它知道哪个部门模型能处理你的需求需要排队就去排队出了问题它换个部门。生产环境里很少只部署一个模型通常是大模型做复杂推理、小模型做归纳、专用模型做分类的组合这时候 llm 网关的价值就显现出来了。热词里 llm 网关 提了不少我用的方案是 LiteLLM Proxy支持统一的 OpenAI 兼容协议后端可以接本地 vLLM、Ollama、也可以挂闭源 API 作为 fallback。生产环境配置里最核心的是超时和重试策略——本地模型偶发排队超时线上不能因为一次超时就整个链路报错。我把这个超时调成 90 秒重试次数设为 1 次实测对用户无感体验比裸连模型后端好得多。# LiteLLM proxy 配置片段 model_list: - model_name: local-qwen litellm_params: model: ollama/qwen2.5:14b api_base: http://localhost:11434 timeout: 90 - model_name: code-model litellm_params: model: vllm/deepseek-r1-32b api_base: http://localhost:8000/v1 timeout: 120 litellm_settings: drop_params: true num_retries: 15. 把开源模型接进业务RAG 与知识库实战光对比模型不落到业务上等于白比。热词里大量出现 llm wiki 知识库、rag graphrag llm wiki 本体 rag、本地 erp rag llm 产品检索 semantic kernel 实例 这些搜索说明大家真正关心的是知识库怎么建、RAG 怎么接、业务系统怎么整合。我把落地路径按从简单到复杂拆开讲。5.1 从 LLM Wiki 到 GraphRAG知识库的必经之路llm wiki 项目 这个热词的核心思路其实是知识库最朴素的形态把文档切片、向量化、存进向量库、召回增强。我建议任何团队都先走这条路线不要在还没跑通 Naive RAG 就上 GraphRAG。微信里有句话叫先完成再完美RAG 也一样。Naive RAG 的坑主要在切片策略上。固定长度 500 字符的切片是省事但经常把一句话从中间切断导致向量检索命中率暴跌。我现在的方法有四个层次一级用 Markdown 标题做段落切分二级按语义完整的句子组切三级给每块做重叠 50 字符的窗口四级给标题和摘要单独建立索引字段。召回效果比固定切片提升的立竿见影而且完全不用换框架。GraphRAG 比向量检索多建了一层实体关系图。它适合做跨文档推理比如两篇文档分布在不同的切片中但都提到数据中台和数据治理把它们建模成实体和关系你问数据中台和数据治理有什么关系时就能直接通过图结构给出整合答案。但成本高到很多人没意识到——建图阶段等于把所有文档重新灌给大模型做信息抽取文档一多token 消耗和耗时让人崩溃。我的建议是先跑通 Naive RAG评估 60% 以上的问题都是单点事实问答时GraphRAG 的投入就可以往后放。5.2 本地 ERP RAG LLM 产品检索实例这个项目是我最近的落地重点也是我认为最有代表性的中小企业落地范式。场景是本地 ERP 系统里存了 2000 多个 SKU每个 SKU 有规格、库存、价格、适用工况业务员在对话窗口里用自然语言问有没有适用高温环境且耐腐蚀的阀门预算 3000 以内传统 SQL 查询搞不定这种模糊条件得靠 RAG。架构是三层第一层用嵌入模型把 SKU 描述向量化存进 pgvector第二层收到问题后先召回 top 20 候选再用 LLM 做结构化抽取把高温、耐腐蚀、预算 3000 映射成查询条件第三层走 SQL 执行并生成自然语言回答。这个流程里 LLM 的角色是条件理解器 回答生成器真正的数据准确性靠 SQL这个设计你一定得记住永远别让 LLM 直接编数据它的核心价值是理解意图和总结答案。5.3 Semantic Kernel 的组装逻辑热词里提到 Semantic Kernel 是有道理的它是微软出的 LLM 编排框架跟 LangChain 抢地盘。两者差别在于LangChain 是链式调用生态大但版本变更频繁Semantic Kernel 以 Planner 为核心更强调技能Skill 插件Plugin的组装对 .NET 生态特别友好。如果你的 ERP 是 C# 写的Semantic Kernel 几乎是无缝融入。// Semantic Kernel 调用本地模型配置示例 var builder Kernel.CreateBuilder(); builder.AddOpenAIChatCompletion( modelId: qwen2.5:14b, apiKey: not-needed, endpoint: new Uri(http://localhost:11434/v1) ); var kernel builder.Build(); // 注册产品检索插件 kernel.ImportPluginFromTypeProductSearchPlugin();这就是本地 ERP RAG LLM 产品检索 semantic kernel的雏形。你要抓的主线是先用 Kernel 对象管理模型连接再把业务能力封装成 Plugin最后用 Prompt 模板把用户问题和 Plugin 组装起来。启动之后整个调用链是清晰的问题出在哪一层一查便知。5.4 Agent 与工具调用的正确玩法热词里 llm powered autonomous agents 是当前最火的方向但也是翻车重灾区。Agent 的本质是模型 工具 循环它每一步都在做决策要不要调用工具、调用哪个、这个结果够不够回答用户。问题在于开源模型对工具调用的格式约束能力参差不齐JSON 格式只要错一个括号整个链路就断。我调试工具调用时最先看的不是模型回答质量而是它输出的tool_calls结构是否合法。如果模型经常乱生成参数第一件事不是骂模型笨而是看 Prompt 里的工具描述写清楚了没每个参数的格式说明都得细化到枚举值、范围、默认值。热词里 llm request failed: provider rejected the request schema or tool payload 这个报错90% 是工具参数格式错了后面排查章节细讲。Agent 架构经验用两个模型的组合调度模型用大模型负责复杂推理和决定调用什么工具执行模型用小模型负责格式化输出。这个组合的稳定性远高于单个模型硬刚。6. 常见报错与排查技巧实录这部分是我的亲兵战场每个报错都烧掉过不止一个晚上。整理成速查表遇到问题先翻这里能救你半条命。6.1 provider rejected the request schema or tool payload这个报错的意思是你的请求体里带的工具定义或者参数格式不合法供应商接口直接拒收根本到不了模型推理那一步。最常见的原因是模型只支持 OpenAI 格式的tools你在请求里传了functions或者工具参数里塞了一个非 JSON 序列化的值比如 datetime 对象再或模型本身根本不支持某种工具模式你却硬传了 structured_output。排查步骤第一步抓包看完整报错很多框架只提示了错误摘要完整信息在 response body 里第二步简化工具有问题的那一个保留一个最小工具测试通过再逐步加第三步确认模型版本是否支持 function callingQwen2.5 系列支持得很好但某些旧版微调模型并不支持这是硬限制。6.2 本地模型请求失败超时与并发挤压本地模型不像闭源 API 那样永远在线显存不够、并发挤压、模型还在加载都会让你看到请求失败。最典型的一个问题vLLM 统计最大并发要根据显存余量来默认值往往过高一个 24GB 显存卡跑 7B 模型并发设 8请求直接排队到饿死。我的做法是一边压测一边看nvidia-smi的显存占用把并发压到显存利用率 90% 以下为止。另一个容易被忽略的是推理引擎的 prefill 与 decode 排队机制。vLLM 里一个长上下文请求会占大量 prefill 计算混在短请求里会让短请求集体超时。解决手段是给长上下文请求单独开一路网关路由或启用特性限制最长输入长度别让一个 128K 的烹饪文档塞爆你所有短请求的拉取。6.3 模型回答变笨的排查清单先别怪模型如果你发现模型之前表现得挺好某天突然变差请按这个顺序排查上下文是不是被截断了输入太长被模型遗忘、量化档位是不是调低了Q2 的退化肉眼可见、温度是不是被改高了生成更发散了、是不是同一个请求里混进了无关的 system prompt 干扰。以上都没问题再考虑业务数据的分布变了。我在生产里遇到过最隐蔽的问题是模型代码层面没变但传入的 RAG 检索结果质量下降向量库数据更新时 embedding 维度配错了导致召回的一堆垃圾片段。所以排查模型变笨时一定要建立一个可以对比的基准集跑同一组固定的测试题才能确认问题出在模型还是链路。6.4 显存不足与模型加载失败的应急预案显存不足这个问题只要你部署就躲不掉我的做法是一是量化档位往下调一档Q4 变 Q3先保证服务能起来二是换推理框架llama.cpp 的 mmap 可以在内存和显存间动态交换比 vLLM 死扛显存更不容易 OOM三是关掉无关的上下文——上下文窗口从 32K 调到 8KKV Cache 能释放出一大块显存这是最容易被忽视的显存杀手。如果还是不行加 Swap 空间作兜底但加了 Swap 后推理速度会明显变慢只适合临时应急不能当长期方案。我更建议的长期方案是模型和向量库分别部署在不同节点别指望一张卡同时扛所有事。一些收尾的个人体会我做开源模型选型这几年最大的体会是模型对比的结论永远是阶段性的。今天 Qwen 领先明天 Llama 追上来后天又出现新的蒸馏技术死守某个最强模型是没意义的。真正有价值的是你手里那套评测集和部署链路它让你在任何新模型发布时都能在半天之内判断出值不值得切换。如果你现在正准备入坑我的建议是不要试图一步到位。先用 Ollama 加 Qwen2.5-7B 的 Q4 量化版把端到端链路跑通然后挂上 RAG 接真实数据测试之后再根据业务复杂度升级到 14B 或 32B。这一套流程走完你已经比大多数只看榜单选模型的人要懂得多了。最后一个小技巧无论你选什么模型在任何业务上线前固定一组 30 道与业务相关的测试题把模型输出过一遍再上线每次升级模型都重新跑一遍这组测试题才是你真正持有的判断力。