何时使用“编码-预填充-解码”解耦技术来加速多模态模型服务

编码 – 预填充 – 解码 (EPD) 分解是一种适用于多模态模型的推理优化技术,可将视觉编码器阶段与预填充和解码阶段分离开来。它对于图像密集型提示词、中短输出和量化专家混合 (MoE)模型最为有效。

本文介绍了何时以及如何将 EPD 解聚 与 NVIDIA Dynamo 结合使用,从而将生成第一个token (TTFT) 的时间缩短高达 5 倍,并将端到端响应时间缩短 7 倍。本文还介绍了不推荐进行 EPD 分解 的场景。

Dynamo 是一个开源推理框架,用于在分布式环境中服务 AI 模型。它支持 EPD 分解,将这些阶段分离为独立可扩展的阶段,而不是将它们与紧密合的调度和扩展模式一起运行。专用编码器工作者可以提高批处理、内存效率和整体吞吐量。

为什么 EPD 解很重要?

在 LLM 预填充开始之前,多模态请求会添加工作。服务堆栈必须对媒体进行预处理,并运行视觉转换器 (ViT) 以生成嵌入。在聚合服务中,视觉编码、LLM 预填充和解码都共享一个 worker 和一个调度域。当媒体处理仅占工作负载的一小部分时,这种简单的设计效果很好。

Bar chart showing encoder work dominates TTFT for multi-image and video requests.

图 1. 跨单图像、多图像和视频请求的 TTFT 细分,分为媒体预处理、ViT 前向和投影以及 LLM 预填充

当请求包含更多图像或视频时,余量会发生变化。视觉编码可能需要数百毫秒或更长时间。由于编码器和 LLM 工作共享相同的 GPU,媒体密集型请求可能会延迟其自身的预填充,并与并发预填充和解码工作相抗衡。相比之下,在混合流量下,即使不需要视觉编码,纯文本请求也可能会在多模态请求后等待。

Dynamo 通过分离编码器和 PD 工作者角色来实现 EPD 服务,而无需固定其硬件位置。编码器工作者生成视觉嵌入,而 PD 工作者使用这些嵌入并运行 LLM。这种分离允许各个阶段分别进行批量、调度和扩展。图 2 比较了聚合服务和 EPD 服务,其中编码工作者通过 NVIDIA 推理传输库 (NIXL) 将嵌入传递给 PD 工作者。

Flow diagram comparing aggregated and EPD serving, with encode workers passing embeddings to PD workers through NIXL.

图 2. 在 Dynamo 中聚合和 EPD 请求流。EPD 将编码执行与 PD worker 分离,并通过 NIXL 传输嵌入

只有在某些场景中,编码分解才能减少 TTFT,并增加相同 SLO 的良好输出。隔离的编码工作必须足够大,以抵消工作协调和嵌入传输开销。编码工作者可能会共享 PD GPU 或在单独的 GPU 层上运行,从而产生不同的放置选项。在这里,我们将探索编码工作进程的不同放置选项,以及它们在各种场景下产生的优势。

三种编码放置拓扑

图 3 将聚合服务与两种编码器解拓扑 (共置和解拓扑) 进行比较:

  • 聚合:每个 GPU 运行一个聚合 worker,其调度程序在同一请求生命周期中管理视觉编码、LLM 预填充和解码。
  • 协同编码器:每个 GPU 与一个 PD 工作节点一起运行一个或多个编码器工作节点。这允许工作者共享 GPU 计算,同时维护单独的请求队列和批处理。在同构集群中,Colocated Encoder 通常更适合。相对于 LLM,视觉编码器的重量较轻,因此为编码器工作预留完整的同等级 GPU 可能会导致大部分 GPU 未得到充分利用。托管可分离工作节点,而无需将 GPU 专用于编码器。
  • 分类编码器:当集群包含更适合编码器工作的低成本 GPU 层,而主要 GPU 层托管 PD worker 时,分类编码器就会变得很有吸引力。Dynamo 通过 NIXL 将生成的视觉嵌入传输到 PD 层。在我们的测试环境中,两个 NVIDIA RTX 6000D GPU 运行编码器工作节点,四个 NVIDIA GB200 GPU 运行 PD 工作节点。这种布局可在 RTX GPU 上保留较轻的编码器工作负载,并为计算和内存密集型 LLM 工作负载预留 GB200 GPU。请注意,此分析不考虑使用同构 GPU 的解设置,因为它始终低估了共置编码器设置。

