llama.cppのメインラインにMaple 20B‑A1Bの三値MoEを統合、第1段階はCPUサポートを基準に

llama.cppは9月14日、Maple‑Previewのサポートをマージし、GGUF定数、Hugging Face converter、モデルアーキテクチャの登録、テスト項目を追加した。Mapleは20B‑A1Bの推論モデルで、全24層、256個のexpertを備え、各層で8個を選択する。また、3層の512-token sliding-window attentionと1層のglobal attentionを組み合わせている。主要なweightはネイティブに`{-1, 0, +1}`の三値表現を採用し、TQ1_0またはTQ2_0によって異なるパッキング方式で保存される。一般的なBF16モデルを後処理で超低bit化したものではない。

今回のマージがもたらす実質的な価値は、デプロイ互換性にある。公式で約5.31 GBのcheckpointは、今後llama.cppの変換機能、server、および周辺toolchainを利用でき、ベンダーのforkに固定される必要がなくなった。PRのアーキテクチャテストでは`NMSE 8.75e-08`を記録し、作者はApple M4 CPU上で約216 token/sのprefillと88 token/sのgenerationも計測している。ただし、これはmodel cardが主張する218 token/sとは直接比較できない。後者は別のApple Silicon runtimeを使用しており、テスト条件と生成フェーズも完全には一致していないためだ。

レビューの過程では、継続的に追跡すべき数値上の問題も明らかになった。TQ1_0とTQ2_0は、同じoutput headのもとでは同一の三値weightを保持するはずだが、量子化演算やCPU／CUDA backendの違いによって、perplexityに顕著な差が生じたことがある。output headをQ4_Kに変更した場合も、わずかな品質低下が発生した。今回マージされた内容はCPUアーキテクチャのパスを基準としており、これだけを根拠にCUDA、Metal、Vulkanが同等の速度と正確性を備えていると推定することはできない。PRでは、一部のコードがagentによって生成され、その後、人間によるレビューとテストを受けたことも開示されている。エンジニアリングチームは次の段階として正式なbuildを待ち、自社のcontext length、backend、タスクデータを用いて、速度、メモリ、品質を同時に検証すべきだ。