Posted:
| Tags:
ai,
codex,
gemma,
llama-server,
local-llm,
tool-calling
Gemma 4 12B Q4_K_M の GGUF を llama-server で起動し、OpenAI-compatible proxy を挟んで Codex CLI の local model として使えるかを試した。
後続では、同じ環境で Gemma 4 E4B QAT Q4_0 の軽量 backend 評価 も行った。
見たかったのは、単なる短文応答ではなく次の 3 点だった。
- Codex CLI の大きめの agent prompt を context に収められるか
- JSON-only final answer が壊れないか
- shell tool call と tool result の読み取りが成立するか
先に結論を書くと、12GB class GPU でも ctx=16384, ngl=28, --reasoning off なら短時間の JSON/tool smoke は通った。ただし、長文、温度、tool schema の増加、別の chat template ではまだ崩れる余地がある。
構成
抽象化すると構成はこうなる。
flowchart LR
Codex[Codex CLI] --> Proxy[OpenAI-compatible proxy]
Proxy --> Llama[llama-server]
Llama --> Model[Gemma 4 12B Q4_K_M GGUF]
Codex --> Tools[Codex tool executor]
今回の評価では adapter を挟まず、proxy の Responses API 変換から llama-server の Chat Completions へ流した。
Read more...Posted:
| Tags:
ai,
benchmark,
bfcl,
local-llm,
terminal-bench,
tool-calling
先に私の評価結果
- 2026年時点でNvidia 3060 12GBメモリモデルで検証
- 現状のローカルLLMは日本語はかなりのものを返すようになった( 1bit LLMでも割と正しいものを返す )
- ただし tool search , tool use の機能の正確さはまだ良くない( 結構な頻度で失敗する )
- ローカルLLMへの期待としては 1bit LLM かつ tool search 機能を最初から学習したモデルが待たれる
ローカルLLM AdapterをBFCLとTerminal-Benchで評価する計画
ローカル LLM の評価では、model 単体の一般能力と、adapter を含む tool calling 経路の品質を混ぜない方がよい。
今回測りたいのは、Hermes 3 Llama 3.1 8B の総合知能ではなく、Hermes adapter が Codex CLI 互換の tool call をどれだけ安定して成立させるか。
そのため、評価対象を次の 3 層に分ける。
| 層 | 評価したいもの |
|---|
| adapter-native | parser、tool routing、warning filter、output relay、suppression |
| proxy / CLI | OpenAI-compatible proxy、Responses 変換、Codex CLI JSONL |
| terminal task | terminal agent としての最終タスク達成 |
BFCLとTerminal-Benchの位置づけ
BFCL は function calling の評価に近い。adapter の tool schema 変換、arguments、tool name、malformed recovery を見るには相性がよい。
Read more...Posted:
| Tags:
ai,
codex,
local-llm,
tool-calling,
troubleshooting
ローカル LLM と tool calling adapter を組み合わせると、失敗原因が複数の層に分かれる。
最終応答だけを見ると「model が間違えた」に見えるが、実際には次のような層のどこかで起きていることが多い。
- model context / VRAM
- Hermes prompt / parser
- tool pruning / router
- OpenAI-compatible proxy
- CLI の tool execution
- shell sandbox
- internal web tool
- external research helper
- benchmark harness
このメモでは、公開してもよい抽象度でトラブルの傾向を整理する。実 port、実 path、token 名、host 名、生ログは private runbook 側に残す。
全体の切り分け
flowchart TD
Final[final answer] --> A{tool call eventは出たか}
A -->|no| Router[adapter router / model tool selection]
A -->|yes| B{tool executorは動いたか}
B -->|no| Proxy[proxy / schema / unknown tool]
B -->|yes| C{tool outputは正しいか}
C -->|no| Sandbox[sandbox / command / environment warning]
C -->|yes| D{finalが正しいか}
D -->|no| Relay[output relay / model summarization]
D -->|yes| Done[pass]
まず見るべきなのは final answer ではなく、tool call event と tool result 。
Read more...Posted:
| Tags:
ai,
codex,
hermes,
local-llm,
tool-calling
なぜこのアプローチを試しているのか
- ローカルLLM、日本語は結構返してくれるようになった
- tool searchの段階で結構あやしい
- ローカルLLMの性能に期待せずに、途中でインターセプトしてcodexなどから使えないか?と考えた
- 2026年時点ではまだうまくできてない(かなりのユースケースに対応するコードが必要そう)
小型のローカル LLM を coding agent や terminal helper に使う場合、通常の chat 品質よりも tool call の安定性が先に問題になる。
特に 8B 級の model では、次のような失敗が起きやすい。
- tool call すべき場面で自然文のコマンド例を返す
- tool name や arguments の JSON が崩れる
- tool 数が多すぎて選択を誤る
- tool output に混じった環境 warning を実行結果と誤解する
- 「実行しないで」と言われたのに実行系 tool を選びかける
このメモは、Hermes 3 Llama 3.1 8B Q5_K_M を例に、ローカル LLM と Codex CLI の間に小さい adapter を置いて tool call を安定させる設計をまとめる。
基本構成
想定した流れは次のようになる。
flowchart LR
CLI[Codex CLI] --> Proxy[OpenAI-compatible proxy]
Proxy --> Adapter[Hermes tool adapter]
Adapter --> Llama[llama-server]
Llama --> Model[Hermes 3 Llama 3.1 8B GGUF]
Adapter --> InternalTools[adapter internal read-only tools]
InternalTools --> Fetch[fetch_url]
InternalTools --> Search[search_web]
InternalTools --> Research[optional research helper]
CLI --> ToolExecutor[Codex tool executor]
ToolExecutor --> Shell[exec_command / write_stdin]
役割を分けると、
Read more...