Orin TensorRT FP32 部署與 A/B 量測

1 · 結論與計畫

目標是先保留既有 CUDA FP32 基準，再只對 Orin 主 SenseVoice 模型切換 ORT TensorRT EP；TurnSense 維持 CUDA，模型與精度不變。

• 設計：2026-09-04-orin-tensorrt-deployment-design.md
• 計畫：2026-09-04-orin-tensorrt-deployment.md
• 4090 對照來源：2026-09-01-model-quantization-eval.html 第 7.2／7.5 節
• 部署映像：v5.8.0-dirty-orin@sha256:69012fbc…afce4

2 · 代號與名詞

2.1 ID 對照

2.2 名詞定義

3 · Orin A/B 與 4090 對照

圖層：固定 seed synthetic feature，T=50/100/250，各 10 次 warm-up + 50 次正式執行。服務層：同一組 3／6／15 秒 WAV、3 次 warm-up、單一 WebSocket series。

3.1 圖層

4090 的上一份報告只記錄 T=50／100 的 p50，沒有 p95，也沒有同尺的 T=250；缺值不以推測補齊。

3.2 服務層（KITT WebSocket 路徑）

測試經過真正的 WebSocket 與 frame 流程，但表內取 final frame 的 server_latency_ms： 服務端準備 recognizer stream、等待 recognizer lock、解碼及 ITN 的時間；不包含 3／6／15 秒送音時間或 WebSocket/client backlog。因此它是上一份報告所稱的「服務層」，不是完整產品端到端延遲。

3.3 同 shape 圖層：兩平台各自的 CUDA／TRT 收益

兩份報告都使用出貨中的 SenseVoice FP32 graph、batch 1、相同動態 profile T=1/100/2000，且都有 T=50/100 的 p50；這是跨硬體最接近同口徑的一組。 同尺數據已合併在 第 3.1 節；兩台平台都從 TRT 受益，但平台內收益不同： 4090 約 4.30 倍，Orin 約 1.83–1.86 倍。

3.4 服務層：兩份報告只能比較平台內收益

4090 的數字是 sherpa-onnx recognizer 端到端 p50，Orin 是由實際 WebSocket 路徑觸發的 final recognizer latency， 量測邊界、輸入組合與執行環境不同，所以 14.32 ms 與 Orin 的絕對延遲不能當成硬體排名。能安全比較的是 同一列內從 CUDA 切到 TRT 的方向與比例：4090 是 1.22 倍，Orin 的六組服務路徑是 1.10–2.09 倍。

4090 原報告另記錄三次服務層結果為 1.07×／1.22×／1.31×，共用 GPU 的變異較大； 因此本表用 1.22× 作該次正式列值，但不主張它比 Orin 的收益低。來源： 4090 報告第 7.5.3 節。

3.5 Orin 圖層最大 profile：延遲與記憶體

這一節只回答「直接執行 ONNX graph 到最大 profile」；3／6／15 秒 sherpa-onnx recognizer 的 啟動及推論後記憶體另列於 第 3.6 節，部署中服務的穩態 RSS 則列於 第 7.2 節。

同一個 FP32 ONNX、batch 1、T=2000、固定 seed，各 provider 在獨立 NVIDIA Kubernetes Job 執行 3 次；穩態延遲取後兩次中位數。CUDA profiler 記到 CUDA 與 CPU shape-op 節點，TRT profiler 只記到 TensorrtExecutionProvider，沒有 CUDA／CPU 節點 fallback。

Orin 使用統一記憶體，cgroup 與程序 RSS 是兩個獨立 Job 間的主要比較尺。tegrastats 量的是全機 RAM；量測時 production TRT service 與 cache 已常駐，因此其全機增量只作交叉檢查，不當成 TRT 的獨立總 footprint。

3.6 sherpa-onnx 啟動與 3／6／15 秒統一記憶體

每列都在全新 NVIDIA Kubernetes Pod／Python process 中載入同一個 FP32 模型、num_threads=2， 先解一次相同 3 秒 WAV 暖機，再解指定 3／6／15 秒 WAV。TRT cache-warm 命中 persistent engine cache， 但仍讀原始 ONNX、切圖並建立 network；TRT offline 則以 12,273-byte EP context model 直接引用 984,896,180-byte sm87 engine。

