10 款最佳开源 LLM（2026年11月）

最好的开源 LLM，是能够部署、评估并维护，并适用于你实际所需工作的模型。能在工作站上运行的模型，可能比得分更高但需要集群的模型更有价值。反过来，运行高要求编程智能体的组织，也可能会合理地接受高昂的基础设施成本，以换取更强的任务表现。

我们对本指南中的每个模型都进行了独立评估，考察其能力、部署实用性、许可、文档以及对其标明用途的适用性。这是一份编辑部排名，而非全新的实测基准：已公布的性能数据来自所链接的模型开发者，且不同测试框架或设置下的结果无法直接比较。实际使用的便利性占有很大权重，因此 Qwen3.8-27B、Gemma 4 和 gpt-oss 位列榜单前列。

范围：本指南涵盖开源和开放权重 LLM。可下载的权重不一定包含训练数据，也不一定赋予不受限制的使用权。每个条目都会注明其检查点或系列及许可；不要将旧版本或同一开发者开发的其他模型的许可假设套用于该模型。审阅日期：2026 年 10 月 14 日。

开源与开放权重 LLM 对比

1. Qwen3.8-27B

对于希望获得能力强、适应性好的模型，又不想一开始就转向大型 GPU 集群的开发者，我们首先推荐 Qwen3.8-27B。它将密集型语言模型与原生图像和视频理解能力结合起来，适用于编程、文档分析、研究助理，以及需要解读屏幕截图的应用。它的排名体现了能力与部署实用性之间的平衡，并不意味着它在每项基准测试中都胜出。

该模型支持可配置的思考模式，原生上下文窗口为 262,144 个 token，并可扩展至 100 万个 token。这个区别很重要：扩展上下文需要进行配置并投入额外资源，不应被视为工作站上的默认体验。对于内部文档助手，可以先采用适中的上下文长度并结合检索，再仅在更长输入能够显著改善答案时扩展上下文。

该检查点采用 Apache 2.0 许可。量化版本让本地试用更容易上手，但语言模型、视觉组件、缓存和运行环境都会占用内存。请选择明确支持该架构和多模态输入的实现；成功以纯文本模式加载，并不能证明图像、工具调用或扩展上下文也能正常运行。

查看 Qwen3.8-27B 模型卡片

2. Gemma 4

在这里，Gemma 4 系列最适合根据不同的硬件预算，为多模态应用匹配合适的模型。Google 提供多种规格，包括有效参数量较小的模型、12B 模型、26B 混合专家模型，以及 31B 稠密模型。这样一来，开发者就能根据需求，从资源受限的设备一路选择到工作站，而不必假设每位用户都能运行最大的检查点。

该系列不同型号的能力各不相同。31B 模型支持文本和图像输入，而 E2B、E4B 和 12B 还支持音频输入。较小的型号支持 128K 上下文，较大的配置则支持 256K。开发文档或语音应用时，应先根据输入要求选择具体检查点；如果最大的模型不支持所需模态，它就不一定是最合适的选择。

Gemma 4 采用 Apache 2.0 许可，但规划硬件时仍需谨慎。E2B 和 E4B 的有效参数量未计入部分大型嵌入组件，因此不能仅凭这些名称可靠估算内存需求。我们认为，该系列在部署选择方面表现突出；若读者希望在一台固定工作站上获得尽可能强的能力，应使用自己的文档和提示词，直接将合适的 Gemma 型号与 Qwen 进行比较。

查看 Gemma 4 模型卡片

3. gpt-oss

对于需要私有文本推理和支持工具的助手，OpenAI 的 gpt-oss 仍是一个实用的起点。该系列包含 20b 和 120b 两种型号，其中较小的型号面向更容易获得的硬件。它排名靠前，是因为其部署目标明确：用户可以构建本地推理系统，而不必一开始就承担万亿参数模型所需的基础设施成本。

官方发布版本对专家权重采用 MXFP4 量化。OpenAI 说明，20b 可在 16GB 内存环境中运行，120b 则可在配备 80GB GPU 的设备上运行；但这些数据不应被视为适用于所有上下文长度、运行时或同时使用人数的保证。推理力度可以调整；如果应用提供必要的执行层，模型还支持结构化输出和工具调用。

