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

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

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

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

Fable5 UltraCodeに調査してもらう。

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

4方向の調査を並列実行中です（一次情報のURL付きで検証させています）。完了次第、「完全移植は可能か」の判定を根拠付きでまとめます。

先に判定の骨格だけ共有しておくと、鍵になるのは以下の4点です:

1. 変換可否 — ONNX→LiteRTはツール(onnx2tf等)があるので技術的には通る見込み。ただしSCRFDの動的入力形状の固定化が必要
2. Edge TPUの物理制約 — Edge TPUはINT8必須+オンチップ8MB。認識モデル(174MB FP32→INT8でも約44MB)は明らかに超過し、性能が大きく落ちる可能性
3. 既存データとの互換性 — INT8化すると埋め込みベクトルが変わるため、登録済みの顔DBが全て無効化される可能性が高い
4. 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つの理由

1. 重みが別物: Model Zooの arcface_r50 は ms1mv3 学習で、buffalo_lの w600k_r50（WebFace600K学習）とは別の重み = 埋め込み空間が非互換。手元の w600k_r50.onnx を自前でDFCコンパイルすれば同一重みにできますが、それでもINT8量子化で数値は変わるため、既存の登録顔DB（pickle）は全件再登録 + 類似度閾値/DBSCAN epsの再調整が実務上必須
2. 960×960の既製はない: 既製HEFは640×640固定。960×960化は自前再コンパイルが必要（全畳み込みなので原理的に可能、~1MP入力の前例もModel Zooに実在）だが、実例未確認で実機コンパイル検証が必要
3. 補助モデル（年齢性別・ランドマーク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に移す意味はありません。

EVM系のトークンってDEXにあげるときに、監査サービスみたいなのがあったが、

EVM系のトークンってDEXにあげるときに、監査サービスみたいなのがあったが、

Solanaはどうなのか調べてみた、SPLトークンだとできなそうだが・・・

🔥 まず大前提：Solanaでは「独自トークンプログラム」はほぼ使われない

Solanaのトークンは SPL Token Program（2020）か Token-2022（Token Extensions） のどちらかで作るのが普通。 ウォレットもDEXもこれらの標準プログラムしか扱わない。

つまり：

• 勝手に新しいトークンプログラムを作って配布しても、ウォレットが対応しないのでユーザーは受け取れない

• そのトークンを扱うには専用UIや専用ウォレットが必要になる

• → 一般ユーザーを騙す用途には使えない

⚠️ しかし Token-2022 は「危険な拡張」を持てる

検索結果からも分かる通り、Token-2022 は SPL よりはるかに複雑で、悪意ある設計が可能。

危険な拡張例（すべて公式機能）

以下はすべて Token-2022 が標準で持つ機能：

1. Permanent Delegate（恒久デリゲート）

• トークン発行者が ユーザーの残高を勝手に移動・焼却できる

• 署名不要、ユーザーの許可不要

• これは公式仕様（悪用可能）

2. Transfer Hook（転送フック）

• トークン送信のたびに 任意の外部プログラムを強制実行

• つまり「トークンを送るだけで任意コードが走る」

• EVM の ERC-777 のコールバックと同じで、最も危険な拡張

3. Mint Close → 再初期化攻撃

• トークン発行者が Mint を閉じて再初期化できる

• 再初期化後に別の拡張（例：Transfer Fee、NonTransferable）を付けられる

• 古いトークンアカウントは「旧ルールのまま」動く → プロトコル側が想定外の挙動になる

4. Transfer Fee（転送手数料）

• 転送時に自動で手数料徴収

• 手数料は受信側から引かれる（仕様が特殊）

• 会計処理を誤るとプロトコルが損失

🧨 これらは「ウォレットをハックする」わけではないが…

ユーザー資産を奪うトークンを作ることは可能。

できること

• ユーザーが受け取った瞬間に残高を勝手に移動（Permanent Delegate）

• トークン送信時に任意コード実行（Transfer Hook）

• DEX や Lending に預けられた資産を吸い上げる（Permanent Delegate）

• プロトコルの会計を狂わせて資金を抜く（Transfer Fee）

できないこと

• ウォレットの秘密鍵を盗む

• 他のトークンを勝手に操作する

• SOL を勝手に送金させる

• ウォレットアプリを乗っ取る

Solana のセキュリティモデル上、トークンはそのトークンのアカウントしか操作できないため。

🧩 つまり「怪しいトークン」は作れるが、仕組みはこう

✔ トークン自体に悪意ある権限を付ける

✔ トークン転送時に悪意あるプログラムを呼び出す

✔ プロトコル側の検証不足を突いて資金を抜く

これらはすべて Token-2022 の公式機能の悪用。

🛡️ ユーザー視点での防御策

Solanaで怪しいトークンを受け取った時に確認すべきポイント：

• Permanent Delegate が設定されていないか

• Transfer Hook が付いていないか

• Transfer Fee が異常に高くないか

• Mint Close Authority が存在しないか

• Token-2022 かどうか（SPLより危険性が高い）

これらは solana account <mint> で確認できる。

って、監査必要なんか・・・・

🏆 Solana監査の主要プレイヤー（EVM系＋Solanaネイティブ）

