回應串流已成為AI應用程式的預設UX模式，效仿ChatGPT在生成過程中顯示部分回應而非等待完整輸出。該技術分為兩種主要實作：用於簡單單向串流的Server-Sent Events，以及用於複雜工作流程（如多代理系統或程式碼助手）中雙向通訊所需的WebSockets。雖然串流改善了感知回應性，但實際上並不會讓模型推論更快。

對串流的迷戀暴露了對AI應用程式效能的根本誤解。開發者專注於最後一哩——使用者看到文字出現的速度——卻忽略了真正的瓶頸。模型選擇、prompt最佳化和智慧快取才能帶來實際的延遲改善。串流只是用更好的UX掩蓋了慢回應，這很重要但不應該是你的首要最佳化。我們見過太多團隊實作複雜的串流設定，而他們的應用程式產生一個簡單回應仍需8秒。

大多數關於串流討論中缺失的是它增加的基礎設施複雜性。SSE需要維護持續連接、處理網路中斷並管理跨部分回應的狀態。WebSockets更加複雜，需要雙向訊息處理和連接生命週期管理。對大多數AI應用程式來說，這種額外的複雜性並不合理——特別是當適當的prompt快取和模型路由能以更少的工程負擔帶來更好的效能提升時。

對建構AI應用程式的開發者建議：在最佳化實際模型效能之後再實作串流，而不是之前。從回應快取開始，為簡單任務嘗試更快的模型，並最佳化你的prompt。串流應該是你的潤飾，而不是效能策略。使用者更能注意到2秒和8秒回應之間的差異，而不是在已經很快的回應上的串流效果。