Orin 的 CPU 與 GPU 共用 LPDDR，因此不存在可另外填的 per-process GPU VRAM。RSS 會把共用 TensorRT library／檔案頁整份算進每個 process， 所以部署容量判斷應優先看 PSS 與 Pod cgroup；tegrastats 的 RAM 是全機值，只作交叉檢查。

4 · 實作與驗收

• Orin image 加入 TensorRT 10.3 runtime libraries，build-time ldd 擋 unresolved dependency。
• config-k3s-orin.yaml 覆寫主模型為 trt:/app/config-trt-orin.config；base 仍是 CUDA。
• profile：batch=1，T=1/100/2000；engine/timing cache 掛到 /data/srdc/kitt-stt-trt-cache。
• Pod 內確認 libnvinfer.so.10 與 ORT TRT provider 常駐，產出 984,899,100-byte sm87.engine。

✅ 5 · 測試結果（累積追溯表）

所有測試的累積結果。這張表只增不減——過去每一輪的測試都要繼續通過。

依 docs/spec.md CLAUDE.md section 8 第 4 點，此表只增不減：沿用歷輪聯集的所有列， 只新增或更新（SW-DOC-02 機械把關）。

(a) Feature 總覽

計數基準：數的是行為契約（SW_id）的條數，不是測試個數——多條 SW_id 可共用同一個測試檔。驗證方式（離線／live）不影響分組，只出現在「測試」欄。

數量由 pytest --collect-only 直接輸出；「來源」欄為該檔首次加入的 cycle。

6 · 架構與 Frame 資料流

6.1 STT SW stack

6.2 Frame 處理流程

6.3 Frame I/O 契約

7 · 記憶體、冷啟動與限制

7.1 Orin 部署限制

• 常駐 RSS：CUDA 約 4.02 GB；TRT 穩態約 9.20 GB，增加約 5.18 GB。TRT 首次建 engine 的 VmHWM 約 9.81 GB。
• 三種生命週期：online cold build 約 68.19 秒；cache-warm sherpa session 載入中位數 21.74 秒；offline EP context 載入中位數 11.42 秒。只有最後一種跳過 builder。
• profile 邊界：T 最大 2000，超界不是效能下降而是 shape 不符合；最大點 TRT 533.47 ms，較 CUDA 474.24 ms 慢 12.5%。最大錄音時限仍是跨 repo 的既有 gap。
• live 例外：/debug/logs 在 Orin K3s 刻意關閉，避免無驗證端點暴露實際語音 log，因此該單一 live case 不適用。
• 靜態 gate：本輪兩個 Python 修改檔 ruff lint/format 與 pyright 都是 0 error；全 repo 仍有既存的 ruff 29 項與 pyright 107 項型別債，本輪未擴張範圍修理。

7.2 4090／Orin 記憶體與資源對照

7.2.1 Orin 三種載入方式：offline 欄位

3／6／15 秒各一個全新 Pod；表內「中位數」取三個音長 arm 的中間值，15 秒列則直接取 15 秒 arm。

這是隔離 sherpa-onnx recognizer，不是整個 KITT service Pod；offline 數字不能直接取代目前部署的 9.20 GB 服務 RSS， 但足以證明主要額外記憶體來自 cache-warm 載入時仍存在的 ONNX 解析／TensorRT builder 路徑。

7.2.2 4090 與 Orin：只能比較各平台內方向

4090 資源來源：第 7.2.4 節、 第 7.5.3 節、 第 7.6.2 節。跨平台最可靠的結論是「兩台都需要自己的 engine 與量測」； 不能用 4090 的 4.30× 或記憶體配置直接預測 Orin。Orin 短句記憶體見 第 3.6 節，最大 profile 見 第 3.5 節。

8 · 產出與採用判定

9 · 2026-09-05 同 cycle 重測

Orin 短句收益重現；4090 舊 CUDA 圖層基準未重現；服務文字並非逐次完全相同。 兩台各完成 CUDA/TRT × 3/6/15 秒 × bulk/realtime × 三輪，共 72 個成功 final。 完整 JSON（含每次數字、文字、hash、版本與 shell 命令）見 本輪原始量測摘要。 原正式服務未切換、未重启，僅使用臨時容器。Orin image digest 與 2026-09-04 報告相同，因此無須 cross compile sherpa-onnx。

