Qwen3.8-Max 商用許可證驗收：誰要單獨授權？

最後更新於 2026 年 8 月 15 日；資料核實自官方發布文章、模型卡、權重檔案清單與 LICENSE。媒體所稱 revenue-share 只作政策背景，不代表官方已公布固定分成比例或執行細則。

先看結論：本週先做分類，不要先買長期算力

官方發布資料顯示，Qwen3.8-Max 採用約 2.4T 參數、95B active parameters 的架構，並在 2026 年 8 月 3 日宣布開放權重將於翌週釋出。這些資料只能證明模型規模與開放權重安排，不能單獨證明所有商業情境都能直接使用。(Qwen3.8-Max 官方發布文章)

我們的判斷是：普通商業使用不會因為「商用」二字自動觸發單獨授權，但企業仍須保留 LICENSE、版權聲明與署名證據；達到條款規定規模的產品，須履行介面署名義務；若業務符合 Model as a Service 或 AI Work Assistant 定義，並超過規定收入門檻，正式自託管上線前應先取得單獨授權。分類不清楚時，本週應採用「API 驗證＋許可證評審」雙軌，不要先採購長期算力再補做合規判斷。

這篇適合三類讀者：

• 企業內部部署團隊：要確認只供員工使用，是否落在內部使用豁免範圍。
• SaaS 與 AI Agent 產品團隊：要確認產品整合是否觸發署名或單獨授權。
• 模型平台、AI 編程與辦公助手團隊：要核對特定商業模式的定義與收入門檻。

本文是技術採購與上線驗收框架，不替代法律意見；最終仍應由法務依實際合約、銷售地區與產品流程確認。

先分清楚兩個交付物：託管版與開放權重版

QwenCloud 上可呼叫的 Qwen3.8-Max，與開放權重版本 Qwen3.8-2.4T-A95B，不能視為完全相同的產品。官方文章先介紹託管 API，再說明權重會於後續開放；因此，企業在驗收時必須把模型來源、能力邊界與服務條款分開記錄。(Qwen3.8-Max 官方發布文章)

我們建議至少保存以下資料：

1. 權重下載位置與提交版本。
2. LICENSE 原文與下載日期。
3. 模型卡中列明的輸入模態、上下文、推理設定及限制。
4. 託管版 API 的服務說明與帳戶條款。
5. 實際上線使用的模型識別碼與部署設定。

官方託管版模型說明列出文字輸入與文字輸出、Function Calling、結構化輸出、連網搜尋及批量推理等能力；這些是託管服務的產品說明，不應直接移植成開放權重版一定具備的功能。(Alibaba Cloud Model Studio Qwen Max 模型說明)

企業也應查閱官方模型能力總表與文字生成模型文件，確認目前使用的是哪個快照、上下文限制及可用能力，而不是只依照文章標題判斷版本。(Model Studio 支援模型與能力總表)(Model Studio 文字生成模型文件)

若團隊正在準備權重部署，可先參考我們整理的Qwen 開放權重下載與 Mac 上線前清單，但其中的硬體與啟動步驟仍要按照 Qwen3.8-2.4T-A95B 的最新模型卡重新驗證。

四種業務身份，對應四種驗收路徑

企業內部使用：看「誰能用」，不只看「部署在哪裡」

員工、受控承包商與內部系統使用，通常比公開 API 更容易落在內部使用情境；但內部部署並不等於天然安全。只要模型能力透過客戶入口、合作方帳號、外部測試平台或未受控的分享連結間接提供給第三方，原本的內部分類就可能失效。

內部團隊應核對三個限制：

• 使用者限制：是否只有公司帳號能登入，離職或合約終止後是否立即撤銷權限。
• 資料限制：客戶資料、合作方資料或外部訓練資料是否會進入同一推理環境。
• 產品化限制：現時只供員工使用的工具，日後是否會包裝成客戶可購買的功能。

建議在專案目錄保存用途說明、群組權限、登入紀錄、模型版本及 LICENSE 快照。這些材料不是為了把內部使用「包裝成合規」，而是避免半年後產品化時，團隊忘記當初的使用邊界。

普通商業產品整合：先看產品定位，再看技術架構

