Ternary Bonsai、LocalLLaMAはcompression claimの比較軸を疑った

小さなmodel familyと鋭い但し書き

PrismMLのTernary Bonsai投稿は、LocalLLaMAで112ポイント、34コメントを集めた。普通のhardwareにどれだけ使えるmodelを詰め込めるかという、コミュニティの中心的な関心に直接触れたからだ。PrismMLによれば、Ternary Bonsaiはembeddings、attention layers、MLPs、LM head全体で1.58-bit weightsを使い、weightを{-1, 0, +1}の3状態で表す。Familyは1.7B、4B、8B parameterで、8B版は1.75GB、平均benchmark score 75.5とされる。

Headline claimは魅力的だ。PrismMLはTernary Bonsai 8Bが1-bit Bonsai 8Bより平均benchmarkで5ポイント高く、memoryは約600MB増えるだけだとする。Apple devicesではMLXでnative実行でき、M4 Proで82 toks/sec、iPhone 17 Pro Maxで27 toks/secという数字も出している。Edge AIやlocal assistantを考えるユーザーには、十分に目を止める数字だ。

LocalLLaMAは比較相手を問うた

上位コメントは敵対的ではなかったが、非常にLocalLLaMAらしく懐疑的だった。複数のユーザーは、Ternary Bonsaiのsize advantageをfull 16-bit peersと比べると大きく見えすぎるのではないかと指摘した。実際のユーザーが知りたいのはQ4 quantized modelとの比較だ。コミュニティが生きているのは、きれいなFP16 baselineではなく、GGUF file、mixed quantization、quality-speed-memory tradeoffの世界だからだ。

もうひとつの論点はprovenanceだった。コメントでは、これらのモデルはscratchからquantization awareに学習されたものではなく、Qwen3をquantizeしたものに見えるという指摘も出た。それで価値がなくなるわけではないが、claimの読み方は変わる。LocalLLaMAが欲しいのは賢いtableではなく、実際に使えるmodelだ。1.58-bit modelが小さくても、よく調整されたQ4 modelに対して品質を落としすぎるなら、memory winだけでは足りない。

本当の問いはPareto frontier

Ternary Bonsaiが面白いのは、二つの欲求の間にあるからだ。ひとつはbrowserやphoneでも動く最小modelを求める欲求。もうひとつは、常時動くlocal workflowのためにwattとGBあたりの品質を最大化したい欲求だ。1.58-bit familyが本当に意味を持つには、table上でuncompressed modelに勝つだけでなく、performance-size curve自体を押し動かす必要がある。

このthreadの熱は、建設的な圧力に近かった。ユーザーは35Bや122B級の大きなvariantを求め、自分たちが実際に動かすformatとの強い比較を求めた。これは健全な反応だ。コミュニティはextreme compressionに興奮する一方で、reproducible numbers、realistic baselines、実際のpromptに耐えるdownloadを要求するようになっている。

PrismML post · Reddit discussion