llama.cppのデイリービルド、旧世代GPU向けにF32フォールバックを導入し、Nemotron MTPウェイトのゼロ除算クラッシュを防止

llama.cppは9月13～14日に複数のプレリリースビルドを相次いで公開した。焦点は新しいモデル機能ではなく、異種ハードウェアと新しい投機的デコーディング用ウェイトに関するエラー処理だ。b10950では`ggml-cuda`を変更し、ハードウェアによるBF16アクセラレーションに対応するデバイスでのみBF16を使用するようにした。対象はNVIDIA Ampere以降、およびAMD RDNA3またはCDNAで、それ以外のCUDA／HIPデバイスでは関連処理をF32で実行する。これにより、従来は実行できなかった可能性のある構成でも、速度は低下するものの動作可能なフォールバックモードを利用できる。ただし、リリースノートには速度やVRAM使用量の増加に関する数値は示されていない。

b10947では、Nemotron-HのNextN／MTP末尾レイヤーに対処した。各レイヤーに`expert_feed_forward_length`が指定されていない場合、ローダーは`n_ff / n_expert_used`によってexpert FFNのサイズを推定する。しかし、非MoEレイヤーでは両方のフィールドが正当にゼロとなる可能性があり、旧実装ではゼロ除算が発生し、診断可能なメッセージを出さずに読み込み中にSIGFPEで終了していた。新版ではガード処理が追加され、この種のcheckpointメタデータを検出すると、フォーマット上の問題を明示的に報告する。

同じ期間に公開されたb10952では、oneDNNのscratchpadがSYCLメモリプールの解放順序を壊す問題も修正された。b10951では`llama_n_rs_seq`のチェックを`llama_decode`の前に移し、デコードを必要としないsequenceを早期に返すようにした。これらの変更はそれぞれ異なるbackendに属するが、llama.cppが現在、新しいモデルアーキテクチャ、投機的デコーディング用head、複数ベンダーのGPU実行経路に伴う互換性コストを同時に負っていることを示している。

エンジニアリングチームは、デイリービルドをstable releaseとしてそのまま全面展開すべきではない。F32へのフォールバックにより、throughput、メモリ使用量、数値結果が変化する可能性がある。また、Nemotron向けの修正はクラッシュを理解可能なエラーに置き換えるだけで、欠陥のあるGGUFを修復するものではない。より安全な方法は、固定したモデルとpromptでアップグレード前後の出力を比較し、代表的なlong contextとMTP構成を使用してVRAM、prefill、decodeを計測したうえで、本番環境への導入を判断することだ。