阿里開源 Qwen3.8-27B 本地實測：性能很強，但 Agent 適配仍待補課

從部署到實測：覆蓋標準部署、量化部署、Agent場景三大維度。作者丨吳海明 何宇軒 編輯丨李娜 岑峰 8月14日，阿里 Qwen 團隊開源了 Qwen3.8-27B 模型，緊接著社區裡的聲音從“能不能跑”變成了“是不是新的模型斬殺線”，有人把它叫作本地 Opus，也有人直接給出更刺激的判斷：一個 27B 開源模型，已經能在部分代碼和 Agent 任務上達到頂級閉源模型的水平。那麼，一個 27B 開源模型，體驗到底怎麼樣呢?根據官方數據，27B dense、Apache 2.

0、262K 原生上下文、可擴展到 100 萬 token、支持視覺理解、思考默認開啟，低比特量化後還能壓到十幾 GB 級 GGUF 文件，這說明 Qwen3.8-27B 是一個試圖把代碼、長上下文、多模態和 Agent 工作流一起拉到本地的開源底座。因此，我們從適配 Agent 出發，先後測試標準化部署、量化部署和接入 Agent 框架。其中，標準部署看 vLLM、SGLang 和 Llama.cpp 誰更能榨乾 GPU，將推理速度提到最快；量化部署從 2bit 測到 16bit，看文件體積、速度和質量怎麼取捨；Agent 測試則把本地 Qwen3.

8-27B 接入 DeepSeek Harness，並用同樣本地部署的 DeepSeek-V4-Flash-0731 做對照。測試任務從組合推理、事實校驗、新聞寫作，一直壓到論文綜述和 3D 網站生成。實測結果有點像給這波熱度潑了一杯很濃的咖啡：確實醒腦，但也很苦。在 Agent 質量評分裡，Qwen3.8-27B 最終拿到任務完成度的滿分，複雜任務完成度明顯更穩；標準部署下，vLLM 和 SGLang 平均吞吐都超過 40 token/s；量化部署裡，3bit 到 6bit 在本輪文本任務中保持了完成度滿分的質量。

可另一面也同樣扎眼：Qwen 最終跑通 9 個 Agent 任務消耗了 13,995,350 token、197 次請求和 22,564.37 秒，約 6 小時 17 分鐘；其中，生成 3D 網站單題就燒掉 11,533,959 token，分析日誌發現，核心問題出現在複雜任務拆分歸於複雜、單步目標過重、上下文反覆回灌，導致大量時間消耗在和空轉上。它確實能幹活，而且能把複雜任務做得更完整，但是它燒的不僅是 token，更是用戶的時間。所以，這篇文章回答了：性能比肩 Claude Opus 4.6 Max 的開源 dense 模型，放到本地工作流裡到底怎麼用？

在哪些部署框架下跑得快，量化到幾 bit 還可靠，接入 Agent 後質量優勢值不值得、等待時間和本地計算成本？簡單說，Qwen3.8-27B 是一個能做事、願意深想、但必須被嚴格約束 token、步驟和輸出邊界的開源 Agent 底座。它讓社區開發者和科研院所有機會用本地設備獲得接近頂級閉源模型的能力，也把一個新的問題擺到臺前：開源免費之後，我們還要不要為時間買單？01不看榜單，直接實踐：部署、量化、Agent 三組硬測我們在一臺搭載 A100 GPU 的服務器上對 Qwen3.

8-27B 進行部署和測試，同時，我們設計了三類任務題目：第一類是模型能直接完成的推理題，第二類是指令跟隨和事實校驗題，第三類是接入 Agent 後才有意義的長上下文、文件讀寫和前端生成任務。具體題目如下：這三類題目被用來考驗模型的多種能力，推理題考察模型能不能在沒有工具輔助的情況下穩定完成多條件推導，尤其是能否區分不同統計口徑、避免只給一個看似合理但不完整的答案。指令跟隨和事實校驗題更接近日常內容生產場景，重點考察模型是否能遵守字數、格式、禁詞、語氣和事實邊界，避免在任務中把話說滿、說偏或說過頭。

