在 Apple Silicon 上使用 Qwen3.8-27B-Uncensored-MLX：如何挑選你的版本、在 LM Studio 或 mlx-vlm 中載入，以及駕馭 262K 上下文

最需要知道的orcarouter/Qwen3.8-27B-Uncensored-MLX是：你不必選擇子資料夾就能執行它。OrcaRouter 的 abliterated、Apple Silicon 版 Qw​en/Qwen3.8-27B — 於 2026 年 8 月 17 日發布到 Hugging Face，所以它不是新東西，只是文件不足 — 在 repo 根目錄保留了一份 4-bit 建置，專門為了讓把一個 repo 當作一個模型的工具（最重要的是 LM Studio）完全無需設定就能載入。這一個決定就是為什麼這張卡在過去一個月獲得了約 83,000 次下載，而同類的 MLX 轉換只獲得一小部分。關於它的其他一切都是真正的選擇：四種精度中哪一種適合你的 Mac 的統一記憶體、你使用哪個 runner、視覺與工具呼叫在你的位元寬度下是否還能運作，以及 262,144 個 token 的上下文視窗在你的硬體上是否值得其所耗費的代價。這本 runbook 依序討論這些選擇。它是第一方文件 — 下列的大小、精度與保真度數據都是 OrcaRouter 自己的，在此確切版本上測得，而每個社群數字也都如此標示。

這個 repo 裡到底有什麼

這是 Qw​en/Qwen3.8-27B 的一個經 Abliteration 處理的建置——這是一個 27B 參數的稠密混合注意力模型（Gated DeltaNet 線性注意力加上完整注意力），原生支援視覺語言，具備思考控制、工具呼叫、多 Token 預測（MTP）頭，以及 262,144 個 Token 的上下文視窗。Abliteration 透過將拒答方向正交化移出殘差流，來移除模型的拒答行為；如果你對此不熟悉，我們關於此技術的入門指南會比這個頁面更適合入門，因為這個頁面是關於執行此建置，而非方法本身。權重採用 Apache-2.0 授權，繼承自基礎模型。

請勿將此儲存庫與 qwen-3-8-27b-mlx 混淆，後者是 MLX 格式的相同基礎模型但未經abliteration 處理。讀者經常會抓錯：本來要下載的是另一個，卻抓到這個——這個是移除拒絕機制的研究版本；那個是在 Apple Silicon 上執行的標準 Qwen/Qwen3.8-27B。在花費時間下載之前，請先檢查儲存庫名稱。

有一個結構細節比表面上看起來更重要：視覺塔、所有正規化層，以及線性注意力 conv1d 都保持在 BF16，只有語言模型的線性層——包括 embed_tokens 和 lm_head——被量化。這就是為什麼影像理解能在量化後保留下來，也是為什麼下方所列的磁碟大小會比粗略的「27B 以 N 位元」估算值略大：模型的一部分從未被壓縮。

決定：哪個版本適合哪台 Mac

四种精度以子文件夹形式提供——8位、6位、4位、2位——全部为组大小64的MLX仿射量化。4位构建额外镜像于仓库根目录。先按Mac的统一内存选择，再看质量：

• 8-bit — 磁碟上約 27.5 GB，需要 64 GB 的 Mac（32 GB 的機器可以載入，但留給其他用途的空間所剩無幾）。相對於 BF16 來源量測的餘弦保真度為 0.9997，實際上接近無損。當品質是首要目標且記憶體充裕時，選擇它。

• 6位元 — 約 22 GB，適合 24–32 GB 的 Mac。保真度 0.9996，極佳。對於大多數 48 GB 機器的擁有者而言，這是每 GB 品質的最佳平衡。

• 4-bit — 約 15 GB，在 24 GB Mac 上綽綽有餘。保真度 0.996，非常出色。這是我們推薦的預設選項，因此儲存庫根目錄中的就是此版本。

• 2-bit — 約 8.7 GB，16 GB 的 Mac 也裝得下。保真度 0.92，且在 27B 下嚴重退化：重複迴圈、文字、程式碼與中文亂碼、視覺能力不全。卡片上寫得很清楚——僅供歸檔，不適合實際工作。16 GB 的 Mac 技術上可以載入；但這並不表示它可用。

磁碟上的大小並非記憶體數字。權重必須與 macOS、KV cache 和 Metal 的暫存緩衝區一起放入統一記憶體中，因此請保留餘裕。社群在 M1 Pro 32 GB Mac 上執行 4-bit 版本，量測到磁碟上的權重約 16 GB，但推論峰值為 18.5–21.7 GB；社群執行 8-bit MLX 版本則回報峰值約 34–36 GB，即使權重約為 29.5 GB。來自同一社群測試的實用建議是：16 GB 對 27B 模型來說並非真正的選項，24 GB 可以嘗試搭配短上下文的 4-bit，而 32 GB 是舒適的起點。我們的 VRAM 規劃文章針對整個系列說明了相同的計算方式。

