傳送請求與收到第一個回應之間的延遲。在 AI 領域，這通常以「首次 Token 產生時間」（Time to First Token，TTFT）— 模型開始串流回答之前需要多長時間來衡量。受模型大小、伺服器負載、網絡距離和提示長度影響。
AI 系統中的延遲可分解為幾個不同的組成部分，了解每個部分有助於診斷實際上是什麼導致了延遲。首先是網路延遲—您的請求到達服務提供商的伺服器，以及回應的第一個位元組返回所需的往返時間。這通常根據您與資料中心的地理距離而定，約為 20-100 毫秒。接下來是排隊時間—您的請求在 GPU 可用來處理它之前需要等待的時間。在高峰時間或熱門模型上，這可能從零到數秒不等。然後是預填充時間—模型處理您整個輸入提示的時間。對於一個 1,000 token 的提示，在大型模型上這可能需要 200-500 毫秒。最後，解碼開始，您會收到第一個 token。所有這些階段的總和就是您的 TTFT（First Token Time）。
在第一個 token 到達後，還有另一個同樣重要的延遲指標：token 間延遲，或後續 token 流入的速度。這通常以每秒 tokens 數來衡量。GPT-4o 可能以 80-100 tokens/秒的速度流傳，而 Claude 在大多數請求中以類似的速度流傳。對於聊天機器人而言，任何超過約 30 tokens/秒的流速對人類讀者來說都感覺「即時」—比您閱讀的速度還要快。低於 15 tokens/秒時，流傳開始感覺斷斷續續。這就是為什麼提供商有時會同時引用 TTFT 和 tokens/秒—他們是在衡量不同的用戶體驗瓶頸。一個回應可能開始得很快但流速慢，或稍慢開始但之後飛快。
提示長度對延遲的影響比大多數開發人員預期的還要大。對於標準的 Transformer 模型，預填充階段的時間大致與輸入長度呈平方關係（感謝自注意力機制），因此一個 10,000 token 的提示不僅需要比 1,000 token 的提示長 10 倍的時間—實際上可能需要顯著更長的時間。這就是為什麼像 Anthropic 這樣的提供商會對輸入和輸出 tokens 收取不同的費用，以及為什麼將整個程式碼庫塞入上下文視窗會對性能產生實際影響。技術如提示緩存在此處幫助巨大：Anthropic 的提示緩存功能讓您可以標記提示的一部分為可緩存，因此如果您每次請求都傳送相同的系統提示（這在大多數應用程式中都是如此），那麼這部分的預填充在第一次呼叫後基本上是免費的。
開發人員在處理延遲時最常見的錯誤是在開發階段使用短提示進行測試，然後對生產環境的性能感到驚訝。一個 50 token 的測試提示在 300 毫秒內回應；而真實的生產提示包含系統訊息、少數示例和對話歷史總共 4,000 token，則需要 2 秒。另一個陷阱是地理路由—如果您的伺服器在歐洲，但您呼叫的是美國的 API 端點，那麼您會在每次請求中增加 100-150 毫秒的網路延遲。一些提供商提供區域端點，而更智能的推論代理服務會自動將您的流量路由到最近的資料中心。對於像語音助手這樣的即時應用程式，總體端到端延遲必須保持在 500 毫秒以下，因此每一個這些組成部分都至關重要，您最終會同時優化所有這些部分。