Agent 測試題則進一步把模型放進文件系統和代碼生成流程裡，觀察模型能不能讀材料、寫文件、組織長上下文、生成可運行代碼，並在複雜任務中持續推進到一個可交付結果。評分上，我們採用 0 到 2 分制：完全滿足題目要求記 2 分；主體方向正確但有明顯瑕疵記 1 分；關鍵結論錯誤、任務失敗或輸出截斷記 0 分。需要說明的是，質量分、吞吐、顯存、耗時和 token 消耗是不同口徑，本文會分開統計，同時評估模型在跑得快與答得好兩方面的表現。基於上述題目，我們同時構建了三組測試任務：標準部署、量化部署和 Agent 場景測試。

標準部署組使用官方標準模型權重與題目，對比 vLLM、SGLang 和 Llama.cpp 三種部署框架，觀察不同部署框架下的回答質量與吞吐差異；量化部署組採用 Llama.cpp 作為框架，橫向測試 2bit 至 16bit 版本，考察模型權重文件大小、生成速度和回答質量之間的取捨；Agent 組則把部署好的模型接入熱門的 DeepSeek Harness，在 A1~A7 之外加入論文綜述（A8）和 3D 網站生成（A9），記錄任務完成率、質量得分、token 消耗、請求次數和端到端耗時。

三組測試分別回答三個用戶最關心的問題：什麼框架更合適本地部署、壓縮到什麼程度仍然可靠，以及接入 Agent 後能否以可控成本完成任務。標準部署：vLLM / SGLang 跑滿 A100，Llama.cpp 勝在門檻低三款主流模型部署框架：vLLM, SGLang 和 Llama.cpp在這組實驗中，我們分別用 vLLM、SGLang 和 Llama.cpp 部署標準 Qwen3.8-27B，並使用 A1-A7 的 7 道題測試回答質量和平均吞吐量，題目覆蓋組合推理、時間線校驗、表格推理、中文精確指令跟隨、閒聊、新聞寫作和實驗結果歸因。

一起看看結果：從結果看，vLLM 的表現最穩，7 道題拿到 14/14，SGLang 和 Llama.cpp 沒有出現方向性錯誤，但都暴露出一些約束執行問題：SGLang 在 A3 表格推理裡對不同口徑的分析不夠完整，A4 的第 5 句話也低於題目要求的 18 到 28 個漢字；Llama.cpp 的主要扣分點出現在 A6，新聞稿要求約 800 字，實際生成到 1400 多字，內容能用，但篇幅控制失守。速度差異比質量差異更明顯，vLLM 和 SGLang 的平均吞吐分別為 41.77 token/s 和 40.06 token/s，基本在同一檔；Llama.cpp 為 23.

50 token/s，只有前兩者的六成左右。進一步從三個框架在推理過程中的顯存佔用可以發現，vLLM 和 SGLang 都充分利用了 GPU 資源：vLLM 在兩張 A100 上都接近 39.3GB 顯存佔用，GPU 利用率達到 100%；SGLang 的顯存佔用也在 38GB 到 40GB 附近，GPU 利用率約 98%。Llama.cpp 則只佔用了 34GB 左右顯存，推理時 GPU 利用率只有 46% 到 53%，這解釋了它為什麼質量還能跟上，吞吐卻明顯落後一檔。因此，標準部署裡真正拉開速度的核心是框架能否把 GPU 算力高效利用。

量化部署：3bit 到 16bit 質量持平，2bit 開始露出邊界這組實驗用 Llama.cpp 測試 2/3/4/5/6/8/16bit 版本，量化本身不改變模型參數量，改變的是權重存儲精度和文件體積，在一定程度上會影響模型結果的效果。Qwen3.8-27B 的權重參數量為 27.78 B，官方版本的權重大小約 55.59 GB，量化後的 GGUF 版本文件大小則從 7.27GB 到 54.7GB 不等。具體測試結果如下：這組量化結果要分三條線來看：1.

