33.7B 总参只激活 4B稀疏转写省下的到底是显存还是时间【免费下载链接】NVIDIA-Nemotron-3.5-Transcribe-30B-A4B项目地址: https://ai.gitcode.com/hf_mirrors/nvidia/NVIDIA-Nemotron-3.5-Transcribe-30B-A4B“30B 级模型、4B 级激活”这句话在语音转写赛道已经变成了标准宣传语。听起来像是把一张 80GB 显卡的账单砍到了 24GB 显卡的水平。但如果把 model.safetensors 的 LFS 元数据、config.json 的层结构和 README.md 里的 RTFx 表放在一起核算结论会很不客气稀疏专家省下的是每个 token 的算力预算不是权重驻留的显存预算。33.7B 参数一个字节都不能少地躺在卡上激活 4.3B 只决定了它能算多快不决定它能不能装下。这篇文章用仓库里的真实配置把这个账算清楚钱显存花在哪里时间吞吐漏在哪里以及为什么把投机 token 从 2 个加到 8 个吞吐反而从 410 RTFx 掉到 270 RTFx。先把三个数字钉死标题里的 33.7B 不是估值是文件大小反推出来的。仓库里的权重指针写明size 67496013734即 67.50 GB。BF16 每参数 2 字节67,496,013,734 ÷ 2 ≈ 33.75B且这个数字包含音频编码器、说话人编码器与 CTC 头与 README 中 “34B (4.3B active), including the audio encoder” 的口径一致。标题取 33.7B是把十进制 GB 换算成参数量后的精确值。激活侧 README 给的是 4.3B其中语言主干约 3.5B、联合音频编码器约 800M。换句话说稀疏度按激活占比 4.3 / 33.75 ≈12.7%路由专家的稀疏度 top-6 / 128 ≈4.7%这两个数字经常被混用。4.7% 只是 MoE 层内部的门控稀疏12.7% 才是整机口径因为 Mamba 层、注意力层、共享专家、embedding 和输出头都是稠密计算的躲不开。稀疏专家的落点编码侧稠密解码侧稀疏architecture.png 把落点画得很清楚稀疏只发生在右侧的生成主干左侧的音频通路是纯稠密计算。按 config.json 与 llm_backbone/config.json 逐项核对模块结构参数量级是否稀疏ASR 编码器32 层 Transformerd_model128010 头8× 下采样约 600M稠密说话人编码器Sortformer31 层d_model5128 个 speaker slotfreeze_diar: true约 99M稠密、冻结CTC 时间戳头2 层、upsampling_factor: 2、词表 23863约 47M稠密语言主干52 层 23 Mamba-2 23 MoE 6 Attention约 33BMoE 稀疏语言主干里只有 6 层是全注意力num_key_value_heads: 2、head_dim: 12823 层是 Mamba-2 状态空间层23 层是 MoE。MoE 的配置是n_routed_experts: 128、num_experts_per_tok: 6、n_shared_experts: 1、routed_scaling_factor: 2.5共享专家中间维3712恰好是路由专家moe_intermediate_size: 1856的两倍。这个结构对成本的含义是单向的音频进来先过一段完全稠密、不可稀疏化的编码然后才进入可以被稀疏化的自回归解码。所以“激活 4B”这句话在时序上只覆盖了后半段。顺带把 token 预算算出来后面所有的账都要用它。processor_config.json 里hop_length: 160、sampling_rate: 16000即每 100ms 一个 mel 帧subsampling_factor: 8之后是 80ms 一个音频 token也就是12.5 token/秒30 秒音频 → 375 个音频 token正好对上 config.json 的encoder_chunk_size_seconds: 30.01 小时音频 → 45,000 个音频 tokenmax_position_embeddings: 262144但训练与部署实际锚定在 65,536README 提到“密集的一小时对话可能需要约 20,000 个输出 token”。于是单条长音频的输入输出比约45,000 : 20,000 ≈ 2.25 : 1。这个比例决定了它是一份“预填充少、解码多”的工作负载后面会看到它如何支配整机吞吐。显存账本MoE 省不出 VRAM先看一张 H100 80GB 上按官方命令启动后的真实可用空间。README 给的参数是--gpu-memory-utilization 0.94即预算 75.2 GB。BF16 权重占 67.5 GB占掉 89.8%剩余约 7.7 GB要给激活、工作区、CUDA graph、音频缓冲和所有序列的缓存状态。再看缓存侧。KV 只发生在 6 层全注意力上每 token 每层存 K 和 V、各 2 个头、每头 128 维、BF166 层 × 2 (K/V) × 2 头 × 128 维 × 2 字节 6 KB/token 65,536 token × 6 KB ≈ 384 MB单序列满上下文 45,000 音频 token × 6 KB ≈ 270 MB单条 1 小时音频也就是说即便把上下文顶满KV 也只是百 MB 量级——这正是 23 层 Mamba-2 换来的好处只有 6 层参与二次增长的注意力缓存。但 Mamba 层不是免费午餐它换的是“与长度无关、却与并发强相关”的状态。按mamba_num_heads: 64、mamba_head_dim: 64、ssm_state_size: 128、mamba_ssm_cache_dtype: float32估算单层 SSM 状态约64×64×128×4 ≈ 2 MiB23 层合计约46 MiB/序列且不随音频长短变化。它与--max-num-seqs 192是同一个数量级的约束192 × 46 MiB ≈ 8.6 GB。这就解释了启动命令里那个容易被忽略的组合--use-replayssm --mamba-backend flashinfer --mamba-cache-mode none。缓存模式设为 none意味着它选择不长期驻留这些状态而是在需要时用 ReplaySSM 重放重建。这是一次赤裸裸的交换——用重复计算换显存。它同时也回答了本文标题的一半在这个模型里“省显存”的手动开关从来不是 MoE而是缓存策略。真正把权重体积压下去的是精度而不是稀疏度。README 的硬件兼容表本身就是证据精度权重体积估算80GB 卡剩余预算官方列出的可落地硬件BF1667.5 GB约 7.7 GBA100 80GB、H100、H200、B200FP8约 33.7 GB约 41 GB追加 L40S 48GBNVFP4约 16.9 GB约 58 GB追加 RTX PRO 6000、DGX Spark、Jetson Thor、RTX 509032GB注意最后一行RTX 5090 只出现在 NVFP4 一列。一张 32GB 消费卡能跑 33.7B 模型靠的是把每个参数压到 4 bit而不是靠“只激活 4B”。如果只激活就能省显存BF16 那 67.5 GB 就没必要存在了。时间账本单流撞带宽批量才兑现稀疏解码阶段每生成一个 token都要把当前激活的那部分权重从 HBM 搬进 SM。激活 4.3B、BF16即8.6 GB/步。H100 的 HBM3 带宽约 3.35 TB/s单流理论上限3.35 TB/s ÷ 8.6 GB ≈ 390 token/s这是“batch 1”的天花板且是带宽墙不是算力墙——此时算术强度只有约 1 FLOP/ByteSM 大部分时间在等数据。MoE 在这一步的作用是把 8.6 GB 而不是 67.5 GB 搬一遍收益是实打实的 7.8 倍访存量削减。这就是稀疏真正兑现的地方。但只有批起来算力才会成为新瓶颈。batch 增大后权重读取被摊薄吞吐才会向算力上限爬升。问题回到上一节BF16 下单卡只剩 7.7 GB 余量batch 根本批不大。用 RTFx 反推一下量级——英语 ASR 大约每秒音频产出 3 个多 token410 RTFx 对应约 1,300 token/s 的聚合速率相对 390 token/s 的单流上限等价并发只有个位数。稀疏把门开得很大显存把门框卡得很死。再看预填充侧的量级。按 2 × 激活参数 × token 数粗算45,000 音频 token 的预填充 ≈ 2 × 4.3B × 45,000 ≈387 TFLOP20,000 步解码 ≈ 2 × 4.3B × 20,000 ≈172 TFLOP总浮点量差不多但形态完全不同前者是一次可以打满 Tensor Core 的大矩阵乘后者是两万次“搬 8.6 GB、算一点点”的访存循环。转写这种任务的耗时结构天生偏向解码侧因此 MoE 对它的加速效果远不如对“长上下文、短输出”的对话类负载那么夸张。音频编码器的账也要算config.json 里编码器d_model: 1280、ff_expansion: 4、32 层每 token 约 1.26 GFLOP1 小时音频45,000 token合计约57 TFLOP只相当于预填充的 15% 左右。而且这段计算是不可稀疏的稠密前段只能靠 30 秒分块encoder_chunk_size_seconds: 30.0与packed_encoder_sequences: true做流水线重叠没法靠 MoE 加速。真实瓶颈解码步数而不是稀疏度这张图里藏着全文最反直觉的事实。横轴是中位请求延迟纵轴是吞吐RTFx左上角更优。图例分成两层颜色是精度线型是投机解码策略none / MTP 8 tokens / DFlash2 15 tokens。可以读出的三件事第一精度是最强的单一变量。BF16绿在两条子图上都趴在最低一档约 400 RTFx 封顶FP8蓝与 NVFP4橙几乎重合抬到 1,500–1,800 RTFx。同一份权重、同一张卡只换数值格式就是 4 倍量级的差距——原因还是那条解码受 HBM 带宽约束权重体积减半每步搬运就减半。第二批大小沿着曲线向右上移动。图注写明数据点是并发 1、4、16、64、128、256。低并发段曲线几乎垂直上升延迟不变、吞吐线性涨说明此时算力大量闲置、加批几乎免费到了 64–256 区间曲线转平进入算力饱和区。这正是 MoE 优势的兑现窗口也是显存最先告急的地方。第三也是最关键的投机解码不是越多越好。README 给出的 H100 BF16 实测解码模式近似 BF16 RTFxMTP2410MTP8270DFlash2 K7340DFlash2 K15260把每步提议的 token 从 2 个加到 8 个吞吐掉了三分之一DFlash2 从 K7 加到 K15 同样掉二成多。原因不难推投机解码的收益是“减少解码步数”代价是“每步验证变贵 接受率衰减”。批量场景下验证成本随B×K增长而第 7、第 8 个草稿 token 的接受概率已经很低净收益转负。所以官方推荐的是 MTP2 或 DFlash2 K7而不是更大的 K。这也修正了关于“瓶颈”的直觉真正卡住转写吞吐的既不是稀疏度也不是浮点峰值而是解码步数 × 每步权重搬运量 × 可承受并发这三者的乘积。--speculative-config {method:mtp,num_speculative_tokens:8}写在启动命令里是官方示例但在 H100 上它并不是最快的那一档。还有一个必须点明的落差README 的 Efficiency 一节给出的 2,238 RTFx、30 秒音频 0.13 秒返回是在 **RTX PRO 6000 Blackwell 上跑 NIM 的优化实现NVFP4 DFlash2**测得的而“release day 随 NeMo Speech 发布的 vLLM 集成约慢 2 倍”。同一份权重、同一张卡纯软件栈差异就是 2 倍——这再次说明瓶颈在调度、kernel 与缓存策略而不在模型有多少专家。把账算到自己机器上官方单卡启动命令里有几个参数每一个都对应上面某一笔账值得逐条对上export VLLM_PLUGINSnemo_speechlm export VLLM_MAX_AUDIO_DECODE_DURATION_S3600 # 默认 600s只放行 10 分钟音频 export VLLM_MAX_AUDIO_CLIP_FILESIZE_MB180 export VLLM_USE_V2_MODEL_RUNNER0 # 词级时间戳依赖 V1 runner vllm serve ./NVIDIA-Nemotron-3.5-Transcribe-30B-A4B \ --dtype bfloat16 --gpu-memory-utilization 0.94 \ --max-model-len 65536 --max-num-batched-tokens 4096 --max-num-seqs 192 \ --enable-chunked-prefill --no-enable-prefix-caching \ --use-replayssm --mamba-backend flashinfer --mamba-cache-mode none \ --speculative-config {method:mtp,num_speculative_tokens:8}--max-model-len 65536不是随便取的它对应“1 小时音频 45,000 音频 token 提示词 输出”的上界。想处理更长的录音只能外部分段而不是调大这个值。--max-num-batched-tokens 4096一条 1 小时录音的 45,000 个音频 token 要切成约 11 个预填充块。块越小首字延迟越低但吞吐越差——这是又一处时间换时间的旋钮。--max-num-seqs 192与前面估算的 Mamba 状态约 46 MiB/序列量级吻合是显存而不是算力在决定这个数。--no-enable-prefix-caching转写请求之间几乎没有公共前缀每条音频都是新 token开了只浪费元数据开销。--mamba-cache-mode none--use-replayssm明确选择“不缓存状态、按需重放”用时间换显存。如果目标是吞吐而不是单卡验证README 给了专家并行的走法--data-parallel-size 8 --api-server-count 8 \ --enable-expert-parallel --disable-custom-all-reduce这一行才是“用稀疏度省显存”的唯一正确姿势128 个路由专家被切分到 8 张卡上TP1、DP8、EP8每张卡只驻留 1/8 的专家权重。张量并行切不了专家维度只有专家并行能把 67.5 GB 摊到 8 张卡上。单卡谈 MoE 省显存本质上谈错了对象。如果只有一张 24–48GB 的卡路径也很清晰换 FP8 或 NVFP4 权重而不是指望激活比例。这也是硬件表把 L40S 48GB 限定在 FP8、把 RTX 5090 限定在 NVFP4 的原因。结论省下的是“每 token 的时间”前提是“显存先够”把两条账并排放问题就结束了维度MoE/稀疏专家带来的变化实际决定因素权重驻留无变化33.7B 全量驻留参数量 × 精度想省显存靠 FP8/NVFP4 或 EP 切分KV 缓存间接受益只有 6 层全注意力层数 × KV 头数 × 上下文长度Mamba 状态无变化约 46 MiB/序列且与长度无关并发数可用mamba-cache-mode none换显存每 token 算力降低约 7.8 倍8.6 GB vs 67.5 GB 访存激活参数 4.3B单流延迟明显受益带宽墙被推低HBM 带宽 ÷ 激活权重字节数批量吞吐需要足够显存才能兑现剩余显存 →max-num-seqs→ 可批大小解码步数与稀疏无关靠投机解码压缩MTP2 / DFlash2 K7 优于更大 K所以标题里的问题有一个不含糊的答案稀疏专家省下的是时间——准确地说是每个 token 的权重搬运时间它一分显存都没省。而这份时间收益能不能兑现取决于你有没有先把 33.7B 装进去、并留出足够的余量把 batch 批起来。这解释了为什么同一份权重在不同硬件上表现差异如此之大A100 80GB 只能 BF16几乎没余量批处理L40S 48GB 用 FP8 反而更从容RTX PRO 6000 用 NVFP4 加 DFlash2 能跑到 2,238 RTFx。模型没变稀疏度没变变的只是“权重占多少、剩下多少留给并发”。对工程落地的直接建议只有三条先把精度降下来腾出显存再用 MTP2 或 DFlash2 K7 压解码步数最后才去调max-num-seqs和max-num-batched-tokens找吞吐拐点。把顺序倒过来就会得到一台“激活只有 4B、但一张 80GB 卡只能跑个位数并发”的机器。【免费下载链接】NVIDIA-Nemotron-3.5-Transcribe-30B-A4B项目地址: https://ai.gitcode.com/hf_mirrors/nvidia/NVIDIA-Nemotron-3.5-Transcribe-30B-A4B创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