把模型接進客服後台、文件搜尋、報表工具或一般 SaaS，不代表一定屬於模型服務；但把模型能力做成獨立 AI 助手，也不能只因外層仍是普通軟體就排除授權限制。

我們會用以下問題區分：

• AI 是產品的附加功能，還是主要付費功能？
• 客戶購買的是整套軟體，還是模型生成、代理執行本身？
• 產品宣傳是否把 AI 助手、編程代理或自動化工作流程作為核心賣點？
• 收入是歸入普通軟體訂閱，還是按模型使用量、請求量或代理任務收費？

若產品達到 LICENSE 所列的使用者或收入規模，介面署名可能成為交付條件。工程團隊應把模型名稱、版權聲明與許可證連結保留為可配置元件，並在驗收時保存實際頁面截圖，而不是等客戶或法務指出缺漏後才臨時加上。

模型服務：API 不是分類答案，客戶控制權才是關鍵

模型平台最容易誤判的地方，是把所有 API 集成都視為同一類。實際上，自建模型 API、託管端點、請求轉發，以及單純呼叫第三方託管模型，對客戶可控制的輸入、參數、訓練資料與推理流程可能完全不同。

可先按以下方式分流：

• 自建推理服務：企業持有權重並自行管理推理伺服器，客戶透過介面取得模型能力。
• 託管端點：企業提供模型端點、微調或資料訓練功能，客戶可調整模型相關設定。
• 請求轉發：平台主要負責帳戶、計費與路由，真正推理由其他服務商完成。
• 第三方 API 整合：產品只使用外部模型回傳結果，未持有或再分發開放權重。

若客戶能實質控制輸入、模型參數、訓練資料或推理工作流程，便應認真檢查是否落入 Model as a Service。當業務同時符合 LICENSE 的收入門檻，應在商業部署前聯絡權利方取得單獨授權，而不是先把「開放權重」理解成可無條件再提供模型服務。

託管服務本身也有獨立的模型、配額與計費說明；例如官方 Model Studio 文件會按模型快照、部署範圍、輸入長度與輸出長度列示服務條件，因此不能把託管 API 的產品限制，直接當成開放權重 LICENSE 的條文。(Model Studio 模型價格與服務條件)

媒體曾報道可能存在 revenue-share 方向，但目前不能把報道改寫成已確認的固定分成制度；我們只把它列為政策風險訊號。Yahoo Finance 的相關報道可用於追蹤背景，但尚不能取代官方 LICENSE 或正式授權文件。(Yahoo Finance revenue-share 報道)

AI 編程與辦公助手：主要用途會改變驗收結果

AI 編程助手與 AI Work Assistant 需要獨立檢查，因為產品名稱不一定反映實際分類。若工具主要協助寫程式、修改專案、操作終端機、產生辦公文件或執行跨應用工作流程，便不能只說「它是一個編輯器外掛」或「它只是辦公軟體功能」。

驗收時應同時調閱：

• 產品定位文件與商業計畫。
• 主要付費功能和套餐頁面。
• 營銷頁面中對 AI 編程、辦公自動化或代理能力的描述。
• 使用者實際操作路徑。
• AI 功能收入在整體收入中的歸屬方式。

官方文件亦會把部分 Qwen 模型可使用的網路搜尋、程式碼解釋器及網頁抓取等工具分開列示，這說明工具能力與模型權重本身並不是同一個交付物。(Model Studio Harness 工具支援文件)

單一用途工具、普通軟體內的輔助功能、垂直領域助手及綜合工作助手，可能對應不同的排除情形與授權要求。這裡不能靠工程師對「產品類型」的直覺判斷，必須把功能說明與實際交互流程一起交給法務評審。

上線前的五步驗收流程

第一步：鎖定權重來源與版本

不要使用聊天群組或轉載頁面的檔案作為正式來源。從官方模型倉庫、權重檔案清單及模型卡取得版本，保存提交記錄、檔案雜湊與下載日期。官方模型卡與權重頁面若出現新提交，重新觸發評審。

第二步：建立 LICENSE 快照

把 LICENSE 原文、提交版本、核對日期與內部評審人員寫入專案紀錄。特別標出版權聲明、署名要求、規模條件、Model as a Service、AI Work Assistant 及單獨授權條款。不要只保存一張網頁截圖，因為日後需要證明評審當時依據的是哪一版文件。

