Qwen3.5 27BでローカルにClaude Codeを動かす

Reddit r/LocalLLaMA / 2026/4/5

💬 オピニオンDeveloper Stack & InfrastructureTools & Practical UsageModels & Research

共有:

要点

この記事は、Arch Linux（Strix Haloハードウェア）上で、llama.cpp経由によりローカルホストしたQwen3.5 27Bモデルを用いて、Claude Codeを完全オフラインで実行するためのセットアップを解説しています。
テレメトリ、自動アップデータ、不要な通信を無効化するための環境変数の設定を提示しつつ、シェルでのexportに頼るよりも `claude/settings.json` を使うほうが安定していると述べています。
著者が、コンテキストサイズ（ctx-size 65536）、GPU層のオフロード（n-gpu-layers 999）、ROCmのチューニング（ROCBLAS_USE_HIPBLASLT=1）、推論時のサンプリングパラメータを含む具体的なllama.cppの起動コマンドを共有しています。
7回の実行結果として、タスク種別（単純なファイル操作、git clone＋コード読み取り、計画）ごとに性能と出力品質を比較する表が示されており、概ね正確／優秀な結果で、高いトークン生成速度が確認できます。
ワークフローは、Claude Codeとllama.cppのパラメータを時間をかけて改善するための反復的な「セッション」単位で構成されており、信頼性の高いツール連携やコーディングタスクの性能を目指しています。

長い調査の末、
OpenCodeでローカルLLMを llama.cpp を使って利用する
ことで、コーディング作業に完全にローカルな環境を使えるようにできる最良の代替方法を探していたところ、Claude Code CLI をローカルの llama.cpp サーバーに接続する方法
そして、テレメトリを無効化して Claude Code を完全にオフラインにする方法が書かれたこの記事を見つけました。

使用モデル - Qwen3.5 27B
使用量子化 - unsloth/UD-Q4_K_XL
推論エンジン - llama.cpp
OS - Arch Linux
ハードウェア - Strix Halo

私のセットアップは、CC（Claude Code）と llama.cpp モデルパラメータをどのように改善できたかという反復サイクルを回すために、セッションごとに分けました。

First Session

ガイドに書かれていた通り、テレメトリを無効にするためにオプション1を使いました。

~/.bashrc の設定；

export ANTHROPIC_BASE_URL="http://127.0.0.1:8001" export ANTHROPIC_API_KEY="not-set" export ANTHROPIC_AUTH_TOKEN="not-set" export CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 export CLAUDE_CODE_ENABLE_TELEMETRY=0 export DISABLE_AUTOUPDATER=1 export DISABLE_TELEMETRY=1 export CLAUDE_CODE_DISABLE_1M_CONTEXT=1 export CLAUDE_CODE_MAX_OUTPUT_TOKENS=4096 export CLAUDE_CODE_AUTO_COMPACT_WINDOW=32768

ネタバレ：claude/settings.json を使うほうが良いです。より安定していて制御もしやすいです。

さらに ~/.claude.json で

"hasCompletedOnboarding": true

llama.cpp の設定：

ROCBLAS_USE_HIPBLASLT=1 ./build/bin/llama-server 
 --model models/Qwen3.5-27B-Q4_K_M.gguf \
 --alias "qwen3.5-27b" \
 --port 8001 --ctx-size 65536 --n-gpu-layers 999 \
 --flash-attn on --jinja --threads 8 \
 --temp 0.6 --top-p 0.95 --top-k 20 --min-p 0.00 \
 --cache-type-k q8_0 --cache-type-v q8_0

私は Strix Halo を使用しているので、ROCBLAS_USE_HIPBLASLT=1 を設定する必要があります。
llama.cpp のセットアップを具体的なハードウェアに最適化するために調査してください。
その他は同じかもしれません。

7 回の実行結果：

Run	Task Type	Duration	Gen Speed	Peak Context	Quality	Key Finding
1	ファイル操作（ls、cat）	1m44s	9.71 t/s	23K	正確	ベースライン：低いコンテキストでは速い
2	Git clone + コード読み取り	2m31s	9.56 t/s	32.5K	非常に良い	ツール連携がうまく機能する
3	7日間の計画 + ガイド	4m57s	8.37 t/s	37.9K	非常に良い	長文生成の品質
4	スキル評価	4m36s	8.46 t/s	40K	とても良い	Web検索が壊れている（Anthropic が必要）
5	Python スクリプトを書く	10m25s	7.54 t/s	60.4K	良い（7/10）
6	コードレビュー + 修正	9m29s	7.42 t/s	65,535 CRASH	とても良い（8.5/10）	コンテキスト壁に到達、auto-compact なし
7	/compact コマンド	~10m	~8.07 t/s	66,680（失敗）	N/A	コンパクション用の出力トークン上限が低すぎる

学び

生成速度はコンテキスト範囲全体で約24%低下：9.71 t/s（23K）から 7.42 t/s（65K）
Claude Code のシステムプロンプト = 22,870 トークン（65K の予算の35%）
自動コンパクションが完全に壊れていた：Claude Code は 200K のコンテキストを想定していたため、95% 閾値 = 190K。65K の上限に到達したのは、Claude Code が想定していたウィンドウの 33% の時点でした。
/compact には出力ヘッドルームが必要：最大出力が 4096 の場合、コンパクション要約を収められません。16K+ が必要です。
Anthropic なしでは Web 検索は死んでいる（Run 4）：解決策は SearXNG を MCP 経由で使う、またはもっと良い解決策があるなら提案してほしいです。
LCP プレフィックスキャッシュは素晴らしく機能する：sim_best = 0.980 は、システムプロンプトがターン間でキャッシュされることを意味します。
コード品質はしっかりしているが指示には精密さが必要：修正案を出すために2人目の査読（レビュー）エージェントを追加する予定です。

