垂直扩展能力：从 MVP 到万亿参数工作负载的推理——Sitanshu Gupta，CoreWeave

中文العربيةDeutschEnglishEspañolFrançaisहिन्दी日本語한국어PortuguêsРусский
AAI Engineer
컴퓨터/소프트웨어AI/미래기술

스크립트

00:00:00大家下午好。我是来自 Coreweave 的 Sitan Shu。我今天将探讨纵向
00:00:19流动性。虽然我们拟定的这个标题听起来挺花哨，但基本上
00:00:26是要讲解我们在 Coreweave 构建的推理平台，旨在服务
00:00:30从小型到大型的各类模型以及多种不同的工作负载。先简单自我介绍一下，我
00:00:38大约四个月前加入 Coreweave，领导这里的整个推理团队。在此之前，
00:00:44我在 AWS Annapurna Labs 负责训练相关的事务，更早之前
00:00:49则在 SambaNova 负责推理和训练。因此在该领域积累了相当丰富的经验。接下来
00:00:56我的讲解思路是：首先阐述我们现有的消费模式，
00:01:00并以此为基础推导出平台应有的架构，从而无需频繁变动平台，
00:01:04而是能够在现有的推理服务平台之上持续进行功能增强，
00:01:09同时也会解释性能为何在其中扮演着如此至关重要的角色。
00:01:14其中一部分内容可能与此前讨论过的议题有所重合。
00:01:20关于消费模式。整体而言，我们主要有两种核心消费模式。一种是 Serverless（无服务器模式），
00:01:29客户或消费者接入后，无需亲自管理
00:01:35硬件设施，也无需操心集群管理、资源编排等任何底层细节。
00:01:40我们提供 API 和 UI 界面，用户直接接入、按 Token 付费，即可获得模型推理服务。
00:01:47该模式最大的优势在于模型目录中提供的丰富选择，即客户可以调用的模型广度。
00:01:54我先介绍专属服务（Dedicated），稍后再折返回来补充 Serverless，因为 Serverless 还有一个独到之处。
00:02:01我们提供的 Dedicated 专属推理服务，则更适合那些希望明确了解
00:02:05自己运行在何种具体硬件上的客户，但模型的部署策略也由他们自主掌控。
00:02:11也就是说，他们使用我们的基础服务和编排层，但模型如何部署由他们决定。
00:02:18模型的性能表现同样取决于他们，前提是我们平台提供了运行这些特性所需的
00:02:25能力和配置开关。重新回到 Serverless 话题，
00:02:30这里有一个很有意思的现象：常规的 Serverless 模型往往存在“嘈杂邻居（Noisy Neighbor）”问题，
00:02:38假设所有人都在集中请求完全相同的模型，那么根据后端的容量储备情况，
00:02:43你很可能会遇到频繁超时。因此，我们在 Serverless 模式下推出了
00:02:48另一项功能，我们称之为“预留吞吐量（Provisioned Throughput）”。作为客户，如果你清楚自己的流量特征，
00:02:55并提前告知我们，我们就可以在后台为你专门
00:03:00划分出专属资源。你依然无需关心底层具体运行在什么硬件上，
00:03:04只要你的吞吐量和 SLA 服务承诺得到保障即可。
00:03:07这是 Serverless 领域的另一项补充方案，它依然按 Token 计费，
00:03:12但能确保你不会受到“嘈杂邻居”问题的干扰。
00:03:19下面我来粗略分析一下我们目前观察到的几种不同类型
00:03:27的工作负载特征，它们之间的比例一直在动态变化，不过 Agent（智能体）类的
00:03:32增长势头非常迅猛。Agent 与 Chat（对话）模式十分类似，输入序列长度（Input Sequence Length）
00:03:39通常非常长，而输出序列长度则相对较短。但 Agent 与
00:03:43Chat 最大的区别在于，Agent 中的多轮交互（Multi-turn）对延迟要求极高，而 Chat 则不同，因为当
00:03:50用户收到响应后，需要先阅读内容然后再回复。所以这两者
00:03:56存在本质区别。而这种显著差异，最终会转化为
00:04:01对 KV Cache 管理的具体需求。不过这两者都属于实时工作负载，另一种实时负载则是
00:04:09语音和视频，它们需要稳定流式传输，且对延迟极其敏感。在 Agent 和 Chat
00:04:16方面，需求主要体现在吞吐量维度，对极致延迟的要求倒没那么严苛；但实时
00:04:23语音和视频则对延迟有着绝对的敏感度。再看 Batch（批处理）工作负载，批处理的 SLA 限制则非常
00:04:32宽松。响应时间可以长达几秒、几分钟，对某些客户来说甚至可以按小时计算。
00:04:37他们的态度往往是：我把任务扔给你，给我提供 10 到 12 小时的批处理计算能力，我把能提交的都扔过来，
00:04:44你们抽空处理完即可。这些批处理负载之所以会影响
00:04:52我们在技术栈中的架构设计选择，是因为我们需要满足其特定需求。试想
00:04:59这四种截然不同的工作负载形态。在时间维度上，你必须根据各自的
00:05:04特性进行精细化调度，从而最大化地提升底层基础设施的利用率。
00:05:12下面我将高屋建瓴地介绍一下我们目前的架构栈形态，并带大家梳理一下
00:05:19这里的具体请求流程。无论是 Serverless 还是 Dedicated，观察屏幕右侧
00:05:24就会发现，在平台层面，请求首先进入控制平面（Control Plane），进行
00:05:31身份鉴权、限流控制以及用量追踪等，以便进行精准计费；
00:05:37同时配合可观测性组件，以确保我们没有违反已签署的 SLA 协议，
00:05:45对吧？在平台底层，我高度概括地展示了我们集成的各种
00:05:52推理引擎，比如 vLLM、SGLang 以及 TensorRT-LLM，稍后我会对此展开细讲。
00:06:00而在底层，我在这里用绿色标注的是各种不同的硬件。
00:06:09因此平台需要具备足够的能力，将工作负载
00:06:15高效分发到不同代际的 GPU 算力上，尤其是我们所使用的 NVIDIA GPU，
00:06:21对吧？我们来看几个具体的例子。假设请求源自
00:06:31客户端的应用、Notebooks 或智能体，请求首先到达网关（Gateway）。
00:06:36一旦命中网关，正如我提到的，控制平面会执行身份认证
00:06:42等一系列流程，随后请求将分流至 Serverless 或 Dedicated 模式。在 Serverless 模式下，
00:06:48系统按 Token 计费，因此这里会监控 Token 的使用量（并非监控具体的文本内容，
00:06:53仅统计 Token 用量，因为我们严格遵循 ZDR，即零数据保留政策）。
00:06:59接着根据是多租户还是预留资源，如果是预留资源，系统就知道
00:07:05底层路由器（Router）需要精准定向到为预留吞吐量客户
00:07:12准备的独立部署上。而对于普通多租户客户，则有独立的共享部署。
00:07:17这里的路由器（Router）扮演着极其关键的角色，因为它负责
00:07:26做出感知 KV Cache 的路由决策。这为什么重要？因为正如我们在讨论
00:07:31工作负载特征时提到的，Agent 场景通常具有极长的输入序列，
00:07:39且输入序列的大部分内容（取决于不同的公司或客户，大约占 80% 到 90%）
00:07:44在不同的请求之间都是完全高度重合的。
00:07:51因此，完全没有必要去重新计算或重复执行 Pre-fill（预填充）阶段。
00:07:57Pre-fill 是极度消耗计算资源的受限环节，开销十分昂贵，因此缓存命中率越高，
00:08:04能节省的成本就越多。这也是为什么看各大厂商的 Token 定价时，输入 Token 有标准价，
00:08:11而命中的缓存输入 Token 定价要便宜得多。因此，缓存机制在此处
00:08:18显得尤为关键。至于底层如何划分硬件，完全取决于平台的架构配置
00:08:26灵活性，我们支持两种模式：如果业务场景有需求，可以采用 Pre-fill 与 Decode（解码）解耦分离的架构；
00:08:31反之亦然，因为 Pre-fill 与 Decode 解耦并不适用于所有业务场景，且成本并不低。
00:08:41我们来看另一个请求流程。看看如果换成 Dedicated（专属资源）客户，会发生什么。
00:08:48专属客户的请求同样会通过为其专门搭建、具备良好隔离性的专属网关。
00:08:55其计费模式并非基于 Token，而是按照 GPU 的使用时长（每 GPU/小时）进行结算。
00:09:03这是一个私有网关，因此绝不会受到“嘈杂邻居”问题的干扰，外部流量无法侵入。
00:09:09底层依然运行相同的路由器逻辑，以便在遇到高度相似的请求时，能最大化地命中缓存。
00:09:18根据客户在其专属 GPU 上进行的部署方案，
00:09:24他们可以自主决定是否开启 Pre-fill 与 Decode 解耦；也可以自主选择
00:09:29使用哪种推理引擎（如 vLLM、SG-Lang 还是 TensorRT-LLM）。鉴于客户已预订了
00:09:35大量的算力容量，他们可以自由选择是采用单一部署并具备
00:09:42跨整个集群扩缩容的能力，还是部署多个不同的模型与服务。
00:09:47关于这里的路由器，有一点我想特别强调一下：
00:09:54我们支持跨不同可用区和地区的异构算力容量。
00:09:59在这类复杂环境下实现负载均衡是一个相当棘手的技术难题。
00:10:04因此我们采取的优先级策略通常是：首选 KV Cache 的亲和性本地化（Locality），其次是兜底的最小负载路由。
00:10:16以上就是这部分内容。接下来我想再梳理另一个请求流程，
00:10:21从架构图上可能不太容易直观看出，那就是 Batch（批处理）工作流。
00:10:25对于批处理工作流，我们的实际做法是充分利用客户现有的底层算力，
00:10:31假设同一个 Dedicated 专属推理客户，在美国白天的时段运行实时
00:10:37工作负载，而从傍晚到夜间希望运行批处理任务，同一套算力容量在特定时间段后
00:10:43便可被重新调度来执行批处理任务。因此，我们在 API 中提供了控制扩缩容时机的能力，
00:10:51如果客户通过计划任务通知我们可以缩容实时集群，
00:10:56我们就会执行缩容，并在夜间将其释放给批处理任务使用。
00:11:05关于 KV Cache 方面的优化我已经讲了不少，但我还是想略微复述
00:11:10一下，因为这是最核心精妙的部分之一。只要能提高缓存命中率，
00:11:19你就能避免预填充的开销，而这是其中最昂贵的部分。
00:11:26在智能体工作负载的不同轮次之间复用 KV 缓存，轮次之间
00:11:31输入序列长度中也有许多相似的预填充内容。
00:11:38想想对话类工作负载，这也是卸载 KV 缓存变得极其重要的原因，
00:11:43因为在对话工作负载中，我们作为用户在多次提问之间
00:11:49会有很大的延迟间隔。但如果我们完全逐出具体对话中的内容，
00:11:57那么下次在同一个对话中提问时，耗时就会稍微长一些。
00:12:02因此，与其完全逐出并重新进行预填充，现在使用的技术
00:12:08可能是——我们内部有自己的技术，外部大家熟知的是 LM Cache 和 Mooncake。
00:12:17我们的做法是将 KV 缓存卸载到高带宽存储中，
00:12:21这样就能存储大量此类预填充，以便在该特定对话的后续请求传来时，
00:12:28只要有该对话的后续请求进来，就能立即将其加载到 HBM 中。
00:12:37在性能杠杆方面，我想提几个我们讨论过的性能杠杆，
00:12:41讨论过的性能杠杆，PD 分离是一个，量化和投机解码则是另外两个，以及如何
00:12:48精心选择并行度与策略，这其实非常重要。
00:12:54我们一直在研究的两个最大杠杆是 NVFP4 量化和投机解码。
00:13:01我们确实提供了这项功能：如果客户有自己的数据集，并希望我们针对其数据集训练小模型（speculators），
00:13:07以获得更好的接受长度，从而最终大幅提升输出吞吐量，
00:13:12显著提升，我们也有这项服务。但这是异步进行的，我们会异步获取数据、
00:13:20异步训练投机模型，然后再根据客户需求将投机模型部署到其环境中
00:13:26如果这是他们所需要的话。大家在这里可以看到三张截图。这是我贴出的
00:13:32过去一个月里，我们团队中部分成员的工作成果。你可以看到我们
00:13:39快速冲上了 Kimi 2.6、2.7 的排行榜前列，这些数据来自 Artificial Analysis。
00:13:46回到上一个环节的问题：我们能信任这些数据吗？所以对于 GLM，我展示的是
00:13:52来自 OpenRouter 的结果。Artificial Analysis 在运行基准测试时，跑的是非常特定类型的工作负载。
00:13:58而 OpenRouter 则是真实的真实用户流量。你可以在 OpenRouter 侧看到 Weights & Biases。虽然
00:14:05品牌名称不同，但 Weights & Biases 基本上就是 Curv。我们在大概一年前
00:14:09收购了 Weights & Biases。你可以看到我们部署的响应速度
00:14:16非常接近 Fireworks 所提供的 Fireworks Fast 模式，对吧？但我们在底层使用的技术
00:14:21才是我在这里最想强调的性能优化要点。这至关重要，因为
00:14:27归根结底，你想为客户提供、我们想为客户提供的，是性价比红利。
00:14:36快速回顾一下，我一直试图强调和展示的，是一个统一的平台。
00:14:44为客户提供两种不同的消费模式：无服务器（Serverless）和专用（Dedicated）；而在无服务器模式下，
00:14:49我也介绍了两种不同的消费模式：按量付费，以及在在意性能保障时的预置吞吐量模式，
00:14:53最终通过整个技术栈的性能优化来实现收益复利。
00:15:01以上就是全部内容。谢谢大家。

