一個(gè)企業(yè)級的 AI 應(yīng)用推理架構(gòu)中往往面臨以下5個(gè)關(guān)鍵問題：限流、負(fù)載均衡、異步化、數(shù)據(jù)管理、索引增強(qiáng)，本文對這5個(gè)關(guān)鍵問題進(jìn)行深度剖析并給出優(yōu)雅的解決方案。

1、AI 應(yīng)用推理架構(gòu)中的關(guān)鍵問題剖析

落地一個(gè)企業(yè)級 AI 應(yīng)用產(chǎn)品是一項(xiàng)復(fù)雜的任務(wù)，它涉及到多個(gè)層面的產(chǎn)品化挑戰(zhàn)。為了確保產(chǎn)品的穩(wěn)定性、效率和高質(zhì)量的輸出結(jié)果，必須在大模型推理引擎的外圍進(jìn)行大量的工程優(yōu)化工作。以下是構(gòu)建此類 AI 應(yīng)用服務(wù)時(shí)可能遇到的一些關(guān)鍵問題：

第一、接入層調(diào)度問題

• 用戶請求的速率可能遠(yuǎn)高于大模型推理服務(wù)的處理速率，導(dǎo)致請求積壓和服務(wù)器過載。
• 推理服務(wù)器間的負(fù)載可能不均衡，一些服務(wù)器過載而另一些則資源閑置，影響整體性能。
• 推理請求的處理時(shí)間可能較長且不確定，使得接入層服務(wù)難以設(shè)置合適的超時(shí)時(shí)間，增加了連接異常斷開的風(fēng)險(xiǎn)。
• 傳統(tǒng)的一問一答模式限制了人機(jī)交互的流暢性，無法支持復(fù)雜的雙向交互。

第二、用戶數(shù)據(jù)管理問題

• 需要有效管理用戶信息，以便根據(jù)用戶的具體需求定制化服務(wù)。
• 在多輪對話場景中，需要存儲和管理歷史對話信息，以維持對話的連貫性。

第三、結(jié)果的準(zhǔn)確性問題

• 由于大模型的訓(xùn)練數(shù)據(jù)有限，可能無法覆蓋所有行業(yè)數(shù)據(jù)和企業(yè)私域數(shù)據(jù)，影響結(jié)果的準(zhǔn)確性。

2、AI 應(yīng)用推理架構(gòu)中5大關(guān)鍵問題解決方案

上面提到的 AI 應(yīng)用推理架構(gòu)中的問題可以概括為5大關(guān)鍵問題，分別為：限流、負(fù)載均衡、異步化、數(shù)據(jù)管理、索引增強(qiáng)，下面我們針對每個(gè)關(guān)鍵問題來逐一給出解決方案。

第一、限流關(guān)鍵問題的解決方案

為確保 AI 應(yīng)用推理服務(wù)在面臨前端請求速率與后端處理速率不匹配時(shí)的穩(wěn)定性，防止服務(wù)過載，并維持服務(wù)的吞吐量和服務(wù)質(zhì)量水平，實(shí)施請求限流是一種有效策略。在傳統(tǒng)微服務(wù)服務(wù)架構(gòu)中，可以利用 Redis 的 Incr 命令結(jié)合過期時(shí)間機(jī)制來實(shí)現(xiàn)固定窗口限流功能。

以下是實(shí)現(xiàn)該限流邏輯的偽代碼示例：

ret = jedis.incr(KEY);
if (ret == 1) {
    // 設(shè)置過期時(shí)間
    jedis.expire(KEY, EXPIRE_TIME);
}
if (ret <= LIMIT_COUNT) {
    return true; 
} else {
    return false; 
}

這是一種基礎(chǔ)的限流方法，它能夠在一個(gè)固定的 ??EXPIRE_TIME ???時(shí)間內(nèi)限制用戶的請求數(shù)量不超過 ??LIMIT_COUNT??。

然而，這種方法存在一些不足之處：限流效果不夠平滑，用戶可能在限流周期開始的第一秒就耗盡了所有的請求額度，導(dǎo)致在剩余時(shí)間內(nèi)無法進(jìn)行任何請求。此外，這種方法還要求用戶不斷嘗試重新發(fā)送請求，這可以想象，在一個(gè)人機(jī)交互的場景中，如果機(jī)器人服務(wù)一直提示用戶“系統(tǒng)繁忙，請稍后再試”，而用戶需要不斷重試，這種體驗(yàn)是非常糟糕的。

