Qwen3.8-Max 商用许可证：上线前验收清单

截至 2026 年 8 月 15 日，官方核验口径已经把 Qwen3.8-2.4T-A95B 开放权重与 Qwen3.8-Max License 放在同一套商业验收框架中。我们的本周建议是：先判断业务身份，再核对内部使用、普通产品集成、Model as a Service 和 AI Work Assistant 四类条件；结论不清楚时，暂缓正式自托管上线，先用 API 验证并同步完成许可证评审。

这意味着，普通商业使用并不会因为“商用”二字自动触发单独授权，但版权声明、署名和规模门槛不能省略；如果业务符合特定模型服务或办公助手定义，并达到许可证规定的收入条件，就应在商业部署前取得单独授权。

⚠️ 本文是技术采购与上线验收框架，不替代法律意见。最终判断应以权利方当前有效的 LICENSE、提交记录和书面授权为准。

先按业务身份划分风险

这篇文章适合三类团队：企业内部部署团队，需要确认员工和受控账号使用是否属于内部使用；SaaS、AI Agent 与普通商业产品团队，需要判断是否触发署名或其他产品义务；模型平台、AI 编程和办公助手团队，则需要重点审查业务定义与收入门槛。

我们建议不要先问“这个模型能不能商用”，而是先填写下面这张分类表。相同的推理服务，放在内部系统、客户产品或模型平台中，许可证结论可能完全不同。

这里的“内部使用”不是“服务器在公司机房”的同义词。如果客户可以通过门户、合作方账号、外部接口或嵌入式功能间接获得模型能力，项目就不能只按内部部署处理。

内部部署团队的证据边界

企业内部使用通常是最容易被误判的场景。模型只服务员工，并不代表许可证文件可以不留；真正需要确认的是访问主体、系统边界和未来是否会向外部开放。

至少应保存以下材料：

• 权重下载地址、文件校验值和下载日期；
• 使用的 LICENSE 原文、版本号和仓库提交记录；
• 员工、承包商与服务账号的访问控制记录；
• 模型输出是否进入客户门户、外部报告或合作方系统；
• 项目用途说明，以及“仅供内部使用”的产品范围；
• 后续产品化时重新评审的触发条件。

Qwen3.8-2.4T-A95B 的权重来源、模型卡和许可证应分别归档，不能只保存一个模型名称。我们建议把许可证快照放进部署仓库，与启动脚本和容器版本一同冻结；这样未来更换权重或升级镜像时，能够知道当时依据的是哪一版条款。

官方 Qwen3.8-2.4T-A95B 模型卡与权重文件列表 是核对权重来源的起点，官方 LICENSE 文件 才是判断授权义务的主要依据。媒体对政策方向的描述不能替代许可证正文。

普通商业产品的集成判断

把模型接入商业产品，并不自动等于模型服务。单一用途工具、普通软件中的辅助功能和独立 AI 助手，需要按照产品定位分别判断。

例如，企业软件增加一个“自动生成摘要”按钮，与产品主要卖点就是代码生成、文档撰写或智能办公，风险分类并不相同。我们建议产品负责人提供三份材料：

1. 产品功能说明，写清 AI 功能是否属于核心付费能力；
2. 用户路径，记录用户从登录、输入到获得模型输出的完整流程；
3. 收入归属，说明收入来自软件订阅、模型调用、增值功能还是独立助手服务。

如果许可证要求达到特定用户或收入规模后在界面突出显示模型名称，团队不能等到法务询问时才补一个文字标签。署名位置应在设计稿、测试环境和正式版本中分别记录，并确认改版、白标销售及嵌入合作方页面后仍然有效。

模型服务与 Model as a Service

Model as a Service 的判断重点，不是接口名称里有没有“API”，而是客户是否实质获得了模型能力的控制权。自建模型 API、托管端点、请求转发和仅调用第三方托管模型，不能被当作同一种模式。

如果客户可以管理训练数据、调整推理参数、控制模型实例，或者将模型能力嵌入自己的开发平台，业务就更接近实质性的模型服务。达到许可证规定的连续收入门槛时，应在商业部署前联系权利方取得单独授权。

目前关于 revenue-share 的媒体报道只能作为政策背景。 Yahoo Finance 的相关报道 并不能证明官方已经公布固定分成比例或执行细则；本文不把“收入分成制度”写成已确认条款。正式评审应回到 Qwen 官方发布说明 与当前 LICENSE。

