Burn 0.21とは？Rust製ディープラーニングフレームワークのバックエンド選定と実装手順

Burnは、モデル定義から学習・推論・GPUカーネルまでをRustだけで書ける深層学習フレームワークです。2026年9月23日時点の最新安定版は 0.21.0（2026年5月7日公開）で、この1年で分散学習・量子化・CPUバックエンドが立て続けに入り、設定ファイルや推奨バックエンドの構成も変わりました。

この記事では、Burn 0.21で選べるバックエンドの対応表、0.18からの各リリースで何が変わったか、cargoでの導入と実行確認、学習済みモデルの読み込み形式、そしてRustの機械学習クレート全体の中でBurnをいつ選ぶかまでを、公式リリースノートと実機で確かめた結果にもとづいて整理します。テンソル演算の最小コードは Rust 1.98.0 と burn 0.21.0 で実際にコンパイル・実行し、出力をそのまま載せています（モデル読み込みの節だけは、モデル定義を省いた処理の断片です）。

まとめ

• 最新安定版は 0.21.0（2026年5月7日公開）で、必要なRustは 1.92 以上です。開発版として 0.22.0-pre.4（2026年9月22日）も公開されています。
• バージョンの確認は cargo tree -p burn --depth 0、更新は cargo update -p burn です。導入は cargo add burn --features <バックエンド名> の1行で済みます。
• CPUバックエンドの推奨が変わりました。従来の burn-ndarray は非推奨（deprecated）となり、WebAssembly・組み込み向けの軽量バックエンド burn-flex か、CubeCLベースのCPUバックエンドへ移行する形になっています。
• 設定ファイルも cubecl.toml からプロジェクト直下の burn.toml へ集約され、オートチューニングやFusionの挙動を再コンパイルなしで変更できます。
• 0.21.0の目玉は分散学習とフレームワークオーバーヘッドの削減です。公式計測では、Fusion有効時のオーバーヘッドが平均5.4倍・最大8.2倍、4GPUでのデバイス間転送が最大21.2倍速くなっています。
• Burnは「Rustで学習まで回す」場合の選択肢です。学習済みモデルを推論するだけなら ort や candle、古典的な機械学習なら linfa のほうが近道になります。

Burnとは：Rustだけで学習から推論まで完結する深層学習フレームワーク

Burnは、カナダのTracel AIが中心となって開発しているオープンソースの深層学習フレームワークです。PyTorchやTensorFlowがフロントエンドにPython、計算の本体にC++／CUDAを置く二層構成であるのに対し、Burnはテンソル演算・自動微分・学習ループ・GPUカーネルまでをすべてRustで記述します。

crates.ioのAPIで2026年9月23日に取得した時点で、burn の累計ダウンロードは1,447,497件、直近90日分は438,844件です。リリース間隔はおよそ3〜4か月で、0.18.0（2025年7月18日）から0.19.0、0.20.0を経て0.21.0（2026年5月7日）まで、開発ペースは安定しています。なお推論寄りの candle-core は同じ時点で累計8,391,439件と配布数では上回っており、ダウンロード数だけでRust製フレームワークの優劣は測れません。用途が違うためです。

二言語問題を避ける設計と、その代わりに引き受けるコスト

Pythonの実行コードを含めて配布する構成では、デプロイ先にもPython実行環境が必要になり、バインディング層のオーバーヘッドやビルド環境の差異が問題になります。Burnはここを単一言語に寄せることで、静的リンクした単一バイナリとして配布でき、コンパイル時にメモリ安全性とスレッド安全性が検査されるという利点を得ています。

一方で、引き受けるコストもはっきりしています。Pythonの学習済みモデルやデータ前処理の資産がそのまま使えるわけではなく、多くの場合はONNXやSafeTensors経由での持ち込みになります。またコンパイル時間はPythonの実行と比べれば確実に長く、後述のとおり最小構成でも初回ビルドに数分かかります。Burnの開発陣自身もこの点を課題として認識しており、0.21.0ではコンパイル時間の短縮を見据えた burn-dispatch クレートが導入されました。