質量：3bit、4bit、5bit 和 6bit 在 7 道題上都拿到 14/14，說明在這批文本推理、指令跟隨和短文寫作任務裡，中低比特量化沒有帶來明顯質量塌陷。2bit 和 8bit 都是 13/14，扣分點集中在 A2 時間線校驗：它們先識別出日期矛盾，卻在修正版裡又把“正式權重已在更早日期公開”寫了回去，而 16bit 也是 13/14，但問題換成了 A6 篇幅控制，約 800 字的新聞稿實際寫到 1200 多個漢字，內容可用，邊界沒守住。2.速度：吞吐並沒有隨著 bit 數升高而平滑下降，但大方向仍然清楚：2bit / IQ2_XXS 最高，為 47.

89 token/s；3bit 為 44.68 token/s；4bit 為 39.45 token/s；5bit 和 6bit 繼續降到 36.11 和 33.12 token/s。8bit 為 30.79 token/s，16bit 只有 23.50 token/s。低比特確實能換來更輕的存儲和更高的平均生成速度，但 2bit 的質量邊界已經在事實修正題裡露出來。3.顯存: 截圖顯示，量化文件越大，推理時顯存佔用也基本同步上升：2bit 在兩張 A100 上約佔 13.8GB 和 14.

1GB，3bit 約 15GB，4bit 約 17GB，5bit 接近 19GB，6bit 約 20GB，8bit 約 23GB；到 16bit 時已經升到約 34GB。相比標準 bf16 部署，低比特版本把本地運行門檻明顯壓低了。不過這些 Llama.cpp 量化測試裡的 GPU 利用率大多在 46% 到 53% 之間，說明 Llama.cpp 和量化版模型的組合更加適合 PC 或邊緣設備端部署推理 。

因此，這組結果更適合支持一個剋制結論：如果只看本輪 7 道文本任務，3bit 到 6bit 是比較穩的區間；2bit 最省、最快，但已經出現事實修正錯誤；8bit 並沒有因為更高精度完全避免同類問題；16bit 則證明高精度也可能在輸出長度上失控。Agent 測試拉開差距：Qwen 質量拿滿分，成本也衝到天花板Agent 測試實驗，是本文最關鍵的一組。我們在分別在 DeepSeek Harness 上分別接入 Qwen3.8-27B 和 DeepSeek-V4-Flash-0731-Q4 兩個開源模型，兩個模型都在本地部署後，完成上述 9 個任務。

這些任務包括組合推理、時間線校驗、表格推理、中文指令跟隨、新聞寫作、長上下文論文綜述，以及一個複雜 3D 網頁生成任務。從回答質量來看，Qwen3.8-27B 表現更佳，最終拿到 18/18，質量通過率 100%；DeepSeek-V4-Flash-0731-Q4 得分為 14/18，質量通過率 77.78%。DeepSeek 的優勢是執行快，但在若干需要嚴格校驗的任務中不夠穩，例如 A1 會保留錯誤中間表格，A2 的時間線修正版仍有不嚴謹之處，A7 對 Agent 增益的表述偏積極。Qwen 的答案更剋制，尤其在表格口徑、事實邊界和實驗歸因這類題目上，更接近媒體評測需要的寫法。

另外，A9 的差異更直觀，兩個模型都被要求生成“頤和園 · 昆明湖與萬壽山”的 3D 網站，結果如下圖所示。Qwen 生成的頁面已經具備昆明湖、萬壽山、佛香閣、橋、導覽按鈕和日景/暮色切換等核心元素，拖拽旋轉、滾輪縮放、鏡頭切換也能工作，整體更接近一個可交付的 3D 數字沙盤。DeepSeek 的頁面雖然保留了標題、景點按鈕和交互提示，但主畫面基本為空，頤和園主體元素沒有真正渲染出來。這一題把兩者的差別放大了：Qwen 更願意把複雜場景一步步補齊，DeepSeek 更容易先把框架搭出來，但視覺內容沒有跟上。Qwen3.

