ハクソク

世界を動かす技術を、日本語で。

30B QwenモデルがRaspberry Piに入り、リアルタイムで動作する

139日前原文(byteshape.com)

概要

  • Shapelearn によるビット長学習で、Qwen3-30Bモデルの 速度と品質 を最適化
  • メモリ制約 を満たした上で、 Tokens per Second (TPS) と出力品質のバランスを重視
  • ByteShape モデルがUnslothやMagicQuantよりも高いTPS/品質トレードオフを実現
  • CPU・GPU・Raspberry Pi など各プラットフォームでの実践的な比較結果
  • GPUではビット数削減＝高速化 とは限らず、カーネルやハードウェア特性が重要

ShapelearnによるQwen3-30B-A3B-Instruct-2507最適化の概要

  • Shapelearn は、 ビット長学習手法 を用いてモデル重みのデータ型を選択
  • 目標 は、特定デバイス上での 高TPSと高品質 の両立
  • 実用的な制約 として、「モデルがメモリに収まること」を最優先
  • モデルが収まった後は、 ファイルサイズの縮小のみを目的にしない
  • 速度と品質のトレードオフ が改善される場合のみ、さらなる縮小を検討

llama.cppにおけるビット長最適化の重要性

  • llama.cpp では「ビット数削減＝速度向上」とは 限らない
    • 異なる量子化形式で 異なるカーネルやオーバーヘッド が発生
    • 一部GPUでは低ビット化で逆に 速度低下 する場合あり
  • メモリは「予算」 として扱い、 TPSと品質の最適化 を最重視

Raspberry Pi 5（16GB）での実践例

  • Qwen3-30B が Raspberry Pi 5（16GB） で動作可能
    • Q3_K_S-2.70bpw [KQ-2] は 2.70 BPW/8.03 TPS/94.18% BF16品質
    • リアルタイム感 を実現（8 TPS超で体感上十分な応答速度）
  • ByteShape はUnslothやMagicQuantより 効率的なTPS/品質トレードオフ
  • メモリ制約下 （「RAMに収まること」が最優先）でのモデル選択指針

    • レスポンスタイム重視 ：Q3_K_S-2.70bpw [KQ-2]推奨

    • 最高精度重視 ：ByteShapeが最小エラー率で最高精度を実現

    • 代表的なモデル比較表

      • Q4_K_S-3.92bpw [KQ-7]：1.14%誤差/3.92 BPW/5.30 TPS
      • Q4_K_S-3.61bpw [KQ-6]：1.25%誤差/3.61 BPW/5.94 TPS
      • Q3_K_S-3.25bpw [KQ-5]：2.03%誤差/3.25 BPW/6.68 TPS
      • Unsloth UD-IQ3_XXS [6]：2.22%誤差/3.38 BPW/5.03 TPS

Intel i7（64GB）での比較

  • 全モデルがRAMに収まる環境 でのTPS/精度比較
  • ByteShape はUnsloth・MagicQuantより 少ないビット数で高品質/高TPS
  • 26+ TPS領域 で動作するのはByteShapeのみ
  • 品質最優先 ：IQ4_XS-4.67bpw [KQ-9]が最小誤差（0.25%）を達成
  • バランス重視 ：Q3_K_S-3.25bpw [KQ-5]が高精度・高TPS・低BPWの最良バランス

GPU（RTX5090/32GB・RTX4080/16GB）での最適化

  • GPUではカーネル選択が性能に大きく影響
    • ビット数削減が必ずしも速度向上にならない
    • 4ビット付近に TPSと品質のスイートスポット が存在
  • RTX5090（32GB） ：UnslothとMagicQuantの~4bモデルが高TPS・高品質で拮抗
    • ByteShapeは高精度領域で最良（IQ4_XS-4.67bpw [IQ-8]：4.67 BPW/272.98 TPS/99.75%精度）
  • RTX4080（16GB） ：VRAM制約下で ByteShapeがUnslothより高効率
    • IQ4_XS-3.87bpw [IQ-6]：3.87 BPW/214.81 TPS/98.66%精度
    • Unsloth Q3_K_XL [8]より1.59倍低誤差・9.4%高TPS

