2026年的开放AI模型：DeepSeek、Qwen与Kimi详解

“开放AI模型”是什么意思？

“开放”是一组描述的统称，而不是一项保证。开放权重的发布会分享模型最终训练好的参数，在许可证允许的情况下，其他人可以对其进行微调、适配或部署。^[4] 开源AI系统则是一种更强的主张。开放源代码促进会（Open Source Initiative，OSI）的定义要求在OSI认可的条款下具备三项要素：足够详细、能让熟练人员构建出实质等效系统的数据信息，用于训练和运行该系统的完整源代码，以及模型参数。^[1]

这一区别会影响实际的选择。权重可能可以获取，而训练数据和训练代码却无法获取。开放源代码促进会关于开放权重的说明文章指出，开放权重之所以不同于开源AI，是因为它不包含训练代码或训练数据集，在数据集依法不能分享的情况下也不包含关于该数据集的全面细节；缺少这些，训练过程就难以复现或审计。^[4] 因此，一个模型可能可以在本地部署却无法完全复现，或者其权重虽然可以获取，所附条款却限制了某些用途。

在选择某个发布版本之前，先问四个问题：能否拿到确切的权重？适用哪种许可证？哪种运行时和硬件能够加载所选的格式？对于自己关心的任务，有哪些证据？“开源”不是性能等级，不是隐私保证，也不是模型能装进笔记本电脑的承诺。

下文在证据只涉及权重时使用“开放权重”一词，而把“开源AI”留给更强的系统层面的含义。这样可以避免把一个有用的技术区分变成营销口号。

关于DeepSeek V4，哪些信息已经得到确认？

DeepSeek的透明度中心（Transparency Center）列出了DeepSeek-V4，发布日期为2026年4月24日，并链接到一份模型卡和一份技术报告。^[2] 其官方更新日志称，API自2026年4月24日起支持V4-Pro和V4-Flash。2026年9月10日的条目称，V4 Flash已经停用，其API名称被暂时路由到V4.1 Flash；而截至2026年11月11日的最新条目日期为2026年10月17日，该条目把这一模型升级为V4.1-Flash-1017。^[6] 这些表述确认的是模型家族的发布和API的演变；它们并不意味着每个V4变体都有相同的权重、许可证、价格或本地部署要求。

DeepSeek在2026年4月24日的公告中称V4 Preview“已开源”，链接到其在Hugging Face上的开放权重，并介绍V4-Pro的总参数为1.6T、激活参数为49B，V4-Flash的总参数为284B、激活参数为13B。^[7] “已开源”是该公司自己的措辞；某个V4发布版本是否符合OSI的定义，取决于其代码仓库和许可证实际提供了什么。这些规模很重要：一个模型处理每个token时的激活参数可以少于总参数，但仍然需要相当可观的基础设施和模型文件。不要由此推断，一个通过API提供的模型可以在个人电脑上轻松运行。

对开发者来说，要把API模型名称与下载下来的检查点区分开。DeepSeek的文档解释了API名称和兼容性路由；而要确认一次重大发布并找到它的模型卡，透明度中心才是合适的地方。^[2][6] 做本地部署时，应依据具体的模型卡、权重来源、许可证和受支持的运行时，而不是根据API名称去猜。

对普通读者来说，把DeepSeek理解为一个家族是有帮助的：在相近的名称之下，可能有大型的、托管的和适合本地使用的不同选项。实际要选择的是确切的发布版本和交付方式，而不是对某个品牌标签的忠诚。

Qwen3.8与Kimi K3.1 Pro有何不同？

Qwen3.8-27B是一个视觉语言模型，其官方模型卡列出27B语言模型参数和Apache 2.0许可证；Hugging Face为该代码仓库给出的文件摘要显示的模型规模为28B参数。模型卡称，该仓库包含后训练模型的Transformers格式权重和配置文件，Hugging Face页面则链接到面向llama.cpp、Ollama、LM Studio或任何兼容应用的量化版本。^[3] 这些量化版本存放在各自独立的仓库中，因此要逐一核对每个版本是谁发布的。只有当所选的量化方式、上下文和硬件相互匹配时，它才算得上一个可行的本地模型候选。

