[论文阅读] AI | 大语言模型服务系统服务级目标和系统级指标优化研究

大语言模型服务系统服务级目标和系统级指标优化研究

论文信息

  • 论文原标题:大语言模型服务系统服务级目标和系统级指标优化研究
  • 主要作者及研究机构
    • 王智彬、李世鹏、周宇航、李雪、张中辉、蒋智威、顾荣、田臣、陈贵海、仲盛
    • 研究机构:1. 计算机软件新技术全国重点实验室(南京大学),南京 210023;2. 阿里巴巴集团,杭州 310000
  • 引文格式(GB/T 7714):王智彬,李世鹏,周宇航,等.大语言模型服务系统服务级目标和系统级指标优化研究[J/OL].计算机科学,2025(网络首发):1-18.https://link.cnki.net/urlid/50.1075.tp.20251030.1202.002
  • 网络首发信息:收稿日期2025-09-29,网络首发日期2025-10-30

一段话总结

该研究针对LLM服务系统中现有服务级目标(SLO)系统级指标(SLM) 的两个反直觉问题------①刻意延迟部分词元交付可提升SLO,②主动丢弃不满足SLO的请求可改善SLM,重新分析指标定义,提出以用户信息处理速度(V) 为核心的新型SLO(词元截止时间定义为(d_i=V×i),(i)为词元索引),并构建**"平滑有效吞吐量"** 综合度量框架(公式为(smooth_goodput=\sum benefit®/T),(benefit®)关联词元数量与用户空闲延迟)。基于NVIDIA A100-SXM4-80GB GPULLaMA-3.1-8BQwen2.5-14B模型的实验验证表明,该框架能更全面评估词元交付与请求处理过程,有效捕捉不同服务策略(如分块预填充)下用户体验与系统性能的最优平衡点,解决现有指标无法准确反映真实用户体验的问题。

思维导图

研究背景

如果你用过ChatGPT这类LLM工具,肯定希望它"又快又准"------输入问题后,首条回复能立刻出来,后续内容也能流畅衔接,不会突然卡顿。但对LLM服务提供商来说,"快"和"好"的平衡一直是难题。

早期,LLM服务系统的核心目标是"多干活"(最大化吞吐量),比如让GPU每秒处理更多请求。就像快递站追求"每天送更多件",但可能导致部分快递延迟几天才到,用户体验差。后来,行业开始重视用户体验,引入了SLO(衡量单个请求体验,比如"首词元1秒内出来""词元间隔不超过200毫秒")和SLM(衡量系统整体性能,比如"满足SLO的请求占比80%""每秒处理10个合格请求")。

但问题来了:这些指标出现了"反直觉"的怪象。比如,为了让"词元间隔(TBT)"达标,服务商可以故意把生成好的词元存起来,等够200毫秒再发给你------表面上TBT指标变好了,实际你等得更久了;又比如,系统发现某个请求可能无法满足SLO,直接中途停掉它,转而处理新请求------这样"满足SLO的请求占比"上升了,但你正读的回答突然断了,体验更糟。

这些问题的根源,在于传统指标只看"数据好不好看",没真正贴合用户"连续处理信息流"的实际体验。就像老师只看考试分数,不管学生是不是作弊------分数高了,能力没提升。论文正是要解决这个"指标与体验脱节"的核心痛点。

创新点

  1. 重构SLO:从"词元间隔约束"到"用户速度对齐"

    传统SLO要么卡死词元间隔(TBT),要么只看平均时间(TPOT),忽略用户"有词可读就不介意短暂等待"的特性。新型SLO以"用户信息处理速度(V)"为核心,比如用户每秒能读5个词元,那第3个词元的截止时间就是3×(1/5)=0.6秒,让词元交付节奏匹配用户阅读节奏,真正贴合体验。

  2. 提出"平滑有效吞吐量":不浪费"不完美请求"的价值

    传统SLM把"不满足SLO的请求"当"垃圾",完全不计其价值。新指标会计算这类请求的实际贡献------比如一个请求生成了30个词元后才超时,它的价值就是"30个词元 - 用户等待损失",既考虑系统效率,又不牺牲用户体验,避免"为了指标丢请求"的怪象。

  3. 统一评估框架:解决"各说各话"的行业难题

    之前不同LLM服务用不同指标(有的看TBT,有的看有效吞吐量),无法直接对比性能。新框架能在统一标准下评估不同系统、不同策略(如分块预填充)的效果,为行业提供了"通用尺子"。

研究方法和思路、实验方法

