开源模型选型指南：Llama、Qwen、DeepSeek、Mistral、Gemma、Phi、GLM与Yi
摘要
本文讨论开源和开放权重模型的生产选型问题。文章不把 Llama、Qwen、DeepSeek、Mistral、Gemma、Phi、GLM 与 Yi 处理成“谁更强”的横向榜单，而是把它们放入任务、许可证、推理栈、语言场景、量化质量、硬件预算、微调空间和长期维护成本构成的决策系统中。核心观点是：开源模型的真正优势不是“免费”，而是当团队拥有评测、部署和治理能力时，可以把模型变成可控的产品资产；如果缺少这些能力，本地能跑只会把外部 API 风险换成内部工程风险。
关键词
开源模型；开放权重；模型选型；私有化部署；量化；推理框架；中文任务；许可证
研究问题与方法
本文研究的问题是：一个团队如何从“模型家族很多、排行榜很多、版本很多”的噪声中，选出能承担真实业务的模型组合。方法上，文章先把应用拆成能力节点，再用同一组维度比较候选模型：任务质量、语言适配、上下文使用、工具调用、硬件成本、许可证风险、部署生态和迁移成本。这样得到的不是单一冠军，而是面向不同任务层级的模型矩阵。
选型路径可以表达为一个从任务到证据的漏斗。每一层都应淘汰一批不合适模型，而不是在最后靠主观手感拍板。
候选模型的综合得分可用下式近似：
其中 是模型在某一评测维度上的质量， 是业务权重。公式的意义在于把“模型强不强”改写成“在约束内是否值得维护”。
开源模型选型，最容易掉进两个坑。第一个坑是把排行榜当成采购单，谁分高就上谁。第二个坑是把本地能跑当成生产可用，模型能在显卡上吐字，就以为它已经适合真实业务。大模型不是普通依赖库，选型也不是在同一类零件里挑参数最高的那个。模型的能力、许可、上下文、语言、工具调用、推理模式、部署生态、量化质量、显存账、数据安全和长期维护，都会影响最终结果。
对团队来说，最实用的问题不是“哪个开源模型最强”，而是“哪个模型在我的任务、我的硬件、我的成本和我的风险边界里最稳”。同一个模型，在聊天演示里显得聪明，在企业知识库里可能引用混乱；在数学题上很强，在客服分类里可能太慢；在英文代码里表现好，在中文制度问答里未必稳；在云端 API 上体验顺滑，搬到本地量化后可能格式输出错误增多。选型要从任务反推模型，而不是从模型发布新闻反推产品。
这篇指南围绕八个常见开源或开放权重模型家族展开：Llama、Qwen、DeepSeek、Mistral、Gemma、Phi、GLM 和 Yi。它们代表了当前开放模型生态里的几种典型路线：通用大模型路线、中文和多语言路线、推理强化路线、小模型高效路线、多模态和端侧路线、智能体工具调用路线、老牌长上下文路线。每个家族都有适合的场景，也都有不该硬上的边界。
先说明一个词。很多模型被社区习惯称为“开源模型”，但严格看，模型权重、训练代码、数据、许可证、使用限制、再分发条件并不完全一样。Llama 长期采用自己的社区许可，Gemma 早期也有专门许可而 Gemma 4 转向 Apache 2.0，Qwen 多数主线模型采用 Apache 2.0，DeepSeek-R1 采用 MIT，Mistral 的开放模型既有 Apache 2.0 也有非生产许可历史，GLM-4.5 采用 MIT，Yi-1.5 采用 Apache 2.0。工程选型时不要只看“open”字样，要读模型卡和许可证原文。
引言：选模型之前，先把任务拆清楚
模型选型第一步不是列候选模型，而是拆任务。一个真实应用通常不是一个单一问答场景，而是多个能力节点的组合：用户意图理解、知识检索、长文档阅读、结构化抽取、工具调用、代码生成、计划分解、内容改写、合规拒答、多轮对话状态维护、引用生成、表格理解和错误恢复。不同节点对模型的要求并不相同。
比如企业知识库问答，最重要的通常不是自由发挥，而是证据定位、引用准确、版本意识和拒绝无证据回答。代码助手关注仓库上下文、补丁一致性、测试理解和命令执行建议。智能体任务关注工具调用稳定性、参数格式、状态跟踪和失败后修正。文案创作关注风格控制和长文本连贯。数学推理关注中间步骤和答案校验。端侧助手关注延迟、功耗、内存和离线能力。把这些任务混在一起，最后只会得到一个看似均衡但处处妥协的选择。
第二步是确定输入输出形态。输入是否主要是中文，是否中英混合，是否有代码、表格、图片、音频、扫描件、PDF、网页、数据库记录。输出是否需要 JSON、Markdown、表格、自然语言、函数调用参数、SQL、代码补丁或多步计划。模型在聊天里回答自然，不等于能稳定输出合法 JSON；模型支持长上下文，不等于能准确利用中间证据；模型宣称多模态，不等于能读懂业务表格和票据版式。
第三步是确定部署边界。你是调用云端托管，还是自建推理服务；是单机消费显卡，还是多卡服务器；是低并发内部工具，还是外部用户高峰服务；是允许发送数据到第三方平台，还是必须内网部署。大模型选型一定要和推理栈一起看。vLLM、SGLang、llama.cpp、Ollama、Transformers、TensorRT-LLM、MLX、LiteRT-LM 对不同模型的支持成熟度不同，最终体验可能比模型理论能力更重要。
第四步是建立业务评测集。没有评测集，选型就是看宣传材料。评测集不必一开始很大，但要覆盖真实失败类型：用户原话、长文档、模糊问题、相似条款、过期资料、中文术语、工具失败、格式约束、拒答边界和多轮修正。每个候选模型都用同一套输入、同一套提示词、同一套检索结果、同一套采样参数评估。只用三五个手工问题试模型，很容易被某次好答案误导。
判断模型的十个维度
第一个维度是基础能力。基础能力包括语言理解、常识、推理、代码、数学、指令遵循和长文本组织。Llama、Qwen、Gemma、Mistral、GLM 这类通用家族通常覆盖面较广；DeepSeek-R1、Phi-4-reasoning、GLM-4.5、Qwen3 thinking 模式更强调推理；Mistral Devstral、Qwen Coder、Codestral 等更偏代码。基础能力要按业务任务测，而不是只看 MMLU、AIME 或 Chatbot Arena。
第二个维度是语言和地域适配。中文业务不能只看英文 benchmark。Qwen、DeepSeek、GLM、Yi 对中文生态更友好，中文术语、制度文本、考试题、客服表达和中英混杂代码场景通常更值得优先测试。Llama、Mistral、Gemma、Phi 在英文和全球生态里有很强资源，中文能力也在进步，但具体任务仍要实测。多语言支持不是“会翻译”这么简单，还包括术语一致性、标点、单位、格式习惯和文化语境。
第三个维度是上下文长度。长上下文对合同、论文、代码仓库、会议记录和知识库问答很有吸引力。Meta 在 Llama 3.1 中把上下文扩到 128K，Llama 4 Scout 文档标注了更长窗口；Qwen3 官方博客提到训练阶段扩展到 32K，并在生态中有更长上下文版本；Gemma 4 官方介绍区分边缘模型 128K 和大模型更长窗口；GLM-4.5 模型卡强调 128K；Yi 早期就有 200K 长上下文分支。问题是，长窗口不等于稳定阅读。长输入会增加延迟、显存和注意力负担，相关证据放在中间也可能被忽略。
第四个维度是推理模式。DeepSeek-R1 让开放推理模型进入大众视野，展示了强化学习和蒸馏在数学、代码、复杂问题上的价值。Qwen3 提供 thinking 与 non-thinking 的混合路线。GLM-4.5 也明确区分 thinking mode 和 non-thinking mode。Phi-4-reasoning、Phi-4-mini-reasoning 把小模型推理做成细分方向。推理模型适合难题，但不适合所有请求都深思。简单客服、分类、摘要、短改写如果强制走长思考，会浪费成本并增加等待。
第五个维度是工具调用和智能体能力。现代应用不是只让模型聊天，而是让模型查询数据库、调用搜索、读文件、生成代码、执行工作流。Gemma 4 官方强调函数调用、结构化 JSON 和系统指令；Qwen3 后训练包含 agent capabilities；GLM-4.5 定位为智能体基础模型；Mistral 文档把 function calling 和 agentic workflow 作为重要场景；Llama 生态有 Llama Stack 和安全组件。工具调用要测参数正确率、缺参追问、错误恢复、重复调用控制和对工具结果的归纳能力。
第六个维度是部署生态。一个模型再强，如果推理引擎支持差、chat template 混乱、tokenizer 兼容问题多、量化版本质量参差，就会拖慢落地。Llama、Qwen、Mistral、Gemma 在 Hugging Face、vLLM、llama.cpp、Ollama、SGLang 等生态里通常资料更多。GLM-4.5 模型卡明确给出 vLLM、SGLang、transformers 相关用法和硬件建议。Yi-1.5 有成熟的 Hugging Face 模型卡和 vLLM/SGLang 示例，但更新节奏相对没那么激进。生产团队应该把“能否稳定服务”纳入评分。
第七个维度是许可证和商业风险。Apache 2.0、MIT 通常更清晰，社区和企业采用阻力较小。Llama 的社区许可有特殊条款，不能只按传统开源许可证理解。Mistral 某些开放模型是 Apache 2.0，某些代码模型历史上使用非生产许可。Gemma 4 切换到 Apache 2.0 是重要信号，但老版本仍要看具体许可证。模型派生关系也要看，比如 DeepSeek-R1 的蒸馏模型基于 Qwen 和 Llama，不同衍生版本涉及不同原始许可证。商业部署前应让法务或合规读原文。
第八个维度是硬件成本。模型参数量只是粗略指标。MoE 模型有总参数和激活参数之分，DeepSeek-R1 是 671B 总参数、37B 激活参数，GLM-4.5 是 355B 总参数、32B 激活参数，Qwen3-235B-A22B 是 235B 总参数、22B 激活参数。MoE 可以降低单 token 计算，但部署仍需要存放总权重，并处理路由、通信和显存。小模型如 Phi、Gemma E2B/E4B、Llama 1B/3B、Mistral Small、Qwen 小尺寸更适合低延迟和边缘场景。
第九个维度是量化和微调。很多团队会下载 INT4、AWQ、GPTQ、GGUF 或 FP8 版本，但量化不是无损压缩。权重量化可能保住闲聊质量，却损害 JSON、工具参数、数学和引用准确性。微调也不是万能，数据质量差会让模型更固执地犯错。选择模型时，要看官方是否提供量化版本，社区量化是否活跃，LoRA/QLoRA 是否成熟，推理框架是否支持对应格式。
第十个维度是维护节奏。模型家族更新太快，会带来迁移成本；更新太慢，会落后生态。Qwen、Gemma、Mistral、GLM 在 2025 到 2026 年都有较活跃发布；Llama 生态仍然庞大；DeepSeek-R1 作为推理模型标杆有强影响；Phi 持续强化小模型路线；Yi 的主线模型相对稳定，更像成熟候选而非追新焦点。长期产品需要稳定版本策略，而不是每次发布就立刻替换。
Llama：生态最宽，适合做通用底座和安全可控系统
Llama 的最大优势是生态。Meta 从 Llama 2、Llama 3 到 Llama 3.1、Llama 3.2，再到 Llama 4，把开放权重模型推成了开发者默认候选之一。Llama 3.1 官方文章强调 8B、70B、405B，128K 上下文、多语言、工具使用和更完整的 Llama Stack。Llama 4 文档进一步把 Scout、Maverick 和 Guard 放在同一套开发入口里，说明 Llama 不只是模型权重，而是想成为一套应用开发生态。
选 Llama，通常是选成熟生态、丰富教程、云厂商支持、推理框架适配和大量社区派生。很多开源 Agent、RAG、微调、评测、量化项目都会优先支持 Llama。遇到问题时，搜索资料更容易找到同类经验。对企业来说，这种生态确定性很重要，因为生产问题很多不是模型能力问题，而是部署、监控、格式、回滚和安全治理问题。
Llama 适合几类场景。第一类是通用英文和多语言应用，需要可控部署、成熟安全组件和广泛第三方集成。第二类是需要微调或蒸馏的团队，Llama 社区里有大量训练脚本、数据处理经验和评测基线。第三类是希望把模型纳入标准化 AI 平台的团队，Llama Stack、Llama Guard、Prompt Guard、LlamaFirewall 等组件提供了一个相对完整的安全和应用框架。第四类是希望在云厂商和本地之间切换的团队，Llama 在各大云和本地工具里的可用性都较高。
Llama 的限制也要看清。它不是传统意义上无条件开源，许可证需要单独评估。中文任务虽然可用，但在很多中文知识密集场景，Qwen、DeepSeek、GLM、Yi 可能更值得优先比较。大尺寸 Llama 对硬件要求高，405B 或 Llama 4 大模型不是普通团队轻松自托管的选择。小尺寸 Llama 适合端侧和轻任务，但不能期待它承担复杂推理和严肃知识问答。
如果你要选 Llama，建议不要只问“用哪个版本”。更好的问题是：要不要把 Llama 作为平台默认通用模型；是否需要 Llama Guard 这类安全组件；是否需要自建微调和评测流程；是否接受 Llama 许可；中文业务是否已通过真实评测；本地量化版本是否保留结构化输出能力。只要这些问题回答清楚，Llama 是非常稳的底座型选择。
Qwen：中文、多语言、代码和智能体任务的强候选
Qwen 的优势在于覆盖面和中文友好度。Qwen3 官方博客介绍了 dense 和 MoE 两条线，包括 Qwen3-235B-A22B、Qwen3-30B-A3B，以及多个小尺寸 dense 模型。官方强调 36T 训练 token、119 种语言和方言、思考与非思考模式、代码、数学、工具和 agent 能力。对中文团队来说，Qwen 往往是第一个应该认真测试的开放模型家族。
Qwen 很适合企业中文知识库、中文客服、中文文档抽取、代码助手、教育题解、智能体工具调用和混合推理场景。它的模型尺寸跨度大，从轻量模型到大 MoE 都有，便于做分层路由。简单任务可以用小模型，复杂推理用大模型或 thinking 模式，代码任务用 Coder 系列，检索可配 Qwen3 Embedding 和 Reranker。这种家族完整性对平台化团队很有价值。
Qwen3 的 thinking / non-thinking 路线非常适合做成本控制。不是所有请求都应该深度思考。用户问“把这段话润色一下”，走快速模式即可；用户问“分析合同里的付款风险并引用条款”，可以开启思考；用户让模型调用多个工具完成任务，则要测工具调用模式。模型本身提供模式选择，应用层就有机会按任务复杂度路由，而不是所有请求走同一种采样和同一种提示词。
Qwen 的另一个优势是工程生态。官方文档、GitHub、Hugging Face、ModelScope、Kaggle、Ollama、LM Studio、MLX、llama.cpp、KTransformers 等路径都比较活跃。对于国内网络、中文资料、国产推理平台和本地化部署，Qwen 往往比很多海外模型更顺手。Apache 2.0 许可也降低了很多商业采用障碍。
Qwen 的风险主要来自版本和模式复杂度。Qwen2.5、Qwen3、Coder、Math、VL、Omni、Embedding、Reranker、Instruct、Thinking、AWQ、FP8 等版本很多，团队容易混用模型卡和提示格式。不同版本的 chat template、思考控制方式、上下文长度、工具调用格式可能不同。生产选型要固定模型 ID、固定模板、固定推理参数，不能靠“Qwen 大概都一样”的印象上线。
如果你的业务是中文优先、兼顾代码和智能体，Qwen 通常应该进入第一梯队。选型时可以用三层方案：小尺寸 Qwen 处理高频轻任务，中等 dense 或 MoE 处理主流程，大模型或 thinking 模式处理复杂推理；再配专门 embedding/reranker 做检索。这样比一个模型包打天下更稳。
DeepSeek：复杂推理和蒸馏路线的代表，但不该滥用
DeepSeek-R1 的重要性不只是一个模型分数高，而是它改变了很多团队对开放推理模型的预期。官方 GitHub 和论文说明，DeepSeek-R1-Zero 通过大规模强化学习在没有先做监督微调的情况下涌现出自我验证、反思和长链推理行为；DeepSeek-R1 又引入 cold-start 数据和多阶段训练，改善可读性和语言混杂问题。官方还发布了基于 Qwen 和 Llama 的多个蒸馏 dense 模型。
DeepSeek 适合数学、代码竞赛、复杂逻辑、规划、难题分析和需要多步推理的任务。它也适合作为蒸馏老师，让较小模型学习推理轨迹。对研发团队来说，DeepSeek-R1 的蒸馏模型很有实用价值：不一定部署完整 671B MoE，而是测试 R1-Distill-Qwen-14B、32B、R1-Distill-Llama-70B 等版本，在成本和推理能力之间找平衡。
DeepSeek-R1 的使用方式和普通聊天模型不同。官方 README 给出了一些使用建议，比如 temperature 推荐范围、避免系统提示词、数学问题给出明确逐步推理要求、评测时多次测试取平均。这些建议说明推理模型不是“随便换上去就好”。如果应用层仍然沿用旧模型提示词，可能出现重复、过度思考、语言混杂、输出太长或响应太慢。
DeepSeek 的主要风险是成本和用户体验。复杂推理模型会生成长思考过程，延迟和 token 成本可能显著增加。对简单问题，它可能显得啰嗦；对需要直接执行的客服流程，它可能把本该快速完成的任务变成长篇分析。生产应用应该把 DeepSeek 类模型放在“复杂问题升级通道”，而不是所有请求的默认入口。
还有一个现实问题是引用和事实。推理强不等于事实永远正确。模型可以很会推理，但如果输入证据错、检索漏、知识过期，仍然会给出自洽但错误的答案。DeepSeek 适合做推理器，不应替代检索、数据库、规则约束和结果校验。很多“看起来会思考”的答案，反而更容易让用户相信错误结论。
如果你的产品需要解数学题、写算法、修复杂代码、做多步计划、分析技术方案，DeepSeek 是必须测试的候选。如果你的产品主要是低延迟客服、简单摘要、短文本分类、固定表单抽取，DeepSeek 可能不是默认最优。好选型不是用最聪明的模型回答所有问题，而是让聪明模型出现在真正需要它的地方。
Mistral：效率、欧洲生态和多样开放模型的实用路线
Mistral 的特点是模型线丰富，且长期强调效率。Mistral 7B、Mixtral、Mistral Small、Mistral Nemo、Pixtral、Codestral、Devstral、Magistral 等名字覆盖通用、MoE、多模态、代码、智能体和推理。Mistral 官方模型总览在 2026 年已经列出 Mistral Large 3、Mistral Small 4、Devstral 2、Ministral 3 等开放或托管模型，说明它已经从单模型公司变成完整模型平台。
Mistral Small 3.1 官方文章强调 Apache 2.0、128K 上下文、多模态、多语言、单 RTX 4090 或 32GB Mac 可运行、低延迟 function calling。这样的定位很清晰：不是追求最大参数，而是把可部署性和质量放在一起。对很多企业和个人开发者来说，一个能在单机或低成本 GPU 上稳定跑的 20B 级模型，比一个理论上更强但部署困难的大模型更有价值。
Mistral 适合几个方向。第一是低延迟通用助手，尤其是需要欧洲厂商生态、私有部署和许可证清晰的团队。第二是代码和软件工程任务，Devstral、Codestral、Mistral Small 系列都值得测试。第三是多模态轻量应用，Pixtral、Mistral Small 3.1 这类模型可以处理图文输入。第四是希望在 Apache 2.0 开放模型上做二次开发的团队。
Mistral 的注意点是许可证差异和版本生命周期。官方文档里不同模型有 Open、Premier、Labs、Legacy、Deprecated 等状态；一些历史模型有非生产许可，一些新模型是 Apache 2.0。生产选型时要确认具体模型版本和退役时间。Mistral 文档会标注替代模型和退休计划，这对长期服务很关键。不要只看社区帖子里的模型名，要看官方当前文档。
Mistral 还有一个优势是模型规模和推理效率的平衡。很多团队不需要最大模型，而需要稳定、便宜、快、可微调、能本地跑。Mistral 的小中型模型正好适合这类需求。如果你的应用重视响应速度、私有部署、成本可控和英文/多语言能力，Mistral 很值得进入候选名单。
Gemma：端侧、多模态和开放许可转向后的新选择
Gemma 是 Google DeepMind 面向开放社区的模型家族，定位一直偏轻量和开发者友好。Gemma 3 官方模型卡强调 128K 上下文、140 多种语言、多尺寸和单 GPU 可运行。2026 年 Google 发布 Gemma 4，官方博客称其为最强开放 Gemma 家族，并转向 Apache 2.0 许可，提供 E2B、E4B、26B MoE、31B Dense 四种形态，覆盖边缘设备、个人工作站和更强本地推理。
Gemma 4 的卖点很明确：高级推理、agentic workflows、函数调用、结构化 JSON、代码生成、视觉和音频输入、更长上下文、140 多语言、Android 和边缘生态。对希望把 AI 放到手机、笔记本、IoT、Jetson、Raspberry Pi 或本地 IDE 里的团队，Gemma 很有吸引力。Google 还强调 AI Edge、LiteRT-LM、vLLM、llama.cpp、Ollama、MLX、NVIDIA NIM、SGLang 等工具支持，这说明 Gemma 不只是研究模型，而是想打端到端开发者生态。
Gemma 适合端侧助手、离线代码辅助、低功耗设备、个人生产力工具、教育应用、多语言轻量应用和需要图像理解的本地应用。E2B、E4B 这类 effective 小模型不应该和大模型比绝对智力，它们的价值在于低延迟、隐私、断网可用和设备级集成。26B MoE 和 31B Dense 则更适合作为单机或工作站级通用模型。
Gemma 的风险在于不要把“Google 出品”误解成事实权威。Gemma 是开放模型，仍可能幻觉；如果用于事实问答、医疗、金融、法律或人物信息，需要检索、引用和安全策略。另一个注意点是不同 Gemma 版本许可证不同，Gemma 4 的 Apache 2.0 不自动覆盖所有旧版本。模型卡、用途限制和责任说明仍然要读。
如果你的产品需要在用户设备上运行，或者希望构建低成本、多模态、本地优先的 AI 功能，Gemma 应该重点测试。它未必是中文企业知识库的第一选择，但在端侧、多模态和 Google 工具链里非常强。未来端侧 AI 的很多模式，很可能会围绕 Gemma、Phi、Llama 小模型和 Qwen 小模型展开。
Phi：小模型高质量路线，适合受限环境和专门推理
Phi 的定位和大多数通用模型不同。Microsoft 把 Phi 做成小语言模型路线，强调高质量数据、合成数据、推理、低延迟和受限环境。Phi-4 模型卡显示它是 14B dense decoder-only Transformer，16K 上下文，MIT 许可，主要面向英文、数学和复杂推理。Phi-4-mini-reasoning 则是 3.8B 小模型，模型卡标注 128K 上下文，专注数学推理，基于合成数学数据和 DeepSeek-R1 蒸馏。
Phi 的价值不是替代所有大模型，而是在小模型里榨出尽量多的能力。对边缘设备、内网小服务、教育数学、低延迟推理、资源受限场景，Phi 很值得测试。一个 3.8B 或 14B 模型如果能解决足够多的任务，就能显著降低部署成本和响应延迟。小模型也更容易做本地实验和快速迭代。
Phi 适合专门任务，而不是广泛知识型中文问答。Phi-4 模型卡明确提示它主要适合英文，且开发者应评估准确性、安全和公平性。Phi-4-mini-reasoning 的训练数据主要是合成数学内容，强项自然集中在数学和逻辑。把它用于中文政策问答、企业知识库、复杂多语言客服，可能不如 Qwen、GLM、DeepSeek、Llama 等更合适。
Phi 的另一个优势是许可证简洁。MIT 对商业使用和二次开发比较友好。对于希望在产品里嵌入一个小模型、做本地推理或作为更大系统的辅助节点，Phi 的法律和工程门槛相对低。比如可以用 Phi 做初筛、分类、数学子任务、格式转换、离线辅助，再把难题交给大模型。
选 Phi 的关键是边界管理。不要让小模型承担超出能力范围的开放世界事实问答。给它清晰任务、受控输入、明确输出格式和可校验结果，它会很有价值。让它替代大模型回答所有复杂业务问题，失望会来得很快。
GLM：中文智能体、代码和混合推理的新强项
GLM 是智谱系模型家族。GLM-4 早期以多语言、多模态对话模型形式开源，GLM-4.5 则把定位推向智能体、推理和代码。GLM-4.5 Hugging Face 模型卡写得很直接：它是面向智能体的基础模型，GLM-4.5 有 355B 总参数、32B 激活参数，GLM-4.5-Air 有 106B 总参数、12B 激活参数，支持 thinking mode 和 non-thinking mode，开放 base、hybrid reasoning 和 FP8 版本，MIT 许可，可商用和二次开发。
GLM-4.5 的价值在于把中文生态、MoE、推理、代码和工具调用放在同一个模型线里。论文摘要也把它称为 Agentic、Reasoning、Coding 基础模型，强调多阶段训练、专家模型迭代和强化学习。对中文智能体平台、代码开发平台、复杂工具调用系统和企业内网助手，GLM 是非常值得测试的候选。
GLM 的工程资料相对具体。模型卡给出 vLLM 和 SGLang 启动示例、tool-call-parser、reasoning-parser、FP8 推理、128K 上下文满血配置和硬件建议。这对生产部署很重要，因为很多大模型发布只给能力宣传，不给足够明确的推理边界。GLM-4.5 明确告诉你完整 128K 上下文需要更多 GPU，这比只写“支持 128K”更诚实。
GLM 的风险也来自规模。355B-A32B 和 106B-A12B 不是普通团队随便本地部署的模型。即使有 FP8，仍然需要高端多卡，尤其是长上下文。GLM-4.5-Air 更实用，但也不是消费级轻模型。团队要判断自己是调用 API、托管部署，还是自建服务。如果只是单机 24GB 显卡，GLM-4.5 不是合适入口。
另一个注意点是国际生态。Llama、Qwen、Mistral、Gemma 在全球开发者中资料更多，GLM 的中文资料和国内生态更强。若团队的工程栈、云环境和开发者主要在中文环境，GLM 很有优势；若主要依赖海外生态和英文资料，Llama、Mistral、Gemma 可能更省心。
如果你的目标是中文智能体、复杂工具调用、代码修复和高质量中文推理，GLM-4.5 和 GLM-4.5-Air 应该进入严肃评测。不要因为它大就直接排除，也不要因为分数高就忽略部署成本。它更适合作为平台高级能力节点，而不是所有轻任务的默认模型。
Yi：稳定中文基础模型和长上下文历史优势
Yi 是 01.AI 推出的开放模型家族。Yi 论文介绍了 6B 和 34B 基础模型，并扩展到 chat、200K 长上下文、depth-upscaled 和视觉语言模型。Yi-1.5 模型卡显示，它是在 Yi 基础上继续用 500B 高质量语料预训练，并用 3M 多样微调样本训练，覆盖 6B、9B、34B 等尺寸，提供 4K、16K、32K 等上下文版本，采用 Apache 2.0 许可。
Yi 的优势在于中文和英文基础能力均衡、长上下文路线较早、模型相对稳定、许可证清晰。对不想追逐每月新模型、希望找一个成熟开放权重基座的团队，Yi 仍有价值。Yi-1.5-34B-Chat 在很多中文和通用任务里可以作为强基线，尤其适合比较新模型是否真的带来收益。
Yi 不一定是当前最热的模型家族，但这未必是坏事。生产系统需要稳定性，过度追新会带来模板迁移、参数重调、评测重跑和用户体验波动。Yi 可以作为一个可靠参照：如果新模型在你的业务评测里没有明显超过 Yi，那么没有必要只因发布更晚就切换。
Yi 的限制是生态热度和模型更新节奏不如 Qwen、Gemma、Mistral、GLM 等活跃。工具调用、agent、原生多模态和推理模式上，Yi-1.5 不是最前沿选择。若你的任务是复杂智能体、强代码修复或最新推理能力，Qwen3、DeepSeek-R1、GLM-4.5、Gemma 4、Mistral 新系列可能更值得优先。
Yi 适合做中文通用基线、长文档阅读候选、企业内网问答候选和成本可控的 34B 级模型。它的正确位置不是追热点，而是作为稳态选择。对很多项目来说，一个稳定、可商用、容易部署、中文表现不错的模型，比一个能力更强但迁移成本高的新模型更适合长期运行。
按场景给出选型建议
中文企业知识库问答，优先测试 Qwen、GLM、DeepSeek 蒸馏模型、Yi，再加入 Llama 或 Mistral 做对照。关键指标不是答案好听，而是引用是否正确、是否使用最新版本、是否拒绝无证据回答、是否能处理相似条款。模型之外还要配好切分、召回、重排和引用格式。若检索差，换模型只是让错误更流畅。
复杂数学、代码竞赛和多步推理，优先测试 DeepSeek-R1、Qwen3 thinking、GLM-4.5 thinking、Phi-4-reasoning、Mistral Magistral。评测时要控制输出长度、温度和最终答案格式。推理模型要看最终正确率，也要看延迟和成本。很多产品可以设置“深度分析”按钮，把推理模型变成用户可选择的增强能力。
代码助手和软件工程，优先测试 Qwen Coder、Mistral Devstral 或 Codestral、DeepSeek、GLM-4.5、Llama 大尺寸和 Gemma 4 大尺寸。关键指标是能否理解仓库上下文、生成可应用补丁、减少编译错误、读懂测试失败、避免破坏无关文件。代码任务不要只用 HumanEval，要用真实仓库问题和修复回放。
端侧和离线助手，优先测试 Gemma E2B/E4B、Phi mini、Llama 1B/3B、小尺寸 Qwen、Mistral Ministral。指标要包括启动时间、内存、功耗、首 token 延迟、断网可用、隐私和量化后质量。端侧模型不要追求大而全，应围绕明确本地任务设计，比如摘要、改写、语音转文本后指令理解、设备控制和轻量问答。
智能体工具调用，优先测试 Qwen3、GLM-4.5、Gemma 4、Mistral Small 4/3.1、Llama。评测集要包含工具参数、缺失信息、工具报错、重复调用、长任务状态和多轮计划修正。一个模型说自己支持 function calling 不够，必须验证它在错误条件下能否停止、重试、改参和解释。
多模态文档和图像理解，优先测试 Gemma 4、Mistral Pixtral/Small 多模态、Qwen-VL、GLM-V、Llama 多模态。要用真实票据、截图、表格、扫描 PDF、模糊图片和中文混排材料测试。多模态模型容易在演示图片上表现很好，在企业文档上因为 OCR、版式、表格合并和页眉页脚出错。
低成本通用助手，优先测试 Mistral Small、Qwen 中小尺寸、Gemma 31B/26B、Llama 8B/70B 量化、Yi-1.5、Phi-4。这里的关键是单位有效回答成本。不要只看 tokens/s，要看错误率、重试率、人工修正成本和用户等待。便宜模型如果经常答错，真实成本会比贵模型更高。
不要用一个模型解决所有问题
成熟系统通常不是单模型系统，而是模型路由系统。轻任务用小模型，复杂任务用大模型；普通问答用快速模式，难题用推理模式；结构化抽取用稳定格式模型，开放创作用风格模型；检索前用 embedding，检索后用 reranker，生成时用通用或推理模型；安全边界用 guard model 或规则加模型共同处理。这样做比把所有请求扔给一个最大模型更经济，也更容易控制质量。
模型路由可以从简单规则开始，但不要做成硬编码假智能。实际做法应该基于任务分类、输入长度、用户意图、风险等级、历史失败、工具需求和成本预算。比如同一个知识库问题，如果召回证据足够且问题简单，用 Qwen 中模型即可；如果证据冲突、涉及多文档比较或要求推理，可以升级到 DeepSeek 或 GLM thinking；如果用户只是让改写语气，小模型就足够。
路由系统必须可观测。每次请求要记录模型、版本、提示模板、检索片段、重排分数、输出长度、延迟、错误类型和用户反馈。否则模型越多，问题越难定位。生产级选型不是一次性决策，而是持续评估。新模型可以进入影子评测，先在离线集和少量灰度中比较，再决定是否替换。
评测也要分层。模型裸测只回答“模型本身会不会”；RAG 测试回答“给证据后会不会”；工具测试回答“能不能干活”；端到端用户旅程回答“用户是否拿到正确结果”。很多团队只做裸测，然后上线 RAG 或 Agent，出问题又怪模型。模型选型必须连同应用链路一起测。
实用评分表
可以给每个候选模型打十项分数：任务准确率、中文能力、长上下文使用、结构化输出、工具调用、延迟、吞吐、显存成本、许可证清晰度、生态成熟度。每项不一定等权。知识库问答应提高引用准确和中文权重；代码助手提高仓库修复和工具权重；端侧应用提高延迟和内存权重；合规业务提高许可证和私有部署权重。
评分时要避免“平均主义”。一个模型在十项里都不错，但核心任务不够好，就不该选为主模型。反过来，一个模型只在数学推理上强，但你的产品正好是数学辅导，它就是好选择。选型的本质是匹配，不是找全能冠军。
还要设置淘汰线。许可证不满足，直接淘汰；部署成本超预算，直接淘汰；结构化输出失败率超过业务阈值，直接淘汰；中文核心术语经常错，直接淘汰；引用无法稳定对应证据，知识库场景直接淘汰。没有淘汰线，团队会被模型优点诱惑，忽略上线后最痛的缺点。
最后做一次真实流量压测。模型在离线单请求里表现好，不代表高并发下稳定。长上下文会吃 KV Cache，推理模型会增加输出 token，小模型量化可能在高并发下速度很好但错误率上升。生产前至少要测短输入短输出、短输入长输出、长输入短输出、长输入长输出、多轮会话和取消请求。
推荐的起步组合
如果是中文 AI 应用平台，起步可以选 Qwen 作为主力通用模型，DeepSeek 或 GLM 作为复杂推理升级，Qwen Embedding/Reranker 或同类检索模型作为知识库底座，再用小尺寸 Qwen、Gemma 或 Phi 处理轻任务。这样覆盖中文、推理、检索和成本。
如果是全球化英文开发者产品，可以选 Llama 或 Mistral 作为通用模型，Gemma 作为端侧和多模态补充，DeepSeek 或 Phi-reasoning 作为推理节点。这个组合生态资料丰富，云端和本地选择都多。
如果是本地离线工具，可以优先测试 Gemma、Phi、Mistral Small、小尺寸 Qwen、Llama 小模型。目标不是最高智力，而是可安装、可运行、响应快、隐私好。复杂任务可以允许用户手动接入更大远程模型。
如果是代码智能体，可以从 Qwen Coder、DeepSeek、GLM-4.5、Mistral Devstral、Llama 大模型、Gemma 4 里选。评测标准必须是真实仓库修复，而不是单文件代码题。工具调用、补丁应用和测试失败解释，比闲聊能力更重要。
如果是企业严肃知识库，不要只选生成模型。先建立文档清洗、结构化切分、混合召回、重排、引用、版本管理和离线评测，再测试 Qwen、GLM、Yi、Llama、Mistral、DeepSeek。RAG 系统里，模型只是最后一环，证据质量决定上限。
结论：选型不是追新，是建立可验证的模型组合
Llama 胜在生态和通用底座。Qwen 胜在中文、多语言、代码和完整家族。DeepSeek 胜在复杂推理和蒸馏影响力。Mistral 胜在效率、开放模型多样性和部署实用性。Gemma 胜在端侧、多模态和 Google 工具链。Phi 胜在小模型高质量和受限环境。GLM 胜在中文智能体、代码和混合推理。Yi 胜在稳定中文基线和早期长上下文积累。
没有哪个模型永远是最优。真正可靠的做法，是建立自己的任务评测、成本模型、部署基线和模型路由。每个模型进入系统前，都要回答四个问题：它解决了哪个具体任务；它比当前方案强在哪里；它的成本和风险是否可接受；它失败时系统如何发现和降级。能回答这些问题，模型选型才从追热点变成工程能力。
开源模型生态的价值，不是让所有团队都用同一个模型，而是让团队可以掌握选择权。你可以把数据留在本地，可以微调自己的模型，可以用小模型降低成本，可以用推理模型处理难题，可以组合多个模型形成自己的智能系统。选型做得好，开源模型不是便宜替代品，而是产品能力和技术主权的基础。
迁移模型时最容易被低估的成本
模型迁移不是把配置里的模型名从 A 改成 B。真正的迁移会碰到 tokenizer、chat template、系统提示词、工具调用格式、结构化输出、采样参数、上下文长度、停止词、流式输出、错误码、内容安全、量化格式和监控指标。很多团队在演示环境里换模型很快，上线后才发现旧提示词不再适配，新模型输出风格改变，前端解析失败，用户历史会话里混入旧模型格式。
第一项成本是模板迁移。不同模型家族有不同 chat template，有些要求明确 system、user、assistant，有些对工具调用有专门格式，有些推理模型不建议使用复杂系统提示词，有些模型需要显式控制 thinking 模式。模板不对，模型会表现得像能力下降。迁移时应该把模板视为模型的一部分，连同模型版本一起固定和评测。
第二项成本是输出合同。应用通常依赖模型输出里的字段、标题、编号、JSON 结构或工具参数。新模型即使语义正确，也可能换一种表达方式。比如旧模型稳定输出 {"answer": "...", "sources": [...]}，新模型喜欢在 JSON 前后加解释；旧模型工具参数用字符串，新模型用数组；旧模型引用编号从 1 开始，新模型输出文档标题。生产系统要用 schema、解析器和验证器控制，而不是假设模型永远听话。
第三项成本是安全边界。不同模型的拒答风格不同，有些更保守，有些更开放；有些会给出泛泛安全提示，有些会直接拒绝；有些对中文敏感问题识别更好，有些主要对英文安全集优化。迁移后，原来的安全提示词和审核策略可能不再足够。尤其是医疗、法律、金融、未成年人和企业内部数据场景，必须重新做边界评测。
第四项成本是性能曲线。一个模型平均速度更快，不代表所有请求都更快。长上下文、复杂推理、工具调用、多轮历史、量化后解码、KV Cache 占用，都可能改变尾延迟。MoE 模型激活参数少，但总权重和多卡部署复杂；推理模型答案更准，但输出 token 变长；小模型首 token 很快，但需要更多重试。迁移前要看真实分布里的 p50、p95、p99，而不是单次样例。
第五项成本是用户体验。模型换了，回答长度、语气、结构、确认方式、追问习惯都可能变化。一个更强模型如果总是长篇解释，用户可能觉得效率下降；一个更快模型如果答案太短，用户可能觉得不专业。面向最终用户的产品要把模型迁移当成体验变更，必要时做灰度和反馈收集。
灰度发布和回滚策略
生产模型选型应该有灰度路径。第一步是离线评测，把候选模型跑过固定样本和历史失败样本。第二步是影子流量，让新模型在后台回答真实请求，但不展示给用户，只记录与当前模型的差异。第三步是小比例灰度，把低风险用户或低风险任务切过去。第四步才是扩大覆盖。每一步都要有明确通过线。
灰度指标不能只看点赞率。要看答案准确率、引用命中率、格式成功率、工具调用成功率、平均输出长度、超时率、重试率、成本、人工接管率和用户二次提问率。用户没有点踩，不代表答案正确；用户追问“你确定吗”，可能说明模型不够可信；用户复制结果后又人工修改，系统也应该尽量捕捉。
回滚要提前设计。模型版本、提示模板、工具 schema、量化格式和推理参数应当作为一组发布单元。回滚时不能只换回模型名，却保留新模板。检索增强系统还要注意 embedding 模型迁移，如果向量库是用旧 embedding 建的，切到新 embedding 查询可能效果变差。生成模型和检索模型可以分开升级，但每次升级都要记录依赖关系。
多模型系统还要避免灰度污染。假设 10% 用户切到新模型，系统记录的用户偏好、会话摘要、工具结果和缓存可能带有新模型风格。回滚时，旧模型能否继续理解这些状态，需要提前测试。尤其是长期会话产品，模型迁移不是无状态请求切换，而是会影响后续对话历史。
如何让开源模型真正成为产品资产
开源模型最大的价值，是团队可以建立自己的能力资产。你可以保留评测集，沉淀提示模板，训练专用适配器，积累错误案例，优化推理参数，控制数据流向，按任务路由模型。时间越久，这些资产越重要。只会追最新模型的团队，每次发布都重新开始；有评测和路由的团队，可以把新模型纳入体系，而不是被新模型牵着走。
第一项资产是任务数据。用户真实问题、标准答案、引用证据、失败标签、人工修正和满意度，是选型最重要的资料。没有这些数据，模型更新再快也只是看别人榜单。任务数据不一定要包含隐私原文，可以脱敏、抽象或保存结构化标签，但必须能代表真实工作。
第二项资产是模型画像。每个模型上线后，都要记录它擅长什么、不擅长什么、在哪些输入长度下出错、哪些任务需要升级、哪些提示词有效、哪些量化版本会损失质量。模型画像越清楚，路由越准确。否则多模型系统会变成一堆名字，维护者不知道该在什么时候用谁。
第三项资产是失败恢复。生产系统里模型一定会错。关键是错了以后怎么办：能否检测格式错误，能否自动重试，能否换模型，能否要求补充信息，能否转人工，能否把失败样本进入评测。模型选型的终点不是找到永不出错的模型，而是建立一个错误可见、可控、可修复的系统。
第四项资产是成本纪律。开源模型看起来便宜，但自建推理的 GPU、运维、人力、监控和故障成本都是真钱。每个模型都应该有单位任务成本，而不是只看 token 价格或显卡占用。一个 7B 模型如果需要三次重试和人工复核，可能比一个 32B 模型更贵。一个 70B 模型如果能显著减少人工处理，则可能比小模型更划算。
最终，开源模型选型不是一次性采购，而是持续运营。模型会更新，框架会更新，硬件会更新，用户需求也会变化。真正稳的团队，会把 Llama、Qwen、DeepSeek、Mistral、Gemma、Phi、GLM、Yi 这些模型都看成候选能力，而不是身份标签。谁能在某个任务上稳定创造价值，谁就进入系统；谁在评测中退化，谁就被降级或替换。
参考资料
- Meta：Introducing Llama 3.1: Our most capable models to date，https://ai.meta.com/blog/meta-llama-3-1/
- Meta：Get started with Llama，https://ai.meta.com/llama/get-started/
- Qwen Team：Qwen3: Think Deeper, Act Faster，https://qwenlm.github.io/blog/qwen3/
- Qwen3 Technical Report，https://arxiv.org/abs/2505.09388
- DeepSeek-AI：DeepSeek-R1 GitHub，https://github.com/deepseek-ai/DeepSeek-R1
- DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning，https://arxiv.org/abs/2501.12948
- Mistral AI：Models Overview，https://docs.mistral.ai/models/overview
- Mistral AI：Mistral Small 3.1，https://mistral.ai/news/mistral-small-3-1
- Google：Gemma 4: Byte for byte, the most capable open models，https://blog.google/innovation-and-ai/technology/developers-tools/gemma-4/
- Google AI for Developers：Gemma 3 model card，https://ai.google.dev/gemma/docs/core/model_card_3
- Microsoft：Phi-4 Model Card，https://huggingface.co/microsoft/phi-4
- Microsoft：Phi-4-mini-reasoning Model Card，https://huggingface.co/microsoft/Phi-4-mini-reasoning
- Z.ai：GLM-4.5 Model Card，https://huggingface.co/zai-org/GLM-4.5
- GLM-4.5: Agentic, Reasoning, and Coding Foundation Models，https://arxiv.org/abs/2508.06471
- 01.AI：Yi-1.5-34B Model Card，https://huggingface.co/01-ai/Yi-1.5-34B
- Yi: Open Foundation Models by 01.AI，https://arxiv.org/abs/2403.04652