01、概述

字節跳動 Prompt 平臺旨在為用戶提供全面的 Prompt 開發、調優、評測及應用等全生命周期功能。在這些功能中，打字機效果的流式輸出大模型結果是一項至關重要的特性。基于 SSE(Server-Sent Events) 實現雖然可行，但需要額外編寫 HTTP 服務，這增加了開發的復雜性。而輪詢方式雖然簡單，但用戶體驗并不理想，顯得過于笨拙。至于 gRPC，雖然性能出色，但可能引入兼容性問題，使得部署和維護變得復雜。因此，我們借助 Kitex 的 Thrift streaming 能力，成功實現了流式接口的落地，從而為用戶提供了流暢、高效的打字機效果大模型結果輸出體驗。

02、業務背景

隨著 AI 技術的不斷發展，人們的生活正在發生深刻的變化。以字節旗下的 AI 產品豆包為例，其中的智能體給人們帶來了許多新奇的體驗。其中，AI 男友、AI 女友等趣味智能機器人尤其受歡迎，它們不僅能夠以風趣幽默的方式與用戶互動，還能展現出溫柔體貼的一面。

這一切都離不開一個與大模型緊密相連的概念——提示詞（Prompt）。簡單來說，Prompt 就是向預訓練模型輸入的文本，用以引導模型生成符合特定需求的文本輸出。形象地講，Prompt 就像是為大模型打造一個專屬的夢境，通過它，我們能夠引導大模型在特定場景下給出更貼切、更有針對性的回答。

以 AI 女友為例，我們會通過精心設計的 Prompt 來告訴大模型，它的角色是一個溫柔體貼的虛擬女友。同時，我們還會設定一些限制條件，比如要求它以溫柔體貼的方式與用戶交流，并具備傾聽、理解、鼓勵和建議等技能。此外，我們還會詳細描述它的工作流程，比如在問候時引導用戶說出自己的名字，為用戶起一個合適的昵稱，然后與用戶進行深入的溝通交流，并提供有益的建議。

通過這樣的 Prompt，我們為大模型構建了一個完整的“夢境”，讓它明白自己是一個 AI 女友，并清楚自己應該如何與用戶互動。當這個 Prompt 被激活后，我們與大模型進行問答時，它就會根據我們的提示給出相應的回復。比如，當我們向它問好時，它會引導我們說出自己的名字，并為我們取一個可愛的昵稱，然后給予我們鼓勵和寬慰。

從這個例子中可以看出，Prompt 在特定場景下對大模型的輸出起著決定性的作用。更進一步地說，它還會影響到大模型在輸出過程中 token 的消耗以及響應時間的快慢。因此，一個優秀的 Prompt 對于提升模型輸出效果至關重要。

03、需求場景

字節跳動 Flow 團隊正致力于構建一個全面而成熟的平臺/方法，旨在幫助 Prompt 開發者設計、迭代、評測及優化其 Prompt，從而增強 LLM（大型語言模型）的表現力。在開發階段，我們計劃提供結構化生成和引導式生成的方式，以輔助用戶編寫出高效且精準的 Prompt，并進行相應的調試運行。

隨著開發的深入，我們將進一步引入 COT(Chain of Thought)、Few shots 等自動調優技術，以及 APO(Auto Prompt Optimization) 方法，幫助 Prompt 提高回答的正確率。同時，我們還將提供 Prompt 擴縮寫的能力，以優化大模型在 token 消耗方面的效率。

此外，為了全面評估 Prompt 的效果，我們將結合多樣化的數據集對 Prompt 進行打分，并深入分析其性能瓶頸，以便進行針對性的改進。最終，我們將提供一鍵部署的功能，使開發者能夠輕松地將 Prompt 能力及其背后的大模型集成到他們的應用中。

當然，這些功能的實現都離不開對實時流式傳輸技術的支持。就像你體驗過的 GPT、豆包、百度 AI 搜索等 AI 能力一樣，它們在用戶提問后，都采用了打字機形式的回復方式，讓用戶感受到數據在不斷流入屏幕，從而提高了聊天的流暢性和響應速度。這種實時流式傳輸技術正是我們 Prompt 平臺需要提供的最基礎能力。通過將數據分成多個數據流進行網絡傳輸，我們可以有效減少網絡延遲，提高性能，確保用戶在與大型語言模型交互時獲得更好的體驗。

04、解決方案

為了實現流式輸出功能，我們進行了深入的調研，綜合考慮了多種方案：

• 輪詢
• HTTP SSE
• Kitex gRPC Streaming(protobuf)
• Kitex Thrift Streaming