CubeCLとの関係：カーネルを書く層とモデルを書く層

Burnを調べると必ず出てくるのが CubeCL です。これはBurnの姉妹プロジェクトで、GPU向けの計算カーネルをRustで一度書けばCUDA・ROCm・Metal・Vulkan・WebGPUで動かせるようにするコンパイラ兼言語です。CubeCLはBurnから独立して単体でも利用できます。

役割分担としては、CubeCLが低レベルのカーネルとランタイムを担い、Burnがテンソル・モジュール・学習ループといった利用者向けAPIを担います。CubeCL系バックエンドの性能にはカーネル実装だけでなく、Fusionや実行管理も影響します。後述する0.21.0の改善には、Burn側のデバイスハンドルや集合通信の変更も含まれます。CubeCLの最新安定版は 0.10.0（2026年5月7日）で、Burn 0.21.0と同日にリリースされています。

Burn 0.21のバックエンド一覧と選び方

Burnの最大の特徴は、同じモデルコードのままバックエンドを差し替えられる点です。どのバックエンドがどのハードウェアで使えるかは、公式リポジトリの v0.21.0タグのREADME（Supported Backends）に対応表があり、次のとおりです。

GPUバックエンドの対応ハードウェア

複数ベンダーのGPUを対象にする場合は、対応OSとGPUを確認してVulkanまたはWebGPUを選び、NVIDIAで性能を出し切りたい場合はCUDA、Apple SiliconではMetalという選び分けになります。ブラウザ上でGPUを使う経路はWebGPUです。CPU実行にはWebAssembly向けのFlexも使えます。WebGPUの実装そのものについては、wgpuとは？RustでWebGPUを扱う仕組みと最小サンプル・主要APIで別途解説しています。

CPUバックエンドの対応と、burn-ndarrayの非推奨化

ここが0.21.0で大きく変わった部分です。長らくCPU実行の既定だった burn-ndarray は非推奨になり、crates.ioの説明文にも[Deprecated] Ndarray backend for the Burn framework - use burn-flex, burn-cuda, burn-rocm, or burn-wgpu insteadと明記されています。0.21.0の公式リリース記事でも、既存プロジェクトの移行期間として動作は維持するものの、あと1〜2リリース残してから削除する予定だと告知されています。

代わりに入った burn-flex は、Rustだけで書かれた純粋な先行評価型（eager）のCPUバックエンドです。JIT・オートチューニング・カーネルFusionをあえて持たず、burn.toml による設定にも対応しません。WebAssemblyや組み込み、小さなモデルの推論では、コンパイラやスケジューラが挟まらない予測しやすい実行のほうが望ましいという判断です。

ただし、0.21.0の時点で burn-ndarray が使えなくなったわけではありません。burn クレートのフィーチャ一覧には ndarray が残っており、cargo add burn --features ndarray は通ります。削除されたのではなく、READMEのCPUバックエンド対応表から外れて flex と cpu に置き換わった段階です。

性能が必要なCPU実行では、CubeCLベースの Cpu バックエンドを選びます。こちらはMLIRとLLVMを使ったJITコンパイル・オートチューニング・Fusionを備えます。なお、LibTorchバックエンド（burn-tch）も開発版0.22.0系のリリースノートに chore: deprecate burn-tch backend として非推奨化が入っているため、新規にLibTorchを前提に組むのは避けるのが安全です。

0.18から0.21までのリリース履歴と変更点

Burnは日本語の解説記事が版ごとに散らばっており、手元の情報が何バージョン時点のものか判別しづらい状態です。各版の公開日と最小Rustバージョン（MSRV）、主な変更点を一覧にします。公開日とMSRVはcrates.ioのバージョン一覧、変更点はGitHubのリリースノートと公式ブログの各リリース記事にもとづきます。

