ローカルLLM：openclawでvllm-mlxを使うはなし
この記事は人間が書いてる。
最近ローカルLLMとopenclawで遊んでるんですよ。なんというか、ちょっと賢いたまごっちみたいな感じ
今つかっているモデルについて
で、作業させようとするとqwen3.6-35b-a3bあたりがちゃんとやってくれる。最初はGemma4の２７B(MoE)使ってたんですけど、サボり癖が治らないのでこっちにしたらちゃんと働いてくれる。
gemini4については、タスク完遂能力がかなり低く、適当にお茶を濁す傾向があるのですが、qwenはタイムアウトまでずっと試行を繰り返してくれます。あと、ツールちゃんと使ってくれる
qwen3.6-35b-a3bを使う時の問題点
ただ、長時間ぶん回すと途中からGPUに処理が流れなくなってCPUで処理しだすんですよ。
どうやらollama側の既知のバグらしいので何とかなんねぇかなって思ってたら、vllm-mlxなるものを見つけました。Appleシリコンに最適化してあって、AIによって書かれたクソ記事によると性能がびっくりするほど上がるとかなんとか
というわけで無理やりopenclawに接続しちゃいましょうね～
環境
M5 Macbook air 32GBユニファイドメモリ
ヤッテイキ
git clone https://github.com/waybarrios/vllm-mlx.git
cd ./vllm-mlx
brew install python@3.13
python3.13 -m venv .venv
source .venv/bin/activate
pip3.13 install -e .
vllm-mlx serve mlx-community/Qwen3.6-35b-a3b-optiq-4bit --port 8000 --continuous-batching --api-key てきとうなキー
openclaw configure
あとはウィザード形式で勝手にやってくれる
local
model
vllm
APIキーは自分で設定したやつ入力する。いやちゃんとした手順とかあるかもしれん
結果
最初の会話３回くらいまではollamaよりちょい早くらいで推移するんですけど、すぐpythonエラーでクラッシュすることが発覚
色々設定をかえてみたものの、ダメでした…
現状では、ollamaでqwen3.6:35b-a3b-nvfp4が最適なようです。（遅すぎてだめかも
で、とりあえずchromeを２つ開くのをやめてopenclawの自動操作用だけにしたらなんか安定しました。
メモリ不足でCPU、GPU混合運用に切り替わるっぽいです。なお、サーマルスロットリングでGPUマックスで使いきれないっぽいです。うへぇ
また、タイムアウト周りに重大なバグがあり、agent.default.timeoutSecondを設定してしまうとollamaサーバとの接続を１分で切断する謎の挙動が発生する。
タイムアウトを設定しなければ６分持つっぽいが長い推論で落ちる。
→AGENTS.ｍｄに定期的に報告するよう指示したらなんか解決したっぽい。
メモ：openclawで試したモデルの感想
gemma4:26b-mlx
ギリギリ動くがツールを立ち上げられず、browser automationができない。
作業も途中ですっぽかすので、定期的に「どうなった？」と聞く必要がある。
ファイル書き換えが苦手でほとんど何もできない
ただし、SOUL.mdのキャラ付けだけは愚直に守る。指示を守ってくれ頼む
gemma4:9b
mlxではないやつ最初にいれちゃった
何ならできるんだ？おしゃべりとか？あんまり使えない
qwen3.6:35b-a3b-nvfp4
大抵のことは実行できるしちゃんと終わるまでやるが、当該スペックのMacbookだとちょっとしんどい。
コンテキストサイズが40k超えたあたりからタイムアウトするようになる。
もうちょっとメモリあれば余裕で使えそうなのでMacbookPro欲しくなる。
反応はめちゃくちゃ遅い
qwen3.5:9b-mlx
ちょっとアホだけどちゃんとタスクを完遂しようと試みるので使える
ツール系の操作が若干怪しいものの、まだなんとかなりそう
反応はまあまあ遅いがなんとかなる
いまのところこれが一番安定してる気がする
Ornith1.0：９ｂ
qwen3.5とかを元にタスク遂行能力を上げたって触れ込みなのですが…
ツール類の起動に難があるのでダメでした