ブラウザや端末上で推論するモデルを選ぶとき、パラメータ数や公開ベンチマークの精度から先に候補を絞りがちだが、実行環境（wasm、モバイル GPU、量子化ランタイム）での実測を先に取らないと順位を誤る。

実例

同一系列の2サイズを候補にし、容量と演算子の安全性から大きい方を本命に選んでいた。実行環境で測ると、

• 小さい方: パラメータ 1、推論 1.0（基準）
• 大きい方: パラメータ 5.6倍、推論 4.1倍

で、大きい方は置き換え前の既存モデルより 1.8 倍遅く、採用不可だった。小さい方は既存より 2.3 倍速く、サイズも 1/3 で、精度も用途上十分だった。机上の判断のままなら遅い方を選んでいた。

入力解像度を下げて速度を取り戻す案の落とし穴

速度が足りないときの定番策だが、

• 時間は画素数に比例して下がるとは限らず、期待ほど戻らないことがある（実測で確認する）
• 小さい対象の検出は入力解像度に強く依存するため、速度を取り戻せても別の失敗（密に並んだ小物体の取りこぼし）を招く

速度回収策として採る前に、必ず実測と、小物体を含む条件での精度確認をセットで行う。

手順

1. 速度予算を先に決める（既存実装の実測値を下回らない、等の具体値で）
2. 候補を学習前に、事前学習済み重みのまま変換して実行環境で計測する。数十分で済み、学習に入る前に候補を落とせる
3. 演算子の互換性も同時に確認する（実行できたという事実が最も確実な互換性検証）
4. 予算に収まる中で最大容量を選ぶ

注意

開発機での計測値は端末実機と数倍ずれる。相対比較（候補間の順位、既存実装との比）には使えるが、絶対値の合否判定には実機計測が要る。