0.19.0：分散学習・量子化・MLIRベースのCPUバックエンド

複数GPUを使い切るために、実行キューを並行化するマルチストリーム実行が入りました。CUDAではストリームという概念が元からありますが、WGPUランタイムには相当する仕組みがないため、Burn側で独自のスケジューラを実装して異なるストリームのカーネルを交互に流す形を取っています。実装上は、新しいスレッドでテンソル演算を実行すると新しいストリームが作られる設計です。勾配同期には burn-collective が導入されました。

量子化も本格的に入り、量子化スキーム・量子化モジュール・融合した逆量子化・量子化行列積が揃いました。モデルのメモリ使用量を落としたい場合の選択肢が増えています。量子化そのものの考え方は、量子化（モデル量子化）とは？仕組み・PTQとQATの違いと実装判断を解説【2026年版】にまとめています。

さらに、MLIRのvectorダイアレクトを経由してLLVMへ降ろす新しいCPUバックエンドが追加されました。ただし0.19.0の公式リリース記事は「この版ではまだ強い性能は期待しないでほしい」と明言しており、CPU向けのカーネル最適化はこの後の版に持ち越されています。

0.20.0：CubeKによるCPU/GPUカーネル統合とONNXインポート刷新

0.20.0では CubeK という新プロジェクトが導入されました。カーネルの構造に厳しい指針を設け、ハードウェア特化やエラー処理を起動のたびに行うのではなく、JITコンパイル時に一度だけ済ませてキャッシュする方式に切り替えたものです。結果としてカーネル起動時のCPU側オーバーヘッドが下がりました。

CPUバックエンドの効果はベンチマークに現れています。0.20.0の公式リリース記事が公開したMax Pool 2D（形状 2×128×512×512）の実測では、CubeCLのCPU実行が5.73ミリ秒だったのに対し、LibTorchは18.51ミリ秒、SIMDを有効にしたndarrayは80.30ミリ秒、SIMDなしのndarrayは1.085秒でした。この条件での倍率は約3.2倍で、公式が本文で述べている「最大4倍」は、ほかの条件も含めた幅のうちの上限です。いずれにせよ、この差は max_pool2d のロジックを変えずに起動戦略だけを見直して得られたものだと説明されています。

ONNXインポートも作り直されました。ノード単位のアーキテクチャに組み替えられ、新形式のburnpackを使ったメモリマップによるゼロコピー読み込みに対応しています。ビルドスクリプトからONNXモデルを読み込み、Rustのコードと重みファイルを生成する仕組みです。なお、ONNXインポートが burn-onnx として本体リポジトリから独立したのは0.20.0のリリース後で、別リポジトリが公開されたのは2026年1月27日、独立後の最初のリリースは burn-onnx 0.21.0（2026年5月11日公開）です。旧 burn-import は互換用のシムとして残されています。ONNX自体の位置づけはONNXとは？モデル変換・推論の仕組みと使い方を初心者向けに解説で扱っています。

なお0.20.0は学習APIに破壊的変更があり、LearnerBuilder が SupervisedTraining を起点とする流れへ置き換わりました。0.19以前のサンプルコードはそのままでは動きません。

0.21.0：オーバーヘッド削減・burn.toml・burn-flex

0.21.0は4か月分の改善をまとめた版で、性能面の主役は分散学習とフレームワークオーバーヘッドです。

分散側では、集合通信を微分可能な演算として作り直しました。0.21.0の公式リリース記事が示す4枚のCUDA GPUでの計測では、デバイス間転送 to_device が形状 32×512×1024 で21.13ミリ秒から1.29ミリ秒へ（16.4倍）、形状 128×512×2048 で170.44ミリ秒から8.03ミリ秒へ（21.2倍）短縮されています。all_reduce も同じ2形状で6.3倍・6.2倍の改善です。