硬件可用性决定了编码器的运行位置,而工作负载特性则决定了将其分离是否会带来回报。

Diagram of three encoder placements: aggregated (one worker), colocated (shared GPU through CUDA MPS), and disaggregated (RTX encoders, GB200 PD).

图 3. 三种编码放置选项:聚合服务、共同定位编码器和 PD 工作节点,以及为编码器工作节点提供单独的低成本 GPU 层的解编码器

哪些因素决定了 EPD 分解的优势?

EPD 的优势取决于视觉编码、LLM 预填充和解码工作的分配方式。当视觉编码在请求处理时间中占很大比例或限制吞吐量时,EPD 非常有用。媒体密集型请求通常会造成这种情况,但媒体加载本身并不能决定结果。输出长度、模型大小和精度以及流量组合也会改变这种平衡。

因子为什么它对 EPD 很重要EPD 何时产生收益
输入媒体负载媒体负载越重,视觉token就越多,这意味着编码器的工作量也就越大。EPD 允许纵向扩展编码器,从而防止编码瓶颈。生成更多视觉token的多张图像、高分辨率图像或视频输入。
输出序列长度 (OSL)更长的 OSL 会将总延迟转为解码。TTFT 从 EPD 持有中获益,但端到端 (E2E) 收益缩小。短 OSL:E2E 获得长期 OSL 支持:E2E 获得侵蚀
模型大小/ 精度ViT 计算在很大程度上是固定不变的,而 LLM 计算会随着活动参数的减少和精度的降低而减少。因此,小型 MoE 和量化 LLM 具有更高的 ViT 与 LLM 的计算比。较小、MoE 和较低精度的模型从 EPD 中受益更多,而大型密集型模型的增益更少。
混合流量 (文本+ 多模态)混合预填充批量会导致文本请求等待 ViT 处理。EPD 隔离编码器工作,允许文本请求跳过等待编码器的过程。混合了大量多模态流量和延迟敏感型文本请求。

表 1. 各种因素如何影响 EPD 性能

测试环境

除精度消融实验外,所有基准测试均使用 Qwen3.5 122B A10B NVFP4 运行。我们使用了四个 GB200 GPU (以及在解设置中额外使用的 RTX 6000D GPU) :

  • 聚合:每个 GB200 聚合一个 TP1 工作者
  • 共享 EPD:每个 GB200 配备 2 个编码器工作节点和 1 个 PD 工作节点
  • 解 EPD:以 RTX 节点作为编码器层,以 GB200 作为 PD

我们使用 NIXL over UCX RC/ TCP 以太网进行视觉嵌入传输,测量峰值为 20 Gbps。我们使用了启用前端并行媒体解码的 Dynamo 前端。有效输出 SLO 是低于 100 毫秒的token间延迟 (ITL) 。

图像密集型工作负载示例

我们在以下请求中将聚合服务与编码器解服务进行了比较:在 OSL 1024 下,每次请求提供 10 张图像 (每张图像上限为 256 个token) ,以模拟具有长输出序列的中等负载视觉工作负载。图 4 显示了结果。

Bar charts showing ~2x TTFT reduction and ~1.5x goodput gain with EPD for 10 images/request.

图 4. 跨拓扑的平均 TTFT 和端到端延迟,适用于图像密集型工作负载 (每请求 10 张图像) (左) 。在 ITL SLO 低于 100 毫秒的情况下,与聚合设置相比,输出更出色 (右)

使用共置编码器时,TTFT 下降了 58%,使用异构编码器时,TTFT 下降了 50%。端到端改进幅度不大,因为 OSL 1024 意味着模型会生成 1024 个 token,而且编码器解聚不会缩短解码时间。信号越大,输出越好:异构层在相同延迟 SLO 下服务的流量增加了 70%,因为编码器容量增加了,而没有影响 GB200 预算。

