七脉神剑的秘密

七脉神剑的秘密
记录学习与成长中的的点点滴滴
  1. 首页
  2. 好好学习
  3. AI-study
  4. 正文

NVIDIA 的AI推理系统技术细节

2025年8月6日 41点热度 0人点赞 0条评论
智能摘要
NVIDIA Dynamo是一款高吞吐量低延迟的分布式推理框架,专为多节点环境中的生成式AI模型服务设计。其核心功能包括分离prefill(处理输入提示并生成KV缓存)和decode(自回归生成token)阶段,以优化GPU资源分配;动态GPU调度机制实时调整资源比例,应对高并发负载;LLM-aware智能路由基于请求特征(如Prompt Tokens、Output Tokens)精准调度至合适节点;并采用NIXL库加速KV cache传输,通过RDMA和异步数据处理降低延迟。系统以Rust实现核心组件,支持Python接口,显著提升资源利用率和推理系统SLA。
— 此摘要由AI生成仅供参考。

NVIDIA Dynamo是一款设计为高吞吐量低延迟的分布式推理框架,旨在为多节点分布式环境中生成式AI和推理模型提供高性能推理服务。Dynamo被设计为与具体推理引擎无关(支持TRT-LLM、vLLM、SGLang或其他推理引擎),并有效发挥大语言模型特定的功能。Dynamo通过Rust语言实现核心组件以提高性能,支持Python接口以提高可扩展性和快速迭代和生态构建。

640NVIDIA Dynamo核心功能设计

  • Disaggregated prefill & decode inference

Dynamo将大模型推理任务分为二个阶段,prefill和decode阶段。原因在于prefill和decode阶段对于GPU资源需求差异很大,合并在一起一个instance跑在一个GPU集群上会产生互相干扰,很难保证推理系统SLA,比如推理请求大量到来时prefill会占满GPU的计算能力,导致decode阶段的请求被无限延迟,导致ITL(Inter-Token Latency)激增,前端服务体验变差。

其实,prefill和decode分离本身并不神秘,从技术上来说是非常常用的软件层面优化方法,通过队列异步化解耦系统不同组件,提升系统整体吞吐量。通过分离式部署可以显著提高整个推理系统的吞吐量,榨干GPU资源,使得硬件性能发挥极致,取得吞吐量和延迟之间的平衡。当然如果单请求来看延迟一定是增加的,毕竟走了RDMA网络。

分离式推理系统架构使得可以根据prefill和decode的负载特征部署不同的GPU集群,充分利用GPU资源,同时可以通过配置不同的并行策略提升系统整体性能。

预填充(Prefill)负责处理输入提示并生成KV缓存,GPU计算密集型任务,适合部署高算力GPU集群

解码(Decode) 自回归生成新Token并输出,延迟敏感任务,ITL必须保证,适合部署高内存带宽GPU

prefill instance和decode instance通过PrefillQueue来交互实现disaggregation

640

l Worker: 实例线程,执行prefill和decode请求

l Prefill worker: prefill实例线程,仅执行prefill请求

l Disaggregated router: 由router决定执行本地prefill还是远端prefill

l Prefill queue:  remote prefill requests cache和负载均衡

分离式架构必须保证高性能,其中的关键是高效的KV cache传输,Dynamo使用NIXL从prefill engine的VRAM高效的传输KV到decode engine的VRAM,KV transfer采用非阻塞方式,允许GPU传输KV cache的时候同时处理其他请求,同样是用到了communication-comupution overlap降低了整个系统的延迟。

640-1

在KV键值块分配后,scheduler会通过预填充队列将远程prefill requests发送给prefill worker scheduler,请求包含已分配KV键值块内存描述符。

得益于NIXL高性能库单边RDMA读写 ,prefill worker无需远程worker显式处理,即可读写远程KV键值块。远程prefill完成后,worker scheduler只需将解码请求添加到worker in-flight queue中。这使得worker可以在等待远程prefill完成的同时,执行正在进行的其他解码/预填充请求的计算处理。

  • Dynamic GPU scheduling

在大规模多模型多租户多任务的高并发推理集群中,传统的静态资源绑定方式已不再适合。会出现集群资源的严重浪费,延迟抖动,业务Qos无法保证等痛点。

Dynamo通过planner持续跟踪GPU负载和请求流量,动态调整预填充与解码阶段的GPU分配比例,实现宝贵GPU资源的动态智能分配,支持按需增减节点,例如在高流量时段扩展解码节点以降低延迟,低负载时释放资源降低成本,实现资源伸缩弹性。

可以看出Dynamo就类似于GPU集群的操作系统,通过Dynamo能够充分用好GPU集群资源,实现资源最大化利用。在应对突发流量时,Dynamo调度器可自动平衡吞吐量与延迟,确保推理系统SLA。

 

