LLM Serving有效吞吐量的最大化实现

Sarathi的chunked prefill论文 3. 耗时大的部分:2个FFN,preproj,postproj。1. Prefill阶段,batch size为1时,GPU算力已满(saturate),所以提高batch size不能减少单个request的耗时。4. 它的实验里,batch-size为1时,1个decode的平均耗时,是1个prefill的平均耗时,的200倍。(似乎没有打成batch,是一个一个独立计算的)。2. Decode阶段,因为是memory-bound,提高batch size几乎可以让单个request的耗时线性减少。 阅读详情

如今的LLM应用具有多样化的时延要求。例如,聊天机器人可能需要快速的初始响应(例如,少于0.2秒),但在解码速度上只需要匹配人类阅读速度,而代码补全则需要快速的端到端生成时间,以实现实时代码建议。

本文说明了优化吞吐量(throughput)的现有serving系统**,在时延标准下并不是最优选择。作者主张使用有效吞吐量(goodput)**,即符合服务等级目标(SLO)的每秒完成请求数量,作为衡量LLM serving性能的改进指标,以考虑成本和用户满意度。

为优化有效吞吐量,作者引入了预填充-解码解耦(prefill-decode disaggregation),也就是将预填充从解码中分离到不同的GPU。他们还构建了一个系统原型DistServe,能够实现高达4.48倍的吞吐量或SLO严格(tighter)10.2倍,同时保持在严格的时延约束内。DistServe正在集成到vLLM中。