镜像加载和 OSL 如何影响性能提升?

我们在一系列实验中分析了对 TTFT 和端到端延迟的影响,这些实验使用 5-50 张图像,每张图像使用 128/ 256 token预算,保持 OSL 不变。在聚合编码器场景中,TTFT 和端到端延迟的性能都会降低,而对于两种解拓扑而言,性能相对稳定。

Two side-by-side line charts showing aggregated TTFT rising steeply with image count while both EPD topologies stay flat.

图 5. 平均 TTFT 与视觉标记负载 ( 5 至 50 张图像,OSL 512) 。聚合延迟随着视觉token (每张图像的图像数量乘以token) 的图像数量急剧增加;两种 EPD 拓扑几乎保持不变

接下来,我们将 OSL 从 128 改为 2048,同时将图像加载固定为 5 张图像。随着 OSL 的增加,TTFT 在很大程度上保持不变,但解码时间越来越多地主宰了端到端延迟。因此,与聚合服务相比,异构 EPD 端到端收益从 20.3% 缩小到 5.2%。位于同一位置的编码器从 11.8% 的增益转变为 2.5% 的回归,因为其附加编码器工作节点与 PD 工作节点共享相同的 GPU。随着 OSL 的增加和解码压力的增加,GPU 争用会越来越多地抵消并最终超过编码器解的优势。

Line chart showing EPD end-to-end latency advantage over aggregated narrowing as OSL increases.

图 6. 均值 端到端 延迟与 OSL 的对比。这个 端到端 随着 OSL 的增长,由于解码时间越来越占主导地位,因此 EPD 和聚合窄带之间的差距

图 7 和 8 显示了 TTFT 和端到端延迟相对于一系列 OSL 和图像负载的聚合 (基准) 的百分比改进。在几乎所有场景中,编码器解在高输入介质负载的情况下提供最大价值。在高 OSL 和低图像负载的场景中,解构编码器会降低性能。

Two heat maps showing 25–93% TTFT improvement over aggregated, with strongest gains at high image counts.

图 7. 输入图像加载 (图像数量乘以视觉token) 。TTFT 优于聚合 (Qwen 3.5 122B NVFP4) 。共享 EPD (上) 和异构 EPD (下) 。两种拓扑均可将整个电网的 TTFT 提升 25-93%。最重的单元 ( 50 x 128 张图像,任何 OSL) 达到 92-93%。由于 TTFT 不受输出长度的影响,因此在 OSL 维度上的增益是一致的

Two heat maps showing end-to-end gains largest at high image load and short OSL, shrinking with lighter media and longer outputs.

图 8. 相较于聚合 (相同的模型和硬件) ,端到端请求延迟得到改善。在高图像负载和短 OSL 下,增益很强,向左上角收缩 (光线媒体、长输出) 。协同运行的 EPD 显示略有变化 端到端 在 5 x 128 张图像/ OSL 2048 (-2.5%) 下进行回归,其中编码器容量节省无法恢复嵌入传输开销

模型大小和精度如何改变 EPD 收益?

随着模型大小的增加,LLM 在服务工作负载中占据更多,而视觉编码器的大小大致保持不变。为了量化这对 EPD 的影响,我们在 Qwen3.5 4B、Qwen3.5 9B 和 Qwen3.5 27B 上运行了模型大小消融。ViT 参数占比从 4B 时的 7.2% 降低到 9B 时的 4.7% 和 270B 时的 1.7%。托管式 EPD 遵循相同的趋势,可分别提供 2.62 倍、1.50 倍和 0.65 倍的聚合服务输出。

Bar chart showing colocated EPD goodput over aggregated declining with model size and rising with MoE/quantization.

图 9. 与跨模型配置的聚合服务相比,SLO 良好的输出收益相同。EPD 增益会随着模型大小的增加而减少,即使在 270 亿个模型下,也会下降到低于平衡点。激活参数较少的低精度模型和 MoE 模型显示更大的收益