两种型号均采用 Apache 2.0 许可，并要求使用正确的 Harmony 格式。它们仅支持文本，因此处理视觉文档的工作流需要另行配置组件。对于编码助手，在授予写入权限前，应先验证工具调用参数的结构定义和错误恢复能力。选择 gpt-oss 的主要理由，是它支持可控且相对容易部署的文本推理；优先考虑原生视觉能力的用户则应从本指南中的其他模型开始。

查看 gpt-oss 模型卡片

4. DeepSeek V4

对于能够支持大规模推理、并需要广泛推理与编码能力的组织，DeepSeek V4 是一个强有力的选择。此次重要更新是正式发布的 Pro-0813 版本，它取代了此前的 Pro 预览版。评估时应明确指出这一具体检查点，而不是把所有标注为 V4 的端点都视为同一版本，尤其是在比较结果或排查智能体行为变化时。

该系列包括 Pro 和 Flash：Pro 总参数量为 1.6 万亿，每个 token 激活 490 亿；Flash 总参数量为 2840 亿，每个 token 激活 130 亿。其架构支持 100 万 token 的上下文，而正式发布的 Pro 版本还新增了推测解码模块。这些设计旨在实现大规模推理效率，但代价也相当可观；激活参数描述的是计算量，并不意味着可以免去存储其余专家权重的需求。

该版本采用 MIT 许可。我们将它排在面向工作站的领先模型之后，是因为部署复杂度大幅限制了适用人群，而不是因为较小的模型普遍胜过它。若团队要构建集中式推理服务，应根据已完成任务的成本、并发能力和工具可靠性，对 Pro 和 Flash 进行比较。若个人开发者想快速搭建本地助手，则应从本指南其他位置介绍的较小检查点入手。

查看 DeepSeek V4 模型卡片

5. GLM-5.3

GLM-5.3 是 Z.ai 面向高难度软件工程和长时间智能体任务推出的更新版开放权重模型。它沿用 GLM-5.2 的基础模型，改进则来自后训练。开发者表示，该模型在编程和智能体基准测试中的表现均有显著提升，因此评估时应关注这一版本，而不是简单沿用上一代的定位和描述。

它的优势在于能够持续处理工具、文件和中间结果。不过，模型公布的智能体得分也取决于测试框架、推理预算、上下文管理方式以及允许的运行时间。评估代码库助手时，应考察它能否完成所需修改、是否引入回归问题，以及能否正确使用工具。仅凭基准测试的亮眼成绩，无法判断它在另一种开发环境中能否取得这些成果。

许可方面的区别至关重要：GLM-5.3 使用定制许可证，并非本文此前介绍 GLM-5.2 时标注的 MIT 许可证。对于某些规模特别大的模型即服务企业，该许可证还附加了一项审查条件。此外，这个体量庞大的检查点也需要按服务器级部署进行规划。GLM-5.3 值得列入企业编程模型候选清单，但对于希望轻松在笔记本电脑上部署的读者而言，它并非理想的默认选择。

查看 GLM-5.3 模型卡

6. Kimi K3

对于需要结合视觉理解、长时间推理和工具使用的组织，Kimi K3 是一款专业之选。Moonshot 的这款模型总参数量为 2.8 万亿，每个 token 激活约 1040 亿个参数，具备原生视觉能力，上下文窗口长达 100 万个 token。当助手需要在同一系统中处理代码、屏幕截图、文档以及较长的交互历史时，这款模型便能派上用场。

集成细节尤其重要。Kimi K3 会保持思考功能启用，并要求在多轮对话中保留完整的助手消息，包括推理内容和工具调用信息。因此，如果应用只存储最终答案，就可能无法正确处理预期的对话格式。在将它与其他模型进行比较之前，请先确认服务层和智能体框架能够正确保留所需的对话历史。

其定制许可证和体量庞大的检查点，使之不仅是模型选择，也是一项基础设施决策。原生量化有助于提高服务效率，但并不会让它变成一款普通的工作站模型。对于能够通过要求较高的多模态工作流证明其运营成本合理的团队，我们推荐 Kimi K3；常规文本摘要或小型文档集通常无需如此庞大的规模。

