為裝置而設計：NAS 與部署流程

從壓縮到搜尋

先前每一篇導覽都把架構視為既定，再讓它變便宜。但對手機最高效的模型，其「形狀」可能與你為 GPU 設計的根本不同——不同的深度、寬度、核大小與運算子選擇。神經架構搜尋（neural architecture search, NAS）把這形狀的發現自動化：你不再手調網路，而是定義一個可能架構的搜尋空間，讓演算法在你的約束下找出其中最佳的一點。

早期 NAS 惡名昭彰，要花數千個 GPU-日從零訓練每個候選。現代 NAS 便宜得多，主要歸功於「權重共享」：只訓練一個大型「超網路（supernet）」一次，使每個候選架構都是它的子網路，再讓候選繼承超網路的權重來評估，而非重新訓練。搜尋於是變成在子網路間的搜尋，而非上千次訓練。

硬體感知 NAS：把延遲放進損失

只搜尋準確度，等於重新發明雲端模型。高效 AI 的關鍵一步是硬體感知 NAS（hardware-aware NAS）：把「真實」目標裝置上的「真實」成本直接折進目標函數，讓搜尋同時優化準確度與裝置端延遲或能量。關鍵在於，成本項是在實際晶片上量測（或由延遲模型預測）的——因為 FLOPs 是個糟糕的代理。兩個 FLOPs 相同的層，可能因記憶體存取模式、以及加速器對哪些運算子有硬體支援，而在延遲上相差 5 倍。

\mathcal{L}(\alpha, w) = \mathrm{CE}(w, \alpha) + \lambda\,\mathbb{E}_{\alpha}\!\left[\mathrm{LAT}(\alpha)\right]

硬件感知的 NAS 把实测的端侧延迟直接写进训练目标，用 λ 在精度与真实速度之间权衡。

# hardware-aware search objective
reward = accuracy(arch) - lambda * latency_on_device(arch)
#                                    ^ measured on the target chip,
#                                      not estimated from FLOPs

硬體感知目標在準確度與量測得到的裝置端延遲之間取捨。

把它組起來：一條真實的邊緣流程

裝置端推論正是所有這些工具會合之處。從一個訓練好的雲端模型，到一個能出貨的邊緣部署，務實的路徑通常會依序疊上其中數項，並在每階段後於目標上重新量測：

挑選或搜尋一個對裝置友善的架構（硬體感知 NAS，或一個已知優良的行動主幹網路），讓形狀從一開始就貼合矽晶片。
在結構上縮小它——結構化剪枝冗餘的通道與頭，必要時從較大的教師模型蒸餾以恢復準確度。
最後量化——以訓練後量化轉為 INT8 或 INT4，因為它是最便宜、最寬容的一步，並能疊加在其他一切之上。
匯出到可攜的執行階段——轉成如 ONNX（或廠商的行動執行階段）這類格式，讓同一張計算圖能在裝置的 CPU、GPU 或 NPU 上執行。
在真實裝置上對延遲、峰值記憶體與能量做基準測試；反覆迭代，直到預算與準確度下限都達標。

前緣將往何處去

兩個想法推動這個領域前進。其一，雲端與邊緣的界線正在模糊：服務系統越來越會拆分一個請求，在裝置上跑一份便宜的草稿，只把困難的部分升級到伺服器——效率技術正變成跨整批機群的「路由」決策。其二，最低精度的前緣（三元權重、原生低位元訓練）暗示著，最高效的模型不會是訓練後才壓縮，而是從第一步起就為便宜而設計。

p_{\text{accept}}(x) = \min\!\left(1, \frac{p(x)}{q(x)}\right)

推测解码以 min(1, p/q) 的概率接受廉价的端侧草稿 token，只有在目标模型不一致时才升级到更大的模型。