参数共享只是更直接因素的代理:ViT 前向、LLM 预填充和解码之间的运行时平衡。当 ViT 转发占请求处理时间的重要部分时,EPD 提供了更多优势。随着预填充和解码成为主流,需要优化的编码器工作也会减少。在我们的 270B 配置中,LM 的成本超过了在托管设置下分离编码器的优势。

我们测量了 LLM 精度对 EPD 增益的影响。当视觉编码器和 LLM 都使用 BF16 时,共享 EPD 提供了 1.78 倍的聚合服务输出。仅将活跃的 LM 权重量化为 NVFP4 后,此增益提升至 2.64 倍。

Bar chart showing co-located EPD goodput rising from 1.78x to 2.64x when LLM precision drops from BF16 to NVFP4.

图 10. LLM 量化对 EPD 输出的影响。柱形图显示了相对于聚合服务的共置 EPD 良好输出。通过量化 BF16 到 NVFP4 的活动 LM 权重,该比率从 1.78 倍提高到 2.64 倍。在这两种配置下,视觉编码器均保留在 BF16 中

NVFP4 可加速 LLM 预填充和解码,而 ViT 正向则保留在 BF16 中,从而将更大比例的请求时间转移到编码器工作上。这为 EPD 提供了更多空间,可以独立于 PD 工作负载来调度编码器工作负载。

EPD 如何帮助混合模态请求

生产工作负载通常混合纯文本和多模态请求,这两种请求类型可以一起调度以进行预填充。借助聚合服务,一名工作者可同时处理视觉编码和 LLM 预填充。如果批量包含多模态请求,则工作节点会在开始预填充之前完成媒体预处理和 ViT 转发。纯文本请求不需要这项工作,但仍然可以等待它,从而增加其 TTFT。

EPD 通过在单独的编码器工作流上运行视觉编码来消除这种依赖关系。前端会将这两种请求类型路由到预填充工作器,但只有缺少嵌入的多模态请求才能调用编码器池。纯文本请求可以继续进行预填充,而编码器则独立处理多模态请求,从而减少两种请求类型之间的线头阻塞。

为了衡量这一点,我们将聚合服务与持续混合文本和图像流量下的协同编码器进行了比较。

Bar chart showing co-located EPD cutting text TTFT by 42% and image TTFT by 31% under 50/50 mixed traffic.

图 11. 在 OSL 128 下 50:50 持续混合流量下的文本和图像请求的平均 TTFT (与协同定位编码器的聚合服务比较)

编码器解聚将文本请求的平均 TTFT 从 92.3 毫秒降低到 53.3 毫秒,减少了 42.2%。图像请求 TTFT 从 289.9 毫秒降至 200.6 毫秒,减少了 30.8%。图像请求仍然会产生编码器延迟,而文本请求可以开始 LLM 预填充,而无需等待视觉编码完成。这是在文本请求 TTFT 中相对改进较大的原因。

如何选择最佳编码器拓扑

编码器的最佳放置位置取决于请求所花费的时间。当视觉编码代表请求处理的重要组成部分时,例如媒体密集型输入、中短输出、较小模型或量化模型以及混合流量,EPD 可提供最大价值。当媒体处理速度较慢或长解码序列主导延迟时,聚合服务仍然是一个很好的选择。

硬件也会影响放置决策。在同构集群上,位于同一位置的编码器可将编码器调度和批处理分开,而无需为相对轻量级的视觉模型预留整个 GPU。单独的编码器层对于异构硬件更有用,其中较低级别的 GPU 可以运行编码器,而高端 GPU 仍然专用于 PD。

请注意,vLLM 和 SGLang 具有进一步开发其 EPD 堆栈的路线图。

开始使用 EPD 分解

要重现本文中介绍的实验,请遵循 AI – dynamo/dynamo GitHub 指南。

如图 1 所示,在 ViT 开始之前,TTFT 花费了 43%。EPD 无法帮助优化管道的这些阶段。尝试以下 Dynamo 中列出的其他手段,以解决堆栈的不同阶段问题。

