Blink: CPU-Free LLM Inference by Delegating the Serving Stack to GPU and SmartNIC

作者/机构: Mohammad Siavashi (KTH Royal Institute of Technology), Mariano Scazzariello (RISE), Gerald Q. Maguire Jr. (KTH Royal Institute of Technology), Dejan Kostić (KTH Royal Institute of Technology), Marco Chiesa (KTH Royal Institute of Technology)

A1 主要贡献

核心问题与研究目标：大型语言模型（LLM）推理正迅速成为数据中心的核心服务，但当前的服务栈将主机CPU置于编排和令牌级控制的关键路径上。这使得LLM的性能对CPU干扰非常敏感，不仅影响了应用程序的共存，还迫使运营商预留CPU空间，导致大量计算能力未被利用。本文的目标是设计一个端到端的LLM服务架构，通过将职责重新分配给智能网卡（SmartNIC）和GPU，将主机CPU从稳态推理路径中移除。

创新点与主要贡献：
本文的主要贡献如下：
* 识别出控制路径依赖是LLM推理的关键瓶颈。论文指出，现代LLM服务系统依赖于细粒度的、由主机驱动的控制，这使得它们对CPU干扰非常敏感，限制了资源的有效共享。
* 提出一种无CPU的LLM推理架构Blink。Blink是一种新型服务系统，通过将控制和数据职责重新分配给GPU和智能网卡DPU，将主机CPU从稳态关键路径中移除。
* 通过持久化内核实现GPU常驻控制。论文设计了一个GPU常驻调度器，取代了由主机驱动的解码循环，实现了无需每次令牌生成都与CPU交互的连续批处理、调度和KV缓存管理。
* 展示了强大的性能和隔离优势。即使在独立运行的环境中，Blink的性能也优于现有SOTA系统（吞吐量最高提升2.1倍，P99 TTFT最多降低8.47倍）。在CPU干扰下，Blink性能保持稳定，而现有系统性能则下降数个数量级。

下图展示了Blink在有CPU干扰的情况下，相比于其他三个生产级服务系统（SGLang, vLLM, TRT-LLM）的吞-吐量优势。Blink几乎不受影响，而其他基准系统则出现显著性能下降。


图1. 4个LLM服务系统在Qwen-3 30BA3B (MoE)模型上，以4 req/s的负载，在隔离和共存执行下的实现吞吐量。Blink不受共存影响，而基准系统性能下降。标注显示了共存与隔离吞吐量的比率。

A3 背景知识与关键洞察

2.1 主机CPU成为延迟瓶颈

主流LLM服务栈中主机CPU的角色。在所有主流LLM服务栈中，主机CPU负责协调自回归解码的每一次迭代。请求接纳、连续批处理、KV缓存块管理以及CUDA内核分派都在主机线程上执行。即使使用CUDA Graphs【27, CUDA Graphs, 2024, NVIDIA】来分摊单个内核的启动成本，调度器在每个解码步骤后仍需返回主机，以更新批次成员、管理KV缓存块表并分派下一个图。例如，一个vLLM实例采用多进程架构，包括一个API服务器、一个引擎核心和每个GPU一个GPU工作进程【48, vLLM Documentation — V1 Process Architecture, 2026, vLLM】；这种架构的资源占用会随着所选的并行策略而扩展，导致主机进程数量随部署配置迅速增长【47, vLLM Documentation — Process Count Summary, 2026, vLLM】。

主机-设备紧密耦合的后果。这种紧密的主机-设备耦合意味着对CPU的任何扰动，如抢占、缓存驱逐或页面遍历延迟增加，都会直接增加令牌间延迟（Inter-Token Latency, ITL）。此外，当主机重建微架构状态时，GPU处于空闲状态，并且由于解码是迭代的，这种惩罚会在数百个输出令牌上累积。这种主机抖动和令牌级延迟之间的反馈循环将在§2.2中进行量化。

近期优化并未根本解决问题。主机端调度开销的严重性已被注意到。分析研究报告称，在快速加速器上，CPU调度可消耗高达50%的端到端推理延迟【43, Can Scheduling Overhead Dominate LLM Inference Performance? A Study of CPU Scheduling Overhead on Two Popular LLM Inference Systems, 2024, Srivatsa et al.】。为此，近期的引擎修订版（如vLLM的V1引擎架构【50, vLLM V1: A Major Upgrade to vLLM’s Core Architecture, 2025, vLLM Team】和SGLang的重叠调度【39, SGLang v0.4: Zero-Overhead Batch Scheduler, FP8 Cache, and More, 2024, SGLang Team】）将主机端工作与GPU执行流水线化，以在正常操作条件下减少调度开销。这些优化减轻了CPU的参与，但并未将其从关键路径中移除。在共存部署时，其他租户会驱逐共享的LLC行和TLB条目，从而增加了本应被重叠隐藏的CPU操作的延迟。一旦主机端工作超过了可用于掩盖它的GPU执行时间，多余的延迟就会直接体现在每个令牌的生成时间中。正如§2.2所量化的，即使是中等程度的干扰也足以打破这种重叠，因为任何留在关键路径上的CPU工作都会将共享微架构的争用转化为每个令牌的延迟。

共存部署是常态。生产集群为了追求高利用率会积极地打包工作负载【34, Shenango: Achieving High CPU Efficiency for Latency-sensitive Datacenter Workloads, 2019, NSDI, Amy Ousterhout et al.】。集群调度器通常会将延迟敏感型服务与尽力而为或批处理作业共存部署，依赖优先级、cgroups和NUMA分区来管理干扰。运营商已经开发了一套成熟的隔离工具（如Intel CAT的末级缓存(LLC)分区、巨页和动态电压频率缩放(DVFS)调优），但所有这些缓解措施都假设延迟敏感型工作负载能容忍一定程度的CPU参与。对于LLM推理，其中CPU参与每个令牌的生成，即使是管理良好的共存也会引入逐令牌的抖动，最终累积成服务等级目标（SLO）违规。

2.2 动机性测量：CPU干扰

实验设置与观察。我们通过一个简单实验展示CPU干扰的影响。我们使用vLLM (v0.13) 【20, Efficient Memory Management for Large Language Model Serving with PagedAttention, 2023, SOSP, Woosuk Kwon et al.】在NVIDIA H100 GPU上服务Llama-3 8B模型【13, The Llama 3 Herd of Models, 2024, Aaron Grattafiori et al.】，服务器为双插槽Xeon Gold，并使用ShareGPT v3【33, OpenChat ShareGPT v3 Dataset, 2023, OpenChat Team】对话追踪（平均输入/输出长度为1019/463令牌）。所有配置均启用CUDA Graphs，并禁用超线程和DVFS。干扰源是运行pbzip2【11, Parallel Data Compression with bzip2, 2004, PDCS, Jeff Gilchrist】压缩大文件。我们在测量开始前完全预热服务引擎，并在整个运行期间（包括启动和排空阶段）进行性能剖析。

