Qwen3.8-27Bは、ローカルのコーディングエージェントに使える27Bクラスとしてかなり有力です。ただし、現時点で「最強」と断定するのは早すぎます。
エージェント型コーディングでは、モデルをロードしてコードを一度生成できるだけでは足りません。リポジトリの指示を読み、適切なツールを呼び、複数ファイルを編集し、テスト失敗から修正し、レビュー可能な差分まで到達して初めて仕事が完了します。判断すべきなのは、自分の量子化・ハードウェア・runtime・agent harnessの組み合わせで、受け入れタスクを安定して終えられるかです。
先に結論：メモリ容量ごとの現実的な位置づけ
| 利用可能なメモリ | 最初の判断 | 注意点 |
|---|---|---|
| 24GB級VRAM / unified memory | Q4_K_Mでテキスト中心の限定テスト | ロードできても64K contextまでGPU常駐できるとは限らない |
| 32〜48GB | Q4で実用的な余白を確認しやすい | Q8や長いcontextは、実測したprocessor splitで判断する |
| 48GB以上 | 64K以上のagent loopが現実的になる | native 262Kを常用する必要はなく、KV cacheはさらに大きくなる |
| CPU offloadが重い | 小型モデルまたはhybrid routeを優先 | 多段のツール実行では少しの遅さが積み上がる |
24GB環境なら「動くか」ではなく、リポジトリ情報を読み込んだ後の速度と残りメモリを見ます。32GB以上なら候補として扱いやすくなりますが、ビルドやテストが同じマシンで走るなら、その分も空けておかなければなりません。
モデルカードから分かる強みと、分からないこと
Qwenの公式モデルカードによると、Qwen3.8-27BはApache-2.0の27B dense causal language modelで、vision encoderを備え、画像と動画も扱えます。thinkingはデフォルトで有効で、reasoning_effortとpreserve_thinkingに対応します。native contextは262,144 tokens、YaRNによる1,000,000 tokensへの拡張も用意されています。
コーディング系では、QwenがTerminal-Bench 2.1で73.0、SWE-bench Proで61.7、NL2Repo-Benchで42.3、DeepSWE 1.1で42.2、QwenSWEBenchで79.0と報告しています。27Bモデルを評価対象に入れる十分な根拠ですが、ローカルGGUFでの独立実測ではありません。benchmarkごとのharness、context、temperature、修正されたtask、in-house datasetといった条件が違うため、別モデルとの単純な横並びには使えません。
また、Qwen3.8世代の紹介で示されたMaxの自律実行デモを27Bへそのまま当てはめてはいけません。27Bで確認できるのはモデルカードの仕様と公開ファイルであり、Maxと同じ規模や成功率ではありません。
18.97GBのQ4ファイルは必要メモリではない
ggml-orgのGGUFでは、現在のファイルサイズは次の通りです。
Qwen3.8-27B-Q4_K_M.gguf：約18.97GBQwen3.8-27B-Q8_0.gguf：約28.60GB- BF16 vision projector：約0.93GB
これらはディスク上のファイルであり、プロセス全体のメモリではありません。実行時にはweightsに加えてKV cache、runtime buffer、OS、coding agent、リポジトリindex、コンパイラやtest runnerが同居します。contextを長くすればKV cacheも増えます。
Ollamaのcontext lengthガイドは、agentやcoding toolには少なくとも64Kを推奨する一方、contextの増加はメモリ消費を増やすと明記しています。自動設定は24GB未満で4K、24〜48GiBで32K、48GiB以上で256Kです。つまり24GBのGPUでQ4がロードできても、agent用途に欲しい64Kが自動で確保されるわけではありません。
確認時はollama psで実際のCONTEXTとPROCESSORを見ます。CPU offloadが増えているなら、短いchatでは気にならなくても、tool callを何度も繰り返す仕事ではwall timeが膨らみます。
まずテキスト専用の最小構成で動かす
ggml-orgは、現行llama.cpp向けに短い起動経路を公開しています。
bashllama serve -hf ggml-org/Qwen3.8-27B-GGUF
Qwen3.8-27Bは2026年8月14日に公開されたばかりなので、llama.cppは新しいbuildを使います。古いchat templateや未対応のthinking処理を、モデル能力の問題と誤認しないためです。
Ollamaでは公式のGGUF import手順に沿ってModelfileを作れます。
textFROM ./Qwen3.8-27B-Q4_K_M.gguf PARAMETER num_ctx 65536 PARAMETER temperature 1 PARAMETER top_p 0.95 PARAMETER top_k 20
bashollama create qwen3.8-27b-local -f ./Modelfile ollama run qwen3.8-27b-local ollama ps
coding agentを接続するなら、Qwen Codeのprovider設定はOllama、LM Studio、vLLMのOpenAI-compatible endpointをサポートしています。Ollamaではhttp://your-ollama-host:11434/v1を 使い、your-ollama-hostをagent processから解決できる実際のhost名へ置き換えます。model idもlocal serverが公開している名前と一致させます。
ツール呼び出しが壊れた場合は、モデルを即座に切り捨てる前にruntime version、chat template、context truncation、API schemaを確認します。それでも固定条件でtool nameやargumentsが崩れ続けるなら、無人運転ではNo-Goです。
8〜12個の受け入れタスクで比較する
派手なone-shot demoではなく、自分たちが正解をレビューできる小さな仕事を使います。たとえば、単純なbugfix、複数ファイルの変更、失敗したtestからの回復、リポジトリ固有ルールへの対応、もっともらしい実装を拒否すべきケースです。
各タスクで次を記録します。
| 記録項目 | 合否に使う内容 |
|---|---|
| accepted completion | 差分がreview基準を満たし、関連testが通るか |
| tool-call validity | tool名、構造、argumentsが正しいか |
| retry | 再起動、同じ呼び出し、新しいpromptの回数 |
| human repair | 人が加えた修正とsteering |
| wall time | 開始から受け入れまでの総時間 |
| peak resources | VRAM/unified memory、offload、context、build負荷 |
比較時はquantization、runtime、context、agent harness、task setを揃えます。最も重要なのはraw tokens per secondではなく、受け入れられた一件あたりの機械時間と人手修正です。少し遅くても正確なtool callで終わるモデルは、三回やり直す高速モデルより安くなります。
Qwen3.8-27Bを採用する条件
32GB以上の利用可能メモリがあり、ローカルデータを外へ出したくなく、最新runtimeを追えるなら、Qwen3.8-27Bは優先的に試す価値があります。24GBではQ4・短いtext-only task・制限したcontextから始め、結果をconditional Goとして扱うのが安全です。
重いCPU offloadが必要、巨大monorepoで長いcontextが常態化する、またはunattended successが最優先なら、唯一のcoding modelには向きません。その場合は、小型ローカルworkerに定型変更を任せ、難しいtaskだけ強いhosted modelへ送るhybrid routeの方が、受け入れ作業を増やせます。
Qwen3.8-27Bがあなたにとって最適かどうかは、モデル名や公開直後のscoreでは決まりません。同じリポジトリタスクを、許容できるメモリ・時間・人手で、繰り返しreview可能な変更へ変えられるか。それが最終的な判断材料です。
