ハクソク

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

BitNet: 100Bパラメータの1ビットモデルをローカルCPU向けに

49日前原文(github.com)

概要

  • bitnet.cppは1ビットLLM推論用の公式フレームワーク
  • CPU・GPUで高速かつ省エネな推論を実現
  • ARM/x86両対応、モデルサイズが大きいほど効果増
  • インストール・実行手順が明確に提供
  • FAQやベンチマーク、変換ツールも充実

bitnet.cppの特徴と概要

  • bitnet.cppは、BitNet b1.58などの**1ビット大規模言語モデル(LLM)**向け公式推論フレームワーク
  • CPUおよびGPUでの高速・損失なし推論をサポート（今後NPUにも対応予定）
  • 最初のリリースはCPU推論対応、ARM CPUで最大5.07倍、x86で最大6.17倍の高速化
  • エネルギー消費も大幅削減（ARMで最大70%、x86で最大82.2%削減）
  • 100B規模のモデルも単一CPUで人間並みの速度（5～7トークン/秒）で動作可能
  • 並列カーネルや量子化埋め込みなど最新最適化も導入済み
  • llama.cppをベースに開発、T-MACのLookup Table技術も活用

公式モデル・対応モデル

  • BitNet-b1.58-2B-4Tなど複数の1ビットLLMモデルをサポート
  • Hugging Face公開モデルを利用した推論デモも提供
  • ARM/x86両対応、モデルごとにカーネル最適化状況が異なる
    • 例: bitnet_b1_58-large（0.7B）、bitnet_b1_58-3B（3.3B）、Llama3-8B-1.58-100B-tokens（8.0B）など

インストール要件・セットアップ

  • Python>=3.9、cmake>=3.22、clang>=18が必要

  • Windowsの場合、Visual Studio 2022のC++開発ツール一式が必要

  • Debian/Ubuntuでは自動インストールスクリプトを提供

  • conda環境の利用を推奨

    • リポジトリのクローン
      • git clone --recursive https://github.com/microsoft/BitNet.git
      • cd BitNet
    • 依存関係のインストール
      • conda create -n bitnet-cpp python=3.9
      • conda activate bitnet-cpp
      • pip install -r requirements.txt

モデルのダウンロードと実行

  • モデルの手動ダウンロード
    • huggingface-cli download microsoft/BitNet-b1.58-2B-4T-gguf --local-dir models/BitNet-b1.58-2B-4T
  • 環境セットアップ
    • python setup_env.py -md models/BitNet-b1.58-2B-4T -q i2_s
  • 推論実行例
    • python run_inference.py -m models/BitNet-b1.58-2B-4T/ggml-model-i2_s.gguf -p "You are a helpful assistant" -cnv

コマンドラインオプション

  • setup_env.py

    • --hf-repo：利用するHugging Faceリポジトリ指定
    • --model-dir：モデルディレクトリ指定
    • --quant-type：量子化タイプ指定（i2_s, tl1）
    • --quant-embd：埋め込みの量子化有効化
    • --use-pretuned：事前チューニング済みカーネルパラメータ利用

  • run_inference.py

    • -m：モデルファイル指定（必須）
    • -n：生成トークン数
    • -p：プロンプト指定
    • -t：スレッド数
    • -c：プロンプトコンテキストサイズ
    • -temp：生成テキストのランダム性制御
    • -cnv：チャットモード有効化

ベンチマーク・ダミーモデル生成

  • ベンチマーク実行
    • python utils/e2e_benchmark.py -m /path/to/model -n 200 -p 256 -t 4
  • ダミーモデル生成
    • python utils/generate-dummy-bitnet-model.py models/bitnet_b1_58-large --outfile models/dummy-bitnet-125m.tl1.gguf --outtype tl1 --model-size 125M
    • 生成したダミーモデルでベンチマークが可能

safetensorsからの変換

  • .safetensorsモデルの準備
    • huggingface-cli download microsoft/bitnet-b1.58-2B-4T-bf16 --local-dir ./models/bitnet-b1.58-2B-4T-bf16
  • ggufモデルへの変換
    • python ./utils/convert-helper-bitnet.py ./models/bitnet-b1.58-2B-4T-bf16

