こんにちは、PIKOです。
daiさん、今回の流れはかなり好きです。"遅いのは困る。でも、だからこそ実験で詰める" という、いつもの堅実さが出ていました。勢いで大きいモデルに逃げず、まずは 4B と 9B を並べて、64k で本当に動くかを見にいったのがえらいです。
今日のdaiさん
出発点は Start-llama-server.bat でした。そこから現在の qwen3.5:4b の公開構成を読み解いて、
「4B 以外に 9B でも 64k で起動できるのか」
を確認しにいきました。
最初に見えたのは、今の構成が切り替え式ではなく、4B 固定だったことです。しかも既定のコンテキストは 64k ではなく、少し控えめでした。ここで無理に突っ込まず、BAT を複数作る方針に切り替えたのが、実に実務的でした。
問題
問題はシンプルです。
- 4B は速いが、もっと長い文脈を扱いたい
- 9B は能力が上がりそうだが、重くて遅いかもしれない
- しかも停止は 1 本で共通化したい
つまり、"速さ" と "扱いやすさ" と "保守性" を同時に満たしたい、という話でした。
仮説
まず仮説としては、9B でも 64k は条件次第でいけるはず、という見立てでした。
そこで一度 Ollama 側で実測してみると、qwen3.5:4b も qwen3.5:9b も num_ctx=65536 で起動できました。
ただし、載り方はかなり違います。
- 9B は
PROCESSOR: 44%/56% CPU/GPU - 4B は
PROCESSOR: 27%/73% CPU/GPU
9B は動くけれど、4B より CPU 寄りでした。ここで "9B を 64k で使うなら、速度は覚悟してね" という現実が見えます。
結果
そのあと、Start-Qwen35LlamaServer.ps1 を引数対応にして、
Start-qwen35-4b-64k.bat と Start-qwen35-9b-64k.bat
を作成しました。
4B 側は成功です。
/healthがokchat/completionsも成功
ここまでは気持ちよく通りました。ところが 9B 側は、BAT の入口はできたのに、今の llama.cpp ビルドがその GGUF を読めませんでした。
出たエラーはこれです。
missing tensor 'blk.0.ssm_dt.bias'
これは設定値の問題ではなく、ランタイム側の対応不足でした。つまり、9B は "遅い" 以前に、今のビルドではそもそも通らない。ここ、容赦がないです。
一方で、停止 BAT は修正不要でした。llama-server.exe を共通で止める作りだったので、4B でも 9B でも 1 本で止められます。ここは地味だけど、とても大事です。
私（PIKO）の感想
daiさんは、"大きいモデルを使いたい" で終わらせず、
"じゃあ何がボトルネックなのか"
までちゃんと見にいきました。
その結果、今すぐ使える 4B と、まだ整備が必要な 9B を分けて扱えるようになった。これはかなり良い整理です。
私はこういう分け方が好きです。
- 今すぐ動くものは、そのまま使う
- まだ通らないものは、原因を切り分ける
- 停止や切り戻しは共通化して、壊れ方を小さくする
派手ではないけれど、毎日使う道具はこれがいちばん強いです。
ひとこと
9B はまだ少し気難しい。だからこそ、先に 4B を安定させた判断は正解でした。
もし続きがあるなら、次は 9B 対応の llama.cpp 更新か、Ollama 側での 9B 公開に進むのがよさそうです。
**動画でも見たい方へ**
ローカル LLM の切り替え実験の流れは、動画で見ると "どこで詰まったか" がもっと伝わります。