首先，輪詢方案由于其呆板性，不符合我們的需求，因此被排除在外。其次，雖然基于 HTTP 的 SSE 是一種可行的方案，但考慮到我們對 RPC（遠程過程調用）同樣有嚴格的要求，因此也需要尋找更為合適的方案。另外，我們發現 Protobuf 協議的流式處理支持并不能完全滿足我們的需求，尤其是在 Thrift 接口方面。最后，我們注意到了 Kitex 對于 Thrift Streaming 的支持。當時，Kitex Thrift Streaming 正處于開發階段，我們果斷決定成為其首批用戶，并以此為基礎構建整個 Prompt 平臺的基本框架。

在架構設計上，我們首先對標 LangChain，建立 LLM 工程化服務。在此基礎上，我們進一步構建 Prompt 服務，以提供最基本的 Prompt 管理及應用能力。為了與前端進行交互，我們通過 API Gateway 提供 HTTP 接口。而在微服務之間的通信方面，我們采用了 Kitex 框架，以提供流式接口和非流式接口的支持，確保數據的高效傳輸和處理。

通過這一解決方案，我們成功實現了流式輸出功能，為用戶提供了更加流暢、高效的 AI 交互體驗。同時，我們也為未來的擴展和優化打下了堅實的基礎。

05、實踐與踩坑

流式調用的流程

流式調用的流程起始于用戶發起提問。這一請求首先被發送至網關，網關隨后與下游的 Prompt RPC 接口建立連接。Prompt RPC 接口進一步與 LLM 工程化服務建立通信，該服務負責持續與模型交互，并獲取模型的輸出結果。這些結果通過流式的方式逐層向上傳遞，直至到達網關層，并最終實現流式上屏展示給用戶。

在此過程中，我們在 Prompt 服務中編寫了一個流式接口，用于處理流式調用。該接口首先通過調用下游接口建立與下游的連接，然后通過一個 for 循環不斷地去接收下游吐給我們的這個流式的包的結果。一旦接收到數據包，我們通過 send 方法將其向上層透傳，直至遇到錯誤或流關閉為止，循環隨之結束。

在實現過程中，我們體驗到了 Kitex Thrift Streaming 的簡潔性。然而，我們也遇到了一些問題。尤其是在錯誤處理方面，我們發現代碼運行時無法獲取預期結果，甚至導致 CPU 負載過高。

進一步分析錯誤日志后，我們發現在單個請求中存在錯誤信息，特別是關于首包的 QPM（查詢每秒）超限問題。按照我們的代碼邏輯，遇到這類錯誤應該快速退出 for 循環，但實際情況并非如此。于是，我們開始利用 Kitex 提供的排查手段進行問題定位。Kitex 提供了 RPCStart 和 RPCEnd 的埋點，以及更細粒度的包接收和發送事件埋點。通過對這些埋點的分析，我們發現 Kitex 將整個請求識別為正常響應，并且在調用鏈路上有大量的數據包在發送。進一步查看單個包的打點信息，也顯示被 Kitex 識別為正常響應。

經過初步判斷，我們認為 Kitex 的流式處理中可能忽略了業務錯誤，導致錯誤未被正確識別。與 Kitex 團隊溝通后，他們進行了相應的調整，例如在代碼中增加了對 biz status error（業務狀態錯誤）的識別。

基于這次錯誤處理的經驗，我們進一步分析了流式調用中可能遇到的其他異常場景，如建聯階段的權限報錯、首包階段的 TPM/QPM 超限、中間包階段的流超時以及內容審核錯誤等。我們重點關注了 Kitex Thrift Streaming 在這些場景下的錯誤處理表現，如建聯時是否能快速返回錯誤信息，以及在首包和中間包返回錯誤時是否能迅速停止流等待。經過與 Kitex 團隊的共同調整和測試，最終這些場景下的錯誤處理均符合預期。

在服務治理方面

在服務治理方面，我們特別關注超時和限流兩個關鍵環節。

首先，超時管理至關重要。由于我們的模塊與大模型進行交互，這種交互可能涉及秒級甚至分鐘級的響應時間。因此，在 HTTP 層和 RPC 層，我們都對流處理設置了分鐘級的超時限制。這樣做可以避免因無法退出 for 循環而導致的服務阻塞，確保服務的穩定性和可用性。

