llama.cpp b11988：Limite 1B対応、GGUF変換経路の追加

1. 変換から実行まで対応

今回の対応を含むb11988ビルドは、2026年10月29日にGitHubでプレリリース版として公開された。変更はモデル構造のファイル形式への登録、元のモデルの変換機能、変換済みモデルの実行実装にわたる。対応名を一覧に加えるだけでなく、変換と実行の両方をつないだ。

GGUFはモデルの重みと実行に必要な設定を格納するファイル形式だ。開発者は元のモデルをこの形式に変換し、新しいビルドで実行する流れを利用する。変換ツールにはparadigma-inc/limite-1b-violettoがサンプルモデルとして登録されており、対象モデルを確認できる。

2. 専用推論実装と量子化のトレードオフ

専用の実行部は、複数の層の情報を混ぜて伝える接続方式であるMUDD接続など、このモデル固有の計算を処理する。変換ツールは元の設定と重みを、実行部が読み取る構造に移す役割を担う。

重みの表現精度を下げて容量を減らす量子化にも、モデル固有の処理が加わった。情報の通過量を調節するゲートと層間の情報混合に使う小さなテンソルは、比較基準となる参照実装と同様に、32ビット浮動小数点表現であるF32精度を維持し、後続の量子化からも除外する。残りの重みを削減できるようにしつつ、この小さな重みの精度を保つ折衷策であり、該当部分は容量削減の対象外となる。

3. 単一リクエストの数学推論に合わせた会話処理

モデルリポジトリ側の参加者は、このモデルが1回の質問に答える数学推論向けに設計されたと説明した。推奨される入力は、過去の会話をつなぐのではなく、固定の数学用システムメッセージと現在の質問を使う方式だ。ローカルで数学問題の解答を試す際も、この用途に合わせてリクエストを構成することが出発点となる。

変更提案には、回答の推論内容を別途取り出して<think>区間に入れる会話テンプレートの修正案も示された。モデルリポジトリ側は9月27日のコメントで、この修正を適用し、モデルカードで単一リクエスト向けの用途を明確にしたと述べた。以下は提案に掲載された追加部分だ。

+    {%- elif message.role == 'assistant' %}
+        {{- '<|im_start|>assistant\n' }}
+        {%- if message.reasoning_content is string and message.reasoning_content %}
+            {{- '<think>\n' + message.reasoning_content + '\n</think>\n\n' }}
+        {%- endif %}
+        {{- message.content + '<|im_end|>\n' }}

4. Vulkan測定で確認されたスループット

変更提案の作成者は、MUDDの混合計算を修正した後にローカルで試し、モデルが動作して速度も向上したと報告した。測定モデルは16ビット浮動小数点形式のLimite 1B BF16で、サイズは1.93 GiB、パラメータ数は1.04 Bと記載された。

測定はVulkanバックエンドとngl -1設定で行われた。作成者の報告では、プロンプト処理テストのpp512は、変更前の8847.75 ± 1208.96から変更後の9814.88 ± 44.44トークン/秒へと向上した。

生成処理テストのtg128も、同じモデル・バックエンド・設定で99.46 ± 6.66から122.70 ± 4.40トークン/秒へと向上したと報告された。入力を処理する段階と回答を生成する段階の両方で、計算変更の効果が観察されたことになる。

5. 開発者にとって変わる点

リリースにはLinux、Windows、macOS、Android向けビルドと、CPUおよび各種アクセラレーションバックエンドのビルドが並ぶ。開発者がまず行うのは、環境に合うビルドを選び、モデル変換と会話テンプレートを併せて準備することだ。

性能測定に使ったハードウェアの機種はコメントに記載されておらず、機器ごとの期待速度を判断するには追加確認が必要だ。実行実装は異なるリクエストをまとめて処理する混合バッチに対応しない。また、入力を計算済みのベクトルで渡す方式ではなく、トークンIDで値の埋め込み、つまりトークンを数値ベクトルに変えた表現を参照する方式のみをサポートする。

b11988の実質的な変化は、Limite 1BのGGUF変換と専用実行を一連の流れとしてつなぎ、ローカルでの数学推論実験の導入障壁を下げた点だ。