機器人推斷延遲是指從物理觀測變得可用到相應命令生效的時間。神經網路執行時間僅是一個區間。曝光、感測器緩衝、傳輸、解碼、預處理、佇列、後處理、中介軟體、控制器排程和致動器應用同樣重要。
一個有用的預算是跟蹤一個影格或狀態樣本並同步時間戳。它區分處理時長與資料年齡，報告在定義工作負載下觀察到的中位數、高百分位數和最大值。吞吐量和每秒影格數不回答機器人執行命令時，該命令生成至今已過去多久。
將本指南與 ROS 2 即時控制指南 和 機器人 VLA 評估指南一起使用。即使感知或策略路徑延遲變化，也要保持有界的下層控制環路。
定義物理起始和停止時間戳
選擇在相機曝光、光達採集或機器人狀態取樣時起始，而非應用回呼執行時。選擇在接受或應用命令的控制器或驅動器事件處停止。軟體錄入和返回時間省略傳輸和硬體延遲。
使用共享時鐘或刻畫時鐘偏移和漂移。如果有硬體時間戳，優先使用。保留從輸入到輸出的序列辨識符號，以便證明每個動作是哪影格產生的。如果沒有身份，快速回呼可能只是處理舊的緩衝影格。
推論開始前，感測器採集已經產生資料時延
滾動快門、曝光時間、影格讀取和感測器端影像處理會增加延遲。以每秒 30 影格執行的相機可以呈現代表不同行時間的影格，並且在主機轉移前已經在捕捉中花費了一小部分時間。
檔案觸發模式、曝光、緩衝區深度、丟棄策略和時間戳起源。僅保留最新影格的消費策略可以透過丟棄影格來保持低年齡，而佇列消費者則保留每一影格，但在過載時會在過載時逐漸變得陳舊。這兩種策略都不是普遍正確的；控制後果決定了這一點。
| 階段 | 啟動事件 | 事件結束 | 隱藏延遲 |
|---|---|---|---|
| 被捕 | 物理暴露 | 感測器框架準備就緒 | 讀出與 ISP |
| 轉會 | DMA 或分組傳送 | 可用的主機緩衝區 | 複製和匯流排佇列 |
| 預處理 | 已選定框架 | 輸入張量準備 | 解碼與調整大小 |
| 推斷 | 請求佇列 | 輸出同步 | 主機與裝置工作 |
| 應用 | 輸出解碼 | 驅動器接受指令 | 中介軟體與控制階段 |
副本和佇列數量可能超過模型計算
影像解碼、顏色轉換、調整大小、正規化、主機到裝置複製和張量佈局變化都可能建立緩衝區。零複製設計可以減少傳輸次數，但增加壽命和對齊約束。分析實際記憶體移動，而不是假設框架消除了它。
儀器佇列與服務時間分開等待。 CPU 執行緒爭用、回呼致動器、 GPU 流和非同步驅動程式可以隱藏可見函式之間的等待。限制佇列深度，定義到達的輸入是替換、跳過還是等待。
模型延遲需要顯式同步
GPU 啟動 API 通常是非同步的。僅測量主機呼叫可以記錄佇列時間，而非完成推斷。使用適當的裝置事件或在輸出邊界同步，同時保留圍繞完整應用路徑的實際時間測量。
目前 TensorRT 效能基準測試檔案 將吞吐量、主機延遲、傳輸、 GPU 計算和佇列時間區分開來。其僅推斷指標有助於隔離，但除非應用測量機器人感測器和控制器階段，否則不包括它們。
吞吐量和延遲迴答了不同的問題
吞吐量是單位時間內完成的推斷次數。延遲是單個請求的經過時間。批處理或併發流可能提升彙總吞吐量，同時增加單個機器人影格的等待時間或爭用。在同一排程設定下報告兩者。
如果生產超過消耗且佇列增長，流水線還可以具有高吞吐量和無界年齡。在命令應用時繪製影格年齡與推論計數。在控制方面，較低速率的最新觀測通常比按順序交付的每一個陳舊觀測更有用。
| 度規 | 答案是什麼 | 統計量 | 機器人風險 |
|---|---|---|---|
| 模型計算 | 裝置核心執行多長時間 | 中線和尾部 | 錯過保單期 |
| 端對端延遲 | 一次觀察需要多長時間 | P50， P95， P99，最高限度 | 晚期反應 |
| 資料時代 | 證據使用的年代有多久 | 分佈 | 陳舊指揮 |
| 吞吐量 | 完成了多少請求 | 每秒 | 佇列增長 |
| 抖動 | 時間變化 | 範圍與百分位 | 控制不均 |
尾延遲決定了罕見的物理故障
平均延遲會隱藏排程器暫停、首次使用編譯、快取未命中、熱限流、動態圖形和網路重試。單獨記錄預熱，然後執行足夠長以觀察罕見的爭用。報告 P95 和 P99 時，樣本計數足以解釋這些百分位數。
跟蹤最差觀測值時，除非系統和分析支援該說法，否則不應稱其為已被證明的上界。將離群值與功率、溫度、時鐘、 CPU 負載、記憶體壓力、網路和設定檔變化關聯起來。少數延遲命令可以主導碰撞或抓取失效。
板上、邊緣和雲路徑的預算不同
板載推斷避免了廣域網路的差異，但與機器人共享功率和熱量限制。邊緣伺服器增加了無線、交換和排隊功能，同時提供更多計算能力。雲路徑增加了路由和服務爭用，並且需要明確的斷線或反應延遲行為。
測量真實部署區域及漫遊或干擾下的往返分佈。不要傳送基於已超過年齡限制影格的指令。在機器人中使用順序和截止時間檢查，確保延遲但經過有效認證的反應無法改變目前狀態。
最佳化在準確性、負載和排程之間做出權衡
精度降低、量化、剪枝、降低解析度和跳影格會減少計算，但這些都會改變模型輸出。在目標硬體最佳化後驗證任務準確性和失敗模式。更快的引擎但校正偏移或不支援運算子，則不是等價的策略。
目前 TensorRT 最佳實踐指南 建議控制時鐘、功率、熱狀態、傳輸和軟體設定以實現可復現的數值。將已構建的發動機釘在其硬體和驅動環境上，而不是將廠商基準與其他機器人進行比較。
策略費率和伺服費率應當解耦
視覺策略或 VLA 策略可能以數十赫茲的速度更新，而關節控制每秒執行數百甚至數千次。底層可以插值有界引用、監控跟蹤並拒絕陳舊命令。它不應在硬時序路徑內等待神經推斷。
將視界與 機器人動作分割槽指南進行協調。紀錄預測時間、執行字首和命令年齡。如果推論錯過截止日期，選擇測試過的備選方式，如暫停、減速或切換到更安全狀態，而不是重放任意的舊動作。
在現實壓力下驗證時機
將代表性的攝影機、紀錄記錄、網路、地圖和使用者介面工作負載協同執行。調整溫度、功率模式、動態形狀、物件數量和後台流量。在測量機器人反應的同時，注入丟影格、延遲資料包和推論超載。
保持版本管理延遲預算，為每個階段設定目標和測量分佈。模型、預處理、中介軟體、驅動、韌體或計算變更後重新檢查。階段最佳化應僅在感測器到致動器路徑和任務結果全面改善時被接受。
評估“機器人推論延遲：從相機曝光到致動器指令”時，還應儲存模型版本、機器人設定、校正檔案、測試日期和全部試驗記錄。
只有把這些持續投入與單位成功任務的價值比較，才能判斷方案是否適合擴大。
上線後仍要持續檢查分佈變化、感測器漂移、機械磨損和人工接管原因。
實際專案還應指定資料、模型、控制器和安全流程的負責人，並預先定義回復條件。責任邊界、審批記錄與變更紀錄越清楚，故障發生後越容易停止擴散、定位原因並安全恢復。
- 時間戳、物理捕獲和命令應用。
- 在每個階段都保持序列身份。
- 分開佇列等待，主機工作和裝置工作。
- 報告延遲尾部、吞吐量和資料老化情況。
- 測試過載、發熱、網路丟失和備用行為。
常見問題
如果模型執行 10 毫秒，機器人會在 10 毫秒內反應嗎？
不。捕獲、傳輸、預處理、佇列、後處理、通訊、控制器排程和致動器反應均不在模型計算範圍內。
FPS 和延遲是同一個指標嗎？
不。影格數是吞吐量。管道每秒可以完成很多影格，而單個影格在佇列中等待並遲到機器人。
為什麼平均延遲不夠？
罕見的停滯可能導致最重要的物理故障。報告百分位數、最大觀測值、樣本計數及異常值相關條件。
舊影格可以直接丟棄嗎？
通常僅限最新策略會降低年齡，但丟棄會改變時間取樣和模型行為。用任務和控制器驗證丟棄規則。
雲推斷可以用在機器人上嗎？
它可以支援那些截止日期和備用條件允許網路變異的任務。測量真實路徑，並拒絕超出機器人指令年齡限制的反應。
推斷時序證據邊界
延遲資料適用於定義的感測器、模型、硬體、軟體、負載和測量邊界。僅憑推斷基準測試並不能證明機器人反應時間有限制。