(以下内容由OneFlow编译发布,转载请联系授权。原文:hao-ai-lab.github.io/blogs/dists…

作者 | Yinmin Zhong, Junda Chen, Shengyu Liu, Yibo Zhu, Xin Jin, Hao Zhang

OneFlow编译

翻译|张雪聃、杨婷、宛子琳

(单次请求通过LLM Serving引擎并使用预填充(prefill)和解码(decode)解耦示意图)

1 背景:吞吐量与有效吞吐量

LLM正在改变整个行业在其服务中采用AI技术的方式,但LLM serving的成本却仍然很高。为降低serving成本,目前许多公司专注于最大化整体LLM serving系统的整体吞吐量(throughput) ,即每秒服务的请求数量(或rps),作为最小化**每个请求的成本($/req)**的代理。几乎所有流行的LLM serving引擎都把吞吐量作为比较性能的主要指标,如vLLM和TensorRT-LLM。

实际上,下游应用程序有不同类型,可能对用户体验有不同的时延要求,因此需要满足不同的SLO。LLM服务中最广泛使用的SLO包括:

  • 首词元时间(TTFT):LLM为用户输出第一个生成词元所需的时间。
  • 每个词元输出时间(TPOT):衡量两个连续生成的词元之间的平均时延。

(图0:应用程序有多样化的SLO)

吞吐量衡量的是所有用户和请求中完成的请求或词元的数量,因此忽略了这些时延要求。我们引入了有效吞吐量(goodput) ,即每秒完成请求的遵守SLO(TTFT和TPOT要求)的数量,并展示了它是一个更优指标,因为它捕获了在SLO达成下的请求吞吐量——因此既考虑了成本又考虑了服务质量。

为了简要说明有效吞吐量,可以假设一个应用要求至少90%的请求TTFT < 200ms以及TPOT < 50ms,我们得到以下定义:

有效吞吐量(P90 TTFT < 200ms和P90 TPOT < 50ms)= 当至少90%的请求同时满足TTFT < 200ms和TPOT < 50ms时,系统可以承受的每秒最大请求速率。

图1展示了一个简单案例,一个具有高吞吐量的应用,其有效吞吐量可能很低。该应用的吞吐量为每秒10个请求。但由于时延限制,只有3个请求符合SLO约束,得到有效吞吐量为每秒3个请求。可以想象,这个serving系统吞吐量高但有效吞吐量低,用户仍然会遭受服务质量低下的困扰。

(图1:高吞吐量≠高有效吞吐量。优化吞吐量的系统在某些SLO约束下可能具有很低的有效吞吐量)

让我们来总结下本小节引入的术语:

  • 有效吞吐量(goodput): 衡量LLM serving系统有效性的指标,同时考虑成本和用户满意度。它被定义为系统在满足指定SLO的同时,每秒可以保持的最大请求速率。
  • 吞吐量(throughput): LLM serving系统每秒处理的完成请求数量。
  • **服务等级目标(SLO):**LLM serving系统必须满足的一组目标,以提供满意的用户体验。常见的SLO包括首词元时间(TTFT)、每个词元输出时间(TPOT)、端到端时延(E2E)和指数移动平均(EMA)时延。
  • **预填充:**LLM推理的第一阶段,消化所有输入词元,填充KV缓存,并生成第一个输出词元。
  • 解码:逐个生成词元直到终止的后续阶段。
  • **首词元时间(TTFT):**LLM serving系统生成响应用户请求的第一个词元所需的时间。
  • **每个输出词元时间(TPOT):**LLM serving系统对用户请求生成后续词元的平均时间。

2 为什么现有系统无法实现高有效吞吐量?

LLM请求是如何被处理的?

在深入讨论之前,让我们回顾一下LLM serving中请求的生命周期。图2显示了这一过程。当一个请求进入LLM推理引擎时,系统首先会取用户输入生成第一个词元(预填充),然后逐个自回归地生成输出(解码)。一个请求通常由一个预填充步骤和多个解码步骤组成,直到终止。

LLM serving系统通常将预填充和解码一起批处理,用一种称为迭代级调度(iteration-level scheduling)或连续批处理(continuous batching)的技术,以便GPU处理尽可能大的批大小,运行一次迭代,并为所有这些请求生成一个词元。这种技术有效地提高了整体吞吐量(每秒词元数),并且被广泛应用于流行的serving系统,如vLLM和TensorRT-LLM。

(图2:传统LLM serving系统中请求的处理方式)

然而,计算中的预填充和解码阶段各具独特属性。预填充对计算资源的需求量极大,哪怕是小批次的预填充任务,甚至单个较长的预填充任务,都足以使GPU的计算能力达到饱和。与此相对,解码任务则需要更大的批大小才能充分利用计算资源,并且更容易受到GPU内存带宽限制的影响。

由于这两个阶段的计算模式和SLO截然不同,将它们合并处理并不是实现高有效吞吐量的最佳策略。原因如下:

  • 合并预填充和解码会导致它们之间相互干扰。
  • 合并预填充和解码会耦合它们的资源分配和并行策略。

接下来,我们将进一步阐释这些问题。

合并预填充和解码导致的干扰

图3以简化形式展示了预填充和解码之间的干扰情况。在图的最左侧,我们将这两个请求在单个GPU上进行批处理。可以看到,连续批处理显著增加了解码任务(R1)的时延,并略微增加了预填充任务(R2)的时延。在图的右侧,我们展示了一个稳定的传入请求流。此时,处于解码阶段的请求在每次预填充请求进入系统时都会“卡住”,因此意外地增加了解码任务的时延。

(图3:连续批处理引发的干扰)

如图4所示,由于这种干扰,为同时满足TTFT和TPOT的SLO,系统必须过度配置资源以满足时延目标,尤其是在SLO要求严格的情况下。

(图4:为满足SLO目标,合并预填充和解码的系统必须过度配置资源)

资源分配与并行策略紧密耦合

此外,由于合并,预填充和解码计算的并行策略(张量、流水线或数据并行)本质上是耦合的。如前所述,由于它们的计算模式和时延目标截然不同,预填充和解码阶段的最优并行策略通常也不同。例如,当实时吞吐量(TTFT)要求严格而总吞吐量(TPOT)要求宽松时,预填充阶段更倾向于使用张量并行(TP)来满足严格的时延目标,而解码阶段则更倾向于数据或流水线并行以提高吞吐量。接下来,我们将探讨解决这些问题的新方法。

3 解耦预填充和解码阶段

背后的逻辑很简单:将预填充和解码解耦到不同的GPU中,并为每个阶段定制并行策略。这自然解决了上述两个问题:

  1. 预填充和解码之间没有干扰,使得两个阶段都能更快地达到各自的SLO。
  2. 资源分配和并行策略解耦,从而为预填充和解码量身定制优化策略。

图5展示了请求在这种解耦系统中被处理的方式。当一个请求进入系统时,它首先被发送到一个预填充工作器,并完成其预填充阶段。然后,系统将其中间状态(主要是KV缓存)迁移到一个解码工作器,并且进行多个解码步骤以生成后续词元。一旦完成生成,请求就离开了系统。

(图5:当预填充/解码被解耦时,请求的处理方式)

让我们通过一个简单的实验来看看为什么解耦是有用的。我们按照泊松到达过程(Poisson arrival),使用输入长度为512、输出长度为64的合成工作负载,在单个A100-80GB GPU上运行一个13B参数的LLM。我们逐渐增加请求率(x轴),并测量两个时延(P90 TTFT和P90 TPOT,y轴)的变化,如图6所示。

假设我们将P90 TTFT的SLO设定为0.4秒,P90 TPOT设定为0.04秒(图6中的水平线)。我们观察到现有系统可以使用1个GPU,在TTFT时延约束内支持大约3RPS(请求率),而对于TPOT,则可以维持在1.6 RPS(图6a)。由于我们需要同时满足这两个约束,现有合并系统的有效吞吐量变为:有效吞吐量(合并) = min(3,1.6) = 1.6 RPS(每GPU)。

可见解耦后的性能显著提升。如图6所示,如果各自仅处理一个阶段,预填充工作器和解码工作器都能达到比之前更高的RPS。一个预填充工作器大约能够达到5.6 RPS,而一个解码工作器大约能够达到10 RPS。更为关键的是,现在我们可以灵活配置,将两个预填充工作器(2P)与一个解码工作器(1D)进行配对(记为2P1D),总共使用3个GPU。因此有效吞吐量变为:

Goodput(2P1D) = min(5.6 x 2, 10) = 10 reqs/s / 3 GPUs ≈ 3.3 reqs/s (per GPU)

该实验表明,在没有使用任何并行策略的情况下,这种简单的解耦能产生2倍的有效吞吐量。

(图6:合并处理(a)的灵活性比解耦(b)差,后者为预填充分配了2个GPU,为解码分配了1个GPU(计为2P1D))

实际上,除了为每个阶段分配不同的资源外,解耦预填充和解码还能让我们为每个阶段选择最佳的并行策略,以优化有效吞吐量(称为“量身定制的并行策略”),我们在论文中详细研究了这一点。

KV Cache传输

解耦造成了在预填充和解码GPU之间传输中间状态(即KV Cache)的成本。在LLM推理中,KV Cache看似是一个巨大的内存开销,而在GPU之间传输KV Cache则像是一种瓶颈。然而,我们展示的情况恰恰相反:通过适当的放置(placement),KV Cache传输开销可以有效地最小化,甚至低于一个解码步数的时间,这要归功于现在的高速网络,如NVLink和PCI-e 5.0。

为了更直观,假设我们有8通道PCIe 5.0 x16(每个链路64GB/s)作为GPU之间的节点内网络。给定一个2048词元的请求,当提供OPT-175B的请求时,传输的KV Cache预计如下:

时延 = 2048 token *(4.5 MB/token)/(64GB/s * 8)= 17.6 ms

该时延小于OPT-175B的单个解码步数时间(在A100上约为30-50ms)。对于更大的模型、更长的序列或更先进的网络(例如,带宽为600GB/s的A100-NVLink),如图7所示,与单个解码步数相比,与KV Cache传输相关的比较性计算开销变得不那么显著。总之,通过精心放置预填充和解码工作器来利用高带宽网络,可以有效地隐藏KV Cache传输开销,这在我们的论文中有详细讨论。

(图7:KV cache传输开销可以有效地最小化,直至低于解码步数的时间)

DistServe:评估解耦的有效性

我们在名为DistServe的系统原型中实现了这一技术,并将其与现有系统在三个具有不同时延约束的工作负载和数据集上进行了比较:聊天机器人、代码补全和摘要生成,如下表所示。

(表8:我们评估中的工作负载和时延要求)

图9展示了DistServe与vLLM的比较结果:

  • **聊天机器人:**DistServe的吞吐量比vLLM高2.0倍至3.41倍。
  • **代码补全:**DistServe的吞吐量比vLLM高3.2倍,其SLO比vLLM严格1.5倍。作为一个实时编码助手,代码补全任务所要求的TTFT比聊天机器人更低,这导致两个系统最终都受到TTFT要求的限制。然而,通过消除解码作业的干扰并为预填充定制张量并行性,DistServe减少了预填充作业的平均时延,从而满足了更多请求的TTFT要求。
  • **总结:**DistServe的吞吐量比vLLM高4.48倍,其SLO比vLLM严格10.2倍。正如预期的那样,由于vLLM将预填充和解码合并在一起,其解码的降速幅度更大,无法满足TPOT的要求。请查看我们的技术报告获取更详细的实验结果。

(图8:在各种数据集上评估DistServe与vLLM的性能)

解耦与分块预填充

本节将预填充-解耦与动态分割(dynamic splitfuse)或称分块预填充(chunked prefill)和捎带确认(piggybacking)的最新方法进行比较,并讨论它们各自的优缺点。

动态分割的关键是将较长的预填充分成更小的块(chunk),从而通过将预填充块与多个解码任务组合形成批处理,并充分调动GPU,这个过程称为捎带确认(piggybacking)。块大小是根据工作负载有意选择的,以便这种方法在所有步数上都能充分利用GPU,从而提高整体的系统效率。然而,它可能会增加TTFT和TPOT,进而在时延约束下减少吞吐量。这是由于动态分割无法完全解耦预填充和解码操作,导致资源争用以及TTFT与TPOT之间的妥协。

对于TTFT,分块预填充会导致预填充的计算开销(因此TTFT较高),不管块大小如何。

首先,选择明显低于GPU饱和点的块大小会延长预填充任务的执行时间。例如,假设GPU在预填充长度为512时饱和,将块大小设置为256将使所有超过512的预填充的TTFT翻倍。

其次,即使块大小被优化到几乎最大化GPU使用率,分块预填充也会显著增加预填充任务的内存访问量,因为需要将KV Cache从GPU的HBM加载到SRM以用于每个后续块。对于更长的预填充,这种情况更会加剧,导致KV Cache加载操作呈二次增长,而不是线性增长,由于解码词元槽的限制,附带的机会也会减少。至于TPOT,正如之前所言,将预填充和解码在批次中合并实际上会降低所有这些解码任务的速度。

总之,分块预填充可能有助于最大化整体吞吐量,但当应用程序无法在TTFT和TPOT之间进行权衡,而是要同时遵守这两者时,解耦就成为更好的选择。

4 DistServe的现状

我们正在与vLLM社区合作,将所提出的技术整合到vLLM生态系统中。

与此同时,Splitwise、TetriInfer和DéjàVu也采用了这种解耦策略,将预填充与解码分开,以实现更好的LLM serving有效吞吐量。我们很高兴看到许多研究人员和公司都用解耦来优化系统吞吐量,我们相信,解耦很快将成为LLM serving引擎的首选。

致谢:感谢Vikranth Srivatsa、Lanxiang Hu和Will Lin为这篇博客提供了独到的见解和反馈。

**【语言大模型推理最高加速11倍】**SiliconLLM是由硅基流动开发的高效、易用、可扩展的LLM推理加速引擎,旨在为用户提供开箱即用的推理加速能力,显著降低大模型部署成本,加速生成式AI产品落地。(技术合作、交流请添加微信:SiliconFlow01)

SiliconLLM的吞吐最高提升2.5倍,时延最高降低2.7倍

数据中心+PCIe:SiliconLLM的吞吐最高提升2.8倍;消费卡场景:SiliconLLM的吞吐最高提升1.7倍

如何系统的去学习大模型LLM ?

作为一名热心肠的互联网老兵,我意识到有很多经验和知识值得分享给大家,也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑,所以在工作繁忙的情况下还是坚持各种整理和分享。

但苦于知识传播途径有限,很多互联网行业朋友无法获得正确的资料得到学习提升,故此将并将重要的 AI大模型资料 包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

😝有需要的小伙伴,可以V扫描下方二维码免费领取🆓

在这里插入图片描述

一、全套AGI大模型学习路线

AI大模型时代的学习之旅:从基础到前沿,掌握人工智能的核心技能!

img

二、640套AI大模型报告合集

这套包含640份报告的合集,涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师,还是对AI大模型感兴趣的爱好者,这套报告合集都将为您提供宝贵的信息和启示。

img

三、AI大模型经典PDF籍

随着人工智能技术的飞速发展,AI大模型已经成为了当今科技领域的一大热点。这些大型预训练模型,如GPT-3、BERT、XLNet等,以其强大的语言理解和生成能力,正在改变我们对人工智能的认识。 那以下这些PDF籍就是非常不错的学习资源。

img

在这里插入图片描述

四、AI大模型商业化落地方案

img

阶段1:AI大模型时代的基础理解

  • 目标:了解AI大模型的基本概念、发展历程和核心原理。
  • 内容:
    • L1.1 人工智能简述与大模型起源
    • L1.2 大模型与通用人工智能
    • L1.3 GPT模型的发展历程
    • L1.4 模型工程
      - L1.4.1 知识大模型
      - L1.4.2 生产大模型
      - L1.4.3 模型工程方法论
      - L1.4.4 模型工程实践
    • L1.5 GPT应用案例

阶段2:AI大模型API应用开发工程

  • 目标:掌握AI大模型API的使用和开发,以及相关的编程技能。
  • 内容:
    • L2.1 API接口
      - L2.1.1 OpenAI API接口
      - L2.1.2 Python接口接入
      - L2.1.3 BOT工具类框架
      - L2.1.4 代码示例
    • L2.2 Prompt框架
      - L2.2.1 什么是Prompt
      - L2.2.2 Prompt框架应用现状
      - L2.2.3 基于GPTAS的Prompt框架
      - L2.2.4 Prompt框架与Thought
      - L2.2.5 Prompt框架与提示词
    • L2.3 流水线工程
      - L2.3.1 流水线工程的概念
      - L2.3.2 流水线工程的优点
      - L2.3.3 流水线工程的应用
    • L2.4 总结与展望

阶段3:AI大模型应用架构实践

  • 目标:深入理解AI大模型的应用架构,并能够进行私有化部署。
  • 内容:
    • L3.1 Agent模型框架
      - L3.1.1 Agent模型框架的设计理念
      - L3.1.2 Agent模型框架的核心组件
      - L3.1.3 Agent模型框架的实现细节
    • L3.2 MetaGPT
      - L3.2.1 MetaGPT的基本概念
      - L3.2.2 MetaGPT的工作原理
      - L3.2.3 MetaGPT的应用场景
    • L3.3 ChatGLM
      - L3.3.1 ChatGLM的特点
      - L3.3.2 ChatGLM的开发环境
      - L3.3.3 ChatGLM的使用示例
    • L3.4 LLAMA
      - L3.4.1 LLAMA的特点
      - L3.4.2 LLAMA的开发环境
      - L3.4.3 LLAMA的使用示例
    • L3.5 其他大模型介绍

阶段4:AI大模型私有化部署

  • 目标:掌握多种AI大模型的私有化部署,包括多模态和特定领域模型。
  • 内容:
    • L4.1 模型私有化部署概述
    • L4.2 模型私有化部署的关键技术
    • L4.3 模型私有化部署的实施步骤
    • L4.4 模型私有化部署的应用场景

学习计划:

  • 阶段1:1-2个月,建立AI大模型的基础知识体系。
  • 阶段2:2-3个月,专注于API应用开发能力的提升。
  • 阶段3:3-4个月,深入实践AI大模型的应用架构和私有化部署。
  • 阶段4:4-5个月,专注于高级模型的应用和部署。
这份完整版的大模型 LLM 学习资料已经上传优快云,朋友们如果需要可以微信扫描下方优快云官方认证二维码免费领取【保证100%免费】

😝有需要的小伙伴,可以Vx扫描下方二维码免费领取🆓

在这里插入图片描述

HexAGenT:面向Agentic LLM Serving的异构感知调度框架设计 在分布式系统和AI工程化实践中,调度算法是协调计算资源与任务执行的核心组件,其原理在于根据系统状态和任务需求做出最优的资源分配决策。该技术的价值在于能够显著提升集群的资源利用率、系统吞吐量,并降低任务的整体完成延迟与运行成本。尤其在当前大模型(LLM)与智能体(Agent)应用日益复杂的背景下,传统的简单调度策略难以应对工作流任务间的复杂依赖及底层GPU、CPU等异构硬件在算力、成本上的巨大差异。HexAGenT框架正是针对此挑战,创新性地融合了工作流感知与异构性感知两大核心机制,通过动态解析任务DAG、构 阅读详情

相关推荐

模型推理的Goodput指标、Prefilling和Decode阶段物理分离、DistServe

调整灵活:如果input prompt长,那就增加Prefilling的GPU数目;如果output sequence长,那就增加decoding的GPU数目;开销:KV-Cache在2个阶段的GPU之间传输。但,该开销

smartcat2010的博客 1866

vllm serve的参数大全及其解释

以下是vllm servemodel_tagport=800000.9--dtypefloat32float16bfloat16uvicorndebuginfowarningerrorcriticaltraceraympray--api-keyfp8。

keyboard专栏 2万+

vllm serve 使用方法

是 vLLM 提供的命令行工具,用于快速部署兼容 OpenAI API 的 HTTP 服务器。是 vLLM 中简洁的命令行接口,用于快速启动 API 服务。指定模型路径或 Hugging Face Hub 模型名称(如。信任远程代码(加载需要自定义代码的模型,如某些社区模型)。张量并行 GPU 数量(多卡推理时设置为 GPU 数量)。SSL 私钥文件路径(启用 HTTPS)。确认模型路径正确(本地模型需绝对路径)禁用性能统计日志(减少日志输出)。禁用请求日志(减少日志输出)。GPU 显存利用率(默认。

NLP与推荐算法 2539

【有啥问啥】 什么是Chunked Prefill技术?

阶段对输入提示(prompt)进行前向推理,构建 Key-Value (KV) 缓存;阶段逐步生成输出令牌。传统流程中,Prefill 会处理整个输入序列后才开始输出解码,此时并行度高但对后续解码造成阻塞。即将一个长prompt的Prefill过程拆分成多个小块(chunk),在调度时将这些预填充块与其他请求的解码任务混合批处理。

Chauvin的博客 2671

vllm部署记录

pip install -e`是Python包管理器`pip`的一个参数。在这里,`-e`代表editable,意思是在安装包时,它会以可编辑模式进行安装。这样安装的包实际上是通过符号链接与源代码关联起来的,这意味着您对源代码的修改会立即反映在安装的包上,而无需重新安装。第一个opt-125m是名字,可以在vllm支持的模型中查到,第二个是模型存放文件夹及其路径。注意在modelscope上的这个opt-125m好像不行了,我git不下来报错。2. 源码部署普通单机(失败)

andeyeluguo的博客 1275

EdgeLoRA: An Efficient Multi-Tenant LLM Serving System on Edge Devices

本文介绍了EdgeLoRA,这是一种针对资源受限边缘设备设计的高效多租户大语言模型(LLM)服务系统。该系统旨在解决边缘设备上部署微调LLM时面临的关键挑战,包括适配器选择复杂、内存开销大、多租户场景下计算效率低等问题。EdgeLoRA基于Llama3.1-8B等模型进行了全面评估,结果显示其在延迟、吞吐量和能效方面显著优于现有方案(如llama.cpp):吞吐量提升高达4倍,能耗更低,同时能支持数量级更多的适配器并行服务且不损失推理性能。

c_cpp_csharp的专栏 184

NanoFlow:面向LLM的革命性高吞吐量服务框架,性能超越TensorRT-LLM达1.91倍

NanoFlow是一款面向大型语言模型(LLM)的高吞吐量服务框架,专为提升AI模型部署效率而设计。作为GitHub加速计划的重要项目,NanoFlow通过创新的并行计算架构和智能调度机制,实现了比TensorRT-LLM高出1.91倍的吞吐量,为企业级LLM应用提供了性能突破。 ## 为什么选择NanoFlow? 在AI大模型时代,服务框架的性能直接决定了业务响应速度和成本效益。NanoFl

gitblog_00322的博客 829

从S参数矩阵到硬件实现:手把手教你用耦合微带线设计Marchand巴伦

本文详细介绍了使用耦合微带线设计Marchand巴伦的完整流程。从奇偶模理论和S参数矩阵分析入手,结合ADS仿真软件进行参数优化与电磁仿真验证,最终指导PCB布局、制作与实测调试。文章以2.4GHz Wi-Fi前端电路为例,手把手演示了从理论计算到硬件实现的全过程,并分享了关键的工程经验与调试技巧。

weixin_29271263的博客 537

【大模型推理】SCORPIO: Serving the Right Requests at the Right Time for Heterogeneous SLOs in LLM(上)

SCORPIO的TPOT估算方法通过。

王尚权 qq:2515162716 1029

VCS和UVM常用编译选项

VCS编译选项 -full64 在64bit模式下编译、仿真,用于64位操作系统 -j8 指定编译器可以并行编译的进程数为8 -timescale=1ns/1ps 指定仿真时间和精度 +libext+.v+.V+.sv+.svh 识别.v、.sv、.svh等多种格式文件 -sverilog 支持system verilog 编译 -f xxx.lisf 指定包含所有设计文件列表的文件名 -top test 设置顶层模块为test。(指包含.

qq_40571921的博客 9934

RK3576+IMX415 MIPI摄像头零拷贝显示系统

MIPI CSI-2是嵌入式视觉系统中主流的高速图像传感器接口标准,其核心价值在于低延迟、高带宽与硬件级DMA直通能力。基于V4L2子系统与DRM/KMS驱动栈,可构建从传感器RAW数据到帧缓冲区的零拷贝通路,显著降低CPU负载并提升实时性。该技术广泛应用于工业检测、边缘AI推理前数据接入及多路同步采集等场景。本文以Rockchip RK3576 SoC和索尼IMX415传感器为典型组合,详解MIPI物理层适配、内核驱动集成、GStreamer零拷贝管道搭建及systemd服务化部署,覆盖从硬件信号完整性到

weixin_36047538的博客 217

Ascendra:动态请求优先级分配以实现高效的LLM服务

大型语言模型(LLMs)的快速发展推动了对更高效服务策略的需求。在此背景下,效率指的是满足其服务水平目标(SLOs)的请求数量比例,特别是首次生成时间(TTFT)和标记间时间(TBT)。然而,现有系统往往在优化一个指标时牺牲另一个。我们介绍了Ascendra,一种设计用于同时满足TTFT和TBT SLOs的LLM服务系统。Ascendra的核心洞察是,随着请求接近其截止时间,其紧迫性会发生变化。为了利用这一点,Ascendra将GPU资源划分为两种实例类型:低优先级和高优先级。

栖客 1167

OpenClaw实操:给网站装上“智能眼睛”?手把手教你用OpenClaw实时监控网站

本文介绍如何在Windows系统使用OpenClaw构建智能网站监控助手。手把手教你通过配置本地AI模型,让openclaw构建的ai助手自动检测指定网页的内容变化,理解更新重要性,并及时通过邮件、微信、Telegram等渠道发出预警,让你第一时间掌握关键信息,彻底告别手动刷新。

plawuyue的博客 2165

实测对比:NanoFlow vs vLLM vs TensorRT-LLM,谁是LLM服务性能王者?

在当今大语言模型(LLM)服务框架的激烈竞争中,**NanoFlow**作为一款面向吞吐量的高性能LLM服务框架,正在以其惊人的性能表现挑战传统框架的霸主地位。本文将为您带来NanoFlow与vLLM、TensorRT-LLM的全面性能对比实测,揭示谁才是真正的LLM服务性能王者。 ## 🔥 性能王者之争:NanoFlow的颠覆性创新 **NanoFlow**通过两大核心技术革新彻底改变了L

gitblog_00238的博客 1078

【毕设级教程】从0到1实现基于YOLOv8的xView卫星图像目标检测系统(含UI界面,助力遥感智能毕设)

本文基于YOLOv8模型设计了一个面向xView卫星图像的目标检测系统。首先对xView数据集进行了格式转换处理,将原始多边形标注转换为YOLO格式的边界框标注。随后通过配置YOLOv8模型参数完成训练,实现了对卫星图像中建筑、车辆等多类目标的准确识别。为提高系统交互性,采用PyQt开发了可视化界面,支持图像选择、实时检测和结果展示功能。整个系统兼顾学术价值和实用价值,为遥感领域的自动化目标检测提供了可行方案。

m0_64661770的博客 131

Megatron-LM中的TP、PP、DP、SP、CP并行

SP主要优化的是激活内存,它沿序列维度切分部分激活,适用于较短序列并行。CP主要解决的是长序列的显存问题,它沿序列维度切分所有激活和输入,并且对注意力机制也进行并行处理。二者可以组合使用,特别是当 TP > 1 并且需要处理长序列时,通过启用 SP 和 CP 可以最大化地优化内存使用和加速计算。

u013250861的博客 861

DistServe进阶教程:自定义调度策略实现LLM推理效率最大化

在当今大语言模型(LLM)推理服务领域,**DistServe**作为一款创新的解耦式推理系统,通过将预填充和解码阶段分离,显著提升了LLM推理效率。本教程将深入探讨如何通过自定义调度策略来最大化DistServe的性能潜力,帮助您掌握高级配置技巧,实现推理吞吐量的显著提升。 ## 🚀 为什么需要自定义调度策略? DistServe的核心优势在于其解耦架构设计,但默认的FCFS(先来先服务)

gitblog_00034的博客 458

R3LIVE项目实战(3) —双目相机与激光雷达 lidar_camera_calib联合标定

lidar_camera_calib是一个在无目标环境中,用于高分辨率LiDAR(例如Livox)和摄像机之间准确的外部标定工具。我们的算法可以在室内和室外场景中运行,并且只需要场景中的边缘信息。如果场景适合,我们可以实现类似于或甚至超过基于目标的方法的像素级准确度。我们使用标定的外部参数给点云上色,并与实际图像进行比较。A和C是点云的局部放大视图。B和D是与A和C中的点云对应的摄像机图像的部分。

几度春风里的博客 4059

Mooncake:LLM服务的KVCache为中心分解架构

24年6月AI公司月之暗面的技术报告“Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving”。

yorkhunter的博客 7967

RTOS与Linux功能差异与应用场景全面对比

在嵌入式系统的开发中,操作系统的选择至关重要。和是两种广泛应用的操作系统,它们在功能、设计目标以及应用领域中各具优势。随着嵌入式系统的不断发展,已成为嵌入式行业的大趋势。那么,这两者到底有什么不同呢?

硬核科技 402

Statistics and Machine Learning Toolbox

Statistics and Machine Learning Toolbox(带书签),MATLAB统计学习工具

如何理解NanoFlow:从论文到代码的高性能LLM服务框架实现原理

NanoFlow是一个面向吞吐量优化的**高性能大语言模型服务框架**,通过创新的设备内并行技术和纳米批处理调度,实现了比现有框架高达1.91倍的吞吐量提升。作为专门为大语言模型推理设计的服务框架,NanoFlow通过重新设计计算、内存和网络操作的调度方式,最大化GPU硬件利用率,为大规模LLM服务提供了全新的解决方案。 ## 🚀 NanoFlow的核心设计理念 ### 设备内并行技术突破

gitblog_00641的博客 847

pscad IEEE标准系统搭建说明

pscad IEEE标准系统搭建说明,包含典型的IEEE 9节点、14节点、30节点、39节点和118节点系统。内含标准测试系统的原始数据和潮流结果。

《Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving》阅读笔记

最近昇腾提供的大EP PD分离推理解决方案非常火,很多开发者都开始使用了。正好这两天也看了一篇PD分离的经典论文,就是Kimi采用的PD分离架构:Mooncake。

weixin_42619941的博客 280

霍尼韦尔SoftMaster使用说明

霍尼韦尔SoftMaster使用说明

LLM 论文精读(八)Towards Efficient Generative Large Language Model Serving: A Survey from

这篇论文讲的是 LLM 推理加速的综述,比较全面地讲述了在推理加速领域中从算法到硬件上当前取得的进展以及存在的问题,在文章发表的时候(2023年)多模态大模型还没出现爆炸性增长,单单处理自然语言的话推理加速其实没有那么紧切,但现在(2025年)随着多模态模型的井喷,一张图像输入就可能消耗掉几千几万个 token,推理加速就变得非常重要,这也是很多公司 CTO 和 CIO 的共识。现在再回头看这篇综述,可以说是准确预言了大模型正在面对的困难。

nenchoumi3119的博客 1832

为什么选择NanoFlow?解析1.91倍吞吐量提升背后的关键技术

在大语言模型(LLM)部署领域,吞吐量是衡量服务性能的核心指标之一。NanoFlow作为一款面向吞吐量优化的高性能LLM服务框架,通过创新的系统设计和调度策略,实现了相比传统方案高达1.91倍的吞吐量提升。本文将深入剖析NanoFlow的核心技术优势,为您揭示其如何突破性能瓶颈,成为企业级LLM部署的理想选择。 ## 一、实测数据:NanoFlow吞吐量优势一目了然 NanoFlow的性能优势

gitblog_00842的博客 463
上一篇: 开源教程「动手学大模型应用开发」,从零基础到掌握大模型开发的关键技能!
下一篇: 自主 AI Agent 的构建|Function Calling 技术实例探索
Llama-Turbo
博客等级 码龄4年 9901粉丝 2024原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值