由於儲存庫的整體清單涵蓋所有精度，總計約 94 GB，因此請僅下載您需要的子資料夾，使用hf download orcarouter/Qwen3.8-27B-Uncensored-MLX --include "4-bit/*" --local-dir ./Qwen3.8-27B-Uncensored-MLX，並替換為您選擇的精度。根目錄中的 4-bit 副本與 4-bit 子資料夾內容重複，因此您無需同時下載兩者。

路徑一 — LM Studio，零配置

根目錄的 4-bit 副本是專門為了讓 LM Studio 能將整個 repo 視為單一模型。搜尋模型 ID，選擇你想要的精度（根副本是 4-bit），應用程式會處理其餘部分。三個陷阱，全部來自我們的卡片，而它們正是成敗之間的完整差別：

• 此儲存庫已受門禁保護。匿名下載會收到 HTTP 401。請先在模型頁面接受條款，然後將 Hugging Face 讀取權杖貼到 LM Studio 的 Settings → Integrations → Hugging Face。若略過此步驟，載入就會直接失敗。

• 關閉 KV 快取量化。MLX 視覺模型在此架構上不支援此功能，若啟用則會在初始化期間載入失敗（追蹤編號：mlx-engine#286）。這與 GGUF 建置版本的建議相反，在 GGUF 中對 K/V 快取進行量化是合理的 VRAM 節省方式——這兩種格式在此處不可互換。

• 更新執行環境。 qwen3_5架構支援已加入 mlx-vlm 0.6.x；較舊的內建執行環境根本無法載入這些權重。相較之下，LM Studio 的「Likely too large」標籤只是 RAM 警告，而非錯誤——如果你的統一記憶體符合上述指引，請忽略它。

{{1}}在 LM Studio 中該選擇哪種精度：8-bit 在磁碟上約佔 29.5 GB，需要 64 GB 的 Mac；6-bit 約 22 GB，適合 48 GB 的機器；4-bit 約 16 GB，是 32 GB Mac 的正確選擇。{{/1}}{{2}}如果你在其他硬體上想走 llama.cpp / Ollama 路線，我們針對未審查模型的本機執行指南會另外涵蓋這條路徑。{{/2}}

路徑二 — mlx-vlm 和 mlx-lm 從子資料夾

命令列方式能直接提供精確度，並提供一個與 Open​AI 相容、供代理工具使用的伺服器。需求： pip install -U mlx-vlm (mlx-vlm ≥ 0.6.13 且 mlx ≥ 0.32；Metal 後端會在 Apple Silicon 上自動選取)。在上述子資料夾下載完成後：

python -m mlx_vlm generate --model ./Qwen3.8-27B-Uncensored-MLX/4-bit --prompt "用一句話解釋量子糾纏。" --max-tokens 256

新增 --image path/to/image.png 以進行視覺輸入，或提供它：

python -m mlx_vlm server --model ./Qwen3.8-27B-Uncensored-MLX/4-bit --port 8080

For agent frameworks that speak Open​AI-compatible APIs, mlx_lm.server is the lighter path — uv tool install mlx-lm then mlx_lm.server --model "orcarouter/Qwen3.8-27B-Uncensored-MLX", which serves at http://localhost:8080/v1 with api type openai-completions. Our card carries self-reported community configs pointing Pi, Hermes and OpenClaw at that endpoint. Those are user-supplied setups we have not reproduced, so treat them as starting points, not guarantees.

視覺在量化中存活

由於視覺塔（vision tower）和 conv1d 保持在 BF16，影像理解在 4/6/8-bit 下得以保留。在我們的測試圖像上——形狀、顏色、位置、背景和圖內文字——4/6/8-bit 版本都能正確描述一切；2-bit 只能部分描述。如果你正在選擇版本，且視覺功能對你很重要，4-bit 是你應該選擇的最低等級。我們尚未發布此版本針對 Apple Silicon 的視覺吞吐量數據，因此除非該 tok/s 數字來自於你自己晶片等級上的具名運行，否則不要相信它。

被保留的視覺塔也是風險表面的一部分，值得直白地說明：一個也能讀取圖像的 abliterated 模型，不只是純文字的安全問題。

工具呼叫與代理使用