结果分析。Table 1揭示了问题的严重性。在pbzip2的干扰下，吞吐量下降了3.8倍，而P99首令牌时间（TTFT）膨胀了高达139倍。即使是中等程度的干扰也会导致显著的性能下降，表明LLM服务性能对CPU争用高度敏感。这种性能下降伴随着缓存未命中（LLC）、地址转换未命中（dTLB）和内存停顿的大幅增加，这与共享CPU资源争用情况一致。

Table 1. 共存对vLLM服务延迟和微架构计数器的影响。H100, Llama-3 8B, 7 req/s, 启用CUDA Graphs。

3.1 微架构层面的根本原因

地址转换加剧LLC争用。分析Table 1中的LLC停顿预算，揭示了一个由地址转换驱动的两阶段放大循环。在基准情况下，页面遍历活动（即TLB未命中时的页表遍历）占所有LLC停顿周期的85%，这与基于Python的服务栈在碎片化虚拟地址空间上运行的重翻译行为一致【21, The Impact of Dynamic Storage Allocation on CPython Execution Time, Memory Footprint and Energy Consumption: An Empirical Study, 2022, Christos P. Lamprakos et al.】。引入干扰后，TLB未命中总数仅适度增加（1.6倍），但每次未命中的成本却大幅增加：干扰程序的频繁内存管理操作（如madvise, mprotect, munmap）引发TLB失效，强制重新翻译，并同时用额外的数据和页表元数据污染共享LLC。原本能在LLC中命中的页表项现在必须一直访问DRAM，导致walk_active周期增加了3.8倍。总体而言，LLC停顿周期增加了11.2倍，而归因于页面遍历的停顿比例降至25%以下，这并非因为页面遍历变快，而是因为LLC数据访问未命中增长得更剧烈。这种两级放大效应——TLB失效迫使页面遍历进入一个已被污染的LLC，并推高数据访问未命中——创造了一种跨地址空间的干扰机制，标准的按进程缓解措施无法解决。

尾部延迟表现出高可变性。即使在隔离环境中，主机介导的编排也会引入抖动：由于批处理调度、KV缓存管理和CUDA分派的差异，单个令牌的延迟会出现尖峰，即使每个请求的平均延迟保持较低水平。这在P99 ITL和P99 TPOT之间的差距中可见（67.9 ms vs. 14.4 ms，相差4.7倍）。在干扰下，这种抖动被进一步放大：通过NVIDIA Nsight Systems【32, Nsight Systems, 2026, NVIDIA】测量，内核间的分派间隔从约1 µs扩大到40 µs，这种延迟会在每个请求的数百个输出令牌上累积。

结论：CPU干扰严重降低了LLM服务性能：TLB失效和LLC污染共享相同的微架构资源，相互放大了彼此的影响。

3.2 操作系统调优不足以解决问题

引言。一个自然的问题是，标准操作系统和硬件缓解措施（如大页、缓存分区、CPU亲和性和调度优先级）能否在共存环境下恢复性能。我们使用每种缓解措施作为控制变量，系统地隔离性能下降的根本原因。结果表明，干扰通过多个微架构渠道进入，但主要的瓶颈并非任何单一渠道，而是CPU本身参与关键路径这一事实。除非另有说明，本小节的实验使用与§2.2相同的配置，但干扰程序限制为24个线程，负载为128个请求@7 req/s，并使用合成工作负载（随机输入/输出长度为1024/512）以最大化批处理占用率并对主机调度路径施加压力。

巨页（受害者和干扰者）：效果微乎其微。较大的页面通过每个条目覆盖更多内存来减少TLB压力，可能减少§3.1中识别的页面遍历开销。Table 2显示，无论是为vLLM使用2MB页面还是为干扰者使用1GB巨页都无法恢复隔离级别的性能。使用2MB页面时，所有延迟和吞吐量指标仍在测量误差范围内；dTLB加载未命中仅下降16%，这与2MB页面对Python主导的工作集（其主机端足迹由小对象和元数据主导）的TLB覆盖范围有限的优势一致。为干扰者的工作集分配1GB巨页也无济于事：P99 ITL恶化，LLC未命中率不变，因为巨页减少了干扰者自身的TLB未命中，但没有减少其LLC足迹，这与我们在§3.1中观察到的情况类似。

Table 2. 消融实验：页面大小和巨页无法恢复隔离性能（H100，启用CUDA Graphs，128个请求@7 req/s）。所有运行均包含干扰。隔离基准：吞吐量7697 tok/s，平均TPOT 13.5 ms，LLC未命中率5.9%。

核心绑定：有效但在规模化部署时不可行。通过核心绑定来专用物理核心可以消除CPU迁移并防止被其他租户直接抢占，是我们评估的最强的单机制缓解措施。遵循NVIDIA认证系统配置指南【31, NVIDIA-Certified Systems Configuration Guide, 2024, NVIDIA】中每个GPU至少需要六个物理核心的要求，我们将vLLM绑定到核心0-5，并将pbzip2干扰者限制在其余核心。为了在现实条件下压力测试核心绑定，此实验使用生产代表性流量：ShareGPT对话，泊松到达率为12 req/s，测量窗口为60秒。Table 3显示了结果。即使我们将vLLM绑定到GPU本地插槽的六个物理核心（即每个插槽24个核心中的6个，占25%），干扰仍然导致所有指标显著下降（Table 3）：尾部延迟最高膨胀30.3%（P99.9 ITL和TPOT），解码吞吐量下降18.2%，服务器在相同窗口内完成的请求数减少17.3%。原因是结构性的：核心绑定消除了调度器争用，但LLC、内存带宽和插槽互连仍然与共存的工作负载共享。此外，为一个密集的8xH100节点每个GPU专用至少六个物理CPU核心【31, NVIDIA-Certified Systems Configuration Guide, 2024, NVIDIA】需要48个专用的物理核心——这会耗尽我们双插槽Xeon服务器上的所有核心（每个插槽24个核心），甚至占高端双插槽EPYC平台（每个插槽64个核心）的38%。这些专用核心在解码迭代之间基本处于空闲状态，但又不能被回收用于其他租户，否则会重新引入调度干扰。实际上，核心绑定将共享机器变回了专用机器【34, Shenango: Achieving High CPU Efficiency for Latency-sensitive Datacenter Workloads, 2019, NSDI, Amy Ousterhout et al.】，从而消除了共存的经济理由；因此，核心绑定在规模上是不可行的。

Table 3. 在pbzip2干扰下的核心绑定（6个专用核心）。ShareGPT工作负载，泊松到达率为12 req/s，60秒窗口。

