Qwen3.8-27B 文字+影片即將登陸 CPU：SGLang 的 torchcodec PR 帶來哪些變更？

目前 SGLang 中有一份草稿 pull request，標題為 “[CPU] Support Qw​en3.8 text+video: adding torchcodec, ffmpeg and removing pin_memory。” 把這些底層細節剝掉之後，它讀起來就像一份路線圖： Qwen3.8-27B — 阿里巴巴的 Apache-2.0 授權、27B 參數的視覺語言模型，五天前開源 — 正在被接入，使其 text+video 模式可以在沒有 GPU 的硬體上執行。這是第一個明確訊號，顯示這個多模態 27B 模型正在獲得一條真正可用的 CPU 推論路徑，而且是落在團隊實際部署的推論執行環境之一；對於所有一直等著想在本機執行影片理解、又不想買 48GB 顯卡的人來說，這很重要。

那個 PR 中的內容都還沒有合併——它仍是草稿、CI 顯示紅燈，版本鎖定也還在變動。但正是如此，它才值得仔細閱讀。它背後的模型是真實且已發布的，服務生態系在 GPU 上早已跟上進度，而這個 PR 展示了無 GPU 路徑的未來走向。以下說明這個變更實際上做了什麼、為何 27B 模型的 CPU 影片推論比聽起來更重大、關於 Qwen3.8-27B 已確認的資訊，以及你今天可以在哪裡呼叫它。

用一段話說明模型

Qwen3.8-27B 是 Qwen 3.8 世代中開放權重的 27B 模型：一個稠密的約 27.8B 參數視覺語言模型（64 層，隱藏層大小 5,120），配備專用視覺塔（vision tower），於北京時間 2026 年 8 月 14 日晚間在 Hugging Face 與 ModelScope 上以 Apache 2.0 授權釋出。它接受文字、圖片與影片輸入，並回傳文字——原生支援，而非透過外掛的轉接器（adapter）——原生上下文視窗為 262,144 個 token，可透過 YaRN 擴展至約一百萬個。其授權為寬鬆型：允許商業使用、微調與再散布，沒有營收門檻，也無需另行簽訂商業協議，這與旗艦檢查點（checkpoint）的條款不同。

對部署人員而言，有兩項架構細節比主打規格更為重要。{{1}}首先是混合注意力：多數層採用 Gated DeltaNet 線性注意力，僅四分之一層保留完整 KV 快取，因此長上下文所需記憶體僅為傳統 64 層密集模型的一小部分——這正是讓 262K 視窗能在單張消費級 GPU 上實現的關鍵。{{/1}} {{2}}其次是多 token 預測（MTP）：檢查點自帶推測解碼頭，當服務堆疊採用它時，能明顯加快解碼速度。{{/2}}

它也是該系列中具備影片功能的一款。旗艦級開放檢查點 Qwen3.8-2.4T-A95B 在其可下載形式中實際上僅支援文字，而託管的 Qwen3.8-Max API 則在這些權重之上增加了視覺能力。27B 是您確實可以下載並執行、且開箱即用就能處理文字、影像和影片的權重——這就是為什麼其影片模式的 CPU 路徑值得關注。

SGLang 這個 PR 實際上改變了什麼

這個 pull request（sgl-project/sglang #35492）範圍狹窄且清晰易懂。它自己的描述：「此 PR 旨在支援 Qw​en3.8 文字+視訊，透過新增 torchcodec、ffmpeg 並移除 pin_memory。」實際上，這是三項變更。

• torchcodec——PyTorch 以 ffmpeg 為後端的影片解碼函式庫——已加入技術棧，因此 Qw​en3.8 text+video 的影片幀可在主機 CPU 上解碼並預先處理。此 PR 將 torchcodec 0.12.0 固定搭配 torch 2.12，並註明 ffmpeg 必須保持低於版本 9。

• pin_memory 已被移除自多模態路徑。pin_memory 是一種 GPU 傳輸優化，用於固定主機緩衝區以進行快速非同步複製到裝置；在僅 CPU 的路徑上移除它，即表示目標硬體在數據路徑中沒有獨立的加速器。

• 重現命令會啟動實際模型 — Qwen/Qwen3.8-27B — 透過 sglang.launch_server 在 CPU 上執行，並啟用文字+影片輸入路徑。

在你基於它建置任何東西之前，請先閱讀狀態標籤：該 PR 目前是草稿，兩個 CI 執行都失敗，而且截至今天仍在等待 SGLang 程式碼擁有者的審查。它是一個方向，不是一個釋出版本。重要的背景是 SGLang 已經在 GPU 上提供 Qwen3.8-27B 服務——這份 cookbook 涵蓋 H200、RTX PRO 6000、RTX 5090 和 DGX Spark，並附有專用的 lmsysorg/sglang:qwen38-27b 映像檔——因此 CPU 的文字+影片路徑才是真正的新功能。

為什麼 CPU 文字+影片比聽起來更重要

阿里巴巴從一開始就將 27B 定位於邊緣 AI — MediaTek 在權重發布的當天就將其改寫至 Dimensity 手機晶片與 C-X1 車載座艙。本地部署的敘事更強化了這點：Q4_K_M 量化後約 17.1GB，可放入 24GB 的消費級 GPU，或配備 32GB 統一記憶體的 Apple Silicon Mac。但這個敘事唯一無法做到的，是在完全沒有 GPU 的機器上處理影片。這正是本 PR 要填補的缺口。