GPUで「3ビット＝高速化」とは限らない理由

  • データサイズ削減＝速度向上 とは限らない
    • GPUは32スレッド単位の「ワープ」で処理
    • 特定データ形式・メモリアクセスパターン で最適化されている
    • 「黄金パス」から外れると 遅延やオーバーヘッド が発生
  • 32バイト単位でのVRAMアクセス など、ハードウェア固有の制約
  • 柔軟性向上＝ハードウェア複雑化＝遅延・消費電力増加 のトレードオフ

まとめ

  • Shapelearn/ByteShape は、 実デバイスでの速度・品質最適化 に最適な手法
  • メモリ制約を満たしつつ、速度と品質のバランス を重視したモデル選択が可能
  • CPU・GPU・エッジデバイス すべてで、 ByteShapeが最良のTPS/品質トレードオフ を実現
  • 量子化は単なるビット数削減ではなく、ハードウェア特性・カーネル最適化が鍵
  • 現実的なデバイス制約下での最適なAIモデル運用 のための新しいベストプラクティス

Hackerたちの意見

他に「リアルタイム」って何を指すのか気になってクリックした人がいるかもしれないね。 > Pi 5（16GB）で、Q3_K_S-2.70bpw [KQ-2]は2.70 BPWで8.03 TPSを達成し、BF16の品質を94.18%維持してるんだ。他のハードウェアや詳細についても話してるけど、これは見出しの主張の拡張版だね。

└

Hacker Newsのホームページを、こういう記事の重要な詳細をLLMで抜粋したバージョンにしてほしいな。

その精度の測定方法、何か違うのかな？つまり、通常使われるパープレキシティの用語と比べて。BF16から2.8に移行して、たったの5%くらいしか損失がないのは変に感じる。

└

GSM8K、MMLU、IFEVAL、LiveCodeBenchでの精度についてだね。彼らの方法論はここに詳しく書いてあるよ: https://byteshape.com/blogs/Qwen3-4B-I-2507/

ここには大きな市場セグメントが待ってると思う。少なくとも、私みたいな人はこれを欲しがってる。まあ、少なくとも数十ドルは稼げるだろうし。重要な転換点が欠けてるだけなんだ。基本的には、ローカル推論とストレージに支えられた家庭用のAlexaみたいなデバイスが欲しいんだ。標準化されたコンポーネントが必要で、 - インタラクティブデバイス - AlexaやGoogle、Appleのデバイスはこのインターフェースだし、ローカルで動作するテレビ入力もあって、音声でコントロールできるようなものがいいな。良いスピーカーと音声コントロールが必要だね。Wi-Fiレンジエクステンダーやルーターとしても機能するべきだと思う。それがあれば本当に良い。部屋ごとに一台買うから、近くにあればクレイジーなアンテナはいらないし、真のメッシュネットワークを作れる。まあ、話がそれちゃったけど。 - 家庭用の「クラウド」サーバー、ストレージとコントロールを兼ね備えたもの。安いCPUと少しのRAM、そしてたくさんのストレージが必要だね。家庭用の「アプリ」を保持して、ネットワークに関するすべて（ネットワーク設定も含む）をバックアップできる場所が欲しい。 - 推論エンジン。これがこの種のリポジトリ/デバイスの組み合わせが必要なところ。これを買えば、標準的な方法でサービスを宣伝する方法を知っていて、コントロールノードが家庭用デバイスに接続してくれる。プラグインしてすぐに使えるのが理想だね。もちろん、これらはすべて組み合わせることもできるけど、概念的にはこのレベルで入れ替えたりミックスしたりできることが重要なんだ。選択肢と相互運用性が本当に大事。これらのパーツはたくさん存在してるけど、うまく連携してない。シンプルな標準の「これを買って、電源入れて、ローカルネットワークとペアリングする」みたいなプラグアンドプレイ環境はないんだ。私のコアな要求はプライバシーで、ユニタスカーを引き継いで、他のものともうまく連携すること。私がローカルなものを買う理由があるんだ。もし電話をかけてきたり、アカウントを設定させたりするなら、たぶんその製品は買いたくない。『フレディ、10分のタイマーをセットして』とか『フレディ、サウスダコタの一番の観光名所は何？』って言えるようにしたいんだ（もし気になるなら、ウォールドラッグスだよ）。