オーバーヘッド側では、デバイスハンドルの実装を再帰ミューテックスから専用の通信チャネルへ置き換えました。小さな形状（1×8×8×8）でスレッド数を1から16まで変えた計測では、Fusion有効時の平均で5.4倍、最も重い16スレッドの条件で8.2倍（733.06ミリ秒から89.19ミリ秒へ）改善し、計測した構成の中で性能が落ちたものは無かったと報告されています。

カーネル単体ではGEMV・top-k・FFTが改善対象でした。ここは公式が良い数字だけを並べていない点が参考になります。形状 4096×4096 の列優先GEMVでは、CUDA上でCubeCLが174マイクロ秒に対しLibTorchが171マイクロ秒とほぼ互角、CPUではCubeCL 1.451ミリ秒に対しLibTorch 1.626ミリ秒でCubeCLが上回りました。一方で行優先のGEMVはCUDAでCubeCL 231マイクロ秒に対しLibTorch 177マイクロ秒と負けており、公式も「行優先はまだ最適ではない」と認めています。

top-kも同様で、CPU上ではCubeCLがLibTorchより41.8倍速い条件（k=1、axis=0、形状 16×1024×1024 で645マイクロ秒対26.94ミリ秒）がある一方、最終軸（axis=2）でk=10のような条件ではLibTorchの専用カーネルが1.36〜1.42倍速いと明記されています。「どの条件でも常に速い」という書き方はされていないので、採用判断では自分のワークロードに近い形状で測り直すのが現実的です。

インストールとバージョン確認・更新の手順

Burnプロジェクトの作成と依存クレート追加

以下はFlexを使う導入例です。GPUバックエンドでは対応ドライバーやSDKなども必要になります。Burn 0.21.0のMSRVは1.92なので、それ以前のRustを使っている場合は rustup update を先に実行します。

cargo new my_burn_app
cd my_burn_app
cargo add [email protected] --features flex
cargo build

フィーチャ名がそのままバックエンドの指定になります。GPUを使うなら wgpu・cuda・metal・vulkan・rocm、CPUなら flex か cpu を指定します。自動微分が必要なら autodiff、学習ループやダッシュボードが必要なら train を足します。cargoの基本的な使い方はCargo（Rust）とは？インストールと使い方・主要コマンド一覧にまとめています。

初回ビルドには相応の時間がかかります。実測環境（Intel Mac・macOS・Rust 1.98.0・burn 0.21.0・キャッシュを持たない新規プロジェクト）で cargo run を計測したところ、flex のみの最小構成で依存クレートを含め3分35秒、wgpu を指定した場合は5分22秒（このとき target ディレクトリは1.0GB）でした。マシンや依存関係、キャッシュの状態で変わる値なので、桁感の目安として見てください。

なお cargo add [email protected] --features wgpu の出力には「62 deactivated features」と表示されます。burn の既定フィーチャに含まれるのは std と各クレートの既定設定だけで、バックエンドはひとつも既定では有効になりません。どれか1つはフィーチャで明示する必要があります。

Burnの使用バージョン確認と更新

cargo tree -p burn --depth 0
cargo update -p burn

前者は解決済みの実バージョンを1行で表示します。実行すると burn v0.21.0 と返りました。Cargo.toml に書いたバージョン指定と、実際にロックされている版がずれていないかはこれで確認できます。後者は Cargo.toml の指定範囲内で最新へ上げます。メジャー相当の更新（0.20系から0.21系など）は指定範囲を跨ぐため、Cargo.toml 側の記述を書き換えてから実行してください。

Burnは0.x系のため、マイナー版の更新でも破壊的変更が入ります。0.19の学習ストラテジー、0.20の学習API再設計、0.21のパディング指定やモジュール派生マクロの変更はいずれも移行作業を伴うので、更新時は各リリースノートの移行ガイドを先に読むことをおすすめします。