8-27B-Q16 和 DeepSeek-V4-Flash-0731-Q4 在 DeepSeek Harness 框架中一次性完成 “頤和園 · 昆明湖與萬壽山” 3D 網站的頁面結果然而， Qwen 雖然具有質量優勢，但代價也很高，完成上述 9 個任務共消耗 13,995,350 token，其中輸入 token 達到 13,718,510，輸出 token 為 276,840，總耗時 22,564.37 秒 （約 6 小時 17 分鐘），請求 197 次。

DeepSeek 總 token 為 956,630，輸入 token 927,401，輸出 token 29,229，總耗時 1,343.75 秒 （約 22 分鐘），請求 87 次。換算下來，Qwen 的總 token 約為 DeepSeek 的 14.6 倍，總耗時約為 16.8 倍，輸出 token 約為 9.5 倍。其中，A9 任務是兩個模型成本差距最大的來源，Qwen 的單題就消耗 11,533,959 token、124 次 LLM 請求和 18,639.20 秒；DeepSeek 同題只用了 161,019 token、15 次請求和 540.95 秒。

通過這組結果可以知道 Qwen3.8-27B 更適合質量優先、需要長推理和複雜交付的任務，但必須被嚴格約束；DeepSeek-V4-Flash-0731 更適合快速執行和低成本嘗試，但關鍵結論和複雜視覺交付需要人工複核。另外，在 Agent 場景下，模型可用性不只看能否完成，還要看完成一次任務要花多少 token、多少時間，以及失敗時是否容易被發現和修正。02從官方榜單解讀：Qwen3.8-27B 為什麼能成為高端 Agent 的底座為了回答這個問題，我們回到官方在 Hugging Face 的模型卡，Qwen3.

8-27B 的定位是一個面向 coding、professional work、research 和 long-horizon agentic tasks 的本地開源模型，官方給出的基準榜單也基本圍繞這幾個方向展開：代碼、Agent、長程辦公、指令跟隨、科學推理，以及多模態 computer use：()在此，我們通過上表中與當前測試相關的評測榜單數據來進一步分析 Qwen3.8-27B 效果好的原因。首先，對比 Qwen3.6-27B，Qwen3.8-27B 的提升主要集中在更接近真實工作流的任務上。Terminal Bench 2.

1、SWE-bench Pro、NL2Repo-Bench、DeepSWE 和 QwenSWEBench 分別對應終端環境編碼、軟件工程修復、repo 級代碼生成和自主工程執行，這些指標都有明顯提升，說明模型不只是單輪代碼能力變強，而是在讀懂任務、規劃步驟、調用工具和持續修正上更接近 Agent 工作流需要。其次，CoWorkBench、JobBench 和 Agents' Last Exam 的提升，解釋了 Qwen3.8-27B 為什麼在 Agent 場景裡更願意把任務推進完整；IFBench 從 69.1 提到 79.5，則說明它在格式、邊界和複雜約束跟隨上有更強基礎。

與此同時，GPQA Diamond、HLE 以及 OSWorld-Verified、WebArena-Verified、AndroidWorld、MathVision、OmniDocBench、RealWorldQA 等指標也表明，Qwen3.8-27B 保留了較強的科學推理、知識處理、視覺理解和 computer use 能力。這些官方數據共同指向一個結論：Qwen3.8-27B 的優勢來自更完整的 Agent 能力棧，而不只是某一項單點能力變強。更準確地說，據官方披露 Qwen3.

8-27B 的能力確實向代碼、Agent、長程任務、指令跟隨和多模態理解傾斜，這解釋了它為什麼在複雜任務裡更容易做出高質量結果。03Qwen3.8-27B 雖然很強，但在 Agent 場景的處理能力並不強前面的結果說明 Qwen3.8-27B 的能力足夠強，並不能說明它完全適合作為 Agent 底座，這需要深入分析接入 DeepSeek Harness 後的運行數據。

