AI 應用推理架構中五大關鍵問題的解決方案 原創 精華
一個企業級的 AI 應用推理架構中往往面臨以下5個關鍵問題：限流、負載均衡、異步化、數據管理、索引增強，本文對這5個關鍵問題進行深度剖析并給出優雅的解決方案。
1、AI 應用推理架構中的關鍵問題剖析
落地一個企業級 AI 應用產品是一項復雜的任務，它涉及到多個層面的產品化挑戰。為了確保產品的穩定性、效率和高質量的輸出結果，必須在大模型推理引擎的外圍進行大量的工程優化工作。以下是構建此類 AI 應用服務時可能遇到的一些關鍵問題：
第一、接入層調度問題
- 用戶請求的速率可能遠高于大模型推理服務的處理速率，導致請求積壓和服務器過載。
- 推理服務器間的負載可能不均衡，一些服務器過載而另一些則資源閑置，影響整體性能。
- 推理請求的處理時間可能較長且不確定，使得接入層服務難以設置合適的超時時間，增加了連接異常斷開的風險。
- 傳統的一問一答模式限制了人機交互的流暢性，無法支持復雜的雙向交互。
第二、用戶數據管理問題
- 需要有效管理用戶信息，以便根據用戶的具體需求定制化服務。
- 在多輪對話場景中，需要存儲和管理歷史對話信息，以維持對話的連貫性。
第三、結果的準確性問題
- 由于大模型的訓練數據有限，可能無法覆蓋所有行業數據和企業私域數據，影響結果的準確性。
2、AI 應用推理架構中5大關鍵問題解決方案
上面提到的 AI 應用推理架構中的問題可以概括為5大關鍵問題，分別為：限流、負載均衡、異步化、數據管理、索引增強，下面我們針對每個關鍵問題來逐一給出解決方案。
第一、限流關鍵問題的解決方案
為確保 AI 應用推理服務在面臨前端請求速率與后端處理速率不匹配時的穩定性，防止服務過載，并維持服務的吞吐量和服務質量水平，實施請求限流是一種有效策略。在傳統微服務服務架構中，可以利用 Redis 的 Incr 命令結合過期時間機制來實現固定窗口限流功能。
以下是實現該限流邏輯的偽代碼示例：
ret = jedis.incr(KEY);
if (ret == 1) {
// 設置過期時間
jedis.expire(KEY, EXPIRE_TIME);
}
if (ret <= LIMIT_COUNT) {
return true;
} else {
return false;
}這是一種基礎的限流方法，它能夠在一個固定的 ??EXPIRE_TIME ???時間內限制用戶的請求數量不超過 ??LIMIT_COUNT??。
然而，這種方法存在一些不足之處：限流效果不夠平滑，用戶可能在限流周期開始的第一秒就耗盡了所有的請求額度，導致在剩余時間內無法進行任何請求。此外，這種方法還要求用戶不斷嘗試重新發送請求，這可以想象，在一個人機交互的場景中，如果機器人服務一直提示用戶“系統繁忙，請稍后再試”，而用戶需要不斷重試，這種體驗是非常糟糕的。
為了改善這個問題，我們可以采用令牌桶算法的限流邏輯，它能夠解決限流不平滑和減少用戶重試的需求。
以下是采用令牌桶算法的限流邏輯的偽代碼示例：
// 請求端阻塞方式獲取令牌
jedis.blpop(TIMEOUT, KEY);
// 令牌生成端，定期向隊列中投放令牌
if (jedis.llen(KEY) < MAX_COUNT) {
jedis.rpush(KEY, value, ...);
}在限流策略中，引入等待機制可以在一定時間內避免用戶端的重復請求嘗試。如果用戶在指定的 TIMEOUT 時間內未能成功獲取令牌，則請求將被判定為失敗。這種方法有效減少了用戶端的重試頻率。通過設置較短的令牌發放間隔，可以實現更加平滑的流量控制。
然而，這種限流方法并沒有細致區分不同請求對推理服務器資源的不同影響。由于不同的推理請求可能會對推理服務器資源造成不同程度的消耗，因此，依據生成的 Token 數量來評估資源消耗可能更為合理。此外，業務可能需要根據特定情況實施自定義的限流邏輯。
為了滿足復雜的限流需求，僅依靠 Redis 的基本接口可能不夠靈活。因此，引入一個獨立的限流服務變得必要。該服務通過 Redis 與接入服務和限流服務解耦，利用 Redis 實現消息通知和結果推送。
簡化后的 AI 應用推理服務框架如下圖所示：用戶的請求首先到達無狀態的接入服務。接入服務利用 Redis 將限流相關的請求轉發至限流服務。限流服務根據用戶標識信息（uid）、推理服務器的負載情況、令牌狀態等，結合業務邏輯和策略，決定請求是直接失敗還是進入排隊隊列。請求在排隊成功或超時后，限流服務將結果通知接入服務，接入服務根據限流結果決定是否將請求轉發至推理服務。
通過這種設計，獨立的限流服務能夠根據產品的具體需求定制限流策略，實現復雜的限流邏輯。同時，Redis 作為消息隊列，不僅解耦了接入服務和限流服務，還完成了限流結果的實時推送，提高了系統的靈活性和響應速度。
這種架構設計使得系統能夠更加精細和靈活地控制流量，同時保證了服務的穩定性和高效性，為實現高級的業務需求提供了支持。
第二、負載均衡關鍵問題的解決方案
為了應對不斷增長的業務需求，后端通常會部署多臺服務器來處理請求，這就需要一種策略來將用戶的請求路由到合適的推理服務器上。常見的做法是使用 LVS、Nginx 等提供的第4層（L4）和第7層（L7）負載均衡服務來分配請求。
負載均衡器通常采用輪詢調度（Round Robin）或加權輪詢的方式來分發請求。這些調度算法沒有考慮到請求之間的差異，也沒有動態地考慮服務器負載的差異。在傳統的應用場景中，由于每個用戶請求對服務器的資源消耗相差不大，且請求執行速度快、資源消耗少，因此在請求數量足夠多的情況下，各個服務器的負載會趨于均衡。
然而，在 AI 應用推理場景下，不同請求對推理服務器的資源消耗可能有很大差異，請求執行時間較長，資源消耗較高。如果采用輪詢調度的方式，可能會導致部分推理服務器過載，而另一部分服務器的資源卻閑置，這不僅無法最大化整體吞吐量，也無法保證服務水平目標（SLO）。
雖然傳統的負載均衡服務提供了基于應用服務器的連接數、負載等指標的動態調度算法，但在推理場景下，這些算法的效果并不理想。應用服務器的連接數并不能準確代表其負載，而且負載指標通常是由負載均衡服務定期刷新的，無法實時更新。此外，多個負載均衡服務器之間的狀態同步也需要時間，如果多個負載均衡服務器同時將請求調度到一個負載較低的推理服務器上，可能會導致該服務器過載。
總的來說，由于單個推理請求的資源消耗較大，個體差異較大，少量的調度失衡就可能導致負載差異很大，因此傳統的負載均衡服務無法滿足推理請求的調度需求。
目前，針對推理請求的調度主要有兩類方案：
- 基于代價估算的方案：由一個調度器評估每條推理請求的代價，通過一個小模型快速估算請求推理結果所需的 Token 數量，然后在全局維度上根據估算的代價來分發請求。這種方案的優點是在分發請求時能夠考慮 KVCache 的親和性，比如：將多輪對話分發到同一臺推理服務器上，復用之前的 KVCache，減少重復計算。但缺點是調度邏輯較為復雜，調度器需要考慮服務器負載、請求估算代價、KVCache 親和性等多個指標，而且全局的調度器可能存在性能瓶頸，也需要考慮高可用性問題。當估算模型出現偏差時，還可能導致負載不均。
- 基于拉取的模型：接入服務并不直接將請求轉發給推理服務，而是將請求放入 Redis 的 stream 結構中，當推理服務空閑時，主動從 Redis 拉取請求。這保證了所有推理服務都能在最佳負載下運行。這種方案的優點是實現起來比較簡單，能夠保證推理服務器在最佳負載下運行，同時實現服務器間的負載均衡，提高整體吞吐量。缺點是很難保持 KVCache 的親和性，后續優化手段有限。
這兩種方案各有優缺點，需要根據具體的業務需求和系統架構來選擇最合適的負載均衡調度策略。
第三、請求異步化關鍵問題的解決方案
在復雜的模型推理場景中，由于推理過程耗時較長且推理時間不確定，如果接入服務同步等待結果，可能會導致過多的 HTTP 連接，以及因連接異常斷開而導致的請求失敗等問題，這些問題會降低整體性能并增加失敗率。
另一方面，同步請求方式通常遵循用戶發起提問、服務端完成推理后返回答案的一問一答模式。如果服務端能夠合理判斷用戶需求并主動發起對話，可以提升交互體驗。例如，當用戶詢問北京的景點后，他們可能對北京的旅游感興趣，因此也可能關心北京的酒店信息。異步化可以使架構更加靈活，簡化后期擴展新業務邏輯的過程。
此時，可以引入 Redis 作為消息隊列，將推理結果寫入 Redis stream 結構中。接入服務在請求提交成功后即可返回用戶請求提交成功的狀態，并可以流式地返回推理結果，避免用戶長時間等待。此外，這種設計解耦了接入服務和推理服務之間的強綁定關系，允許其他服務組件也能向 Redis stream 結構寫入數據，實現對用戶的主動交互。
通過異步化改造，可以獲得以下好處：
- 流式返回結果給用戶，提升用戶體驗。
- 解耦組件間的直接關聯，方便后續業務邏輯的擴展。
- 避免請求發起端盲目等待結果返回，提高效率。
第四、用戶數據管理關鍵問題的解決方案
1.用戶信息管理與個性化服務
通過整合用戶的注冊信息和歷史對話記錄，系統能夠為每位用戶創建獨特的標簽。這些標簽隨后作為系統提示（Prompt）與用戶請求一同提交至推理引擎，從而生成定制化的結果。這種“千人千面”的方法使得服務結果更貼合用戶的個性化需求和預期。
利用 Redis 的 hash 結構，可以以樹狀格式高效存儲用戶的屬性信息，該結構同時支持快速的單個查詢（點查）和批量查詢操作。
2.歷史消息管理與對話連續性
在多輪對話場景中，系統需存儲先前的對話內容，并將這些信息作為提示詞（Prompt）影響后續請求，以保持對話的連貫性。此外，為了產品化需求，系統還需保存用戶在一定時間內的歷史對話記錄，以便用戶能夠回顧之前的交流內容。
對話信息的存儲方式具有很高的靈活性，可采用多種實現策略。例如，可以使用 zset 結構來保存歷史對話，并將對話的時間戳作為評分（score），這樣不僅便于對對話信息進行排序，還能輕松實現最早對話的刪除以及按時間順序查看歷史對話。
如果服務已經通過 stream 結構實現了異步化改造，那么所有的推理請求和結果都將存儲在 stream中，無需額外存儲。Stream 結構支持設置隊列大小，并能自動刪除最早的對話消息。
3.會話（Session）管理
鑒于不同的對話可能涉及不同的上下文信息，可以使用 Redis 的 hash 結構來存儲會話（session）信息，以實現快速切換和管理。這種方法有助于維護不同對話的獨立性和連貫性，提升用戶體驗。
第五、RAG（檢索增強生成）
采用檢索增強生成（Retrieval-Augmented Generation，簡稱 RAG）的方法可以有效應對傳統大語言模型（LLM）在實際應用中遇到的限制，這些限制包括：
- 知識更新滯后：LLM 的訓練數據往往停留在某個時間節點，難以實現實時更新。
- 產生幻覺：LLM 有時會產生與事實不符的內容。
- 領域專業性不足：通用模型在特定領域（比如：法律、醫學等）的表現可能不盡如人意。
- 推理能力有限：LLM 在處理復雜的推理任務時可能表現不佳。
與大模型微調（Fine-tuning）相比，RAG 方法的成本更低，且能保持更高的數據時效性。
以實現一個接入 Milvus 向量數據庫的 FAQ 問答機器人為例，可以采取以下方案：
- 數據檢索：利用 Milvus 等向量數據庫，根據用戶的問題檢索最相關的 FAQ 條目。
- 信息融合：將檢索到的信息與 LLM 的生成能力相結合，以提供更準確、更豐富的回答。
- 上下文理解：通過檢索增強，LLM 能夠更好地理解上下文，從而提高回答的相關性和準確性。
- 持續更新：由于 RAG 不依賴于模型的全面微調，因此可以更容易地更新知識庫，以反映最新的信息和數據。
通過這種方式，RAG 不僅能夠提高問答系統的性能，還能夠保持成本效益和靈活性，使其成為處理特定領域問題的有效工具。
綜合上述5個關鍵問題的解決方案，一個典型場景的 AI 應用推理服務流程如下所示：
1.用戶發起請求到接入服務服務器。
2.接入服務異步請求限流服務，并在請求的 UUID 上等待 Redis 通知。
3.限流服務在排隊完成或超時后通過 Redis 將限流結果通知給接入服務。
4.接入服務通過 Redis 查詢到用戶信息、歷史對話信息，作為請求的 Prompt。
5.接入服務通過 Milvus 向量檢索拿到相關信息，也作為請求的 Prompt。
6.接入服務將請求寫入 Redis stream 隊列。
7.空閑的推理服務從 Redis stream 拉取到推理請求。
8.推理服務將推理結果寫入 Redis stream 隊列。
9.接入服務通過 Redis 異步獲取到推理結果。
10.返回用戶結果。
這個流程描述了用戶請求如何通過接入服務、限流服務、Redis 以及推理服務進行處理，并最終將結果返回給用戶。通過使用 Redis 作為消息隊列和存儲，實現了請求的異步處理和負載均衡，提高了系統的響應性和可靠性。
?? 輪到你了：你認為 AI 應用企業級落地還有哪些注意點？
本文轉載自??玄姐聊AGI?? 作者：玄姐
