Tabletop Clutter Detector

A repair applied to something that is not broken is damage壊れていないものへの修正は破壊になる

bgsub alone leaves a bimodal error distribution: 47.3 % of objects recovered at IoU ≥ 0.9, and 38.6 % below 0.5 because touching objects merge into one region. The obvious fix — distance-transform watershed — made things worse when applied to every region.

bgsub単体では誤差の分布が二峰性になります。47.3 %の物体はIoU ≥ 0.9で検出できる一方、38.6 %は 接触した物体が1つの領域に融合するためIoU 0.5未満になります。素直な対策である距離変換watershedを全領域に適用すると、結果は悪化しました。

Running the watershed everywhere redraws the boundary of regions that were already correct: the near-perfect tier collapsed from 47.3 % to 6.3 % while the merged tier only fell from 38.6 % to 25.0 %. Counting distance-transform seeds inside each connected region first, and leaving single-seed regions untouched, keeps the good tier and fixes the merges. A parameter sweep would never have found this — the sweep converged towards "split less", which was the wrong axis entirely.

watershedを全領域に適用すると、すでに正しかった領域の境界まで引き直されます。ほぼ完璧だった層は47.3 %から6.3 %に崩れ、 融合していた層は38.6 %から25.0 %にしか減りませんでした。先に連結領域ごとに距離変換のseedを数え、seedが1つの領域には手を付けないようにすると、 良い層を保ったまま融合も解消できます。パラメータsweepではこれは見つかりませんでした。sweepは「分割を減らす」方向に収束しましたが、 それはそもそも見当違いの軸だったからです。

A wrong prior still returns an answer誤った前提でも答えは返ってくる

Global Otsu thresholding on greyscale is a reasonable-looking method: objects and table differ in brightness, so split the histogram. Under easy it scores 0.446. Under hard, where table value is uniform(0.25, 0.85) and object value uniform(0.45, 1.0), the two distributions overlap and the split lands inside the objects — mAP 0.143, a 3.1× collapse, detection rate 0.232. It never raised an error. It returned a mask every time, and its per-class numbers read like a weak detector rather than a broken one.

グレースケールに対する大域的なOtsu二値化は、一見妥当な手法です。物体とテーブルは明るさが違うので、ヒストグラムを分ければよい、という発想です。 easyでは0.446を出します。しかしhardではテーブルの明度がuniform(0.25, 0.85)、物体の明度がuniform(0.45, 1.0)で 2つの分布が重なり、閾値が物体の内側に来てしまいます。mAPは0.143と3.1分の1に崩れ、検出率は0.232でした。 それでもエラーは一度も出ませんでした。毎回maskを返し、クラスごとの数値も「壊れた検出器」ではなく「弱い検出器」のように見えました。

Classification is the bottleneck, not localisationボトルネックは位置推定ではなく分類

On hard, class-agnostic AP50 is 0.823 against class-aware AP50 0.698. The boxes are in the right place; the label on them is wrong 15 % of the time. Per class: sphere 0.695, cylinder 0.510, box 0.391. A sphere's silhouette is a circle from every direction, so nine shape features describe it completely. A box's silhouette under a tilted camera changes with yaw, and at 28 px there is not enough of it left for a linear rule. That gap is the specific thing a learned feature extractor should close — and it is now measured rather than assumed.

hardでは、クラスを区別しないAP50が0.823、クラスを区別するAP50が0.698です。 矩形の位置は合っていますが、付いているラベルが15 %の割合で間違っています。クラス別ではsphere 0.695、cylinder 0.510、box 0.391です。 球のシルエットはどの方向から見ても円なので、9個の形状特徴量で完全に記述できます。一方、傾いたカメラから見た箱のシルエットはyawによって変わり、 28 pxでは線形のルールで扱えるほどの情報が残りません。この差こそ学習ベースの特徴抽出器が埋めるべきもので、今回それを想定ではなく計測で示しました。

Occlusion is where the classical pipeline stops, not degradesocclusionで古典的パイプラインは「劣化」ではなく「停止」する

Recall at IoU 0.5 by visible fraction: 0.785 above 0.9 visibility, 0.348 between 0.5 and 0.9, and 0.000 below 0.5. Not a slope — a cliff. A partially hidden object has the wrong silhouette, so every shape feature it produces is wrong at once.

可視率別のIoU 0.5でのrecallは、可視率0.9超で0.785、0.5〜0.9で0.348、0.5未満で0.000です。 緩やかな低下ではなく崖です。一部が隠れた物体はシルエットが正しくないため、そこから得られる形状特徴量がすべて同時に狂います。