硬件缓存分区：消除了LLC争用但未解决延迟开销。Intel缓存分配技术（CAT）要求核心绑定作为先决条件，因此我们评估在绑定的基础上增加缓存分区是否能带来额外的好处。我们逐步为vLLM绑定的核心分配1到12个LLC缓存路，并在干扰下进行评估。Table 4总结了结果。为vLLM分配足够的缓存路可以将LLC未命中率恢复到接近隔离水平，并显著减少LLC停顿周期。这个机制是间接的：CAT不分区TLB，所以dTLB未命中数在所有配置中保持不变（约7M）。然而，当TLB未命中发生时，CPU必须遍历页表来解析物理地址，而这些页表项本身驻留在LLC中。为vLLM分配更多缓存路后，页表项更有可能保留在LLC中，使每次遍历更短。在7路时，LLC未命中率达到7.0%（而12路全部分配时为6.8%），LLC停顿周期下降了7.4倍。尽管完全消除了LLC争用，尾部延迟几乎没有变化：P99 ITL在所有配置中都在53.4 ms–55.6 ms之间，波动不到4%。硬件缓存分区没有改善延迟，因为主要开销，即主机端调度抖动和CUDA分派，不受缓存分配的影响。此外，实现这种LLC恢复对其他租户的成本很高，且该机制本身不可扩展。我们还注意到，调度优先级（nice -20）同样没有可测量的效果。

Table 4. 在干扰下CAT缓存路分配的效果（H100，启用CUDA Graphs，128个请求@7 req/s，专用CPU核心）。LLC未命中率下降8.5倍，但P99 ITL几乎不变。

结论：即使完全消除LLC争用也无法恢复尾部延迟：无论缓存分配如何，主机端调度抖动和CUDA分派开销仍然在关键路径上。

RDT的实际局限性。Intel资源导向技术（RDT）【16, Intel Resource Director Technology (Intel RDT), 2024, Intel】，CAT是其一部分，作为操作员级别的隔离机制也不切实际：服务类别（CLOS）条目稀少且必须连续；CLOS分配在上下文切换中不被保留，因此维持隔离需要专用核心或内核级修改来保存和恢复CLOS状态【42, Phoenix – A Novel Technique for Performance-Aware Orchestration of Thread and Page Table Placement in NUMA Systems, 2025, Mohammad Siavashi et al.】；CAT只解决缓存占用问题，不解决内存带宽问题；并且RDT是Intel特有的，在AMD或ARM平台上没有等效技术。

主机端编排抖动是可直接观察的。为了确认主机端开销是残留的瓶颈，我们使用PyTorch【36, PyTorch: An Imperative Style, High-Performance Deep Learning Library, 2019, NeurIPS, Adam Paszke et al.】对单个transformer层的forward()进行性能分析。在干扰下，每个主机端操作的耗时都会增加：attention分派增加104%，cudaLaunchKernel增加115%，KV缓存分派（reshape_and_cache_flash）增加172%，元数据操作如aten::empty增加81%。关键是，GPU端的内核执行时间保持不变（例如，matmul每次调用仍在0.41 ms–0.42 ms之间），这证实了加速器仅仅是被其主机饿死了。

3.3 启示：移除主机的理由

架构失配的根本问题。我们的分析揭示了一个根本的架构失配：当今的服务系统将一个脆弱、对干扰敏感的CPU置于每个令牌生成的关键路径上，而这个环境又是干扰普遍存在的。我们测试的每一种缓解措施要么效果微乎其微，要么留下了持续的性能残余。这些不是实现上的错误；它们反映了当前服务栈的迭代式主-设备耦合与多租户数据中心共享资源现实之间的结构性不匹配。

资源分区无法解决架构失配。运营商可能会结合所有之前的缓解措施，但成本高昂。像Caladan【9, Caladan: Mitigating Interference at Microsecond Timescales, 2020, OSDI 20, Joshua Fried et al.】和Shenango【34, Shenango: Achieving High CPU Efficiency for Latency-sensitive Datacenter Workloads, 2019, NSDI, Amy Ousterhout et al.】这样的动态核心重分配系统优化的是租户获得的CPU容量，而不是CPU是否在关键路径上。LLC和内存总线带宽是插槽范围的资源，核心重分配无法有效分区，而且这两个系统都要求应用程序链接自定义的用户空间线程和网络运行时，这与所有主要LLM服务引擎底层的Python/PyTorch栈不兼容。

结论：实现抗干扰性需要将主机CPU完全从稳态推理循环中移除。

A2 方法细节

4.1 概述

Blink的设计原则。Blink的设计原则是让主机CPU成为配置平面而非数据平面：主机在启动时加载模型并捕获CUDA图一次，然后完全退出推理路径。Blink是一个端到端的LLM推理服务系统，有五个核心目标：（1）高并发与可预测的延迟；（2）稳态无CPU——一次性初始化后，主机CPU脱离推理路径；（3）通过单边RDMA实现prompt和token在网络和GPU内存之间的零拷贝移动；（4）无需任何模型修改即可与现有模型兼容；（5）API兼容OpenAI风格的HTTP端点和服务器发送事件（SSE）流式语义，实现直接部署。

Blink的架构。图2展示了Blink的高层架构并追踪了一个prompt在推理路径中的生命周期（1-13）。Blink由两个运行时平面组成。前端运行在DPU的ARM核心上：它接收客户端请求(1)，对prompt进行分词(2)，定位一个空闲的环形缓冲区槽位(3-4)，通过单边RDMA将prompt写入GPU内存(5)，检索生成的token(11)，对它们进行反分词(12)，并将响应流式传输回客户端(13)。后端完全在GPU上运行：一个持久化的调度器内核轮询共享的环形缓冲区以获取新输入的prompt(6)，选择并启动预捕获的CUDA图(7-8)，通过设备端采样从logits计算token(9)，并将结果发布回环形缓冲区(10)——所有这些都无需返回主机控制。两个平面仅通过一个由RDMA访问的GPU常驻环形缓冲区进行通信(5, 11)，该缓冲区是唯一的交汇点，消除了任何主机介导的协调需求。这清晰地将初始化（主机辅助）与稳态（仅DPU+GPU）分离开来。


图2. Blink的架构。一次性初始化后，主机CPU处于空闲状态；稳态推理路径仅涉及GPU和DPU。实心圆圈追踪单个请求的生命周期。

DPU-GPU分工的理由。现代智能网卡在每核心网络带宽方面比服务器级CPU（Xeons, EPYCs）高出15-24倍，每核心内存带宽高出1.6-2.1倍【35, Lovelock: Towards Smart NIC-Hosted Clusters, 2025, SIGENERGY Energy Inform. Rev., Seo Jin Park et al.】，使其非常适合传输和请求管理任务。然而，它们有限的核心数量无法在连续批处理中吸收大量的每次迭代调度决策而不成为瓶颈。Blink利用了这种不对称性：DPU处理请求管理和网络I/O，而GPU常驻的持久化内核处理延迟关键的调度和执行循环。这种分工将主机CPU从数据路径中移除，而不会造成DPU端的瓶颈。