我們從 DeepSeek Harness 的會話日誌中拆分了 reasoning chunks、text chunks 和 step 時長，並分別統計 A1~A7 常規任務、加入 A8 長上下文論文綜述後、再加入 A9 複雜 3D 網站生成後的平均思考佔比。結果如下：根據 A1~A7 常規任務，Qwen 的平均思考時間佔比約為 55.6%，平均思考 token 佔比約為 60.7%，這說明，Qwen 還沒有真正進入輸出和操作階段，就已經把一半以上資源花在內部推理裡。加入 A8 後，Qwen 的思考時間佔比下降到 48.

4%，主要是因為長上下文論文綜述帶來了更重的 prefill 和上下文處理成本，降低了思考的比例，到了 A9 複雜 3D 網站任務，平均思考時間佔比又回到 51.3%，思考 token 佔比也升到 58.3%。相比之下，DeepSeek 的思考時間佔比從 A1~A7 的 29.6% 降到 A1~A9 的 24.2%，思考 token 佔比也從 36.6% 降到 30.1%。為了更好分析模型在複雜任務中與 Agent 框架的適配性，我們進一步統計了兩個模型在 A9 上的運行數據。

A9 要求模型完成頁面構思、結構拆分、前端實現、文件讀寫和結果交付，如果 Agent 能力足夠強，模型應該先把任務拆成若干邊界明確的小目標，再逐步完成。從上表看，相比 Qwen 總耗時 21,543 秒 （約 6 小時），DeepSeek 只用了 540 秒，約 9 分鐘；同時，Qwen 的結果輸出時間是 146 秒，DeepSeek 是 23 秒，差距約 6.3 倍。

真正拉開距離的是思考時間、其它運行時間和多輪執行，Qwen 的思考時間達到 5,974 秒，是 DeepSeek 的 157 倍；而其它運行時間達到 12,632 秒，佔總時間 59%，這部分往往對應上下文處理、工具調用、文件讀寫、等待和反覆執行，即 Qwen 並不是一直在高效生成結果，而是在 Agent 流程裡耗費了大量不可見時間。任務拆解數據也能解釋這種空轉，Qwen 拆出了 75 個 step，分 3 輪 turn 執行，請求大模型 124 次，而 DeepSeek 只有 8 個 step、15 次請求。

可以發現，Qwen 的步驟更多、更細，但結合耗時和 token 看，問題恰恰是“拆得多，不等於拆得好”。有效的任務拆分應該讓每一步目標更窄、完成標準更清楚、上下文更輕，而 Qwen 的很多 step 仍然很重，單步內繼續長時間思考，後續又反覆帶著龐大上下文進入下一輪，最終把輸入 token 推到 11,315,587，是 DeepSeek 的 548 倍。所以，Qwen3.8-27B 在 Agent 場景中的真實表現是不會經濟地把任務做完，儘管模型能力很強，但很大程度上來自更長時間的深思、更多輪次的反覆和更高 token 消耗，而不是來自高效的規劃、拆解和執行控制。

對於 Agent 產品的底座來說，一個模型如果不能把任務拆細、不能識別無效循環、不能及時停止空轉，即使最後能做出結果，也會讓用戶付出過高的等待成本和算力成本。04從部署到 Agent：Qwen3.8-27B 值得用，但 Agent 場景必須被約束回到最實際的問題：如果只是部署 Qwen3.8-27B，框架怎麼選？追求服務化吞吐和 GPU 利用率，vLLM 和 SGLang 更合適，兩者基本處在同一檔；如果更看重上手門檻、量化版本支持和本地設備適配，Llama.cpp 仍然是更友好的選擇。換句話說，vLLM / SGLang 更適合“把 A100 跑滿”，Llama.cpp 更適合