当前位置：首页 > news >正文

基於 MAC 的模型算力估算方法

news 2025/10/29 7:13:37

基於 MAC 的模型算力估算方法

1. 背景與目的

在評估深度學習模型（如檢測網路、分割網路）在嵌入式或 NPU 平台上的部署可行性時，通常需要估算所需算力（TOPS，Tera Operations Per Second）。
該算力可用模型的 乘加次數（MACs, Multiply-Accumulate Operations） 或 浮點運算次數（FLOPs, Floating-point Operations） 推算得到。

2. 基本公式

2.1 理論公式

模型的理論算力需求為：
$required_TOPS=required_MAC_per_sec1012 \text{required\_TOPS} = \frac{\text{required\_MAC\_per\_sec}}{10^{12}}$

其中：
$required_MAC_per_sec=MACs_per_frame×FPS \text{required\_MAC\_per\_sec} = \text{MACs\_per\_frame} \times \text{FPS}$

MACs_per_frame：模型處理一張影像所需的乘加次數（由工具如 thop、torchinfo、onnx_tool 得出）。
FPS：目標處理幀率（frames per second）。
結果的單位是 TOPS（每秒萬億次乘加）。

2.2 FLOPs 與 MACs 的關係

部分工具輸出的是 FLOPs（浮點運算次數），而非 MACs。
需要注意：

一次「乘加」運算包含一次乘法與一次加法。
因此：
$\text{FLOPs} = 2 \times \text{MACs}$
若工具報的是 FLOPs，則換算公式為：
$required_TOPS=required_FLOPs_per_sec2×1012 \text{required\_TOPS} = \frac{\text{required\_FLOPs\_per\_sec}}{2 \times 10^{12}}$

3. 精度對應與硬體標稱 TOPS

3.1 理論 MACs 不隨精度改變

不論模型使用 FP32、FP16 或 INT8 量化，其理論 MACs 數量不變，因為運算結構相同。

3.2 精度對應的硬體 TOPS

不同精度下硬體能達到的峰值 TOPS 不同：

精度	典型峰值算力（相對值）	備註
FP32	1×	高精度，算力最低
FP16	約 2×～4×	多數 GPU/NPU 支援
INT8	約 4×～16×	常用於推理部署

因此：

模型的理論 MACs 不變；
但比較時，應對照相同精度的硬體 TOPS（例如 INT8 模型對比 INT8 TOPS）。

4. 實際情況修正（利用率與系統因素）

4.1 利用率折算

實際運行時，NPU 不可能達到理論峰值。
原因包括算子支援度、記憶體訪問瓶頸、調度開銷等。

定義利用率：
$\frac{\text{實際達到的算力}}{\text{理論峰值算力}}$

常見範圍：

模型優化程度	利用率 u	說明
無特別優化，部分算子回退 CPU	0.1 – 0.3	低效
常見卷積網路（NPU 支援良好）	0.3 – 0.6	一般
廠商 SDK + kernel fusion 優化	0.6 – 0.9	高效

則：
$required_chip_TOPS=required_TOPSu \text{required\_chip\_TOPS} = \frac{\text{required\_TOPS}}{u}$

4.2 量化與軟體開銷（Overhead）

量化後的實際推理過程還會有：

Quantize / Dequantize 操作
部分算子仍由 CPU 執行（如 NMS、解碼層）
Memory Copy、Tensor Layout 轉換

可用一個修正係數 ( o ) 表示：
$final_required_TOPS=required_chip_TOPS×o \text{final\_required\_TOPS} = \text{required\_chip\_TOPS} \times o$
典型取值：

o = 1.05 ～ 1.25

4.3 其他實務限制因素

因素	說明
Memory Bandwidth	若頻寬不足，算子需等待資料載入，實際算力下降。
SRAM 容量	若中間張量無法放入片上 SRAM，頻繁訪問 DRAM 導致延遲上升。
Operator Coverage	若部分 Layer NPU 不支援（如 Sigmoid、NMS），則會退回 CPU。
NMS 與後處理	通常在 CPU 完成，需額外時間，對即時性有影響。

因此，在部署階段應透過 profiling 工具或實機測試驗證實際利用率與瓶頸所在。

5. 綜合計算流程（總結公式）

輸入參數

M：模型每幀 MACs（單位：GMac）
f：目標 FPS
u：NPU 利用率（0~1）
o：Overhead 係數（約 1.1）

計算步驟

計算每秒 MACs：
$M_{sec} = M \times f$
換算理論 TOPS：
$T_{theory} = \frac{M_{sec}}{10^{12}}$
考慮利用率：
$T_{nominal} = \frac{T_{theory}}{u}$
加上量化與軟體開銷：
$T_{final} = T_{nominal} \times o$

6. 範例

假設：

模型：YOLO11n
每幀運算：30 GMac
目標幀率：20 FPS
利用率：0.4（中等）
Overhead：1.1（10%）

計算：
$M_{sec} = 30 × 20 = 600\text{ GMac/s} = 0.6 \text{ TOPS (理論)}$
$T_{nominal} = 0.6 / 0.4 = 1.5 \text{ TOPS}$
$T_{final} = 1.5 × 1.1 = 1.65 \text{ TOPS}$

即：

實際部署 INT8 模型時，需要約 1.6 TOPS（INT8 精度） 的有效算力。

7. 結論與建議

MAC 為理論運算量，不受精度影響；FLOPs = 2×MACs。
TOPS 計算要與硬體標稱精度一致（例如 INT8 模型用 INT8 TOPS 對比）。
務必考慮實際利用率（u）與開銷（o）修正。
記憶體頻寬、SRAM、算子支援度與 NMS 的 CPU 開銷 都會影響最終性能。
建議預留 2～4 倍算力冗餘，以保證模型在實機上穩定運行。

算力需求與實際推理耗時之間的關係

🧩 一、NMS、前後處理對算力的影響

類別	是否計入「算力需求」(TOPS/MACs)	是否影響「每幀耗時」
卷積、全連接、BN、激活	✅ 是（這些構成 MACs/FLOPs）	✅ 主要耗時來源
上采樣、下采樣、Concat	✅ 是（通常算入 MACs）	✅
NMS（非極大值抑制）	❌ 否（不屬於算力核心運算）	✅ 可能佔 10～40% 時間
bbox 解碼、sigmoid/logit	❌ 否	✅ 較輕但不可忽略
圖像前處理（resize、normalize）	❌ 否	✅ 取決於實作方式
後處理（畫框、追蹤、融合等）	❌ 否	✅ 顯著增加 latency
量化/反量化（Q/DQ）	⚙️ 視平台而定：若在 NPU 中執行則算入；若在 CPU 則不算	✅ 影響整體時間

🧠 二、解釋

算力（TOPS）評估目的是衡量模型主幹在 NPU 上的乘加運算需求。
因此只統計 MAC 類運算（Conv、FC、MatMul 等）。
這些與輸入解析度、網路深度、通道數直接相關。
NMS / 前後處理屬於控制流程與少量運算邏輯，通常由 CPU 或 DSP 處理。
它們：
- 不消耗大量乘加；
- 不反映 NPU 的算力負載；
- 但會拉長整體 latency。

⚙️ 三、在項目中如何處理這部分

算力評估文檔（如你在做的芯片選型報告）中：

只統計主幹網路（backbone + neck + head）的 MACs/FLOPs。
不包含 NMS、decode、前後處理。
性能預估（latency profile）報告中：

需加上 NMS、decode、前後處理的 CPU/DSP 時間，給出實際 FPS 或 ms/frame。