Kimi K3.1 Pro在规模和许可证方面的情况有所不同。其发布方的模型卡称它是一个开放权重的多模态混合专家模型，列出总参数2.8T、激活参数104B，并指明采用Kimi专属的许可证。^[5] 它在技术上可以获取，但这并不代表它是普通硬件上合适的本地选择，也不代表它的授权方式与采用Apache许可证的模型相同。

这两个发布版本说明了为什么仅凭参数数量无法回答“哪个更好”。Qwen的27B规模配合合适的量化方式，可能更容易在本地测试。Kimi大得多的规模，面向的可能是内存和部署容量都大得多的基础设施。正确的比较维度是任务、输出质量、延迟、成本、许可证和硬件，而不是声称某个家族在每项基准测试中都胜出。

两份模型卡都是发布方提供的信息。其中的基准测试结论和能力描述应被当作评估的起点，而不能替代对有代表性的提示词、语言和失败案例的测试。对于后果重大的用途，应保留人工审核环节和独立的信息来源核查流程。

哪种开放模型适合做什么？

如果是为了学习本地部署，就选择能够胜任所需语言和任务的、受支持的最小模型，然后进行测试。一个体量可控、与Qwen兼容的量化版本，作为第一次实验可能比一个大得多的发布版本更切合实际。Hugging Face的文档介绍了GGUF、MLX等格式对应的本地应用途径，包括LM Studio、Ollama、llama.cpp和MLX LM。^[8]

对于托管式工作流程，API可以减轻下载权重、选择运行时和维护硬件的负担。这是一种服务选择，而不是本地隐私方面的选择。DeepSeek的API文档显示了模型名称的变更和API的发布情况；用户在发送敏感材料之前，应查看当前的服务条款、定价和数据处理方式。^[6]

对于研究团队或基础设施团队，超大型的开放权重发布可以支持受控的自托管、专门的评估或适配。它们也会增加运维工作：获取权重、管理推理容量、应用安全更新、遵守许可证以及监控输出质量。Kimi K3.1 Pro的规模说明，权重可以获取并不能消除这些成本。^[5]

对于多模态工作，要核对确切的模型卡，而不是假定每个模型都能接受图像、视频或文档。Qwen把Qwen3.8-27B描述为视觉语言模型，而Kimi的模型卡描述的是文本和图像模态。^[3][5] 这本身并不能说明它在某一张具体图像或某一份具体文档上的准确性，在敏感领域尤其如此。

对于隐私敏感的工作，本地运行可以减少与托管服务提供方共享提示词，但这并不自动等于隐私。模型下载、更新、本地日志、备份、插件和暴露在网络上的服务器仍然是各自独立的风险。关于硬件和隐私方面的完整取舍，请参阅本站的本地AI指南。

应当如何评估一个开放权重模型？

先读模型卡。确认发布方、模型修订版本、许可证、预期任务、架构、模态、已知局限和受支持的部署格式。模型卡不是对准确性的认证，但它是了解发布方所称发布内容的最直接来源。^[2][3][5]

然后选定一套贴近实际的测试集。使用一小组有代表性的提示词，其中包含已知的预期事实、棘手的边缘情况和打算使用的语言。从正确性、完整性、一致性和有害的过度自信这几个方面比较输出。不要仅凭一个漂亮的首次回答或单独一项公开基准测试来评判模型。

记录确切的环境：模型修订版本、量化方式、上下文上限、运行时、硬件、提示方式和工具访问权限。当这些变量不同时，两位用户用同一个名称的模型也可能得到不同的结果。这份记录还让人能够复现一套好用的配置，或者追查一个糟糕的回答。

