kitt-stt 效能與記憶體研究

2026-09-12 · 67160fab1a16f52945e11da37070a144cc6511d1 · RTX 4090

已證實的主要成本是 interim 重算／排隊、hotword beam search，以及 tracing 的鎖內序列化。 四席 30 秒音訊，把 interim 起始與最小間隔從 0.5 秒改為 1 秒，final 中位數為 301.5 ms；兩次 0.5 秒對照分別是 539.6／487.8 ms，相對降低 38.2–44.1%。這是固定音訊的實測改善，字幕更新頻率與喚醒／轉錄品質限制見下文。

這份報告把可重播的改善、已量到的成本，以及仍需要實驗的候選方向分開標示。沒有修改 production source、push 或部署。所有結果只代表本次硬體、模型、設定與音訊；不能宣稱已窮盡任意輸入與部署環境的所有瓶頸。

優化優先順序

實驗身分與可重播性

ASR provider API 本身未提供 active-provider accessor。本次 native sample 在同一條 decode_stream → _sherpa_onnx → ONNX Runtime 堆疊中實際觀測到 CUDA provider／CUDA driver；因此可以確認 ASR 執行了 CUDA 路徑，但不能說所有 operator 都在 GPU。TurnSense 額外保存 session.get_providers()，並有啟動時 CUDA assertion。這比只看 available_providers 或模型設定更強；它仍不是 GPU kernel 計時。

所有音訊以 repository 的 tests/functional/audios/say-open-door.wav 為來源，重複其真實 PCM 並裁成 1／3／6／15／30／60 秒；沒有呼叫 TTS 或使用 generator 的 BASE_TEXT。這是固定「打開車門」內容的延遲負載，並非多語言或辨識準確率資料集。來源 WAV、每個 clip 的長度與 SHA-256 都有保存。另有中文／英文 wake 的既有 fixture 小型功能對照，與延遲負載分開。

測試重用 repository 的 RemoteFrameProcessor、真實 WebSocket、VAD frames 與 collector。每回合先送 2 秒靜音 preroll，再按絕對 20 ms deadline 送 PCM。標準組為每種長度 3 個同步回合、每回合 4 席；每長度的 12 筆席位結果共享模型，不能當成 12 次獨立試驗。warmup 有獨立欄位並排除於延遲表；raw rows 仍保留。所有 p95 都只是這些樣本的描述，不是 SLO 或 production p95 估計。

重播的 status=ok 只表示收到預期 final 與 EOT commit、沒有重複／跨回合污染，且 pacing 合格。reason=timeout 另外保存，不能因此稱為 Smart Turn 品質測試通過；本次沒有做完整 EOT 分類評分。

速度 A/B

client_final_latency_ms 從 client 排入 VAD-stop 起算，到 segment final 到達；它含傳輸與 pipeline 等待。server_latency_ms 是 ASR 階段的既有指標，沒有涵蓋該 callback 開始前的等待，也不能當成完整 final latency。eot_latency_ms 則等到帶 metadata.eot.decision 的 commit，涵蓋 final-transcription carrier 或明確 stop carrier。

「累計 ASR path」包含 interim／final 各次 inference 的 latency 與 recognizer queue；多席位等待會重疊。它是工作量／排隊壓力的指標，不能加總成 GPU kernel time 或直接當 CPU 使用率。

4 WS 各 1 席使用同步 barrier；其 clock skew 與 pacing 在 raw rows 中保留。這組是共用已暖機程序的拓撲探索，不能直接和上方新程序 A/B 合併。沒有看到穩定改善，因此不建議把多開 WS 當成已證明的優化。

Hotwords／beam search 與功能代價

以全新服務只改 hotwords enable 或 beam paths，cadence 與 tracing 不變。關掉 hotwords 同時切換成 greedy search；這不是只略過一個字串表。因此效能差距是整個 decoding policy 的差異，需要一起評估專有詞、英文 wake、同音字與誤喚醒／漏喚醒。下表重用既有三種 fixture 的 _run，每種每設定 5 次，保存每筆 finals／TTS／errors；通過條件是精確 normalized final、無 error，active case 另要求 TTS。這個固定小 corpus 不能證明整體辨識品質不變。