핵심 요약

CoreWeave 构建了一个统一的推理平台，通过灵活的消费模式、感知 KV Cache 的智能路由以及高带宽存储卸载等性能优化手段，实现了从 MVP 到万亿参数规模工作负载的高性价比服务。

하이라이트

  • CoreWeave 提供 Serverless 和 Dedicated 两种核心消费模式，并在 Serverless 下引入预留吞吐量（Provisioned Throughput）功能以消除嘈杂邻居（Noisy Neighbor）干扰。

  • Agent 工作负载对多轮交互延迟极敏感，且 80% 至 90% 的输入序列在不同请求间高度重合，使得 KV Cache 命中率成为降低 Pre-fill 阶段开销的关键。

  • 平台利用跨可用区和地区的异构 GPU 资源，在路由决策上优先采用 KV Cache 亲和性本地化（Locality），其次采用最小负载路由。

  • 通过将 KV 缓存卸载至高带宽存储（如 LM Cache 和 Mooncake 技术），可在提问间隔期保存预填充数据，并在后续请求到来时快速载入 HBM。

  • 系统支持异步训练客户专用的投机模型（speculators），通过提高接受长度来显著提升输出吞吐量。

타임라인

推理平台的核心消费模式与服务形态

  • Serverless 模式屏蔽了硬件管理与资源编排细节，按 Token 计费并提供丰富的模型选择。
  • Dedicated 模式允许用户自主决定模型部署策略与性能配置，按 GPU 使用时长结算。
  • 预留吞吐量（Provisioned Throughput）功能为有明确流量特征的客户划分专属后端资源，保障 SLA 并消除嘈杂邻居问题。