為了改善這個(gè)問題，我們可以采用令牌桶算法的限流邏輯，它能夠解決限流不平滑和減少用戶重試的需求。

以下是采用令牌桶算法的限流邏輯的偽代碼示例：

// 請求端阻塞方式獲取令牌
jedis.blpop(TIMEOUT, KEY);


// 令牌生成端，定期向隊(duì)列中投放令牌
if (jedis.llen(KEY) < MAX_COUNT) {
  jedis.rpush(KEY, value, ...);
}

在限流策略中，引入等待機(jī)制可以在一定時(shí)間內(nèi)避免用戶端的重復(fù)請求嘗試。如果用戶在指定的 TIMEOUT 時(shí)間內(nèi)未能成功獲取令牌，則請求將被判定為失敗。這種方法有效減少了用戶端的重試頻率。通過設(shè)置較短的令牌發(fā)放間隔，可以實(shí)現(xiàn)更加平滑的流量控制。

然而，這種限流方法并沒有細(xì)致區(qū)分不同請求對推理服務(wù)器資源的不同影響。由于不同的推理請求可能會對推理服務(wù)器資源造成不同程度的消耗，因此，依據(jù)生成的 Token 數(shù)量來評估資源消耗可能更為合理。此外，業(yè)務(wù)可能需要根據(jù)特定情況實(shí)施自定義的限流邏輯。

為了滿足復(fù)雜的限流需求，僅依靠 Redis 的基本接口可能不夠靈活。因此，引入一個(gè)獨(dú)立的限流服務(wù)變得必要。該服務(wù)通過 Redis 與接入服務(wù)和限流服務(wù)解耦，利用 Redis 實(shí)現(xiàn)消息通知和結(jié)果推送。

簡化后的 AI 應(yīng)用推理服務(wù)框架如下圖所示：用戶的請求首先到達(dá)無狀態(tài)的接入服務(wù)。接入服務(wù)利用 Redis 將限流相關(guān)的請求轉(zhuǎn)發(fā)至限流服務(wù)。限流服務(wù)根據(jù)用戶標(biāo)識信息（uid）、推理服務(wù)器的負(fù)載情況、令牌狀態(tài)等，結(jié)合業(yè)務(wù)邏輯和策略，決定請求是直接失敗還是進(jìn)入排隊(duì)隊(duì)列。請求在排隊(duì)成功或超時(shí)后，限流服務(wù)將結(jié)果通知接入服務(wù)，接入服務(wù)根據(jù)限流結(jié)果決定是否將請求轉(zhuǎn)發(fā)至推理服務(wù)。

通過這種設(shè)計(jì)，獨(dú)立的限流服務(wù)能夠根據(jù)產(chǎn)品的具體需求定制限流策略，實(shí)現(xiàn)復(fù)雜的限流邏輯。同時(shí)，Redis 作為消息隊(duì)列，不僅解耦了接入服務(wù)和限流服務(wù)，還完成了限流結(jié)果的實(shí)時(shí)推送，提高了系統(tǒng)的靈活性和響應(yīng)速度。

這種架構(gòu)設(shè)計(jì)使得系統(tǒng)能夠更加精細(xì)和靈活地控制流量，同時(shí)保證了服務(wù)的穩(wěn)定性和高效性，為實(shí)現(xiàn)高級的業(yè)務(wù)需求提供了支持。

第二、負(fù)載均衡關(guān)鍵問題的解決方案

為了應(yīng)對不斷增長的業(yè)務(wù)需求，后端通常會部署多臺服務(wù)器來處理請求，這就需要一種策略來將用戶的請求路由到合適的推理服務(wù)器上。常見的做法是使用 LVS、Nginx 等提供的第4層（L4）和第7層（L7）負(fù)載均衡服務(wù)來分配請求。