查看 Kimi K3 模型卡

7. Mistral Small 4

Mistral Small 4 将通用指令遵循、推理、编程和图像理解能力整合在一个模型中。对于需要通过统一接口提供多种能力、而不想为每种请求分别维护专用模型的企业应用而言，这颇具吸引力。它的定位体现了这种运营层面的灵活性，尤其适合已经能够熟练管理大型推理服务的团队。

尽管名称中带有 Small，它的总参数量仍达 1190 亿，每个 token 激活 65 亿个参数。它支持 256K 上下文窗口，并可配置推理强度，让服务针对常规问题采用较短的回答，针对复杂任务则进行更深入的推理。混合专家架构减少了活跃计算量，但权重的完整规模仍是存储和内存负担的重要决定因素。

该检查点采用 Apache 2.0 许可证。官方提供的量化和推测解码选项带来了优化途径，但实际收益取决于硬件和运行时支持。对于需要读取屏幕截图并生成结构化操作的支持助手，应同时测试图像理解质量、对输出规范的遵循程度以及响应时间。如果整合多种能力能够简化运营，就可以考虑选择它；不要以为它的名称意味着它的占用规模与 8B 笔记本模型相当。

查看 Mistral Small 4 模型卡

8. Devstral Small 2

对于主要希望借助模型探索代码库、编辑文件，并在软件工程智能体中运行的开发者来说，Devstral Small 2 是一个专注于此类任务的替代选择。它拥有 240 亿参数，部署门槛比前文介绍的大型编程模型更易企及。即使较新的通用模型也值得纳入同一轮评估，它仍然是一个实用的专业模型。

Mistral 的文档说明，该模型支持 256K 上下文窗口、图像理解，并可集成到 Vibe 编程环境中。它的价值在于能否妥善完成从编辑到测试的完整工作流，而不在于能否单独生成一段令人印象深刻的代码。评估时，应使用与其他候选模型相同的工具和权限，结合代码库结构、编程语言、依赖项限制和测试套件进行测试。

该模型采用 Apache 2.0 许可。Mistral 指出，它可部署在消费级 GPU 和 32GB Mac 上，但实际能否运行还取决于精度、上下文长度和运行时开销。尝试在单个提示中处理大型代码库之前，应先从较短的会话和兼容的量化方案开始。我们认为它适合专用编程工作站；需要广泛研究、语音或通用多模态辅助功能的团队，则应将它较窄的专注范围与排名更靠前的通用模型进行比较。

查看 Devstral Small 2 模型卡

9. Nemotron 3 Nano

对于希望提升文本智能体运行效率的开发者而言，NVIDIA 的 Nemotron 3 Nano 是一个值得关注的选择。它结合了 Mamba 组件、注意力机制和混合专家层，总参数量为 300 亿，每个词元激活约 35 亿参数。评估它的理由在于其架构是否适合实际运行，而不是因为名称中有 Nano，就假设它能在任何设备上运行。

该模型可通过聊天模板支持推理和非推理模式。这样一来，应用便能针对复杂请求启用更长时间的推理，同时对简单请求争取更快响应。它的混合架构也使运行时支持成为一项关键的选择标准：应确认具体的推理引擎、量化格式和硬件组合，而不要假设所有标准的 Transformer 优化方案都适用。

该模型采用 NVIDIA Nemotron Open Model License。对于正在构建可重复的推理基准测试、且愿意调整部署方案的团队来说，它是一个值得考虑的专业候选模型。比较时，除了输出质量，还应考察得出正确答案所需的时间、内存用量和并发请求时的表现。主要想要开箱即用的视觉助手的读者，会发现本榜单前面介绍的多模态选项更适合这一目标。

查看 Nemotron 3 Nano 模型卡

10. Olmo 3.1

Ai2 的 Olmo 3.1 值得入选，因为开放性不只是提供一个下载按钮。32B Instruct 模型属于一个开放生态，其中包括训练数据集、代码、中间检查点和方法论。对于研究训练决策如何影响模型行为的研究人员而言，这些资源可能比一个开发过程基本不公开、但得分更高的模型更有价值。