4.2 后端：GPU常驻的推理引擎

GPU集成了四个子系统：（1）一个持续管理请求生命周期的持久化GPU调度器，（2）避免主机介导内核分派的设备端CUDA图启动，（3）一个将新请求接纳到正在运行的解码批次中的连续批处理引擎，以及（4）一个用于DPU-GPU协调的无锁环形缓冲区。

持久化调度器。Blink用一个持久化的CUDA内核取代了主机驱动的解码循环（§2.1），该内核占用一个线程块（256个线程）并无限期运行。调度器执行一个无限控制循环：（1）扫描环形缓冲区以查找新提交的prompt，（2）通过原子比较并交换（compare-and-swap）来声明它们，（3）选择并启动适当的CUDA图用于预填充或解码，（4）在token采样后轮询设备常驻的输出缓冲区以获取完成信号，（5）将生成的token和状态更新发布回环形缓冲区。由于调度器从不将控制权交还给主机，因此在token关键路径上没有内核启动开销，没有主-设备同步，也没有CPU介导的簿记工作。

并行插槽扫描。为避免序列化，调度器线程块中的所有256个线程并行扫描环形缓冲区插槽的不相交连续范围，并通过原子CAS声明待处理的插槽，从而消除了锁和块间同步。对所有4096个插槽的完整扫描在1µs–5µs内完成，确保了prompt接纳延迟主要由RDMA传输时间决定，而非调度开销。

GPU常驻调度与CPU常驻调度的对比。图3量化了GPU常驻调度的好处。我们在相同的编译引擎（Qwen3-32B, FP16, H100, 批大小16）上运行相同的工作负载，但采用两种调度器部署方式，它们共享相同的调度策略。在CPU常驻的基准测试中，采样后的token在每个解码步骤后通过PCIe复制到主机内存，然后在CPU上重新组装批次，再启动下一个图；相比之下，GPU常驻的调度器消除了这种每步同步。在两种情况下，token采样都在GPU上执行，以最好地匹配vLLM等流行的以CPU为中心的系统。在四种工作负载配置中，CPU路径将总执行时间（makespan）增加了1.16-1.70倍，其中对短输出工作负载的惩罚最大，因为每步PCIe往返开销主导了计算时间。


图3. 归一化执行时间：Qwen3-32B上GPU常驻调度与CPU常驻调度的对比（N×I→O表示N个请求，I个输入token，O个输出token）。

设备端CUDA图启动。实现无CPU操作的一个关键技术是设备端图启动【28, CUDA Graphs — Device Graph Launch, 2024, NVIDIA】【30, Enabling Dynamic Control Flow in CUDA Graphs with Device Graph Launch, 2024, NVIDIA】：持久化调度器本身被包装成一个CUDA图，直接从设备上将预捕获的推理图加入队列执行。Blink使用“即发即忘”（fire-and-forget）启动模式，对于代表性的图拓扑（直线、分叉-合并和并行），完成时间约为2µs——比主机端启动（11µs–17µs）快5–8倍，比尾部启动（≈5.5µs）快2.7倍。经过数百个解码步骤，这些差异会累积：与主机启动相比，“即发即忘”模式在生成512个token时可节省4.6ms–7.7ms。更关键的是，主机启动会重新将CPU引入关键路径，使推理再次暴露于主机端干扰。

挑战：120次启动的硬限制。即发即忘模式有一个未被广泛记录的基本限制：CUDA运行时限制单个父图执行中未完成的即发即忘启动次数为120次【29, CUDA Graphs — Fire and Forget Launch, 2024, NVIDIA】；一旦达到此限制，后续启动将产生未定义行为。对于必须无限期生成token的推理服务器来说，这是一个关键障碍——一个有512个输出token的请求在完成前就会耗尽启动预算。在120次迭代后回退到主机启动会重新将CPU引入关键路径，而仅使用尾部启动则会产生2.7倍的每次启动开销，这会在数百个解码步骤中累积。

解决方案：基于窗口的尾部启动恢复。Blink通过一个基于窗口的尾部启动恢复机制解决了这个限制。调度器在共享内存中维护一个单调递增的启动计数器。当达到120次启动限制时，它会发出一个单一的尾部启动，原子地用一个全新的实例替换当前的图执行。所有状态——环形缓冲区指针、KV缓存元数据、进行中的请求——都驻留在持久的GPU内存中，并在图重新实例化后得以保留；新实例将计数器重置为零，并从相同的逻辑点恢复调度循环。此设计实现了三个特性：（i）近乎最优的启动延迟——每121次迭代中有120次使用即发即忘，单个尾部启动的开销在窗口内被分摊（每解码步骤开销<0.03µs）；（ii）无缝的状态连续性——所有元数据、KV缓存状态和环形缓冲区内容都驻留在持久的GPU内存中，在图重新实例化后得以保留；（iii）无限制的生成——对生成的token数量没有上限。

完成检测。即发即忘启动不提供主机端完成回调——父内核不会收到子图完成的通知。Blink完全在设备上执行基于轮询的完成检测：在推理引擎执行前向传播并且token采样写入结果后，调度器轮询指定的输出缓冲区，直到提取的token出现。对于预填充，调度器轮询一个由推理图在计算第一个输出token时填充的token提取缓冲区；缓冲区占用情况标志着预填充的完成。对于解码，调度器轮询由每个解码图写入的每步提取缓冲区。轮询成本（每次迭代几个共享内存加载）相对于推理计算可以忽略不计，并且它保持了稳态期间没有主机参与的不变性。

内联预填充的连续批处理。Blink实现了连续批处理【54, Orca: A Distributed Serving System for Transformer-Based Generative Models, 2022, OSDI 22, Gyeong-In Yu et al.】和FCFS调度，与TensorRT-LLM、vLLM【20, Efficient Memory Management for Large Language Model Serving with PagedAttention, 2023, SOSP, Woosuk Kwon et al.】和SGLang【56, SGLang: Efficient Execution of Structured Language Model Programs, 2024, NeurIPS, Lianmin Zheng et al.】使用的策略相匹配，以便评估差异（§6）能隔离出移除主机CPU的架构优势，而不是调度优势。为了在不暂停正在进行的生成的情况下接纳新请求，调度器实现了带重叠环形扫描的暂停-恢复批处理：当一个解码图异步执行时，调度器的256个线程并行扫描环形缓冲区以查找待处理的prompt，将扫描延迟隐藏在解码计算之后。如果找到候选请求，调度器在暂停前评估三个条件：（i）在重叠扫描期间检测到待处理的预填充，（ii）有空闲的批处理槽位容量（考虑到本步骤将完成的槽位），以及（iii）有足够的即发即忘启动窗口余量用于预填充图和恢复的解码。当所有三个条件都满足时，调度器在当前步骤后暂停进行中的解码请求，为新到达的请求执行预填充图，将新预填充的请求合并到解码批次中，并重新启动解码循环——所有这些都在单个持久化内核调用内完成，没有主机往返。这确保新请求在一个解码步骤的延迟内被接纳，限制了TTFT而不牺牲解码吞吐量。

