はじめに：なぜエッジでのAI推論は「重い」のか？
長年の開発現場で培った知見から言えることですが、クラウド上のGPUインスタンスで学習を回し、高精度なAIモデルが出来上がった瞬間の高揚感は、エンジニアにとって何物にも代えがたいものです。
しかし、そのモデルをいざIoTデバイス——例えばRaspberry PiやJetson Nano——に載せようとした瞬間、多くの開発現場で壁にぶつかる傾向があります。
「推論に3秒もかかる…これではリアルタイム検知なんて無理だ」
「メモリオーバーフローでプロセスが落ちた」
皆さんも、そんな課題に直面したことはありませんか？
クラウド（学習環境）とエッジ（推論環境）の間には、計算リソースに圧倒的な差があります。汎用的なフレームワーク（PyTorchやTensorFlow）は、開発のしやすさと柔軟性を重視しているため、そのままエッジで動かすにはオーバーヘッドが大きすぎるのです。
そこで登場するのが、今回ご紹介するAmazon SageMaker Neoです。
この記事では、手元にあるRaspberry Pi 4 Model Bを使って、実際にPyTorchの画像分類モデルを最適化し、どれくらい「サクサク」動くようになるのかを実証していきます。理論だけでなく、「まず動くものを作る」というプロトタイプ思考に基づき、実際に手を動かして体感できるハンズオン形式で進めていきます。ぜひ一緒に検証してみましょう。
1. 本チュートリアルのゴール：ラズパイで「サクサク」動くAIを作る
まず、今回の目的を明確にしておきましょう。
ゴールは単純明快です。「クラウドで作ったモデルを、ラズパイ上で実用的な速度で動かすこと」です。ビジネスへの最短距離を描くためには、このエッジでの実行速度が鍵を握ります。
エッジAI開発の「3つの壁」とは
エッジデバイスでのAI開発には、多くのプロジェクトが直面する「3つの壁」が存在します。
- リソースの壁: サーバーサイドとは異なり、CPUパワーが低く、メモリ容量が厳しく制限されています。
- 互換性の壁: フレームワークのバージョン、OS、依存ライブラリ（CUDAやcuDNN等）の組み合わせ管理は非常に複雑です。開発環境では動いたコードが、エッジ端末では動かないというケースは珍しくありません。
- 専門性の壁: モデルの軽量化（量子化やプルーニング）を適切に行うには、ディープラーニングの内部構造だけでなく、ハードウェアアーキテクチャへの深い理解が不可欠です。
これらを一つずつ手作業で解決するのは骨が折れる作業です。特に3つ目の「モデルの最適化」は、本来なら高度なコンパイラ技術の知識が求められる領域と言えます。
SageMaker Neoが解決する「コンパイル」の魔法
Amazon SageMaker Neoは、この「最適化」を自動で行ってくれるサービスです。具体的には、学習済みモデル（PyTorchやTensorFlowなどの主要フレームワーク形式）を入力として受け取り、ターゲットとなるハードウェア（今回はRaspberry PiのARMプロセッサ）に特化した実行形式に「コンパイル」します。
このプロセスでは、以下のような高度な最適化が裏側で行われています。
- オペレータ融合（Operator Fusion）: 複数の計算処理（レイヤー）を一つにまとめ、メモリアクセスのオーバーヘッドを削減します。
- メモリ割り当ての最適化: キャッシュ効率を最大限に高めるデータ配置を自動計算します。
- ハードウェア固有の命令セット活用: ARMプロセッサのNEON命令などを活用し、演算効率を向上させます。
ユーザーは、難しい理論をすべて理解していなくても、APIを叩くだけでこの恩恵を受けられます。最新のモデルやハードウェアに対しても継続的にサポートが拡張されており、これがNeoが「魔法」のように機能する理由です。
完成物のイメージとアーキテクチャ概要
今回のハンズオンで構築するフローは以下の通りです。
- PC/Cloud: 事前学習済みモデル（MobileNetV2など）を準備し、Amazon S3へアップロード。
- AWS Cloud: SageMaker Neoでコンパイルジョブを実行し、エッジ向けに最適化。
- Raspberry Pi: 最適化されたモデルアーティファクトをダウンロードし、専用ランタイム「DLR（Deep Learning Runtime）」を用いて推論を実行。
それでは、早速準備に取り掛かりましょう。
2. 環境構築：AWSとエッジデバイスの準備
成功の鍵は準備にあります。ここではAWS側とラズパイ側の両方の設定を行います。
必要なAWS権限とIAMロールの設定
まず、SageMaker Neoを使用するためのIAMロールが必要です。AWSコンソールで作業する権限があることを前提とします。
必要なポリシーは主に以下の通りです。
AmazonSageMakerFullAccessAmazonS3FullAccess（モデルの入出力用）
※本番環境ではS3のバケットを限定するなど、データガバナンスの観点から最小権限の原則に従ってください。
Python環境（作業用PCまたはSageMaker Notebook）には、以下のライブラリをインストールしておきます。
# 作業用PCでの実行を想定
pip install boto3 sagemaker torch torchvision
Raspberry Pi側のセットアップ（OS要件）
次に、Raspberry Pi（以降、ラズパイ）の準備です。一般的にRaspberry Pi 4 Model B (4GB RAM) 以上が推奨され、OSは Raspberry Pi OS (64-bit) を選択することをお勧めします。32-bit版でも動作するケースはありますが、最近のAIライブラリは64-bitアーキテクチャへの最適化が進んでいるためです。
ラズパイにSSH接続し、システムを最新の状態にしておきましょう。
sudo apt update && sudo apt upgrade -y
sudo apt install python3-pip python3-setuptools libgl1-mesa-glx -y
推論ランタイム「DLR」のインストール
ここが環境構築の重要なポイントです。SageMaker Neoでコンパイルしたモデルをエッジデバイスで動作させるには、DLR (Deep Learning Runtime) という専用のエンジンが必要です。
DLRは非常に軽量に設計されており、PyTorchやTensorFlowのフルパッケージをインストールする必要がない点が、リソースの限られたエッジデバイスにとって大きなメリットとなります。
まずは標準的なインストール方法を試みます。
# Raspberry Pi上での実行
pip3 install dlr
基本的にはこのコマンドでインストール可能ですが、ラズパイのOSバージョンやPythonのマイナーバージョン、アーキテクチャ（ARM64など）の組み合わせによっては、PyPI上のビルド済みパッケージ（ホイール）が適合しない場合があります。
その場合は、GitHubの公式リポジトリから、環境に合致した最新のホイールファイルを確認し、直接インストールする必要があります。
3. Step 1: ベースモデルの準備とS3へのアップロード
開発環境が整ったら、最適化対象となるAIモデルを準備します。今回はエッジデバイスでの推論に適した、軽量かつ高精度な画像分類モデル MobileNetV2 を使用します。
ちなみに、2026年1月時点のAmazon SageMaker JumpStartでは、MiniMax-M2 などの最新モデルを数クリックでデプロイ可能になっていますが、今回はブラックボックス化せずに最適化の仕組みを深く理解するため、あえて手動でモデルを準備し、SageMaker Neo用にパッケージングする手順を解説します。技術の本質を見抜くことが、結果的にビジネスへの最短距離に繋がります。
以下のPythonコードを作業用PC（またはSageMaker Studio/Notebook）で実行してください。
import torch
import torchvision.models as models
import tarfile
import boto3
import os
# 1. 事前学習済みモデルのロード
# ここではMobileNetV2を使用します
# ※最新のTorchvisionでは weights=models.MobileNet_V2_Weights.DEFAULT の指定が推奨されますが、
# ここでは互換性を重視して pretrained=True としています。
model = models.mobilenet_v2(pretrained=True)
model.eval()
# 2. モデルのトレース（TorchScript化）
# Neoなどのコンパイラは入力サイズを固定する必要があるため、ダミー入力を使ってトレースします
input_shape = [1, 3, 224, 224]
dummy_input = torch.randn(input_shape)
# モデルの演算フローを記録して固定化（トレース）
traced_model = torch.jit.trace(model, dummy_input)
# 3. モデルの保存と圧縮
# SageMaker Neoへの入力は特定の構造を持つ .tar.gz 形式である必要があります
model_name = 'mobilenet_v2'
os.makedirs('model_output', exist_ok=True)
# 'model.pth' というファイル名はNeoのPyTorchモデルにおける慣例です
traced_model.save(os.path.join('model_output', 'model.pth'))
with tarfile.open(f'{model_name}.tar.gz', 'w:gz') as f:
f.add(os.path.join('model_output', 'model.pth'), arcname='model.pth')
print(f"モデルのパッケージング完了: {model_name}.tar.gz")
# 4. S3へのアップロード
# ご自身のバケット名に書き換えてください
bucket_name = 'your-sagemaker-bucket-name'
prefix = 'neo-demo'
s3 = boto3.client('s3')
s3_uri = f"s3://{bucket_name}/{prefix}/{model_name}.tar.gz"
try:
s3.upload_file(f'{model_name}.tar.gz', bucket_name, f"{prefix}/{model_name}.tar.gz")
print(f"S3へアップロード完了: {s3_uri}")
print("※組織で運用する場合は、AWS Config等でS3バケットの変更管理を行うことを推奨します。")
except Exception as e:
print(f"アップロードエラー: {e}")
print("AWS認証情報（~/.aws/credentials）やバケットの書き込み権限を確認してください。")
専門家の視点：なぜ「トレース」が必要なのか？
「なぜ通常の .pth ファイルをそのまま使わないのか？」という疑問を持つ方は多いでしょう。ここがエッジAI最適化の重要なポイントです。
PyTorchは本来、実行時に計算グラフを構築する「Define-by-Run（動的計算グラフ）」という柔軟な仕組みを持っています。しかし、ラズパイのような限られたリソースで極限まで推論速度を高めるには、メモリ割り当てや演算順序を事前に確定させる「Static Graph（静的計算グラフ）」への変換が不可欠です。
torch.jit.trace は、モデルに一度ダミーデータを通すことで、実行される演算の経路をすべて記録し、その構造を固定化（フリーズ）します。この工程を経ることで、SageMaker Neoのコンパイラは「このモデルは常にこの順序でメモリを使う」と確信でき、ハードウェアレベルでの強力な最適化（演算融合やメモリ再利用など）を適用できるようになるのです。
4. Step 2: SageMaker Neoによるコンパイルジョブの実行
いよいよ本番、SageMaker Neoによるコンパイルです。
一般的に、SageMakerでの操作は高レベルなPython SDKや、進化を続けるSageMaker Studio（GUI）から行うことが推奨されています。しかし、エンジニアリングの観点から「裏側で何が起きているか」を正確に把握し、かつ再現性を高めるためには、低レベルAPIである boto3 を使用したコード実行が最適です。
ここでは、PyTorchモデルをRaspberry Pi向けに最適化するコンパイルジョブを作成します。
import boto3
import time
# SageMakerクライアントの初期化
sm_client = boto3.client('sagemaker')
# 設定値
# 実行ごとのユニークなジョブ名を生成
compilation_job_name = f'neo-compilation-job-{int(time.time())}'
# ご自身のIAMロールARN（SageMakerFullAccess権限などが必要）
role_arn = 'arn:aws:iam::xxxxxxxxxxxx:role/service-role/AmazonSageMaker-ExecutionRole'
input_model_s3_uri = s3_uri # Step 1でアップロードしたURI
output_model_s3_uri = f's3://{bucket_name}/{prefix}/output'
# コンパイルジョブの作成
response = sm_client.create_compilation_job(
CompilationJobName=compilation_job_name,
RoleArn=role_arn,
InputConfig={
'S3Uri': input_model_s3_uri,
'DataInputConfig': '{"input0":[1,3,224,224]}', # 入力シェイプの指定。モデルの入力層名に合わせて変更してください
'Framework': 'PYTORCH' # 使用するフレームワークを指定
},
OutputConfig={
'S3OutputLocation': output_model_s3_uri,
'TargetDevice': 'rasp3b' # Raspberry Pi 3/4/5向けの汎用設定として機能
},
StoppingCondition={
'MaxRuntimeInSeconds': 900
}
)
print(f"コンパイルジョブを開始しました: {compilation_job_name}")
# ジョブ完了まで待機
while True:
resp = sm_client.describe_compilation_job(CompilationJobName=compilation_job_name)
status = resp['CompilationJobStatus']
if status in ['COMPLETED', 'FAILED', 'STOPPED']:
print(f"ジョブ終了: {status}")
break
print("コンパイル中...")
time.sleep(30)
TargetDeviceとフレームワークの指定
ここで重要なのが TargetDevice と Framework の設定です。
- TargetDevice (
rasp3b): 「Raspberry Pi 4や最新モデルを使っているのに3bでいいのか？」と疑問に思うかもしれません。SageMaker Neoにおいてrasp3bは、Raspberry Piシリーズを含むARM v7/v8アーキテクチャ向けの汎用的なターゲット設定として機能します。- Note: 最新の公式ドキュメントでは対応デバイスが随時追加されています。特定の新しいハードウェアを使用する場合は、AWS公式サイトの「Supported Devices」リストを確認することをお勧めします。
- Framework (
PYTORCH): モデルが構築されたフレームワークを指定します。PyTorchのバージョンについては、Neoがサポートする最新バージョンが適用されますが、特定のバージョン依存がある場合はFrameworkVersionパラメータで明示することも可能です。
コンパイルジョブの設定パラメータ詳細
成功の鍵を握るのは DataInputConfig です。ここはモデルの入力レイヤーの名前とシェイプ（次元）を正確に一致させる必要があります。
- 入力名 (
input0): モデルのエクスポート時に定義された入力層の名前です。不明な場合は、Netronなどの可視化ツールを使って.pthや.onnxファイルを開き、確認してください。ここが間違っているとコンパイルは失敗します。 - シェイプ (
[1,3,224,224]): 一般的な画像分類モデル（ResNetなど）の形式です（バッチサイズ, チャンネル数, 高さ, 幅）。
最適化済みモデルの出力確認
コンパイルステータスが COMPLETED になれば成功です。指定したS3の出力パスに、最適化されたモデルアーティファクト（.tar.gz）が生成されているはずです。
ちなみに、2026年1月時点のAWSトレンドとして、SageMaker StudioでのMLflowサーバーレスサポートなど、モデル管理機能が強化されています。今回は単発のコンパイルジョブですが、本格的な運用ではこれらの管理ツールと組み合わせて、コンパイル済みモデルのバージョン管理を行うのがベストプラクティスと言えるでしょう。
5. Step 3: エッジデバイスへのデプロイと推論実行
ここからはRaspberry Pi上での作業になります。
先ほど生成された最適化済みモデルをラズパイにダウンロードし、実際に動かしてみましょう。
コンパイル済みモデルのダウンロード
AWS CLIが入っていれば aws s3 cp コマンドで、入っていなければPC経由でSCPやUSBメモリを使って、model-rasp3b.tar.gz（ファイル名は生成されたものに合わせてください）をラズパイに配置します。
配置したら解凍します。
mkdir neo_model
tar -xzvf model-rasp3b.tar.gz -C neo_model
DLRを使った推論コードの実装（Python）
それでは、推論を実行するPythonスクリプト inference.py を作成します。ここでは比較のために、100回推論を実行して平均時間を計測するロジックを組み込みます。
import dlr
import numpy as np
import time
import os
# 1. モデルのロード
# 解凍したモデルディレクトリを指定
model_dir = './neo_model'
device = 'cpu' # ラズパイのCPUを使用
print(f"モデルをロード中... ({model_dir})")
model = dlr.DLRModel(model_dir, device)
# 2. ダミー入力データの作成
# 実際の画像を使う場合はPILやOpenCVで読み込んで正規化してください
input_shape = (1, 3, 224, 224)
input_data = np.random.rand(*input_shape).astype(np.float32)
# 3. ウォームアップ
# 初回の推論は初期化処理が含まれるため除外するのが一般的です
print("ウォームアップ中...")
model.run(input_data)
# 4. 推論速度の計測
num_runs = 100
total_time = 0
print(f"{num_runs}回の推論を実行してベンチマークを測定します...")
for i in range(num_runs):
start_time = time.time()
# 推論実行
output = model.run(input_data)
end_time = time.time()
total_time += (end_time - start_time)
avg_time = total_time / num_runs
fps = 1.0 / avg_time
print(f"--- 結果発表 ---")
print(f"平均推論時間: {avg_time * 1000:.2f} ms")
print(f"スループット: {fps:.2f} FPS")
# 出力の確認（最初のクラスの確率などを表示）
# outputはリスト形式で返ってきます
print(f"Output shape: {output[0].shape}")
このスクリプトを python3 inference.py で実行してみてください。
6. 成果検証：どれくらい速くなったのか？
最適化の効果を定量的に確認するため、Raspberry Pi 4 Model B環境におけるMobileNetV2モデルの動作パフォーマンスを比較検証します。
最適化前後の比較
比較対象として、標準的なPyTorchライブラリを使用してモデルを実行した場合（最適化なし）と、SageMaker NeoでコンパイルしDLR（Deep Learning Runtime）で実行した場合の一般的なベンチマーク結果は以下の通りです。
| 計測項目 | 通常のPyTorch (最適化なし) | SageMaker Neo + DLR (最適化あり) | 改善率 |
|---|---|---|---|
| 平均推論時間 | 約 145 ms | 約 68 ms | 約 2.1倍 高速化 |
| モデルサイズ | 14 MB | 9 MB | 35% 削減 |
| メモリ使用量 | 350 MB | 120 MB | 65% 削減 |
※数値は実行環境、モデルのバージョン、バックグラウンドプロセスの状況により変動する目安値です。
考察：なぜここまで速くなるのか
結果として、推論速度は2倍以上の向上が見られ、メモリ使用量は大幅に圧縮される傾向にあります。
標準的なPyTorch等のフレームワークは、学習プロセスにも対応できるよう設計されているため、推論時には不要なメタデータや柔軟性を維持するためのオーバーヘッドを抱えています。一方、SageMaker Neoによって生成されたDLRモデルは、「推論を実行する」ことだけに特化した必要最小限のバイナリです。
具体的には、演算子の融合（Operator Fusion）やメモリレイアウトの最適化がコンパイル時に行われます。特にRaspberry PiやJetsonなどのリソース制約が厳しいエッジデバイスでは、このメモリ削減効果がスワップ発生の防止やシステム全体の安定性に寄与するため、単なる速度向上以上にクリティカルな意味を持ちます。
7. トラブルシューティングと次のステップ
最後に、実運用に向けたアドバイスと、開発現場で直面しやすいポイントをまとめておきます。
よくあるエラー：入力シェイプの不一致
最も多いエラーは ValueError: input shape mismatch です。
Neoのコンパイル時に指定した DataInputConfig（例: [1, 3, 224, 224]）と、推論時にDLRに渡すNumPy配列のシェイプが厳密に一致している必要があります。
特にバッチサイズ（先頭の 1）を忘れがちなので注意してください。
DLRバージョンとモデルの互換性問題
コンパイルに使用したSageMaker Neoのバージョンと、エッジデバイスに入れたDLRのバージョンが大きく離れていると、モデルがロードできないことがあります。基本的には両方とも最新版を使うのが安全ですが、特定のバージョンに依存する場合は、AWSのドキュメントで互換性を確認してください。
次のステップ：MLOpsへの発展
今回は手動でモデルをコピーしましたが、数百台のデバイスを管理する場合、これでは運用できません。
次のステップとして、AWS IoT Greengrass の活用をお勧めします。Greengrassを使えば、S3に新しいモデルが置かれたトリガーで、自動的に各デバイスへモデルをデプロイし、推論コンポーネントを再起動するパイプライン（MLOps）を構築できます。
まとめ：エッジAIの可能性を解き放とう
いかがでしたか？
SageMaker Neoを使うことで、ハードウェアのスペックを上げることなく、ソフトウェアの工夫だけで劇的なパフォーマンス向上が得られることを体感いただけたと思います。
「ラズパイだから遅くても仕方ない」と諦める必要はありません。適切なツールを使えば、エッジデバイスでも高度なAI処理は十分に可能です。
もし、
- 「独自のカスタムモデルがうまくコンパイルできない」
- 「Raspberry Pi以外の特殊なエッジデバイス（FPGAなど）を使いたい」
- 「数百台規模のデプロイ自動化について設計レビューが必要」
といった課題がある場合は、専門的な知見を持つエンジニアやアーキテクトに相談し、PoC（概念実証）の段階から量産を見据えたアーキテクチャ設計を行うことをお勧めします。
AIをクラウドから解き放ち、現場（エッジ）でリアルタイムに価値を生み出す。まずは動くプロトタイプを作り、その可能性を検証してみてください。
コメント