以 CPU 處理文字與影片的路徑，使影片理解能部署於一般 CPU 機器上——虛擬機器、小型伺服器、地端機架單元、邊緣閘道——這類工作負載屬於非同步處理，吞吐量比延遲更重要。影片字幕、內容審核、文件與圖表解析、對錄影內容的離線檢索：這些正是不需要 GPU 的批次工作，而如今任何具影片輸入的 VLM 仍預設必須使用 GPU。

誠實的權衡是：Qwen3.8-27B 是一個擁有 270 億參數的模型，沒有任何 CPU 路徑能讓 270 億參數跑得快。即使在配備 AVX 等級的強大伺服器上，且上下文包含視訊幀時，也只能期待個位數的每秒 token 數——足以應付批次與隔夜任務，但不適合視訊上的互動式聊天。CPU 路徑的意義在於這個選項確實存在：無 GPU 部署可以執行同一個模型的視訊模式，而不是退而使用較小的視覺模型，或將每一幀畫面都送往雲端 GPU。

Qwen3.8-27B 如今運行於何處

生態系很快就趕上了這個模型。在自架（self-host）那一端，你有 llama.cpp 和 LM Studio，提供低至約 10.7GB 的 2-bit 量化 GGUF 套件；Ollama 讓你一行指令搞定；vLLM 和 SGLang 則負責正式伺服部署。目前這些大多只支援文字或影像；在 CPU 上的影片處理路徑，仍是還在建置中的部分。

如果您不想自行運行 27B 模型，託管路由已存在：OrcaRouter 提供 qwen/qwen3.8-27b支援文字、圖片和影片輸入，上下文視窗為 262,144 個 token，並提供文字輸出；每百萬個輸入 tokens 收費 $0.33，每百萬個輸出 tokens 收費 $2.40。它與平台上其他所有模型一樣，使用同一個 OpenAI 相容端點——一個 API 金鑰，不需要第二份合約——而且該平台的自動容錯移轉和路由 DSL 適用於該金鑰上的 200+ 個模型。一個剛發布五天、CPU 路徑尚未驗證的模型，正是路由而非固定連線的典型情況：你可以透過路由在實際工作負載上試用 Qwen3.8-27B，而無需將整個呼叫路徑押注在單一伺服堆疊上，並且可以在自架與託管版本之間切換，無需修改程式碼。

這些數字——由廠商回報，值得查證

以下每個標題數字均來自阿里巴巴自家，取自模型卡和發布資料。該模型才推出五天，獨立的複現測試才剛開始出現，所以請將這些視為有明確方向的說法，而非定論。以27B而言，程式碼與智能體的分數最引人注目：

• SWE-bench Pro — 61.7（Alibaba 所報告；其自身表格顯示 Claude Opus 4.6 Max 為 53.4）

• Terminal-Bench 2.1 — 73.0（代理式終端編碼）

• OSWorld-Verified — 84.3 (電腦使用代理任務)

• AndroidWorld — 81.9

• DeepSWE 1.1 — 42.2，大約是先前開放 27B 的 13.3 的三倍

在視覺方面——也就是本文真正關注的這一方面——阿里巴巴報告，其在無工具情況下，影片理解的 VideoMME 得分為 87.0，視覺推理的 MathVision 得分為 90.0。{{1}}Artificial Analysis{{/1}} 的初步評估將其模型在其智慧指數上列為 52 分，在其代理指數上列為 51 分，{{2}}在某些推理設定下，可與規模大得多的封閉模型一較高下；{{/2}}{{3}}這些仍是針對一個發布僅五天模型所做出的早期分數。{{/3}}

對於任何在本地或 CPU 上運行該模型的人來說，有一個注意事項格外重要，那就是推理調節旋鈕。Qwen3.8-27B 預設開啟思考模式，並提供每次請求的 reasoning_effort 設定（low / medium / xhigh）。預設的 xhigh 會嚴重過度思考：如今廣為人知的首次運行 17GB GGUF 檔案，花了約 21 分鐘和 22,000 個推理 token 才畫出一張簡單的圖片。尤其在 CPU 上，務必審慎設定 reasoning_effort——互動體驗與完全無法使用之間的差異，僅在於這一個參數。

看什麼

三件事將告訴你CPU路徑是否會成真：

• PR #35492 是否會合併。它目前是草稿，今天的 CI 呈現紅色。要等到合併後、CI 通過的版本正式釋出，CPU 的文字＋影片路徑對我們其他人來說才算可執行。

• 獨立基準測試。61.7 的 SWE-bench Pro 與 87.0 的 VideoMME 分數為廠商自行申報的數據。接下來幾週內，LMArena 和 Artificial Analysis 的測試結果將顯示，在阿里巴巴自家的測試框架之外，這些數字還能保留多少。

• 代管式 1M 上下文版本是否會實現。原生 262K 已經很可觀；百萬 token 的多模態模式，才是混合注意力快取節省能真正回本之處。

目前決定很簡單。如果你有硬體，{{1}}17GB 的 Q4 GGUF 加上 SGLang 或 llama.cpp 今天就能跑這個模型，而 CPU 文字+影片的 PR 則顯示了無 GPU 路線的走向{{/1}}。如果沒有，{{2}}{{KEEP}}Qwen3.8-27B{{/KEEP}} 可透過 OrcaRouter 呼叫，單一金鑰下輸入端每百萬 tokens 收費 0.33 美元，輸出端每百萬 tokens 收費 2.40 美元{{/2}}。無論如何，具備影片能力的開放 27B 模型是 Qwen 3.8 世代中最值得關注的模型——而且它才五天大。