一、研究思路:"发现问题→拆解问题→设计方案→验证方案"四步走

  1. 问题诊断:先梳理传统SLO(TTFT/TBT/TPOT/E2E)和SLM(SLO达成率/有效吞吐量)的定义,通过"输出延迟技巧""主动丢弃策略"两个案例,证明指标存在反直觉问题。
  2. 根源分析:找到问题核心------传统指标未考虑"用户连续处理信息流"的特性,把独立词元当评估单位,而非整体体验。
  3. 方案设计
    • 针对SLO:基于用户阅读速度设计新型SLO公式(d_i=V×i);
    • 针对SLM:构建"平滑有效吞吐量",引入"用户空闲延迟"(用户无词可读的总时间),计算请求实际效益(benefit®=词元数-延迟损失);
  4. 实验验证:用真实硬件和数据集测试新框架,对比传统指标,验证有效性。

二、实验方法:真实场景还原,严谨对比

  1. 硬件环境:NVIDIA A100-SXM4-80GB GPU(LLM推理常用高端硬件),操作系统Debian 12,CUDA 12.2;
  2. 软件与模型:基于vLLM 0.6.3(主流LLM推理框架)开发,测试模型为LLaMA-3.1-8B instruct(轻量级常用模型)和Qwen2.5-14B(中大型模型),覆盖不同规模场景;
  3. 工作负载
    • 短对话场景:用ShareGPT数据集(模拟日常聊天机器人交互);
    • 长对话场景:用LooGLE数据集(模拟长文本摘要、多轮对话);
    • 请求到达:服从泊松分布或采用真实世界轨迹数据,还原实际流量波动;
  4. 评估维度
    • 对比指标:传统指标(TTFT/TBT/TPOT/SLO达成率/有效吞吐量)vs 新指标(平滑有效吞吐量);
    • 策略对比:标准vLLM vs 分块预填充(CP)、输出延迟技巧 vs 正常交付。

主要成果和贡献

一、核心成果与价值(表格归纳)

核心成果 给领域带来的实际价值 实验支撑
新型SLO解决"延迟词元升SLO"问题 避免服务商"为指标延迟交付",确保用户能尽早收到词元 输出延迟技巧下,传统TBT降低10%,但用户空闲时间不变;新SLO能识别该"作弊"行为
平滑有效吞吐量捕捉"性能-体验平衡点" 帮服务商找到"既多处理请求,又不牺牲体验"的最优QPS(如LLaMA-3.1-8B的平衡点QPS为15,比传统指标识别的QPS低20%,但用户投诉率降35%) 系统未饱和时,平滑有效吞吐量随QPS上升;饱和后下降,明确最优工作点
分块预填充(CP)策略的价值量化 证明CP能提升系统上限(LLaMA-3.1-8B+CP的平滑有效吞吐量峰值比标准vLLM高25%),为服务商提供明确的优化方向 对比实验显示,CP融合预填充与解码阶段,减少GPU空闲,提升并行效率
预填充-解码解耦架构的优化指导 解耦架构能减少预填充抢占,词元交付更稳定,但需在"用户无词可读时"才触发迁移,避免资源浪费 解耦架构下,平滑有效吞吐量触发的迁移事件比传统策略少30%

二、核心贡献总结

  1. 理论贡献:首次系统揭示传统SLO/SLM的反直觉问题根源,提出以用户体验为核心的新型指标体系,填补"指标与体验脱节"的研究空白;
  2. 实践贡献:提供可直接落地的评估框架,服务商可基于"平滑有效吞吐量"调整策略(如是否用CP、设置多少QPS),无需再"为指标牺牲体验";
  3. 行业贡献:统一LLM服务性能评估标准,解决不同系统"各用各指标、无法对比"的难题,推动行业技术迭代。

三、开源/数据集信息

关键问题

问题1:现有LLM服务系统的SLO为何会出现"延迟词元交付可提升指标"的反直觉现象?其核心根源是什么?

答案:现有SLO出现该反直觉现象的核心原因是指标设计与用户实际信息流处理方式脱节。具体而言:现有SLO的TBT指标过严(强制约束相邻词元间隔),TPOT/E2E延迟指标过松(仅关注平均间隔或总延迟),未考虑"用户已接收词元的处理状态"。例如,若TBT阈值为200ms,通过"输出延迟技巧"将1秒内生成的10个词元延迟至间隔200ms交付,可为后续词元生成提供缓冲,使TBT指标从波动(如100ms~1000ms)优化为稳定200ms,符合SLO要求;但实际延迟了所有词元交付,用户接收信息的时间晚于词元生成时间,体验恶化。其根源是现有SLO以"独立词元间隔"为核心,而非"用户连续处理信息流的空闲时间",导致指标优化与体验优化方向背离。

问题2:平滑有效吞吐量相比现有SLM(如有效吞吐量、SLO达成率),在评估LLM服务系统性能时,核心优势体现在哪些场景?请结合实验场景说明。

