人工智能大模型模型推理服务后端【免费下载链接】MooncakeMooncake is the serving platform for Kimi, a leading LLM service provided by Moonshot AI.项目地址https://gitcode.com/gh_mirrors/mo/Mooncake点击查看免费下载导读本文讲解 Mooncake 专家并行Expert Parallel, EP模块内置的 dispatch/combine 基准测试工具ep_benchmark它用于量化 Mooncake EP Buffer 在均匀路由uniform、k-hot 扇入incast和 Zipfian 路由三种流量模式下的吞吐量与尾部延迟。读完本文你将掌握该基准脚本的全部命令行参数、三种运行方式单机 spawn / 多机 torchrun / 配置文件、输出 JSON 的指标语义并能结合底层Buffer.dispatch/Buffer.combine源码理解每个参数对通信行为与性能结果的实际影响。基准脚本与说明文档位于 mooncake-ep/benchmarks/ep_benchmark。一、基准测试定位衡量什么为什么重要在 MoEMixture-of-Experts推理/训练中dispatch把每个 token 按topk_idx发送到对应专家所在的 rank与combine把各专家输出按topk_weights加权聚合回原 rank是 EP 通信的性能关键路径。Mooncake EP 为这一过程提供了专用的通信 BufferC 运行时封装为mooncake.epPython 层接口为 python/mooncake/mooncake_ep_buffer.py 中的Buffer类。ep_benchmark的设计目标是度量 dispatch/combine 吞吐以每秒处理的 token 数tokens_per_second为聚合吞吐指标度量尾部延迟输出 p50 / p90 / p99 / p999 及均值四个分位数覆盖两类通信各自的延迟与端到端周期延迟覆盖真实负载的偏斜特征真实 MoE 路由往往高度偏斜少量热门专家承接大部分 token因此除均匀路由外专门实现了 k-hot 扇入与 Zipfian 两种偏斜模型。二、快速开始三种运行方式2.1 单机多卡内部使用mp.spawnpython mooncake-ep/benchmarks/ep_benchmark/run_ep_benchmark.py \ --num-ranks 8 --num-experts 256 --hidden-size 7168 \ --top-k 8 --num-tokens 1024 --dtype bf16 \ --routing-mode k_hot --hot-experts 32 --hot-fraction 0.9 \ --zero-copy --async-finish \ --warmup-iters 20 --iters 100 \ --pg-backend nccl \ --json-output results/khot_8rank.json该模式不依赖外部启动器main()会检查环境中是否存在RANK环境变量若不存在则调用torch.multiprocessing.spawn启动args.num_ranks个 worker 进程见 run_ep_benchmark.py。2.2 多机多卡通过torchrun启动torchrun --nnodes2 --nproc_per_node4 --rdzv_backendc10d \ --rdzv_endpoint$HEAD_NODE \ mooncake-ep/benchmarks/ep_benchmark/run_ep_benchmark.py \ --num-experts 256 --hidden-size 7168 \ --top-k 8 --num-tokens 1024 --dtype bf16 \ --routing-mode k_hot --hot-experts 32 --hot-fraction 0.9 \ --zero-copy --async-finish \ --pg-backend nccl \ --json-output results/khot_8node.jsontorchrun模式下--num-ranks会被忽略脚本读取WORLD_SIZE环境变量作为世界大小并分别使用RANK/LOCAL_RANK环境变量初始化进程见main()中的RANK分支run_ep_benchmark.py。世界大小必须与--num-experts整除关系一致见下节校验规则。2.3 使用配置文件CLI 参数优先覆盖配置值仓库自带了三个与三种路由模式一一对应的现成配置python mooncake-ep/benchmarks/ep_benchmark/run_ep_benchmark.py \ --config mooncake-ep/benchmarks/ep_benchmark/configs/cuda_zipfian.json \ --num-ranks 8配置文件机制在解析阶段实现脚本先用一个精简的预解析器提前读取--config指向的 JSON再通过parser.set_defaults(**config_defaults)将其中字段设为默认值随后正常的命令行解析会覆盖它们run_ep_benchmark.py。三个示例配置分别为cuda_uniform.jsonrouting_mode uniform其余参数与默认值一致cuda_incast_k_hot.jsonrouting_mode k_hot、hot_experts 32、hot_fraction 0.9cuda_zipfian.jsonrouting_mode zipf、zipf_alpha 1.0。三者均默认backendcuda、zero_copytrue、async_finishtrue、pg_backendnccl、warmup_iters20、iters100即开箱即用。三、参数全表与校验规则3.1 参数总览Flag默认值说明--configNoneJSON 配置文件路径CLI 参数覆盖配置值--backendcuda输出 JSON 中标注的设备后端标签不改变实际执行--num-ranks8EP rank / GPU 数量torchrun模式下被忽略--num-experts256全集群专家总数--hidden-size7168隐层维度对应 Kimi 类大模型典型宽度--top-k8每个 token 路由到的专家数--num-tokens1024每个 rank 的 token 数--dtypebf16dispatch 数据类型可选bf16或fp8--routing-modeuniform路由模式uniform、k_hot、zipf--hot-experts32k_hot 模式下热门专家数量--hot-fraction0.9k_hot 模式下路由到热门专家的 token 占比--zipf-alpha1.0Zipf 分布参数 alphazipf 模式--zero-copyoff通过get_next_combine_buffer实现零拷贝 combine--async-finishoff基于 CUDA 事件的异步同步event-based--return-recv-hookoff基于回调 hook 的同步与--async-finish互斥--pg-backendnccl进程组后端nccl或mooncake后者要求 RDMA 环境--warmup-iters20预热迭代次数不计时--iters100计时迭代次数--seed0随机种子基值每个 rank 使用seed rank--json-outputstdoutJSON 结果输出路径默认 rank 0 打印到 stdout--master-addr127.0.0.1进程组 master 地址仅单机 spawn 模式使用--master-port29500进程组 master 端口3.2 参数校验与约束源码级确认脚本在validate_args()中强制以下规则run_ep_benchmark.pynum_experts必须能被num_ranks整除否则抛ValueError——因为每个 rank 负责的本地专家数为num_experts // num_ranks对应Buffer的assert num_experts % self.group_size 0检查mooncake_ep_buffer.py--async-finish与--return-recv-hook互斥同时开启会抛错fp8 模式下hidden-size必须能被 128 整除——FP8 量化以 128 元素为 block 计算缩放因子_fp8_cast中x.view(m, -1, 128)的分组方式mooncake_ep_buffer.py 以及 routing.py 无直接关联此约束主要源于 FP8 内核的 block 粒度。此外Buffer.dispatch还对输入张量做形状断言x必须为 2 维 BF16 连续张量、hidden同时满足% 16 0与% 128 0、num_tokens num_max_dispatch_tokens_per_rankmooncake_ep_buffer.py基准脚本以--num-tokens作为容量上限传入因此--num-tokens也是 EP buffer 工作区容量参数。3.3 环境变量与后端选择--pg-backend nccl标准 PyTorch NCCL 进程组dist.init_process_group(backendnccl)适用于无 RDMA 的调试环境--pg-backend mooncake要求导入mooncake.pg扩展脚本会显式检查并抛RuntimeErrorrun_ep_benchmark.py并依赖 RDMA 传输IBGDA以获得 fast-path 性能其初始化方式与 EP 快速开始示例一致参见 docs/source/api-reference/python/ep-backend.md 的 quick start 部分。四、三种路由模式的实现原理路由张量由 routing.py 中的生成器生成ROUTING_MODES字典将模式名映射到对应函数。所有模式都返回(topk_idx, topk_weights)topk_idx形状[num_tokens, top_k]int64topk_weights为 softmax 归一化权重float32。4.1 uniform均匀路由uniform_routing为每个 token 从全部num_experts中按标准正态分数torch.randn(num_tokens, num_experts)取top_k个最大值的索引即每个 token 的专家选择近似均匀分布。它是负载均衡的理想基线用于衡量通信层在无偏斜压力下的峰值能力。4.2 k_hot扇入incast偏斜路由k_hot_routing模拟真实 MoE 中的热点专家场景hot_fraction默认 0.9比例的 token 的全部 top-k 都从前hot_experts个专家中选取在hot_experts维度上取 top-k其余 token 均匀路由。随后用torch.randperm打乱 token 顺序避免热点 token 聚簇影响计时。该模式的三个合法性约束源码中显式抛ValueError值得注意routing.pyhot_experts num_experts非法hot_experts top_k非法无法从比 top-k 还小的集合中选出 top-k 个不同专家hot_fraction必须在(0, 1)开区间内。--hot-experts 32配合--num-experts 256意味着 12.5% 的专家承担约 90% 的流量会产生极端的不均衡专家负载见第六节imbalance_ratio这正是 incast 拥塞与尾延迟压力的来源。4.3 zipfZipfian 路由zipfian_routing使专家选择概率服从 Zipf 分布P(expert_i) ∝ 1 / (i1)^alphazipf_alpha默认 1.0alpha 越大分布越陡峭且必须 0。实现上采用Gumbel-max trick进行无放回 top-k 采样先对 log 概率加上 Gumbel(0,1) 噪声-log(-log(U))U 下限裁剪到1e-20防止 NaN再取 noisy scores 的 top-krouting.py。相比 k_hot 的硬扇入Zipfian 提供的是无硬边界的平滑偏斜梯度适合扫不同 alpha 观察偏斜程度对尾延迟的影响曲线。五、基准流程拆解worker 生命周期基准的核心类是EPBenchmarkWorkerrun_ep_benchmark.py每个 rank 一个实例按warmup → run_measured → aggregate_and_output三段执行5.1 初始化设置 CUDA 设备、初始化进程组通过Buffer.get_ep_buffer_size_hint(num_tokens, hidden_size, num_ranks, num_experts)计算 EP 工作区字节数并构造Buffer对应 C 侧BufferPair布局计算每个 rank 需要num_experts个 int 的信号区与num_experts × num_max_dispatch_tokens_per_rank × (2·sizeof(int4) hidden·EP_BF16_SIZE)的数据区见 mooncake-ep/include/mooncake_ep_buffer.h生成路由张量topk_idx/topk_weights种子为seed rank保证各 rank 路由分布独立但可复现准备随机输入xBF16、全 1 的active_ranks与零初始化输出out_tensor。5.2 预热与计时warmup()跑--warmup-iters轮完整 dispatch → mock 专家前向 → combine不计时最后torch.cuda.synchronize()用于建立连接、分配缓冲、触发 CUDA 内核编译run_measured()跑--iters轮每轮用torch.cuda.Event(enable_timingTrue)记录四个时间点——dispatch 起止、combine 起止由此得到dispatch_latencydispatch 内核耗时combine_latencycombine 内核耗时end_to_end_latency完整 dispatch → mock 专家前向 → combine 周期dispatch_starts[i].elapsed_time(combine_ends[i])。5.3 mock 专家前向与 fp8 反量化mock_expert_forward()模拟专家计算对recv_x的每个本地专家槽位执行recv_bf16[le] * (expert_id * 0.1 1.0)的线性缩放保持数据形状不变且成本极低。fp8 模式下dispatch 返回(fp8_data, scales)元组需先按 128 元素块反量化为 BF16dequantize_fp8模式与test_ep_grid.py一致见 run_ep_benchmark.py。5.4 零拷贝与两种异步同步方式combine 前通过prepare_combine选择数据路径run_ep_benchmark.py默认路径expert_out.contiguous()后直接传入combine--zero-copy调用buf.get_next_combine_buffer(handle)获取 combine 目标缓冲并copy_写入避免一次额外的张量复制Python 包装层中该方法在非 fast-path 环境会抛NotImplementedError说明零拷贝 combine 依赖 C fast-path 运行时mooncake_ep_buffer.py。同步方式二选一--async-finishdispatch/combine返回EventOverlap事件worker 调用event.current_stream_wait()让当前流等待通信事件完成事件式异步可与计算流重叠--return-recv-hook返回一个回调hook()worker 立即调用以等待接收完成hook 式同步。两者互斥的校验已在 3.2 节说明。六、输出指标详解与 JSON 结构结果先在aggregate_and_output中聚合各 rank 的延迟张量通过dist.all_gather汇集到 rank 0随后取逐迭代的跨 rank 最大值作为关键路径延迟torch.stack(all_dispatch).max(dim0)run_ep_benchmark.py——因为一次 EP step 的完成时间取决于最慢的 rank这保证了指标反映真实的全局关键路径而非单卡乐观值。compute_global_expert_load通过torch.bincount统计本地专家分配次数再all_reduce(SUM)得到全局计数输出max/min/mean_tokens_per_expert与imbalance_ratio max/meanmetrics.py——该比值是衡量路由偏斜导致的负载不均程度的直接读数k_hot 模式90% 流量打入 32 个专家会产生远高于 uniform 模式的 imbalance_ratio配合 p99/p999 可以观察负载不均与尾部延迟的相关性。tokens_per_second (num_tokens × world_size) / (mean_e2e_ms / 1000)metrics.py注意分母是端到端周期均值而非 dispatchcombine 之和。标准输出 JSON 结构如下来自 README.md 的 schemaassemble_json_output在 metrics.py 中实现{ benchmark: mooncake_ep, world_size: 8, num_experts: 256, hidden_size: 7168, routing_mode: k_hot, metrics: { dispatch_latency_ms: {p50: 0, p90: 0, p99: 0, p999: 0, mean: 0}, combine_latency_ms: {p50: 0, p90: 0, p99: 0, p999: 0, mean: 0}, end_to_end_latency_ms: {p50: 0, p90: 0, p99: 0, p999: 0, mean: 0}, tokens_per_second: 0, expert_load: { max_tokens_per_expert: 0, min_tokens_per_expert: 0, mean_tokens_per_expert: 0, imbalance_ratio: 0 }, per_rank_stats: { dispatch_latency_ms: { rank0: {p50: 0, p90: 0, p99: 0, p999: 0, mean: 0}, rank1: {p50: 0, p90: 0, p99: 0, p999: 0, mean: 0} }, combine_latency_ms: { rank0: {p50: 0, p90: 0, p99: 0, p999: 0, mean: 0}, rank1: {p50: 0, p90: 0, p99: 0, p999: 0, mean: 0} }, e2e_latency_ms: { rank0: {p50: 0, p90: 0, p99: 0, p999: 0, mean: 0}, rank1: {p50: 0, p90: 0, p99: 0, p999: 0, mean: 0} } } } }实际运行时还会在顶层补充backend、top_k、num_tokens、dtype、zero_copy、async_finish、return_recv_hook、warmup_iters、iters、pg_backend字段并在 k_hot 模式下追加hot_experts/hot_fraction、zipf 模式下追加zipf_alphametrics.py便于结果归档与复现。使用--json-output时结果写入指定文件否则 rank 0 将 JSON 打印到 stdout。七、底层原理速览dispatch/combine 的 C 实现了解底层实现有助于正确解读基准数据。C 运行时mooncake.ep扩展在 mooncake-ep/include/mooncake_ep_api.cuh 中暴露三个核心内核入口dispatch(...)接收x、topk_idx、active_ranks写出packed_recv_x打包的接收数据、packed_recv_x_scalesfp8 缩放、packed_recv_src_info来源 rank 信息、packed_recv_layout_range布局范围与packed_recv_count各专家槽位接收计数并支持timeout_ticks超时检测与phases分阶段同步mark_phase_ack/wait_phase_ack/mark_and_wait_phase_ack阶段确认原语用于跨 rank 的同步屏障无 CUDA 协作网格能力的平台会走 split SEND/RECV 路径Python 层对此会发出 RuntimeWarningmooncake_ep_buffer.pycombine(...)接收各专家输出与topk_idx/topk_weights/src_info/layout_range加权聚合回combined_x支持zero_copy标志。MooncakeEpBuffer类mooncake-ep/include/mooncake_ep_buffer.h内部管理两条传输路径节点内 NVLink P2PP2pTransport通过 IPC handle 与对端共享与跨节点 IBGDA RDMARdmaTransportnullptr表示不可用。use_fast_path()的判定逻辑是IBGDA 可用或所有对端均可 P2P 访问否则回退到 Python 实现的降级路径性能下降。因此基准结果在不同网络拓扑NVLink-only、RoCE、IBGDA下会有显著差异--pg-backend nccl与mooncake的对比正是用于量化 fast-path 收益。Python 层Buffer.dispatch/Buffer.combine的完整签名、参数语义num_max_dispatch_tokens_per_rank容量、timeout_us-1禁用超时、use_fp8返回(data, scales)元组等可进一步参考 docs/source/api-reference/python/ep-backend.md 中的 API reference 与 quick start 示例。八、实操建议如何做一轮有效的对比实验综合以上机制推荐的最小对比实验矩阵如下均可直接用现有配置或 CLI 组合完成基线--routing-mode uniformcuda_uniform.json衡量通信层峰值偏斜压力--routing-mode k_hot --hot-experts 32 --hot-fraction 0.9cuda_incast_k_hot.json观察imbalance_ratio与 p99/p999 的抬升偏斜梯度--routing-mode zipf扫--zipf-alpha 0.5/1.0/1.5观察偏斜程度与尾延迟的关系特性开关固定路由模式对比--zero-copy --async-finish组合的开与关、以及--async-finish与--return-recv-hook两种同步方式的差异后端对比在具备 RDMA 的环境中对比--pg-backend nccl与--pg-backend mooncake量化 fast-path 收益。注意事项num_experts必须被num_ranks整除fp8 时hidden-size须为 128 的倍数--async-finish与--return-recv-hook不可同时开启解读end_to_end_latency_ms时应记住它包含 mock 专家前向不是纯通信延迟多机实验优先用torchrun并由其管理WORLD_SIZE。赞分享人工智能大模型模型推理服务后端【免费下载链接】MooncakeMooncake is the serving platform for Kimi, a leading LLM service provided by Moonshot AI.项目地址https://gitcode.com/gh_mirrors/mo/Mooncake点击查看免费下载相关推荐GPT-NeoX推理性能测试终极指南如何优化大语言模型的吞吐量与延迟GPT NeoX推理性能测试终极指南如何优化大语言模型的吞吐量与延迟 GPT NeoX是由EleutherAI开发的开源大语言模型训练框架基于DeepSpe深度学习NLP大模型分布式训练预训练nanomsg性能测试报告吞吐量与延迟基准测试结果nanomsg性能测试报告吞吐量与延迟基准测试结果 nanomsg是一个轻量级、高性能的套接字库为构建分布式应用提供了简单而强大的消息传递能力。作为下一代消消息队列通信上一篇BetterGI终极指南打造你的原神自动化游戏体验下一篇终极碧蓝航线自动化脚本告别重复操作重获游戏乐趣创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考