llama.cpp b10448がKimi K3をネイティブサポート、MXFP4のロスレス再配置で5.5TBのBF16中間変換を回避

llama.cppのb10448では、Kimi K3テキストモデルのサポートが追加された。重要なのは単に新しいアーキテクチャ名を認識することではなく、この2.8Tパラメータモデル固有のハイブリッド推論パスをGGMLグラフへ組み込んだ点だ。K3は線形KDAとフルMLA Attentionを交互に使用し、さらにcross-layer residual attention、896個のlatent expertsからtokenごとに16個を選択する仕組み、SiLU系とは異なる新しいactivation、MLA output gate、複数形式のKDA decay gateを備える。モデル内部の`text_config`は依然として旧来のKimi Linearアーキテクチャを返すため、llama.cppはトップレベル名からルーティングするよう変更する必要があった。そうしなければ、誤ったモデル定義が適用される。

デプロイにおける重要な変更は、量子化weightの変換だ。公式checkpointはcompressed-tensorsの`mxfp4-pack-quantized`を採用している。数値エンコーディングはGGML MXFP4と同一で、違いはblock内のnibble配列だけだ。このため新版ではビットを直接並べ替える。作者はdequantization errorがゼロであることを検証しており、約5.5TBのBF16 weightへいったん展開してから再量子化する必要はない。また、並べ替えは遅延実行されるため、GGUF writerが出力前に変換済みtensorをすべて同時保持する事態も回避できる。

チャット層にも、K3のXTML形式によるreasoning、response、typed tool-callの解析が追加された。フルモデルを8基のB200上で実行し、ストリーミング内容、推論フィールド、停止理由が検証されている。制約として、cross-layer residual operatorのkernelは現時点でCPUとCUDAにしか用意されていない。MetalとVulkanではノード単位でフォールバックが発生するため、「ロード可能」であることを、各backendですでに良好なパフォーマンスが得られることと同一視すべきではない。今後は、コミュニティ製GGUFの実容量、KDA stateのメモリ使用量、非CUDA kernelの実装ペースを注視する必要がある。