目次 / トラブルシュート

トラブルシュート

つまずきやすい所を、起きやすい順にまとめました。多くは llama.cpp 周りです。

画像を渡した瞬間にクラッシュする(0xC0000409 など)

原因はほぼ --jinja の付け忘れです。 llama.cpp は画像トークン処理にチャットテンプレートが必要で、無いと即クラッシュします。Pixubus EX は自分で起動した llama-server につなぐ方式なので、起動コマンドに --jinja を必ず付けてください(設定画面の推奨コマンドにも入っています)。これでも落ちるならビルドが環境に合っていない可能性(下の GPU 項目)。

llama-server -m model.gguf --mmproj mmproj-F16.gguf --jinja

Blackwell(RTX 50 系)で固まる / 落ちる

新しい GPU 世代(sm_120)はビルドの相性があります。

llama.cpp の準備(Windows)cudart-… を一緒に展開し忘れていないかも確認。

遅い / VRAM が足りない

目安は 速度の目安 へ。

接続できない

リモート(RunPod)で 1 回目のジョブが「llama-server 524」で失敗する

初回だけの現象で、多くは待てば直ります。 RunPod の公開 proxy は Cloudflare 経由のため、リクエストが約 100 秒を超えると 524(タイムアウト)で切られます。初回のジョブはモデルの自動ダウンロード + ロードを伴うので、この制限を超えがちです(実測: 26B の初回で発生)。

自動ダウンロードされたモデルはどこにある?(リモート)

リモート用 INI(hf-repo 方式)で自動ダウンロードされたモデルは、サーバーの ~/.cache/llama.cpp/ に置かれます。

RunPod では pod を削除するとキャッシュも消えます(次回また数分のダウンロードが走る)。永続ボリュームに残したい場合は、起動コマンドの前に LLAMA_CACHE を付けて置き場所を変えます:
LLAMA_CACHE=/workspace/llama-cache ./build/bin/llama-server --models-preset ./pixubus-ex-remote.ini --models-max 1 --jinja --no-warmup --host 0.0.0.0 --port 8080

起動直後にターミナルへ赤いエラー(ECONNREFUSED)

多くは正常です。 開発時(npm run dev)、サーバーが立ち上がるまでの数秒だけ画面側が接続を試みて出ることがあります。両方そろえば消えます。

Node のエラー / SQLite の警告

モデルのダウンロードが途中で失敗する

読み取りが甘い / 細部を間違える

画像が扱えない / mmproj 関連のエラー

解決しないときは、ターミナルに出ている llama-server のログ(エラー行)を確認すると原因が分かることが多いです。