1. 項(xiàng)目概述從兩層視角看多智能體LLM系統(tǒng)的推理時并行最近在折騰一個多智能體LLM系統(tǒng)的性能優(yōu)化項(xiàng)目核心目標(biāo)就一個怎么讓一群“AI大腦”在推理時也就是實(shí)際干活回答問題時跑得更快、更穩(wěn)、更省錢。這問題聽起來有點(diǎn)學(xué)術(shù)但實(shí)際落地時全是實(shí)打?qū)嵉墓こ烫魬?zhàn)。你可能會想現(xiàn)在單個大模型的推理優(yōu)化已經(jīng)夠復(fù)雜了多個模型智能體一起協(xié)作那延遲和資源消耗豈不是要指數(shù)級增長沒錯這就是“推理時并行”要解決的核心矛盾——如何在保證多智能體間復(fù)雜協(xié)作邏輯的前提下最大化硬件利用率和整體吞吐量。我這次分享的“兩層視角”不是什么高深理論而是我們從一堆失敗嘗試?yán)锟偨Y(jié)出來的實(shí)戰(zhàn)框架。簡單說就是把問題拆成兩個層面來看智能體間并行和智能體內(nèi)并行。前者關(guān)注多個智能體如何像一支球隊一樣分工協(xié)作、同時跑任務(wù)后者則深入到單個智能體內(nèi)部看它的計算圖比如Transformer層怎么在芯片上高效展開。很多團(tuán)隊一上來就扎進(jìn)某個具體的技術(shù)比如某款推理引擎往往忽略了這種分層設(shè)計的全局觀結(jié)果就是局部優(yōu)化了整體瓶頸卻卡在別處。這個思路尤其適合當(dāng)前熱門的應(yīng)用場景比如基于LLM的自主智能體、復(fù)雜任務(wù)編排與分解、多專家協(xié)作系統(tǒng)像最近大家討論的text2jsontext2sql這類管道任務(wù)甚至是多智能體強(qiáng)化學(xué)習(xí)中的策略評估。在這些場景里系統(tǒng)往往由多個具備不同能力的LLM或同個LLM的不同實(shí)例組成它們需要通信、競爭或協(xié)作來完成一個用戶請求。如果并行策略設(shè)計不好輕則響應(yīng)慢、用戶體驗(yàn)差重則GPU資源空轉(zhuǎn)、成本失控。2. 核心架構(gòu)兩層并行設(shè)計詳解2.1 智能體間并行宏觀任務(wù)編排與調(diào)度這一層處理的是“球隊?wèi)?zhàn)術(shù)”問題。我們把每個LLM實(shí)例看作一個獨(dú)立的智能體它們共同處理一個復(fù)雜任務(wù)。智能體間并行的目標(biāo)是讓多個智能體能夠同時執(zhí)行各自的任務(wù)分支減少串行等待。2.1.1 常見的協(xié)作模式與并行機(jī)會根據(jù)任務(wù)類型智能體間通常呈現(xiàn)幾種模式對應(yīng)不同的并行策略流水線并行任務(wù)被分解成多個階段每個智能體負(fù)責(zé)一個階段。例如在一個text2jsontext2sql的管道中可能先由“解析智能體”將自然語言轉(zhuǎn)換成結(jié)構(gòu)化的JSON再由“SQL生成智能體”將JSON轉(zhuǎn)換成SQL語句。這兩個智能體的執(zhí)行是串行的但多個用戶請求可以形成流水線——當(dāng)智能體A在處理用戶2的請求時智能體B可以同時處理用戶1的請求。這種并行化發(fā)生在請求級別。任務(wù)并行一個復(fù)雜任務(wù)被拆分成多個獨(dú)立的子任務(wù)由不同的智能體同時處理。例如一個“市場分析報告生成”任務(wù)可以同時派發(fā)給“數(shù)據(jù)收集智能體”、“趨勢分析智能體”和“報告潤色智能體”。這些子任務(wù)完成后結(jié)果再被匯總。這是最理想的并行形式能極大縮短端到端延遲。競爭/投票并行同一個任務(wù)同時發(fā)給多個同質(zhì)或異質(zhì)的智能體例如調(diào)用不同廠商的LLM API取最先返回的結(jié)果或?qū)Χ鄠€結(jié)果進(jìn)行投票/綜合。這主要用于提高可用性或結(jié)果質(zhì)量。2.1.2 調(diào)度器智能體間并行的核心實(shí)現(xiàn)上述并行的關(guān)鍵是一個高效的調(diào)度器。它需要決定任務(wù)分配將子任務(wù)分給哪個哪些空閑的智能體實(shí)例依賴管理任務(wù)B需要任務(wù)A的輸出調(diào)度器必須管理這種依賴關(guān)系在A完成后才觸發(fā)B。負(fù)載均衡確保沒有智能體過載而其他智能體閑置。故障處理某個智能體實(shí)例推理失敗或超時如何重試或切換路由實(shí)操心得調(diào)度器的實(shí)現(xiàn)不必一開始就追求復(fù)雜。我們最初用了一個基于Redis的簡單隊列系統(tǒng)每個智能體作為Worker從指定隊列拉取任務(wù)。依賴關(guān)系通過任務(wù)狀態(tài)機(jī)來管理。雖然簡陋但能快速驗(yàn)證并行架構(gòu)是否有效。后期再逐步引入更復(fù)雜的調(diào)度算法如基于資源預(yù)測的調(diào)度和框架如Apache Airflow for LLMs, 或基于asyncio的自定義調(diào)度器。2.2 智能體內(nèi)并行微觀計算圖優(yōu)化這一層處理的是“球員個人體能訓(xùn)練”問題。當(dāng)任務(wù)分配到一個具體的智能體即一個LLM實(shí)例后我們需要讓這個模型本身的推理速度最快。這就是傳統(tǒng)的LLM推理優(yōu)化領(lǐng)域但在多智能體系統(tǒng)中我們需要有全局視角。2.2.1 模型加載與內(nèi)存共享在多智能體系統(tǒng)中很可能多個智能體使用的是同一個基礎(chǔ)模型例如都基于Llama-3-8B。最 naive 的做法是為每個智能體實(shí)例單獨(dú)加載一份模型權(quán)重這會消耗巨大的顯存。權(quán)重共享通過進(jìn)程間共享內(nèi)存或使用支持多租戶的推理服務(wù)器如vLLM,TGI讓多個智能體實(shí)例共享同一份模型權(quán)重。這能極大減少顯存占用讓你能在單臺服務(wù)器上運(yùn)行更多智能體。動態(tài)加載/卸載對于不常用的智能體對應(yīng)特定功能的微調(diào)模型可以采用動態(tài)加載策略需要時加載到顯存空閑一段時間后卸載回內(nèi)存或磁盤。這需要精細(xì)的生命周期管理。2.2.2 推理引擎的并行化技術(shù)這是加速單個推理請求的核心。現(xiàn)代LLM推理引擎主要利用以下幾種并行計算范式張量并行將模型的權(quán)重矩陣切分到多個GPU上。例如一個大型的FFN層矩陣計算被拆分到2塊GPU上同時進(jìn)行最后合并結(jié)果。這適用于模型單卡放不下的情況。流水線并行將模型的不同層分配到不同的GPU上。一個輸入依次經(jīng)過GPU1層1-10、GPU2層11-20... 多個請求可以在不同GPU上形成流水線提高總體吞吐量。這在智能體使用極大模型時有用。序列并行針對處理超長序列的場景將序列維度進(jìn)行切分分散計算注意力等操作。請求級并行這是吞吐量優(yōu)化的關(guān)鍵即一個推理引擎同時處理多個并發(fā)的請求Continuous Batching或Incremental Batching。當(dāng)智能體A在思考時引擎可以立刻處理智能體B的請求高效填充GPU計算單元。2.2.3 計算與通信的重疊在TP/PP等并行模式下GPU間需要傳輸中間結(jié)果激活值或梯度。通過預(yù)取、異步通信等技術(shù)將通信時間隱藏在計算時間之下可以顯著提升效率。例如在計算當(dāng)前層的正向傳播時可以異步發(fā)送上一層的輸出給下一個GPU。注意事項(xiàng)智能體內(nèi)并行的技術(shù)選型強(qiáng)烈依賴于硬件配置和模型大小。對于8B/13B級別的模型在單張A100/H100上請求級并行Continuous Batching通常是提升吞吐最有效的技術(shù)應(yīng)優(yōu)先考慮。張量并行會引入通信開銷只有在模型太大如70B單卡放不下時收益才明顯。流水線并行則對負(fù)載均衡要求高如果每個請求的序列長度差異大容易導(dǎo)致GPU等待。3. 實(shí)戰(zhàn)構(gòu)建一個延遲與性能感知的多智能體服務(wù)系統(tǒng)理論講完了我們來點(diǎn)實(shí)際的。假設(shè)我們要構(gòu)建一個類似chimera理念的系統(tǒng)即能感知延遲和性能服務(wù)異構(gòu)LLM的多智能體系統(tǒng)用于處理復(fù)雜的多步驟查詢?nèi)蝿?wù)。3.1 系統(tǒng)組件設(shè)計我們的系統(tǒng)主要包含以下組件網(wǎng)關(guān)/入口接收用戶請求進(jìn)行初步解析和認(rèn)證。編排器Orchestrator這是大腦負(fù)責(zé)解析復(fù)雜任務(wù)將其分解為子任務(wù)并管理任務(wù)流DAG。調(diào)度器Scheduler接收編排器產(chǎn)生的子任務(wù)根據(jù)當(dāng)前各推理后端的負(fù)載、任務(wù)優(yōu)先級、資源約束將任務(wù)分派到合適的智能體。智能體池Agent Pool由多個智能體執(zhí)行器組成。每個執(zhí)行器封裝了一個LLM的調(diào)用能力可能是本地模型也可能是API。執(zhí)行器向調(diào)度器注冊自己的能力如“SQL生成”、“文本總結(jié)”。推理后端集群可以是多個vLLM或TGI實(shí)例每個實(shí)例托管一個或多個模型提供高性能的推理API。共享狀態(tài)存儲如Redis用于存儲任務(wù)狀態(tài)、中間結(jié)果、智能體對話歷史等方便不同組件間協(xié)作。3.2 關(guān)鍵配置與實(shí)現(xiàn)步驟步驟1定義智能體與任務(wù)流我們以“智能數(shù)據(jù)分析助手”為例它需要完成用戶問題 - 問題分類 - 數(shù)據(jù)查詢(SQL生成) - 執(zhí)行查詢 - 結(jié)果分析 - 生成報告。 我們可以設(shè)計三個智能體Classifier_Agent: 負(fù)責(zé)問題分類和任務(wù)分解。SQL_Expert_Agent: 負(fù)責(zé)生成精準(zhǔn)的SQL。Analyst_Agent: 負(fù)責(zé)執(zhí)行查詢或調(diào)用工具并分析結(jié)果生成報告。任務(wù)流是一個DAG[用戶輸入] - (Classifier) - (SQL_Expert) - (DB Tool) - (Analyst) - [報告]。其中(DB Tool)可能是一個同步調(diào)用會阻塞因此需要考慮超時和異步化。步驟2實(shí)現(xiàn)基于異步消息的調(diào)度我們使用asyncio和消息隊列如RabbitMQ或Redis Stream來實(shí)現(xiàn)松耦合的調(diào)度。# 簡化示例 - 調(diào)度器核心邏輯 import asyncio import json from typing import Dict import aioredis class AgentScheduler: def __init__(self): self.redis aioredis.from_url(redis://localhost) # 智能體能力到隊列的映射 self.agent_queues { classification: queue:classifier, sql_generation: queue:sql_expert, analysis: queue:analyst } # 任務(wù)狀態(tài)跟蹤 self.task_registry {} async def dispatch(self, task_id: str, task_type: str, input_data: dict): 將任務(wù)分發(fā)到對應(yīng)隊列 target_queue self.agent_queues.get(task_type) if not target_queue: raise ValueError(fNo agent for task type: {task_type}) task_message { task_id: task_id, input: input_data } # 將任務(wù)發(fā)布到消息隊列 await self.redis.rpush(target_queue, json.dumps(task_message)) # 更新任務(wù)狀態(tài)為“已排隊” await self.redis.hset(ftask:{task_id}, status, queued) async def process_task_dag(self, user_input: str): 處理一個完整的DAG任務(wù) import uuid main_task_id str(uuid.uuid4()) # 1. 創(chuàng)建分類任務(wù) classify_task_id f{main_task_id}_step1 await self.dispatch(classify_task_id, classification, {query: user_input}) # 2. 等待分類結(jié)果這里簡化實(shí)際應(yīng)用更復(fù)雜的DAG引擎 # ... 通過訂閱Redis頻道或輪詢獲取結(jié)果 # 3. 根據(jù)分類結(jié)果觸發(fā)后續(xù)的SQL生成、分析等任務(wù) # ...步驟3配置高性能推理后端為每個智能體類型配置對應(yīng)的推理后端。例如SQL_Expert_Agent對準(zhǔn)確性要求高可以使用CodeLlama-34B模型部署在4張GPU上使用張量并行。Analyst_Agent對速度更敏感可以使用Llama-3-8B-Instruct模型部署在單卡上但開啟vLLM的連續(xù)批處理以提升吞吐。vLLM的啟動配置示例# 啟動一個支持連續(xù)批處理和權(quán)重共享的推理服務(wù)器 python -m vllm.entrypoints.api_server \ --model codellama/CodeLlama-34b-Instruct-hf \ --tensor-parallel-size 4 \ --gpu-memory-utilization 0.9 \ --max-num-batched-tokens 4096 \ --served-model-name sql_expert步驟4實(shí)現(xiàn)智能體執(zhí)行器智能體執(zhí)行器是“工人”從自己的任務(wù)隊列中拉取任務(wù)調(diào)用對應(yīng)的推理后端API然后將結(jié)果寫回狀態(tài)存儲。# 簡化示例 - 智能體執(zhí)行器 class AgentExecutor: def __init__(self, agent_name: str, queue_name: str, api_endpoint: str): self.agent_name agent_name self.queue_name queue_name self.api_endpoint api_endpoint self.redis aioredis.from_url(redis://localhost) async def run(self): 持續(xù)從隊列拉取并執(zhí)行任務(wù) while True: # 阻塞式彈出任務(wù) _, message_json await self.redis.blpop(self.queue_name) task_msg json.loads(message_json) task_id task_msg[task_id] input_data task_msg[input] # 更新狀態(tài)為“處理中” await self.redis.hset(ftask:{task_id}, status, processing) try: # 調(diào)用LLM推理后端 result await self.call_llm_api(input_data) # 存儲結(jié)果 await self.redis.hset(ftask:{task_id}, status, done, result, json.dumps(result)) # 可能觸發(fā)下游任務(wù)通過發(fā)布事件 await self.redis.publish(ftask_done:{task_id}, success) except Exception as e: await self.redis.hset(ftask:{task_id}, status, failed, error, str(e)) async def call_llm_api(self, input_data: dict): # 調(diào)用vLLM或TGI的API import aiohttp async with aiohttp.ClientSession() as session: payload { prompt: self._construct_prompt(input_data), max_tokens: 512, temperature: 0.1 } async with session.post(f{self.api_endpoint}/generate, jsonpayload) as resp: response await resp.json() return response[text][0]3.3 性能調(diào)優(yōu)與監(jiān)控系統(tǒng)跑起來后監(jiān)控和調(diào)優(yōu)是關(guān)鍵。關(guān)鍵指標(biāo)監(jiān)控智能體間任務(wù)隊列長度、調(diào)度延遲任務(wù)產(chǎn)生到開始執(zhí)行的耗時、各智能體利用率。智能體內(nèi)推理后端P99/P95延遲、每秒處理令牌數(shù)、GPU利用率、連續(xù)批處理的批次大小。全局端到端請求延遲、每秒查詢數(shù)。動態(tài)調(diào)優(yōu)策略彈性伸縮根據(jù)隊列長度動態(tài)增加或減少某個智能體執(zhí)行器的實(shí)例數(shù)Kubernetes HPA。負(fù)載感知路由調(diào)度器在分發(fā)任務(wù)時不僅看能力匹配還看目標(biāo)推理后端的當(dāng)前負(fù)載正在處理的請求數(shù)、GPU內(nèi)存使用率選擇最空閑的后端。批處理大小自適應(yīng)推理后端可以根據(jù)請求的緊急程度是否有低延遲SLA動態(tài)調(diào)整批處理策略。高優(yōu)先級請求可以插隊或使用更小的批次。4. 常見陷阱與性能瓶頸排查實(shí)錄在多智能體LLM系統(tǒng)中性能問題往往不是由單一原因引起的而是多個層面因素交織的結(jié)果。下面是我們踩過的一些坑和對應(yīng)的排查思路。4.1 智能體間通信成為瓶頸現(xiàn)象整體吞吐量上不去GPU利用率很低但觀察發(fā)現(xiàn)任務(wù)在“排隊”或“等待結(jié)果”狀態(tài)的時間很長。排查與解決檢查消息隊列Redis或RabbitMQ是否成為瓶頸使用redis-cli --latency檢查Redis延遲。如果隊列操作rpush/blpop耗時超過幾毫秒就需要考慮分片、升級實(shí)例或換用性能更高的中間件如基于Raft的內(nèi)存存儲。序列化開銷智能體間傳遞的中間結(jié)果可能是大段的文本或復(fù)雜的JSON序列化/反序列化開銷巨大。我們曾遇到一個案例一個分析結(jié)果包含大量數(shù)據(jù)點(diǎn)JSON字符串長達(dá)1MB頻繁的序列化操作吃掉了大量CPU。解決方案對于大的中間結(jié)果考慮使用二進(jìn)制格式如MessagePack、Protocol Buffers或者將其存儲在共享內(nèi)存/對象存儲如S3/MinIO中只傳遞一個引用指針。同步調(diào)用阻塞在異步框架中混入了同步的HTTP調(diào)用或數(shù)據(jù)庫查詢導(dǎo)致整個事件循環(huán)被阻塞。務(wù)必使用異步客戶端如aiohttp,asyncpg。4.2 智能體內(nèi)推理延遲不穩(wěn)定現(xiàn)象同一個智能體處理相似任務(wù)延遲波動很大時快時慢。排查與解決檢查連續(xù)批處理這是最常見的原因。推理引擎如vLLM的連續(xù)批處理為了效率會等待極短時間以合并多個請求。如果當(dāng)前請求恰好是批次中的第一個它需要等待調(diào)度周期延遲就會增加。調(diào)整參數(shù)可以調(diào)整vLLM的max_num_batched_tokens或調(diào)度策略在延遲和吞吐之間做權(quán)衡。對于延遲敏感型智能體可以考慮分配專屬的、批處理大小設(shè)為1的推理實(shí)例。GPU內(nèi)存競爭如果多個智能體共享同一個GPU上的不同模型可能會因?yàn)轱@存碎片或cudaMalloc競爭導(dǎo)致延遲抖動。使用nvidia-smi監(jiān)控顯存使用情況。解決方案為延遲敏感的模型預(yù)留顯存或使用CUDA_MALLOC_CONF環(huán)境變量調(diào)整分配策略。冷啟動影響如果使用了動態(tài)加載模型第一次推理的延遲會包含模型加載時間。需要做好預(yù)熱或者在系統(tǒng)低峰期預(yù)加載常用模型。4.3 資源死鎖與饑餓現(xiàn)象系統(tǒng)運(yùn)行一段時間后完全卡住任務(wù)不再被處理。排查與解決依賴死鎖任務(wù)A等待任務(wù)B的結(jié)果任務(wù)B又間接等待任務(wù)A形成環(huán)路。這需要在編排器層面對任務(wù)DAG進(jìn)行環(huán)路檢測。心得在定義任務(wù)流時強(qiáng)制使用有向無環(huán)圖DAG并使用像Airflow或Prefect這樣的成熟編排器它們內(nèi)置了環(huán)路檢測。資源饑餓某個智能體類型任務(wù)堆積耗盡了所有線程池或數(shù)據(jù)庫連接導(dǎo)致其他智能體無法工作。實(shí)施資源配額為每個智能體池設(shè)置最大的并發(fā)任務(wù)數(shù)并使用像asyncio.Semaphore這樣的信號量進(jìn)行控制。推理后端過載所有請求都路由到同一個負(fù)載過高的推理實(shí)例。實(shí)施熔斷與降級監(jiān)控推理后端的健康狀態(tài)和延遲如果連續(xù)失敗或延遲過高調(diào)度器應(yīng)暫時將其標(biāo)記為不健康并將流量切換到其他實(shí)例。4.4 異構(gòu)模型帶來的挑戰(zhàn)現(xiàn)象系統(tǒng)中有的模型是70B的大模型有的是7B的小模型調(diào)度和資源分配困難。解決思路分級調(diào)度調(diào)度器需要知道每個智能體背后模型的“重量級”。可以將智能體分為“重型”大模型和“輕型”小模型。調(diào)度時優(yōu)先將重型任務(wù)分配到有空閑重型資源的節(jié)點(diǎn)避免輕型任務(wù)占用重型資源導(dǎo)致浪費(fèi)。差異化部署重型模型部署在A100/H100集群使用TP/PP。輕型模型可以部署在消費(fèi)級GPU甚至CPU通過優(yōu)化如llama.cpp集群。調(diào)度器需要感知不同后端的處理能力tokens/sec和成本。預(yù)算感知調(diào)度對于按token計費(fèi)的API模型如GPT-4調(diào)度器在分配任務(wù)時還需要考慮成本約束在性能、成本和準(zhǔn)確性之間做出權(quán)衡。構(gòu)建一個高效的多智能體LLM系統(tǒng)遠(yuǎn)不止是調(diào)幾個API那么簡單。它要求我們從系統(tǒng)架構(gòu)的層面同時審視宏觀的智能體協(xié)作流和微觀的模型計算圖。兩層并行的視角幫助我們將這個復(fù)雜問題模塊化逐層擊破。從設(shè)計一個解耦的、基于消息的異步架構(gòu)開始到為每個智能體選擇并優(yōu)化合適的推理后端再到建立全面的監(jiān)控和動態(tài)調(diào)優(yōu)機(jī)制每一步都需要結(jié)合具體的業(yè)務(wù)場景和資源約束來做決策。沒有銀彈最好的系統(tǒng)永遠(yuǎn)是那個最能理解自身負(fù)載特征并能持續(xù)演進(jìn)的系統(tǒng)。