Posted:
| Tags:
ai,
codex,
gemma,
llama-server,
local-llm,
mcp
Gemma 4 E4B QAT Q4_0 GGUF を、Codex CLI の text-only local model backend 候補として試した。
比較対象は、先に評価していた Gemma 4 12B Q4_K_M である。見たかったのは、単なる短文応答ではなく次の 4 点だった。
- 12B より GPU memory が下がるか
- Codex CLI の agent prompt を現実的な context に収められるか
- JSON final answer と read-only shell tool use が成立するか
- 広い文書検索や MCP tool selection で破綻しないか
先に結論を書くと、E4B は memory / speed 面では 12B よりかなり扱いやすい。
一方で、Codex CLI の tool routing まで含めると、12B の単純な置き換えではない。特に MCP tool を model に直接選ばせる構成は不安定で、検索 intent は adapter / router 側でルールベースに拾う方が堅い。
Read more...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...