Dynamo支持请求三层分级调度,每一层通过实时负载感知、实现请求动态调度决策,充分用好推理集群中的算力和存储。

  • 集群级调度(Smart Router)

Smart Router负责决定集群中哪台机器更适合接收处理新请求

  • 节点级调度(Node Agent)

Agent实时监控GPU资源和KV cache,实现在同一节点内,GPU之间动态分配请求

  • GPU内核调度(Device Scheduler)

同一张GPU上,微观调度不同请求的 token

Dynamic GPU scheduling关键特性

Fine-Grained Partition
同一张GPU切成小块,高效复用
Token-level Scheduling
按token动态插入调度,降低尾延迟
Dynamic Batching & Repacking
实时合并小请求,提升吞吐
Hierarchical Scheduling
集群-节点-GPU内多层次优化
QoS-aware Scheduling
不同请求优先级控制,满足SLA
  • LLM-aware request routing

传统推理系统常用的路由策略有

· Round Robin(轮询)

· Least Load(挑当前负载最低的节点)

· Static Sharding(固定某模型在某些节点)

Dynamic为推理系统提供更加智能的路由策略,解决不同模型不同推理阶段请求特性不同导致路由策略失效出现集群节点间负载不均衡,尾延迟爆炸,ITL无法保证最终影响终端用户的推理体验。

Dynamo通过request profiling实现对每个请求的精准把控,通过请求特征分析就能够更精准的预测负载。

请求ID
模型
Prompt Tokens
Output Tokens
预估负载
Req-123
Llama2-13B
200
50
中
Req-456
Mistral-7B
10
20
轻
Req-789
Mixtral-12x7B MoE
2000
4000
极重

和Dynamic GPU scheduling一样,实现LLM-aware intelligent routing也需要实时掌握Node和每个GPU的运行时状态。在Smart Router层维护一张全局资源表实现请求精准路由

节点
可用GPU
空闲KV Cache
Token速率
健康状态
Node1
8张/8张
80%
12k tokens/s
OK
Node2
5张/8张
40%
8k tokens/s
OK
Node3
6张/8张
90%
15k tokens/s
OK
Node4
2张/8张
20%
5k tokens/s
Degraded

Dynamo smart router在路由时,会根据请求负载Profile、节点资源Map、历史推理表现(token速率,延迟)、预期延迟目标(QoS)。动态做出请求匹配决策,比如:

  • 轻量短文本请求 → 发到空闲的Node3

  • 超大请求(小说续写) → 发到Node1上显存充裕的GPU

  • Streaming请求 → 发到延迟最低的节点

  • 节点健康不佳 → 自动避开

  • 如果模型类型不兼容(节点上没这个模型)→ 拒绝或转发到冷启动

而且 Dynamo Smart Router 会不断实时反馈校正:

  • 发现延迟超过预期 → 动态调低该节点评分

  • 某节点负载上升太快 → 适当做 backpressure(限流)

  • 节点故障 → 自动重路由到其他节点

通过Smart Router可以精准的判定每个请求的负载,从而实现更可控的请求路由。

请求
模型
Prompt Tokens
Output Tokens
类型
Req-A
Llama2-7B
5
20
轻
Req-B
Mixtral 12x7B
1000
3000
重
Req-C
Mistral-7B
100
50
中

最终实现,集群负载均匀,高优先请求优先得到快速响应,GPU资源最大化利用,整体P99延迟、吞吐量大幅优化,同时,消除不必要的KV缓存重新计算,极大程度提升系统整体性能。

  • Accelerated data transfer

分布式推理工作负载给系统带来了复杂的挑战,包括但不限于网络和通信问题。这些挑战涵盖高性能要求、跨越内存和存储的异构数据路径,以及动态扩展和缩减的需求。

NIXL 旨在通过解决推理框架面临的挑战,同时提供高带宽、低延迟的点对点数据传输,从而为其提供支持。它通过一个多功能 API,为各种内存类型(包括 HBM、DRAM、本地或远程 SSD 以及分布式存储系统)提供统一的抽象。该 API 可以支持多种后端插件,例如 UCX、GDS、S3 以及其他协议或客户端。此外,NIXL 还抽象出了其他后端细节,例如连接管理、寻址方案和内存特性,以简化与推理框架的集成。

NIXL 作为一个独立库运行,为各种网络和存储后端提供必要的抽象,以支持分布式推理平台(例如 NVIDIA Dynamo)的数据平面操作。NIXL 目前支持的后端包括UCX和NVIDIA Magnum IO GPUDirect Storage。对其他文件系统(包括 DFS)、块存储和对象存储的支持正在开发中。NIXL 提供通用接口,能够支持以张量、字节或对象形式进行数据传输。

640-2