baseline 功能結果 · greedy · beam 4 · 1 秒 interim；不是原本 15 repeats、90% threshold 的完整 live pytest suite。

Frame timeline 與原生 flamegraph

整合 Perfetto trace：ASR／TurnSense／client／memory · 整合 SQL · 實際查詢結果。所有時間按原始 monotonic origins 對齊；保留 warmup，memory 排除 shutdown。可載入 Perfetto UI，或交給官方 TraceProcessor API 分析。

這張圖對齊 client 的 monotonic clock 與兩份 tracer origin。四席同一條 WS 的 VAD-stop callback 依序處理，之後每席的 ASR 與 TurnSense 可在自身 callback 內並行。後面席位在 callback 開始前的等待不會出現在該席的 rec_lock_wait(final)，因此不能只找最大 decode span。

ASR 的 prep、rec_lock_wait、decode、post、itn、seg_lock_wait 用 Perfetto SQL 與 raw JSON 逐組核對 count／sum。TurnSense supplement 分出 waveform prepare、feature extraction、native ONNX 與整體 path；剩餘差值仍可能包含排程與 semaphore 等待，不強行分配成某個原因。既有 final_tm_break.itn_ms=0 欄位不能替代真實 itn span。

保存 16,393 samples、5,606 個 frame definitions、7 個 thread profiles；py-spy log 記錄 36 個 errors。這份 profile 的 30s final 中位數 1133.7 ms，顯著高於 clean baseline 529.5 ms，因此不以它的 span duration 作為 production 效能數字。上方階段表與 frame timeline 改用沒有 py-spy 的獨立重播。

完整 Speedscope · thread weights 與 ASR→CUDA 原始 stack 範例

橫軸是堆疊取樣權重，沒有時間先後順序；不同執行緒的權重可以重疊。native CUDA host call 的等待不等於 GPU kernel 執行時間。圖中相鄰、未解析符號的同一 native module 合併為模組名稱，完整位址／檔案／行號與 thread profiles 都在 Speedscope JSON。原生 library 多數沒有完整 debug symbols，因此不要從十六進位位址推測 operator。

Tracing 對量測本身的成本

PerfettoTracer.write_trace() 在同一把 lock 中完成 trimming、metadata 建構、json.dumps(indent=2)、gzip、atomic rename 與舊檔清理。producer 也拿同一把 lock。source 指向 utils/perfetto_trace.py:317–380；詳細 caller inventory 與所有 raw microbenchmark 參見 tracer.md。

56,268 是已保存 live snapshot 的 regular event count，該 snapshot 涵蓋一席、四席與 idle，並非單一四席 turn；75,000 是額外壓力樣本。compact 的每個正式 pair 都逐次核對完整 decoded JSON 相等。75k compact 的三輪 p50 曾出現 811／90／1,238 ms，原因尚未確診，全部保存，不能只採最快一次或外推成固定加速比。

重疊是時間對照；搭配真實 lock probe 才支持 producer 阻塞機制。時間點本身不足以把所有 final 尾延遲歸給 tracing。兩種 tracing 的 final median 沒有一致改善，應以 flush／loop continuity 與記憶體成本評估這個改法。

去除縮排、減少高頻 trace 事件、縮短 retention、snapshot 後移出 lock，分別會影響序列化、記憶體與 producer 阻塞。只有 compact 是本次已實作的暫時 A/B；其他方向須保持 thread safety、UID metadata、輪替與 trace 完整性後再測。關閉 tracing 會減少可觀測性，因此報告不把它當作唯一解法。

記憶體：用量、保留與生命週期

RSS 來自 /proc/<host PID>/status，PSS／USS 來自 smaps_rollup；USS 為 Private_Clean + Private_Dirty。GPU 使用 host PID 精確比對 nvidia-smi，每秒更新；process memory 每 200 ms 取樣，保留 PID starttime 防止誤讀重用 PID。缺失值保留 null，沒有用零補值。CPU seconds 使用 /proc/<pid>/stat，與 stack-sample 權重分開。

