（本文閱讀時間：10分鐘）
大語言模型（LLMs）以其卓越的語言理解能力引領了一場應用開發領域的正規化轉變。在新興正規化中，一個或多個應用實體，被稱為 AI 代理（AI agent）或 AI 智慧副駕駛（AI co-pilot），透過自然語言（即“提示詞”prompt）與 LLMs 進行交流，以協作完成一項任務。這種協作方式使得基於 LLMs 的應用程式能夠透過一系列精心設計的對話流程，實現任務的高效執行。這些對話流程通常涉及多輪對話，每個對話都透過向 LLMs 發起 API 呼叫來實現。
圖1：LLMs 應用中幾種流行的對話模式
圖1展示了一些常見的基於 LLMs 的應用工作流程。這些流程不僅揭示了 LLMs 在不同場景下的應用模式，還體現了它們在處理複雜任務時的靈活性和高效性。以多代理程式設計應用為例，它展示了 LLMs 扮演的不同角色（如產品經理、架構師、工程師、QA 測試員）如何協作完成軟體專案。在這個過程中，每個角色都透過呼叫 LLMs 來執行特定的任務，如設計 API、編寫程式碼、進行程式碼審查等。這些任務之間的呼叫關係並非簡單的線性流程，而是形成了一張複雜的呼叫關係圖，即有向無環圖（DAG）。這種結構不僅揭示了任務之間的依賴關係，也為最佳化整個工作流程提供了可能。
現在大多數 LLMs 應用都依賴於公共的語言模型服務，但這些公共 LLMs 服務提供商只能觀察到大量的單獨請求，而不瞭解任何應用級資訊。例如，它們不清楚哪些請求屬於同一應用，不同請求之間如何連線，或者是否存在任何相似性。這些丟失的應用級資訊使得公共 LLMs 服務只能盲目地最佳化單個請求的效能，從而導致 LLMs 應用在端到端之間產生效能次優的問題。
目前的公共 LLMs 服務中存在三個關鍵問題：
網路延遲開銷。在 API 的排程中，多個 LLMs 請求之間的依賴性和相互關聯容易被忽略。這些 LLMs 請求只能在基於 LLMs 的應用客戶端和公共的 LLMs 服務之間互動式執行。其中可能產生網路延遲、排隊等額外開銷，損害了 LLMs 應用端到端的效能。
排程目標錯位。LLMs 請求可能存在不同的排程偏好。例如 Map Reduce 模式可以透過批次處理 Map 請求增加任務的吞吐量、減少端到端的延遲，在 Reduce 時則統一針對延遲問題進行最佳化。然而當前的公共 LLMs 服務難以區分這兩種型別任務的差異，只會盲目地最佳化單個請求的延遲，這就導致了使用過程中的需求錯位，不利於端到端的體驗。
重複共性需求。LLMs 請求之間存在高度的共性。流行的 LLMs 應用會使用一個長系統提示，包括任務定義、示例和安全規則，來指導 LLMs 應用的行為。長系統提示通常是靜態的，對所有使用者都是通用的。但現有的公共 LLMs 服務是將每個請求單獨對待，這些常見的字首提示在每個請求中都被重複提供，導致儲存、計算和記憶體頻寬產生巨大的浪費。
總結來說，以上三類問題基本源於對 LLMs 請求相關性的理解不足。關鍵資訊的缺失使得最新的最佳化技術難以在現在的服務中得到充分的應用。因此，開發一個能夠將 LLMs 請求間的各種關係“傳達”到服務後端的方法至關重要。
基於以上的分析，微軟亞洲研究院的研究員們設計了 Parrot 工具，它可以透過簡單的抽象語義變數保留大部分應用級資訊，從而實現在增加系統複雜性和帶來新資訊進行最佳化之間的完美平衡。該論文已被計算機系統領域頂級學術會議 OSDI 2024 收錄。
論文：Parrot: Efficient Serving of LLM-based Applications with Semantic Variable
論文連結：
https://arxiv.org/abs/2405.19888
GitHub連結：
https://github.com/microsoft/ParrotServe
圖2：Parrot 系統概覽
語義變數的引入
研究員們首先提出了語義變數（semantic variable）以實現對跨請求的抽象。圖3是使用 Parrot 前端編寫的一個簡單的 LLMs 應用：編寫一段 Python 程式碼並撰寫測試程式碼。它包含三個語義變數：task、code 和 test，以及兩個語義函式：WritePythonCode 和 WriteTestCode。
圖3：簡化的多代理應用示例
語義變數是一個字串型別的變數，具有填充或未填充兩種狀態。研究員們在前端中將語義變數設計為 Python 中的變數。再基於 OpenAI 的 API 擴充套件，利用 Parrot 提供帶有語義變數的 API，透過在提示中引入佔位符，可以支援以 {{placeholder_name}} 這樣的形式將每個佔位符繫結一個語義變數，從而實現請求對語義變數的引用。
一個提示中的佔位符和其繫結的語義變數可能有輸入、輸出兩種關係：輸入表示語義變數為這個佔位符提供值；輸出表示這個提示對應的請求為這個語義變數生成值。利用佔位符和語義變數，Parrot 就能在服務端輕鬆建立 DAG。
圖4：圖3中的 DAG 工作流和用於請求間分析和最佳化的原語
此外，在提示中引入佔位符的方式還能夠使提示本身變得結構化（structural）。依賴語義變數，Parrot 首先可以構建出請求間的 DAG，再透過分析圖上的資訊來提取請求間關係的資訊。其次，Parrot 能利用語義變數將提示分段，然後對每段分別進行雜湊值計算等，以獲取請求間在提示結構方面的關係。
綜上，透過允許在提示中引入佔位符，Parrot 擴充套件了現有的 API，引入了抽象的語義變數，實現了對請求間關係以及排程偏好的分析。
基於語義變數進行最佳化
在有了語義變數及其帶來的請求間分析的原語後，研究員們豐富了系統獲取應用端資訊的能力，具體而言：
透過分析 DAG，Parrot 能找到互相依賴的請求（例如請求 A 的輸出是請求 B 的輸入）且可以將其改為非同步的形式。使用者可以透過帶有語義變數的 API 將整個執行圖先提交到系統中，再對最後輸出的語義變數呼叫 “get” 來獲取結果。之後，Parrot 會使用基於圖的執行器對 DAG 圖進行高效執行，並且在排程上會考慮請求與應用的關係從而最最佳化排隊時間。這使得在 Parrot 中執行這樣的相互依賴性請求時非常節省時間。
透過效能目標推導，Parrot 能實現端到端的最佳化（例如針對延遲、吞吐量）。Parrot 會給每個語義變數附帶一個“效能目標”標記。使用者可以提供整個 DAG 最後一個語義變數的效能目標，然後 Parrot 會在圖上將這一標記“反向傳播”，最後讓每一個語義變數都擁有一個性能目標。此外，對於前面提到的 MapReduce 情況，Parrot 還會採用 Grouping 的策略，讓排程器儘量將它們當作整體進行排程。
透過對提示結構的分析，Parrot 可以迅速找到不同請求間共享的相同字首。Parrot 會使用類似 vLLM 的 fork 技術共享它們的 KV 快取，並且在這一基礎上支援更多情況：
-
動態生成的共享字首。現有字首共享技術大都需要提前知道所共享的字首內容（具體值），但是在很多場景中，該內容是動態生成的。比如前述多代理程式設計應用中的程式碼段，其會被多個下游代理（如測試，程式碼審查等）所使用，由於它是動態生成的，所以現有共享字首技術很難對其加速。對於 Parrot 系統而言，同一個 DAG 如果請求間共享相同的佔位符（而非僅僅是靜態字串），即使其還沒有真正具有值，Parrot 也可以將其判定出來並在執行時進行共享。
-
執行時加速。Parrot 設計了特殊的 CUDA kernel 與注意力演算法，使得其在共享字首的批次推理中不僅能夠節省儲存開銷，還能夠省掉不必要的資料載入和計算，從而能夠達到很好的加速效果。
-
與其他最佳化的配合。需要注意的是，Parrot 的 Sharing Prefix 技術與其他系統中的部件是一體的，並不是獨立的技術。例如配合 DAG，Parrot 具有 DAG 上的共享能力。總而言之，基於相同的抽象基礎，Parrot 能夠實現多種最佳化技術之間的協同工作。
透過一個綜合性、啟發性的演算法，Parrot 能找到滿足請求排程偏好的引擎，同時最小化負面影響。例如，對於相互依賴的請求，Parrot 會優先進行排程來減少排隊時間；而對於帶有特定效能目標標記的請求，Parrot 會根據不同的標記進行排程，以及將叢集的請求當作一個整體進行排程。
作為一個為 LLMs 應用提供的端到端 LLMs 服務，Parrot 展示了 LLMs 請求之間的依賴性和共性，使得一個新的最佳化空間成為可能。一方面 Parrot 聚焦於 LLMs 應用服務的最佳化，指出不應該把應用端請求都當成獨立的請求來看待，而應該將其“傳達”給服務端，並明確各請求間的關聯；另一方面，Parrot 的技術細節，包括 API 設計、Engine API 都能為以後的 LLMs 應用服務設計提供參考。
Parrot 的評估結果表明，其可以透過高達11.7倍的最佳化改善基於 LLMs 的應用。它不僅能有效提高 LLMs 應用的效率，還能提升例如 LLMs 應用端到端效能的公平性等其他排程特性。未來，微軟亞洲研究院的研究員們將持續探索該技術如何用於更廣泛的 LLMs 應用場景，以及如何進一步最佳化 LLMs 應用的多維度效能。
你也許還想看：