└

これも楽しみだな。HAからChatGPTへのスムーズな音声体験を得るのに問題があったんだ。受信機のウェイクワードの概念も好きじゃない。全体的にまだまだ改善の余地があると思う。

└

まだプラグアンドプレイのものはないけど、Home AssistantとHome Assistant Voice Preview版で素晴らしい成功を収めてるよ。目標はほぼAlexaを排除することだと思う。家の中にはWi-Fi + マイク + スピーカーが揃った安いデバイスがたくさんあって、それらが実際の音声処理ボックスにストリーミングされる感じかな（ちょっと高くなるけど、必要なデータにはローカルアクセスもできる）。これがホスト上で動いてる別のプログラムになるのはすぐに分かるから、少しパワフルなマシンを使ってWi-Fiカードを追加すれば、Wi-Fiエクステンダーもできるよ。

└

おもちゃもね。

└

そんなのは絶対にないよ。なんでか分かる？巨大企業があなたのデータを吸い上げて、広告をカスタマイズできなくなるからだよ。いいものを一度だけ売るより、広告だらけのクソみたいなソフトを毎月サブスクリプションで売った方がいいじゃん。

└

ここ数年、ちょこちょここれに取り組んでるけど、確実に進展してると思う。今の時点で可能だとは思うけど、まだ簡単ではないね。

└

最新のチャットボットは、単なるLLM推論だけじゃなくて、どんどん機能が増えてるね。ウェブ検索したり、ファイルを処理したり、他のアプリと統合したりできるんだ。だから、ほとんどの人がローカルLLMはすぐに不十分だと考えるようになると思うよ。

Pi 5 16GBで最新のllama.cppを使ってこれを再現しようとしたんだけど、セグメンテーションフォルトが出た。./build/bin/llama-cli -m "models/Qwen3-30B-A3B-Instruct-2507-Q3_K_S-2.70bpw.gguf" -e --no-mmap -t 4 ... モデルを読み込み中... -ggml_aligned_malloc: メモリ不足（24576.00 MBの割り当てを試みた） ggml_backend_cpu_buffer_type_alloc_buffer: サイズ25769803776のバッファの割り当てに失敗 alloc_tensor_range: サイズ25769803776のCPUバッファの割り当てに失敗 llama_init_from_model: コンテキストの初期化に失敗: kvキャッシュのためのバッファの割り当てに失敗 セグメンテーションフォルト。どうやって動かしてるのか分からない...彼らの結果を再現するためのガイドはある？セグメンテーションフォルトが出る前に、10GB以上のRAMを使ってるのをbtopで見てたよ。[編集: コンテキストサイズを減らすために-c 4096を追加したら、今は読み込めるようになった]

└

スワップを追加した可能性はある？

└

https://codeberg.org/ikawrakow/illama や https://github.com/ikawrakow/ik_llama.cpp、あとは彼らの4Bit-quantsを試したことある？それともMicrosoftのBitnetとか？ https://github.com/microsoft/BitNet https://github.com/ikawrakow/ik_llama.cpp/pull/337 https://huggingface.co/microsoft/bitnet-b1.58-2B-4T-gguf みたいな、ローカルのLLMを低スペックなデバイスで動かすのは面白い比較になると思うよ。普通のオフィスのマシンでもiGPUだけで動くし。

いろんなモデルを簡単に比較できる良い場所ってある？gpt-oss-20bとgpt-oss-120bはパラメータの数が違うのは知ってるけど、実際にはそれが何を意味するのか分からないんだ。AIの経験は大きいモデル、例えばGeminiやGPTでしかないから、自分のハードウェアでモデルを動かしたいけど、どれくらい小さいのが使えるのか、スペルや文法の修正みたいな簡単なことから、プログラミングみたいな複雑なことまで、役に立つ出力が得られるか分からない。