环形缓冲区。环形缓冲区驻留在GPU内存中，是DPU和GPU之间唯一的共享数据结构，作为单边RDMA读/写的对象。它由一组固定的槽位以及用于输入和生成token的共享区域组成。每个槽位记录每个请求的元数据（例如，prompt标识、token计数和生成进度）以及到token区域的偏移量。调度器通过一个生命周期状态机推进每个槽位——empty → prefill_pending → prefill_processing → decode_processing → decode_completed → empty——并使用decode_paused状态来支持抢占和连续批处理。所有权和状态转换使用原子比较并交换（CAS）。其布局和更新规则旨在避免中间复制，容忍良性竞争，并通过内存屏障确保RDMA可见的更新按预期顺序可见。

CUDA图缓存。Blink使用预编译的TensorRT【25, NVIDIA TensorRT, 2019, NVIDIA】引擎进行推理。在初始化期间，主机为密集的（批大小，序列长度）对捕获推理计算为CUDA图，并为每个图实例化以便于设备端启动，这样持久化调度器就可以直接调用它们。所有图都重用为最大支持形状一次性分配的一组设备缓冲区，避免了每个图的内存重复。由于每个捕获的图只消耗2MB–3MB——比典型的基于PyTorch的CUDA图的数百MB小几个数量级——在我们评估的模型中，一个包含650–1000个图的缓存可以放在2GB–4GB的内存中，从而实现了细粒度的形状匹配，而不会耗尽内存预算和动态捕获的开销。在运行时，调度器通过一个由（批次，序列长度）索引的预计算查找表选择最合适的预填充图，实现O(1)选择，无需每步搜索；一个最大形状的回退图处理缓存中没有的任何组合。Token采样（带温度的Top-P）被捕获在每个图中，因此从attention到下一个token选择的整个前向传播都作为单个设备端启动执行，没有主机往返。

4.3 模型兼容性

与模型无关的设计。由于持久化调度器将推理图视为一个不透明的计算——填充输入张量，启动图，并读取输出缓冲区——Blink继承了TensorRT广泛的模型支持，无需修改。密集Transformer、混合专家（MoE）模型和编码器-解码器架构仅需一个TensorRT编译步骤；无需对调度器、环形缓冲区或RDMA数据路径进行任何更改。模型层面的创新（如新的注意力机制【3, GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints, 2023, EMNLP, Joshua Ainslie et al.】、【40, Fast Transformer Decoding: One Write-Head is All You Need, 2019, Noam Shazeer】，量化方案，激活函数）和服务层面的优化（分块预填充【2, Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve, 2024, OSDI, Amey Agrawal et al.】，前缀缓存【56, SGLang: Efficient Execution of Structured Language Model Programs, 2024, NeurIPS, Lianmin Zheng et al.】，推测解码【23, Fast Inference from Transformers via Speculative Decoding, 2023, ICML, Yaniv Leviathan et al.】）都与Blink的架构正交；我们将在§7中讨论具体的集成路径。

4.4 前端：DPU侧的控制和数据平面

前端的职责。前端运行在BlueField DPU的ARM核心上，管理从请求到达到着信交付的完整请求生命周期。一个请求跟踪器维护每个请求的状态——槽位分配、token计数和完成状态——协调prompt提交、token检索和面向客户端的流式传输。前端还托管一个与OpenAI兼容的轻量级HTTP服务器，支持SSE流；由于解耦的架构，这个接口层也可以在独立的网关上运行。

RDMA数据路径。前端使用单边RDMA直接读写GPU常驻的环形缓冲区。它将待发送的prompt和待接收的结果分别暂存在DPU本地的缓冲区中，以解耦提交和检索，并减少控制元数据和批量token流量之间的干扰。提交时，前端将分词后的prompt传输到指定的槽位并更新其状态，以便后端可以开始预填充。当请求突发到达时，前端会合并传输，以在多个prompt之间分摊RDMA开销。

插槽跟踪器。插槽跟踪器不是在每次提交前通过RDMA扫描所有环形缓冲区槽位，而是在DPU上维护一个本地可用性缓存，通过单个批量RDMA读取定期刷新。一种基于提示的循环扫描以O(1)的摊销时间找到空闲槽位，提高了空间局部性并减少了每次提交的RDMA开销。

令牌读取器。一个后台的令牌读取器持续轮询环形缓冲区以获取生成的token。每个周期，它发出一次RDMA读取来刷新缓存的槽位元数据（64 KB），然后将每个活动槽位的生成计数与其本地状态进行比较以检测新的输出。为了最小化TTFT，新槽位会进入一个优先扫描的紧急槽位，因此第一个token在一个轮询间隔内被检索。自适应轮询限制了每个token的延迟，同时限制了RDMA流量。在突发到达时，读取器会限制每次轮询的工作量，并使用大型RDMA任务池来避免完成队列饱和；一个专用的进度线程处理完成事件以维持吞吐量。检索到的token被送往反分词器，并通过SSE流式传输给客户端。

分词器。DPU上的分词必须在ARM微架构上高效。Blink实现了一个分词器，其合并规则存储在一个64字节对齐的扁平哈希表中，每个L1D缓存行打包四个键值对；16字节对齐的符号节点将短词工作集保持在两个缓存行内，避免了堆间接引用。正则表达式预分词使用ARM NEON SIMD进行字节分类，速度为每周期16字节，所有每个请求的状态都存在于预分配的线程本地缓冲区中，消除了请求路径上的堆分配。图4比较了Blink在BlueField-3 ARM A78核心上的分词器与HuggingFace（vLLM和SGLang使用）和llama.cpp【10, llama.cpp: LLM Inference in C/C++, 2023, Georgi Gerganov et al.】在Intel Xeon CPU上的分词器。尽管ARM核心的时钟速度较低，但对于10–2048个token的输入，Blink的分词器比HuggingFace快8-19.7倍，并且始终优于llama.cpp，这表明DPU没有引入分词瓶颈。


图4. 在BlueField-3 ARM A78核（Blink）与Intel Xeon（HuggingFace, llama.cpp）上的分词延迟。标签显示了相对于HuggingFace的加速比。

5 实现细节

代码实现。Blink的GPU常驻后端包含大约16k行CUDA和C++代码，实现了持久化调度器、设备端图启动机制、连续批处理引擎、KV缓存管理和token采样，目标是CUDA 13.1，并利用TensorRT推理引擎来处理预捕获的模型图。而DPU常驻的控制和数据平面增加了大约17k行C/C++代码，实现了HTTP解析和请求验证、通过DOCA 3.2 SDK的RDMA编排、环形缓冲区协调和SSE流式传输。DPU还在其ARM核心上提供可选的分词功能，以卸载这一传统上由主机端完成的工作，从而减少端到端延迟。