并行媒体解码可将下载和解码从工作流中移出,然后进入 Dynamo 前端,后者会将解码后的像素传输到后端。在仅对编码器进行的基准测试中,在具有两个编码工作器的一个 GB200 上,其性能为 30 × 256,在匹配的吞吐量下,它将编码器请求的平均延迟从 271.3 毫秒降低到 207.0 毫秒,降低了 26%,将 P99 的平均延迟从 752.1 毫秒降低到 581.7 毫秒,降低了 23%。使用 --frontend-decoding 启用它。

在 CPU DRAM 中嵌入缓存存储并卸载计算的嵌入,因此重复的媒体不会被重新编码。当图像或视频等相同的多模态内容在多个请求中出现时,系统会重复使用缓存的嵌入,而无需再次运行视觉编码器。

多模态 KV 路由会将媒体内容与 Dynamo KV 感知路由器中的文本一起哈希处理,以便在已持有相关 KV 块的工作者上请求共享媒体。如果没有它,每张图像看起来都与路由器的占位符token相同。

致谢

我们要感谢 Inferact 联合创始人 Roger Wang 对此博文的反馈,并感谢 NVIDIA 团队 Alexandre Milesi、Ayush Agarwal、Guan Luo、Indrajit Bhosale、J Wyman、Kris Hung、Krishnan Prashanth、Qi Wang 和 Zhongdao Ren 在 Dynamo 中就多模态支持所做的核心工作。

原文来源:NVIDIA 技术博客原文

相关推荐

使用 NVIDIA RTX Spark 在一台机器上进行编码、测试和部署

NVIDIA RTX Spark 将本地编码智能体、模型微调、编译、测试与部署整合到一台机器。本文介绍 GB10、128GB 统一内存与 Grace/Blackwell 架构的开发性能,Windows on Arm、PyTorch-CUDA 和 CUDA-X 软件生态,以及 Pi、Junie Local、Nemotron 模型、媒体 AI SDK 和现有 Windows 应用迁移路径,帮助开发者在本地构建并部署 AI 应用。

NVIDIA_Community的博客 355

深入了解 NVIDIA Sentry:运行时安全 AI 智能体

本文介绍 NVIDIA Sentry 如何在 BlueField-4 DPU 的独立信任域中为 AI 智能体提供运行时保护。通过 DOCA Tower 检查通信与执行访问策略,结合 DOCA Argus 实时内存内审、身份验证、专用模型行为检测和防篡改遥测,将 OpenShell 的软件安全边界扩展到硬件隔离防护,并与企业 XDR、SIEM 平台集成。

NVIDIA_Community的博客 413

NVIDIA OpenShell 参考架构如何大规模保护和治理 AI 智能体工作负载

本文介绍 NVIDIA OpenShell 参考架构如何在智能体之外实施确定性治理,并结合 NVIDIA Vera CPU、BlueField-4 DPU 和 NVIDIA Sentry,构建兼顾性能、隔离与运行时安全的可扩展智能体基础设施。涵盖网关、Supervisor、沙盒、策略验证器,以及 CoreWeave 的沙盒启动和智能体任务性能测试。

NVIDIA_Community的博客 227

China AI Infra Day 从物理到虚拟:网络基础设施驱动 AI 工厂 重磅来袭!

存储架构,解析如何减少重复计算、加速推理响应,提升规模化。3. 填写报名信息并提交,即可完成注册。网络创新与重要动态,聚焦五大网络架构与。或复制并打开以下链接,进入报名页;从物理到虚拟:网络基础设施驱动。本次在线研讨会将探索。技术专家带你打破技术壁垒,解锁。更有价值:网络与存储的协同之道。加入本次研讨会微信直播交流群。构建超大规模网络:适用于百万。工厂性能优化与部署验证。打破数据瓶颈:面向代理式。数字孪生,探索超大规模。:围绕网络与存储协同、高性能组网实现十亿瓦级。:聚焦五大网络架构、

NVIDIA_Community的博客 126

NVIDIA AI 培训班 | 10 月 29 日《为大语言模型添加新知识》开课,转化开源 LLM 为领域 AI 资产