第三步：用業務身份完成分類

將專案放入「內部使用、普通產品整合、模型服務、AI 編程或辦公助手」其中一類；若同時符合兩類，按限制較高的一類繼續驗收。產品團隊應提供使用者路徑、收費方式、客戶登入方式與資料流程，基礎設施團隊則提供權重位置、端點架構與存取控制。

第四步：核對第三方開放方式

檢查客戶是否能直接呼叫模型、提交微調資料、控制參數、取得中間結果或透過 API 反覆使用模型能力。只有「模型在企業內網」這個事實不足以排除外部服務情境；同樣地，只有「產品沒有直接下載權重」也不足以證明不屬於模型服務。

第五步：完成 go/no-go 決定

若分類、收入門檻或署名義務仍不清楚，正式自託管應先暫停，保留 API 驗證或隔離測試環境。只有在權重來源、LICENSE 版本、產品分類、規模條件、署名位置、第三方開放方式與單獨授權狀態均有紀錄時，才進入正式部署。

兩張表快速判斷：目前應該走哪條路

評分：哪些情況適合立即自託管

我們用五個維度作為內部決策評分，每項只評「低風險」或「高風險」，不把分數當成法律結論：

• 使用範圍：只供受控內部帳號，低風險；對外提供模型能力，高風險。
• 客戶控制權：只能使用固定功能，低風險；可控制輸入、參數或訓練資料，高風險。
• 產品定位：普通軟體的附加功能，較低；AI 編程或辦公助手是主要賣點，較高。
• 收入結構：沒有按模型能力獨立收費，較低；按請求、代理任務或模型服務收費，較高。
• 文件完整度：LICENSE 與版本證據完整，較低；只依賴新聞或口頭說法，較高。

若五項中有兩項以上屬於高風險，我們不建議直接進行長期自託管。先用 API 驗證產品需求，再把模型權重、產品流程與授權條款放在同一個評審週期內，通常比先投入硬體、後補法律判斷更容易回滾。

常見誤區：開放權重不等於條款消失

第一個誤區，是把「可下載」等同於「可自由提供模型服務」。開放權重主要解決取得與部署問題，並不會自動消除署名、版權聲明或特定商業模式限制。

第二個誤區，是把託管版能力直接套到開放權重版。託管 API 可能提供特定推理模式、輸入模態、上下文設定或服務級別；開放權重版則要依模型卡、推理框架與實際部署驗收。兩者在功能、成本、穩定性與資料路徑上都要分開記錄。

第三個誤區，是以媒體報道代替正式條款。revenue-share 報道可以提醒團隊留意政策方向，但尚不能推出固定比例、計費週期或所有產品都必須分成。只有官方 LICENSE、授權文件或正式公告，才可以作為上線條件。

若團隊需要先建立可回滾的開發環境，可參考雲端 Mac 部署 AI Agent 開發環境的配置方向，把控制端、測試端與模型推理端分開，避免許可證仍未確認時就把整個產品綁死在單一部署方案上。

FAQ：把五個長尾問題放回實際決策

以上判斷只適用於目前可取得的官方文件版本。若 LICENSE、模型卡或官方授權申請流程在權重正式上架後更新，應重新完成一次驗收，而不是沿用本次快照。

對大多數企業而言，現在最穩妥的做法不是立即否定自託管，也不是把開放權重當成無條件商用，而是先確認使用主體、產品定位、第三方控制權與收入門檻，再決定部署方式。

先解決授權分類，再決定是否長期租用算力

如果目前方案是直接使用託管 API，優點是能快速驗證產品，但會受制於供應商的服務條款、API 可用性、資料路徑與長期單價；如果改用自建伺服器，則要自行承擔模型版本更新、權限隔離、推理穩定性、硬體折舊與許可證變更。對仍在等待 Qwen3.8-Max 商用許可證結論的團隊而言，兩種方案都不適合一開始就作不可逆的長期承諾。

我們更建議把開發控制環境、API 驗證環境與正式推理環境拆開。若您只是需要臨時算力、測試 AI Agent 或在授權結論明確前保留回滾選項，可先了解 JexMac 的 Mac 租用方案，再依本文清單確認自身屬於內部使用、普通產品整合，還是需要單獨授權的模型服務場景。

常見問題