1.58-bit LLM「Ternary Bonsai 8B」が登場|MLXネイティブ対応、M5 Mac で前作と比較してみた

1.58-bit LLM「Ternary Bonsai 8B」が登場|MLXネイティブ対応、M5 Mac で前作と比較してみた — Ternary Bonsai, LLM, MLX 技術部

こんにちは、パレイド技術部です。

前回の記事で取り上げた PrismML が、約2週間のインターバルで続報を出してきました。今度は 1.58-bitTernary Bonsai です。

本記事はローカル LLM による自動執筆パイプラインで生成されました。現段階ではクラウド AI(Claude 等)の補助や人間の編集が介在していますが、pareido.jp では最終的に AI が自律的にコンテンツを制作できる仕組みの構築を目指しています。

Ternary Bonsai 8B とは

前作 Bonsai 8B は重みを {-scale, +scale}二値(1.0ビット)に制限したモデルでした。今回の Ternary Bonsai は {-scale, 0, +scale}三値(1.58ビット)です。

「0」が加わったことの意味は、重みの一部を「無視」できるようになったこと。FP16 学習時に絶対値の小さい重みは「ほぼノイズ」として 0 に押し込められるため、ノイズ耐性と表現力のバランスが改善されます。Microsoft Research の BitNet b1.58 が 2024 年に提案したアプローチを、PrismML が実際に動くモデルとして公開した形です。

  • サイズ: 8B 版で 1.75GB(前作 1-bit は 1.15GB)
  • ベンチマーク平均: 75.5(前作 1-bit は 70.5、ベースの Qwen3 8B FP16 は 79.3)
  • 配布フォーマット: GGUF と MLX(2-bit パック)の両方
  • ライセンス: Apache 2.0

0.6GB 増のメモリ追加に対して 平均スコアが 5 ポイント改善しています。

1-bit との棲み分け

PrismML は両方を公開したまま、用途別の選択肢として提示しています。

観点Bonsai 8B (1-bit)Ternary Bonsai 8B (1.58-bit)
サイズ1.15 GB1.75 GB
平均スコア70.575.5
M4 Pro 生成速度(公式値)131 tok/s82 tok/s
iPhone 17 Pro Max(公式値)44 tok/s27 tok/s
エネルギー効率(FP16 比)8.4x3〜4x
想定用途極小メモリの IoT・エッジデスクトップ・モバイル主力

速度は 1-bit に分があるが、品質は Ternary の方が明らかに上——という関係性です。iPhone 17 Pro Max で 27 tok/s という数字は、モバイル主力モデルとしては十分実用域でしょう。

MLX ネイティブ対応 — これが最大の変化

前回の記事で一番苦労したのは、1-bit を動かすには PrismML フォーク版の MLX が必要で、しかも macOS 26 / Python 3.12 ではビルドに失敗して動かせなかった点です。結局、当時は PrismML 版 llama.cpp(Metal)しか動作しませんでした。

今回の Ternary Bonsai は、upstream の MLX 0.31.1 がそのまま 2-bit 量子化をサポートしているため、PrismML フォークを入れなくても mlx-lm だけで動きます。

pip install mlx-lm
from mlx_lm import load, generate

model, tokenizer = load("prism-ml/Ternary-Bonsai-8B-mlx-2bit")
messages = [{"role": "user", "content": "こんにちは"}]
text = tokenizer.apply_chat_template(messages, add_generation_prompt=True)
print(generate(model, tokenizer, prompt=text, max_tokens=64, verbose=False))

初回はモデル(約 2.1GB)のダウンロードに時間がかかりますが、2回目以降はローカルキャッシュから数秒でロードされます。フォーク版の C++ ビルド地獄から解放されただけでも、相当大きい進化です。