课程以 Meridian Response 为基础,这是一个虚拟的人道主义物流组织,需要对传入的防洪响应现场报告进行分类并将其分配到正确的团队。您将首先构建一个评测,定义该任务“更好”意味着什么,然后度量一个库存 8B 开放权重模型,测试提示词的上限,生成针对性的合成训练数据,使用监督微调训练 LoRA 适配器,并在任务行为基本到位后,使用直接偏好优化 (DPO) 来提高响应质量。,访问 NVIDIA 认证中文官网,点击每一门认证科目介绍页面,查看详细的考试大纲、考前学习指南、推荐培训和更多资源。

NVIDIA_Community的博客 229

密集与 MoE 模型:活动参数、吞吐量以及选择每个模型的时间

本文比较密集模型与 MoE 模型的活动参数、吞吐和路由机制,说明在质量、延迟、显存与部署约束下如何选择模型架构。

NVIDIA_Community的博客 169

如何使用 AI 智能体准备用于仿真的 3D 场景

本文展示 AI 智能体如何把 Blender 场景准备成用于仿真的 OpenUSD 资产,包含语义、材质、传感器、物理属性、渲染预检和 SimReady 验证。

NVIDIA_Community的博客 366

借助 NVIDIA Earth-2,将您的最新观测结果转化为及时的天气决策

本文介绍如何用 NVIDIA Earth-2 和 Earth2Studio 将最新气象观测纳入预测,演示区域与全球数据同化工作流,以及 CorrDiff-SDA、StormCast-SDA 和 HealDA。

NVIDIA_Community的博客 265

TensorRT Edge-LLM 在 Jetson AGX Thor 上实现 MLPerf Edge Agentic Benchmark 6.4 倍加速

本文分析 TensorRT Edge-LLM 在 Jetson AGX Thor 上完成 MLPerf Edge Agentic 基准测试的优化方法,包括 NVFP4 量化、KV 缓存复用和多 token 预测。

NVIDIA_Community的博客 104

如何评估从工具调用到任务完成的 AI 智能体

本文介绍从工具调用到任务完成的 AI 智能体评估方法,涵盖任务成功率、执行时间、成本、可复现基准和端到端验证。

NVIDIA_Community的博客 87

使用 AI 智能体和 NVIDIA Isaac ROS 加速 ROS 2 节点

本文展示如何用 AI 智能体与 NVIDIA Isaac ROS 加速 ROS 2 节点,通过识别数据传输瓶颈、采用 CUDA 缓冲区后端并验证机器人工作流的性能。

NVIDIA_Community的博客 67

面向游戏开发者的新功能:DLSS 5 (支持 3D 引导神经渲染) 、NVIDIA ACE 更新和全新 RTX Kit 功能

本文汇总面向游戏开发者的 DLSS 5、NVIDIA ACE 与 RTX Kit 新功能,介绍 3D 引导神经渲染、开发者控制和角色交互等技术。

NVIDIA_Community的博客 285

NVIDIA NVLink 6 如何为 AI 工厂提供多层弹性

本文说明 NVIDIA NVLink 6 为 AI 工厂提供的多层弹性机制,包括链路、交换与系统级故障恢复,及其对训练和推理服务连续性的作用。

NVIDIA_Community的博客 67

借助 NVIDIA Dynamo-Triton 中的 NVIDIA TensorRT 多设备集成,简化跨多个 GPU 的模型服务

本文介绍 NVIDIA Dynamo-Triton 对 TensorRT 多设备推理的集成,展示如何在多个 GPU 上部署模型,并通过 Cosmos 3 上下文并行测试延迟与输出一致性。

NVIDIA_Community的博客 55

借助 NVIDIA Topograph 实现拓扑感知型工作负载调度

本文介绍 NVIDIA Topograph 如何识别 GPU 集群拓扑,并在 Kubernetes、Slurm 等环境中为 AI 工作负载提供拓扑感知调度,减少跨域通信和资源浪费。

NVIDIA_Community的博客 92

借助 NVIDIA 机密计算实现私有高性能生产级 AI 推理

本文介绍 NVIDIA 机密计算如何在私有生产级 AI 推理中保护敏感数据,并比较机密计算开启与关闭时的吞吐和延迟,分析数据传输、内核调优及多 GPU 通信的性能开销。