The classification gap closed — which the baseline predicted分類の差は解消された（baselineから予測した通り）

Per-class AP: box 0.391 → 0.914, cylinder 0.510 → 0.910, sphere 0.695 → 0.908. The spread across classes collapses from 0.304 to 0.006. The learned extractor does not just score higher, it scores evenly — the class that was hardest for hand-designed features is now indistinguishable from the easiest. That was a stated prediction before training.

クラス別AP：box 0.391 → 0.914、cylinder 0.510 → 0.910、sphere 0.695 → 0.908。クラス間のばらつきは 0.304から0.006に縮まりました。学習した特徴抽出器はスコアが高いだけでなく、クラス間で均一です。 手設計の特徴量で最も難しかったクラスが、今では最も簡単なクラスと区別がつきません。これは学習前に明言していた予測です。

The occlusion cliff is gone — with a caveat that matters more than the numberocclusionの崖は消えた（ただし数値以上に重要な注意点あり）

Recall at IoU 0.5 by visible fraction: ≥0.9 → 0.785 becomes 1.000; 0.5–0.9 → 0.348 becomes 0.999; <0.5 → 0.000 becomes 0.910. A centre heatmap has no coupling to the silhouette — the centre of a half-occluded object is still a centre, and the size head regresses the full extent from partial evidence.

可視率別のIoU 0.5でのrecall：≥0.9では0.785が1.000に、0.5–0.9では0.348が0.999に、<0.5では0.000が0.910になりました。 中心heatmapはシルエットに依存しません。半分隠れた物体の中心もやはり中心であり、サイズheadは部分的な情報から全体の大きさをregressionします。

The caveat: n = 53. That is 0.6 % of the dataset, and 0.910 on 53 samples carries about ±0.04 at one sigma. The honest claim is narrow — the specific failure mode that stops the classical pipeline does not appear here. It is not evidence of robustness to heavy occlusion in general.

注意点：n = 53。これはデータセットの0.6 %で、53サンプルでの0.910には1σで約±0.04の幅があります。 正直に言える主張は狭く、古典的パイプラインを停止させる特定の失敗パターンがここでは現れないということだけです。 強いocclusion全般に対する頑健性の証拠ではありません。

Localisation is essentially exact, and AP75 is where it shows位置推定はほぼ厳密で、それはAP75に表れる

AP75 0.9896 against AP50 0.9899 — a gap of 0.0003. The baseline lost 0.134 between the same two thresholds. The metric's shift table gives the reading: a uniform 4 px error leaves AP50 at 1.000 while mAP has already fallen to 0.464, so AP50 alone cannot see localisation. The offset head is what buys this; it is measured at 2.00 px of worst-case centre error, which at stride 4 is exactly the quantisation it exists to undo.

AP75 0.9896に対しAP50 0.9899で、差は0.0003です。baselineは同じ2つの閾値の間で0.134を失っていました。 評価指標のずらし実験の表が読み方を示しています。一律4 pxの誤差ではAP50は1.000のままですが、mAPはすでに0.464まで下がっており、 AP50だけでは位置精度は見えません。これを実現しているのはoffset headです。中心誤差の最悪値は2.00 pxと計測されており、 これはstride 4での量子化誤差、つまりoffset headが打ち消すべき量そのものです。

The learned detector is slower, not faster学習ベースの検出器は速くない（遅い）

3.87 ms against 2.02 ms, single image, PyTorch eager, decode included. Worth stating plainly because the convenient story would be that the network wins on every axis, and it does not. Step 5 was set up to find out whether that was the architecture or the runtime.

画像1枚、PyTorch eager、decode込みで3.87 ms対2.02 msです。ネットワークがすべての面で勝つという都合の良い話にはならないので、 はっきり書いておきます。step 5は、この差がアーキテクチャによるものかruntimeによるものかを確かめるために設計しました。

Small objects still cost, in the expected direction小さい物体は依然として不利（予想通りの方向）

By size tercile: 0.805 (<25.5 px), 0.854 (25.5–31.9 px), 0.884 (>31.9 px). IoU is scale-relative, so a fixed pixel error costs a small box more. Output stride 4 means centres quantise to 4 px cells, which is 16 % of a 25 px object and 9 % of a 43 px one. The offset head removes most of that; the residual 0.079 spread is what is left.