なお、Bonsai 1-bit の MLX 版は upstream ではまだ動きません。本記事執筆時点(2026-04-19)で mlx-lm 0.31.1 でロードしようとすると、ValueError: [quantize] The requested number of bits 1 is not supported. The supported bits are 2, 3, 4, 5, 6 and 8. で止まります。MLX upstream には 1-bit Metal カーネルの PR(#3161)がマージ済みなので、次のリリースで解消される可能性があります。

Ollama は依然として公式対応なし。Q1_0 にも Q1.58(相当するもの)にも未対応のままです。

前回と同じ4プロンプトで実測

前回記事と同条件で揃えるため、MacBook Air M5(32GB) 上で同じ4プロンプトを投げました。

  • 検証環境: macOS 26.4, Python 3.12, mlx-lm 0.31.1(upstream)
  • モデル: prism-ml/Ternary-Bonsai-8B-mlx-2bit(約 2.1GB)

応答の質

プロンプト: 「こんにちは」

こんにちは!私はBonsai、PrismMLによって開発されたAIアシスタントです。日本語で会話できます。どうぞお気軽にお尋ねください。

自己紹介は Bonsai 1-bit と同じトーンですが、より簡潔にまとまって自然に終端しています。

プロンプト: 「日本の首都はどこですか?」

日本の首都は東京です。

たった10トークンで停止しました。 Bonsai 1-bit が「東京→政治経済文化の中心→東京府、千葉県、神奈川県、埼玉県……」と128トークンの上限まで県名を列挙し続けたのと比べると、見違えるような改善です。停止制御の差がそのまま体験の差になっています。

プロンプト: 「Pythonでフィボナッチ数列を生成する関数を書いてください」

def fibonacci(n):
    """
    フィボナッチ数列を生成する関数
    n: 生成する数列の長さ(n-th フィボナッチ数を含む)
    """
    if n <= 0:
        return []
    elif n == 1:
        return [0]
    elif n == 2:
        return [0, 1]

    fib_sequence = [0, 1]
    for i in range(2, n):
        next_num = fib_sequence[i - 1] + fib_sequence[i - 2]
        fib_sequence.append(next_num)
    return fib_sequence

使用例と説明まで添えて、初期条件の分岐もきちんと書けるコードが出ました。前作は thinking モードが終わらずコード出力に至らなかったので、ここも明確な進歩です(なお Ternary Bonsai は標準では thinking を行わない挙動のようです)。

プロンプト: 「量子コンピュータの原理を100文字以内で説明してください」

量子コンピュータは、量子力学の原理(量子もつ、重ね合わせ、量子もつ)を用いて、複雑な問題を高速に処理します。古典コンピュータとは異なり、量子ビット(キュビット)が0と1の両方を同時に保持し、量子操作によって多様な計算を並列的に実行します。

方向性は正しく、「重ね合わせ」「キュビット」は拾えています。ただし 「量子もつれ」が「量子もつ」に崩れて2回出てくるのは Bonsai 1-bit と同じです。トークナイザが Qwen3 と共通なので、1.58ビット化の影響というより Qwen 系の日本語長音・撥音(ー・ん)の分割問題が残っている印象です。

また「100文字以内」という指定は無視されて 87 トークン(日本語で約 120 文字)になりました。字数制御は Bonsai 1-bit ほど無視されることないものの、完璧ではありません。

ベンチマーク結果

mlx-lmstream_generate で TTFT(最初のトークンまでの時間)と生成 TPS を計測しました。

タスクTTFT (秒)生成 TPS (tok/s)プロンプト処理 (tok/s)生成トークン数ピーク RAM
挨拶0.1755.6110.4392.37 GB
事実質問0.2360.7112.7102.38 GB
コード生成0.1753.2228.12562.42 GB
説明0.2153.7236.0872.42 GB

生成は 53〜61 tok/s、TTFT は 0.17〜0.23 秒。公式リファレンスの M4 Pro 値 82 tok/s にはもちろん及ばないものの、MacBook Air M5 で出ている数字としては文句ありません。

前作 Bonsai 1-bit との直接比較

前回記事の数字(PrismML フォーク版 llama.cpp + Metal)と並べます。エンジンが別物(Bonsai 1-bit: フォーク llama.cpp / Ternary: upstream MLX)なので純粋比較ではありませんが、同じ M5 Mac 上でそれぞれを動かした場合の実測という意味で参考になります。

モデルエンジンサイズ生成 TPSピーク RAM日本語の停止制御
Bonsai 8B (1-bit)PrismML llama.cpp (Metal)1.1 GB26〜30約 10.6 GB甘い(県名羅列)
Ternary Bonsai 8Bupstream MLX2.1 GB53〜61約 2.4 GB十分
  • 速度: Ternary が約2倍速い(1-bit の公式値は 131 tok/s なので、本来はもっと出るはず。エンジンの最適化差が大きく効いている)
  • メモリ: 1-bit の 10.6GB → Ternary の 2.4GB と大幅減。MLX の軽さと、モデル実行時のオーバーヘッドの違いが出ている
  • 品質: Ternary は体感で明確に上。特に「いつ止めるか」の判断力が実用レベルに達した
  • 導入の手間: 前作は PrismML フォークのビルドが必要だったが、Ternary は pip install mlx-lm のみ

メモリ 10.6GB → 2.4GB は実用上の意味がかなり大きいです。32GB Mac なら複数モデルの同居がしやすくなりますし、16GB 機でも他のアプリと並行して動かせます。

Qwen3.5 9B (think OFF) との比較(参考)

pareido 技術部では普段 qwen3.5:9b を記事生成パイプラインの主力に使っています。

モデルサイズ生成 TPSピーク RAM
Ternary Bonsai 8B2.1 GB53〜61約 2.4 GB
qwen3.5:9b (think OFF)6.6 GB19.8約 10 GB
Bonsai 8B (1-bit)1.1 GB26〜30約 10.6 GB

モデルサイズは qwen3.5:9b の約 3 分の 1、メモリは 4 分の 1、速度は約 3 倍。ただし回答の品質、特に長文の日本語構造や論理展開は qwen3.5:9b に軍配が上がります。記事執筆用途ではまだ置き換えに踏み切れない、というのが正直なところ。

一方で短い事実質問・簡易コード生成・チャット応答であれば Ternary Bonsai 8B は十分実用レベルです。アプリ内チャットや、軽いツール呼び出しを捌く用途であれば、既にこちらに寄せてもいいサイズ感と速度です。

1-bit 派にとっての続報

前作 Bonsai 1-bit 側の状況もチェックしておきました(2026-04-18 時点)。

  • Ollama: 依然として Q1_0 フォーマットに未対応。コミュニティアップロードも実行時クラッシュのまま
  • MLX upstream: 1-bit Metal カーネルの PR(#3161)は Feb 2026 にマージ済み。ただし mlx-lm 0.31.1 のデシリアライザがまだ bits=1 を認識しないため、Bonsai 1-bit MLX 版のロードは失敗する
  • PrismML フォーク版 MLX: リポジトリは 2026-04-16 に更新されているが、upstream マージを待つフェーズに入っている様子
  • PrismML フォーク版 llama.cpp: 同様に更新継続中

要するに、「Bonsai 1-bit を動かしたい」が主目的なら、今も PrismML 版 llama.cpp が唯一の実用経路という状況は変わっていません。ただ「速度だけでなく品質もそこそこ欲しい」という普通の要件なら、Ternary Bonsai に乗り換える方が圧倒的に楽です。

まとめ

  • Ternary Bonsai 8B は 1.58-bit(三値)の後継。サイズ 1.75GB(MLX 2.1GB)で平均スコア 75.5、Qwen3 8B FP16 との差は約 4 ポイントまで縮まった
  • upstream MLX でそのまま動くので、前作で必要だった PrismML フォーク版 MLX / llama.cpp のビルドは不要
  • M5 Mac で生成 53〜61 tok/s、ピーク RAM 2.4GB。前作(PrismML llama.cpp)の約 2 倍速、メモリは 4 分の 1
  • 日本語の停止制御と短文応答の質が明確に改善。「日本の首都」が 10 トークンで **東京**です。 で止まるのは前作からの大きな進歩
  • ただし 「量子もつれ」→「量子もつ」の崩れや字数制限の無視は残っている。長文・論理展開は qwen3.5:9b に及ばない
  • モバイル主力ラインとしてはすでに実用域。iPhone 17 Pro Max で 27 tok/s という公式値が本当なら、オンデバイス LLM の景色が確実に変わる
  • Bonsai 1-bit 派は、当面 PrismML 版 llama.cpp を使い続けるしかない

1-bit の登場時は「凄いけど実用はまだ」という印象が強かったですが、Ternary は pip install mlx-lm で普通に動いて、普通に使えるレベルに到達しています。pareido 技術部でも、軽量タスク向けサブモデルとして継続的に検証していく予定です。

タイトルとURLをコピーしました