9.1 量測條件與可比範圍

兩台 source 均為 49f0488，模型／tokens 及兩個主要服務 source SHA-256 逐一相同。 4090：ORT 1.23.2 / TRT 10.13.3.9；Orin：ORT 1.24.0 / TRT 10.3。 FP32、batch=1、T=1/100/2000；graph 固定 seed 42、threads=2、10 次暖機與 50 次取樣，計時時關閉 ORT profiler，另起程序證明 provider。 服務沿用 hardware_profile.py、3 次暖機、每 provider 三個獨立 series，保留 streaming interim 與 Perfetto。

音檔由版控 multiuser-10s.wav 的 PCM 重複並裁切為 3/6/15 秒，兩台 hash 一致； 舊 WAV 未保存，故未宣稱與歷史音檔逐位元一致。15 秒在第 10 秒拼接；只能作本次兩 provider 的共同 workload。 GPU 仍與既有程序共用，未鎖 GPU clocks。服务 latency 是 server final recognizer，不包含 browser、LiveKit 或送音時間。 每組只有三次，範圍代表觀測到的波動，不是信賴區間。

9.2 圖層基準：4090 的舊 CUDA 數字不宜直接沿用

4090 改 threads=0／2／4 都約 8 ms；額外啟用 ORT profiler 後，T=50/100 的 p50 為 19.82/21.64 ms。profiler 確實大幅增加 CUDA 的多節點執行開銷， 但舊腳本缺失，這不是舊 26 ms 根因的證明。兩台 TRT 的獨立 profiler 證明皆只有 TensorRT node events。 Profiling 的數字只用於開銷實驗，不混入主比較表。

9.3 WebSocket 服務：短句收益較穩，長句與共享 GPU 波動須揭露

9.4 文字重複性：單獨 recognizer 一致，服務仍有差異

兩平台 × 三個音長 × CUDA/cache-warm/offline，各三次直接 recognizer 解碼，共 54 次， 同平台同音長的三種 provider 輸出一致。服務則有 15 秒「風量開」／「風量開大」與斷句差異； Orin realtime 3 秒也有逗號／句號差異。Orin 15 秒 CUDA 與 TRT 兩邊都出現變體， 因此不能將它歸因於 TensorRT 降精度；也不能再把本次完整服務結果稱為逐次文字完全一致。 本輪只確認現象，未定位到具體排程／前處理根因，未修改產品程式。逐組變體已保存於 JSON。

9.5 載入與記憶體：offline 的收益保留，cgroup 未作歷史同尺比較

每個 arm 使用全新 recognizer 程序，最後一輪已停止全部臨時服務。下表的中位數取三個音長 arm， 不是同一個音長重啟三次。load 計時含 sherpa/soundfile import 與 recognizer 建構；ready 指尚未暖機。 PSS 是按比例分攤共享頁的程序記憶體；MiB=2²⁰ bytes。本次共用同一個臨時容器，cgroup 會累積 page cache， 所以不與原報告的 fresh-Pod cgroup 總量直接比較。舊 MB 標記也不假設等同 MiB。 這是 isolated recognizer，不能取代整個 production service 的 RSS。

新的空 cache 建置時間：4090 22.78 秒，Orin 69.15 秒 （舊 Orin 68.19 秒）。EP context 複製必要 metadata 後，在原始 ONNX 暫時移開的狀態下仍可辨識；兩台 offline profiler 都只有 TensorRT 節點。 沒有把 cache hit 改名成 offline。Orin cache-warm 載入範圍仍達 15.97–44.89 秒，單一 21.74 秒不能代表每次啟動。 目前正式部署仍用 cache-warm，本次没有改 release 載入路徑。

9.6 最大 profile：T=2000 仍非 TensorRT 甜蜜點

每 provider 全新程序，1 次暖機、3 次正式執行；這是 graph 的最大形狀，不是 120 秒 WebSocket 服務測試。 不能把短句倍數外推到這個上限。

9.7 驗證、產物與未覆蓋範圍