在限流方面，雖然 Kitex 支持在創建流時進行限流，但對于 LLM 場景來說，我們的關注點不僅在于建立連接時的 QPM 限流，更在于大模型 token 消耗的限流。大模型的推理過程中會產生大量的 token 消耗，如果不加以限制，可能會導致資源耗盡和服務崩潰。因此，我們利用 Kitex 實現了建聯的限流，同時借助自己的分布式組件來計算不同模型下的 token 消耗，并據此實現 token 級別的限流。這樣做可以有效地控制資源使用，避免服務過載。

然而，我們也對 Kitex 抱有期待。我們希望未來 Kitex 能夠提供包粒度上的自定義限流能力。這樣，我們可以更靈活地定義限流規則，更精確地控制資源使用，從而進一步提升服務的穩定性和性能。

06、未來的期待

便捷性

首先，在便捷性方面，我們期待微服務框架能夠支持更多的測試工具接入，尤其是針對流式接口的測試。目前，對于 Kitex Thrift streaming 接口的測試還存在一定的局限性，主要依賴于編寫非流式接口進行包裝調用。未來，我們希望能夠通過泛化調用等方式，使得流式接口能夠更方便地支持各種測試工具，提高開發效率。

AI 場景下的能力

隨著 AI 技術的蓬勃發展，越來越多的產品開始融入 AI 能力以優化用戶體驗和功能。在 AI 場景下，我們對微服務框架如 Kitex 提出了更高的期待，期望它能更好地支持 AI 組件的集成與編排，以及適配傳統的框架能力。

• 開箱即用的 AI 組件編排能力

在當前的開發實踐中，當需要集成AI能力時，開發人員通常需要自行處理復雜的邏輯，如調用 prompt、解析大模型輸出、以及將結果轉換為機器語言等。這不僅增加了開發難度，也降低了開發效率。因此，我們期待 Kitex 框架能夠提供開箱即用的 AI 組件編排能力。

具體來說，我們期望框架能夠預置一系列封裝好的 AI 組件，如 prompt 組件、大模型組件、結果解析組件以及 RPC調用組件等。這些組件應該具備高度的可配置性和可擴展性，以便能夠適應不同的業務需求。開發人員只需將業務邏輯傳入這些組件，而無需關心組件內部的實現細節，從而能夠更專注于業務邏輯的實現。

• 靈活的 AI 組件編排能力

除了提供預置的 AI 組件外，我們還期待 Kitex 框架能夠支持靈活的AI組件編排能力。這意味著框架應該提供一種表達式語言或可視化工具，使得開發人員能夠輕松地按照業務需求編排這些 AI 組件。通過這種方式，開發人員可以定義組件之間的執行順序、通信方式以及并行處理策略等，而無需深入了解組件之間的交互細節。這將大大提高 AI 應用的開發效率和可維護性。

• 傳統框架能力在 LLM 鏈路上適配

在 AI 場景下，傳統的框架能力如服務治理、元數據透傳以及可觀測性等仍然具有重要意義。因此，我們期待 Kitex 框架能夠在這些方面做出適配和優化。

首先，在服務治理方面，由于 AI 應用可能涉及長時間的推理過程，因此框架需要提供針對秒級甚至分鐘級響應時間的超時和限流策略。同時，還需要考慮如何處理與 AI 組件相關的異常情況。

其次，在元數據透傳方面，我們期望框架能夠支持在 AI 組件之間傳遞元數據，以便進行更精細化的監控和調試。這將有助于我們更好地理解 AI 應用的運行狀況，并快速定位問題。

最后，在可觀測性方面，我們期待 Kitex 框架能夠提供全面的日志、追蹤和指標收集功能，以便對 AI 鏈路進行全方位的監控和分析。這將有助于我們及時發現潛在的性能瓶頸和優化點，從而提升 AI 應用的性能和穩定性。

綜上所述，我們對 Kitex 框架在 AI 場景下的未來期待主要集中在開箱即用的 AI 組件編排能力、靈活的 AI 組件編排能力以及傳統框架能力在 LLM 鏈路上的適配等方面。我們相信隨著技術的不斷進步和團隊的深入合作，這些期待將逐漸變為現實，為 AI 應用的開發帶來更大的便利和效率。

實際上，我們團隊已經與 Kitex 團隊展開了深入的合作，共同探討如何在微服務框架中更好地支持 AI 場景。我們相信，在不久的將來，我們將能夠推出一個 MVP 版本的解決方案，為業務開發人員提供一個簡單、無縫地與 AI 能力結合的框架。這將是一個激動人心的時刻，我們期待著這一天的到來。

項目地址

GitHub：https://github.com/cloudwego

官網：www.cloudwego.io