打算把 Qwen 接进产品，或者拉到本地自己跑，最容易忽略的不是效果好不好，而是「这么用允不允许」。许可条款怎么读、内容filter能关到什么程度、自部署之后还有哪些调用侧限制，散在各种文档里。这篇不讲跑分，只给你一条上线前的核对路径，加上什么情况下这些判断会失效。
打算把 Qwen 接进产品，或者拉到本地自己跑，最容易忽略的不是效果好不好，而是「这么用允不允许」。很多人先跑通 demo，再谈上线，结果卡在许可那一关，返工成本很高。这篇不讲能力对比，只给你一条上线前的核对路径，把许可、内容、调用三块容易踩的地方按顺序过一遍。
需要提前说清楚的是：下面这些判断标准会随协议版本和平台策略变化。你看到的任何一条，都要回到站内对应页面去核对当时的口径，别拿别人转述的结论当依据。
先分清三种「能用」，许可边界在前
多数人把「能下载权重」「能商用」「能改完再闭源卖」当成一件事，其实这是三件独立的事，而且卡人的往往是第二件。先把你手上的用途归类，再看协议，效率高很多。
| 使用形态 | 要重点确认什么 | 容易忽略的点 |
|---|---|---|
| 内部自用、不对外 | 是否需要保留署名与协议副本 | 内部系统也可能被审计，别默认无义务 |
| 交给单一客户的项目 | 商用是否需申请、交付物里模型算谁的 | 客户拿去二次分发，责任仍可能回到你 |
| 做成 SaaS 对外卖 | 是否按用户量或营收设门槛 | 门槛以哪一方口径算，要写进合同 |
不同参数规格、不同发布渠道拿到的协议可能不是同一份。你从官网下的、从某个镜像拿的、或者通过云厂商调用的，对应的条款未必一致。先确认你手上这份到底对应哪一版，命名后缀和版本关系可以到站内页面 /models 与 /ai-dict 对照着看。
- 商用是否需要单独申请，还是随协议默认允许
- 是否要求保留署名、附带协议副本，放到哪里算合规
- 衍生模型（微调、蒸馏、二次训练）是否必须沿用同一协议
- 有没有按用户量、营收或调用量设置的门槛，以谁的口径算
- 协议是否允许你修改后再闭源分发，修改后的行为责任归谁
内容层面的限制：不是关个开关就没了
线上 API 有输入输出审查，这个大家都知道；但自部署的权重里也带着对齐后的倾向，本地部署不等于「随便说」，只是少了平台那一层拦截。拒答、回避、话术变形这些现象，换了部署方式依然会碰到。
如果业务涉及医疗、金融、法律建议这类高风险场景，输出必须安排人工复核环节。模型自己附带的免责声明，不构成你的免责——出事时责任在提供方，不在模型。
- 高风险输出场景：先列清单，标出必须人工过一遍的节点
- 多模态边界：图里的小字、密排长表格、方言语音，先测清楚识别率再决定是否上线
- 想「去掉限制」的做法：往往同时降低指令跟随和拒答判定的准确性，还会牵扯修改后行为的责任归属，参考 /safety 的口径再决定
- 兜底话术：模型答不了或答偏时，产品该说什么，提前写死在流程里
一个判断顺序
- 列场景把会用模型处理的任务按风险从高到低排一遍，高风险放最前面。
- 测边界每个高风险场景准备一批边界输入，看模型是拒答、胡答还是答对，记下来。
- 定复核点对拒答和胡答比例高的场景，加人工复核或改成规则处理。
- 写兜底给无法覆盖的情况准备统一话术，别让用户看到裸的模型输出。
落地时真正会硌人的调用侧限制
许可证和内容之外，真正在联调阶段把人拖住的是调用侧的限制。这些限制分官方接口和自建推理两套口径，混着看容易得出错误结论。
上下文长度和输出长度是分开算的，长文档塞得进去不代表答得完整。分块策略和上下文设置可以参照 /ai-dict/category/basics，部署相关的参数口径看 /models/deploy。
| 限制项 | 官方接口侧重看什么 | 自建推理侧重看什么 |
|---|---|---|
| 并发与限流 | 账号级限额、突发额度怎么算 | 显存与吞吐撑得住多少并发 |
| 超时与重试 | 网关超时、重试是否计费 | 推理队列积压后的降级策略 |
| 上下文与输出 | 请求上限与输出上限分别多少 | KV 缓存对可用长度的挤压 |
| 量化档位 | 一般不涉及 | 掉精度后拒答和话术是否变形 |
- 先量基线：单请求延迟、稳定并发数，拿一周真实流量跑，别用压测峰值当常态
- 量化影响：降档之后，原本能过的合规话术可能变形，量化取舍看 /ai-dict/category/tech
- 版本更新：协议和限制可能跟着模型更新变，上线前留一次复核动作
- 价格与规格：随时会动，到 /official-api/providers/alibaba 看当时的说法，别用旧截图
上线前照着走一遍的核对清单
- 第一步 定用途内部自用 / 交付客户 / 对外卖服务，三选一。这一步决定了后面所有条目，别跳。
- 第二步 对协议找到你实际下载那一份的原文，逐条比对商用、署名、衍生、门槛四项，存一份带日期的快照，方便日后对比。
- 第三步 列禁区把高风险输出场景写出来，每个标上人工复核点和兜底话术。
- 第四步 做技术核对上下文、输出上限、并发限制各测一遍，把数字填进容量表；价格与规格类数字到 /official-api/providers/alibaba 核对当时的说法。
- 第五步 留退路如果协议或限制变了，换规格或换供应商要多久，提前想清楚并写下切换步骤。
提醒一句：这套清单在「模型和平台策略都比较稳定」的前提下成立。如果你接的是刚发布的新规格，或者平台正在调整条款，那第二、第四步要更频繁地重做。选供应商时也可以顺手看一眼可信度和速度评测，/rankings 和 /tools/speed-test 里有可对照的维度。
先把「允不允许」问清楚，再谈「效果好不好」，顺序反了就要返工。下一步把你现在的用途和协议逐条对一遍，顺便看看同类中转在合规口径上怎么做，心里有底再上线。→
常见问题
Qwen 能免费商用吗？
不能一句话回答。要看具体是哪一份协议、哪个规格、从哪个渠道拿的，有的允许商用但要求署名和协议继承，有的对规模和用途设了门槛。做法是找到你实际下载页面附的那份原文，逐条核对商用条款，别用别人博客里的结论代替原文。
本地部署后是不是就没有内容限制了？
不是。少了平台侧的输入输出拦截，但权重本身带着对齐倾向，敏感话题依然会拒答或绕开。而且你要自己承担内容责任：医疗、法律、金融这类输出必须加人工复核。真去改权重来放开限制，通常会牺牲指令跟随质量，也可能触碰协议里的修改条款。
自部署和调 API 的限制差别大吗？
差别主要在谁拦、谁负责。API 侧有平台审查和限流，你要遵守平台条款；自部署侧条款换成模型协议，技术限制换成显存、上下文和量化的取舍。两边都要确认的是：用途是否被允许、输出出问题谁兜。合规与风险的通用口径可以先看站内 /safety。
