[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"similar-deepseek-ai--EPLB":3,"tool-deepseek-ai--EPLB":61},[4,18,26,36,44,53],{"id":5,"name":6,"github_repo":7,"description_zh":8,"stars":9,"difficulty_score":10,"last_commit_at":11,"category_tags":12,"status":17},4358,"openclaw","openclaw\u002Fopenclaw","OpenClaw 是一款专为个人打造的本地化 AI 助手，旨在让你在自己的设备上拥有完全可控的智能伙伴。它打破了传统 AI 助手局限于特定网页或应用的束缚，能够直接接入你日常使用的各类通讯渠道，包括微信、WhatsApp、Telegram、Discord、iMessage 等数十种平台。无论你在哪个聊天软件中发送消息，OpenClaw 都能即时响应，甚至支持在 macOS、iOS 和 Android 设备上进行语音交互，并提供实时的画布渲染功能供你操控。\n\n这款工具主要解决了用户对数据隐私、响应速度以及“始终在线”体验的需求。通过将 AI 部署在本地，用户无需依赖云端服务即可享受快速、私密的智能辅助，真正实现了“你的数据，你做主”。其独特的技术亮点在于强大的网关架构，将控制平面与核心助手分离，确保跨平台通信的流畅性与扩展性。\n\nOpenClaw 非常适合希望构建个性化工作流的技术爱好者、开发者，以及注重隐私保护且不愿被单一生态绑定的普通用户。只要具备基础的终端操作能力（支持 macOS、Linux 及 Windows WSL2），即可通过简单的命令行引导完成部署。如果你渴望拥有一个懂你",349277,3,"2026-04-06T06:32:30",[13,14,15,16],"Agent","开发框架","图像","数据工具","ready",{"id":19,"name":20,"github_repo":21,"description_zh":22,"stars":23,"difficulty_score":10,"last_commit_at":24,"category_tags":25,"status":17},3808,"stable-diffusion-webui","AUTOMATIC1111\u002Fstable-diffusion-webui","stable-diffusion-webui 是一个基于 Gradio 构建的网页版操作界面，旨在让用户能够轻松地在本地运行和使用强大的 Stable Diffusion 图像生成模型。它解决了原始模型依赖命令行、操作门槛高且功能分散的痛点，将复杂的 AI 绘图流程整合进一个直观易用的图形化平台。\n\n无论是希望快速上手的普通创作者、需要精细控制画面细节的设计师，还是想要深入探索模型潜力的开发者与研究人员，都能从中获益。其核心亮点在于极高的功能丰富度：不仅支持文生图、图生图、局部重绘（Inpainting）和外绘（Outpainting）等基础模式，还独创了注意力机制调整、提示词矩阵、负向提示词以及“高清修复”等高级功能。此外，它内置了 GFPGAN 和 CodeFormer 等人脸修复工具，支持多种神经网络放大算法，并允许用户通过插件系统无限扩展能力。即使是显存有限的设备，stable-diffusion-webui 也提供了相应的优化选项，让高质量的 AI 艺术创作变得触手可及。",162132,"2026-04-05T11:01:52",[14,15,13],{"id":27,"name":28,"github_repo":29,"description_zh":30,"stars":31,"difficulty_score":32,"last_commit_at":33,"category_tags":34,"status":17},1381,"everything-claude-code","affaan-m\u002Feverything-claude-code","everything-claude-code 是一套专为 AI 编程助手（如 Claude Code、Codex、Cursor 等）打造的高性能优化系统。它不仅仅是一组配置文件，而是一个经过长期实战打磨的完整框架，旨在解决 AI 代理在实际开发中面临的效率低下、记忆丢失、安全隐患及缺乏持续学习能力等核心痛点。\n\n通过引入技能模块化、直觉增强、记忆持久化机制以及内置的安全扫描功能，everything-claude-code 能显著提升 AI 在复杂任务中的表现，帮助开发者构建更稳定、更智能的生产级 AI 代理。其独特的“研究优先”开发理念和针对 Token 消耗的优化策略，使得模型响应更快、成本更低，同时有效防御潜在的攻击向量。\n\n这套工具特别适合软件开发者、AI 研究人员以及希望深度定制 AI 工作流的技术团队使用。无论您是在构建大型代码库，还是需要 AI 协助进行安全审计与自动化测试，everything-claude-code 都能提供强大的底层支持。作为一个曾荣获 Anthropic 黑客大奖的开源项目，它融合了多语言支持与丰富的实战钩子（hooks），让 AI 真正成长为懂上",150037,2,"2026-04-10T23:33:47",[14,13,35],"语言模型",{"id":37,"name":38,"github_repo":39,"description_zh":40,"stars":41,"difficulty_score":32,"last_commit_at":42,"category_tags":43,"status":17},2271,"ComfyUI","Comfy-Org\u002FComfyUI","ComfyUI 是一款功能强大且高度模块化的视觉 AI 引擎，专为设计和执行复杂的 Stable Diffusion 图像生成流程而打造。它摒弃了传统的代码编写模式，采用直观的节点式流程图界面，让用户通过连接不同的功能模块即可构建个性化的生成管线。\n\n这一设计巧妙解决了高级 AI 绘图工作流配置复杂、灵活性不足的痛点。用户无需具备编程背景，也能自由组合模型、调整参数并实时预览效果，轻松实现从基础文生图到多步骤高清修复等各类复杂任务。ComfyUI 拥有极佳的兼容性，不仅支持 Windows、macOS 和 Linux 全平台，还广泛适配 NVIDIA、AMD、Intel 及苹果 Silicon 等多种硬件架构，并率先支持 SDXL、Flux、SD3 等前沿模型。\n\n无论是希望深入探索算法潜力的研究人员和开发者，还是追求极致创作自由度的设计师与资深 AI 绘画爱好者，ComfyUI 都能提供强大的支持。其独特的模块化架构允许社区不断扩展新功能，使其成为当前最灵活、生态最丰富的开源扩散模型工具之一，帮助用户将创意高效转化为现实。",108322,"2026-04-10T11:39:34",[14,15,13],{"id":45,"name":46,"github_repo":47,"description_zh":48,"stars":49,"difficulty_score":32,"last_commit_at":50,"category_tags":51,"status":17},6121,"gemini-cli","google-gemini\u002Fgemini-cli","gemini-cli 是一款由谷歌推出的开源 AI 命令行工具，它将强大的 Gemini 大模型能力直接集成到用户的终端环境中。对于习惯在命令行工作的开发者而言，它提供了一条从输入提示词到获取模型响应的最短路径，无需切换窗口即可享受智能辅助。\n\n这款工具主要解决了开发过程中频繁上下文切换的痛点，让用户能在熟悉的终端界面内直接完成代码理解、生成、调试以及自动化运维任务。无论是查询大型代码库、根据草图生成应用，还是执行复杂的 Git 操作，gemini-cli 都能通过自然语言指令高效处理。\n\n它特别适合广大软件工程师、DevOps 人员及技术研究人员使用。其核心亮点包括支持高达 100 万 token 的超长上下文窗口，具备出色的逻辑推理能力；内置 Google 搜索、文件操作及 Shell 命令执行等实用工具；更独特的是，它支持 MCP（模型上下文协议），允许用户灵活扩展自定义集成，连接如图像生成等外部能力。此外，个人谷歌账号即可享受免费的额度支持，且项目基于 Apache 2.0 协议完全开源，是提升终端工作效率的理想助手。",100752,"2026-04-10T01:20:03",[52,13,15,14],"插件",{"id":54,"name":55,"github_repo":56,"description_zh":57,"stars":58,"difficulty_score":32,"last_commit_at":59,"category_tags":60,"status":17},4721,"markitdown","microsoft\u002Fmarkitdown","MarkItDown 是一款由微软 AutoGen 团队打造的轻量级 Python 工具，专为将各类文件高效转换为 Markdown 格式而设计。它支持 PDF、Word、Excel、PPT、图片（含 OCR）、音频（含语音转录）、HTML 乃至 YouTube 链接等多种格式的解析，能够精准提取文档中的标题、列表、表格和链接等关键结构信息。\n\n在人工智能应用日益普及的今天，大语言模型（LLM）虽擅长处理文本，却难以直接读取复杂的二进制办公文档。MarkItDown 恰好解决了这一痛点，它将非结构化或半结构化的文件转化为模型“原生理解”且 Token 效率极高的 Markdown 格式，成为连接本地文件与 AI 分析 pipeline 的理想桥梁。此外，它还提供了 MCP（模型上下文协议）服务器，可无缝集成到 Claude Desktop 等 LLM 应用中。\n\n这款工具特别适合开发者、数据科学家及 AI 研究人员使用，尤其是那些需要构建文档检索增强生成（RAG）系统、进行批量文本分析或希望让 AI 助手直接“阅读”本地文件的用户。虽然生成的内容也具备一定可读性，但其核心优势在于为机器",93400,"2026-04-06T19:52:38",[52,14],{"id":62,"github_repo":63,"name":64,"description_en":65,"description_zh":66,"ai_summary_zh":66,"readme_en":67,"readme_zh":68,"quickstart_zh":69,"use_case_zh":70,"hero_image_url":71,"owner_login":72,"owner_name":73,"owner_avatar_url":74,"owner_bio":75,"owner_company":76,"owner_location":76,"owner_email":77,"owner_twitter":76,"owner_website":78,"owner_url":79,"languages":80,"stars":85,"forks":86,"last_commit_at":87,"license":88,"difficulty_score":89,"env_os":75,"env_gpu":90,"env_ram":90,"env_deps":91,"category_tags":95,"github_topics":76,"view_count":32,"oss_zip_url":76,"oss_zip_packed_at":76,"status":17,"created_at":96,"updated_at":97,"faqs":98,"releases":136},6507,"deepseek-ai\u002FEPLB","EPLB","Expert Parallelism Load Balancer","EPLB（Expert Parallelism Load Balancer）是一款专为混合专家模型（MoE）设计的开源负载均衡工具。在采用专家并行策略时，不同专家的计算负载往往差异巨大，容易导致部分 GPU 过载而其他闲置，从而降低整体训练或推理效率。EPLB 通过智能算法解决这一痛点，它能根据预估的专家负载，自动制定“冗余专家”复制与分布方案，确保集群中各 GPU 的算力得到均衡利用。\n\n该工具特别适合从事大模型架构研究、分布式训练系统开发的科研人员与工程师。其核心技术亮点在于深度适配了类似 DeepSeek-V3 的先进架构：一方面支持“分层负载均衡”策略，在满足特定条件时，优先将同组专家部署在同一节点内，显著减少跨节点通信开销；另一方面提供“全局负载均衡”策略，灵活应对不同阶段的并行需求。用户只需输入专家负载权重及硬件拓扑信息，EPLB 即可快速输出最优的专家放置计划，极大简化了大规模 MoE 模型的部署与复现流程，是提升多卡多机环境下模型运行效率的得力助手。","# Expert Parallelism Load Balancer (EPLB)\n\nWhen using expert parallelism (EP), different experts are assigned to different GPUs. Because the load of different \nexperts may vary depending on the current workload, it is important to keep the load of different GPUs balanced. \nAs described in the DeepSeek-V3 paper, we adopt a **redundant experts** strategy that duplicates heavy-loaded experts. \nThen, we heuristically pack the duplicated experts to GPUs to ensure load balancing across different GPUs. Moreover, \nthanks to the **group-limited expert routing** used in DeepSeek-V3, we also attempt to place the experts of the same \ngroup to the same node to reduce inter-node data traffic, whenever possible.\n\nTo facilitate reproduction and deployment, we open-source our deployed EP load balancing algorithm in `eplb.py`. \nThe algorithm computes a balanced expert replication and placement plan based on the estimated expert loads. Note \nthat the exact method to predict the loads of experts is out of this repo's scope. A common method is to use \nmoving average of historical statistics. \n\n## The Algorithm\n\nThe load balancing algorithm comes with two policies used for different cases.\n\n### Hierarchical Load Balancing\n\nWhen the number of server nodes divides the number of expert groups, we use the hierarchical load balancing policy to\nharness the group-limited expert routing. We first pack the expert groups to nodes evenly, ensuring the loads of \ndifferent nodes are balanced. Then, we replicate the experts within each node. Finally, we pack the replicated experts \nto individual GPUs to ensure different GPUs are load-balanced. The hierarchical load balancing policy can be used in \nprefilling stage with a smaller expert-parallel size.\n\n### Global Load Balancing\n\nIn other cases, we use the global load balancing policy that replicates the experts globally regardless of expert \ngroups, and pack the replicated experts to individual GPUs. This policy can be adopted in decoding stage with a larger \nexpert-parallel size.\n\n## Interface and Example\n\nThe main function of the load balancer is `eplb.rebalance_experts`.\n\nThe following code illustrates an example of a two-layer MoE model, and each layer contains 12 experts. We introduce 4 redundant experts per layer, and the total 16 replicas are placed on 2 nodes, and each node contains 4 GPUs.\n\n``` python\nimport torch\nimport eplb\n\nweight = torch.tensor([[ 90, 132,  40,  61, 104, 165,  39,   4,  73,  56, 183,  86],\n                       [ 20, 107, 104,  64,  19, 197, 187, 157, 172,  86,  16,  27]])\n\nnum_replicas = 16\nnum_groups = 4\nnum_nodes = 2\nnum_gpus = 8\n\nphy2log, log2phy, logcnt = eplb.rebalance_experts(weight, num_replicas, num_groups, num_nodes, num_gpus)\nprint(phy2log)\n\n# Output:\n# tensor([[ 5,  6,  5,  7,  8,  4,  3,  4, 10,  9, 10,  2,  0,  1, 11,  1],\n#         [ 7, 10,  6,  8,  6, 11,  8,  9,  2,  4,  5,  1,  5,  0,  3,  1]])\n```\n\nThe output, generated by the hierarchical load balancing policy, indicates the following \nexpert replication and placement plan.\n\n![](https:\u002F\u002Foss.gittoolsai.com\u002Fimages\u002Fdeepseek-ai_EPLB_readme_478a011a30fc.png)\n\n\n## License\n\nThis code repository is released under the MIT License.\n","# 专家并行负载均衡器 (EPLB)\n\n在使用专家并行（EP）时，不同的专家会被分配到不同的 GPU 上。由于不同专家的负载可能因当前工作负载而异，保持各 GPU 的负载均衡至关重要。正如 DeepSeek-V3 论文中所述，我们采用了一种**冗余专家**策略，即对负载较高的专家进行复制。随后，我们通过启发式方法将这些复制的专家合理地分配到各个 GPU 上，以确保不同 GPU 之间的负载均衡。此外，得益于 DeepSeek-V3 中使用的**分组受限专家路由**机制，我们还会尽可能地将同一分组内的专家放置在同一节点上，从而减少节点间的数据传输开销。\n\n为了便于复现和部署，我们将已部署的 EP 负载均衡算法开源至 `eplb.py` 文件中。该算法会根据预估的专家负载计算出一个均衡的专家复制与放置方案。需要注意的是，如何准确预测专家负载的方法并不在此仓库的讨论范围内。一种常见的方法是使用历史统计信息的滑动平均值来预测负载。\n\n## 算法说明\n\n该负载均衡算法包含两种策略，分别适用于不同的场景。\n\n### 层次化负载均衡\n\n当服务器节点的数量能够整除专家分组的数量时，我们采用层次化负载均衡策略，以充分利用分组受限专家路由机制。首先，我们将专家分组均匀地分配到各个节点上，确保各节点的负载均衡；接着，在每个节点内部对专家进行复制；最后，再将复制后的专家分配到各个 GPU 上，以实现不同 GPU 之间的负载均衡。层次化负载均衡策略适用于预填充阶段，此时专家并行规模较小。\n\n### 全局负载均衡\n\n在其他情况下，我们则采用全局负载均衡策略，该策略会忽略专家分组，对所有专家进行全局复制，并将复制后的专家分配到各个 GPU 上。此策略适用于解码阶段，此时专家并行规模较大。\n\n## 接口与示例\n\n负载均衡器的主要函数为 `eplb.rebalance_experts`。\n\n以下代码展示了一个两层 MoE 模型的示例，每层包含 12 个专家。我们在每层引入 4 个冗余专家，总共生成 16 个副本，并将其放置在 2 个节点上，每个节点配备 4 个 GPU。\n\n``` python\nimport torch\nimport eplb\n\nweight = torch.tensor([[ 90, 132,  40,  61, 104, 165,  39,   4,  73,  56, 183,  86],\n                       [ 20, 107, 104,  64,  19, 197, 187, 157, 172,  86,  16,  27]])\n\nnum_replicas = 16\nnum_groups = 4\nnum_nodes = 2\nnum_gpus = 8\n\nphy2log, log2phy, logcnt = eplb.rebalance_experts(weight, num_replicas, num_groups, num_nodes, num_gpus)\nprint(phy2log)\n\n# 输出：\n# tensor([[ 5,  6,  5,  7,  8,  4,  3,  4, 10,  9, 10,  2,  0,  1, 11,  1],\n#         [ 7, 10,  6,  8,  6, 11,  8,  9,  2,  4,  5,  1,  5,  0,  3,  1]])\n```\n\n输出结果由层次化负载均衡策略生成，表明了如下专家复制与放置方案。\n\n![](https:\u002F\u002Foss.gittoolsai.com\u002Fimages\u002Fdeepseek-ai_EPLB_readme_478a011a30fc.png)\n\n\n## 许可证\n\n本代码库采用 MIT 许可证发布。","# EPLB 快速上手指南\n\nEPLB (Expert Parallelism Load Balancer) 是专为 DeepSeek-V3 等混合专家模型（MoE）设计的专家并行负载均衡工具。它通过**冗余专家策略**和启发式打包算法，解决不同专家负载不均导致的 GPU 利用率差异问题，并尽可能将同组专家部署在同一节点以减少跨节点通信。\n\n## 环境准备\n\n*   **系统要求**: Linux 操作系统\n*   **前置依赖**:\n    *   Python 3.8+\n    *   PyTorch (建议版本与您的模型训练\u002F推理环境一致)\n    *   NumPy\n\n确保已安装 PyTorch。国内用户推荐使用清华或阿里镜像源加速安装：\n\n```bash\npip install torch numpy -i https:\u002F\u002Fpypi.tuna.tsinghua.edu.cn\u002Fsimple\n```\n\n## 安装步骤\n\n本项目核心逻辑位于 `eplb.py` 文件中。您可以直接克隆仓库或下载该文件到项目目录。\n\n**方式一：克隆仓库**\n\n```bash\ngit clone https:\u002F\u002Fgithub.com\u002Fdeepseek-ai\u002FEPLB.git\ncd EPLB\n```\n\n**方式二：直接使用单文件**\n\n如果您只需使用负载均衡算法，可直接将 repo 中的 `eplb.py` 复制到您的项目根目录，无需额外安装步骤。\n\n```bash\n# 假设您已下载 eplb.py 到当前目录\nls eplb.py\n```\n\n## 基本使用\n\nEPLB 的核心接口是 `eplb.rebalance_experts`。该函数接收专家负载估计值，输出平衡后的专家复制与放置方案。\n\n### 使用示例\n\n以下示例展示了一个两层 MoE 模型的配置：每层包含 12 个专家，引入 4 个冗余专家（共 16 个副本），部署在 2 个节点（共 8 张 GPU）上。\n\n```python\nimport torch\nimport eplb\n\n# 模拟专家负载权重 (2 层 x 12 专家)\n# 实际场景中，这些数据通常来自历史统计的移动平均值\nweight = torch.tensor([[ 90, 132,  40,  61, 104, 165,  39,   4,  73,  56, 183,  86],\n                       [ 20, 107, 104,  64,  19, 197, 187, 157, 172,  86,  16,  27]])\n\n# 配置参数\nnum_replicas = 16  # 每层总副本数 (原始专家 + 冗余专家)\nnum_groups = 4     # 专家组数量 (用于组限制路由)\nnum_nodes = 2      # 服务器节点数\nnum_gpus = 8       # 总 GPU 数\n\n# 执行重平衡\n# phy2log: 物理 GPU 索引 -> 逻辑专家索引映射\n# log2phy: 逻辑专家索引 -> 物理 GPU 索引映射\n# logcnt: 每个逻辑专家的副本计数\nphy2log, log2phy, logcnt = eplb.rebalance_experts(weight, num_replicas, num_groups, num_nodes, num_gpus)\n\nprint(\"物理 GPU 到逻辑专家的映射计划:\")\nprint(phy2log)\n```\n\n**输出说明：**\n`phy2log` 张量展示了最终的部署方案。每一行代表一个模型层，列对应物理 GPU 索引（0-7），值为该 GPU 上运行的逻辑专家 ID。算法会自动根据负载情况选择**分层负载均衡**（适用于 Prefill 阶段，节点数能整除组数）或**全局负载均衡**（适用于 Decoding 阶段）策略。","某大模型团队在部署基于 DeepSeek-V3 架构的混合专家（MoE）推理服务时，面临高并发请求下专家负载不均的挑战。\n\n### 没有 EPLB 时\n- **GPU 资源严重浪费**：由于不同专家被调用的频率差异巨大，部分 GPU 因承载“热门专家”而过载，其他 GPU 却因“冷门专家”空闲，导致整体吞吐量受限于最慢的节点。\n- **跨节点通信延迟高**：专家分配未考虑“组限制路由”特性，同一组的专家分散在不同物理节点，导致推理过程中产生大量不必要的跨节点数据流量。\n- **扩缩容策略僵化**：缺乏动态冗余机制，无法针对高负载专家进行复制，只能被动等待硬件升级或手动调整拓扑，响应速度慢且运维成本高。\n\n### 使用 EPLB 后\n- **实现细粒度负载均衡**：EPLB 自动识别高负载专家并生成冗余副本，通过启发式算法将副本智能打包到不同 GPU，消除了单点瓶颈，显著提升集群整体利用率。\n- **优化通信拓扑结构**：利用分层负载均衡策略，EPLB 优先将同组专家调度至同一节点内，大幅减少跨节点通信开销，降低了推理延迟。\n- **灵活适配不同阶段**：在预填充阶段采用分层策略以匹配较小的并行度，在解码阶段切换为全局策略以应对大规模并行，确保全链路性能最优。\n\nEPLB 通过智能的专家冗余与放置策略，将原本参差不齐的算力负载转化为均衡高效的推理流水线，是释放 MoE 模型潜力的关键基础设施。","https:\u002F\u002Foss.gittoolsai.com\u002Fimages\u002Fdeepseek-ai_EPLB_1b97df27.png","deepseek-ai","DeepSeek","https:\u002F\u002Foss.gittoolsai.com\u002Favatars\u002Fdeepseek-ai_04503588.png","",null,"service@deepseek.com","https:\u002F\u002Fwww.deepseek.com\u002F","https:\u002F\u002Fgithub.com\u002Fdeepseek-ai",[81],{"name":82,"color":83,"percentage":84},"Python","#3572A5",100,1358,201,"2026-04-10T07:49:12","MIT",1,"未说明",{"notes":92,"python":90,"dependencies":93},"该工具是一个专家并行负载均衡算法（eplb.py），主要用于计算专家的复制和放置计划。README 中未明确列出具体的操作系统、GPU 型号、显存大小、内存需求或 Python 版本要求。代码示例显示其依赖 PyTorch (torch)。专家负载的预测方法不在本仓库范围内，通常需用户使用历史统计数据的移动平均值自行实现。",[94],"torch",[35,14],"2026-03-27T02:49:30.150509","2026-04-11T10:02:43.944296",[99,104,109,113,118,122,127,132],{"id":100,"question_zh":101,"answer_zh":102,"source_url":103},29435,"EPLB 算法是否适用于大规模 MoE 模型的训练阶段？","不适用。EPLB 目前仅用于推理阶段，并未被设计或应用于训练过程。在训练中处理冗余专家权重的同步以及避免原专家与副本同时参与训练等问题，当前版本并未涉及。","https:\u002F\u002Fgithub.com\u002Fdeepseek-ai\u002FEPLB\u002Fissues\u002F10",{"id":105,"question_zh":106,"answer_zh":107,"source_url":108},29436,"在 Prefill（预填充）阶段，共享专家（Shared Expert）是如何处理和部署的？","在 Prefill 阶段，共享专家会被复制到每一个 GPU 上，且不被视为路由专家（routed expert）。所有额外的冗余专家名额都专门用于复制其他高负载的路由专家。因此，每个 GPU 通常承载 10 个专家（8 个原始专家 + 1 个共享专家 + 1 个冗余的路由专家）。","https:\u002F\u002Fgithub.com\u002Fdeepseek-ai\u002FEPLB\u002Fissues\u002F4",{"id":110,"question_zh":111,"answer_zh":112,"source_url":108},29437,"代码中的“Replica”是指冗余专家吗？专家组的节点部署在初始化后是固定的吗？","1. 代码中的'Replica'指专家的物理副本，既包含为了负载均衡生成的冗余专家，也包含原始的专家实例。\n2. 关于部署策略：技术报告撰写时，专家仅是在节点内（within nodes）进行重平衡。但在优化后的 EPLB 版本中，允许专家组在不同节点之间迁移（migrate across nodes），以实现更好的全局负载均衡，因此节点部署并非完全固定。",{"id":114,"question_zh":115,"answer_zh":116,"source_url":117},29438,"跨节点重新平衡专家组的开销是否值得？是否会带来显著的复制成本？","跨节点专家重平衡的开销非常小。根据实际观察，其带来的负载均衡收益几乎总是远超其产生的复制成本。即使在最坏情况下需要跨节点复制参数，相比其解决的负载不均问题，这部分开销是可以忽略不计的。","https:\u002F\u002Fgithub.com\u002Fdeepseek-ai\u002FEPLB\u002Fissues\u002F17",{"id":119,"question_zh":120,"answer_zh":121,"source_url":117},29439,"为什么在解码（Decoding）阶段不强制将同一个专家组的所有专家部署在同一个节点以利用 NVLink？","主要原因是为了支持更大的专家并行度（EP Size）。如果强制将整个专家组限制在单个节点内，EP Size 将被限制在该节点的 GPU 数量（例如最多 64），这可能导致推理延迟增加。为了获得更好的性能，系统倾向于使用更大的 EP Size（如 EP32 跨越多个节点），此时即使部分通信需通过 IB 进行，整体收益也更高。当然，如果 NVLink 带宽显著高于 IB 或对延迟不敏感，用户可根据具体硬件条件调整配置，将专家组放在单节点。",{"id":123,"question_zh":124,"answer_zh":125,"source_url":126},29440,"在解码阶段，全局负载均衡策略为何只处理冗余专家而不跨节点平衡负载？","因为在解码阶段不使用 NVLink 转发机制，跨节点进行细粒度的负载均衡意义不大且收益较低。目前的策略主要关注节点内的 GPU 负载均衡。维护者表示后续可能会更新 EPLB 以包含针对此场景的进一步优化，但核心原则是优先保证节点内效率。","https:\u002F\u002Fgithub.com\u002Fdeepseek-ai\u002FEPLB\u002Fissues\u002F14",{"id":128,"question_zh":129,"answer_zh":130,"source_url":131},29441,"使用 EPLB 后，在 GPU 利用率、通信量或推理速度方面具体有多少提升数据？","目前官方暂无计划披露 EPLB 带来的具体改进数值（如具体的百分比提升或绝对耗时减少数据）。虽然其在降低跨节点通信和优化负载方面有效，但详细的基准测试数据尚未公开。","https:\u002F\u002Fgithub.com\u002Fdeepseek-ai\u002FEPLB\u002Fissues\u002F20",{"id":133,"question_zh":134,"answer_zh":135,"source_url":126},29442,"Prefill 阶段的节点限制路由（Node-Limited Routing）如何影响跨节点通信开销？","该策略旨在减少跨节点数据流量。在 EP>=64（至少 8 个节点）的情况下，最坏情况下的令牌分发节点数可从 8 个减少到 4 个。而在当前常用的 EP32（4 个节点）配置下，虽然最坏情况仍是分发到 4 个节点，但该策略优化了平均情况，尽可能将令牌分发到同一节点上的多个专家组，从而显著降低平均跨节点通信开销。",[]]