🔥 Solanaネイティブ（Solana特化）

これらは Rust / Anchor / CPI / アカウントモデル を深く理解しているため、Solana監査では最重要。

• OtterSec Solanaネイティブの代表格。Wormhole、Jito Labs、Solana Foundation などを監査。 Solanaの TVL 36.8B を超える領域を担当。

• Zellic Solana Foundation とも協業。Wormhole や Pyth を監査。Rust と Solana専門性が高い。

• Neodyme Solanaの古参セキュリティチーム。CTF文化が強く、低レイヤーの脆弱性に強い。

• Sec3 Solana専用の自動脆弱性スキャナとリアルタイム監視を提供。

• Softstack 1,200+監査、ゼロエクスプロイト。Solanaのアカウントモデルや Anchor に強い。

🧩 EVM系の大手で Solana も対応している会社

EVMで有名な監査会社の多くは Solana もカバーしている。

• Trail of Bits Rust解析・形式手法が強い。Solana runtime や SPL の監査も実施。

• Halborn Solana Labs / Solana Foundation とも協業。インフラ・アプリ・スマートコントラクトを総合的に監査。

• Quantstamp 初期からの大手監査会社。Solanaも対応。

• CertiK 高ボリューム監査会社。Solanaも対応。

• Hacken EU中心の大手。Solana監査も提供。

• Cyfrin Codehawks などで有名。Solanaも対応。

• Spearbit 世界中のトップ研究者を束ねる監査集団。Solana対応。

📊 まとめ：Solana監査は「EVMより専門性が高い」

Solanaは Rust / Anchor / CPI / アカウントモデル / runtime の理解が必要で、 EVMより監査難易度が高いと言われている。

そのため：

• EVM監査会社でも Solanaを扱えるところは限られる

• Solanaネイティブの OtterSec / Zellic / Neodyme / Sec3 が強い

• Halborn / Trail of Bits は EVM・Solana両方でトップクラス

GoogleのAntigravityがClaude DesktopやChatGPT Codex（旧Codex Desktop）と同じ感じになってる。

Antigravity 2.0系

いつのまにかIDEじゃなくなってる。

IDEモードもあるんだけど、他のChatエージェント系のデスクトップアプリとほとんど同じになってる。

スケージュール（定期タスク）もある。

SUMinchoVを調べてみる。

「SUJPMLFV.TTF」は、ウイングアーク１ｓｔ社が提供する帳票出力システム「SVF（Super Visual Formade）」に付属している「SUMinchoV（明朝体）」というフォントファイルです。前回の回答にあった台湾の「AVECTOR TECHNOLOGY」社が製造したフォントをベースに、リコー社がSVF用にチューニングして提供しているものです。

どうやらSUMinchoVはLinux環境でMS明朝の代替品として作られた。

なのでWindowsの場合、MS明朝でほぼ同じになるっぽい。

SUMinchoV は MS明朝と同じグリフ順序を持つため、フォントファイルを差し替えるだけで済みます。グリフマッピングの調整は不要です。全GIDの一致を包括的に確認します

全角英数字・記号の11文字だけGIDがずれています。これらは「（」「）」「＊」「：」「Ｂ」「Ｅ」「Ｇ」「Ｌ」「Ｏ」「Ｒ」などです。

非常に良い知らせです。ずれは全角文字11個すべて一定の-304です。

つまり、これらの全角文字だけGIDが304ずつずれていますが、すべて同じ差分です。これは、SUMinchoVの作成時に全角英数字・記号ブロック（U+FF00〜）のGIDが304だけ後ろにずらされたことを意味します。

Wrangler v4 の主な変更点

 

⚡ Wrangler v4 の主な変更点（実質 “小規模アップデート”）

1. Node.js 16 が完全に非対応

• Wrangler v4 は Node.js 18 以上必須。

• Node.js 16（2022年に EOL）はサポート外。

• v16 のままだと Wrangler が正常動作しない可能性あり。

2. esbuild が v0.17 → v0.24 に大幅アップデート

• 内部バンドラーが新しくなり、以下の影響が出る可能性：

  • ワイルドカード動的 import の挙動が変わる

  • esbuild は pre-1.0 のため、今後も Wrangler minor 更新で破壊的変更が入る可能性あり

• 新しい JS 機能が利用可能：

  • using キーワード（Explicit Resource Management）

  • Import Attributes（例：with { type: "json" }）

3. CLI のデフォルトが “local mode” に変更

• 以前：必要に応じて remote

• 今回：すべてのコマンドが local をデフォルトに

• リモート API を叩きたい場合は --remote を明示する必要あり

  • 例：wrangler kv list --remote

4. 古いコマンド・設定が削除

• Wrangler v3 で非推奨だったものが完全削除

• 古い flags や legacy 設定が使えなくなる

surrealdb v3ってメモリ2Gじゃコンパイルできない。

Out of Memory で落ちる。

wasmer.ioでcronは無料では無理

有料プランだと使えるんだけど、無料だと使えない。

引き落とし失敗して無料プランになってたっぽ・・・

なので、cron-job.orgを使った。

https://firemio-fire-arbitrage.wasmer.app/

ちなみにプロセスは30秒まで、スクレイプが最大で17秒なので間に合う。