Qwen3.8 許可證商用前驗收清單
下載頁面已經出現，法務卻找不到與權重完全對應的 LICENSE；最快解法是：截至 2026 年 8 月 12 日，暫緩正式商用與對外托管，只保留隔離 PoC 和可回滾的雙軌整合。
只有最終許可證、具體模型倉庫與版本標識完全對應，並且地域限制、revenue-share、再分發及衍生模型條款都完成書面核對，Qwen3.8 才能進入正式放行階段。
這篇適合準備把 Qwen3.8 接入收費產品、企業內部系統或 AI Agent 的技術負責人。
同樣適合提供模型 API、托管推理服務，以及負責採購、法務和資安驗收的人員。
先記住一個門檻： open weights 不等於開放原始碼，也不等於無地域限制或無條件商用。官方 Qwen3 系列過往曾說明，模型權重要以各模型倉庫附帶的許可文件為準；程式碼、權重和線上服務條款不能混為一談。可先參考官方 Qwen GitHub 的許可說明及官方 Qwen3 模型庫說明。
先分清楚：公告、權重與服務不是同一份權利
目前可確認的是，官方曾預告 Qwen3.8-Max 開放權重，並將 Qwen3.8-27B 列入開放計劃。Qwen3.8-Max 的公開介紹涉及 2.4T 參數；Qwen3.8-27B 則是另一個模型身份，不能因為同屬 Qwen3.8 系列，就直接套用同一份條款。相關發布資訊可見媒體整理的官方公告內容。
截至本文更新日，在官方 GitHub 組織及可核驗的模型頁面中，仍未能把一份 Qwen3.8 最終許可證與具體權重版本完整配對。這不代表未來一定沒有商用權利，只代表目前不能用「已經開放權重」替代正式驗收。
技術團隊應建立三個獨立欄位：
- 模型權重：下載、部署、複製、微調、蒸餾及再分發受哪份文件約束。
- 推理程式碼：官方 GitHub 上的範例、部署工具、函式庫及修改義務受哪份許可證約束。
- 線上服務：若使用 Qwen 的 API、工作台或托管端點，則要另外查看服務條款、帳戶限制、輸出權利和轉售限制。
驗收紀錄至少應保存以下項目：
- 許可證原始網址。
- 文件發布日期及頁面標題。
- 模型完整名稱，例如 Qwen3.8-Max 或 Qwen3.8-27B。
- 權重倉庫的提交識別碼、標籤或下載時間。
- LICENSE、模型卡及使用政策的快照或雜湊值。
- 審核者、審核日期、未決問題及責任人。
這一步的隱性成本不在下載本身，而在日後無法證明「當時究竟根據哪一版條款放行」。許可文件可能更新，模型倉庫也可能更換模型卡。沒有快照，就很難重現採購、法務或資安當時的決策依據。
地域限制要拆成五條部署鏈路
媒體和社群曾提到美國、歐盟、英國及韓國可能受到限制，但這些說法目前仍屬未獲最終許可證確認的資訊。Byteiota 的先行整理明確指出，相關內容源自草案解讀，Alibaba 尚未發布可作最終依據的許可證；Latent Space 的分析也把這場爭議列為未解決的許可問題。
審核時不要只問「公司在哪裡」。至少要分開記錄：
- 下載地點：權重由哪個國家或地區的帳戶取得。
- 部署地點：模型實際載入哪個雲端或本地伺服器。
- 公司註冊地：簽約、營運或控制模型的主體在哪裡成立。
- 最終使用者所在地：客戶、代理操作人或資料提供者身處何地。
- 資料流經地區：提示內容、工具輸出、日誌及備份是否跨境。
例如，香港公司從日本環境下載權重，再由美國伺服器提供 API，客戶位於歐盟。這不是一個「香港能不能用」的單一問題，而是至少五個適用範圍同時出現。若服務還有海外銷售代理，則要把交付和轉售鏈路一併畫入審核圖。
經驗提醒： 地理條款若使用「不得下載」、「不得使用」、「不得提供服務」等不同動詞，風險完全不同。不要把下載限制自行解讀成部署限制，也不要把部署限制縮小成最終客戶限制。
revenue-share 不要先填比例，要先填義務
目前流傳的 revenue-share 說法，應只用來設計核對表，不能用來直接下結論。相關報導整理提到，大型商業使用者可能需要分享由模型產生的部分收入，但具體比例、門檻及最終條款仍不能在正式 LICENSE 出現前視為確定。
產品團隊應把商業模式拆成六類：
- 企業內部提效，不直接向外收費。
- 把模型嵌入收費軟體或 SaaS。
- 按 API 調用量、席位或任務收費。
- 以廣告、交易佣金或導流方式間接變現。
- 由平台代為托管模型並收取服務費。
- 將模型能力包裝成白標服務或渠道方案。
若最終許可證出現 revenue-share，至少要抽取以下欄位：
| 驗收指標 | 必須確認的內容 | 未確認時的處理 |
|---|---|---|
| 適用主體 | 公司規模、關聯企業、平台商或個別開發者 | 暫列高風險，不作商用放行 |
| 收入定義 | 模型直接收入、整體產品收入或毛利 | 要求文字定義及例子 |
| 觸發門檻 | 年收入、客戶數、調用量或其他條件 | 不自行推算或套用其他模型 |
| 計算週期 | 月度、季度、年度及追溯期間 | 交由財務與法務確認 |
| 報送義務 | 報表格式、申報時間、付款方式 | 未具備流程則暫緩 |
| 審計權 | 查核範圍、通知期、資料保存期限 | 納入合約和系統留檔要求 |
提供托管 API 的團隊尤其要小心。即使客戶看不到權重，平台仍可能被視為商業托管、模型服務提供者或再分發鏈路中的一方。這不是單靠技術架構就能排除的問題，必須回到許可證對「分發」、「提供服務」及「商業使用」的定義。
再分發與衍生模型要按使用形態驗收
「只調用模型」和「交付模型能力」不是同一種風險。建議用下列順序逐項判斷：
- 本地調用：團隊只在內部環境載入權重，不向外部提供模型存取。
- 遠端推理：客戶透過 API 傳入提示並取得輸出。
- 托管服務：平台持有權重，按月、按量或按任務向客戶收費。
- 交付權重：把原始權重、量化檔或容器映像交給客戶。
- 微調版本：在 Qwen3.8 基礎上加入企業資料或 LoRA 適配器。
- 蒸餾版本：用 Qwen3.8 產生資料或教師訊號，再訓練另一個模型。
每一類都要核對是否必須附帶許可證、保留署名、披露修改、傳遞使用限制，或取得額外商業授權。DeepSeek、Llama 等其他模型的公開許可證可以用作檢查維度參考，但不能把它們的商用權利直接套用到 Qwen3.8。
特別要避免兩個常見誤區：
- 「輸出歸客戶，所以模型可以隨意提供」：輸出權利和模型服務權利可能是兩份不同問題。
- 「微調只增加一個適配器，所以不算衍生模型」：是否屬於衍生物，要看最終許可證的文字、技術實作及交付方式。
FAQ：正式許可證前，哪些工作可以先做
Qwen3.8 可以直接用於商業產品嗎？
截至 2026 年 8 月 12 日，不應把 Qwen3.8 視為已完成商用許可驗收。正式產品、對外托管和收費 API 應暫緩。若只是驗證介面、工具調用、代理流程或輸出品質，可以使用隔離環境，但不能把 PoC 的通行當成正式商用許可。
Qwen3.8 是否限制美國、歐盟或其他地區使用？
目前傳出的地域名單並未獲最終許可證確認。審核人員要分別檢查下載、部署、公司註冊、客戶所在地及資料流經地區。跨國團隊必須把每個環節列入部署圖，最後只引用正式 LICENSE、使用政策或官方澄清。
Qwen3.8 revenue-share 對哪些商業用戶生效？
現在不能確認適用對象、收入門檻或分成比例。平台型公司、托管推理服務、按調用收費產品及白標 API 都應列入優先澄清範圍。若條款缺少收入定義、計算週期、申報和審計方式，工程團隊不應自行補完。
提供 Qwen3.8 托管 API 是否屬於模型再分發？
不能一概而論。托管 API 沒有交付權重，但仍可能涉及提供模型服務、商業托管或再分發義務。驗收時要把權重是否交付、端點是否白標、客戶是否可轉售、收入如何計算等事項分開記錄，並要求正式條款針對服務形態作解釋。
最終許可證發布前能否先做 AI Agent 整合測試？
可以採用隔離 PoC，但要限制權限、資料和對外入口。測試環境應能切換至替代模型，並保留工作流回歸、工具調用、提示版本及回滾紀錄。若需要建立這類環境，可先閱讀ProxyMac 的技術支援說明，把測試和正式部署分開管理。
上線前用三檔條件決定放行或回退
這份清單不應最後只留下「允許商用」四個字。較可執行的做法，是把未決問題、責任人、截止時間和替代路線一起寫入決策單。
若滿足以下條件，選擇「放行」
- 最終 LICENSE 與具體 Qwen3.8 權重倉庫、模型名稱和版本完全對應。
- 已完成下載地點、部署地點、主體所在地、客戶所在地及資料流經地區核對。
- 商業使用、托管 API、按調用收費和白標服務的適用性已有書面結論。
- revenue-share 的主體、收入定義、門檻、週期、報送和審計義務均已明確。
- 再分發、微調、蒸餾、署名和 NOTICE 要求可以轉換成工程動作。
- 基礎設施、客戶條款和營運流程已能執行地域控制及版本鎖定。
若有任何一項未完成，選擇「暫緩正式商用」
- 找不到與權重版本對應的最終許可證。
- 地域限制只存在於草案、社群貼文或媒體轉述。
- revenue-share 只有「大型商業用戶」等模糊描述。
- 托管服務是否屬於再分發尚未獲得書面說明。
- 微調或蒸餾後的模型權利沒有清晰處理。
- 系統沒有能力阻止受限制地區存取或下載。
若只需驗證效果，選擇「隔離 PoC＋雙軌方案」
- Qwen3.8 只進入非生產環境。
- API 介面使用可替換的模型適配層。
- 不向客戶交付權重或公開收費端點。
- 不把不可逆的伺服器採購、長期合約和地域部署鎖定在單一模型。
- 同步測試一個已完成許可驗收的替代模型。
- 設定許可證發布後的重新驗收觸發點。
這種雙軌方式的好處，不是繞過許可證，而是把技術整合和商業放行拆開。AI Agent 的工具調用、狀態管理、權限控管和回歸測試可以先完成；真正需要等待的，是模型權重及商業條款的法律確認。
上線後仍要持續留檔與監測
許可證驗收不是一次性的 PDF 閱讀工作。產品、法務、基礎設施和營運應各自負責一部分證據：
- 法務：保存原文、版本差異、地域解釋及未決問題。
- 產品：記錄模型用途、收費方式、客戶類型及白標安排。
- 基礎設施：鎖定權重版本，記錄部署地區、下載權限、容器映像和回滾點。
- 營運：保存客戶通知、NOTICE 展示、下游使用限制及事件處理紀錄。
模型更換、部署地域變更、收入模式變更、引入微調權重，或把內部工具改成對外 API 時，都應重新驗收。若 Qwen 官方發布最終 LICENSE、模型卡、服務條款或官方澄清，也應立即重新比對。
目前直接把 Qwen3.8 接入正式服務，最大的問題不是模型能不能跑，而是條款不清會讓後續的客戶合約、地域控制和收入申報全部失去依據。相較之下，Windows 或 Linux 上自行堆疊長期伺服器環境，還會增加硬體折舊、驅動相容、權限分散和回滾困難等成本；若只是短期驗證，先使用可撤換的 Mac 測試環境，通常比鎖定一套尚未完成許可驗收的長期基礎設施更容易控制風險。若團隊需要臨時算力、隔離測試或快速切換工作環境，可再查看ProxyMac 的方案資訊，先完成 AI Agent 回歸測試和替代模型驗證，等正式許可證確認後再決定是否擴大部署。
