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

一个包含 300 亿个参数的模型如何仅对每个 token 激活 300 亿个参数,同时仍然使用更大模型的容量?Nemotron 3.5 Lightning 说明了答案:它使用的是多专家模型 (MoE) 架构,该架构仅为每个 token 选择其参数的子集。

有两种主要的模型架构:密集模型和 MoE。模型如何组织参数与它有多少参数一样重要。与原始参数计数相比,正确的选择对吞吐量、内存成本和服务复杂性的影响更大。因此,在两者之间进行选择取决于部署限制。

想象一下总排量相同的两个引擎之间的区别。一个循环会在每个循环中启动每个圆柱体,另一个则仅激活所需的圆柱体。

本文将介绍:

  • 稠密和 MoE 架构的工作原理
  • 它们如何影响性能
  • 何时选择

密集模型与 MoE 模型

简而言之,密集模型和 MoE 模型在使用参数方面存在差异。稠密模型会为每个 token 激活其所有参数。MoE 模型可存储多个专家网络,但每个 token 仅通过选定的子集进行路由。

密集模型通常有利于更简单、更可预测的部署,而当内存和服务复杂性易于管理时,MoE 模型可以提供更高的容量和吞吐量。

观看视频:原文视频

视频 1. 密集与 MoE:如何选择合适的 AI 架构

参数的不同之处在于

在稠密模型中,每个参数都参与每次前向传递。通过每个解码器层的单个共享前馈网络 (FFN) 块,一个 27B 模型的所有 270B 参数可对应每个 token。

MoE 模型将单个共享 FFN 替换为多个 FFN 块 (也称为专家) 。通过内部路由过程,传入的 token 通过一小部分专家 (而非每个参数) 进行处理。从结构上讲,在每个解码器层 (其中稠密模型将具有一个 FFN) 内部,MoE 层具有多个 (例如。8、64 或 128) 。习得的门网络 (通常称为路由器网络) 位于所有门网络的前面,并将每个传入token分配给排名前 k 的评分专家。选定的 FFN 块是为该 token 运行的块,而为该特定层跳过的其余块。不过,大多数现代 MoE (例如 Mistral Small 4) 也会运行一个“共享”专家,每个 token 都会路由到该专家。

MoE 路由的工作原理

对于 MoE 模型,每个层的路由决策都是独立的,这意味着 token 不会路由给专家,而是会一直保留在那里进行其余的计算。在每个解码器层,它都会根据token在网络中该点所代表的内容重新路由。每一层的这些专家都不是传统意义上的专家,他们专注于某一主题,而是主要专注于语法和标记类型模式 (标点符号、数字等) ,尽管这因架构或训练方法而异。

虽然路由器机制决定在每个解码层跳过哪些 FFN 块,但token仍然像往常一样通过完全注意力机制。当模型卡显示“3B active parameters” ( 3B 活跃参数) 时,它会包括每个 token 的注意力和嵌入权重,以及选定的 FFN 权重。

MoE 变体

MoE 也有一些变体,其中之一是用于 Nemotron 3.5 Lightning 的 NVIDIA 模型卡,该卡指定了 Mamba-2+ MoE+ Attention 混合模式。在大多数层中,Mamba-2 层是注意力的集中点,具有恒定大小的循环状态,而不是不断增长的 KV 缓存。这改变了长上下文的内存配置文件,而稀疏性本身并不能解释这一点。

Lightning 不是使用完整模型的广度来做出这些路由决策,而是首先将它们压缩到更小的空间中,从而使路由决策对模型来说更便宜。下图 1 描述了通用 Transformer-MoE 案例。请注意,MoE 模型是一种稀疏模型。

Side by side decoder layer diagrams. Left (dense): single shared FFN that every token passes through. Right (MoE): multiple FFN blocks (experts) with a router selecting top-k per token per layer. The router governs the FFN selection only, attention weights are dense in both cases.

图 1. 具有不同路由机制 (来源:Medium) 的稠密模型和稀疏模型解码器块

密集模型还是 MoE 模型?

MoE 模型的 token 吞吐量通常更快,因为它们只为每个 token 激活了前馈参数的子集。密集模型可激活整个网络,但可以提供更简单的服务和更可预测的延迟。

在高并发情况下,路由和内存移动会缩小 MoE 的优势。结果还取决于硬件、精度、推理框架和模型设计。例如,Nemotron 3.5 Lightning 具有 Mamba-2 层和预测解码。

关键模型性能差异

两者之间的性能差异主要表现在两个方面。首先,在总参数计数相等的情况下,跳过的 FFN 块可加快 MoE 速度。两者之间更重要的区别在于,MoE 将内存 (总参数 = VRAM 到主机) 与计算 (活动参数 = 每个token的 FLOPS) 解。

在稠密模型中,托管和推理成本共同增加,MoE 打破了这种联系。有了 MoE,VRAM 就会预先得到回报。当每个专家加载到内存中时,计算按 token 支付,并且仅随着启动的专家进行扩展。空闲专家无需任何成本即可运行,同时仍需支付存储所需的内存费用,因此从按标记变量计算到固定内存的转变成为主要权衡。

在批量大小为 1 时,解码受可用内存而非计算的约束,这正是 MoE 的出色表现,因为它读取的每个token的权重字节数较少。随着批量大小的增加,token 最终会共同使用网络中的大多数专家,而这种优势会缩小,而每个 token 的工作量会继续减少。MoE 在批量大小方面具有吞吐量优势,但与经过良好优化的密集模型相比,其延迟幅度在高并发下进行压缩。

