1. 從“請求排隊”到“會話調(diào)度”為什么我們需要重新思考LLM Agent的調(diào)度最近在折騰一個基于大語言模型的多智能體協(xié)作系統(tǒng)時我遇到了一個非常典型且棘手的問題。系統(tǒng)里有十幾個不同類型的Agent有的負責調(diào)用API獲取數(shù)據(jù)有的負責分析有的負責生成報告。當多個用戶同時發(fā)起請求每個請求又需要多個Agent協(xié)同工作時整個系統(tǒng)的響應速度變得極不穩(wěn)定。有時一個簡單的查詢秒回有時一個復雜任務卻要等上幾十秒甚至出現(xiàn)某些Agent“餓死”長時間得不到執(zhí)行資源而另一些Agent“撐死”資源被過度占用的情況。這讓我開始重新審視我們通常為LLM服務設(shè)計的調(diào)度策略。傳統(tǒng)的思路無論是基于請求隊列Request Queue還是簡單的輪詢Round-Robin本質(zhì)上都是“任務中心”的。它們把每個LLM調(diào)用看作一個獨立的、原子性的任務調(diào)度器的工作就是盡可能公平、高效地把這些任務分配給可用的計算資源比如GPU實例。這在處理大量獨立的、短小的文本生成或問答請求時效果還不錯。然而當LLM作為智能體Agent的大腦時游戲規(guī)則變了。一個Agent的生命周期不再是一次性的“輸入-輸出”而是一個持續(xù)的“會話”Session。在這個會話中Agent會與環(huán)境用戶、工具、其他Agent進行多輪交互維護著上下文記憶并根據(jù)歷史對話和工具執(zhí)行結(jié)果來決定下一步行動。例如一個數(shù)據(jù)分析Agent的會話可能包括理解用戶問題 - 規(guī)劃查詢步驟 - 調(diào)用SQL工具 - 解讀查詢結(jié)果 - 生成可視化建議。這其中的每一步都可能需要調(diào)用LLM但這些調(diào)用不是孤立的它們共享同一個會話狀態(tài)上下文、記憶、目標。如果我們還用傳統(tǒng)的“任務中心”調(diào)度來處理這些LLM調(diào)用就會產(chǎn)生幾個核心矛盾會話連續(xù)性被破壞調(diào)度器可能把同一個會話中的連續(xù)兩次LLM調(diào)用分配到了兩個不同的GPU實例上。雖然模型參數(shù)相同但會話的上下文即對話歷史可能沒有及時同步或傳遞導致Agent“失憶”做出前后矛盾的決策。資源競爭失焦一個需要多步復雜推理的會話比如代碼調(diào)試和一個只需要單步簡單回復的會話比如天氣查詢在“任務中心”調(diào)度下被平等對待。每個LLM調(diào)用都占一個“坑位”復雜會話長時間占用資源阻塞了大量簡單會話整體用戶體驗的“公平性”很差。用戶感知的是整個會話的完成時間而不是其中某一次LLM調(diào)用的延遲。Agent狀態(tài)管理混亂Agent的內(nèi)部狀態(tài)如已執(zhí)行的動作、工具調(diào)用結(jié)果、臨時結(jié)論需要在多次LLM調(diào)用間保持。分散的調(diào)度使得狀態(tài)同步成為巨大的開銷要么引入復雜的分布式狀態(tài)管理要么忍受性能損耗。這正是論文《SMetric: Rethink LLM Scheduling for Serving Agents with Balanced Session-centric Scheduling》所瞄準的核心問題。它提出為Agent服務的LLM調(diào)度其基本單位不應該是獨立的“請求”Request而應該是完整的“會話”Session。調(diào)度器需要以會話為視角去平衡資源、保障體驗。而“SMetric”就是其提出的一個用于量化會話資源需求與優(yōu)先級的關(guān)鍵度量指標。簡單說它不再問“下一個LLM任務該給誰”而是問“為了最優(yōu)的整體會話體驗下一個該服務哪個會話以及該給它多少資源”2. 拆解“以會話為中心”調(diào)度核心挑戰(zhàn)與設(shè)計原則將調(diào)度粒度從“請求”提升到“會話”聽起來很直觀但具體落地面臨一系列設(shè)計上的挑戰(zhàn)。這不僅僅是換個調(diào)度隊列那么簡單它涉及到如何定義、衡量和優(yōu)化一個全新的調(diào)度目標。2.1 傳統(tǒng)調(diào)度為何在Agent場景“失靈”我們首先需要明確傳統(tǒng)調(diào)度策略在Agent服務中的局限性先進先出FIFO一個包含10次LLM調(diào)用的復雜會話排在隊首后面所有會話哪怕是僅需1次調(diào)用的簡單會話都必須等待它完全執(zhí)行完畢。這導致了極高的尾部延遲簡單會話的用戶體驗極差。最短作業(yè)優(yōu)先SJF理想很豐滿現(xiàn)實很骨感。在LLM Agent場景下我們很難在任務LLM調(diào)用入隊時就準確預測其執(zhí)行時間Token生成數(shù)量、思維鏈長度未知。更關(guān)鍵的是即使能預測單次調(diào)用時間也無法代表整個會話的復雜度。一個會話可能第一次調(diào)用很簡短接收指令但后續(xù)調(diào)用非常耗時執(zhí)行復雜規(guī)劃。輪詢Round-Robin在各個會話間公平地分配單次LLM調(diào)用機會。這看似公平但實際上對復雜會話是致命的。因為它把一個連貫的、有狀態(tài)的推理過程切割成碎片穿插在其他會話中執(zhí)行。這極大地增加了會話內(nèi)上下文切換的開銷每次都需要重新加載長篇上下文并且由于執(zhí)行過程被頻繁打斷Agent的“思考”連貫性受損可能導致規(guī)劃錯誤或效率低下。基于優(yōu)先級的調(diào)度這需要為每個會話或請求賦予一個優(yōu)先級。但優(yōu)先級依據(jù)什么用戶等級付費情況這些是業(yè)務邏輯不能完全解決資源效率問題。我們需要一個能反映會話本身資源需求和緊急度的、更內(nèi)蘊的度量標準。問題的根源在于這些策略的優(yōu)化目標與最終用戶體驗是錯配的。用戶不關(guān)心單次LLM調(diào)用的延遲他們關(guān)心的是從提出問題到獲得最終答案的會話完成時間以及會話交互過程中的響應流暢度。因此新的調(diào)度器必須直接將會話完成時間或類似指標作為優(yōu)化目標。2.2 “以會話為中心”調(diào)度的四大設(shè)計原則基于以上分析一個合理的“以會話為中心”的調(diào)度器設(shè)計應遵循以下原則會話完整性優(yōu)先在可能的情況下盡量讓一個會話的連續(xù)多次LLM調(diào)用在同一個計算實例上連續(xù)執(zhí)行或者至少保證其上下文和狀態(tài)能夠被高效、低延遲地傳遞。這減少了上下文加載開銷保障了Agent推理的連貫性。差異化資源分配認識到不同會話的“重量”不同。一個旨在生成一篇長文的創(chuàng)作Agent會話和一個僅進行事實核查的會話對計算資源總Token處理量、所需時間的需求有數(shù)量級差異。調(diào)度器應能感知這種差異并進行差異化的資源分配。平衡吞吐量與公平性目標不是單純追求系統(tǒng)總吞吐量每秒處理的Token數(shù)也不是機械的絕對公平。而是要在保證系統(tǒng)整體效率的同時優(yōu)化一個能反映所有用戶體驗的聚合指標例如會話完成時間的百分位數(shù)如P99或者更復雜的基于會話權(quán)重的公平性指標。可預測性與適應性調(diào)度決策最好能基于對會話未來資源需求的預測。同時系統(tǒng)需要能適應動態(tài)變化新會話的加入、現(xiàn)有會話因用戶交互而產(chǎn)生的路徑分支Agent決策不同后續(xù)步驟數(shù)可能變化?！癝Metric”正是在這些原則下被設(shè)計出來用于量化會話特性、指導調(diào)度決策的那個核心“標尺”。它需要將會話的多個維度如已消耗資源、預估剩余資源、等待時間、優(yōu)先級權(quán)重等壓縮成一個可比較的單一數(shù)值或向量供調(diào)度器使用。3. SMetric深度解析如何量化一個會話的“調(diào)度價值”SMetricSession Metric是整個調(diào)度策略的大腦。它的設(shè)計好壞直接決定了調(diào)度器的性能。論文中提出的SMetric是一個綜合函數(shù)它通常會考慮以下幾個關(guān)鍵因子S f(已執(zhí)行成本 預估剩余成本 等待時間 會話優(yōu)先級 ...)讓我們逐一拆解3.1 已執(zhí)行成本Consumed Cost這代表會話已經(jīng)占用了多少系統(tǒng)資源。最簡單的度量是會話歷史中所有LLM調(diào)用生成的總Token數(shù)包括輸入和輸出。更精細的版本可能還會考慮使用的GPU時間、內(nèi)存占用等。記錄已執(zhí)行成本有兩個作用防止饑餓一個已經(jīng)消耗了大量資源的會話不應該被無限期地推遲否則可能永遠無法完成。作為公平性的參考在考慮資源分配時已經(jīng)消耗多的會話或許應該略微讓位于消耗少的會話以實現(xiàn)某種程度的公平。3.2 預估剩余成本Estimated Remaining Cost這是SMetric中最具挑戰(zhàn)性也最關(guān)鍵的部分。我們需要預測一個會話還需要多少資源才能完成。對于LLM Agent會話這本質(zhì)上是預測會話的“剩余步數(shù)”以及“每步的平均開銷”。預測方法可以包括基于會話類型的啟發(fā)式規(guī)則如果是“代碼生成”類Agent其會話通常比“天氣查詢”類需要更多步數(shù)和更長的生成內(nèi)容。可以為不同類型的Agent設(shè)置不同的經(jīng)驗系數(shù)?；跉v史數(shù)據(jù)的統(tǒng)計模型收集同類Agent會話的歷史數(shù)據(jù)計算其平均步數(shù)和平均每步Token數(shù)作為預測值。在線學習與動態(tài)調(diào)整在會話運行過程中根據(jù)已執(zhí)行步驟的模式例如Agent是否頻繁調(diào)用搜索工具生成的內(nèi)容是否越來越長動態(tài)調(diào)整剩余成本的預測。保守預測與樂觀調(diào)度一種實用策略是采用保守預測高估剩余成本這樣調(diào)度器會更傾向于先完成那些“看似剩余工作少”的會話從而快速釋放資源降低簡單會話的延遲。這類似于操作系統(tǒng)中的“短作業(yè)優(yōu)先”思想但應用在會話粒度。3.3 等待時間Waiting Time即會話自進入系統(tǒng)或自上次被調(diào)度后已經(jīng)等待了多久。引入等待時間是為了保證響應性防止任何會話被無限期擱置。即使一個會話預估剩余成本很高如果它等待了太長時間其SMetric值也應該增長從而獲得被調(diào)度的機會。這通常通過一個隨時間增長的函數(shù)如線性增長、平方增長來實現(xiàn)。3.4 會話優(yōu)先級Session Priority這是一個由業(yè)務邏輯決定的外部因子。例如VIP用戶的會話、高付費等級的會話、或來自關(guān)鍵業(yè)務線的會話可以被賦予更高的優(yōu)先級權(quán)重。這個權(quán)重會乘數(shù)或加數(shù)地影響最終的SMetric值。3.5 SMetric的計算與調(diào)度策略一個簡單的SMetric公式示例可以是SMetric(session) (等待時間 * α) / (預估剩余成本 * β) 已執(zhí)行成本 * γ 優(yōu)先級權(quán)重其中α, β, γ是可調(diào)節(jié)的超參數(shù)。等待時間/預估剩余成本這部分賦予了“短剩余作業(yè)”更高的優(yōu)先級類似于歸一化的最短剩余時間優(yōu)先SRTF。已執(zhí)行成本用于防止長會話饑餓。優(yōu)先級權(quán)重體現(xiàn)業(yè)務差異。調(diào)度器的工作周期例如每100毫秒內(nèi)它會計算所有活躍會話的SMetric值然后選擇值最高或最低取決于公式定義的會話為其分配下一次LLM調(diào)度的機會。如果系統(tǒng)支持會話在GPU間的遷移調(diào)度器還可能決定是否將會話轉(zhuǎn)移到更合適的計算節(jié)點上。注意SMetric的具體公式?jīng)]有銀彈需要根據(jù)實際業(yè)務負載進行反復調(diào)優(yōu)。線上系統(tǒng)通常需要實現(xiàn)SMetric的A/B測試框架對比不同公式下核心業(yè)務指標如會話P99延遲、會話超時率、系統(tǒng)吞吐量的變化。4. 從理論到實踐構(gòu)建平衡的會話中心調(diào)度系統(tǒng)理解了SMetric的原理后我們來探討如何將其嵌入一個實際的LLM Agent服務系統(tǒng)中。這不僅僅是一個調(diào)度算法更是一套系統(tǒng)架構(gòu)設(shè)計。4.1 系統(tǒng)架構(gòu)組件一個典型的實現(xiàn)可能包含以下組件會話管理器Session Manager負責會話的生命周期管理。為每個用戶請求創(chuàng)建唯一的會話ID維護會話狀態(tài)上下文歷史、Agent內(nèi)部狀態(tài)、工具調(diào)用記錄等。它需要與一個低延遲的存儲后端如Redis集成以持久化狀態(tài)。資源預測器Resource Predictor實現(xiàn)上文提到的“預估剩余成本”模塊。它可以是一個輕量級模型也可以是一組規(guī)則引擎。輸入是會話的元信息Agent類型、已執(zhí)行步驟模式、當前狀態(tài)輸出是對剩余Token數(shù)或計算時間的預測。SMetric計算器SMetric Calculator根據(jù)預定義的公式實時計算每個活躍會話的SMetric值。它需要從會話管理器獲取“已執(zhí)行成本”和“等待時間”從資源預測器獲取“預估剩余成本”從業(yè)務系統(tǒng)獲取“優(yōu)先級權(quán)重”。調(diào)度器Scheduler核心決策組件。它維護一個優(yōu)先隊列通常基于SMetric值。定期或事件驅(qū)動從隊列中取出SMetric最高的會話檢查其狀態(tài)然后向執(zhí)行器發(fā)送指令執(zhí)行該會話的下一個待辦LLM調(diào)用或工具調(diào)用。執(zhí)行器Executor負責實際執(zhí)行LLM調(diào)用。它從調(diào)度器接收任務加載對應的會話上下文可能通過會話管理器獲取調(diào)用LLM API如本地部署的模型或云端API并將結(jié)果返回給會話管理器更新狀態(tài)同時將“本次執(zhí)行成本”反饋給SMetric計算器。[用戶請求] - 會話管理器 (創(chuàng)建/更新會話) | v 會話狀態(tài) 元信息 | |---------------------------------------| v v 資源預測器 ------------------------- SMetric計算器 --- 優(yōu)先級服務 (預估剩余成本) (計算SMetric值) | | |---------------------------------------| v 調(diào)度器 (基于SMetric的優(yōu)先隊列) | v 執(zhí)行器 (執(zhí)行LLM調(diào)用) | v 更新會話狀態(tài) 反饋執(zhí)行成本4.2 關(guān)鍵實現(xiàn)細節(jié)與踩坑點在實際編碼和部署中有幾個細節(jié)需要特別注意狀態(tài)同步與一致性當多個調(diào)度器或執(zhí)行器實例分布式部署時會話狀態(tài)的更新會成為瓶頸。必須保證一個會話在同一時間只有一個執(zhí)行器在處理否則會導致狀態(tài)混亂。通常需要使用分布式鎖如基于Redis的鎖來保護會話狀態(tài)。預測不準的應對資源預測不可能100%準確。系統(tǒng)必須能容忍預測誤差。策略包括定期重預測在會話每完成幾步后重新運行預測模型根據(jù)最新信息調(diào)整預估剩余成本。設(shè)置上限與超時為每個會話設(shè)置最大資源消耗上限或最大執(zhí)行時長防止因預測嚴重偏差導致“僵尸會話”無限占用資源。采用衰減預測隨著會話執(zhí)行逐漸降低“預估剩余成本”的權(quán)重提高“已執(zhí)行成本”和“等待時間”的權(quán)重讓長時間運行的會話也能有機會被調(diào)度。冷啟動問題一個新會話剛創(chuàng)建時“已執(zhí)行成本”為0“預估剩余成本”可能也不準。如何給它一個合理的初始SMetric值使其不至于永遠排不上隊一個常見做法是給新會話一個“啟動加成”或者使用一個基于會話類型的默認預估成本。與底層推理引擎的協(xié)同如果你的LLM推理引擎本身支持連續(xù)批處理Continuous Batching那么調(diào)度器在分配“下一次LLM調(diào)用”時實際上是在決定將哪個會話的prompt加入下一個推理批。這時SMetric調(diào)度需要和批處理調(diào)度策略如是否優(yōu)先填充批次進行協(xié)同目標是最小化會話級延遲而非批次級吞吐。4.3 一個簡化的代碼示例概念層面以下是用偽代碼展示的核心調(diào)度循環(huán)邏輯class SessionCentricScheduler: def __init__(self, session_manager, predictor): self.session_manager session_manager self.predictor predictor self.priority_queue PriorityQueue() # 按SMetric排序 def calculate_smetric(self, session): consumed_cost session.get_consumed_tokens() waiting_time time.now() - session.last_scheduled_time estimated_remaining_cost self.predictor.predict(session) priority session.get_priority() # 一個示例公式鼓勵短剩余作業(yè)防止長等待考慮優(yōu)先級 smetric (waiting_time * 1.0) / (estimated_remaining_cost 1e-5) \ - consumed_cost * 0.01 \ priority * 10.0 return smetric def scheduling_loop(self): while True: # 1. 更新所有活躍會話的SMetric active_sessions self.session_manager.get_active_sessions() for session in active_sessions: new_smetric self.calculate_smetric(session) self.priority_queue.update(session.id, new_smetric) # 2. 取出SMetric最高的會話進行調(diào)度 if not self.priority_queue.empty(): session_id_to_run self.priority_queue.pop() session self.session_manager.get(session_id_to_run) # 3. 獲取該會話下一個待執(zhí)行的動作LLM調(diào)用或工具調(diào)用 next_action session.get_next_action() if next_action: # 4. 提交給執(zhí)行器 executor.submit(session.id, next_action) # 5. 更新會話的“最后調(diào)度時間” session.update_last_scheduled_time() time.sleep(SCHEDULING_INTERVAL) # 調(diào)度間隔如50ms5. 效果評估與權(quán)衡SMetric調(diào)度帶來了什么引入SMetric和以會話為中心的調(diào)度后我們需要一套評估體系來衡量其效果并理解其帶來的權(quán)衡。5.1 核心評估指標會話完成時間分布這是最重要的指標。關(guān)注P50中位數(shù)、P90、P99尾部延遲。一個好的調(diào)度策略應該能顯著降低P99延遲即改善最差用戶體驗同時保持P50延遲可接受。會話超時率在設(shè)定會話最大時長限制下有多少比例會話因超時失敗。系統(tǒng)吞吐量單位時間內(nèi)系統(tǒng)成功完成的會話數(shù)量。需要注意的是在資源固定的情況下優(yōu)化延遲尤其是尾部延遲有時會輕微犧牲吞吐量這是一個需要權(quán)衡的點。公平性指數(shù)例如可以計算所有會話的“已執(zhí)行成本/總會話成本”的方差方差越小說明資源分配越公平。或者使用Jain‘s Fairness Index等指標。資源利用率GPU的平均使用率。調(diào)度策略應避免資源空閑但也要避免過度擁擠導致排隊延遲激增。5.2 與基線策略的對比我們可以將SMetric調(diào)度與幾種基線策略在模擬或真實流量下進行對比調(diào)度策略平均會話完成時間P99會話完成時間系統(tǒng)吞吐量公平性適合場景FIFO (先進先出)中等極差中等順序公平負載極低或所有會話成本相似Round-Robin (輪詢)較差較差較高時間片公平會話短且無狀態(tài)不關(guān)心連續(xù)性Shortest-Job-First (SJF)最優(yōu)好低對短作業(yè)友好需精確預知作業(yè)長度LLM場景不現(xiàn)實SMetric-Based (本文)好最優(yōu)中等偏上可配置的平衡Agent服務混合長短會話強調(diào)體驗平衡從上表可以看出SMetric策略的核心優(yōu)勢在于它通過預估和平衡在不依賴精確先知的前提下取得了接近SJF的理想效果優(yōu)秀的尾部延遲同時保持了較好的吞吐量和可調(diào)控的公平性。5.3 實踐中的權(quán)衡與調(diào)優(yōu)沒有任何調(diào)度策略是完美的SMetric亦然預測準確性 vs 調(diào)度效果預測越準調(diào)度效果越好。但構(gòu)建高精度預測模型本身有成本。實踐中往往一個簡單的、基于會話類型的啟發(fā)式規(guī)則就能帶來80%的收益。調(diào)度開銷 vs 收益頻繁計算SMetric和重新排序隊列本身消耗CPU。需要設(shè)置合理的調(diào)度間隔例如50-100ms在調(diào)度精度和開銷間取得平衡?！伴L會話”的體驗為了優(yōu)化整體P99延遲SMetric策略可能會適度“拖延”非常長的會話。這需要業(yè)務方接受或者通過“優(yōu)先級權(quán)重”為重要長會話提供保障。參數(shù)調(diào)優(yōu)的復雜性SMetric公式中的權(quán)重參數(shù)α, β, γ需要針對具體的業(yè)務負載進行調(diào)優(yōu)。這可能是一個持續(xù)的過程建議建立自動化實驗平臺進行線上A/B測試。在我自己的系統(tǒng)中從簡單的FIFO隊列切換到基于SMetric的調(diào)度后最直觀的感受是用戶投訴“卡頓”、“響應慢”的數(shù)量大幅下降。雖然整體平均響應時間沒有翻天覆地的變化但那些“倒霉”的、被復雜任務堵在后面的簡單查詢現(xiàn)在能得到及時的處理了。系統(tǒng)給人的感覺從“時快時慢看運氣”變成了“穩(wěn)定可預期”。6. 進階思考SMetric的擴展與未來方向以會話為中心的調(diào)度和SMetric是一個強大的范式但其應用不止于基礎(chǔ)的LLM調(diào)用調(diào)度。6.1 擴展到多資源調(diào)度目前的討論主要圍繞計算資源GPU/TPU時間。但在實際Agent系統(tǒng)中資源是多元的外部API調(diào)用配額很多Agent需要調(diào)用搜索、數(shù)據(jù)庫、支付等外部API這些接口常有速率限制。內(nèi)存帶寬處理極長上下文如128K Token的會話對內(nèi)存帶寬壓力巨大。I/O等待Agent在等待工具調(diào)用結(jié)果時處于I/O阻塞狀態(tài)。一個更高級的SMetric可以是一個多維向量分別表征會話對各類資源的需求和消耗。調(diào)度器則成為一個多維資源調(diào)度器在滿足多種資源約束的前提下優(yōu)化全局目標。這大大增加了問題的復雜性但也是生產(chǎn)系統(tǒng)必須面對的。6.2 與Agent推理框架的深度集成現(xiàn)有的LangChain、LlamaIndex等Agent框架主要關(guān)注于單個Agent的推理邏輯編排。它們?nèi)狈Χ鄷?、系統(tǒng)級資源調(diào)度的考量。未來的框架或許會將“調(diào)度感知”作為一等公民Agent聲明資源需求在定義Agent時可以為其不同步驟如“規(guī)劃”、“執(zhí)行”、“反思”聲明典型的資源需求模式?？蚣芴峁┱{(diào)度鉤子框架在即將執(zhí)行一個耗時的LLM調(diào)用或工具調(diào)用前會詢問調(diào)度器“現(xiàn)在可以執(zhí)行嗎還是需要讓位”。這允許更細粒度的、基于步驟的調(diào)度。支持會話掛起與恢復為了更靈活的調(diào)度框架需要支持將會話狀態(tài)包括復雜的思維鏈中間狀態(tài)序列化并暫存稍后在另一個實例上恢復執(zhí)行。6.3 基于強化學習的自適應調(diào)度SMetric公式中的權(quán)重參數(shù)調(diào)優(yōu)是個麻煩事。一個更智能的方向是使用強化學習RL來訓練調(diào)度器。我們將調(diào)度系統(tǒng)建模為一個RL環(huán)境狀態(tài)State當前所有活躍會話的特征SMetric的各分量。動作Action選擇下一個要調(diào)度的會話。獎勵Reward根據(jù)后續(xù)一段時間內(nèi)系統(tǒng)指標的變化如P99延遲的降低、吞吐量的提升來計算。讓RL智能體去學習在復雜、動態(tài)的負載下如何做出最佳的調(diào)度決策以最大化長期獎勵。這可以自動找到最優(yōu)的SMetric形式甚至超越固定公式的局限。從“請求”到“會話”的調(diào)度視角轉(zhuǎn)變是LLM從單純的文本生成模型走向具有持續(xù)交互能力的智能體服務的必然要求。SMetric作為一個核心的度量與決策工具為我們設(shè)計高效、公平、體驗優(yōu)良的Agent服務系統(tǒng)提供了切實可行的思路。它不是一個僵化的算法而是一個靈活的框架需要工程師們根據(jù)自己業(yè)務的具體形態(tài)去填充、調(diào)整和優(yōu)化。開始重新審視你系統(tǒng)中那些排隊隊列吧也許第一個要優(yōu)化的就是那個默認的、簡單的任務調(diào)度器。