工具呼叫是基礎模型的一項能力，且能挺過 abliteration，這使得此版本對代理式系統進行紅隊測試確實有用——而若指向真實服務則確實危險。標準設定是上述的mlx_lm.server端點，任何與 Open​AI 相容的代理都能呼叫。如果你確實要將它作為代理執行，請了解你啟用了什麼：一個無拒答、具函式呼叫與 262K 上下文的模型，其安全態勢與聊天模型不同；而模型卡將其定位為僅供研究，正是出於這個原因。

262K 上下文與其實際成本

這種架構賦予此模型異常低廉的長上下文成本。此處的混合注意力意指 48 個線性注意力（Gated DeltaNet）層與 16 個完整注意力層交錯排列，且只有這 16 個完整注意力層配備傳統的 KV 快取——線性層則改為維持緊湊的遞迴狀態。因此，262,144 個 token 的處理成本會顯著低於在完整注意力的 27B 模型上的成本。這是關於基礎模型的結構性事實，而不是對你的 Mac 所做的效能保證。

實際上，上下文視窗是一項能力，而不是免費額度。社群在 M4 Max 上進行的長上下文測試顯示，短上下文時約為 63 tok/s，在 31K tokens 時降至約 11 tok/s——解碼速度會隨著快取填滿而急劇下降；而在非常長的提示詞上，首個 token 的延遲通常比原始吞吐量構成更大的障礙。基於投機（speculative）與 ANE 的 prefill 能改善輸入處理，但無法改善解碼。我們自家針對此版本在 Apple 晶片上的 KV-cache 成本數據並未公開；如果你需要針對自身硬體的具體數據，社群測試才是最可靠的來源，而社群的共識是：將完整的 262K 視為需要刻意動用的能力，而非預設開啟的預設值。

速度 — 實際測量的是什麼

我們針對這個版本只發布一個速度數據，而它不是 Apple Silicon：透過 MLX CUDA 後端在單一 H200 上穩定狀態約為 32–37 tok/s，這也證實了權重可以在 macOS 以外運行。在 Mac 上，我們的卡片刻意不發布 tok/s，因為這取決於晶片、精度和執行器。值得了解的實務數字，且都明確標示為如此：

• 這個確切的版本，4-bit，M1 Pro 32 GB：在短期運行中，生成速度約 8.7 tok/s，預填充速度約 41.7 tok/s（社群測試，2026 年 8 月）。雖然是較舊的晶片，但這是個現實的下限。

• 在 M4 Max 上搭配原生 MTP 的 oMLX，使用未經消融（non-abliterated）的原始 checkpoint：散文生成 53.3 tok/s，程式碼生成 72.1 tok/s；4K 前綴填充（prefill）約 273.7 tok/s；未使用 MTP 的原始解碼（decode）約 24.6 tok/s。這些數據是由實務者於不同的 checkpoint 與執行環境下測得，因此請將其視為 abliterated 權重可能達到的上限，而非保證數值。

• 在 M3 Ultra 上使用 oMLX 雙 ANE 預填充（prefill），abliterated oQ4e-MTP：在 16K 時預填充速度提升約 17.7%，在 32K 時約 18.9%；透過 Lightning MTP 解碼，在 16K 時可達約 75 tok/s。這些限制確實存在：它使用了 Apple 私有的執行時期介面與近似 INT8 權重，會增加約 4 GB 的峰值記憶體，並將模型載入時間從約 3.4 秒拉高到約 28 秒。這是提示攝入（prompt ingestion）的最佳化，而非生成加速器。

MTP 頭 — 如果您的執行器支援，即可免費加速

此版本在 mtp/ 子資料夾中提供了基礎模型的多 token 預測草稿模型（架構為 qwen3_5_mtp），且可搭配任何主精度使用。接受過程是無損的——使用貪婪解碼時，輸出與不執行草稿模型時完全相同——因此當它啟用時能帶來真正的加速，且不損失品質。我們卡片中有兩點設定說明：它需要一個包含 qwen3_5_mtp 草稿模型的 mlx-vlm 建置版本（main 分支），而且你必須同時傳入 --draft-model ./Qwen3.8-27B-Uncensored-MLX/mtp 與 --draft-kind mtp。只設定 mtp_enabled 不會有任何作用。如果你的執行器不支援此草稿模型，它會被忽略，模型照常正常運行——不會有任何問題。

安全 — 請在執行前閱讀，而非之後