消費 VRAM - 22GB
消費 RAM（CC による）- 7GB（CCはかなり重い）

Second Session

claude/settings.json の設定：

{ "env": { "ANTHROPIC_BASE_URL": "http://127.0.0.1:8001", "ANTHROPIC_MODEL": "qwen3.5-27b", "ANTHROPIC_SMALL_FAST_MODEL": "qwen3.5-27b", "ANTHROPIC_API_KEY": "sk-no-key-required", "ANTHROPIC_AUTH_TOKEN": "", "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1", "DISABLE_COST_WARNINGS": "1", "CLAUDE_CODE_ATTRIBUTION_HEADER": "0", "CLAUDE_CODE_DISABLE_1M_CONTEXT": "1", "CLAUDE_CODE_MAX_OUTPUT_TOKENS": "32768", "CLAUDE_CODE_AUTO_COMPACT_WINDOW": "65536", "CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "90", "DISABLE_PROMPT_CACHING": "1", "CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS": "1", "CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING": "1", "MAX_THINKING_TOKENS": "0", "CLAUDE_CODE_DISABLE_FAST_MODE": "1", "DISABLE_INTERLEAVED_THINKING": "1", "CLAUDE_CODE_MAX_RETRIES": "3", "CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY": "1", "DISABLE_TELEMETRY": "1", "CLAUDE_CODE_MAX_TOOL_USE_CONCURRENCY": "1", "ENABLE_TOOL_SEARCH": "auto", "DISABLE_AUTOUPDATER": "1", "DISABLE_ERROR_REPORTING": "1", "DISABLE_FEEDBACK_COMMAND": "1" } }

llama.cpp の実行：

ROCBLAS_USE_HIPBLASLT=1 ./build/bin/llama-server \
 --model models/Qwen3.5-27B-GGUF/Qwen3.5-27B-UD-Q4_K_XL.gguf \
 --alias "qwen3.5-27b" \
 --port 8001 \
 --ctx-size 65536 \
 --n-gpu-layers 999 \
 --flash-attn on \
 --jinja \
 --threads 8 \
 --temp 0.6 \
 --top-p 0.95 \
 --top-k 20 \
 --min-p 0.00 \
 --cache-type-k q8_0 \
 --cache-type-v q8_0

claude --model qwen3.5-27b --verbose

消費 VRAM - 22GB
消費 RAM（CC による）- 7GB
何も変わっていません。

最初のセッションで出たエラーはすべて修正されました）

Third Session（Vision）

qwen で vision を有効にするには、gguf に含まれていた mmproj を使う必要があります。

セットアップ：

ROCBLAS_USE_HIPBLASLT=1 ./build/bin/llama-server \ --model models/Qwen3.5-27B-GGUF/Qwen3.5-27B-UD-Q4_K_XL.gguf \ --alias "qwen3.5-27b" \ --port 8001 \ --ctx-size 65536 \ --n-gpu-layers 999 \ --flash-attn on \ --jinja \ --threads 8 \ --temp 0.6 \ --top-p 0.95 \ --top-k 20 \ --min-p 0.00 \ --cache-type-k q8_0 \ --cache-type-v q8_0 \ --mmproj models/Qwen3.5-27B-GGUF/mmproj-F32.gguf

そして、追加されたRAM使用量はたった1〜2です。

8枚の画像でテストしましたが、視覚品質が私にとっては「WOW」でした。
Artificial AnalysisのVision Benchmarkを見ると、qwenは[Claude 4.6 Opus](Claude 4.6 Opus)レベルにあり、視覚タスクにおいて優れていることがわかります。

私のテストでは、画像の文脈や手書きの図解を本当にうまく理解できることが示されました。

結論（Verdict）

システムプロンプトが大きすぎて、読み込みに時間がかかります。ですが、これは最初だけで、その後はキャッシュによってすべてがうまくいきます。
CCはローカルモデルと一緒に使う価値がありますし、最近のローカルモデルはコーディング用途でも優秀です。そして私は[Opencode](Opencode)と比べて、より「オフライン」なコーディングエージェントCLIだと感じました。SOTAを使えるのに、なぜより「高性能（performant）」な代替手段を減らして使う必要があるのでしょうか？）

今後の実験:
- [Qwen3.5](Qwen3.5)ファミリーのより大きい[Mixture of Experts](Mixture of Experts)モデルを使いたいのですが、2倍のサイズで2倍のパフォーマンスが得られるのでしょうか？
- [Zed](Zed)エディタでCCを試してみて、ローカルのCCでオフラインのZedがどのように振る舞うか確認したいです。
- コンパクションがエージェントの推論をどれくらい維持でき、品質はどの程度劣化するのか？ codexまたはCCでは、サイズに対して見合う程度に質の高い状態で、10Mコンテキストのチャットができました。

提出者 /u/FeiX7
[リンク] [コメント]