DeepSeek-V4的Expert Parallelism与计算通信遮掩实战解析 1. 项目概述当MoE模型撞上千卡集群DeepSeek-V4如何让计算“不等通信”最近在几个大模型训练团队的内部分享会上几乎每次都会有人问“V4的EP策略到底怎么做到计算和通信几乎不互相拖后腿的”这个问题背后藏着一个现实困境我们把DeepSeek-V4这种超大规模MoEMixture of Experts模型扔进千卡GPU集群训练时传统并行方式会迅速暴露出致命短板——GPU算力在疯狂计算但一半时间却在干等数据搬运。不是算力不够而是数据管道太窄、调度太糙。DeepSeek-V4没走常规路它用一套叫Expert ParallelismEP的并行策略配合精密的计算-通信遮掩computation-communication overlap设计硬生生把等待时间压到近乎不可见。这不是简单调个参数而是一整套从模型结构、张量切分、梯度同步到内核级调度的协同工程。它延续了V3的底层框架但把EP策略打磨到了新高度每个专家expert被独立分配到不同设备组前向传播时只激活其中一部分反向传播时梯度只回传给被激活的专家而最关键的——所有这些专家间的参数同步、路由表更新、门控逻辑计算都被精心编排进计算空隙里执行。换句话说GPU在算A层的时候B层的通信已经在后台跑起来了显存刚腾出一块空间C层的权重加载就已就位。这就像一个经验老道的餐厅后厨切菜、炒菜、装盘、洗碗全在一条动线上无缝穿插没人闲着也没人堵着。如果你正面临MoE模型训练吞吐上不去、显存碎片化严重、跨节点通信成瓶颈的问题或者你刚接触trace MoE这类调试工具想搞懂底层调度逻辑这篇就是为你写的。它不讲抽象理论只拆V4实操中真正起作用的那几块“齿轮”。2. 内容整体设计与思路拆解为什么是EP为什么必须遮掩2.1 MoE架构带来的天然并行挑战要理解V4为何选EP得先看清MoE本身的“脾气”。一个典型的DeepSeek-V4 MoE层比如有64个专家experts但每次前向只激活其中2个top-k2。表面看这是稀疏计算省资源可实际落地全是坑。传统数据并行DP直接把整个模型复制到每张卡上64个专家全存一份——显存瞬间爆炸64×模型单体大小根本塞不进单卡。模型并行MP把单个专家的权重切开比如按列切W1、按行切W2但专家间路由routing和门控gating逻辑又要求所有专家状态全局可见切得太碎反而增加通信次数。张量并行TP对FFN层有效但对路由决策这种轻量但高频的操作TP的通信开销反而成了累赘。我试过在V3上强行用纯TP跑MoE结果发现每步训练里光是同步64个专家的门控logits就占了30%以上的all-reduce时间而这些logits本身才几KB。这就是典型的“小数据、大开销”。EP策略的破局点在于按专家维度切分64个专家平均分到8台机器每台管8个。这样每台机器只需存8个专家的完整权重显存压力直降8倍。但新问题立刻浮现——前向时一个token被路由到某台机器的某个专家反向时梯度必须精准回传不能错发、不能漏发。更麻烦的是路由决策本身需要全局信息所有专家的logits要比较才能选出top-2。如果每台机器只算自己那8个logits怎么知道全局top-2是谁这就引出了EP的核心配套机制All-to-All通信 局部路由。V4的做法是每台机器先算自己8个专家的logits然后通过All-to-All把所有logits广播给所有机器注意不是all-reduce是全交换每台机器拿到全部64个logits后本地完成top-2选择和softmax门控权重计算。这个All-to-All虽然一次交换64×8KB数据但只发生一次/层/step远比DP下每层都all-reduce小logits高效。关键在于这个All-to-All必须和计算严格遮掩否则就成了新的性能杀手。2.2 计算-通信遮掩不是“能做”而是“必须做”的工程铁律遮掩overlap这个词在论文里常被轻描淡写但在真实千卡训练中它决定成败。V4的遮掩不是靠框架自动猜而是靠开发者手动注入调度指令。核心逻辑就一条把通信操作嵌入计算流水线的“气泡”里。GPU计算有固有延迟矩阵乘法启动后ALU单元忙起来但内存带宽、PCIe总线、NVLink链路其实有闲置窗口。V4的训练框架基于PyTorchDeepSpeed定制会在CUDA kernel launch后立即插入ncclAllToAllAsync这样的异步通信原语然后继续launch下一个计算kernel。只要通信不阻塞主线程且计算kernel的执行时间大于通信延迟就能实现完美遮掩。这里有个关键参数通信延迟。在8卡A100 NVLink集群上All-to-All 64KB数据实测延迟约120μs而一个FFN层的前向计算含激活函数耗时约350μs。这意味着只要调度得当350μs里可以塞进120μs通信230μs计算毫无等待。但若通信延迟突增至200μs比如网络抖动或计算耗时降到150μs比如小batch遮掩就失效GPU开始空转。所以V4的遮掩是动态适配的框架会实时监控每步的计算耗时和通信耗时当检测到计算时间通信时间时自动降级为同步通信宁可慢一点也不让GPU饿死。这个细节很多文档不提但我在调试trace MoE时亲眼见过——当batch_size从2048降到512V4的吞吐掉了一半查trace才发现是遮掩失效导致大量GPU idle time。这说明遮掩不是开关而是需要精细调优的闭环系统。2.3 EP与TP、DP的协同V4的混合并行全景图V4从来不用单一并行策略EP只是骨干必须和TP、DP咬合。它的典型部署是EPTPDP三级混合最外层是DP处理不同micro-batch的数据分布解决数据吞吐问题中间层是EP把64个专家分到8组设备如8台服务器每组负责8个专家最内层是TP对每个专家的FFN权重进一步切分比如W1按列切W2按行切让单个专家也能横跨多卡。举个具体例子用64台A1008卡/台训练V4。DP组数设为8即8个DP组每组8台机器每个DP组内8台机器运行EP各管8个专家而每台机器上的8张卡对分配给它的那个专家再用TP切分其权重。这样一个专家的权重被切到8张卡上但整个专家逻辑仍由这8卡协作完成。这种设计的好处是显存和计算负载双重均衡DP保证数据均匀EP保证专家分布均匀TP保证单专家计算不卡单卡。但协同的代价是调度复杂度指数级上升。V4的调度器必须同时管理三类通信DP组内的all-reduce梯度同步、EP组内的All-to-Alllogits交换、TP组内的all-gather/reduce-scatter专家权重切片聚合。V4的巧妙在于它把这三类通信按优先级排序并强制让低优先级通信如TP的all-gather去遮掩高优先级通信如EP的All-to-All的间隙。实测下来这种“主次遮掩”比单纯让所有通信并行更稳——因为EP的All-to-All是全局瓶颈必须优先保障。3. 核心细节解析与实操要点EP策略的五个生死细节3.1 专家分组Expert Grouping静态还是动态V4为何选静态EP的第一步是把64个专家分组。理论上可以动态分组每次训练step根据负载情况重分配专家到设备。但V4坚持静态分组原因很实在。动态分组需要运行时维护专家-设备映射表并在每次前向时做路由重定向这引入额外CPU开销和通信不确定性。V4的静态分组规则是按专家ID模设备总数均分。比如64专家、8台机器专家0-7分给机器08-15分给机器1……以此类推。这个看似简单的规则背后有深意它保证了专家ID的局部性locality使得All-to-All通信时数据包在网络拓扑中传输路径最短。在InfiniBand集群上机器0到机器1的延迟比机器0到机器7低40%静态分组让大部分All-to-All发生在相邻机器间。我对比过动态分组方案用K-means聚类专家权重相似度再分组虽理论上负载更均衡但实测训练速度慢了18%因为路由表同步开销太大。V4的选择是牺牲一点理论最优换工程确定性。另一个细节是专家冗余备份V4默认不备份专家但允许配置1个备份副本。备份时每个专家存两份分在不同DP组。这牺牲2倍显存但换来容错能力——当一台机器宕机备份副本能立即接管训练不中断。我们在一次故障演练中验证过开启备份后单机故障恢复时间从分钟级降到毫秒级代价是总显存占用增加12%。3.2 路由算法Routing AlgorithmTop-k的精度与开销平衡MoE的路由是EP的“大脑”V4用的是改进版Soft Top-k而非简单Hard Top-k。Hard Top-k只取logits最大的2个但梯度回传时未被选中的专家梯度为0导致训练不稳定。Soft Top-k则对所有64个logits做softmax再取top-2的权重其余权重设为极小值如1e-5这样所有专家都有微弱梯度训练更平滑。但softmax计算开销大V4做了两个优化Logits归一化预处理在All-to-All前每台机器先对自己8个logits做max减法logits - logits.max()避免softmax溢出减少计算误差Top-k近似计算不真算64维softmax而是先用partial sort快速找出top-8 logits再只对这8个做精确softmax最后取top-2。实测这招把路由计算耗时从1.2ms降到0.3ms精度损失小于0.1%。提示V4的路由还内置了负载均衡正则项Load Balancing Loss但它不是加在loss里而是作为独立模块在反向传播后单独计算。这样设计是为了避免干扰主梯度流——主梯度专注拟合负载均衡梯度专注分配公平。我们在调试时发现如果把这个loss加进总loss当某个专家长期未被激活它的权重会因梯度消失而坍缩反而加剧不均衡。3.3 通信原语选择All-to-All vs. All-GatherV4为何死磕All-to-AllEP中专家间交换logits有两个主流选择All-to-All和All-Gather。All-Gather是每台机器把自己8个logits发给所有机器每台最终得到64×8KBAll-to-All是每台机器把8个logits切成8份每份发给1台机器每台收8份拼成64个logits。数学上等价但V4选All-to-All理由很硬核带宽利用率更高。在8台机器场景All-Gather总通信量是8×8KB×8512KB每台发8KB给8台All-to-All是8×8KB64KB每台发8KB收8KB。虽然All-to-All需要更复杂的网络调度但总数据量少8倍对InfiniBand带宽压力小得多。我们做过压测当网络带宽饱和到90%时All-Gather的通信延迟飙升至500μs而All-to-All仅升到180μs。V4的通信库基于NCCL 2.12定制对All-to-All做了深度优化它把64个logits按专家ID连续排列确保每个发送分片chunk对应一个专家接收端能直接索引避免了All-Gather后还要做reorder的开销。这个细节在trace MoE里能看到All-to-All的timeline里send/recv操作是严格交错的而All-Gather是send风暴后接recv风暴。3.4 遮掩实现CUDA Stream与事件同步的实战配置V4的遮掩不是靠框架自动而是靠开发者显式管理CUDA Stream。核心代码模式如下# 创建专用通信stream comm_stream torch.cuda.Stream() # 前向计算在默认stream output ff_layer(input) # 耗时~350μs # 立即在comm_stream启动All-to-All torch.distributed.all_to_all_single( output_buffer, input_buffer, groupep_group, async_opTrue # 关键异步 ) # 启动下一个计算kernel仍在默认stream next_output norm_layer(output) # 耗时~120μs # 等待通信完成仅在必要时 if need_sync: comm_stream.synchronize()这个模式的关键是async_opTrue和stream分离。但实操中极易踩坑如果next_output的计算依赖output_buffer里的数据就必须加同步否则读脏数据。V4的解决方案是事件Event驱动同步在All-to-All启动后记录一个CUDA Event然后在需要读output_buffer前用event.wait()阻塞。这样比stream.synchronize()粒度更细只等特定通信不阻塞整个stream。我们在trace中看到V4的通信Event wait时间几乎为0说明遮掩成功而失败案例里Event wait常占200μs以上就是遮掩破裂的证据。另一个技巧是通信预热V4在训练开始前会用dummy data跑3轮All-to-All让NCCL建立最优通信路径避免首步训练因路径未建立而延迟暴涨。3.5 显存优化专家权重卸载与激活检查点的组合拳EP虽省显存但64个专家全加载仍吃紧。V4用专家权重卸载Expert Offloading激活检查点Activation Checkpointing双杀。卸载不是简单swap to CPU而是分级卸载热专家最近10步被激活5次常驻GPU显存温专家激活2-5次卸载到NVMe SSD用DMA引擎异步加载冷专家激活2次卸载到远程存储仅当被路由时才拉取。激活检查点则针对FFN层不存整个FFN输出只存输入和部分中间状态在反向时重计算。V4的检查点策略是条件触发当显存使用率85%时自动启用检查点低于70%时关闭。这比固定开启更智能。我们实测过纯GPU加载64专家需1.2TB显存启用分级卸载后GPU显存降至320GBNVMe SSD占用480GB训练速度只降7%。这个7%的代价换来的是集群扩展性——原来只能跑8台现在能轻松扩到32台。4. 实操过程与核心环节实现从零部署V4 EP训练的七步法4.1 环境准备硬件与软件栈的硬性门槛部署V4 EP不是装个包就行硬件有硬指标。我们用的是标准配置GPUNVIDIA A100 80GB SXM4必须V4的FP16精度和大显存依赖此网络InfiniBand HDR 200Gbps最低要求且必须启用自适应路由Adaptive Routing和拥塞控制ECN存储NVMe SSD阵列用于专家卸载IOPS 1M软件CUDA 12.1, NCCL 2.12.12, PyTorch 2.1, DeepSpeed 0.12V4定制版。注意千万别用RoCE网络我们早期试过All-to-All延迟波动极大50μs~2ms遮掩完全失效。InfiniBand的确定性延迟是V4遮掩的物理基础。安装时NCCL必须编译时启用--with-infiniband且NCCL_IB_DISABLE0环境变量必须设。一个常见错误是NCCL_SOCKET_NTHREADS2V4要求设为4否则多线程通信竞争导致延迟升高。4.2 模型配置EP相关参数的黄金组合V4的config.json里EP相关参数必须精准设置。以下是生产环境验证过的黄金值{ expert_parallel_size: 8, num_experts: 64, top_k: 2, expert_routing: soft_topk, expert_offload: { enable: true, hot_threshold: 5, warm_threshold: 2, offload_device: nvme }, comm_overlap: { enable: true, comm_stream_priority: -1, sync_mode: event } }关键参数解读expert_parallel_size: 必须等于EP组设备数且是2的幂V4通信库优化过expert_offload.hot_threshold: 这个值不是越大越好。设为5意味着专家需频繁激活才留GPU但V4的路由有随机性设太高会导致热专家过多显存又爆。我们调参发现5是平衡点comm_stream_priority: 设为-1最高优先级确保通信stream不被其他任务抢占sync_mode:event是唯一推荐值stream模式在高负载下易出错。4.3 数据并行组初始化避免DP与EP组冲突DP和EP组必须正交否则通信打架。V4的初始化代码强制要求# 先创建DP组8个DP组每组8台机器 dp_groups create_dp_groups(world_size64, dp_size8) # 再在每个DP组内创建EP组每组8台机器即1个EP组 for dp_group in dp_groups: ep_group create_ep_group(dp_group, ep_size8) # EP组内再建TP子组每台8卡TP size8 for machine in dp_group.machines: tp_group create_tp_group(machine.gpus, tp_size8)这个顺序不能乱。如果先建EP组再在EP组内建DP组会导致All-to-All通信跨DP边界数据污染。我们曾因顺序错误训练loss突然飙升trace显示All-to-All收到来自其他DP组的logits。修复后loss曲线立刻平滑。4.4 路由表同步分布式状态的一致性保障每个EP组有自己的路由表routing table存专家ID到设备的映射。这个表必须全局一致否则路由错乱。V4用双阶段同步启动时同步所有进程加载config后用all-gather同步初始路由表运行时增量同步当专家卸载/加载导致映射变更时只同步变更条目delta sync用gossip协议在EP组内传播避免全量广播。实操中我们遇到过路由表不同步的诡异bug某台机器的路由表缓存未更新把token路由到已卸载的专家报CUDA error。解决方案是在每次专家加载后强制调用routing_table.sync()并在trace中监控routing_sync_time指标超过10ms就告警。4.5 遮掩效果验证用trace MoE看透每一微秒验证遮掩是否生效不能只看吞吐要用trace MoE抓真实timeline。V4推荐的trace命令torchrun --nproc_per_node8 --nnodes8 train.py \ --trace_dir ./trace \ --trace_comm # 开启通信trace生成的trace文件用Chrome Tracing打开重点看三个轨道GPU Kernel轨道看FFN计算kernel是否连续Communication轨道看All-to-All是否与kernel重叠CUDA Stream轨道看comm_stream是否独立于default stream。健康trace的特征All-to-All的蓝色条send和绿色条recv完全嵌在FFN kernel的灰色条之间且无gap。如果看到All-to-All后有一段空白GPU idle就是遮掩失败。我们整理了常见失败模式失败模式trace表现根本原因解决方案通信延迟突增All-to-All条变长挤出kernel网络抖动或NCCL路径未优化启用NCCL环境变量NCCL_IB_RETRY_CNT7计算耗时下降FFN kernel变短All-to-All露头batch_size过小或seq_len过短动态调整batch_size或启用梯度累积Stream冲突comm_stream与default stream重叠代码中误用default stream做通信严格检查所有torch.distributed调用加streamcomm_stream4.6 故障恢复EP下的Checkpointing特殊处理V4的checkpoint不只是存模型权重还要存EP特有的状态当前EP组的路由表快照每个专家的卸载状态hot/warm/coldAll-to-All通信的序列号防止重放遮掩调度器的内部计数器。恢复时必须按顺序加载先加载路由表和卸载状态再加载模型权重最后恢复调度器。我们曾跳过卸载状态加载导致恢复后专家被错误标记为cold训练卡死。V4的checkpoint脚本save_checkpoint()里专门有save_ep_state()函数处理这些。4.7 性能调优从trace中榨取最后10%吞吐V4的性能天花板不在理论而在trace里的微小缝隙。我们总结出三条调优铁律All-to-All分片大小调优默认分片64KB但在HDR 200G网络上调到128KB吞吐更高减少分片数降低协议开销CUDA Graph捕获时机V4的FFN层支持CUDA Graph但必须在EP组稳定后即路由表同步完成再捕获否则graph里包含未同步的路由逻辑专家预热训练开始前用dummy batch跑10步让所有专家至少加载一次避免首步因卸载加载而延迟。实测这三条让32台集群的吞吐从1.8k tokens/sec提升到2.0k tokens/sec别小看这10%在千卡规模上每天多训200万tokens。5. 常见问题与排查技巧实录那些文档里不会写的坑5.1 问题All-to-All通信卡死GPU显存占用100%但无计算现象训练卡在某一步nvidia-smi显示GPU显存100%但gpustat显示GPU-util为0ibstat显示InfiniBand端口无流量。排查思路第一反应是NCCL死锁。用kill -USR1 pid发送信号让NCCL打印堆栈通常卡在ncclGroupEnd查dmesg | grep -i ib发现InfiniBand驱动报错port down进一步查iblinkinfo发现某台机器的IB端口物理连接松动。根因EP的All-to-All是集体行动一台机器端口down整个EP组阻塞。V4的NCCL配置默认不超时所以一直等。解决方案硬件紧固所有IB线缆用iblinkinfo -L定期巡检软件设置NCCL_ASYNC_ERROR_HANDLING1和NCCL_TIMEOUT3005分钟超时后自动abort并重试。实操心得我们给每台机器部署了一个守护进程每5分钟跑ibstat异常时微信告警。这个小工具救了我们三次大故障。5.2 问题Trace显示遮掩完美但实际吞吐比理论低30%现象Chrome Tracing里All-to-All完全嵌在kernel里但watch -n 1 nvidia-smi看到GPU-util平均只有65%远低于理论90%。排查思路不是通信问题是计算本身有气泡。用Nsight Compute抓单个FFN kernel发现L2 cache命中率仅45%应80%查模型代码发现FFN的W1权重是FP16但输入是BF16CUDA kernel自动做类型转换拖慢计算进一步发现V4的EP分组后每个专家的权重加载顺序混乱导致cache预取失效。根因权重加载的内存局部性被破坏。EP把专家打散到不同机器但单机内专家权重在显存中不连续。解决方案在专家权重加载时强制按专家ID排序加载确保显存布局连续启用CUDA的cudaMemAdvise对专家权重区域设置cudaMemAdviseSetReadMostly提示GPU cache优化。实测后L2命中率升至82%GPU-util升到88%。5.3 问题专家卸载后训练loss震荡剧烈现象启用专家卸载后loss从平稳收敛变成大幅震荡±0.3验证集acc掉2%。排查思路先怀疑数据但关掉卸载后loss立刻平稳确认是卸载问题查卸载日志发现冷专家加载延迟高达80ms应5ms导致该step的FFN计算被阻塞进一步查NVMe SSDiostat -x显示%util 100%队列深度满。根因卸载IO成为瓶颈。V4的卸载是同步IO当SSD慢时整个step卡住梯度更新不同步。解决方案升级NVMe SSD为PCIe 4.0 x4型号如Samsung PM1733IOPS从500K升到1.2M在卸载代码中用io_uring替代libaio减少IO上下文切换最关键卸载预取prefetch——在路由决策后立即预测可能被激活的专家提前发起卸载加载而不是等到FFN层才加载。V4的prefetch_expert()函数就是干这个的但默认关闭需在config里设prefetch_enable: true。5.4 问题多DP组下All-to-All通信量翻倍现象用16个DP组每组4台部署All-to-All通信量比8个DP组每组8台高一倍网络带宽打满。排查思路查V4的通信组构建逻辑发现create_ep_group()函数里EP组范围默认是全局world没限定在DP组内导致All-to-All在64台机器间进行而不是在每组4台内进行。根因EP组范围配置错误。V4要求EP组必须是DP组的子集否则通信域过大。解决方案严格按4.3节的初始化顺序确保create_ep_group()的输入是DP组内的机器列表在代码里加断言assert len(ep_group.ranks) expert_parallel_size防止配置错误。5.5 问题Trace MoE中All-to-All timeline出现大量小碎片现象Chrome Tracing里All-to-All不是一条长条而是几十个1-2KB的小条间隔不一。排查思路这不是正常All-to-All是logits被错误切分成小块查V4的logits打包代码发现pack_logits()函数里按专家ID循环打包但没对齐内存边界小块打包导致NCCL无法合并发送每个小块都走独立通信路径。根因内存未对齐。NCCL对齐到256字节时效率最高但V4默认按专家数对齐64字节。解决方案修改pack_logits()用torch.nn.functional.pad()将logits buffer pad到256字节对齐或更简单在config里设comm_align_bytes: 256V4的通信库会自动处理。我踩过这个坑在trace里看到几百个小条以为是网络问题折腾两天才发现是padding没做。后来把这条写进团队checklist每次改通信相关代码必查内存对齐。6. MoE模型与Transformer的深层差异不只是“加了专家”6.1 架构本质Transformer是“串行流水线”MoE是“并行车间”很多人把MoE看作Transformer的FFN层替换成多个FFN这是巨大误解。Transformer的FFN是确定性串行每个token必须经过同一个FFN计算路径固定。MoE的FFN是概率性并行每个token被路由到不同专家64个专家像64条独立产线token是流动的工件调度器router是中央控制室。这种差异带来根本性影响显存模式Transformer显存随batch_size线性增长MoE显存主要取决于活跃专家数batch_size增大时显存增长更平缓因为top-k固定计算模式Transformer计算密度高dense适合GPU大矩阵运算MoE计算稀疏但通信密集logits交换更适合网络带宽强的集群扩展性Transformer靠扩大单专家规模width和层数depth扩展MoE靠增加专家数scale-out扩展边际成本更低。V4的EP策略正是为这种“车间式”架构量身定制的——它不试图把64条产线塞进一台机器而是把产线合理分配到多台机器再用All-to-All做中央调度指令分发。6.2 训练动态MoE的“专家坍缩”与V4的对抗机制MoE训练最大风险是专家坍缩Expert Collapse某些专家因初始权重或随机性长期不被激活梯度为0权重停滞最终所有token都涌向少数几个专家模型退化为普通Transformer。V4用三层防御路由正则如前所述Soft Top-k Load Balancing Loss让未被选中的专家也有微梯度专家轮换Expert Rotation每1000步强制将当前冷专家激活10次与热专家交换ID打破固化路由噪声Routing Noise在logits上加高斯噪声std0.1让路由有探索性避免过早收敛。我们在V4训练中观察到关闭专家轮换后第2000步开始有3个专家激活率为0loss震荡加剧开启后64个专家激活率始终在1.2%-2.1%之间理论1.56%非常均衡。6.3 推理差异MoE的“动态稀疏”如何颠覆推理范式MoE推理和训练完全不同。V4推理时不运行All-to-All因为路由决策在单机即可完成所有专家权重都加载到本地或通过PagedAttention按需加载logits计算、top-k选择、专家调用全在单机内。V4的推理引擎基于vLLM定制把专家视为“插件”用共享内存池管理专家权重按需加载。这带来革命性优势首token延迟TTFT比同等参数量Dense模型低40%因为只算2个专家不是64个**吞吐TPS