サイズの三分位別：0.805（<25.5 px）、0.854（25.5–31.9 px）、0.884（>31.9 px）。IoUはスケールに対して相対的なので、 同じピクセル誤差でも小さい矩形ほど影響が大きくなります。出力stride 4では中心が4 pxのセルに量子化され、これは25 pxの物体の16 %、 43 pxの物体の9 %に当たります。offset headがその大部分を取り除き、残ったのが0.079のばらつきです。

The gap is appearance, and it is a cliff, not a slope差の原因は外観で、緩やかな低下ではなく崖

A detector trained on fixed appearance scores 0.90 on what it saw and 0.15 when the table colour and the light move. Detection rate falls to 0.29 — it does not misclassify seven objects in ten, it fails to see them. Nothing about the geometry, the camera, the shapes or the sizes changed. This is the number the whole track is about: a policy trained in an un-randomised simulator meets the real world in exactly this way, and the failure is silent — no error, just boxes missing.

外観を固定して学習した検出器は、学習時と同じ条件では0.90ですが、テーブルの色と照明が変わると0.15になります。 検出率は0.29まで落ちます。10個中7個を誤分類しているのではなく、そもそも見えていないのです。形状配置・カメラ・物体の形・大きさは 何も変わっていません。これがこのトラック全体のテーマとなる数値です。ランダム化していないシミュレータで学習したpolicyは、 まさにこの形で現実世界に出会います。しかも失敗は静かで、エラーは出ず、矩形が欠けるだけです。

Photometric augmentation recovers half the gap and stopsphotometric augmentationは差の半分を取り戻し、そこで止まる

0.147 → 0.521, still 0.35 short of simply training on hard (0.874). The mechanism is visible in what each one varies. Augmentation perturbs the whole image with one brightness, one contrast, one gamma, one channel gain — a global nuisance model. The randomiser gives every object its own hue and moves the light source, which changes the shading direction on every face. Augmentation is a hand-written model of the nuisance; the randomiser samples the nuisance itself. A model cannot be augmented towards a variation nobody wrote down.

0.147 → 0.521となりましたが、単純にhardで学習した場合（0.874）にはまだ0.35届きません。仕組みは、それぞれが何を変化させるかを見ると分かります。 augmentationは画像全体に、1つの明るさ・1つのコントラスト・1つのガンマ・1つのチャンネルゲインを適用します。つまり大域的な外乱モデルです。 一方ランダム化は、物体ごとに別々の色相を与え、光源を動かすため、各面の陰影の向きまで変わります。augmentationは外乱を人が書いたモデルであり、 ランダム化は外乱そのものをサンプリングします。誰も書き下していない変動に向けてaugmentationすることはできません。

Geometric augmentation does nothing across the gapgeometric augmentationはこの差に対して効果なし

0.147 → 0.181, within the noise of a single seed. Flip and translation add placement diversity, and placement was never the problem — the two regimes share one camera and one placement distribution. An augmentation only buys invariance along the axis it perturbs. Worth stating because the default recipe applies everything at once and then cannot say which part worked.

0.147 → 0.181で、単一seedのノイズの範囲内です。反転と平行移動は配置の多様性を増やしますが、配置はそもそも問題ではありませんでした。 2つのregimeは同じカメラと同じ配置分布を共有しているからです。augmentationで得られる不変性は、それが摂動させる軸に沿ったものだけです。 よくあるレシピはすべてを同時に適用するため、どれが効いたのか説明できなくなります。だからこそ明記しておく価値があります。

On top of the randomiser, photometric augmentation buys nothingランダム化に上乗せしたphotometric augmentationは効果なし

hard/none 0.8735 against hard/photo 0.8742: +0.0007, for 33 % more training time. The randomiser already covers the axis photometric augmentation would add. Every hour spent on an augmentation pipeline for a randomised simulator is an hour spent on nothing.

hard/none 0.8735に対しhard/photo 0.8742で+0.0007、しかも学習時間は33 %増えます。 photometric augmentationが加えるはずの軸は、ランダム化がすでにカバーしています。ランダム化したシミュレータ向けにaugmentationパイプラインを 作る時間は、何も生まない時間です。

Geometric augmentation does add +0.016 within hard. Single seed, so suggestive rather than proven, but the direction is expected for a 6000-image dataset: flip and shift are extra placements, which the randomiser only samples 6000 times.

geometric augmentationは、hard内では+0.016の効果があります。単一seedなので証明ではなく示唆にとどまりますが、 6000枚のデータセットとしては予想通りの方向です。反転とずらしは追加の配置であり、ランダム化では配置は6000回しかサンプリングされないからです。