平台针对不同需求的客户提供差异化的服务架构。Serverless 模式适合需要直接调用 API 且按 Token 消费的场景。对于担心多租户抢占资源的客户，预留吞吐量通过后台划分专属资源解决了超时问题。Dedicated 模式则面向希望明确硬件环境并掌控部署细节的大型用户，防止外部流量侵入。

多样化工作负载特征与技术栈架构设计

  • Agent 与 Chat 负载虽然都有长输入短输出的特征，但 Agent 的多轮交互对延迟的要求显著高于 Chat。
  • 控制平面负责身份鉴权、限流控制、用量追踪和 SLA 监测，底层的路由层支持感知 KV Cache 的智能调度。
  • 集群路由在异构算力环境中优先保证 KV Cache 亲和性本地化，其次使用最小负载策略进行调度。

实时语音视频负载对延迟极其敏感，而批处理负载（Batch）的 SLA 限制则十分宽松，响应时间可达数小时。由于 Agent 场景中 80% 至 90% 的输入序列在请求间高度重合，优化 Pre-fill 阶段的缓存命中率能大幅降低昂贵的计算开销。控制平面底层集成了 vLLM、SGLang 及 TensorRT-LLM 等推理引擎，并支持 Pre-fill 与 Decode 解耦架构。

批处理调度、KV Cache 卸载与性能提升杠杆

  • 通过 API 控制缩容时机，可将 Dedicated 客户在夜间闲置的实时算力释放给批处理任务使用。
  • 利用高带宽存储卸载 KV 缓存，避免了对话间隔期间完全逐出数据所带来的重新预填充开销。
  • NVFP4 量化与异步训练投机模型（speculators）是提升输出吞吐量与性价比的重要性能杠杆。

针对对话类任务中用户提问间隔较长的特点，系统将 KV 缓存暂时卸载至高带宽存储，并在新请求传入时重新载入 HBM。在异步流程中，平台可利用客户数据集训练专用的投机模型以增加接受长度。实际测试数据显示，这些优化手段帮助平台在 OpenRouter 和 Artificial Analysis 排行榜中取得了领先的响应速度。

커뮤니티 글

아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!

이 영상에 대해 글쓰기