A4 实验

6.1 实验环境

  • 硬件配置：

    • GPU服务器：1x NVIDIA H100 (96 GB HBM3)
    • CPU：2x Intel Xeon Gold 6336Y (总共96核 @ 2.40 GHz)，DVFS禁用，governor设为performance
    • 内存：256 GB DDR5
    • 网络：ConnectX-6 (200 Gbps)
    • 操作系统：Linux 5.15 (Ubuntu 22.04 LTS)
    • DPU：Blink的前端运行在一台独立的BlueField-3 DPU机器上（16个ARM Cortex-A78核，32 GB内存），通过200 Gbps RDMA链路连接。


    表5. 硬件配置。

  • 模型与数据集：

    • 模型：评估了四种模型：Llama-3 8B（密集模型，8B参数）、Phi-4 15B（密集模型，14.7B参数）、Qwen-3 32B（密集模型，32B参数）和Qwen-3 30B-A3B（MoE模型，30B总参数/3B激活参数）。所有实验均使用paged attention和fp16精度。
    • 数据集：使用guidellm工具和ShareGPT v3数据集，该数据集提供了自然的对话追踪。实验中，负载从1到32 req/s进行扫描。

  • 软件配置与基准系统：

    • Blink：使用TensorRT v10.14作为后端引擎。

    • 基准系统：

      1. TensorRT-LLM v1.1.0：与Blink使用相同的TensorRT引擎，以隔离编排开销的影响。
      2. vLLM v0.13.0：广泛部署的开源服务系统。
      3. SGLang v0.5.8：一个最近的高性能服务系统。

    • 所有基准系统都使用推荐的生产设置并启用CUDA Graphs。为进行公平比较，禁用了分块预填充、前缀缓存和CPU卸载等优化。

  • 干扰负载：

    • 为了模拟多租户的“吵闹邻居”场景，将两个CPU密集型工作负载与推理任务共存部署：

      1. pbzip2：用45个线程压缩一个50GB的文件。
      2. Ninja：用45个并行作业编译LLVM编译器源码。

    • 根据NVIDIA的指导方针，为推理任务保留6个核心，其余90个主机核心分配给干扰负载。

6.2 实验结果

Q1: 隔离环境下的性能

评估方法。我们评估了在无干扰的隔离执行下的性能。我们关注的是系统在达到吞吐量饱和点之前的“非饱和操作范围”内的表现。饱和点是指吞吐量曲线从线性增长过渡到稳定平台的点。

延迟表现。在Blink可服务的负载范围内，Blink提供了最佳的延迟表现。如Table 6所示，在四个模型中的三个上，Blink实现了最低的几何平均P99 TTFT和TPOT。

  • 在Llama-3 8B上，基准系统的几何平均P99 TTFT比Blink高1.35-2.67倍，P99 TPOT高1.17-2.03倍。
  • 在Phi-4 15B上，TTFT差距为1.31-2.59倍，TPOT差距为1.19-1.92倍。
  • 在MoE模型Qwen-3 30B-A3B上，基准系统的TTFT高出3.45-8.47倍，TPOT高出1.85-3.40倍。


表6. Blink定义的运行范围内的预饱和总结。TTFT和TPOT单位为毫秒；Tput@sat是Blink饱和点处的实现吞吐量。

TTFT优势的架构原因。Blink的TTFT优势来源于两个架构特性：首先，持久化GPU调度器能够以微秒级延迟（1-5µs）声明新请求；其次，prompt通过零拷贝单边RDMA直接从DPU进入GPU内存，完全绕过了主机内存层次。

与同引擎的TensorRT-LLM对比。与使用相同TensorRT引擎的TensorRT-LLM相比，Blink在Llama-3 8B、Phi-4 15B和Qwen-3 30B-A3B上的几何平均TTFT分别降低了1.35倍、1.31倍和3.45倍。这些增益完全来自于移除了主机介导的编排。在GPU计算密集的Qwen-3 32B上差距最小，但在更深的P99.9尾部延迟上，Blink的优势依然明显（如图5所示，TTFT高4%-8%，TPOT高15%-48%）。


图5. Qwen-3 32B (隔离) 的P99.9尾部延迟。尽管P99延迟接近，但P99.9显示出Blink对所有基准系统的一致优势，且随负载增加而增大。

吞吐量表现。如图7(a-d)所示，Blink在所有模型上都达到了最晚或并列最晚的饱和点，并维持了最高的平台吞吐量。相对于TensorRT-LLM，平台吞吐量分别高出9%（Llama-3 8B），6%（Phi-4 15B），8%（Qwen-3 32B）和37%（Qwen-3 30B-A3B）。

MoE模型的优势放大原因。MoE模型的优势被放大的原因有二：首先，MoE模型的计算与编排开销比不利，其每步CPU编排成本与密集模型相同，但GPU计算量小，使得CPU开销占比更大。其次，TensorRT的MoE插件将专家路由逻辑封装在静态shape的CUDA图中，Blink的设备端图启动可以无主机干预地执行，而基准系统仍需主机介入每一步解码。

Q2: CPU干扰下的性能

Blink的稳定性。在CPU干扰下，Blink的性能几乎保持不变。在Blink定义的运行范围内，TTFT、TPOT和吞吐量的变化都在1-4%以内，表明主机CPU争用不会干扰稳态解码路径。

基准系统的性能崩溃。相比之下，依赖CPU的基准系统性能急剧下降。如Table 7所示，在Blink的操作范围内：
* 在Llama-3 8B上，基准系统的TTFT膨胀了8.43-18.84倍，TPOT膨胀了5.77-11.10倍，吞吐量仅为其隔离状态的38%-48%。
* 在Phi-4 15B上，TTFT膨胀3.82-10.66倍，TPOT膨胀3.15-6.17倍，吞吐量保留41%-47%。
* MoE模型上，TensorRT-LLM的TTFT膨胀4.90倍，TPOT膨胀9.19倍，吞吐量从3.61 req/s暴跌至1.01 req/s。


表7. 与表6相同的预饱和总结，但在CPU干扰下。括号内为干扰/隔离比率；吞吐量括号内报告了在Blink饱和点的保留率。

饱和后的吞吐量对比。图7(a-d)的虚线显示，Blink的饱和点和平台吞吐量在干扰下保持稳定。而基准系统的平台吞吐量保留率下降到32%-64%。在干扰下，Blink的平台吞吐量比基准系统高出1.69-4.08倍。

延迟曲线对比。图6的P99延迟曲线直观展示了这一差异。Blink的实线（隔离）和虚线（干扰）几乎重叠，而基准系统的虚线则急剧上升，远高于实线。


图6. 四种模型下的P99尾部延迟。顶行(a-d)：TTFT；底行(e-h)：TPOT。实线表示隔离执行；虚线表示CPU干扰。


图7. 四种模型下的吞吐量。实线表示隔离执行；虚线表示CPU干扰。

