前一天把 Model 跑起來之後，我們得到一個數字：

2.7 FPS。

這個速度拿來做即時影像分析，明顯不夠。

所以我們先不急著換 Model，而是把 Pipeline 拆開來看：

RTSP Camera
   ↓
Decode
   ↓
Resize / Pre-process
   ↓
AI Inference
   ↓
Post-process
   ↓
Rule
   ↓
Event

問題很快就出現了。

原本的測試大部分工作都在 CPU：

frame = cv2.resize(frame, (640, 640))
input_tensor = preprocess(frame)

with torch.no_grad():
    result = model(input_tensor)

result = postprocess(result)

Model 在跑，CPU 也在忙。

那 Qualcomm NPU 能幫什麼？

我們開始把 AI Inference 從 CPU 移到 QCS6490 的 HTP/NPU。

概念上：

PyTorch
   ↓
ONNX
   ↓
QNN Model Conversion
   ↓
QNN Runtime
   ↓
HTP / NPU

但這裡不是轉完就結束。

還要確認：

• Operator 支不支援
• Input / Output Shape
• FP32 / FP16 / INT8
• 有沒有 CPU Fallback
• Pre-processing 在哪裡跑
• Post-processing 在哪裡跑

其中一個很容易被忽略的問題就是：

NPU 很快，但前後面的工作還是在 CPU。

所以後來我們開始把 Video Pipeline 往 Qualcomm / GStreamer 方向調整：

gst-launch-1.0 \
  rtspsrc location=rtsp://camera ! \
  <hardware decoder> ! \
  <video convert> ! \
  <preprocess> ! \
  <QNN / HTP inference> ! \
  <postprocess> ! \
  appsink

實際 QCS6490 上會再依 Qualcomm Linux / BSP 使用對應的 GStreamer Plugin，例如 qtirtspbin、qtiml*、V4L2 等。

最後的結果

原本：

CPU：約 2.7 FPS

調整 QCS6490 HTP/NPU 後：

Inference：約 31 FPS

看起來提升很多。

但這裡還不能直接說：

「我們的產品達到 31 FPS。」

因為要先確認：

31 FPS 是 Model Benchmark，還是 End-to-End？

真正產品要算的是：

Camera
 ↓
Decode
 ↓
Pre-process
 ↓
NPU
 ↓
Post-process
 ↓
Rule
 ↓
Event

所以 Day 7 我們先得到一個結論：

NPU 加速不是把 Model 丟進去就結束，而是要把整條 Pipeline 一起調。

而下一個問題就是：

單路 31 FPS 很漂亮，那 2 支、3 支 Camera 呢？