單一次模型呼叫可以很快，但 production 的 AI 工作流會把呼叫一層層疊起來，直到延遲變得無法忍受。n8n 在 2026 年 9 月 19 日發布的這篇指南，開頭就點出一個常被誤判的地方：延遲不是靠多寫幾行 code 就能解決，而是要先知道它來自哪一層。
延遲不是一個數字，而是三層疊加
n8n 把 agentic 系統的總延遲拆成三層：模型推論、工具與 API 呼叫、以及編排開銷。這個切法的價值在於，每一層的修法完全不同。
換模型對一個把四秒花在三次循序 API 呼叫的工作流毫無幫助；反過來說，把 API 呼叫平行化，也救不了一個卡在 worker node 分散於不同 availability zone 的瓶頸。n8n 的說法是：先找出延遲實際發生在哪裡，再對症下藥。
推論本身又分兩段。Prefill 一次處理完整輸入並產生第一個 token，通常在 GPU 上平行執行、速度較快；decoding 則是一個一個 token 依序產生，是較長的那一段。對互動式工作流來說，n8n 建議追蹤 Time to First Token（TTFT），並指出低於 200 到 500 毫秒算低；若非推理型 LLM 的 TTFT 達到一秒以上，可能代表伺服器流量沉重或記憶體過載。這裡有個容易忽略的前提：TTFT 只適用於使用者能即時看到輸出的互動流程，不串流、只顯示最終結果的自動化並不適用。
工具呼叫與編排開銷：加總起來才是使用者看到的秒數
工具呼叫往往要花好幾秒，因為每個檢索步驟與 API 查詢都包含網路往返時間加上目標系統的處理時間。n8n 給的例子很具體：三次各 800 毫秒的呼叫若循序執行，合計 2.4 秒；平行化之後約 800 毫秒，還不含編排開銷。多數近期 LLM 支援平行工具呼叫，若工作流中的呼叫彼此獨立，可以透過 prompt 請模型使用這個能力。
編排開銷則因為每次延遲較短而容易被忽略。步驟之間 100 毫秒看起來無害，但乘上檢索、推論與後處理之後，使用者看到的就是好幾秒。
在動手優化之前，n8n 提醒先確認延遲真的是問題。如果使用者其實需要更好的準確度或檢索品質，花幾週調回應時間就是白費。若工作流建在 n8n 上，可以檢視 executions 找出一次執行把時間花在哪裡。n8n 建議觀察的指標包括 Time to Complete Response（TTCR）、TTFT、Output Tokens per Second（OTPS），以及工作流類型；它給的範例預算是即時工作流 500 毫秒以下、批次 5 到 20 秒、背景 30 秒以上。
工作流層級：平行、逾時、子流程與併發
n8n 主張，當編排層是自己寫的，就得永遠自己維護 scheduler 與 execution store；在平台內則可以直接配置這些模式。
平行工具呼叫是最直接的一招。當 agent 需要兩個獨立查詢，模型可以在同一輪同時發出，相依的計算步驟再等結果。n8n 指出省下的不只是工具執行時間的疊加，還包括 LLM 呼叫次數，因為兩個工具都完成後只呼叫模型一次。
逾時與重試上限處理的是另一種昂貴延遲：卡住的 API 呼叫。n8n 的 HTTP Request node 支援逾時，讓慢端點在指定時間失敗並走預先設計的 fallback，而不是讓整個工作流無限等待。重試能提升可靠度，但同時增加延遲：一個正常一秒的呼叫，若跑三次、每次逾時三秒，失敗時消耗的預算遠超過單次請求。n8n 也提供 node 層級與工作流層級的重試與逾時設定，以及 Guardrails node 攔截會讓 agent 走上長而無用路徑的壞輸入。
有些步驟慢得無法修，例如供應商 API 要八秒。n8n 的建議不是換 node，而是把這個慢步驟拆進 sub-workflow，給它自己的逾時、重試與併發設定，並決定父工作流是否等待它完成。
最後是併發。40 個執行同時進來、全部一起跑，會讓吞吐量問題看起來像延遲問題。n8n Cloud 依方案限制併發執行數；自架則可控制併發上限，或啟用 queue mode，由主實例處理 trigger 與 webhook，再透過 Redis 把執行分派給 worker pool。
模型層級：選對大小、砍輸出、用快取
推論延遲主要由兩個變數決定：模型決定每個 token 多快出來，答案長度決定要等多少個 token。分類與短擷取適合小模型；把大型 dense 70B 換成較小的 Mixture of Experts 模型，n8n 說每次查詢可省下數百毫秒，而需要多步推理的自動化再留給大模型。
輸出 token 通常比輸入更容易控制，因為 decoding 是循序的。n8n 引用 OpenAI 的延遲優化指引，指出輸出與延遲的關係接近線性：砍掉 50% 輸出 token，約可砍掉 50% 延遲。做法包括設定最大輸出長度、要求結構化輸出並使用短欄位名、以及限制回答字數。
至於 prompt caching 與 semantic caching，n8n 指出 prompt caching 一般由模型供應商控制：當請求重複共用可快取的 prefix，供應商就能避免重算。
這套三層拆法對產品團隊的實際意義是：延遲預算要分配到具體步驟，而不是當成一個整體目標。若你的工作流瓶頸其實在工具呼叫的停損設計，可以對照我們先前整理的工具呼叫迴圈的四個停損點；逾時、重試上限與 fallback 的取捨，本質上是同一類工程決策。先量測，再決定要平行化、縮短輸出，還是換模型——順序反了，通常只是把預算花在錯的層。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。