└

https://swe-rebench.com/

└

いろんなモデルを試す簡単な方法は、Open Routerみたいなサイトから20ドル分のトークンを買うことだよ。これでたくさん質問できるし、いろんなモデルを試せる。現実的には、今のところ手頃な価格で動かせる最大のモデルは、Qwen3 30B A3Bファミリーの量子化されたバージョンだね。4ビットの量子化版は大体15GBのRAMに収まる。Nvidia 3090みたいなものでうまく動くよ。でも、普通のRAMでも使えるけど、ちょっと遅くなるかも。これらのモデルはGPT 5やOpus 4.5とは競争にならないけど、GPT-4oよりは大体みんな明らかに良いよ。30Bモデルの中には基本的なエージェントコーダーとして動くものもあるし、小さいシステムに収まる4Bから8Bのモデルもいくつかある。例えば、8Bモデルは素晴らしい翻訳者になれるよ。（お金と忍耐があれば、GPT OSS 120BやGLM 4.5 Airをローカルで動かすこともできるけどね。）

これにはスケールでカスタム推論チップが必要だと思う。どんな形状やボードのコンピュータでも、推論ユニットがあれば、少なくとも推論が効率的で速くなるし、CPUが他のことをしている間にオフロードできるからね。

└

これがダウンボートされるなんて信じられない。マスカスタム推論チップがあればめっちゃ役立つのは納得できるよね。

└

このOrange Pi 6+ボードのスペック見てみて - 専用の30 TPU NPUがあるよ。 https://boilingsteam.com/orange-pi-6-plus-review/

「30B」モデルって呼ぶのはちょっと誤解を招く気がするな。実際には30B-A3Bで、同時にアクティブなのは3Bのパラメータだけなんだ。それでもすごいけど、密な30Bと比べて「A3B」で8T/sを出せるのは全然違うよ。

└

3Bのパラメータが同時にアクティブってどういうこと？これってCPUだけの話なのか、それともPiのGPUも使ってるの？

└

ちょっと好奇心で、Qwen3-30B-A3B-Instruct-2507-Q3_K_S-2.70bpw.gguf（Raspberry Piに推奨されてるバージョン）をBlackwell GPUで試してみた。プライベートベンチマーククエリで200以上のトークンを秒間に出力して、驚くほどシャープだった。3Bのアクティブパラメータから期待される以上のパフォーマンスを発揮してる。これがあればスピルバーグの「AI」に出てくるクマを作れるかも、子供は無理かもしれないけど。

要するに、バイトシェイプモデルの量子化はテンソルごとに変わるってこと？最終結果は「平均」になるのかな？結果は良さそうだけど、なんでこれがもっと普及してないのか気になる！「精度」に影響する要因も知りたいな、測定方法によってニュアンスがあるかもしれないし。

└

「精度」に何が影響するのか、もう少し理解したいな。測定方法によってニュアンスがあるかもしれないし。GSM8K、MMLU、IFEVAL、LiveCodeBenchでの精度についてだね。彼らの方法論はここに詳しく書いてあるよ: https://byteshape.com/blogs/Qwen3-4B-I-2507/

LLMは定義上、どんな速度でもリアルタイムだよ。1秒間に50,000トークン？リアルタイムだね。1分間に0.0002トークン？それでもリアルタイム。1秒間に8トークンっていうのも「リアルタイム」って言えるけど、それって昔のビデオゲームをバカにしてた速度でもあるよね。画面に文字が1文字ずつ、または単語ごとにゆっくり表示されるやつ。

└

この文脈で「リアルタイム」って言うと、たいてい「返信を読むのと同じ速さ」って意味だから、0.0002トークン/分は「リアルタイム」とはみなされないよね。

なんか適当に言ってるけど、特定のモデルにFPGAが役立つ分野ってあるのかな？