テンソル加算の最小コードと実行結果

導入できたか確かめるための最小コードです。2×2の行列に全要素1の行列を足すだけのものですが、バックエンドが正しく選ばれているかまで出力で確認できます。

use burn::tensor::{Tensor, backend::Backend};

fn computation<B: Backend>() {
    let device = Default::default();

    // 2x2 の行列を作る
    let tensor1: Tensor<B, 2> = Tensor::from_floats([[2.0, 3.0], [4.0, 5.0]], &device);

    // 同じ形状で全要素が 1 のテンソルを作る
    let tensor2 = Tensor::ones_like(&tensor1);

    println!("{}", tensor1 + tensor2);
}

fn main() {
    computation::<burn::backend::Flex>();
}

ジェネリクス B: Backend でバックエンドを抽象化しているため、main の型引数を差し替えるだけでCPUからGPUへ移せます。実際、フィーチャを wgpu に変えて型引数を burn::backend::Wgpu にしたものも、関数の中身は1文字も変えずにコンパイルが通り、そのまま実行できました（WGPUで実行する場合は、WebGPUが使えるGPUアダプタを取得できる環境が要ります。取得できないと No possible adapter available for backend で停止します）。Default::default() が返すデバイスはバックエンドごとに異なるため、デバイスの指定もコードに書かずに済みます。

実行結果は次のとおりです。burn 0.21.0・Rust 1.98.0で実際に cargo run して得た出力をそのまま載せています。

Tensor {
  data:
[[3.0, 4.0],
 [5.0, 6.0]],
  shape:  [2, 2],
  device:  Cpu,
  backend:  "flex",
  kind:  "Float",
  dtype:  "f32",
}

backend の行に、実際に使われたバックエンドが出ます。ここは選んだバックエンドによって表記がまったく違います。同じコードのフィーチャを wgpu に、型引数を burn::backend::Wgpu に差し替えて実行すると、出力は次のようになりました。

Tensor {
  data:
[[3.0, 4.0],
 [5.0, 6.0]],
  shape:  [2, 2],
  device:  DefaultDevice,
  backend:  "fusion<cubecl<wgpu<wgsl>>>",
  kind:  "Float",
  dtype:  "f32",
}

Flexが "flex" の1語なのに対し、WGPUでは fusion（カーネル融合）・cubecl（カーネルコンパイラ）・wgpu（ランタイム）・wgsl（シェーダ言語）の入れ子で、どの層を通ったかがそのまま出ます。Fusionを持たないFlexに入れ子が出ないのはこのためです。

なお0.18時点の解説記事には fusion<jit<wgpu<wgsl>>> という表記が載っています。中間層の名前が jit から cubecl へ変わっているので、手元の出力がどちらかを見れば、参照している資料が現行版のものかどうかを判別できます。

burn.tomlによるFusion・オートチューニング設定

0.21.0で、オートチューニングの強さ・Fusionのビームサーチ・コンパイルキャッシュ・ストリームの同時実行数・メモリプールの永続化といった内部設定が、プロジェクト直下の burn.toml 1か所に集約されました。環境変数・ビルドフィーチャ・その場限りのRust APIに散らばっていた調整項目をここへ寄せることで、再コンパイルなしで変更できます。CubeCL側の項目は [cubecl.autotune] のように cubecl. 接頭辞のセクションとして同じファイルに書きます（cubecl.toml 単体での指定も引き続き有効で、公式リポジトリのMNISTサンプルはこちらを使っています）。

[fusion.beam_search]
max_blocks = 5

[cubecl.autotune]
level = "balanced"   # minimal | balanced | extensive | full
cache = "target"

[cubecl.compilation]
check_mode = "auto"  # enforce | validate | auto

[cubecl.streaming]
max_streams = 8

[cubecl.memory]
persistent_memory = "enabled"

