私は、32GBのRAMを搭載したM2のMacbook Proで、Qwen3.6-35B-A3B-UD-Q4_K_M を動かしています。llama.cpp と opencode はかなり新しめのビルドを使っています。
メモリ枯渇によって llama-server が完全にクラッシュしてしまうのを避けるため、コンテキストウィンドウを 32768 トークンに設定しなければなりません。これは重要だと分かりました。
一応それなりのテストとして、opencode に、Claude Code が以前 Opus 4.7 で完了できていたタスクを与えました。プロジェクト自体は大きくありませんが、タスクはアプリケーションのフロントエンドとバックエンドの両方を掘り下げ、私にも（そして私はAI以前の元の開発者でした）どこが問題なのかパッと見では分からなかった不具合を突き止める、という内容です。
結果は本当にそそられます。つまり、バグの本質をちゃんと把握できているのが見て取れます。ですが、実装へ進む前に、圧縮（compaction）によっていつも必要以上に多くの情報が捨てられてしまうようです。
サブエージェントの使用を無効にすると、だいたい最初の圧縮パスではタスクをある程度保ったまま生き残ります。これは、コンテキストを2つ分支払うのではなく、1つ分の支払いで済むからです。
しかし、2回目の圧縮パスに入ると、ほぼ確実に正気を失います。要約は結局のところ私の元のプロンプトになってしまい、さらに現在の作業ディレクトリ名まで誤って覚えて（！）、もちろん存在しない、その変種を作り出します。その後は実質的にゲームオーバーです。
Qwen がRAM要件の点で多くのモデルより実際には優れているらしいこと、そして多くの小規模モデルは本格的にコーディングをこなせないらしいことをいろいろ読んだ結果、私は（1）十分に賢いモデルでやりくりできるコンテキストの最大が 32768 で、それでも（2）それでは足りない、という結論に至りました。このゲームをやるなら、もっと強力な環境が必要です。
誰かが これら、あるいは非常に似た制約のもとで もっと良い結果を得られた人はいますか？
（免責事項：私は Qwen や Mac や OpenCode を嫌っているわけではありません。こうしたものが、そもそも私のMacで動いているのが驚異的です。ただ、実際の役に立つ点で、もう少しだけ有用になってくれるのを見てみたいです。）
ありがとうございます！
編集：
以下が私の設定です。
私の qwen-server のエイリアス：
alias qwen-server='llama-server -m ~/models/unsloth/Qwen3.6-35B-A3B-UD-Q4_K_M.gguf -c 32768 -ngl 99 --host 0.0.0.0 --port 8080' 私の opencode の設定：
{ "$schema": "https://opencode.ai/config.json", "tools": { "task": false }, "provider": { "llama.cpp": { "npm": "@ai-sdk/openai-compatible", "name": "llama-server (local)", "options": { "baseURL": "http://127.0.0.1:8080/v1" }, "models": { "Qwen3.6-35B-A3B-UD-Q4_K_M": { "name": "Qwen3.6-35B-A3B-UD-Q4_K_M" } } } } } M2 Macbook Pro、RAM 32GB。
編集：
Claude が指摘してくれたのですが、このモデルの公式モデルカードには「このモデルには、デフォルトのコンテキスト長として 262,144 トークンが設定されている。OOM（Out of Memory）エラーに遭遇した場合は、コンテキストウィンドウを小さくすることを検討してほしい。しかし、Qwen3.6 は複雑なタスクのために拡張コンテキストを活用するため、思考能力を維持するには少なくとも 128K トークンのコンテキスト長を保つことを推奨する。」と書かれているそうです。
なので、ラベルに「この高さじゃないと乗れない」って書いてある、まさにその通りです。たぶんこれが答えなんでしょう。
（私は -ctk q8_0 -ctv q8_0 で k:v キャッシュの量子化も試しましたが、これはすぐに opencode が現在のディレクトリ名を正確に覚えられなくなるという形で結果が出ました。正直なところ、最初からスペルを間違え始めます）
[link] [comments]