在把模型部署到个人实验之外的场合之前，先核对许可证。OSI的定义说明，开源AI涉及的不只是权重；OSI关于开放权重的说明文章则指出，仅有权重还达不到充分使用、研究、修改和分享一个系统所需的条件。^[1][4] 商业使用、再分发、微调、作为托管服务使用以及署名，可能分别受不同条款的约束。

最后，为输出划定边界。开放模型可以起草、翻译、分类或帮助探索信息。在没有独立的最新证据和适当的专业判断的情况下，它不应成为法律、财务、医疗、安全或安防决策的最终依据。

如何在本地运行开放模型而不至于一头雾水？

在下载模型文件之前先选定运行时。Hugging Face列出了兼容的本地应用和格式：例如，LM Studio支持GGUF和MLX模型，Ollama支持GGUF，MLX LM支持MLX文本生成模型。^[8] 格式不对的模型文件，下载了也没有用。

从发布方的官方页面或成熟的模型托管平台入手，然后选择一种适合自己电脑的格式。Qwen3.8-27B的Hugging Face页面链接到了量化版本，而27B的基础发布本身并不表示每台设备都能加载每个版本。^[3] 要为操作系统和上下文留出内存余量，而不是把模型在磁盘上的大小当作全部需求。

让第一台服务器只在同一台电脑上本地运行，并用无害的数据进行测试。不要仅仅为了从另一台设备上使用，就把本地模型端点暴露到公共互联网上。如果日后确实需要网络服务，就要启用身份验证，为运行时打补丁，并弄清楚谁能向它发送提示词。

用版本控制管理配置，并保留一份模型许可证的记录。一个本地模型可能在技术上很容易运行，却在法律上不适合计划中的服务，反之亦然。一次有条理的实验，比反复下载来源不明的巨大文件更安全，也更有用。

当模型回答得不好时，一次只改变一个变量：更小的上下文、另一种量化方式、另一种运行时，或者一个与任务更契合的模型。更大的参数数量并不是唯一的解决办法。

2026年，读者应当关注开放模型的哪些方面？

要仔细留意发布版本的确切身份。DeepSeek的官方页面区分了V4、V4-Pro、V4-Flash以及V4.1-Flash的API变更。^[2][6] 一条写着“DeepSeek V4”的新闻标题，所指的确切模型或交付途径可能与读者打算使用的并不相同。

要像关注能力一样密切关注许可证和部署细节。Qwen3.8-27B的公开页面标明采用Apache 2.0，而Kimi K3.1 Pro标明采用Kimi专属的许可证。^[3][5] 这些标签应当到实际的代码仓库中去核读，因为基础模型、社区量化版本和衍生版本可能有不同的文档。

要关注与任务相匹配的证据。一项编程基准测试并不能说明文档理解能力，一项长上下文的宣称并不能说明事实准确性，模型支持图像也并不能说明它处理图像的可靠性。开放发布让测试和适配更容易，但并没有免除评估的必要。

除了发布说明，还要关注运维层面的变化。正如DeepSeek的V4更新日志所示，托管API可能会对端点进行重命名、重定向或停用。^[6] 依赖API的团队应在投入生产之前测试任何替代方案，并保留一套后备流程。自托管的团队则必须为下载完整性、运行时升级、存储和容量做好规划。两条路线都不可能永远免于维护。在上线之前，要规划好回滚方案，为监控留出预算，并写明每项运维职责由谁负责。

保存一份证据档案，其中包括模型卡的修订版本、查阅过的许可证文本、运行时版本、评估用的提示词以及观察到的失败模式。这对个人项目来说工作量不大，对组织使用来说则必不可少。它能把一个关于开放发布的诱人说法，变成一项可重复的决策。它还有助于分清问题究竟是模型本身的局限，还是量化方式、提示词设计或本地配置上的失误。

长远来看，真正要做的选择并不是抽象意义上的DeepSeek、Qwen和Kimi孰优孰劣，而是在用户有能力维护的部署方式下，能够满足任务要求的那个最小、许可证最清晰、能力可验证的确切模型。