ブラックマジック初版をもっている俺の意見。

士郎正宗のダメな所ばかり忠実にトレースして、

いい作品を作ろうとする意思を感じられない。

まさに魂がない、完全にゴーストがない。

わかりやすく言うと、AIで漫画をトレースして、映像生成した感じ。

これでいいと思ったのか？

SACのスタッフと比較してみるか。

新しい方

監督：モコちゃん

シリーズ構成・脚本：円城塔

キャラクターデザイン・総作画監督：半田修平

アニメーション制作：サイエンスSARU

SAC

👑 主要制作メインスタッフ

原作・協力：士郎正宗
監督・シリーズ構成：神山健治
キャラクターデザイン：下村一、後藤隆幸、西尾鉄也
メカニックデザイン：寺岡賢司、常木志伸
音楽：菅野よう子
音響監督：若林和弘
アニメーション制作：Production I.G
企画：石川光久、渡辺繁
製作：攻殻機動隊製作委員会（Production I.G、バンダイビジュアル、MANGA ENTERTAINMENT、日本テレビ、電通、ビクターエンタテインメント） [1, 2, 3, 4]

✍️ 各話脚本・演出スタッフ

脚本：神山健治、菅正太郎、佐藤大、櫻井圭記、藤咲淳一、寺戸信寿
絵コンテ・演出：河野利幸、吉原正行、橘正紀、布施木一喜、松本淳、中村隆太郎、竹下健一ほか [1, 2, 3]

pixel10AのTPUを有効に活用する方法ないか、考えてみたけど・・・

gradface.netの顔認識をgoogle TPUで計算できるのか？

感覚的には、乗り切らなそうな気がするけど・・・

Fable5 UltraCodeに調査してもらう。

対象は InsightFace buffalo_l の5つのONNXモデル（SCRFD検出 + ArcFace埋め込み等）なので、「LiteRT(旧TFLite)への変換可否 × Edge TPU(Coral)のハード制約 × 精度・既存データ互換 × アプリ統合」の4軸で判定が要ります。まず手元のモデル実サイズを確認してから、並列で調査します。

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サーバーでは使用不可

省電力エッジ化が真の目的なら、Coralではなく現役でメンテされているNPU（Hailo等）を検討する方が筋が良いです。

hailoのNPUなら完全再現できるの？

いくら？

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に移す意味はありません。

test

2026年7月17日金曜日

Xiaomi Mimo-2.5のトークン効率が悪い。

2026年7月16日木曜日

Opusがバカになってる、体感メモ。

結局Genspark Speakが俺には一番合ってるんだよな・・・

新しい攻殻機動隊、酷い！

2026年7月14日火曜日

Fable5の謎セキュリティー

2026年7月13日月曜日

AI agent tool piebald