• 全套離線入口 ./tests/test.sh：625 passed / 28 skipped，15.49 秒。TurnSense 模型未在新 worktree materialize，22 條相關測試 skip；其餘 skip 保留於 log。完整 live suite 本次未重跑；實際跑的是 72 組服務 benchmark。
• 新增量測腳本有 --self-check；Ruff 與 diff whitespace 檢查通過；報告／追溯測試 39 passed，Playwright 截圖已人工檢視。首次 sandbox executor hang 不算產品失敗，外部執行同套件通過。
• 臨時 Docker 與 Orin Pod 已刪除；正式 Orin Pod 仍 1/1、零 restart，原 4090 四個推論程序保留。原始 log、每次 JSON、WAV、命令與 engine 保存在 tests/batch_decode/results/recheck_20260905/（gitignored）；可審查的精簡 JSON 已進版控。
• 本輪驗收 R1（同模型與音訊）、R2（graph 與 provider 證據）、R4（服務三輪）、R5（歷史比較）完成；R3（程序記憶體）完成，fresh-Pod cgroup 的歷史同尺比較未覆蓋。
• 下一個需要獨立定位的問題是服務 15 秒文字重複性；本輪不將它修補或歸罪於 TensorRT。

重跑 graph 的最小命令（在備齊本平台 CUDA/TRT 函式庫的容器內）：

python3 tests/batch_decode/provider_recheck.py --provider cuda   --model /app/models/sherpa-onnx-sense-voice-kitt-wake-lora-v1/model.onnx   --cache /bench/cache --frames 50,100,250 --threads 2 --warmup 10 --repeats 50   --out /bench/graph-cuda.json
# 改 --provider trt 為同平台 TensorRT；--profile 只另跑 provider 證據，不混入主計時。
python3 tests/batch_decode/hardware_profile.py --target ws://127.0.0.1:19242/stt/sensevoice   --lengths 3,6,15 --warmup 3 --out /bench/service-cuda-1

所有 orchestration shell 全文保存在 JSON 的 commands；provider_recheck.py 為版控腳本。 EP context 相對 engine 路徑的限制依據 ONNX Runtime TensorRT 官方文件；本次亦實際驗證絕對路徑會被拒絕。

10 · deploy.sh 與新 image 重測（完整量測，已發布）

更新時間：2026-09-05T22:21:14.012602+08:00。最終 72 個服務測項已完成；15 秒差異保留為未定位事項。

10.1 建置與部署：首次 Orin 75 分 26 秒

同一 worktree，HEAD 5405eac；應用程式碼未修改。Orin 由 deploy.sh 完整 build／push／deploy；4090 由 Dockerfile 重新 build，另加 TensorRT 10.13.3.9 測試相依層，兩 provider 使用相同 image。此輪不 commit。

Dockerfile.orin 已改為 max(1, floor(nproc / 2))。本機 32 CPU 對應 16 jobs，已驗證 1／2／3／8／32 CPU 算式；沒有用這兩次 build 宣稱並行設定帶來加速。基底下載、磁碟 I/O 與快取狀態不同，兩次時間不能當受控效能比較。QEMU 是在 x86 上執行 arm64 建置程序的模擬層，本次 sherpa 不是原生 x86 編譯。

10.2 同碼圖層：兩平台短句 TRT 收益重現

兩平台的 model.onnx、tokens.txt、batch_asr_manager.py、kitt_stt_service.py SHA-256 完全相同。固定 seed、T=50／100／250、10 次暖機、50 次正式執行；主計時不開 profiler。音長是 shape 約當值，實際 WAV 服務量測另列。4090 ORT 1.23.2，Orin ORT 1.24.0，平台 runtime 不同。

10.3 記憶體：每個 recognizer 測項使用新容器／Pod

3／6／15 秒各啟動一個新程序與新容器，使用 cache-warm TRT。表內 ready 是模型載入後、暖機前；PSS／RSS／cgroup current 為三個音長測項中位數，程序 HWM 為三個測項的最大值。單位均為 MiB。cgroup 包含檔案快取；Orin 的統一記憶體不能拆成獨立 GPU VRAM。

Orin kernel 提供 memory.current，未提供 memory.peak，因此容器峰值標示為不可用；程序 VmHWM 仍有記錄。本輪尚未重測 offline EP context，舊數據保留在第 7／9 節，不能視為這輪新 image 的驗證結果。

10.4 4090 服務歷史批次：與編譯並行的 36 個有效測項