NVIDIA_Community的博客 52

介绍 CUDA Rust:用于编写 GPU 内核的两条轨道

CUDA Rust 提供 cuda-oxide 与 cutile-rs 两条原生 GPU 内核开发路径。前者保留 SIMT 线程控制,后者使用 Tile 抽象和 CUDA Tile IR。本文比较编译链、内存安全与当前成熟度。

NVIDIA_Community的博客 151

CUDA 工具包 13.4 在 Arm 上添加了 Windows 支持,并增强了对共享 GPU 的控制

CUDA 13.4 扩展 Windows on Arm 支持,预览 Rubin 架构,并更新 MPS V3、跨 GPU 传输、CUDA Python、CCCL 与 Nsight 工具。本文梳理对应用迁移和共享 GPU 管理最关键的变化。

NVIDIA_Community的博客 134

GR-Inference:面向生成式推荐的推理系统设计与性能评估

生成式推荐具有长上下文、极短解码和数百条动态 Beam。GR-Inference 通过请求级状态管理、分离 KV、专用 Attention 与 GPU SID Trie 优化这一负载,并在给定 SLA 下提升吞吐。

NVIDIA_Community的博客 327

使用预测解码共同设计 AI 模型,加快 LLM 推理速度

预测解码通过草稿 token 与目标模型并行验证减少自回归迭代。本文梳理草稿长度、接受长度、验证成本与草稿成本的关系,以及在不同延迟和吞吐目标下选择草稿机制的方法。

NVIDIA_Community的博客 293

现代 CUDA 工具箱的实际应用:分步优化演练

以 RGB 图像转灰度并计算 32×32 图块中值为例,串联 Compute Sanitizer、Nsight Systems、CUB、CCCL 内存容器和 CUDA 流,说明如何先定位错误与瓶颈,再逐步优化 GPU 程序。

NVIDIA_Community的博客 298

使用 NVIDIA Nemotron 构建自适应代理式网络安全系统

NVIDIA 与 CrowdStrike 在隔离环境中评估红蓝智能体闭环:攻击生成遥测,防御智能体编写并验证检测,再以新攻击复测。文章介绍 Nemotron 分工、检测验证机制、实验结果及其适用边界。

NVIDIA_Community的博客 83

前沿推理触手可及:如何在 NVIDIA Jetson 上部署和优化模型

紧凑型开放推理模型已能在 NVIDIA Jetson 本地运行。本文比较 Nemotron 3.5 Lightning 与 Qwen3.8-27B 的架构取舍,解释 NVFP4 与预测解码的作用,并给出部署和工作负载验证思路。

NVIDIA_Community的博客 282

构建面向大规模 VLA 的端云协同后训练闭环:使用 verl-vla 统一数据采集、微调与强化学习

大规模 VLA 的推理、仿真、数据采集和人工干预往往分散在云端 GPU、仿真节点与真实机器人上。verl-vla 通过 TrainCluster、Web 遥操作和可组合 Workflow,把示范采集、监督微调、评测与强化学习接入同一端云闭环,并提供 Isaac GR00T、Isaac Lab Arena、RECAP 与 DSRL 的可复现配方。

NVIDIA_Community的博客 305

使用 NVIDIA NemoClaw 构建内存驱动型智能体

本文介绍基于NVIDIA NeMo Claw构建的内存驱动型智能体——办公室主任,通过结构化自我模型(人员、项目、优先级等)实现企业工作流的持续上下文维护与决策优化。该设计强调证据、知识与行动分离,支持选择性检索、用户校正与审计追踪,提升任务准确性与可信度。实测显示,其在事实跟踪、实体消歧、多源合成等任务上显著优于传统RAG。结合NVIDIA OpenShell实现安全沙盒运行,保障权限与边界控制。文章提供可复用的开源配方,涵盖内存架构、分类帐与离线演练,助力开发者构建高效、可信的企业级智能体。

NVIDIA_Community的博客 388

使用 NVIDIA Isaac GR00T 开发端到端人形机器人策略

