- Qwen3-30B-A3B-Instruct-2507 モデルが ラズベリーパイ 5(16GB) 上でリアルタイム動作し、8.03 TPS と BF16 品質の 94.18% を維持
- ByteShape の ShapeLearn ビット長学習法 により、各デバイスのメモリ上限内で 速度と品質のバランス を最適化
- Unsloth や MagicQuant と比べ、同一品質ではより高い TPS、同一 TPS ではより高い品質を達成
- CPU、GPU(特に RTX 5090・4080)のいずれでも 4ビット前後が最適性能帯 として現れ、ビット数を減らしても常に高速化するわけではない
- 全体として ByteShape モデルは 「メモリを予算と見なし、TPS/品質を最適化する」 アプローチにより、エッジからデータセンターまで効率的な性能を提供
ShapeLearn ベース最適化の概要
- ByteShape はモデル実行時にユーザーが体感する 速度と応答品質 を中心に最適化を行う
- ShapeLearn は各テンソルの重みデータ型(bitlength)を学習し、TPS(1秒あたりのトークン数) と 出力品質 を同時に最大化
- 目的は単なるファイルサイズ削減ではなく、速度と品質の実際のバランス の改善
- llama.cpp 環境では、ビット数を減らしても常に速度が向上するわけではなく、カーネル選択とオーバーヘッド が性能に大きく影響
- ByteShape はメモリを 「十分に収まるための予算」 と見なし、その後は TPS と品質を中心に調整
Raspberry Pi 5 の性能
- ラズベリーパイ 5(16GB) で 30B モデルが 8.5 TPS、92% 以上の精度 を維持
- Q3_K_S-2.70bpw [KQ-2] モデルはリアルタイム対話レベルの応答速度を提供
- 精度優先モデル では ByteShape が 1.1〜1.3% の相対誤差(約 98.8% 精度) で、Unsloth より最大 1.87 倍低いエラー率を達成
- 同一環境で 5〜6 TPS を維持し、精度重視の作業に適する
- 速度優先モデル(Q3_K_S-3.25bpw [KQ-5]) も Unsloth より小さく高速で、精度面でも優位を維持
- Unsloth と MagicQuant の多くのモデルは、メモリ制約により Pi 環境では実行不可
Intel i7(64GB)の性能
- すべてのモデルがメモリに収まる環境で、ByteShape は Unsloth・MagicQuant より高い品質と TPS を達成
- 品質重視領域: ByteShape の IQ4_XS-4.67bpw [KQ-9] モデルは、Unsloth の Q6_K と比べて 1.44 倍低いエラー率 とより高い TPS を確保
- バランス領域: ByteShape の Q3_K_S-3.25bpw モデルは、Unsloth より 1.73 倍低いエラー率、MagicQuant より 精度・速度ともに優位
- ByteShape のみが 26+ TPS 領域と高品質領域を同時にカバー
GPU 性能比較(RTX 5090 / RTX 4080)
- GPU では カーネル選択と VRAM アクセス効率 が性能を左右
- 4ビット前後(~4bpw) が TPS と品質の スイートスポット であることを確認
- RTX 5090(32GB)
- Unsloth、MagicQuant、ByteShape はいずれも 4b 領域で 302〜303 TPS、98.4〜98.9% の精度
- ByteShape の IQ4_XS-4.67bpw モデルは 272.98 TPS、99.75% の精度で最高精度を達成
- Unsloth Q6_K(6.57bpw、264.88 TPS、99.64%)および MagicQuant mxfp4(5.46bpw、240.42 TPS、99.32%)より優位
- RTX 4080(16GB)
- VRAM 制約により 4b モデルは不可だが、同じ 16GB 条件で ByteShape は Unsloth より TPS・精度ともに優秀
- ByteShape IQ4_XS-3.87bpw: 214.81 TPS、98.66% の精度
- Unsloth Q3_K_XL と比べ 1.59 倍低いエラー率、9.4% 高い TPS
- Unsloth IQ2_M と比べ 2.54 倍低いエラー率
ビット数と速度のパラドックス
- 3ビット以下まで下げても速度向上は保証されない
- GPU は 32 スレッドのワープ単位で動作し、特定のデータ形式とアクセスパターンに最適化されている
- VRAM は 32 バイト整列ブロック単位で読み込むため、より小さいデータでも同じ帯域幅を使用
- 低ビット幅では デコードのオーバーヘッド増加 により、かえって遅くなる可能性がある
- 例: RTX 5090 で
iq4_xs は 54µs、iq3_xxs は 62µs → 容量 25% 削減が速度 13% 低下につながる
- ShapeLearn はこうしたハードウェア特性を考慮して テンソルごとにデータ型を選択 し、速度と精度を同時に確保
評価方法と結論
- すべてのモデルは同一の評価ハーネスで TPS と 正規化品質スコア(BF16 比) を測定
- 品質評価は MMLU、GSM8K、IFEval、LiveCodeBench V4 の結果を統合
- 主要な結論:
- 「メモリを目標ではなく制約として扱え。」
- モデルがデバイスに収まった後は、TPS と品質のバランス曲線 が重要
- ByteShape はすべてのデバイスで 同一品質ならより高速、同一速度ならより高品質 を達成
- ラズベリーパイ 5 では Q3_K_S-2.70bpw [KQ-2] モデルがリアルタイム対話に適する
- 大型 CPU・GPU 環境でも同じ原則が適用される: 「まず収め、その後で最適化せよ。」
- ByteShape は今後さらに多くの デバイス別最適化モデル を継続的に公開予定
1件のコメント
Hacker Newsのコメント
ここには大きな市場機会があると思う
私が欲しいのは Alexa のような音声アシスタントだが、ローカル推論とストレージを基盤にした標準化コンポーネントを持つシステムだ
重要なのはプライバシーと相互運用性だ。アカウント登録や外部サーバー接続が必要なら買わないだろう。「Freddy, 10分タイマーをセットして」のような命令をローカルで処理したい
複数の低価格な Wi-Fi + マイク + スピーカー機器を家のあちこちに置き、音声処理は中央の高性能ボックスで行う構成だ
結局これは 1 つのプログラムのように動くので、もう少し強力なマシンに Wi-Fi カードを追加すれば Wi-Fi エクステンダー の役割も果たせる
ウェイクワード(wake word) という概念も気に入らない。スタック全体にまだ改善の余地が大きいと感じる
さまざまなモデルを簡単に比較できる良い資料があるのか気になる
gpt-oss-20b と gpt-oss-120b のパラメータ数の違いは分かるが、実際の性能差はよく分からない
Gemini や GPT のような大規模モデルしか使ったことがないので、自分のハードウェアでどの程度小さなモデルまで実用的に使えるのか知りたい
「リアルタイム」の性能がどの程度なのか気になって調べてみた
Pi 5(16GB) で Q3_K_S-2.70bpw [KQ-2] モデルが 8.03 TPS を記録し、BF16 品質の 94.18% を維持しているという
記事ではほかのハードウェア詳細についても触れている
私も Pi 5(16GB) で最新の llama.cpp を試してみたが、セグメンテーションフォルト(segfault) が発生した
メモリ不足のエラーメッセージが出て、約 10GB の RAM を使ったところで終了した
-c 4096オプションでコンテキストサイズを減らしたらロードに成功したBitNet b1.58-2B-4T-gguf のようなモデルは、低スペック機器や iGPU しかないオフィス PC でも比較実験しやすそうだ
精度の測定方法が一般的な perplexity と違うのか気になる
BF16 から 2.8 に下げたのに品質低下が 5% しかないというのが不思議だ
GPT-OSS-20B は 11.2GB ほどなので、16GB メモリの機器でも品質低下なしで十分動かせる