check_mode は0.21.0で追加されたCubeCLカーネルの検証レイヤの設定です。範囲外メモリアクセスを起こすカーネルを検出できます。既定では有効になっておらず、原因不明のメモリエラーを追うときに burn.toml から明示的に有効化する仕組みです。ログ出力もコンポーネント単位で burn.toml から設定でき、ファイル・標準出力・標準エラー・log クレートへ同時に流せます。ただしログレベルの語彙はサブシステムごとに統一されておらず、この点は公式も今後の課題としています。

なお burn-flex は burn.toml の設定対象外です。Flexを使っている限りこれらの項目は効きません。

学習済みモデルの読み込み形式：Burnpack・SafeTensors・PyTorch・ONNX

ゼロから学習させる用途だけでなく、既存のモデルをBurnへ持ち込む経路も整備されています。重みの入出力を担うのが burn-store クレートで、ゼロコピーのメモリマップ読み込み・キーの名前付け替え・部分読み込み・フィルタリングに対応します。従来のRecorder APIをいずれ置き換える想定ですが、当面は両方が併存します。以下の対応表とコードは、Burn Book v0.21.0のSaving and Loadingにもとづきます。

ここは古い解説と食い違いやすい部分です。0.18時点の記事にはSafeTensorsの「インポートに対応」とだけ書かれていることが多いのですが、現在は書き出しにも対応しており、PyTorch側で読める形で保存する経路も用意されています。

PyTorchからエクスポートしたSafeTensorsを読むときは、重みの並びを変換するアダプタを挟みます。以下は処理の断片で、burn-store 0.21.0の依存追加、保存元と対応するMyModelの定義、device、入力ファイル、エラーを返せる関数が別途必要です。Burn自身が書き出したSafeTensorsであればアダプタは不要です。

use burn_store::{ModuleSnapshot, PyTorchToBurnAdapter, SafetensorsStore};

let mut model = MyModel::init(&device);
let mut store = SafetensorsStore::from_file("model.safetensors")
    .with_from_adapter(PyTorchToBurnAdapter);

model.load_from(&mut store)?;

PyTorchの .pt を直接読む場合、よくある失敗は torch.save(model, ...) でモデル全体を保存してしまうことです。Burn側は state_dict を期待するため、torch.save(model.state_dict(), "model.pt") で保存し直す必要があります。PyTorch側の前提についてはPyTorchとは？特徴・できること・TensorFlowとの違いを解説を参照してください。

Burnを選ぶ判断とRust機械学習エコシステムの現在地

Rustで機械学習に取り組もうと調べ始めた段階では、Burnが唯一の選択肢に見えがちです。実際にはレイヤの違う複数のクレートが並立しており、やりたいことによって入口が変わります。2026年9月23日時点でcrates.ioに公開されている最新版は次のとおりです。

用途別クレート早見表

選定で見落とされやすいのが ort の状態です。crates.ioのAPIで2026年9月23日に取得した累計ダウンロードは19,174,724件と、ここに挙げたどのクレートより多いのですが、2.0系は今もリリース候補（rc.13）のままで、安定版が出ていません。本番投入する場合はこの点を承知のうえでバージョンを固定する必要があります。

逆に linfa は最終リリースが2025年12月で、更新頻度はBurnやcandleほど高くありません。古典的な機械学習をRustで完結させる候補としてはもう一つ smartcore（0.6.14・2026年8月26日公開）があり、分類・回帰・クラスタリングを揃えています。ただしどちらも、scikit-learnと同じ感覚でアルゴリズムが揃っているわけではない点は織り込んでおくべきです。他言語での事情も似ており、Rubyの状況はRubyで機械学習を始める方法｜2026年の現行ライブラリと選定基準にまとめています。

Burnが向く場面・向かない場面