The randomised model transfers to the fixed regime for freeランダム化したモデルは固定regimeにそのまま転移する

hard/none loses 0.005 going to easy. easy/none loses 0.75 going the other way. That asymmetry is the entire argument for domain randomisation: the randomised distribution contains the fixed one, so a model trained on it has already seen the fixed regime as a special case. Nothing was tuned for easy and nothing needed to be.

hard/noneはeasyに移っても0.005しか下がりません。逆方向のeasy/noneは 0.75下がります。この非対称性こそが、domain randomisationを使う理由のすべてです。ランダム化した分布は固定された分布を 包含しているため、そこで学習したモデルは固定regimeを特殊ケースとしてすでに見ています。easy向けの調整は一切しておらず、 その必要もありませんでした。

More data does not close an appearance gapデータを増やしても外観の差は埋まらない

The full-budget easy/none model saw 75 % more images and 67 % more epochs and gained +0.027 on easy — and only +0.033 on hard, from 0.147 to 0.180. Coverage of the distribution is what transfers, not the number of samples drawn from the wrong one. When a model fails out of distribution, "collect more data" is only the right answer if the new data comes from somewhere new.

フル学習量のeasy/noneモデルは、画像を75 %、epochを67 %多く使い、easyでは+0.027向上しましたが、 hardでは0.147から0.180へ+0.033しか向上しませんでした。転移を決めるのは分布のカバー範囲であり、誤った分布から取ったサンプルの数ではありません。 モデルが分布外で失敗するとき、「データを増やす」が正解になるのは、新しいデータが新しい場所から来る場合だけです。

The runtime is worth 2.7× at eight threads — and 1.4× at oneruntimeの効果は8スレッドで2.7倍、1スレッドでは1.4倍

The previous project found ONNX Runtime on one thread beating PyTorch eager on eight. That does not repeat here. The difference is the model: that network was 27 k parameters with a 16×16 output, so per-op dispatch overhead was most of the time and a runtime that removes overhead removes most of the time. This one is 14× larger with a 48×48×7 output; the convolutions themselves are the cost, and they cost the same arithmetic in either runtime. The refined rule: the runtime dominates while the model is small enough to be overhead-bound; once it is compute-bound, the thread budget matters as much as the engine. The earlier number was true and its generalisation was not.

前のプロジェクトでは、1スレッドのONNX Runtimeが8スレッドのPyTorch eagerに勝ちました。ここではそれが再現しません。 違いはモデルです。前のネットワークはパラメータ27 k、出力16×16で、処理時間の大半がop単位のdispatchオーバーヘッドでした。 そのためオーバーヘッドを取り除くruntimeは、処理時間の大半を取り除けました。今回のモデルは14倍大きく出力は48×48×7で、コストは畳み込みそのものにあり、 その演算量はどちらのruntimeでも変わりません。修正したルール：モデルがオーバーヘッド律速なほど小さいうちはruntimeが支配的だが、 計算律速になるとスレッド数の割り当てがエンジンと同じくらい重要になる。以前の数値は正しく、その一般化が誤っていたということです。

Four threads is the knee, and eight is worse for eager4スレッドが変曲点で、eagerは8スレッドの方が遅い

ONNX Runtime: 3.69 → 1.12 → 1.01 ms for 1 → 4 → 8 threads. 3.3× from the first four, 10 % from the next four. PyTorch eager on 8 threads (2.75) is slower than on 4 (2.54) — thread oversubscription on a batch-1 forward costs more than the parallelism returns. A node given 4 cores gets essentially everything this model can deliver; a node given 1 core is 1.8× slower than the classical pipeline it was meant to replace. The deployment question is not "how fast is the detector" but "how fast is the detector on the cores it will actually be given" — and that answer can land on either side of the baseline.

ONNX Runtime：1 → 4 → 8スレッドで3.69 → 1.12 → 1.01 ms。最初の4スレッドで3.3倍、次の4スレッドでは10 %です。 PyTorch eagerは8スレッド（2.75）の方が4スレッド（2.54）より遅くなります。batch 1のforwardではスレッドの過剰割り当てによるコストが、 並列化で得られる効果を上回るからです。4コアを割り当てられたnodeは、このモデルが出せる性能をほぼすべて引き出せます。1コアしか割り当てられないnodeでは、 置き換えるはずだった古典的パイプラインより1.8倍遅くなります。デプロイで問うべきは「検出器はどれだけ速いか」ではなく 「実際に割り当てられるコア数で検出器はどれだけ速いか」です。その答えはbaselineのどちら側にもなり得ます。