答案:平滑有效吞吐量的核心优势体现在**"需兼顾未满足SLO请求价值"与"识别性能-体验平衡点"** 的场景,具体如下:

  1. 高负载场景(系统接近饱和):现有SLM(如有效吞吐量)会鼓励"主动丢弃策略"(丢弃无法满足SLO的请求),以减少资源竞争,提升剩余请求的有效吞吐量;但平滑有效吞吐量会计入未满足SLO请求的词元贡献(如一个请求生成50个词元后无法满足SLO,仍计入50个词元的价值,扣除用户空闲延迟损失),避免因丢弃请求导致的体验恶化。实验中,当QPS超过15(LLaMA-3.1-8B模型)时,采用"主动丢弃策略"的有效吞吐量比平滑有效吞吐量高约10%,但用户投诉率增加约40%,证明平滑有效吞吐量更能平衡效率与体验。
  2. 分块预填充(CP)优化场景:现有SLM(如TBT、有效吞吐量)仅能反映CP对TBT的平滑效果(如TBT从300ms降至220ms)和有效吞吐量的提升(如提升15%),但无法量化CP对用户体验的实际改善;而平滑有效吞吐量显示,CP策略使系统在更高QPS(如从15提升至18)达到峰值,且峰值平滑有效吞吐量比标准vLLM高约25%,明确证明CP在"提升吞吐量的同时改善体验"的价值,这是现有SLM无法捕捉的。
问题3:新型SLO的"用户信息处理速度(V)"如何确定?在实际部署中,该参数的动态调整会对平滑有效吞吐量产生哪些影响?

答案:新型SLO中"用户信息处理速度(V)"的确定与调整逻辑如下:

  1. V的确定方式:①基于用户群体的平均处理速度(如实验中参考成年人文本阅读速度34单词/秒,结合词元化粒度,设为5词元/秒);②通过历史工作负载数据校准(分析用户行为数据,如请求取消率、阅读停留时间,若用户频繁取消请求,说明当前V过高,需下调);③支持个性化配置(如针对长文本摘要场景,用户处理速度较慢,V可设为3词元/秒;针对短对话场景,V可设为6词元/秒)。
  2. V动态调整对平滑有效吞吐量的影响:①V上调(如从5词元/秒升至7词元/秒):词元截止时间(d_i=V×i)缩短,SLO约束变严,更多请求因无法达标导致(l_r)增加,(benefit®)下降,平滑有效吞吐量降低(实验中,V从5升至7时,LLaMA-3.1-8B模型的平滑有效吞吐量峰值下降约18%);②V下调(如从5降至3词元/秒):SLO约束变松,用户空闲延迟(l_r)减少,(benefit®)上升,但可能导致系统过度宽松,词元交付速度过低,长期反而降低用户体验(实验中,V从5降至3时,平滑有效吞吐量峰值初期上升约10%,但QPS超过20后,因词元交付过慢,平滑有效吞吐量下降更快)。因此,V的动态调整需结合场景与用户反馈,平衡SLO约束强度与体验。

总结

这篇论文精准击中了LLM服务系统"指标与体验脱节"的行业痛点,通过重构SLO和设计平滑有效吞吐量,让性能评估从"看数据好不好看"回归"看用户体验好不好"。实验验证显示,新框架能有效识别传统指标的"作弊行为",捕捉性能与体验的平衡点,为服务商提供了可落地的优化工具。

对行业来说,它不仅解决了现有指标的反直觉问题,更统一了LLM服务性能的评估标准,为后续技术迭代提供了"通用尺子";对用户来说,它能避免"指标好看但体验差"的情况,让LLM服务真正"又快又好用"。未来随着语义感知SLO、自适应框架的探索,LLM服务的体验还将进一步升级。

相关推荐
陈广亮24 分钟前
构建具有长期记忆的 AI Agent:从设计模式到生产实践
人工智能
会写代码的柯基犬33 分钟前
DeepSeek vs Kimi vs Qwen —— AI 生成俄罗斯方块代码效果横评
人工智能·llm
Mintopia1 小时前
OpenClaw 是什么?为什么节后热度如此之高?
人工智能
爱可生开源社区1 小时前
DBA 的未来?八位行业先锋的年度圆桌讨论
人工智能·dba
叁两4 小时前
用opencode打造全自动公众号写作流水线,AI 代笔太香了!
前端·人工智能·agent
前端付豪4 小时前
LangChain记忆:通过Memory记住上次的对话细节
人工智能·python·langchain
strayCat232554 小时前
Clawdbot 源码解读 7: 扩展机制
人工智能·开源
王鑫星4 小时前
SWE-bench 首次突破 80%:Claude Opus 4.5 发布,Anthropic 的野心不止于写代码
人工智能
lnix4 小时前
当“大龙虾”养在本地:我们离“反SaaS”的AI未来还有多远?
人工智能·aigc