在LLM推理过程中,尤其采用了PD分离架构之后,KV cache跨节点之间的同步变得非常频繁, 初次推理时,prefill要把 Prompt(输入tokens)计算成KV 搬到GPU显存中,decode(token生成)时,需要不断读取KV cache并更新 KV Cache(键值缓存)。显而易见的,当prefill instance和decode instance分布在不同node时,KV的传输是非常频繁的,decode节点解码完成时,还需要将结果返回给请求处理节点并返回客户端。过程中的网络交互传输是非常频繁的,如果网络层性能不稳定延迟高,将严重影响推理系统的性能和用户体验, Dynamo使用高性能的NIXL网络传输库减少推理过程中的网络交互时间。

技术手段:

Pinned Memory + RDMA Transfer

Dynamo在CPU端分配专门的 pinned memory buffer,防止系统换页导致缓存失效降低数据拷贝开销,通过RDMA Zero-copy实现从一台node GPU memory到另一台node GPU memory,过程中cpu不参与,显著降低cpu负载和延迟。

In-GPU KV Cache Update

Dynamo 使用kernel fusion技术把token decode、KV update、token append打包成一个CUDA kernel执行。实现KV Cache更新直接在GPU上完成。update过程bypass cpu,KV cache更新降低了cpu参与次数,减少了数据拷贝,降低了延迟。

KV cache offloading

Dynamo提出KV Cache Manager利用多个内存层次结构实现更高的系统吞吐量。

640-3

计算用户请求的 LLM 键值对资源消耗巨大,因此成本高昂。利用kv缓存来最大程度地减少重复计算是常见的做法。然而,随着 AI 需求的增长,在固定预算下,仅依靠 GPU 内存进行键值缓存已无法满足 SLA 的要求。因此,亟需一种更有效的键值缓存重用管理机制。

Dynamo KV Cache Manager 就是为解决这一难题提出,它支持将较旧或访问频率较低的 KV 缓存块卸载到更经济高效的内存和存储解决方案(例如 CPU 内存、本地存储或网络对象存储或文件存储)。此功能使企业能够以远低于 GPU 内存成本的成本存储高达 PB 级的 KV 缓存数据。通过将 KV 缓存卸载到其他内存层级结构,开发人员可以释放宝贵的 GPU 资源,同时仍保留和重用历史 KV 缓存,从而降低推理计算成本。

Dynamo KV Cache Manager 采用先进的缓存策略,优先将频繁访问的数据放入 GPU 内存,而将访问较少的数据迁移到共享 CPU 内存、SSD 或网络对象存储。它集成了驱逐策略,在过度缓存(可能导致查找延迟)和缓存不足(导致查找丢失和 KV 缓存重新计算)之间取得平衡。此外,此功能还可以管理跨多个 GPU 节点的 KV 缓存,支持分布式和分解式推理服务,并提供分层缓存功能,在 GPU、节点和集群级别创建卸载策略。

机制与策略分离

  • 机制:管理内存分配、缓存层次结构和数据流。
  • 策略:确定缓存策略,包括数据结构的选择(例如,基数树、分布式哈希表)和驱逐算法。

这种分离确保了底层基础架构能够在不破坏缓存逻辑的情况下进行演进。这一设计决策旨在使每个客户都能制定适合其访问模式的内存管理策略和机制。

分层缓存

  • 基数树提供了一种简洁、结构化的方法,用于在分布式推理中组织键值存储。每个节点可以构建一个本地树,并在集群级别构建一个全局树,从而确保高效的抽象。
  • 该层级涵盖 HBM、本地节点键值存储和外部存储,每一层都会缓存下一层的数据,以优化查找。跨层数据移动使用 NIXL API 进行处理,实现无缝通信。数据流完全异步,对工作实例透明。
  • 只要与 KV 管理器 API 兼容,就可以支持多个后端。
  • 为了获得最佳性能,优先使用 RDMA 传输。

运行时注册

  • 分布式 KV 管理器向推理引擎运行时注册,以将 KV 卸载到池中。
  • 注册会在运行时和池之间创建一个双向通信队列。

管理和传输粒度

  • KV 块在块级别(令牌组)进行管理,但 KV 状态的传输可以在层级别进行。
  • 如果需要获取多个token,则这些层传输将并行化,以确保 KV 池的最大吞吐量。
本作品采用 知识共享署名 4.0 国际许可协议 进行许可
标签: AI推理系统 GPU调度 分布式推理
最后更新:2025年8月6日

七脉神剑

这个人很懒,什么都没留下

点赞
< 上一篇

文章评论

razz evil exclaim smile redface biggrin eek confused idea lol mad twisted rolleyes wink cool arrow neutral cry mrgreen drooling persevering
取消回复

COPYRIGHT © 2026 75live.com. ALL RIGHTS RESERVED.

Theme Kratos Made By Seaton Jiang