AI Work Assistant 的专项审查

AI Work Assistant 不能简单理解成“办公软件里用了 AI”。如果产品主要价值是辅助编码、写文档、处理表格、生成报告或自动执行办公流程，就需要确认它是否属于许可证列出的特定用途类别。

验收时应把以下内容放在同一份评审包中：

• 产品定位文档：AI 是附加功能还是主要功能；
• 主要付费功能：用户是否因为 AI 能力购买订阅；
• 营销页面：是否使用“智能办公”“AI 编程助手”等核心表述；
• 实际交互流程：模型是否承担主要任务，而非只提供搜索或格式转换；
• 用户规模、收入归属与客户类型；
• 是否存在企业白标、联合销售或嵌入式交付。

对于仅供内部员工使用的代码助手，重点是内部访问边界；对于向外部用户收费的综合办公助手，则应同时核对产品分类、署名义务和收入门槛。若许可证定义仍然存在解释空间，建议暂时采用托管 API 验证产品需求，把自托管权重留在隔离测试环境，不要先采购长期算力。

Qwen 托管模型说明 可用于核对托管版的输入输出模态、上下文限制和接口能力，但不能拿托管版参数替代开放权重版模型卡。托管版 Qwen3.8-Max 与开放权重 Qwen3.8-2.4T-A95B 的功能、上下文、输入模态和调用权限，应分别验收。

上线前的 go/no-go 清单

我们建议按照下面的顺序执行，不要把许可证检查放到算力采购之后。

1. 确认权重来源。 记录官方仓库、文件列表、提交记录和校验信息，拒绝使用来源不明的再打包版本。
2. 冻结许可证版本。 保存 LICENSE 原文、提交时间和内部评审人，注明后续重新核验的触发条件。
3. 确定使用主体。 写清员工、承包商、客户、合作方和外部开发者分别能否访问模型能力。
4. 划分产品形态。 判断是内部系统、普通产品集成、模型服务，还是 AI 编程与办公助手。
5. 核对规模门槛。 将用户、收入和连续经营数据交给合规负责人复核，不要用“目前规模不大”代替正式判断。
6. 确认署名位置。 在产品界面、文档、API 返回说明或客户交付材料中记录实际展示位置。
7. 核对第三方开放方式。 检查客户门户、合作方接口、白标产品和外部账号是否构成间接开放。
8. 确认授权状态。 若属于 Model as a Service 或 AI Work Assistant 且达到收入条件，应保存单独授权文件；没有授权凭证就不能把测试环境当作正式商业上线。
9. 分开验收模型能力。 开放权重版与托管版的能力边界、上下文和输入模态不得混用。
10. 设置回滚方案。 结论不明确时保留 API 路径和隔离部署，避免长期算力已经投入后才发现商业模式不符合许可证。

经验：如果产品团队无法用一段清晰文字说明“谁在使用、谁在付费、谁能控制输入和训练数据”，许可证分类通常还没有完成。此时继续扩大部署，只会增加回滚成本。

本周可执行的评审节奏

本周先完成分类，不要先做规模化部署。 第一天冻结模型来源与 LICENSE；随后由产品、基础设施和合规人员共同填写使用主体、产品定位和外部访问边界；最后把署名截图、收入归属和授权状态放进上线审批单。

权重开放后的文件提交、模型卡或 LICENSE 如果发生更新，应重新评审全文。对于尚未公布的收入分成比例、执行细则或单独授权申请流程，只能标记为待确认事项，不能把媒体报道写成企业已经接受的固定商业制度。

如果当前方案是直接采购一套长期自托管环境，常见缺点是算力先锁定、许可证结论滞后，此外还要承担模型版本冻结、访问审计、故障回滚和外部接口隔离等运维责任。对于仍在验证产品分类的团队，先使用 API 或短周期远程开发环境通常更容易保留回滚空间；需要临时算力、测试环境或云端 Mac 作为 AI Agent 开发与控制环境时，可先查看 JexMac 的云端 Mac 使用入口 和 AI 模型部署验收清单。许可证结论明确后，再决定是否转向长期自托管。

常见问题

FAQ 已覆盖“免费商用、企业内部部署、API 服务限制、AI 编程助手授权和商业产品界面署名”五类长尾意图。实际上线前，仍应以当前许可证文件和权利方书面回复为最终依据。

常见问题