Qwen3.8-27BはどのMacで動くか──GGUF量子化ファイルの実サイズから積算した

Qwenの最上位モデル「Qwen3.8-Max」（2.4兆パラメータ）は個人のマシンで動かせる規模ではないが、同じQwen3.8世代には27Bパラメータの高密度モデル「Qwen3.8-27B」も存在する。こちらは「持ち帰って自分のMacで動かす」現実的な選択肢に入ってくるサイズだ。本稿はHugging Face上の公式モデルカードとGGUF量子化ファイルの実サイズを一次で確認し、Macで動かす際の目安を積算する。

3行まとめ

1. Qwen3.8-27Bは2026年8月5日公開の27Bパラメータ・高密度（MoEではない）ビジョン言語モデルで、ネイティブに262,144トークン、RoPEスケーリングで最大1,000,000トークンまでのコンテキストに対応する。ライセンスはApache 2.0
2. GGUF量子化版（unsloth配布）は最小6.19GB（IQ1_S）から最大31.46GB（Q8_K_XL）まで24ファイルが公開されている。実用的な品質とされることが多いQ4_K_Mは16.46GB、Q6_Kは21.98GB
3. 「Macで何GB必要か」という公式のガイドはQwen・unsloth双方のモデルカードに見当たらなかった。本稿末尾の対応表は、公開ファイルサイズにmacOS本体の消費分・コンテキスト用メモリを加味した、独自の積算である

Qwen3.8-27Bとは何か

Hugging Face公式モデルカードによれば、Qwen3.8-27Bは「Qwen3.5のアーキテクチャを基盤に、コーディング・専門的な業務・研究・長期にわたるエージェント的タスクで大幅な性能向上を実現した」とされるQwen3.8世代の一角で、「コンパクトでデプロイしやすい高密度（dense）モデル」と位置づけられている。画像・動画を理解するネイティブなビジョン言語モデルであり、思考の切り替え（thinking control）にも対応するという。

パラメータ数は27B。MoE（Mixture of Experts）ではなく、全パラメータが常時使われる高密度モデルである点は、前述のQwen3.8-Max（2.4兆パラメータ・アクティブ950億のMoE）とは構造が異なる。

コンテキスト長は「ネイティブに262,144トークン、RoPEスケーリング技術（YaRNなど）を使えば最大1,000,000トークンまで拡張可能」と明記されている。

GGUF量子化ファイルの実サイズ（2026年8月27日確認）

Hugging Face上のunsloth/Qwen3.8-27B-GGUFリポジトリには、量子化レベル別に24種類のGGUFファイル（量子化モデル本体。ほかにmmproj×2・imatrix×1が別途公開されている）が公開されている。ファイルツリーAPIで実際のバイト数を確認したところ、代表的なものは次の通りだった（値は実ファイルサイズを10進数換算＝1GB=10^9バイトでGBに変換したもの。2進数（1GiB=2^30バイト）換算だとこれより約7.4%小さい値になる）。

一般に量子化レベルが低い（ビット数が少ない）ほどファイルは小さく動作は軽くなるが、出力品質の劣化リスクが高まる。IQ1_S・IQ2系は極端に低ビットな量子化で、実用品質を保てるかどうかはモデル・タスクによって差が大きいとされる。ローカルLLMコミュニティでは、Q4_K_M〜Q6_K程度が「品質と軽さのバランスが取れた実用ライン」として選ばれる傾向がある（この評価軸自体はコミュニティの経験則であり、Qwen・unsloth公式が定めた基準ではない）。

MLX形式の量子化版も、コミュニティから複数公開されている

GGUFはllama.cppなど汎用の推論エンジンで使われる形式だが、Apple SiliconのGPU・Neural Engineに最適化された「MLX」というApple製フレームワーク向けの形式も、Qwen3.8-27Bには存在する。Hugging Face APIで検索すると、mlx-community・lmstudio-communityなど複数のコミュニティアカウントから、4bit・6bit・8bitなど様々な量子化レベルのMLX版が公開されていることを確認した。ただしQwen公式（Qwenアカウント）自身がMLX版を配布しているわけではなく、あくまでコミュニティによる変換版である。

代表的な2つのファイルサイズを、Hugging Face APIで実際に集計すると次のようになった。

同じビット数であれば、MLXとGGUFのファイルサイズはかなり近い水準になる。どちらの形式が実際に速く動くか（Apple Silicon上での実効速度の差）は、この記事では検証していない。

なお、Qwen公式（Qwenアカウント）自身は、GGUF・MLXではなく「FP8」という別の量子化形式を公式に配布している。Qwen/Qwen3.8-27B-FP8のファイルサイズをHugging Face APIで確認すると、実測30.87GBだった。これはGGUFのQ8_0（29.05GB）・MLXの8bit版（29.50GB）と近い、8bit相当のサイズ感になる。

Macで動かす場合の目安（独自の積算・非公式）

Apple・Qwen・unsloth、いずれの公式ドキュメントにも「Macで動かすには何GBの統合メモリが必要か」という具体的な指針は見当たらなかった。そこで本稿では、確認できたファイルサイズをもとに、次の前提で目安を積算する。

• モデルの重み（GGUFファイルサイズ）をそのままメモリに載せる必要がある
• macOS本体・バックグラウンドアプリで一定のメモリが消費される
• 会話の文脈を保持する「KVキャッシュ」も、コンテキスト長に応じて別途メモリを消費する（長いコンテキストを使うほど増える）

これらを踏まえた大まかな対応関係は次の通りになる（あくまで目安であり、実測ではない）。

262,144トークンのネイティブ上限まで使い切るような長文処理をさせる場合は、上記の目安よりもさらに大きな統合メモリが必要になる可能性が高い。短い質問応答中心であれば、表より小さいメモリでも動く可能性はある。

実際にMac上で動作を検証したわけではない

• 上記の「動かせる可能性がある量子化レベルの目安」は、公式のベンチマークや実測データに基づくものではなく、ファイルサイズからの単純な積算に基づく本稿独自の推測である。実際にMac上で動作を検証したわけではない
• KVキャッシュの消費量はコンテキスト長・バッチサイズ・実装（llama.cpp／MLXなど）によって変わり、本稿では具体的な計算式までは示していない
• MLX形式の量子化版が存在すること自体とファイルサイズはHugging Face APIで確認したが、GGUF版との実効速度の差（同じMacで同じプロンプトを流したときのトークン/秒の違いなど）は、この記事では検証していない
• MLX版の配布元はmlx-community・lmstudio-communityなど複数あり、この記事で確認したのはmlx-communityが配布する4bit・8bit版の2つのみ。他の配布元・他の量子化レベルまでは網羅的に確認していない
• Qwen3.8-27Bの実際の生成品質・ベンチマークスコールは、本稿では扱っていない（モデルの性能評価は既存記事「Qwen3.8-Max」の解説を参照）

関連記事

• Alibabaが最上位「Qwen3.8-Max」を発表──2.4兆パラメータの重みを来週公開。ベンチ86行を全部数えた
• Mac Studio 1台か、Mac mini 3台の分散推論か
• Macの統合メモリではこの技がそもそも要らない理由
• ローカルLLM おすすめモデル【2026年】