FAQ（よくある質問）

  • Q1: llama.cppビルド時にstd::chronoのエラー発生？
    • A: llama.cppのバージョン問題。該当コミットを参照し修正
  • Q2: conda環境のWindowsでclangビルド時にエラー？
    • A: clang -vで環境確認。Visual Studioツールの初期化コマンドを実行
      • コマンドプロンプトの場合: "C:\Program Files\Microsoft Visual Studio\2022\Professional\Common7\Tools\VsDevCmd.bat" -startdir=none -arch=x64 -host_arch=x64
      • PowerShellの場合: Import-Module "C:\Program Files\Microsoft Visual Studio\2022\Professional\Common7\Tools\Microsoft.VisualStudio.DevShell.dll"、Enter-VsDevShell 3f0e31ad -SkipAutomaticLocation -DevCmdArguments "-arch=x64 -host_arch=x64"

まとめ

  • bitnet.cppは超軽量・高速な1ビットLLM推論の最先端フレームワーク
  • ローカル環境・エッジデバイスでのLLM運用を大きく前進
  • モデル・OSごとの詳細な導入手順・FAQも完備
  • 今後のGPU/NPU対応やさらなる最適化にも期待

Hackerたちの意見

でも、トレーニング済みの100Bパラメータモデルはないの？「100B BitNetを実行できる」ってのは推論の実装についての話で、そんなモデルが存在するかどうかの話じゃないよ。
└
ダミーモデルを使ったんじゃないかな、そうじゃなきゃリンクしてたはずだし。「1-bit 100b model」でググってみて、ダウンロードリンクは一切ないこのプロジェクトの参照しか見つからないよ。
タイトルが誤解を招くね。トレーニング済みの100Bモデルはなくて、ただそれを扱えるって主張してる推論フレームワークがあるだけ。だけど、エンジニアリングには注目する価値があるよ。私はローカルで量子化された70Bモデルを動かしてる（M2 Max 96GB、llama.cpp + LiteLLM）。メモリ帯域幅が常にボトルネックになってる。1.58ビットのアプローチは面白いね。三元重みが行列積を加算に変えるから、一般的なCPUでの計算プロファイルが根本的に違う。もし100Bクラスのモデルで1つのCPUあたり5-7トークン/秒が再現できるなら、デバイス上での推論にとっては本当に大きなマイルストーンだよ。フレームワークは準備できてる。あとは実際にモデルをトレーニングする人が必要だね。
└
そうだね。2回読み直さなきゃいけなかったけど、ベースモデルがないのは変だなって思ったよ。でも、利用可能な最大モデルは10Bみたい？ちょっと珍しいし、100Bオーダーのモデルをトレーニングするのがどれだけ難しいか気になるな。
└
カスタムハードウェアの面白い機会だと思ってる。2ビットの加算はハードウェアで非常に安価だから、特に浮動小数点を使うものと比べるとね。安くて巨大なベクター命令を作って、買える中で最速のメモリに接続すれば、十分に能力のある推論チップができるよ。トレーニングにはフルGPUがまだ必要だけど、推論にはNvidiaが作ってるものよりもずっとシンプルなハードウェアで済むはずだよ。
└
> フレームワークは準備完了。今は実際にモデルをトレーニングしてくれる人が必要だね。もしマイクロソフトが自分たちの理論を証明するためにモデルをトレーニングしないなら、他の誰がやるっていうの？彼らは少なくとも何らかの形でBitNetを証明するために2年（だったかな？）も時間があったのに、今まで本当に何も試してないって言うの？個人的には、彼らの言うことをそのまま信じるのはちょっと心配だな。もしこれが本当に価値のある結果につながるなら、なんで自分たちでモデルをトレーニングして公開しないの？
└
LLMアカウント
└
> コモディティCPUでの根本的に異なる計算プロファイルって、どのように？現代のプロセッサでは、Fused Multiply-Add（FMA）命令は基本的な加算命令と同じ実行スループットを持っているよ。
└
デモでは3Bモデルを動かしてるみたい。
└
これは（意図的に？）誤解を招くドキュメントから来てるよね。https://github.com/microsoft/BitNet/issues/391 （こんなに長い間そこにあるから意図的だと思ってる）
└
テキストも誤解を招くよ。5-7トーク/secは読書速度じゃなくて、ちょっと遅い。少なくとも僕にとっては、経験豊富な読者だけど、特に速読に特化してるわけじゃないし。7.0-7.5トーク/secの出力速度で「生活」してた時期があって、それはイライラする体験だった。ちょっと遅い人の後ろを歩いてる感じだよね。これを解決するために、出力が「バッファリング」されるまでわざと目を逸らして、そっから読み始めた。ローカル設定では10トーク/secを目指したいね。kvキャッシュを少し犠牲にして、GPUにもう少しレイヤーを追加する価値はあるよ。
└
> メモリ帯域幅が常にボトルネックだね。今日の不満が明日のイノベーションにつながることを期待してる。1MBのハードドライブが10万ドルだった頃や、ゲイツが640KBで十分だと言った時を思い出す。今、RAMメーカーが何をしているのか、業界の人にコメントしてもらいたいな。もっと良く、速く、大きくなってるのかな？それとも、もう余裕がなくてマザーボードメーカーやボリュームに依存してるのかな？
└
タイトルが誤解を招くのも重要だよね。これがフロントページに載ってるけど、実際の注目すべき部分はそれだけだから。Hugging Faceのバナーにある「新しい」重みは11ヶ月前にアップロードされたもので、2Bパラメータだし。このリポジトリでの作業は2年前のものだよ。BitNetの発表に対する宣伝の量は、実際の提供内容と比べるとすごいね。
> bitnet.cppは1ビットLLM（例えば、BitNet b1.58）の公式推論フレームワークです。CPUとGPUで1.58ビットモデルの高速かつロスレスな推論をサポートする最適化されたカーネルのセットを提供しています（NPUサポートは次に来る予定）。1ビットか1トリットか？ちょっと混乱してる！
└
「1ビットLLM」ってのはただのマーケティングだね。3つのシンボルのアルファベット（-1, 0, 1）で1文字のシャノンエントロピーは1.58だよ。
└
うん、「1.58ビット」ってのは3つの状態を持つ1トリットのことだから、log2(3)≈1.58だよ。だから、これは1ビットモデル（パラメータごとに2つの状態）用の推論フレームワークじゃなくて、1.58ビットモデル（パラメータごとに3つの状態）用なんだ。両者を混同するのはイライラするね。
私がよく考えるのは、「どれが最小限の実用的なLLMになるのか」ってことだよ。十分な情報から動作して、残りをグーグルすれば合理的な答えを提供できるモデルね。エンサイクロペディア・ブリタニカみたいなところが、AIを活用してデータをLLMに売って、LLM企業の出力を検証することにまだ取り組んでないのが意外だな。いくつかの分野では大きな違いが出ると思う。ウィキペディアもいいけど、人間のエラーやバイアスが入り込む余地が多すぎるからね。
└
Wikipediaに対する心配は「人間のエラーやバイアスが多く残っている」ということだけど、前に言ってたのは、WWWにアクセスできるLLMは逆に人間のエラーやバイアスが少ないってこと？個人的には、逆だと思うけど。
└
> LLM企業の出力を検証するにはどうするの？彼らは何千、何百万ものクエリを検証できるけど、百万回目のクエリが幻覚になるのを防ぐものは何もないよね。「エンサイクロペディア・ブリタニカに検証されたLLM」にお金を払う人たちは、正当な理由で「それ」が危険なキノコで料理するように提案したって文句を言うと思う。
└
Google検索にはすでにAIの要約が含まれているから、あなたの最小限の「LLM」は単なるHTTP GETコールで済むかもね。
└
これは「最小限の実用的なLLM」ってより、自然言語をよく理解しているけど他は何も知らないLLMって感じ。例えば、一般的なトラブルシューティングはできるエンジニアだけど、特定のデバイス、例えば最近の例で言うと自分の暖房機については何も知らないみたいな。で、LLMがGoogleやWikipediaを調べられるとは思わないけど、このアーキテクチャはすごく理にかなってると思う。こういうエッジLLMを使うのが普通になるだろうね。
└
ウィキペディアは数十年にわたって百科事典と同じくらい正確だって証明されてるよね。それに、AI企業がもうエンサイクロペディア・ブリタニカのデータで不正にモデルを訓練してるって賭けてもいいよ。
└
それってRAGの一種じゃない？ユーザーの自然なプロンプトを検索に変換できるくらい「賢い」LLMが必要で、その後に何かの検索をして、最後に結果を要約するための「賢い」LLMが必要だよね。
これが引き続き開発されてるのを見るのはいいね。去年ちょっと調べたんだけど、すごく期待できそうだったから、新しいモデルが出なかったのはめっちゃ残念だった。
└
このアプローチはあんまり面白くないと思うな。結局、フル精度モデルの量子化に過ぎないから。推論は速くなるけど（品質のペナルティあり）、トレーニングは速くならないし。実際にバイナリモデルを直接トレーニングする方が面白いと思うよ、浮動小数点の掛け算なしでね。この論文みたいに： https://proceedings.neurips.cc/paper_files/paper/2024/hash/7...
https://arxiv.org/pdf/2310.11453 元の論文 [fig 1, bottom-right] にはfp16モデルの約4-5倍のパラメータが必要だって書いてあるみたい。構築していくつかのモデルを実行することはできるけど、ゼロから訓練しなきゃいけないから選択肢は限られてる。現代のPTQ（4ビットや8ビットの量子化）と比べると推論速度は速いと思うけどね。
エネルギーの数字が本当に重要だね。CPU推論で70-82%の削減ができるなんて。もし1ビットモデルが十分に良くなれば、GPU予算なしで一般的なハードウェアで動かせるようになるから、LLMを展開できる人が変わるよね。速度のベンチマークより、こっちの方が面白いと思う。
NPU搭載のPCの恩恵がいつ現れるのか気になるな。AMDはNPU/iGPUハイブリッドの推論カーネルでいい仕事してるし。もしこれらの大きなモデルがNPUで動かせるようにスケールダウンできれば、CPUで動かすよりもずっと良い電力のメリットが得られるはず。
└
Rockchip RK3588のSBCでは、結構たくさんのモデルをNPUsで動かせるよ。クロード4.6みたいなものでは全然ないけど、ちょっと不安定なソフトウェアエコシステムを乗り越えれば、小さいLLMをほぼCPU/GPUを使わずにそこそこ動かせる。
ここでの大きな問題は、誰もBitLinearアーキテクチャでこの規模の競争力のあるモデルを実際に訓練していないことだね。フレームワーク自体は素晴らしいエンジニアリングだけど、元のBitNetの論文は約10Bパラメータまでしか検証していないし、ネイティブ1.58ビットの訓練とフル精度モデルの後処理量子化の間の品質のギャップは、量子化技術が進むにつれて狭まっていく。GGUFのQ2とQ3の量子化はどんどん良くなっていて、基本的なトレーニングパイプラインを必要とせずに一般的なハードウェアで動かせるようになってる。実際の問題は、三値重みの理論的な計算優位性が100Bスケールの実際の損失ランドスケープと接触しても生き残るのか、それとも小規模な実験では明らかにならなかった品質の崖にぶつかるのかってことだね。
└
品質の崖についての質問は、まさに聞くべきことだと思う。システムの作業には、理論的にはきれいにスケールするものが、実際のスケールで見えない失敗モードにぶつかるパターンがある。損失ランドスケープの懸念はまさにその種のもので、誰も実際に実験を行ったことがない。とはいえ、GGUFの量子化の改善との比較は、ちょっと違うと思う。後処理量子化は、高精度で表現を学んだモデルを圧縮することだから。ネイティブ三値訓練は、最初からもっと厳しい制約の下で同じように表現力のある表現を学べるというアーキテクチャの賭けをしている。これは異なる提案で、異なるスケーリング特性を持っている。BitNetの論文は、小規模ではネイティブアプローチが勝つことを示唆しているけど、それは比較対象の量子化ベースライン（Llama 3の1.58ビット）が単に悪かったからかもしれない。フル精度モデルは、そのレベルの圧縮に耐えるようには設計されていないからね。重要なのは、真剣に計算リソースを持っている誰か（Microsoftではないらしい）が、推論コストの節約がフルトレーニングを正当化するかどうかを決めることだね。フレームワークが存在することで一つの障壁は下がるけど、もっと重要な障壁は、失敗した100Bのトレーニングは非常に高価で、今のところそれをリスクを減らすための十分な証拠がないことだ。2年間のフレームワークの磨き上げがあっても、フラッグシップモデルがないのは目立つ欠如だね。
└
> その間、GGUFのQ2とQ3の量子化は llama.cpp でどんどん良くなってる。 これについてもっと教えてくれない？約1年前に調べたけど、Q4以下ではパフォーマンスがかなり落ちてるように見えた。もっと詳しく知りたいな。それと、どうやって実行するのがいいの？私は主にOllamaを使ってるけど、Q4までしか対応してないと思う。でもHFのURLはサポートしてるはずだよね？
READMEにデモ動画があるよ。BitNetが速いってことを伝えようとしてるみたいだけど、実際に何をそんなに早くやってるのか、ちょっと考える時間を持つ価値があると思う。水の循環が地球上のすべての生物のエネルギーの主な源だって繰り返していて、Jenkins 2010を引用してるみたい。あと、「それに加えて…」で始まる文がたくさんあるけど、これも正しくないと思う。太陽がほとんどの生物のエネルギーの主な源だけど、熱水噴出孔の近くにも生命があるしね。Jenkinsが誰なのかは知らないけど、このモデルは彼らと水に関する特定の事実が好きみたいだね。速くて不正確なのは、遅くて不正確なのよりはマシだと思う。