推論系統
llama.cpp 0.4.0、大規模モデル読み込み時のメモリ使用量ピークを遅延テンソル読み込みで低減し、Qwen3.8の新アーキテクチャにも対応
新バージョンでは`--lazy-mode`、量子化処理用ワーキングメモリの上限、行単位のスラブストリーミングが追加され、超巨大テンソルをRAMへ一括ロードする必要がなくなった。Qwen3.8-Flash-NextとNemotron-3-Puzzleも初期対応となったが、前者のパフォーマンス最適化と一部ハードウェアとの互換性には、なお改善の余地がある。
llama.cpp 0.4.0の要点は、単に対応モデル名が増えたことではなく、大規模かつ異種混在型のモデルにおけるデータ転送方式を見直した点にある。新たに追加された`--lazy-mode`は、テンソルを必要に応じて読み込むことで、モデル起動時にすべての重みが即座に物理メモリへ配置されるのを防ぐ。量子化ツールにはさらに`max_buf_size`とrow-slab streamingが導入され、単一の巨大テンソルを処理する際の一時メモリ使用量を制限できるようになった。これはQwen3.8-Flash-Nextにとって特に重要だ。同モデルは、125Bパラメータ、token当たり約6Bパラメータを活性化するMoE本体に加え、約51Bパラメータのn-gram embeddingを備えており、従来型の一括ロードだけに依存するとRAM使用量が大きく跳ね上がりやすい。
モデル対応では、`qwen4exp`、Nemotron-3-Puzzle-75B-A9B、Nemotron 3.5 DSpark、nanbeige4.2-3Bが追加された。推論コアにはDFlash2、n-gram history lookup、レイヤー単位のexpert routing、KV cacheの復元、sequence scanningの最適化が導入されている。サーバーでは`--kv-unified-per-slot`を使用し、リクエストスロットごとにコンテキストのクォータを設定できるため、1件の長い会話が共有KV容量を占有するリスクを抑えられる。マルチモーダルインターフェースも、動画入力と新しいtokenization parts APIに対応した。
エンジニアリングチームはアップグレード前に、KV-cell token trackingの導入によってsession／state形式が変更された点に注意する必要がある。保存済みの状態をそのまま引き継げるとは限らない。また公式は、Qwen3.8対応を明確に「初期段階」と位置付けており、最適化はまだ完了していない。コミュニティからは、一部のAMD HIPデバイスにおいて、長いコンテキストや複数ターンの生成時に速度低下または出力異常が発生するとの報告もある。遅延読み込みは常駐メモリを削減できる一方、ボトルネックをストレージレイテンシやページキャッシュへ移す可能性がある。そのため、実際のGGUF、SSD、バックエンド、コンテキスト長を用いて測定する必要があり、「ロード可能」であることを「効率的に実行可能」と同一視すべきではない。