負(fù)載均衡器通常采用輪詢調(diào)度（Round Robin）或加權(quán)輪詢的方式來分發(fā)請求。這些調(diào)度算法沒有考慮到請求之間的差異，也沒有動(dòng)態(tài)地考慮服務(wù)器負(fù)載的差異。在傳統(tǒng)的應(yīng)用場景中，由于每個(gè)用戶請求對服務(wù)器的資源消耗相差不大，且請求執(zhí)行速度快、資源消耗少，因此在請求數(shù)量足夠多的情況下，各個(gè)服務(wù)器的負(fù)載會趨于均衡。

然而，在 AI 應(yīng)用推理場景下，不同請求對推理服務(wù)器的資源消耗可能有很大差異，請求執(zhí)行時(shí)間較長，資源消耗較高。如果采用輪詢調(diào)度的方式，可能會導(dǎo)致部分推理服務(wù)器過載，而另一部分服務(wù)器的資源卻閑置，這不僅無法最大化整體吞吐量，也無法保證服務(wù)水平目標(biāo)（SLO）。

雖然傳統(tǒng)的負(fù)載均衡服務(wù)提供了基于應(yīng)用服務(wù)器的連接數(shù)、負(fù)載等指標(biāo)的動(dòng)態(tài)調(diào)度算法，但在推理場景下，這些算法的效果并不理想。應(yīng)用服務(wù)器的連接數(shù)并不能準(zhǔn)確代表其負(fù)載，而且負(fù)載指標(biāo)通常是由負(fù)載均衡服務(wù)定期刷新的，無法實(shí)時(shí)更新。此外，多個(gè)負(fù)載均衡服務(wù)器之間的狀態(tài)同步也需要時(shí)間，如果多個(gè)負(fù)載均衡服務(wù)器同時(shí)將請求調(diào)度到一個(gè)負(fù)載較低的推理服務(wù)器上，可能會導(dǎo)致該服務(wù)器過載。

總的來說，由于單個(gè)推理請求的資源消耗較大，個(gè)體差異較大，少量的調(diào)度失衡就可能導(dǎo)致負(fù)載差異很大，因此傳統(tǒng)的負(fù)載均衡服務(wù)無法滿足推理請求的調(diào)度需求。

目前，針對推理請求的調(diào)度主要有兩類方案：

• 基于代價(jià)估算的方案：由一個(gè)調(diào)度器評估每條推理請求的代價(jià)，通過一個(gè)小模型快速估算請求推理結(jié)果所需的 Token 數(shù)量，然后在全局維度上根據(jù)估算的代價(jià)來分發(fā)請求。這種方案的優(yōu)點(diǎn)是在分發(fā)請求時(shí)能夠考慮 KVCache 的親和性，比如：將多輪對話分發(fā)到同一臺推理服務(wù)器上，復(fù)用之前的 KVCache，減少重復(fù)計(jì)算。但缺點(diǎn)是調(diào)度邏輯較為復(fù)雜，調(diào)度器需要考慮服務(wù)器負(fù)載、請求估算代價(jià)、KVCache 親和性等多個(gè)指標(biāo)，而且全局的調(diào)度器可能存在性能瓶頸，也需要考慮高可用性問題。當(dāng)估算模型出現(xiàn)偏差時(shí)，還可能導(dǎo)致負(fù)載不均。
• 基于拉取的模型：接入服務(wù)并不直接將請求轉(zhuǎn)發(fā)給推理服務(wù)，而是將請求放入 Redis 的 stream 結(jié)構(gòu)中，當(dāng)推理服務(wù)空閑時(shí)，主動(dòng)從 Redis 拉取請求。這保證了所有推理服務(wù)都能在最佳負(fù)載下運(yùn)行。這種方案的優(yōu)點(diǎn)是實(shí)現(xiàn)起來比較簡單，能夠保證推理服務(wù)器在最佳負(fù)載下運(yùn)行，同時(shí)實(shí)現(xiàn)服務(wù)器間的負(fù)載均衡，提高整體吞吐量。缺點(diǎn)是很難保持 KVCache 的親和性，后續(xù)優(yōu)化手段有限。

這兩種方案各有優(yōu)缺點(diǎn)，需要根據(jù)具體的業(yè)務(wù)需求和系統(tǒng)架構(gòu)來選擇最合適的負(fù)載均衡調(diào)度策略。

