Article
GX10上のQwenをOpenClawのLLMバックエンドにしようとして、最後はTelegram配送にハマった
前回は、Mac Studio上のGemma 4とGX10上のQwenを直接APIで比べた。結果だけ見ると、GX10 Qwenはかなり速かった。
そうなると次にやりたくなるのは、実際にOpenClawのバックエンドにすることだ。自分がローカルLLMを使いたい場面は、単発のベンチマークではなく、OpenClawやAtlasのような日常の道具の中に入っている。
ただ、ここで分かったのは、モデルに届くことと、Telegram上のOpenClawエージェントとして自然に返事が見えることは別物だ、ということだった。
やりたかった構成
目標はかなりシンプルだった。
Telegram / OpenClaw
-> OpenClaw Gateway
-> OpenAI-compatible API
-> GX10上のQwen
OpenClawは別のMac miniで動いている。GX10はローカルAI専用機として置いている。なので、OpenClaw側からTailnet経由でGX10上のQwenを叩けるようにしたかった。
これが動くと、Mac Studioに載せているGemma 4に頼らず、OpenClawやAtlasのLLM負荷をGX10側に逃がせる。GX10を買った理由のかなり大きな部分がここにある。
まずQwenをOpenAI互換APIとして出す
この時点で試していたのは、Qwen系のGGUFモデルを llama.cpp CUDA serverで出す経路だった。
公開用にパスや実ホスト名を伏せると、起動はだいたい次のような形になる。
llama-server \
-m <model-path>/Qwen3.6-35B-A3B-UD-Q4_K_M.gguf \
--alias qwen3.6-35b-a3b,gx10-qwen \
--host <gx10-tailnet-ip> \
--port 18081 \
-ngl 999 \
-c 262144 \
--jinja \
--reasoning off \
-fa on \
--parallel 1
最初は64K contextで起動していた。しかし、OpenClawの実セッションではシステムプロンプト、ツール定義、履歴がまとめて乗る。単発チャットのつもりで見積もると、すぐ足りなくなる。
実際に64Kでは次のようなエラーに当たった。
request (65555 tokens) exceeds the available context size (65536 tokens), try increasing it
そこでQwenサーバ側のcontextを増やし、OpenClaw側のモデル設定も広げた。最終的には、モデル側で見えていた余裕に合わせて 262144 まで上げている。
ここでの学びは単純で、OpenClawのようなエージェント環境では「モデルが64K対応」と言っても安心できない。実際に投げるプロンプトは、普通のチャットUIよりずっと重い。
Gateway経由のmodel.runは通った
ネットワーク経路は、Tailnet経由でOpenClawホストからGX10へ向ける形にした。
OpenClaw host
-> http://<gx10-tailnet-ip>:18081/v1
-> GX10 llama.cpp Qwen server
この状態で、OpenClaw Gateway経由の安全なモデル実行は通った。
{
"ok": true,
"capability": "model.run",
"transport": "gateway",
"provider": "gx10",
"model": "gx10-qwen",
"outputs": [
{
"text": "OK"
}
]
}
つまり、Mac miniからOpenClaw Gatewayを通してGX10上のQwenを呼ぶ、という下の層は動いていた。
この時点で「できた」と言いたくなる。ただ、実際にはここからが面倒だった。
Telegramグループでは返事が見えなかった
問題は、TelegramグループでOpenClawエージェントとして返答が見えるかどうかだった。
切り分けると、状況はこうだった。
| 層 | 状態 |
|---|---|
| GX10上でQwenを起動 | できた |
| OpenAI互換APIとしてモデル情報を返す | できた |
| Tailnet経由でOpenClawホストから到達 | できた |
| OpenClaw provider/model登録 | できた |
Gateway経由の model.run |
できた |
| Telegramグループで自然に返信表示 | ここでハマった |
最初は、モデルが返していないのか、OpenClawが受け取っていないのか、Telegramへ配送できていないのかが見えにくかった。
さらに良くなかったのは、実Telegramグループのセッションに短いテストプロンプトを流してしまったことだ。このとき tool_choice: required を付けていたため、モデルが OK を繰り返すような挙動になった。これは完全に検証手順のミスだった。
以後、モデル疎通はTelegram配送を伴わない model.run で確認することにした。実ユーザーの見える場所で、低レイヤーの疎通テストをするべきではない。
原因はモデル到達ではなく表示ルール側だった
その後、セッションをリセットして短いメッセージを送ると、Qwenは実際には日本語の返答文を生成していた。
ただし、OpenClaw側のグループ表示設定が次の状態だった。
{
"messages": {
"groupChat": {
"visibleReplies": "message_tool"
}
}
}
この設定では、グループに見える返答は message tool経由のものに限られる。ところが、tool_choice: required を外したQwenは普通のassistant本文を返した。つまり、返答自体はセッション内に残るが、Telegramグループには出てこない。
そこで表示設定を次のように変えた。
{
"messages": {
"groupChat": {
"visibleReplies": "automatic"
}
}
}
このあたりで、やっと「モデルに届いていない」のではなく「モデルの返し方とOpenClawの表示ルールが噛み合っていない」問題だと見えてきた。
直APIの成功とアプリとしての成功は違う
今回の一番大きい教訓はこれだ。
curlで返る
model.runで返る
OpenClawのセッションに残る
Telegramグループで見える
日常利用で期待通りに振る舞う
これらは全部違う。
ローカルLLMを単体で動かすだけなら、OpenAI互換APIの /v1/models と /v1/chat/completions が返ればかなり満足できる。だが、OpenClawの中ではモデルは単なるテキスト生成器ではない。
実際には、次のような要素が絡む。
- provider/model設定
- context windowとtoken上限
- tool callingの形式
- assistant本文を返すのか、message toolを使うのか
- Gatewayのtransport
- Telegramグループで何を表示するか
- 実セッションの履歴とリセット状態
直APIで速く返ることは重要だ。ただ、それだけではOpenClawのバックエンドとして完成したとは言えない。
この時点での判断
この段階では、GX10 Qwenにはかなり可能性を感じていた。
特に前回の比較では、Mac Studio Gemma 4よりかなり速く、基本的なtool callの小テストも通っていた。軽い対話や単純なtool選択には向いていそうだった。
一方で、実用バックエンドとしてはまだ慎重に見た方がいい。
| 観点 | この時点の見方 |
|---|---|
| 速度 | 有望 |
| 直API疎通 | 成功 |
| Gateway経由のmodel.run | 成功 |
| Telegram表示 | 設定と返答形式の切り分けが必要 |
| 長いOpenClaw文脈 | 64Kでは足りず、context拡張が必要 |
| デフォルト採用 | まだ早い |
モデルを起動して返事が出ると、つい「統合できた」と思いたくなる。しかし、今回のようにエージェント、tool、チャット配送が絡むと、成功判定を層ごとに分けないと危ない。
その後に続く話
このあと、GX10上のQwenはさらに別の経路でも試している。GGUF/llama.cppだけではなく、vLLMでHugging Faceモデルを直接出す方向にも進んだ。画像入力やtool callingの扱いも含めると、話はさらに変わる。
なので、この記事で言える結論は限定的だ。
GX10上のQwenはOpenClaw Gateway経由で呼べるところまでは来た。ただし、Telegramグループで自然に使えるかは、モデル到達とは別の表示・tool経路の問題として切り分ける必要があった。
ローカルLLM専用機の評価は、tok/sだけでは終わらない。モデル、runtime、context、tool calling、そして最後に人間が見るチャット画面まで含めて、ようやく「使える」と言える。
今回ハマったのは、まさにその最後の部分だった。
注意点
最後に、今回の話の前提をまとめておく。
- これは手元環境での実験ログであり、一般的なOpenClaw設定すべてに当てはまる話ではない。
- 公開記事ではTailnet IP、LAN IP、ホスト名、個人パス、チャットIDなどは伏せている。
model.runの成功は、Telegram配送や実アプリ利用の成功とは分けて考える必要がある。- 64K contextで足りなかったのは、OpenClawの実セッションが重かったためで、単発チャットの評価とは別。
tool_choice: requiredを実Telegramグループの疎通確認に使ったのは悪い検証手順だった。
次は、QwenとGemma 4をGX10上で載せ替えながら見えた、ローカルLLM専用機としての現実をまとめる。
