4方向の調査を並列実行中です(一次情報のURL付きで検証させています)。完了次第、「完全移植は可能か」の判定を根拠付きでまとめます。
先に判定の骨格だけ共有しておくと、鍵になるのは以下の4点です:
- 変換可否 — ONNX→LiteRTはツール(onnx2tf等)があるので技術的には通る見込み。ただしSCRFDの動的入力形状の固定化が必要
- Edge TPUの物理制約 — Edge TPUはINT8必須+オンチップ8MB。認識モデル(174MB FP32→INT8でも約44MB)は明らかに超過し、性能が大きく落ちる可能性
- 既存データとの互換性 — INT8化すると埋め込みベクトルが変わるため、登録済みの顔DBが全て無効化される可能性が高い
- Coral製品自体の現状 — 2026年時点でGoogleがどこまでメンテしているか
調査結果が揃ったら最終判定を報告します。
結論: 「完全移植」は技術的には一部可能だが、実用上は成立しない(非推奨)
「GoogleのTPU + LiteRT」= Coral Edge TPU として調査しました(他の解釈も末尾に)。4方向×一次情報で検証した結果です。
成立しない理由(3つの壁)
壁1: ハードウェアの物理制約
- Edge TPUは INT8完全量子化必須 + オンチップSRAM約8MB という設計です
- ところが認識モデル
w600k_r50は 174MB(INT8化しても約44MB)で、SRAMの5倍以上。収まらない分は推論のたびにUSB経由でウェイトを流し込む「ストリーミング」になり、大幅に遅くなります。実測報告でもResNet-50級はUSB Coralで37ms/枚程度 — 今日復旧したRTX 4070 Ti(数ms)どころか、GTX 1660 Tiにも負けます - 検出モデルの
det_size=960×960はEdge TPUの想定ワークロード(MobileNet級・~640px)を大きく外れ、TPUフル実行はほぼ不可能
壁2: 精度と既存データの互換性
- INT8量子化そのものの劣化は小さい(ArcFaceはLFWでほぼゼロ、SCRFDも0.2〜0.3pt)のですが、問題はそこではなく:
- TPUに収めるため検出入力を960→640以下に縮小すると、WIDER FACE hard(小さい顔)でAPが82→68.5と約13.5pt低下。集合写真の小顔の取りこぼしが激増します — このアプリの用途に直撃
- 認識モデルを8MBに収めるにはMobileFaceNet級への置き換えが必要ですが、埋め込み空間が非互換になるため、全プロジェクトの登録顔が無効化 → 全ユーザー再登録が必須になります
壁3: Coralエコシステムが事実上死んでいる
pycoralは2025年7月にアーカイブ(Python 3.9止まり)、google-coral/edgetpuリポジトリも2026年4月にアーカイブ- Edge TPUコンパイラは2021年から更新凍結、PCIe版ドライバはLinuxカーネル6.4以降で消滅
- 2025年発表の「Coral NPU」はRISC-VベースのNPU IPで、Edge TPU製品の後継ではないとGoogle自身が明言。今買える後継ハードは存在しません
技術的に「できる」部分(参考)
- ONNX→LiteRT変換自体は
onnx2tfで SCRFD / ArcFace とも変換実績あり - insightfaceの後処理(NMS・アライメント)は純numpyなので流用可能で、統合コード自体は1〜2週間規模
- LiteRTランタイム自体(
ai-edge-litert)は活発にメンテされています
つまり「LiteRTへの移植」は可能ですが、「TPUで速く・良くなる」が成立しません。移植して得られるのは「遅くて・小顔が検出できなくなり・全登録データが飛ぶ・サポート切れハード」です。
他の「Google TPU」解釈も念のため
| 解釈 | 判定 |
|---|---|
| Cloud TPU (v5e/v6e) | LiteRT非対応・ONNX非対応(JAX/TF/PyTorch-XLA専用)。この規模のモデルには常時課金が見合わない |
| Pixel Tensor NPU | LiteRTのNPUデリゲートはAndroid専用。Linuxサーバーでは使用不可 |
4方向(モデルズー収録状況 / ハード価格 / コンパイル制約 / 統合・運用)で並列調査中です。完了したら「完全再現できるか」と「総額いくらか」を根拠付きでまとめます。
先にCoralとの決定的な違いを言っておくと、Hailoが有望なのは:
- SCRFDとArcFaceの両方が公式Model Zooに収録されている(前回調査で量子化後精度 82.1 mAP まで公表されていることを確認済み)— Coralには顔系モデルの公式サポートが一切なかった
- ツールチェーン(Dataflow Compiler / HailoRT)が現役でメンテされている
- Raspberry Pi AI Kit採用でエコシステムが活発
一方で確認が必要な懸念は、960×960入力のカスタムコンパイル可否と、174MBの認識モデルがオンチップに収まらない場合のmulti-context動作のペナルティ、そして既存登録データの互換性です。結果が出たら報告します。
調査完了です。まとめます。
判定: 「完全再現」は不可。ただしCoralと違って「実用的な移植」は現実的に可能 — でも速くはならない
できる根拠(Coralとの決定的な違い)
- 検出も認識も公式Model Zooに既製コンパイル済みモデルがある:
scrfd_10g(量子化後 mAP 82.13→82.1でほぼ劣化ゼロ、440fps)とarcface_r50(LFW 99.72→99.7、w600k_r50と同一アーキテクチャ・512次元)。配布も現役です(2026年5月更新を実確認) - ツールチェーン(Dataflow Compiler / HailoRT)は無料(要登録)で現役メンテ中。Hailo公式コミュニティにSCRFD+ArcFaceの顔認識システム構築ガイドも存在
- 量子化はEdge TPUと違い入出力float可(内部だけINT8)なので、insightfaceへの組み込みも素直
「完全」にならない3つの理由
- 重みが別物: Model Zooの
arcface_r50は ms1mv3 学習で、buffalo_lのw600k_r50(WebFace600K学習)とは別の重み = 埋め込み空間が非互換。手元の w600k_r50.onnx を自前でDFCコンパイルすれば同一重みにできますが、それでもINT8量子化で数値は変わるため、既存の登録顔DB(pickle)は全件再登録 + 類似度閾値/DBSCAN epsの再調整が実務上必須 - 960×960の既製はない: 既製HEFは640×640固定。960×960化は自前再コンパイルが必要(全畳み込みなので原理的に可能、~1MP入力の前例もModel Zooに実在)だが、実例未確認で実機コンパイル検証が必要
- 補助モデル(年齢性別・ランドマーク2種)はModel Zoo未収録 → これらはCPU(onnxruntime)に残すハイブリッド構成が現実解
性能の現実
arcface_r50 はHailo-8のオンチップSRAMに収まらず3コンテキスト動作(公式プロファイラで確認): 113fps(逐次)/390fps(バッチ8)。試算すると集合写真1枚あたり約0.15〜0.4秒 — つまり:
- RTX 4070 Ti(0.37秒/枚)と同等止まり
- GTX 1660 Tiと比べても速くならない(1660 Tiの埋め込み推論の方が2〜3倍速い推定)
- Hailoが勝つのは電力(約2.5W vs GPU 120W)・ファンレス・静音・常時稼働だけ
価格(2026年7月実売・確認済み)
| 構成 | 価格 |
|---|---|
| Raspberry Pi AI HAT+ 26 TOPS(Hailo-8) | $110 / 秋月 ¥20,350(在庫あり) / スイッチサイエンス ¥24,860 |
| AI HAT+ 2(Hailo-10H 40 TOPS) | 公式$200 / 秋月 ¥38,390 |
| Hailo-8 M.2単体(既存PCに挿す) | $180〜266(Waveshare $180、UP Shop $199) |
| Hailo-8L M.2(13 TOPS・半分) | $99 |
| Pi 5 8GB本体(DRAM高騰中) | 米$130〜175 / 秋月 ¥35,200 |
- 最安の現実ライン: Pi 5 8GB + AI HAT+ 26 TOPS = 日本で約¥55,000〜60,000 + 電源等¥5,000
- 既存Linux機(1660 Ti機)に追加するなら: Hailo-8 M.2 モジュール約$180〜200(M.2スロットかPCIe変換が必要)。ただしHailoRTのドライバはカーネルに合わせて自前ビルドです
私の見立て
このアプリの用途は「集合写真を数千枚バッチ処理するサーバー」なので、速度目的でHailoに移す意味はありません。