Q3: 能源效率

测量方法。我们测量服务器级墙上功耗，并对Blink额外计入BlueField-3 DPU的功耗。我们报告每token能耗（mJ/tok）。

隔离环境下的能效。如图8(a)所示，Blink的每token能耗在363-1306 mJ/tok之间，比每个模型最高效的基准系统低13.7%-48.6%。差距最大的模型是Qwen-3 30B-A3B，因为MoE专家路由放大了CPU调度开销。

干扰环境下的能效。如图8(b)所示，在共存干扰下，Blink的能耗为423-1584 mJ/tok，而基准系统上升到1045-3597 mJ/tok，Blink相比最佳基准系统降低了41.4%-70.7%。由于所有系统的墙上功耗相似（1.1-1.4 kW），能耗与吞吐量成反比。当CPU争用导致基准系统吞吐量崩溃时，其每token能耗急剧上升（69%-182%）。而Blink的能耗开销最多为21%，其能效在结构上与主机争用无关。


图8. (a)隔离和(b)共存干扰下的每token能耗。

A7 补充细节

7 讨论

张量并行与流水线并行。尽管Blink当前原型针对单GPU，但其控制平面结构可扩展到多GPU部署。通过在每个GPU上实例化一个持久化调度器，并使用GPU原生的通信原语（如NCCL集合或通过IBGDA【55, DeepEP: an efficient expert-parallel communication library, 2025, Chenggang Zhao et al.】的GPU发起的RDMA）在图执行之间进行通信，可以实现张量并行和流水线并行。由于这些机制在GPU上执行，它们保持了Blink的无CPU关键路径。

服务优化。多种广泛研究的优化可以自然地映射到Blink的GPU常驻调度器上。例如，分块预填充【2, Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve, 2024, OSDI, Amey Agrawal et al.】可以通过调度器跟踪请求进度来实现增量预填充。前缀缓存【56, SGLang: Efficient Execution of Structured Language Model Programs, 2024, NeurIPS, Lianmin Zheng et al.】可以通过GPU常驻的Trie树或哈希表在调度器内部实现。推测解码【23, Fast Inference from Transformers via Speculative Decoding, 2023, ICML, Yaniv Leviathan et al.】可以在调度器内运行草稿生成和验证。分离的预填充/解码【57, DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving, 2024, OSDI, Yinmin Zhong et al.】可以通过独立的调度器实例实现。KV缓存卸载可以通过NVLink的设备发起传输【46, Aqua: NetworkAccelerated Memory Offloading for LLMs in Scale-Up GPU Domains, 2025, Abhishek Vijaya Kumar et al.】或CUDA管理内存实现。

CPU/DRAM卸载。当模型（尤其是MoE架构）超出GPU内存容量时，系统会采用CPU/DRAM卸载专家权重【14, Efficient CPU-GPU Collaborative Inference for MoE-based LLMs on Memory-Limited Systems, 2025, En-Ming Huang et al.】、【15, Pre-Gated MoE: An Algorithm-System Co-Design for Fast and Scalable Mixture-of-Expert Inference, 2024, ISCA, Ranggi Hwang et al.】。在这种情况下，主机CPU不仅在调度路径上，还在数据移动路径上，这使得§3中描述的干扰问题更加严重。Blink目前针对模型能放入GPU内存的常见情况。一个自然的扩展是利用DPU的RDMA引擎直接管理专家权重迁移，使权重传输远离主机内存总线，同时保持无CPU的服务路径。

更广泛的生态系统趋势。Blink基于ARM的DPU前端与ARM在AI数据中心基础设施中日益增长的作用相符，例如与Meta共同开发的Arm AGI CPU【5, Arm AGI CPU, 2026, Arm】。随着基于ARM的DPU获得更高的核心数和更紧密的RDMA集成，Blink的前端将直接受益。

8 相关工作

用于加速器服务的SmartNIC/DPU卸载。最相关的系统将部分机器学习或存储数据路径卸载到SmartNIC，但都针对一次性DNN推理或非推理工作负载。例如，Lynx【45, Lynx: A SmartNICdriven Accelerator-centric Architecture for Network Servers, 2020, ASPLOS, Maroun Tork et al.】提出以SmartNIC替代主机CPU作为GPU网络服务的协调者，但仅支持一次性工作负载，不支持自回归和有状态的LLM。SplitRPC【19, SplitRPC: A Control + Data Path Splitting RPC Stack for ML Inference Serving, 2023, Proc. ACM Meas. Anal. Comput. Syst., Adithya Kumar et al.】将推理负载从NIC直接导向GPU内存，但保留主机CPU进行编排。Conspirator【52, Conspirator: SmartNIC-Aided Control Plane for Distributed ML Workloads, 2024, USENIX ATC 24, Yunming Xiao et al.】将ML控制平面移至SmartNIC ARM核心，但主机CPU仍在内核调用和结果检索的关键路径上。OS2G【17, OS2G: A High-Performance DPU Offloading Architecture for GPU-based Deep Learning with Object Storage, 2025, ASPLOS, Zhen Jin et al.】将对象存储客户端卸载到DPU，但目标是存储而非推理。DeepEP【55, DeepEP: an efficient expert-parallel communication library, 2025, Chenggang Zhao et al.】使用GPU发起的RDMA绕过NCCL的CPU代理，但仅针对主机驱动栈中的单个集合原语。这些系统均未解决自回归LLM推理特有的挑战。

LLM服务与GPU执行。大量工作优化了主机驱动的服务循环，如连续批处理【54, Orca: A Distributed Serving System for Transformer-Based Generative Models, 2022, OSDI 22, Gyeong-In Yu et al.】、分块预填充【2, Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve, 2024, OSDI, Amey Agrawal et al.】、PagedAttention【20, Efficient Memory Management for Large Language Model Serving with PagedAttention, 2023, SOSP, Woosuk Kwon et al.】等。在GPU端，CUDA Graphs【27, CUDA Graphs, 2024, NVIDIA】、设备端图启动【28, CUDA Graphs — Device Graph Launch, 2024, NVIDIA】等技术加速了单个操作。然而，所有这些系统都保留主机CPU作为调度和I/O的中心。Blink则将这些批处理和内存策略在其GPU常驻调度器中运行，使主机脱离了稳态关键路径。Blink是第一个端到端重构推理服务栈，以从整个自回归推理生命周期中消除主机CPU的系统。

A5 结论

本文介绍了Blink，一个无CPU的LLM服务架构。它通过协同设计智能网卡常驻的入口、到GPU内存的零拷贝RDMA以及一个用于连续批处理、KV缓存管理和token生成的GPU常驻持久化调度器，将主机CPU从稳态推理路径中移除。在四种涵盖密集和MoE架构的模型上，Blink相比于TensorRT-LLM、vLLM和SGLang，将预饱和P99 TTFT最多降低了8.47倍，P99 TPOT最多降低了3.40倍，解码吞吐量最多提升了2.1倍，每token能耗最多降低了48.6%。在多租户CPU争用下，Blink的性能保持稳定，而基准系统则出现一到两个数量级的性能下降。