目前 config-k8s.yaml 繼承 base 的 production tracing，並明確開啟 debug log endpoint。deployment/k8s/kitt-stt/deployment.yaml:49–57 的 CPU request／limit 為 2／4、memory 8／20 GiB，dev deployment 也相同，不能直接把這台 32 logical CPU host 的數字當作部署容量。

表中的 idle floor 排除 server shutdown：runner 在 client 結束後至少等 12 秒才關閉 server，分析只使用最後 EOT 後 11 秒內的資料，再取最後 10 筆中位數。否則 CUDA context 拆除時的低值會造成假的「釋放」結論。VmHWM 只保留作輔助，不用來判斷 leak。PSS／USS 與 RSS 的差異、native arena 與 GPU pool 的保留都不能直接歸因為 Python leak。1 秒 interim 圖中約 125–165 秒的 PSS／USS 暫降，並未伴隨 RSS 相同幅度下降；本輪未保存完整 VMA sharing 明細，不將它解讀為釋放了等量實體記憶體。

20 次正常連線／發話／斷線均收到 final 與 commit。live service 最大為 3，最後為 1；session／segment bytes 都回到 0，preroll 剩 64,000 bytes。最後 USS floor 為 2263.3 MiB，沒有觀察到 service 數量按 20 次連線線性增加。仍有最後一個 service／preroll 保留，不宣稱完全清零；也沒有涵蓋 native inference 進行中的突然 abort 或數小時 soak。

獨立元件試驗只 import 真實 UserSession／TurnState／DebugLogBuffer：12 秒 PCM 的 ASR segment 為 384,000 bytes，TurnSense tail 被 8 秒 cap 限制為 256,000 bytes；log 的同樣 4 筆可由 4 bytes 變成 400,000 bytes，證明條數上限不等於 byte 上限。tracemalloc live 1,906,745 bytes，釋放元件後剩 1,886 bytes。這證明這個受控生命週期的物件可釋放，不能當成 live service 沒有 leak 的證據。

真實服務的 Memray native capture 涵蓋四席 3／15／30 秒各一回合（12 席位），模型 preload 後開始，共 83,972,013 次 allocation、累積 34.06 GiB；tracked allocation peak（含 MMAP） 1302.9 MiB。累積配置量包含釋放後重複使用，不是 RSS 或同時存活量；tracked peak 也不包含開始 capture 前已配置的模型。decode_stream 所在 Python call path 占累積 bytes 的 82.7%，其下包含 Sherpa／ORT 原生配置，不能全部歸因為 Python object。

MsgPack／WebSocket deflate 也是已觀測到的配置來源。減少 frame 序列化次數、重用 packer／buffer、評估 PCM 傳輸壓縮策略是可繼續驗證的方向；本輪沒有給這些改法的速度收益，網路頻寬與跨程序 frame 契約也要一起驗證。

真實服務 allocation flamegraph（可互動、離線） · 完整 allocation 統計。capture 的 30s final 中位數為 2,876.45 ms，工具成本很大，不能用作 clean latency。

首次 capture 啟動失敗：實驗掛載覆蓋 PYTHONPATH，誤導入已安裝的 Sherpa 1.12.36，其 max_active_paths 介面與 vendored 1.13.0+cuda 不同。修正為保留 image 搜尋路徑後重跑成功；失敗 log 保留但不計入 benchmark。

Greedy 的配置次數降低 86.0%，累積 bytes 降低 49.8%；但 tracked peak 與 GPU residency 沒有同步下降。每組只有一次 allocation capture，allocator reservation／工作排程會影響 high-water，不能推論 greedy 必然更省常駐記憶體。兩次 capture 各有 12 次 final，但實際 interim 數為 beam 8 的 221 次、greedy 的 379 次；profiler 開銷改變了自適應排程。因此以上是相同音訊矩陣的完整 capture 比較，不是固定 decode call 數的成本比，也不能把 86% 當作未掛 profiler 的 allocation 改善率。peak records 顯示 beam 8 當時有 1 個、greedy 有 2 個 1 GiB 的 MMAP；其 stack 都在 native decode 下。這是映射配置量，並非已駐留的實體 pages，應以 RSS／PSS／USS 分開核對。baseline 與 greedy 的 MsgPack 配置仍都約 2.7 GiB，顯示這個傳輸成本沒有隨 decoder 一起消失。

