EP219: 12 Open-source LLMs

TL;DR · AI 摘要
2026 年值得关注的 12 个开源大语言模型,涵盖性能、成本、应用场景等关键信息。
核心要点
- DeepSeek V4 以 MIT 许可证提供,支持百万级上下文窗口,性能接近前沿模型。
- Nemotron 3 Super 是 NVIDIA 推出的混合 MoE 模型,支持百万级上下文窗口,且完全开源。
- OLMo 2 是 AI2 推出的开源模型,提供完整的训练数据、代码和配方,适用于研究和开发。
结构提纲
按章节快速跳转。
- §引言
介绍 2026 年值得关注的 12 个开源大语言模型。
Meta 推出的首个原生多模态开源模型。
MIT 许可证下发布,支持百万级上下文窗口,性能接近前沿模型。
阿里巴巴的旗舰开源模型,支持切换思考和非思考模式。
Google 推出的开源模型,语言覆盖范围最广。
微软推出的紧凑模型,适合边缘设备部署。
思维导图
用一张图看清主题之间的关系。
查看大纲文本(无障碍 / 无 JS 友好)
- 2026 年值得关注的开源大语言模型
- Llama 4 Scout
- Meta 推出的首个原生多模态开源模型
- DeepSeek V4
- MIT 许可证,支持百万级上下文窗口
- Nemotron 3 Super
- NVIDIA 推出的混合 MoE 模型
金句 / Highlights
值得收藏与分享的关键句。
DeepSeek V4 以 MIT 许可证提供,支持百万级上下文窗口,性能接近前沿模型。
Nemotron 3 Super 是 NVIDIA 推出的混合 MoE 模型,支持百万级上下文窗口,且完全开源。
OLMo 2 是 AI2 推出的开源模型,提供完整的训练数据、代码和配方,适用于研究和开发。
EP219: 12 个开源大语言模型 - ByteByteGo 通讯
EP219: 12 个开源大语言模型
ByteByteGo
2026 年 6 月 20 日
你的代理仍然缺少所需的上下文(赞助)
AI 出现在 60% 的工程工作中。但其中只有大约五分之一的工作可以在不有人监督输出的情况下完成。这是因为代理缺少上下文。
这个 8 阶段的上下文成熟度模型给出了一个真实的答案,解释了为什么在耗费了大量 token 之后,你仍然会得到不一致的输出。
6 月 24 日(免费)参加 Unblocked 直播,学习以下内容:
- 为什么更多的 MCPs 为代理提供了访问权限但没有理解
- 部署可信赖的代理而不需监督需要什么
- 一个上下文层如何解决质量、效率和成本问题
立即注册
本周的系统设计回顾:
- Claude Fable 5:你需要知道的一切!(YouTube 视频)
- 12 个开源大语言模型
- SLMs 与 LLMs,清晰解释
- 单代理与多代理架构
- 每个 Claude Code 用户都应该知道的 7 种权限模式
Claude Fable 5:你需要知道的一切!
12 个开源大语言模型
2026 年值得了解的 12 个模型,每个模型都有一个突出的优势。
- Llama 4 Scout:Meta 首个原生多模态开源权重模型。
- DeepSeek V4:在 MIT 许可下发布的专家混合模型,原生支持百万 token 上下文窗口。在每 token 成本仅为前沿模型一小部分的情况下,性能接近前沿。
- Qwen3:阿里巴巴的旗舰开源权重模型,具有可切换的思考和非思考模式,均在 Apache 2.0 许可下发布。
- Gemma 4:Google 发布的开源权重系列,基于 Apache 2.0 许可,是本列表中语言覆盖范围最广的模型。
- Phi 4:微软的紧凑模型,几乎完全在合成和精选数据上训练。是边缘设备和本地部署的实用选择。
- Mistral Small 3.1:一个具有长上下文窗口的视觉语言模型,适合消费级笔记本电脑。
- Nemotron 3 Super:NVIDIA 的混合专家模型,具有百万 token 上下文窗口。完全开源权重、数据集和配方,在代理编码基准测试中表现出色。
- GLM 5.1:首个在 SWE-Bench Pro 上超越的开源权重模型。在 MIT 许可下发布,无商业限制。
- Kimi K2.6:在编码方面与领先的闭源模型竞争,但每百万 token 成本远低。在 Hugging Face 上以修改后的 MIT 许可发布。
- StarCoder2:目前最透明的代码模型之一。
- OLMo 2(AI2):本列表中最完整的开源可复现性示例。权重、训练数据、代码和完整配方均在 Apache 2.0 许可下发布。
- Falcon 3:一组轻量级开源权重模型,专为在单个 GPU 上运行而设计。
轮到你了:你会在本列表中添加哪个开源模型?
SLMs 与 LLMs 的区别,一目了然
大型模型成本更高。小型模型功能更少。以下是在生产环境中影响重要的维度上,SLMs 和 LLMs 的区别:
- 架构:SLMs 通常参数少于 10B,可以在笔记本电脑或手机上运行。LLMs 则拥有 10B 以上的参数,具有更深的层次和更多的注意力头,适用于跨任务的广泛推理。
- 任务复杂性:SLMs 在简单任务上表现良好,但在需要复杂多步骤推理的任务上会失败。LLMs 可以处理困难的数学问题、多步骤代码和长期规划。
- 长上下文回忆:SLMs 在处理长文档或长时间对话时会丢失上下文。LLMs 可以可靠地跟踪和连接大输入中的信息。
- 延迟和成本:SLMs 在消费级硬件上运行,响应时间低,推理成本显著降低。LLMs 需要 GPU,每请求的成本更高。
- 部署和隐私:SLMs 在设备上或本地运行。LLMs 通常在云端托管,增加了数据治理的复杂性。
- 适用场景:SLMs:设备上的助手、实时分类或隐私敏感型应用;LLMs:复杂推理、代理工作流或广泛知识任务。
你在生产环境中使用的是 SLMs、LLMs,还是混合设置?
单代理与多代理架构
有些任务需要一个代理。有些任务则需要一个完整的团队。了解它们之间的区别是一项关键技能。
单代理系统:一个推理 LLM,它会制定计划、选择工具,并在任务完成之前自行循环。使用单代理系统的情况包括:
- 任务是明确的、线性的序列
- 一个代理可以在其脑海中处理整个问题
- 你希望构建一个简单且易于调试的系统
多代理系统:一个协调者将任务拆分为子任务,并将每个子任务路由到一个专门的代理。使用多代理系统的情况包括:
- 子任务可以并行运行
- 一个代理编写内容,另一个代理独立验证工作
- 问题太大,一个代理无法独自协调
单代理系统更便宜且更容易构建,但它们在处理复杂任务时存在上限。
多代理系统功能更强大且更可靠,但它们增加了协调成本。
从单代理系统开始。只有在上下文或可靠性成为瓶颈时,才转向多代理系统。
轮到你了:你在生产环境中运行的是单代理系统还是多代理系统?
每个 Claude 代码用户都应该了解的 7 种权限模式
- plan:模型起草一个计划。在用户批准之前,不会执行任何操作。
- default:标准的交互式使用。大多数工具调用需要用户批准。
- acceptEdits:工作目录中的编辑会自动批准。其他 shell 命令仍会提示。
- auto:一个机器学习分类器决定那些未通过快速路径的请求。
- dontAsk:不显示任何提示。仍会执行拒绝规则。
- bypassPermissions:大多数提示被跳过。安全关键的防护措施仍然适用。
- bubble:一个子代理将其权限请求升级到父代理。
只有 5 种模式是用户可选择的。“auto” 模式受功能标志控制,“bubble” 模式是内部使用的。
轮到你了:你最常使用的是哪种模式,是什么促使你选择它?