更广泛地看，Blink表明，持久化的加速器常驻控制与智能网卡常驻的I/O相结合，可以取代主机介导的编排，用于延迟敏感型工作负载。随着数据中心的扩展，将推理与共享的主机资源解耦将是实现性能隔离和服务器整合的关键。

A6 附录

A 实验配置

实验设置回顾。本节简要回顾实验设置。所有实验在一台配备单个NVIDIA H100 GPU、两个Intel Xeon Gold 6336Y CPU的服务器上运行。Blink的前端在通过RDMA连接的BlueField-3 DPU上运行。对比系统为Blink、TensorRT-LLM v1.1.0、vLLM v0.13.0和SGLang v0.5.8。工作负载使用ShareGPT v3数据集，干扰负载为pbzip2和Ninja LLVM编译。干扰负载在整个扫描过程中持续运行，由于它们在不同执行阶段资源消耗不同，这可能导致基准系统的干扰曲线在连续的负载点上出现非单调波动。评估模型包括Llama-3 8B, Phi-4 15B, Qwen-3 32B, 和Qwen-3 30B-A3B。

B 预饱和延迟摘要

多百分位延迟对比。Table B.1提供了跨所有百分位的全面延迟比较，报告了Blink操作范围内的几何平均值。
* P50 TTFT：Blink在所有模型上实现了最低的中位TTFT。在Llama-3 8B上，基准系统的中位TTFT比Blink高1.73至5.75倍。在Qwen-3 30B-A3B上，TensorRT-LLM的中位TTFT（1132ms）是Blink（207ms）的5.5倍，反映了即使在中位数情况下，CPU介导的专家路由成本也很高。
* 平均延迟：平均TTFT和TPOT介于P50和P95之间。Blink在Phi-4 15B上的平均TTFT为258.8ms，而TensorRT-LLM为355.7ms（高1.37倍），SGLang为846.9ms（高3.27倍）。
* GPU密集型场景：在最大的密集模型Qwen-3 32B上，各系统间的延迟差异最小，这与主文的发现一致。


表B.1. 在隔离执行下，Blink运行范围内的几何平均延迟（ms）。

Token级吞吐量。Table B.2显示了在各模型饱和点处的token级吞吐量。解码吞吐量对调度最敏感。Blink在Llama-3 8B饱和时实现了3880 tok/s的解码吞吐量（比TensorRT-LLM高10%），在Qwen-3 30B-A3B上实现了1437 tok/s（比TensorRT-LLM高36%）。


表B.2. 在隔离执行下，Blink饱和点处的token级吞吐量（tok/s）。

C 可服务负载摘要

最大可服务负载。图C.1总结了各系统在隔离和干扰条件下的最大可服务负载，定义为系统能保持至少95%理想吞吐量的最高请求速率。Blink在所有模型和条件下都实现了最高的可服务负载。在MoE模型上差距尤其大：隔离下Blink的可服务负载几乎是第二名的两倍，干扰下优势进一步扩大。在Llama-3 8B上，干扰导致基准系统的可服务负载下降60-65%，而Blink保持其全部隔离容量。


图C.1. 每个系统和模型的最大可服务负载（95%吞吐量保持阈值）。

D 扩展延迟指标

本节提供P99.9、P95、P50（中位数）和平均值的延迟分解，补充主文中报告的P99数据。

D.1 P99.9 尾部延迟

结果分析。图D.1将P99.9分析扩展到所有四个模型。
* 隔离环境：在这个深尾部，Blink在整个负载范围内始终保持较低的延迟。在Qwen-3 30B-A3B上，由于CPU介导系统中的MoE专家路由开销放大了尾部事件，差距最为明显。
* 干扰环境：在CPU争用下，基准系统的P99.9延迟（虚线）与其隔离对应项（实线）急剧偏离，而Blink的曲线几乎重叠。这证实了主文中记录的P99抗干扰能力延伸到了最深的实际尾部。


图D.1. 四种模型下的P99.9尾部延迟。

D.2 P95 尾部延迟

结果分析。图D.2报告了P95延迟。在此百分位，系统间的相对排序与P99一致，但曲线更平滑。
* 隔离环境：Blink在所有模型上都保持了其延迟优势。P95 TTFT的差距与P99成比例，证实了这种优势是结构性的（减少了调度开销），而非罕见尾部事件的产物。
* 干扰环境：所有CPU介导的基准系统在隔离和干扰曲线之间都出现了分离，而Blink的P95曲线保持稳定。


图D.2. 四种模型下的P95延迟。

D.3 P50 (中位数) 延迟

结果分析。图D.3显示了中位数延迟，反映了典型请求的体验。
* 隔离环境：Blink在所有指标和模型上实现了最低或接近最低的中位数。在Qwen-3 30B-A3B上，TensorRT-LLM的中位数TTFT比Blink高5.5倍，证实了专家路由开销并不仅限于尾部。
* 干扰环境：CPU干扰显著推高了基准系统的中位数曲线，而Blink的中位数基本不变，表明典型请求也受到了保护。


图D.3. 四种模型下的中位数（P50）延迟。

D.4 平均延迟

结果分析。图D.4报告了平均延迟。由于平均值对重尾分布敏感，其趋势介于中位数和P95之间。
* 隔离环境：系统排序与P50和P99一致。在Qwen-3 30B-A3B上，基准系统的平均TTFT比Blink高3.3倍至8.1倍。
* 干扰环境：在干扰下，基准系统的平均延迟膨胀了3-18倍，而Blink的平均值保持在隔离值的1.0-1.15倍以内，再次证明了其与主机负载的结构性解耦。


图D.4. 四种模型下的平均延迟。

E 扩展吞吐量指标

Token级吞吐量。本节提供了token级吞吐量的补充视图，分为预填充（处理的prompt token/s）和解码（生成的output token/s）。图E.1显示了这两个指标。

解码吞吐量。Blink的GPU常驻调度器消除了每次迭代的CPU往返，从而实现了更高的持续解码吞吐量。在Qwen-3 30B-A3B上优势最明显，Blink在饱和时维持1437 tok/s，比TensorRT-LLM高36%。

预填充吞吐量。预填充吞吐量的差异较小，因为预填充阶段主要是大型矩阵乘法，受调度开销影响较小。尽管如此，Blink仍保持一致的优势（比最接近的基准高2-18%）。

干扰环境下的吞吐量。在CPU争用下，基准系统的解码吞吐量显著下降（底行虚线），而Blink的吞吐量平台得以保留。这与主文中的请求级吞吐量（goodput）发现相符，证实了吞吐量崩溃问题在token层面同样存在。


图E.1. 四种模型下的Token级吞吐量。