该系列提供 Instruct 和 Think 两种变体，文档也介绍了预训练和后训练阶段。这让研究人员更容易探究适配方案，并比较模型开发的不同阶段。用于构建助手时，应从经过指令微调的检查点开始；基础检查点用途不同，不应把它当作已经针对对话使用优化的模型来评估。

Olmo 3.1 采用 Apache 2.0 许可，主要是一款英语文本模型。我们将它列为透明度方面的专业选择，并非声称它在前沿能力上领先。研究团队、教育工作者或研究模型适配的团队，都有充分理由选择它。寻求原生视觉能力、尽可能广泛的多语言支持，或最强开箱即用编程智能体的生产用户，则应优先评估上文介绍的其他选项。

查看 Olmo 3.1 模型卡

需要多少内存？

首先查看实际检查点的大小，以及运行时文档中列明的要求。仅估算权重占用时，可用参数数量乘以每个权重的位数，再除以 8。一个 30B 模型采用 4 位精度时，仅权重就约占 15GB，尚未计入量化元数据、未量化组件、上下文缓存、临时缓冲区和操作系统的占用。这只是算术上的下限，并不意味着它一定能在 16GB 的机器上运行。

对于混合专家模型，应使用总参数量估算权重存储空间。激活参数有助于说明每个词元所需的计算量，但这并不意味着其他专家会消失。将任务卸载到 CPU 可以降低 GPU 内存需求，但速度可能会显著下降。Mac 上的统一内存与系统共享，因此不能将其视为可全部供模型使用的内存。

• 内存受限的个人电脑：可以从较小的 Gemma 变体开始，或在受支持的配置下评估 gpt-oss-20b。预留充足的余量，并在初期使用较短的上下文。
• 内存较大的工作站：可以比较量化后的 Qwen3.8-27B、合适的 Gemma 变体和 Devstral Small 2。图像支持应与文本推理分开验证。
• 服务器和集群：当任务价值足以抵偿服务成本和运维复杂性时，可考虑 DeepSeek V4、GLM-5.3、Kimi K3，或规模更大的配置。

模型的最大上下文窗口也不代表适合日常使用。输入越长，内存和处理需求越高；并发用户越多，资源需求也会随之增加。有关安装方案，以及模型、运行时和界面之间区别的更多信息，请参阅我们的本地运行 LLM 工具指南：本地运行 LLM 的工具。

开源、开放权重与私有化部署

获取模型权重可以让你掌控推理的运行位置，但这并不会自动提供完整的训练方案，也不代表所有用途都被允许。对于采用 Apache 2.0 或 MIT 许可的条目，仍应核查具体检查点的许可条款。GLM-5.3、Kimi K3 和 Nemotron 使用各自的模型许可。如果获取开发过程的信息与获取最终权重同样重要，那么 Olmo 尤其值得关注。

只要对完整应用进行相应配置，自行托管就能让提示词留在你的基础设施内。但云端嵌入、远程搜索、日志服务和智能体工具仍可能将数据发送到其他地方。评估完整工作流，并同时衡量错误回答和操作失败情况，以及延迟。对于会修改文件或与业务系统交互的工具，应采用权限限制；在操作性质需要时，还应设置审批环节。

该选择哪款开放式 LLM？

若要进行实用的初步比较，可以从适用于通用多模态应用的 Qwen3.8-27B、提供多种本地模型尺寸选择的 Gemma 4，以及便于使用、具备文本推理能力的 gpt-oss 入手。在决定搭建核心推理集群之前，这些模型都能作为不错的起点。

对于要求较高的服务器级任务，可以比较擅长广泛推理和编码的 DeepSeek V4、适用于长时间运行软件智能体的 GLM-5.3，以及面向多模态工作流的 Kimi K3。如果需要单个模型处理多种业务任务，并能灵活配置推理能力，那么值得评估 Mistral Small 4。

几款专用模型各有侧重：Devstral Small 2 适用于专注编码的工作站，Nemotron 3 Nano 适用于注重效率的文本智能体，Olmo 3.1 则适合透明化研究和模型调整。选择两到三款符合硬件和许可要求的模型，再用同一组有代表性的任务对它们进行评估，然后确定部署方案。