随着全球人工智能采用的加速，开发者面临日益严峻的挑战：如何提供符合现实世界延迟和成本要求的大语言模型（LLM）性能。在生产环境中运行拥有数百亿参数的模型，尤其是对话式或基于语音的AI智能体，需要实现高吞吐量、低延迟以及稳定可预期的服务水平表现。对于从零开始构建自主可控AI模型的初创企业而言，这些挑战尤为突出，因为它们必须在模型规模与准确性、基础设施效率之间取得平衡，同时确保数据主权并有效控制成本。
Sarvam AI，一家位于印度班加罗尔的生成式 AI 初创公司，致力于构建大型、多语种、多模态的基础模型，为印度多元化的群体提供服务，支持近 20 种语言，并将模型开发与数据管理完全置于印度主权控制之下。为满足严格的延迟要求并提升其旗舰 Sovereign 30B 模型的推理效率，Sarvam AI 与 NVIDIA 合作，共同设计硬件与软件的优化方案。
与基准 NVIDIA H100 GPU 相比，NVIDIA Blackwell 的推理性能提升达 4 倍，为在新一代 NVIDIA Blackwell 架构上部署提供了坚实基础。通过在 NVIDIA H100 SXM GPU 上优化内核与调度策略，实现了 2 倍的速度提升，显著增强了端到端性能。结合 Blackwell 强大的计算能力与 NVFP4 权重量化技术，可进一步实现额外 2 倍的加速效果；在更高交互性场景下，性能提升可达 2.8 倍。
NVIDIA 工程师协助 Sarvam AI 构建了 3B、30B 和 100B 规模的基础模型，并优化了全新的主权基础模型系列。这些模型均基于 NVIDIA Nemotron 库，包括 NVIDIA NeMo 框架 和 NVIDIA NeMo-RL 进行训练，支持 22 种印度语言，涵盖英语、数学和代码等领域。该成果展示了开发者团队如何借助 NVIDIA 全栈 AI 平台（从数据到部署）实现卓越的性能与本地化 AI 功能。
本文将介绍联合工程设计工作，并分享 NVIDIA H100（在印度部署规模领先的 NVIDIA GPU）的加速基准。同时，我们还将提前探讨如何根据 NVIDIA Blackwell 架构对这些工作负载进行优化调整。
通过 MoE 实现多语言主权 AI 的可扩展性
为了高效提供主权级智能，Sarvam AI 模型采用了专为深度推理与高语言密度任务定制的复杂异构混合专家（MoE）架构。这些模型基于 混合专家（MoE）架构，参数规模涵盖 3B、30B 及 100B，基于 NVIDIA NeMo 框架和 NVIDIA Megatron-LM 从零开始进行预训练。Furthermore, Nemo-RL 被用于模型的后训练流程，包括长上下文推理。
为了高效提供主权级智能，Sarvam AI 模型采用了专为深度推理与高语言密度任务定制的复杂异构混合专家（MoE）架构。这些模型基于 NVIDIA NeMo 框架和 NVIDIA Megatron-LM 从零开始进行预训练，参数规模涵盖 30B、30B 及 100B。此外，Nemo-RL 还被应用于模型的后训练流程，以支持长上下文推理等高级能力。
Sarvam 30B 采用 19 层深度结构（1 密集层 + 18 个 MoE 层），包含 128 个专家，利用 top-6 路由策略，并结合分组查询注意力（GQA）以平衡内存带宽与生成质量。
Sarvam 100B 将此设计扩展至 32 层（1 dense = 31 MoE），并在 128 位专家中采用排名前 8 的路由策略，其中 MoE FFN 的隐藏层维度更大，达到 2048。此外，100B 模型采用多头潜在注意力（MLA）（类似于 DeepSeek-V3），可有效压缩键值（KV）缓存，从而在不牺牲标准注意力内存的前提下支持大规模上下文窗口。
这两种模型均采用共享专家设计，其中一位专属专家负责处理常见功能，另一位专属专家则负责处理专业任务。这种高活跃参数数量（通过 top-6/top-8 路由）与复杂的内存访问模式相结合，带来了独特的服务挑战，需在 NVIDIA Hopper 和 NVIDIA Blackwell GPU 上进行深度内核优化，下文将对此进行详细说明。
性能挑战：NVIDIA H100 上的服务水平协议与基准配置
优化 Sarvam 30B 模型不仅关乎原始速度，还需在严格的延迟限制下尽可能提升密度。针对该模型所服务的应用（语音到语音代理），我们制定了以下服务水平协议（SLA）：
- P95（第 95 百分位）首token 时间（TTFT）：约 1000 毫秒
- P95（第 95 百分位）token 间延迟（ITL）：约 15 毫秒
在推理性能测试中，P95（第 95 百分位）用于衡量延迟，表示 95% 的服务请求完成时间快于该数值，仅有 5% 的请求耗时更长。这一指标是评估用户体验与系统稳定性的关键尾部延迟参数，用以确保在负载条件下，绝大多数用户所经历的延迟仍处于可接受范围。工程目标是在不超出 P95 延迟要求的前提下，尽可能提升推理服务器的 token 吞吐量（即并发处理请求的能力）。
在初始性能分析中，Sarvam AI 与 NVIDIA 团队选用了 SGLang 推理引擎进行评估。与将 KV 缓存视为线性缓冲区的传统服务框架不同，SGLang 采用了 RadixAttention 机制，该机制将 KV 缓存作为基数树进行管理。这对 Sarvam 30B 架构尤为关键：RadixAttention 支持自动前缀共享，能够一次性计算共享的专家上下文和系统提示，并在多个并发请求中重复利用。此外，SGLang 的缓存感知调度程序可有效提升这些共享前缀的命中率，大幅降低预填充阶段的冗余内存操作。
Sarvam AI 与 NVIDIA 团队对生产流量配置文件进行了建模，其特征为平均输入序列长度（ISL）3584 个 tokens，输出序列长度（OSL）128 个 tokens。在内部仿真数据的指导下，我们在两块 NVIDIA H100 SXM GPU 上部署了该模型，并采用特定的并行策略，以平衡 MoE 层在内存和计算方面的不同需求。
- 专家权重的专家并行（EP = 2）。此配置通过采用分组 GEMM 内核来提升计算密度，同时确保大量专家权重驻留在 HBM 中，从而降低专家路由的开销。
- 结合 -enable-dp-attention 实现注意力权重的数据并行（DP = 2）。该策略支持在多个并行批次中同时处理注意力计算，有效提升预填充阶段的整体吞吐量。
虽然此配置提供了可靠的功能基准，但分析表明，在高并发场景下实现亚秒级 TTFT 需要更深入的优化，这促使我们转向具体的内核与精度策略，具体如下。
从分析到优化：突破 MoE 瓶颈
模拟数据表明，32 至 64 个请求的并发范围较有可能满足 SLA 要求。为确定在此并发范围内限制 token 吞吐量的具体瓶颈，NVIDIA 与 Sarvam AI 团队采用 NVIDIA Nsight Systems，以 32 个并发请求的形式捕获预填充和解码阶段的执行追踪。随后，我们对追踪数据进行处理，以提取单个 Transformer 层中每个内核的微秒级延迟贡献。
分析结果显示，尽管计算密集型的通用矩阵乘法（GEMM）运算（专家和注意力部分）表现良好，但在非计算密集型操作中仍存在显著的延迟气泡，尤其是在 MoE 路由逻辑和位置嵌入计算环节。这些操作面临内核启动开销大以及内存读取冗余的问题。
根据这些观察结果，我们从三个维度实施了有针对性的优化策略，分别是内核优化、调度效率和细分服务。
通过内核级优化将 Transformer 层的耗时缩短 34%
NVIDIA 和 Sarvam AI 团队系统地锁定了追踪中识别出的开销最高的内核，用特定于架构的融合内核替代了标准的 PyTorch 实现。我们首先在 H100 GPU 上的 SGLang 中使用基准实现来部署模型，随后对其进行优化以实现显著加速，具体结果如表 1 及下文所述。
| 内核 | 基准时间 (微秒) | 优化时间 (微秒) | 已应用优化 |
| RMSNorm = 准备 QKV | 186 | 185 | N/A |
| QK Norm = RoPE | 414 | 54 | 使用优化的原位查询-键归一化内核 |
| Attention | 322 | 296 | 使用 FA3 进行预填充，FlashInfer 后端用于解码 |
| Post-attention 线性投影 | 114 | 112 | N/A |
| AllReduce | 252 | 250 | N/A |
| Router logits 和 TopK | 560 | 134 | 使用融合 TopK 实现；ReplicatedLinear 模块用于 router logits |
| 路由专家计算 | 1103 | 1080 | 调优内核参数以适配 DEP2 配置（每个 GPU 64 位专家） |
| 共享专家计算 | 216 | 215 | 使用 NVIDIA CUDA 流与 TopK 重叠 |
| AllReduce | 265 | 249 | N/A |
| T 层总时间 | 3432 | 2575 | 1.34 倍整体预填充速度提升 |
MoE 路由（比基准 H100 性能快 4.1 倍）：已确认的主要瓶颈是 MoE 路由机制。在基准测试中，计算路由器日志并执行 TopK 选择需多次启动内核并产生冗余的内存往返。
- 优化：我们实现了 Fused TopK 内核，将 logit 计算与选择逻辑融合至单个 CUDA 内核中。同时，针对路由器 logits 采用了 ReplicatedLinear 模块。由于路由器权重较小，跨 GPU 复制这些权重可消除门控阶段中高昂的通信开销，从而使该操作完全受限于计算性能。
融合位置嵌入（性能比基准 H100 快 7.6 倍）： 查询密钥（QK）范数的基准实现以及旋转位置嵌入（RoPE）均需对大量 KV 缓存进行两次读写操作。
- 优化：我们部署了自定义的就地融合 QK 规范与 RoPE 内核。该内核能够在一次传递中完成归一化和旋转嵌入的计算，使数据保留在 L2 缓存中，降低全局内存带宽的消耗。
通过重叠隐藏延迟：尽管共享专家计算本身的加速效果微乎其微，但我们有效掩盖了其开销。借助独立的 NVIDIA CUDA 流，我们将共享专家的计算与路由器 logits 及 TopK 计算安排为异步执行。这种并行机制确保 GPU 的计算单元（流多处理器或 SM）在解析路由逻辑的同时仍能保持充分负载。
这些有针对性的内核优化将预填充阶段每个 Transformer 层的总处理时间从 3.4 毫秒缩短至 2.5 毫秒，相比基准 H100 性能提升了 1.3 倍。延迟的降低直接带来了更高的并发支持能力，使我们能够在每个 GPU 上为更多用户提供服务，同时仍将首个 token 延迟（TTFT）以及约 15 毫秒的 token 间延迟（ITL SLA）严格控制在 1000 毫秒以内，如图 2 所示。
混合预填充与解码调度如何提升 GPU 利用率
虽然内核级优化能够改善单个操作的延迟，但通过优化聚合服务（在同一 GPU 上运行预填充和解码）与分解服务（在不同 GPU 上运行预填充和解码），可在调度程序层面实现显著的效率提升。
SGLang 引擎中聚合服务的默认调度策略是严格序列化预填充和解码阶段。在此默认模式下，GPU 会先处理一批预填充请求，待其全部完成后，才切换至解码阶段的处理。尽管这种做法简化了内存管理，但通常会导致 GPU 利用率不高。预填充阶段通常受计算限制（涉及密集矩阵乘法），而解码阶段则受内存限制（需频繁加载 KV 缓存）。由于两个阶段被串行执行，GPU 的 Tensor 核心单元（SM）在解码阶段难以充分使用，同时在预填充阶段，内存带宽也可能未能充分利用，尤其是在严格的 SLA 要求下导致的低并发操作点时更为明显。
为解决此问题，我们启用了混合批处理策略。该方法允许 SGLang 调度程序在同一批量或计算块中同时处理预填充 tokens 和解码 tokens。通过整合预填充 tokens 的处理与持续的解码请求，我们在 GPU 上实现了更均衡的资源配置。然而，这种优化引入了一定的权衡：将计算密集的预填充块混入解码流中，可能导致活动解码请求的 inter-token 延迟（ITL）上升，因其需等待共享计算资源。
但是，对于 Sarvam 30B 工作负载，我们发现这种影响极小，仍在我们 15 毫秒的 ITL SLA 范围内。作为交换，由于队列时间的缩短，端到端请求延迟得到显著改善。通过更快地清空预填充队列（在解码时附带），我们减少了等待请求启动的时间，从而将系统总吞吐量提升了 15%。这种调度优化在当前关注的高 ISL、低 OSL 场景中尤为有利。对于解码比例更高的场景，采用较小的混合数据块或完全禁用该数据块可能是更合适的选择。
分离服务如何消除关键路径并使吞吐量提升1.5倍
尽管改进了内核和调度，但我们的分析表明，token 分布（专家并行）的 GPU 间通信仍处于关键路径上。由于 Sarvam 30B 模型（通过 FP8 精度进行优化）可轻松适配单个 NVIDIA H100 SXM GPU 的显存，我们决定从模型并行转向分解服务。
我们重新配置了设置，通过 SGLang 路由器采用 1P+1D 策略：将一个 NVIDIA H100 SXM GPU 专门用于预填充，另一个用于解码。该方法消除了前向传递过程中在 GPU 之间路由 tokens 的开销。效果立竿见影：TTFT 显著降低（得益于预填充工作进程持续运行），同时每位用户的解码吞吐量大幅提升（较基准 H100 性能高出 1.5 倍），表明对于此模型规模，工作流分离的优势已超越聚合内存容量的收益。
内核、调度与分解优化的端到端影响
下图 5 总结了我们通过结合使用优化内核和调度优化所实现的端到端性能加速效果。我们还发现，针对该模型和 ISL/ OSL 工作负载模式，以及特定的 TTFT 和 ITL SLA 要求，解服务是较为理想的配置方案。
在 Blackwell NVIDIA GPU 上运行 Sarvam 30B 模型
NVIDIA Blackwell 架构旨在加速生成式 AI。NVIDIA Blackwell GPU 可提供高达 20 PFLOPS 的 FP4 峰值计算能力和 8 TB/s 的显存带宽，性能超越 NVIDIA H100 GPU。这一吞吐量由第二代 Transformer 引擎驱动，该引擎采用全新的 NVFP4 格式，在保持高模型精度的同时，性能较 FP8 提升逾两倍。
为了利用 Sarvam 模型中的这些功能，我们采用 NVIDIA Model Optimizer 将基础 BF16 模型量化为 NVFP4 格式。与需多个 H100 GPU 的配置不同，NVIDIA HGX B200 仅使用一块 Blackwell GPU 即可高效地为 Sarvam 30B 模型提供服务。通过结合模型的内核与调度优化以及 NVIDIA Blackwell 的 NVFP4 计算吞吐能力，我们实现了推理服务吞吐量 4 倍的提升，达到每个用户操作点每秒 75 个 tokens 的处理速度。
如下图 6 所示，NVIDIA Blackwell GPU 凭借其卓越的计算能力，在低延迟条件下实现高性能，并依托显存容量优势，在高并发场景下展现出优异的吞吐能力。
了解详情
这项工作共同展示了将模型设计、内核工程、调度策略、量化和 GPU 架构视为一个整体系统而非独立组件时所能实现的潜力。通过在全栈范围内协同优化，Sarvam AI 与 NVIDIA 在满足现实世界部署所要求的严格 TTFT 和 inter-token 延迟目标的同时，显著提升了吞吐量与延迟表现。
这不仅是一个速度更快的模型，更是一个具备成本效益且符合主权要求的推理堆栈，能够扩展以支持国家级工作负载。这些实践经验为其他在 NVIDIA 平台上构建大型生产级 AI 系统的团队提供了 blueprint。
要探索您自己的自主 AI 模型策略，可查看 NVIDIA Nemotron 框架和库，以便在本地基础设施上训练、微调和部署模型。
- 访问我们的 Nemotron 开发者页面，获取开始使用高度开放、智能的单次计算推理模型所需的所有要点。
- 在 build.nvidia.com 上探索有关 Hugging Face 以及 NIM 微服务 和 Blueprints 的全新开放 Nemotron 模型和数据集。
- 收听即将推出的 Nemotron 直播，并通过 Nemotron 开发者论坛 和 Nemotron 频道 在 Discord 上与 NVIDIA 开发者社区建立联系。
- 浏览 视频教程和直播，充分利用 NVIDIA Nemotron。
单击此处，深入了解 NVIDIA 的多云高性能 AI 推理解决方案 NVIDIA Cloud Functions。