模型卡本身的免責聲明異常直接，而本頁面並不會加以緩和。此建置的安全對齊已被大幅移除。它將順從基礎 Qwen/Qwen3.8-27B 會拒絕的有害、不道德、冒犯性或非法請求，且沒有實質的內建防護措施。它僅為合法研究而發布——可解釋性、AI 安全與拒答機制研究、紅隊測試、穩健性評估及受控實驗。如果你不是在做這些事，那這個模型就不適合你。

模型卡上的兩項警告值得強調。首先，越獄與安全探測在經去拒絕化（abliterated）處理的模型上會輕而易舉地「成功」，但這並非通過安全評估——這正是拒絕方向（refusal direction）已被移除之模型的預期行為。沒有拒絕反應並非安全的證據。其次，被保留的視覺能力、工具呼叫與 262K 上下文，將攻擊面擴展至影像理解與代理式（agentic）使用：一個能讀取螢幕截圖並呼叫工具的無審查模型，比僅限聊天的去拒絕版本構成更大的風險。低位元量化又在此之上疊加了第三層不穩定性——在 2 位元下，亂碼輸出甚至可能被誤認為拒絕回應，這本身就是一種令人困惑的失敗模式。

您須對使用本模型及其輸出內容承擔全部責任與法律責任。Apache-2.0 授權條款繼承自基礎模型，並不改變這一事實：它允許使用，但不會讓您的部署變得安全。任何將本模型部署給終端使用者、未成年人，或部署至任何生產環境的人，都必須先自行加入審核、安全與防範濫用的機制，並遵守適用法律。對於真正在執行本模型的研究人員，實際的防護措施包括：使用隔離且最好離線的環境；代理工具不得指向真實服務；不得暴露給終端使用者；以及在輸出內容流向任何地方之前先加以審查。

當在地化不是答案時

本機端運作正是這個建置的重點——權重檔案放在你的磁碟上，沒有逐 token 的費用，也不會有任何資料離開你的機器。但本機端同時也是一道天花板：它僅支援 Apple Silicon，你必須接受量化後的品質，而且機器忙碌時沒有備援。如果你需要透過 API 取得未經去抑制（non-abliterated）的 27B 級模型來執行實際工作負載，或者想用相同提示詞將本機建置與託管模型進行 A/B 比較，那就是路由層要填補的缺口。OrcaRouter 以供應商列表價格，將 200+ 模型放在同一組 API 金鑰後面，並提供自動故障轉移與路由 DSL——供應商宣布降價當天，我們這端就會同步生效，因為我們直接傳遞列表價格。單一 API、單一整合，你就能在不另開第二個帳號的情況下，將未經驗證的本機設定與託管模型進行比較。我們並未託管這個 MLX 建置——它本來就是本機權重設計——所以 API 是互補路徑，而非替代方案。

快速決策指南

• 16 GB Mac —— 老實說，不建議這個型號。2-bit 裝得下，但僅供歸檔；無論如何你都得跟記憶體搏鬥。找個較小的無審查模型，或採用社群為 18–24 GB 機器打造的混合 3/6-bit 轉換版。

• 24 GB Mac — 4-bit，並保持上下文簡短；請勿同時執行視覺與長上下文功能。

• 32 GB Mac — 4 位元是最佳選擇；若保持上下文緊湊，6 位元亦可。

• 48 GB Mac — 6 bit，具備餘裕空間；若不將視窗推到極限，則為 8 bit

64 GB 及以上 — 在上述注意事項下，8 位元、近乎無損與 262K 上下文長度皆可實現。

這就是完整的操作手冊。該模型來自 2026 年 8 月 17 日，這不是發布新聞，也不需要是：83,000 次下載之所以發生，是因為人們想要一份操作指南，而這個頁面正是那份指南。從 repo 根目錄開始，在 LM Studio 中載入 4-bit 版本，只有在你清楚自己用什麼換取品質時，才離開預設建置。如果你來自 GGUF 或 FP8 那一邊，相關指南涵蓋了那些路徑 — 這裡的決策框架相同，但量化數學不同。

這不是此模型的另一個建置——Qwen3.8-Flash-Next-Uncensored 是獨立發行版：由 Qwen3.8-Flash-Next（Qwen4 架構的 176B 儲存 / 6B 活躍混合專家（MoE）預覽版）去審查化（abliterated）而來。相同的去審查技術，不同的權重，自有其集合。

所有六種 27B 版本 — BF16、GGUF、MLX、FP8、INT8 和 NVFP4 — 皆收錄於Qwen3.8-27B-Uncensored 合集（Hugging Face 上）。

這些權重設計上僅限本機使用。為了有個可供 abliterated 版本對照的託管基準，Qwen3.8-27B以提供者列表價格（0% 加價）在 OrcaRouter 上提供——即原始模型，安全對齊保持完整。