Greedy allocation flamegraph · Greedy allocation 統計 · beam 8 peak stacks · greedy peak stacks

詳見 memory.md、元件 allocation flamegraph。Memray 觀測 host allocation；GPU 記憶體仍由 NVML 補足，兩者不是同一個記憶體集合。

長語音、CPU quota 與 batching

4 CPU quota 的 nr_throttled 在 workload 前後為 28→28，throttled_usec 為 50499140→50499140。啟動階段有 quota throttle，這份四席 steady workload 沒有增加 throttle。server CPU 為 74.73s，無 quota 的重複對照為 75.26s；因此不能說 steady latency 受 4 CPU quota 飽和支配。這不涵蓋更高並發、其他硬體或 cold-start SLO。

真正呼叫同一 native recognizer 的 decode_streams(4)，每個 shape 各自 warmup，serial 與 batch 交替順序。所有 15 對的四席文字逐次相等且非空；原生輸出為簡體，尚未經完整服務文字處理。這證明同長輸入的原生 group throughput 有收益，但長音訊僅約 5%；第一席必須等整組完成。沒有把 batch 接進 WebSocket scheduler，也沒有不同長度 padding、batch formation wait 或即時排程結果，所以不把這個百分比當成端到端 final 改善。prepare 時間另外保存，沒有混入表中 decode。

原生 batch 全部 pairs／設定／文字 · host PID memory samples

目前 main 已有 incremental feature feed 與 final stream handover。降低重算頻率是現有路徑上的策略調整，不應把已存在的 incremental feeding 列成新功能。長語音仍反覆執行整個成長中 segment 的 offline decode；更進一步的 streaming backend、切段或增量模型狀態需要重新驗證轉錄與 turn 行為。

EOT 完成時間與辨識時間

這份固定音訊在 3／30 秒組的 commit 多由 reason=timeout 觸發，decision 的 wait_ms=2000；15 秒組由 model 直接 commit。final 到 EOT 的差距約 2 秒，遠大於 TurnSense native ONNX 的幾十毫秒。因此應把 policy 等待與模型速度分開優化；改短 wait 可能增加過早截斷，需完整語意 turn 的標註資料，這次不能證明應改成多少。

已排除與仍未證實

如何讓 AI 檢查，而不只看一張 flamegraph

1. 以 Perfetto Python API 載入 trace，執行 analysis.sql。本次實際使用 trace_processor v57.2；結果保存於 analysis.json，並與 raw JSON count／sum assert 一致。官方也提供 AI trace analysis 工作流程。
2. py-spy 保存真實 Python + native sampling 的 Speedscope JSON。AI 可先聚合 thread／file／stack，再回到 frame timeline 確認因果，避免把寬的等待堆疊當成純 CPU 工作。
3. Memray 補 host allocation stacks；native mode 的符號可見度取決於 debug information。搭配 PSS／USS／NVML 曲線與 disconnect tail，才能區分暫態 peak、allocator residency 與持續保留。

重播與檢查

• 完成 20 組重播、624 筆席位結果（含 58 筆 warmup、instrumented trials 與 1 筆 smoke）；全部符合 delivery／pacing 檢查。這些不是 624 次獨立試驗，也不是 EOT 品質全部通過。
• 中文連讀喚醒、英文喚醒與 active wake filtering：4 種設定 × 3 fixtures × 5 repeats，60／60 筆精確通過；每筆轉錄／TTS／errors 已保存。
• 8 個相關離線 test files：100 passed in 4.35s，涵蓋 trace、interim contention/collector、EOT state/precedence、TurnSense frontend/policy/runtime 與 hotword wiring；JUnit、log。這是 focused suite，不是全套 pytest。
• 6 個 probe self-check 通過；原生 batch 的 15 pairs 全部有文字且 serial／batch 相等；正式 compact microbenchmark 保存完整 JSON equality assertions。
• 6 份正式 production trace 經官方 Perfetto SQL 核對 ASR count／sum，與 raw JSON 一致；另外保留早期 baseline SQL snapshot。整合檔也已確認 40 筆 final、40 筆 EOT 與四條 memory counters 能被 Perfetto 查詢。
• 初次 sandbox pytest 無輸出且未完成，已中止並保留紀錄；上述通過數來自同 worktree 在 host 加診斷輸出的重跑。原因未進一步確診，不能把中止的那次算成通過。
• 產出的 HTML 使用內嵌 SVG 與離線 Memray assets；Chrome 實際檢查桌面／手機、6 張內嵌 SVG 與兩份 live Memray 互動頁；無 page error、外部請求、缺失本機連結或整頁水平溢出。原始 Speedscope、Perfetto、memory JSONL、configuration 與 hashes 保存在相鄰 evidence。