Decode is 15 % of the end-to-end latency at the best setting最良の設定ではdecodeがend-to-end latencyの15 %を占める

0.18 ms against 1.01 ms of model, and it does not shrink with the runtime. On a small, fast model the post-processing stops being free — any deployment budget that lists only the forward pass is under-reporting by that much.

モデル1.01 msに対してdecodeは0.18 msで、runtimeを変えても縮みません。小さく高速なモデルでは後処理はもはや無視できず、 forward passだけを計上したデプロイ時の時間見積もりは、その分だけ過小になります。

The first measurement was discarded, and why is the most reusable finding here最初の計測値は破棄した。その理由がここで最も応用の利く知見

Step 5 first ran unattended immediately after the 96-minute ablation and recorded ONNX-8t 1.225 ms and eager-8t 3.773 ms. Same weights, same code, same box, re-run idle the next morning: 1.014 and 2.750 — 17 % and 27 % faster. The single-threaded classical baseline moved only 5 % in the same comparison.

step 5は当初、96分のablationの直後に無人で実行され、ONNX-8tで1.225 ms、eager-8tで3.773 msを記録しました。 同じweight、同じコード、同じマシンで、翌朝アイドル状態で再実行すると1.014と2.750で、それぞれ17 %と27 %速くなりました。 同じ比較で、シングルスレッドの古典的baselineは5 %しか変わりませんでした。

WSL exposes no temperature sensor, so the cause cannot be read directly. But the box had just finished 1.5 hours at sustained 8-thread load, and the multithreaded numbers moved while the single-threaded one barely did. Three rules adopted for the rest of the track: a latency number is only reported with the conditions it was taken under; nothing timed directly after a training run is trusted; and both measurements stay in the repository, because a number that was silently replaced is worse than a number that was wrong.

WSLでは温度センサーが見えないため、原因を直接読み取ることはできません。しかしマシンは8スレッドの連続負荷を1.5時間続けた直後で、 マルチスレッドの数値は変動し、シングルスレッドの数値はほとんど変わりませんでした。そこでトラックの残りでは3つのルールを採用しました。 latencyの数値は計測条件とセットでのみ報告する。学習直後に計測した値は信用しない。そして両方の計測値をリポジトリに残す。 黙って差し替えられた数値は、間違っていた数値よりも悪いからです。

Static INT8 turns the one-thread loss into a win, and takes nothing measurable with itstatic INT8は1スレッドでの負けを勝ちに変え、計測可能な損失はない

fp32 through ONNX Runtime: 3.57 ms on one thread. Static INT8: 1.38 ms, a 2.6× cut, under the classical pipeline's 2.13 ms with room to spare. (The MinMax and Entropy rows are the same file timed twice, see finding 02, so read 1.38 and 1.35 as one number with its spread.) On four threads 1.52 ms became 0.60 ms. mAP moved from 0.9107 to 0.9097, a drop of 0.0010; every class moved by 0.001 or less; recall on objects less than half visible stayed at 0.910 on the same 53 objects. The number step 5 could not deliver on one core is delivered by changing the arithmetic, not the network.

ONNX Runtimeでのfp32は1スレッドで3.57 ms。static INT8では1.38 msで2.6分の1になり、古典的パイプラインの2.13 msを余裕を持って下回りました （MinMaxとEntropyの行は同じファイルを2回計測したものなので（finding 02参照）、1.38と1.35はばらつきを含む1つの数値として読んでください）。 4スレッドでは1.52 msが0.60 msになりました。mAPは0.9107から0.9097へ0.0010低下し、どのクラスも変化は0.001以下、 半分未満しか見えない物体へのrecallも同じ53物体で0.910のままでした。step 5で1コアでは達成できなかった数値を、ネットワークではなく演算方式を変えることで達成しました。

Two of three calibration methods produce the same graph, and the elaborate one loses3つのcalibration手法のうち2つは同じグラフを生成し、凝った手法は負ける

MinMax and Entropy do not merely give the same mAP to four decimals: the two output files have the same SHA-256. The entropy histograms were built, and took four times as long, but the KL search kept the full range on all 21 quantized activations, which is what bounded activations without heavy tails give you. Percentile 99.99 costs 0.0048, five times the other two, and almost all of it on the box class (0.914 to 0.904). With 200 calibration images the percentile clip chose a range too tight for at least one tensor the box detections depend on. The default would have been fine here; the comparison is what makes that a measurement rather than a guess. Timing repeatability, measured on the same file in three fresh processes later that night: 1.36, 1.44 and 1.80 ms against fp32's 3.72, 3.96 and 4.51 ms, a ratio of 2.5 to 2.75×. Each table row is one sample from one quiet window, so the ratio is the result and gaps under 10 % between rows are not.