Burnを選ぶ理由がはっきりしているのは、次のような場面です。ひとつは、学習までRustで回したい場合です。推論だけなら他に選択肢がありますが、自動微分と学習ループを備えたRust製フレームワークは限られます。もうひとつは、単一のコードベースで複数のハードウェアへ展開したい場合です。GPUベンダーが混在する環境や、サーバーで学習してブラウザ・組み込みで推論するような構成では、バックエンドを差し替えられる設計が効きます。エッジ側での推論要件についてはエッジAIとは？クラウドAIとの違い・仕組み・実装の判断基準を解説も参考になります。

一方、向かない場面もはっきりしています。学習済みモデルを読み込んで推論するだけなら、ort でONNX Runtimeを呼ぶほうが、モデルをRust側で定義し直さずに済みます（ビルドや配布の負担は、ONNX Runtimeの入手方法と実行プロバイダーの選択によって変わります）。表形式データの回帰や分類といった古典的な課題なら linfa や smartcore で十分です。また、論文実装をそのまま試したい、最新の学習手法をすぐ使いたいといった用途では、エコシステムの厚みでPyTorchに大きく分があります。

Burnが0.x系であることも判断材料です。マイナー版ごとに破壊的変更が入る前提でバージョンを固定し、更新時には移行ガイドを読んで手を入れる体制が取れるかどうかを、採用前に確認しておくことをおすすめします。Rust言語そのものの特性についてはRustとは？特徴・人気の理由・できることを徹底解説（プログラミング言語）で解説しています。

よくある質問

Burnの最新バージョンはいくつですか？

2026年9月23日時点の最新安定版は0.21.0で、2026年5月7日に公開されました。開発版としては0.22.0-pre.4（2026年9月22日）が公開されています。手元で使っている版は cargo tree -p burn --depth 0 で確認できます（実行すると burn v0.21.0 と1行で返ります）。

Burnを使うにはどのバージョンのRustが必要ですか？

Burn 0.21.0の最小サポートRustバージョンは1.92です。0.19.0と0.20系は1.89、0.18.0は1.85でした。版を上げる際はRustツールチェーン側の更新も必要になる場合があります。

burn-ndarrayはもう使えないのですか？

0.21では動作しますが非推奨です。公式は移行期間としてあと1〜2リリースは残すが、その後は削除すると告知しています。新規のコードはWebAssembly・組み込み・小規模モデル向けなら burn-flex、性能が要るCPU実行ならCubeCLベースの cpu バックエンドを選んでください。

CubeCLはBurnなしでも使えますか？

使えます。CubeCLはGPU向けカーネルをRustで書いて複数のバックエンドへコンパイルするための独立したプロジェクトで、Burnのアクセラレータ実装の土台になっていますが、単体でも利用できます。最新安定版は0.10.0（2026年5月7日）です。

PyTorchで学習したモデルをBurnで動かせますか？

動かせます。経路は3つあり、SafeTensors形式で受け渡す方法、.pt や .pth を burn-store で直接読む方法、ONNXへ変換して burn-onnx でRustコードを生成する方法です。.pt を読む場合は、PyTorch側で state_dict を保存しておく必要があります。

BurnはPyTorchより速いのですか？

条件によります。公式計測では、CPU上のMax Pool 2DでLibTorchの約4倍、CPU上のtop-kで条件により最大41.8倍という結果が出ている一方、行優先のGEMVや最終軸のtop-k（k=10）ではLibTorchのほうが速いと公式自身が明記しています。ワークロードの形状によって優劣が変わるため、採用判断では自分のモデルに近い条件で測ることをおすすめします。

関連記事

• wgpuとは？RustでWebGPUを扱う仕組みと最小サンプル・主要API
• Cargo（Rust）とは？インストールと使い方・主要コマンド一覧
• ONNXとは？モデル変換・推論の仕組みと使い方を初心者向けに解説
• 量子化（モデル量子化）とは？仕組み・PTQとQATの違いと実装判断を解説【2026年版】
• PyTorchとは？特徴・できること・TensorFlowとの違いを解説