從同一 worktree 使用本地 .venv、相同 immutable image 與本報告的 clip hashes。clip 是 ignored fixtures，新 checkout 可用以下 stdlib 重建：

from pathlib import Path
import wave
source = Path("tests/functional/audios/say-open-door.wav")
with wave.open(str(source), "rb") as wav:
    assert (wav.getnchannels(), wav.getsampwidth(), wav.getframerate()) == (1, 2, 16000)
    pcm = wav.readframes(wav.getnframes())
out = Path("tests/batch_decode/audio")
out.mkdir(exist_ok=True)
for seconds in (1, 3, 6, 15, 30, 60):
    size = seconds * 16000 * 2
    with wave.open(str(out / f"clip-{seconds}s.wav"), "wb") as wav:
        wav.setparams((1, 2, 16000, 0, "NONE", "not compressed"))
        wav.writeframes((pcm * ((size + len(pcm) - 1) // len(pcm)))[:size])

執行量測與檢查：

.venv/bin/python utils/performance/workload.py --self-check
.venv/bin/python utils/performance/profile_server.py --self-check
python3 utils/performance/memory_probe.py --self-check
python3 utils/performance/tracer_probe.py self-check
.venv/bin/python utils/performance/batch_probe.py --self-check

.venv/bin/python utils/performance/run_case.py \
  --case interim-1s --label your-unique-label \
  --image sha256:f51393696ba3b913c73bd6db38ec79fb75393d165eac54827f474a2423d1fece \
  --out /tmp/your-new-evidence-directory

# 在包含官方 perfetto Python package 的 tools environment 中：
python utils/performance/analyze.py --sql \
  --evidence /tmp/kitt-stt-performance-20260912 \
  --out /tmp/kitt-stt-performance-20260912/analysis.json

run_case.py 建立新容器、驗證 health 與 TurnSense CUDA、啟動 host PID sampler、執行真實重播、保存 log／config／trace／結果後清理自身容器。run.json 保存每組命令、image、source；後續組另保存 experiment script／audio hashes。早期探索組的來源 hashes 由 環境與音訊 manifest 補足。artifact 的最終 hashes 見 manifest.json。大型 Memray .bin 已保存在 worktree 的 evidence 目錄並加入本報告的 .gitignore；可互動 HTML 與小型 raw 結果可直接 review。

獨立 tools environment 使用 py-spy、Perfetto、Memray、matplotlib；沒有把 profiler 加入 production dependency。完整 source 路徑與 caller 關係見 flow.md。

範圍與證據限制

這是一台有其他服務的工作站，沒有固定 CPU／GPU 時脈或宣稱獨占 host。GPU 模型試驗按順序執行，profiled 組與 clean latency 組分列；不能把 instrumentation 的延遲拿來當 production benchmark。記憶體 sampler、trace retention／flush、測量時間窗與冷／暖狀態都有列出。原生 sampling 有少量 sample errors，完整計數保留；不是每一條 native symbol 都可解析。

三個方向的 Luna max 子代理分別負責 flow instrumentation、tracer 證明與 memory probe／元件控制。主控重跑與核對 raw data，修正了假設錯誤、跨檔案系統保存、memory shutdown floor、EOT carrier 與單變因比較等問題；子代理提供的來源推測不會直接升格成結果。

公開版範圍：本頁保留完整分析、圖表與結論；raw workload、trace、log、profile 與 allocation binaries 只保留在受控的本機 worktree，未公開上傳。