CUDA／TRT × 3 音長 × bulk／realtime × 3 輪，共 36 個有效 final。表為三輪中位數。服務量測與 Orin 交叉編譯共用 x86 主機，不能當作無編譯負載的最終基準；尤其 CUDA bulk 与 15 秒比上一輪偏高，編譯結束後的結果見 第 10.6 節。主機仍有其他 GPU 程序。

此 TensorRT 服務首次使用空 engine cache，包含 target-side 建 engine 的成本；暖快取完整服務記憶體見 第 10.7 節。最初另有一個無效嘗試：客戶端冷載入模組約 40 秒，導致 keepalive timeout，沒有送達音訊；已保留 log 並排除。客戶端改為連線前載入模組後，三輪成功，服務 code 未修改。

10.5 前期驗證與可重現資料

資料：本輪完整 JSON；原始 log、WAV、指令位於 tests/batch_decode/results/deploy_recheck_20260905/。模型量測的 Orin image 為 v5.8.0-recheck-20260905-orin，最終服務使用 v5.8.0-recheck-ncpu-20260905-orin，兩者僅建置並行數的寫法不同；精確 image 參照在 JSON。後續更新沿用本 cycle，保留中途失敗與历史數據。

10.6 最終服務：兩平台 72 個測項成功，4090 的 15 秒仍有差異

本節為編譯結束後的服務補測，各平台 CUDA／TRT × 3／6／15 秒 × bulk／realtime × 三輪，共 72 個有效 final。表內為三輪中位數。4090 用相同新 image 與暖 engine cache；Orin TRT 直接測最終 deploy.sh 部署的 Pod，CUDA 使用同 image 的獨立測試 Pod。GPU 與其他既有工作共用，未鎖 clocks，因此不是專用硬體的無負載基準。

4090 前一輪 overlay 的 15 秒 bulk CUDA／TRT 為 39.06／35.61 ms，本輪為 72.64／75.10 ms；realtime 由 39.02／26.07 ms 到 74.55／54.44 ms。新 image 的 graph 數字卻接近前輪，因此不能直接歸因於模型 kernel 退化。並行編譯曾使 3／6 秒 CUDA bulk 高到 50.46／60.64 ms，補測回到 22.45／26.83 ms；15 秒差異則仍在，需要另查服務前處理、排程與 runtime 載入差異，本輪未聲稱已定位根因。

文字方面，Orin 本輪 15 秒各 provider 及送音模式回覆一致；4090 CUDA 的 15 秒仍有「風量開／風量開大」與句讀差異，TRT 本輪三輪一致。這是小樣本重複性觀測，不足以證明哪一個 provider 精度更好，也未修改服務辨識行為。

10.7 最終完整服務記憶體：暖快取與首次建 engine 分列

以下為完整服務，而非 10.3 的独立 recognizer。ready 為 HTTP health 通過、送音前，end 為三輪測試後；單位 MiB。Orin 正式 Pod 的 HWM 自本次啟動起累計。兩平台 RSS／PSS 的差異也受共享 library 頁面分攤影響。

4090 TRT 首次從空 engine cache 啟動時 ready PSS 為 10978.1 MiB，暖快取重啟為 9158.1 MiB（約 10.72 → 8.94 GiB）。記憶體報告應指出是否包含首次建 engine，不能混用。4090 獨立 recognizer 的整卡 VRAM 在載入前均約 9569 MiB，CUDA ready 約 10998 MiB，TRT 約 11076 MiB；觀測增量約 1429／1507 MiB，整卡仍包含其他程序，不當作程序專屬分配量。

10.8 驗證與交付狀態

• 兩次 deploy.sh 成功：首次 4526.42 秒，動態 CPU 版本 2308.95 秒；第二次有前置 layer cache，不能把時間差當成 CPU 公式效益。
• 完整離線測試 652 passed／1 skipped；文件測試 39 passed。完整 live suite 未跑，這次服務 benchmark 獨立記錄為最終 72 次成功，加上並行編譯時 36 次成功。
• 測試客戶端冷載入的 keepalive timeout、過早建立 port-forward 的 readiness 失敗均保留 log，排除於有效測項。
• 測試 Pod／Docker 容器已清理；Orin 保留新部署。此輪不 commit、不 push。
• 使用者已確認公開目的地與內容，報告已發布至 Cloudflare Pages。