现代推理框架通常在不丢弃 token 的情况下处理路由,但所有专家必须同时位于 GPU 显存中。与同等规模的稠密模型通常拥有的空间相比,这给 KV 缓存留下的空间更小。

比较示例

下表 1 显示了直接比较。在相同的总参数大小下,稀疏性在吞吐量方面明显可见:Gemma 4 31B 和 Nemotron 3.5 Lightning 总计约 300 亿,但在 NVIDIA GPU 提供商之间,其输出速度范围并不重叠。每个 token 激活 30 亿个参数是一个主要原因,但这并不是唯一的原因。Lightning 的 Mamba-2 层及其预测性解码功能独立于混合 MoE 架构。

模型架构总参数活动参数显存 (原生)显存 ( 4 位)人工智能分析智能指数输出速度*$/ M 输出*
Gemma 4 31B密集;多模态31B31B61 GB BF16 ( 1 H100)~ 16 GB3036.9 至 2022.4 吨/ 秒0.40 美元
Qwen3.8-27B密集;混合线性/ 全注意力;MTP 头;多模态270 亿270 亿56 GB BF16 ( 1 H100)~ 14 GB5246.8 t/ s$ 3.00 美元
Nemotron 3.5 LightningMoE+ Mamba-2 注意力混合300 亿3B60 GB BF16 ( 1 H100)~ 20 GB24235.7 至 494.2 吨/ 秒0.22 美元
Mistral Small 4MoE;多模态119B6B (包括 80B) 。嵌入)121 GB FP8 ( 4 块 H100 以上)~ 71 GB20147.3 t/ s0.60 美元

表 1. 来自人工分析的中值输出速度和成本数据 ( 1 万个 token 输入,2026 年 8 月 31 日检索) ;基准测试仅涵盖 NVIDIA GPU 提供商

可以观察到两者的权衡;例如,Lightning 以 14 倍的价格提供 Qwen3.8-27B 4 到 5 倍的输出速度,而在一般能力方面得分不到一半。对于批量运行明确指定步骤的代理执行层来说,这是正确的,而对于一个硬推理通道决定结果的情况则是错误的。

何时应使用稠密模型或 MoE 模型?

在决定使用哪种模型时,取决于哪种模型最适合您的部署环境。

需要考虑以下几个因素:

  • 显存占用: 显存占用追踪的是总参数而非活动参数,因此一个 30B MoE 和一个 30B 密集模型大约需要 60 GB。真正的问题在于这些千兆字节会得到什么:dense 将它们转化为能力,MoE 转化为吞吐量。
  • 并发:MoE 在单个请求中明显获胜。它的吞吐量优势随着并发规模的增加而保持不变,但延迟差距会缩小。如果您对高并发延迟很敏感,请在做出决策之前对两者进行基准测试。
  • 微调计划:密集模型微调更简单;所有参数激活,梯度均匀流动。对 MoE 模型进行全面微调会使路由器失去平衡,使一些专家比其他专家更受欢迎,或者完全淘汰某些专家。LoRA/ PEFT 方法有助于避免这种情况,只需冻结路由器即可。NeMo 的 Lightning 监督式微调方法专门针对该模型进行了正确的处理
  • 量化: 压缩比不在架构差异所在的位置。在实践中,有两点更重要。首先,检查检查点已达到的精度:Mistral Small 4 原生为 FP8,因此 4-bit 会再购买+ 1.7% ( 121GB = 71GB) ,而不是 4%。其次,两种架构都有量化不佳的模组,而且它们并不相同。在 MoE 中,它是路由器,其中的小干扰会颠覆离散的路由决策。配方使路由器、嵌入和输出端更高,而在混合注意力模型中,则是反复预测来颠覆路由决策。例如,量化的 Qwen3.8-27B 版本正是出于这个原因,在 BF16 中保留了线性注意力块。

核心权衡

Dense 和 MoE 是一种权衡的两个答案:每个参数的能力与每个token的计算。Dense 可让一切变得简单,让一切变得活跃,这使得微调和服务变得更加容易。MoE 利用内存购买吞吐量,并在服务复杂性方面为此付出代价。

Nemotron 3.5 Lightning 完全开放,包含权重、数据和方法,因此您可以根据工作流程进行调整,并将其部署到任何地方。要开始使用,请在 NVIDIA 官网 或 OpenRouter 上试用。从 Hugging Face 和 ModelScope 中下载权重。

对于物理 AI工作负载,AgiBot GO-1和腾讯 Hy-Embodyed-VLM-1.0是生态系统中的热门选择。

原文来源: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

如何使用 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

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

NVIDIA Dynamo 的 EPD 解耦将视觉编码与 LLM 预填充、解码分开调度。文章分析图像负载、输出长度、模型规模、精度和混合流量如何决定 TTFT 与吞吐收益。

NVIDIA_Community的博客 145

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
上一篇: 如何使用 AI 智能体准备用于仿真的 3D 场景
下一篇: NVIDIA AI 培训班 | 10 月 29 日《为大语言模型添加新知识》开课,转化开源 LLM 为领域 AI 资产
NVIDIA AI 技术专区
NVIDIA AI 技术专区 NVIDIA 官方账号 NVIDIA 官方账号
博客等级 码龄2年 632粉丝 213原创
评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明:

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

余额充值