第三、請求異步化關(guān)鍵問題的解決方案

在復(fù)雜的模型推理場景中，由于推理過程耗時(shí)較長且推理時(shí)間不確定，如果接入服務(wù)同步等待結(jié)果，可能會導(dǎo)致過多的 HTTP 連接，以及因連接異常斷開而導(dǎo)致的請求失敗等問題，這些問題會降低整體性能并增加失敗率。

另一方面，同步請求方式通常遵循用戶發(fā)起提問、服務(wù)端完成推理后返回答案的一問一答模式。如果服務(wù)端能夠合理判斷用戶需求并主動(dòng)發(fā)起對話，可以提升交互體驗(yàn)。例如，當(dāng)用戶詢問北京的景點(diǎn)后，他們可能對北京的旅游感興趣，因此也可能關(guān)心北京的酒店信息。異步化可以使架構(gòu)更加靈活，簡化后期擴(kuò)展新業(yè)務(wù)邏輯的過程。

此時(shí)，可以引入 Redis 作為消息隊(duì)列，將推理結(jié)果寫入 Redis stream 結(jié)構(gòu)中。接入服務(wù)在請求提交成功后即可返回用戶請求提交成功的狀態(tài)，并可以流式地返回推理結(jié)果，避免用戶長時(shí)間等待。此外，這種設(shè)計(jì)解耦了接入服務(wù)和推理服務(wù)之間的強(qiáng)綁定關(guān)系，允許其他服務(wù)組件也能向 Redis stream 結(jié)構(gòu)寫入數(shù)據(jù)，實(shí)現(xiàn)對用戶的主動(dòng)交互。

通過異步化改造，可以獲得以下好處：

• 流式返回結(jié)果給用戶，提升用戶體驗(yàn)。
• 解耦組件間的直接關(guān)聯(lián)，方便后續(xù)業(yè)務(wù)邏輯的擴(kuò)展。
• 避免請求發(fā)起端盲目等待結(jié)果返回，提高效率。

第四、用戶數(shù)據(jù)管理關(guān)鍵問題的解決方案

1.用戶信息管理與個(gè)性化服務(wù)

通過整合用戶的注冊信息和歷史對話記錄，系統(tǒng)能夠?yàn)槊课挥脩魟?chuàng)建獨(dú)特的標(biāo)簽。這些標(biāo)簽隨后作為系統(tǒng)提示（Prompt）與用戶請求一同提交至推理引擎，從而生成定制化的結(jié)果。這種“千人千面”的方法使得服務(wù)結(jié)果更貼合用戶的個(gè)性化需求和預(yù)期。

利用 Redis 的 hash 結(jié)構(gòu)，可以以樹狀格式高效存儲用戶的屬性信息，該結(jié)構(gòu)同時(shí)支持快速的單個(gè)查詢（點(diǎn)查）和批量查詢操作。

2.歷史消息管理與對話連續(xù)性

在多輪對話場景中，系統(tǒng)需存儲先前的對話內(nèi)容，并將這些信息作為提示詞（Prompt）影響后續(xù)請求，以保持對話的連貫性。此外，為了產(chǎn)品化需求，系統(tǒng)還需保存用戶在一定時(shí)間內(nèi)的歷史對話記錄，以便用戶能夠回顧之前的交流內(nèi)容。

對話信息的存儲方式具有很高的靈活性，可采用多種實(shí)現(xiàn)策略。例如，可以使用 zset 結(jié)構(gòu)來保存歷史對話，并將對話的時(shí)間戳作為評分（score），這樣不僅便于對對話信息進(jìn)行排序，還能輕松實(shí)現(xiàn)最早對話的刪除以及按時(shí)間順序查看歷史對話。

如果服務(wù)已經(jīng)通過 stream 結(jié)構(gòu)實(shí)現(xiàn)了異步化改造，那么所有的推理請求和結(jié)果都將存儲在 stream中，無需額外存儲。Stream 結(jié)構(gòu)支持設(shè)置隊(duì)列大小，并能自動(dòng)刪除最早的對話消息。

3.會話（Session）管理