随着越来越多的团队从人形机器人启动转向特定任务的技能开发,对可重复开发工作流的需求也与日俱增。构建人形机器人仍然十分复杂,而且当今的开发流程仍然高度分散。因此,开发者在专注于构建机器人功能之前,会花费大量时间来配置机器人基础设施。虽然机器人社区已经开发出跨流程各个阶段的工具,但由于软件生态系统孤立、数据格式不兼容以及工具之间的手动集成,将它们连接到无缝工作流仍然是一项挑战。为解决这一问题,我们推出了:这是一个开源人形机器人平台,可统一流程的每个阶段,以加快开发速度。

NVIDIA_Community的博客 4084

让长时间运行的 NVIDIA TensorRT 引擎在 Python 或 C++ 中构建可观察和可取消

构建 TensorRT 引擎可能需要几秒钟到几分钟的时间。大型强类型模型、深度策略搜索和全新 GPU SKU 上的冷定时缓存可能会让开发者、最终用户或 AI 智能体盯着冻结的终端,而不知道是否要等待、重试或终止该进程。大多数 NVIDIA TensorRT 集成在构建过程中不会报告任何内容,或者无法提前终止。在长时间运行的智能体工作流中,这会浪费 GPU 小时并导致会话卡顿。图 1. 用于 TensorRT 引擎构建的实时嵌套进度条,由 IProgressMonitor 子类渲染TensorRT 提供。

NVIDIA_Community的博客 3724

如何借助 RL 智能体技能和 NVIDIA NeMo 运行自动研究工作流

编码正成为长期运行的机器学习 (ML) 工作流程的实用运算符。他们可以检查资源库、设置运行时、解决构建问题、启动实验、监控执行、分析指标并汇总结果。对于研究而言,这一点很重要,因为有意义的指标通常只有在基本实验基础设施就绪后才会出现。是 Andrej Karpathy 的一个开源 Python 项目,用于自动化 AI 和 ML 模型训练。通过这种方法,将高层次的目标转化为假设,编辑和测试真实的代码库,保留改进指标的想法,并将结果交还给人类研究人员。这使得团队能够从高性能开放模型 (例如。

NVIDIA_Community的博客 3595

在 NVIDIA GB200 NVL72 上使用 GPU 加速的 Presto 运行低延迟分析工作负载

是一个开源分布式 SQL 引擎,可对超大型数据集快速运行交互式查询。在 NVIDIA GPU 上,Presto 可为分析查询工作负载提供峰值性能,并为用户和智能体提供低延迟。GPU 加速的 Presto 可降低分析工作负载的延迟,让您和智能体畅通无阻并尽可能快地进行迭代。本文将介绍如何使用单节点和多节点在扩展分析基准测试中高效执行多 GPU Presto。我们还强调了在与数据源搭配使用时对 NVIDIA GB200 NVL72 上的高 I/ O 吞吐量的重要性。

NVIDIA_Community的博客 3687

案例分享 | 基于 NVIDIA DGX Spark 的智能安防与工业智能方案开发应用

NVIDIA DGX Spark以GB10超级芯片与128GB高速统一内存为核心算力底座,凭借轻量化、全流程、高性能的特性,系统性解决智能安防与工业智能方案研发过程中数据处理慢、模型迭代难、推理延迟高、落地验证繁琐等痛点。通过构建视频智能分析、设备预测性维护两大AI能力体系,全方位赋能安防智能化管控与工业数字化运维,为智慧城市、智能制造领域的轻量化AI研发与场景落地提供高性能、高可靠的标杆方案。后续可依托平台拓展更多细分场景AI模型,持续拓宽行业智能化应用边界。

NVIDIA_Community的博客 2909
上一篇: GR-Inference:面向生成式推荐的推理系统设计与性能评估
下一篇: CUDA 工具包 13.4 在 Arm 上添加了 Windows 支持,并增强了对共享 GPU 的控制
NVIDIA AI 技术专区
NVIDIA AI 技术专区 NVIDIA 官方账号 NVIDIA 官方账号
博客等级 码龄2年 632粉丝 213原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明:

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

余额充值