MinMaxとEntropyは、mAPが小数点以下4桁まで一致するだけではありません。2つの出力ファイルのSHA-256が同一です。entropyのヒストグラムは 実際に構築され、4倍の時間がかかりましたが、KL探索は量子化した21個のactivationすべてでレンジ全体を残しました。裾の重くない有界なactivationでは そうなります。Percentile 99.99は0.0048の低下で他の2つの5倍、そのほぼすべてがboxクラスです（0.914から0.904）。calibration画像200枚では、 percentileのclipが、box検出が依存する少なくとも1つのtensorに対して狭すぎるレンジを選びました。ここではデフォルトで問題ありませんでしたが、 比較したからこそ、それが推測ではなく計測結果になります。計測の再現性は、同じ夜のうちに同じファイルを新しいプロセスで3回計測して確認しました。 1.36、1.44、1.80 msに対しfp32は3.72、3.96、4.51 msで、比は2.5〜2.75倍です。表の各行は静かな時間帯の1サンプルなので、 結果として言えるのはこの比であり、行間の10 %未満の差は結果とは言えません。

Dynamic quantisation was expected to buy no speed; on one thread it bought halfdynamic quantisationは速度向上なしと予想したが、1スレッドでは時間が半分になった

3.57 ms to 1.82 ms on one thread, a 2.0× cut, but 1.54 ms on four threads against fp32's 1.52: nothing. The integer convolution kernels the dynamic path runs did the single-thread work faster and did not scale with threads, while the static QDQ graph did both. The paragraph written before the run said dynamic quantisation "saves bytes and buys no speed"; that expectation was wrong on one thread and the repository keeps both the expectation and the measurement, because a corrected prediction is part of the record.

1スレッドでは3.57 msから1.82 msへ2.0分の1になりましたが、4スレッドでは1.54 msでfp32の1.52 msと変わりませんでした。 dynamic経路が使う整数畳み込みカーネルは、シングルスレッドの処理は速くなったもののスレッド数に応じてスケールせず、static QDQグラフは両方を達成しました。 実験前に書いた段落では、dynamic quantisationは「容量は減るが速度は上がらない」としていました。この予想は1スレッドでは誤りでした。 修正された予測も記録の一部なので、リポジトリには予想と計測結果の両方を残しています。

Pruning is the wrong tool for this networkこのネットワークにpruningは不適切

Removing 25 % of the channels took 28 % of the multiply-accumulates and 20 % of the one-thread latency (3.57 to 2.84 ms), and cost 0.019 mAP after three fine-tune epochs. Removing 50 % took 53 % of the MACs and 32 % of the latency (2.42 ms) and cost 0.065. Latency falls slower than the arithmetic because narrow convolutions run the kernels less efficiently and the per-operator overhead does not shrink at all. Before fine-tuning the two pruned networks scored 0.220 and 0.000: the γ ranking was never trained toward sparsity, so what it removed was in use. Pruned 50 % plus INT8 reaches 1.25 ms, under 10 % faster than static INT8 alone, for seven points of mAP. The decision is static INT8 with no pruning; a smaller network is a training decision, train it narrow, not surgery on a trained one.

channelを25 %削除すると、積和演算は28 %、1スレッドlatencyは20 %減り（3.57から2.84 ms）、3 epochのfine-tune後でmAPは0.019低下しました。 50 %削除すると、MACsは53 %、latencyは32 %減り（2.42 ms）、mAPは0.065低下しました。latencyが演算量ほど減らないのは、幅の狭い畳み込みでは カーネルの効率が下がり、operatorごとのオーバーヘッドはまったく減らないからです。fine-tune前の2つのpruning済みネットワークは0.220と0.000でした。 γによる順位付けはsparsityに向けて学習されていなかったため、削除したchannelは実際に使われていたのです。50 % pruning＋INT8は1.25 msに達しますが、 static INT8単体より10 %未満しか速くならず、その代わりにmAPを7ポイント失います。結論は、pruningなしのstatic INT8です。 小さいネットワークが欲しいなら、それは学習時の判断であり、学習済みモデルへの手術ではなく、最初から幅を狭くして学習すべきです。