鑒于不同的對話可能涉及不同的上下文信息，可以使用 Redis 的 hash 結(jié)構(gòu)來存儲會話（session）信息，以實(shí)現(xiàn)快速切換和管理。這種方法有助于維護(hù)不同對話的獨(dú)立性和連貫性，提升用戶體驗(yàn)。

第五、RAG（檢索增強(qiáng)生成）

采用檢索增強(qiáng)生成（Retrieval-Augmented Generation，簡稱 RAG）的方法可以有效應(yīng)對傳統(tǒng)大語言模型（LLM）在實(shí)際應(yīng)用中遇到的限制，這些限制包括：

• 知識更新滯后：LLM 的訓(xùn)練數(shù)據(jù)往往停留在某個(gè)時(shí)間節(jié)點(diǎn)，難以實(shí)現(xiàn)實(shí)時(shí)更新。
• 產(chǎn)生幻覺：LLM 有時(shí)會產(chǎn)生與事實(shí)不符的內(nèi)容。
• 領(lǐng)域?qū)I(yè)性不足：通用模型在特定領(lǐng)域（比如：法律、醫(yī)學(xué)等）的表現(xiàn)可能不盡如人意。
• 推理能力有限：LLM 在處理復(fù)雜的推理任務(wù)時(shí)可能表現(xiàn)不佳。

與大模型微調(diào)（Fine-tuning）相比，RAG 方法的成本更低，且能保持更高的數(shù)據(jù)時(shí)效性。

以實(shí)現(xiàn)一個(gè)接入 Milvus 向量數(shù)據(jù)庫的 FAQ 問答機(jī)器人為例，可以采取以下方案：

• 數(shù)據(jù)檢索：利用 Milvus 等向量數(shù)據(jù)庫，根據(jù)用戶的問題檢索最相關(guān)的 FAQ 條目。
• 信息融合：將檢索到的信息與 LLM 的生成能力相結(jié)合，以提供更準(zhǔn)確、更豐富的回答。
• 上下文理解：通過檢索增強(qiáng)，LLM 能夠更好地理解上下文，從而提高回答的相關(guān)性和準(zhǔn)確性。
• 持續(xù)更新：由于 RAG 不依賴于模型的全面微調(diào)，因此可以更容易地更新知識庫，以反映最新的信息和數(shù)據(jù)。

通過這種方式，RAG 不僅能夠提高問答系統(tǒng)的性能，還能夠保持成本效益和靈活性，使其成為處理特定領(lǐng)域問題的有效工具。

綜合上述5個(gè)關(guān)鍵問題的解決方案，一個(gè)典型場景的 AI 應(yīng)用推理服務(wù)流程如下所示：

1.用戶發(fā)起請求到接入服務(wù)服務(wù)器。

2.接入服務(wù)異步請求限流服務(wù)，并在請求的 UUID 上等待 Redis 通知。

3.限流服務(wù)在排隊(duì)完成或超時(shí)后通過 Redis 將限流結(jié)果通知給接入服務(wù)。

4.接入服務(wù)通過 Redis 查詢到用戶信息、歷史對話信息，作為請求的 Prompt。

5.接入服務(wù)通過 Milvus 向量檢索拿到相關(guān)信息，也作為請求的 Prompt。

6.接入服務(wù)將請求寫入 Redis stream 隊(duì)列。

7.空閑的推理服務(wù)從 Redis stream 拉取到推理請求。

8.推理服務(wù)將推理結(jié)果寫入 Redis stream 隊(duì)列。

9.接入服務(wù)通過 Redis 異步獲取到推理結(jié)果。

10.返回用戶結(jié)果。

這個(gè)流程描述了用戶請求如何通過接入服務(wù)、限流服務(wù)、Redis 以及推理服務(wù)進(jìn)行處理，并最終將結(jié)果返回給用戶。通過使用 Redis 作為消息隊(duì)列和存儲，實(shí)現(xiàn)了請求的異步處理和負(fù)載均衡，提高了系統(tǒng)的響應(yīng)性和可靠性。

?? 輪到你了：你認(rèn)為 AI 應(yīng)用企業(yè)級落地還有哪些注意點(diǎn)？

本文轉(zhuǎn)載自??玄姐聊AGI??  作者：玄姐