[开心] [开心] [贱笑]_老虎社区_美港股上老虎 - 老虎社区

[开心] [开心] [贱笑]

DeepSeek王炸开源第六弹：全面揭秘V3/R1推理系统秘密，成本利润率高达545%！

免责声明：上述内容仅代表发帖人个人观点，不构成本平台的任何投资建议。

精彩评论

我们需要你的真知灼见来填补这片空白

发表看法

{"i18n":{"language":"zh_CN"},"detailType":1,"isChannel":false,"data":{"magic":2,"id":408790378217904,"tweetId":"408790378217904","gmtCreate":1740820297067,"gmtModify":1740820298708,"author":{"id":3547634688703059,"idStr":"3547634688703059","authorId":3547634688703059,"authorIdStr":"3547634688703059","name":"007笑","avatar":"https://static.tigerbbs.com/2b7dc0a5634de60afc7c246c20c642ff","vip":1,"userType":1,"introduction":"","boolIsFan":false,"boolIsHead":false,"crmLevel":4,"crmLevelSwitch":0,"individualDisplayBadges":[],"fanSize":17,"starInvestorFlag":false},"themes":[],"images":[],"coverImages":[],"html":"<html><head></head><body><p><span>[开心]&nbsp;</span> <span>[开心]&nbsp;</span> <span>[贱笑]&nbsp;</span>&nbsp;<br></p></body></html>","htmlText":"<html><head></head><body><p><span>[开心]&nbsp;</span> <span>[开心]&nbsp;</span> <span>[贱笑]&nbsp;</span>&nbsp;<br></p></body></html>","text":"[开心] [开心] [贱笑]","highlighted":1,"essential":1,"paper":1,"likeSize":0,"commentSize":0,"repostSize":0,"favoriteSize":0,"link":"https://laohu8.com/post/408790378217904","repostId":1153894248,"repostType":4,"repost":{"id":"1153894248","kind":"news","pubTimestamp":1740819306,"share":"https://ttm.financial/m/news/1153894248?lang=&edition=full","pubTime":"2025-03-01 16:55","market":"sh","language":"zh","title":"DeepSeek王炸开源第六弹：全面揭秘V3/R1推理系统秘密，成本利润率高达545%！","url":"https://stock-news.laohu8.com/highlight/detail?id=1153894248","media":"AI寒武纪","summary":"DeepSeek V3/R1推理系统通过跨节点专家并行 、计算-通信重叠和精细的负载均衡策略，实现了惊人的性能和效率。本来以为DeepSeek开源周连续五天的开源项目已经结束了，万万没想到DeepSeek还有one more thing ，补了一个王炸开源项目第六弹：深度揭秘DeepSeek V3/R1 推理系统背后的秘密本号第一时间给大家划个重点V3/R1系统设计原则：效率至上！DeepSeek V3/R1 推理系统的核心目标非常明确：更高吞吐量，更低延迟！DeepSeek 团队为了解决 EP 带来的复杂性，可谓是下足了功夫！成本利润率高达 545%！","content":"<html><head></head><body><p>DeepSeek V3/R1推理系统通过跨节点专家并行 (EP)、计算-通信重叠和精细的负载均衡策略，实现了惊人的性能和效率。简单来说，EP就像是“多人协作”，把模型中的“专家”分散到多张 GPU 上进行计算，大幅提升Batch Size，榨干 GPU 算力，同时专家分散，降低内存压力，更快响应。</p><p style=\"text-align: justify;\">本来以为DeepSeek开源周连续五天的开源项目已经结束了，万万没想到DeepSeek还有one more thing ，补了一个王炸开源项目第六弹：深度揭秘DeepSeek V3/R1 推理系统背后的秘密</p><p class=\"t-img-caption\"><img src=\"https://static.tigerbbs.com/c4966df229fb52178fbd42809e12dfac\" tg-width=\"1364\" tg-height=\"1004\"/></p><p style=\"text-align: justify;\">本号第一时间给大家划个重点</p><h2 id=\"id_4159871898\">V3/R1系统设计原则：效率至上！</h2><p style=\"text-align: justify;\">DeepSeek V3/R1 推理系统的核心目标非常明确：更高吞吐量，更低延迟！ 为了实现这两个目标，DeepSeek 团队祭出了一个大招 —— 跨节点专家并行 (Expert Parallelism, EP)！</p><p style=\"text-align: justify;\">专家并行 (EP) 是什么神仙操作？</p><p style=\"text-align: justify;\">简单来说，EP就像是“多人协作”，把模型中的“专家”分散到多张 GPU 上进行计算。这样做有两大好处：</p><ul style=\"\"><li><p>• 大幅提升 Batch Size，榨干 GPU 算力！ ???? 更大的 Batch Size 意味着 GPU 矩阵运算效率更高，推理吞吐量自然水涨船高！</p></li><li><p>• 专家分散，降低内存压力，更快响应！ ⚡️ 每个 GPU 只需处理一小部分专家，减少了内存访问需求，延迟也就降下来啦！</p></li></ul><p style=\"text-align: justify;\">当然，EP 也不是完美无瑕的，它也带来了新的挑战：</p><ol start=\"1\" style=\"\"><li><p>1. 跨节点通信！ ???? 专家分散在不同节点，节点间的通信就成了性能瓶颈。DeepSeek 团队必须精心设计计算流程，让通信和计算“无缝衔接”，最大化效率！</p></li><li><p>2. 多节点数据并行 (DP) + 负载均衡！ ⚖️ EP 本身就涉及多节点，再加上数据并行，负载均衡就显得尤为重要！必须保证所有 GPU 都“吃饱喝足”，避免出现“木桶效应”。</p></li></ol><h2 id=\"id_784007131\">硬核技术揭秘！如何应对 EP 带来的挑战？</h2><p style=\"text-align: justify;\">DeepSeek 团队为了解决 EP 带来的复杂性，可谓是下足了功夫！他们主要从以下几个方面入手：</p><blockquote><p style=\"text-align: justify;\">1.规模化跨节点专家并行 (Large-scale Cross-node Expert Parallelism (EP))</p></blockquote><p style=\"text-align: justify;\">DeepSeek V3/R1 模型参数量巨大，专家数量也相当惊人 (256个专家中只有8个被激活！)。这种高稀疏性决定了模型需要 超大的 Batch Size 才能充分发挥性能。 因此，大规模跨节点 EP 是必然选择！</p><p style=\"text-align: justify;\">为了适应预填充 (prefill) 和解码 (decode) 阶段的不同特点，DeepSeek 采用了不同程度的并行策略：</p><ul style=\"\"><li><p>• 预填充阶段 [Routed Expert EP32, MLA/Shared Expert DP32]： 每个部署单元跨越 4 个节点，拥有 32 个冗余路由专家。每张 GPU 管理 9 个路由专家和 1 个共享专家。</p></li><li><p>• 解码阶段 [Routed Expert EP144, MLA/Shared Expert DP144]： 每个部署单元扩展到 18 个节点，依然是 32 个冗余路由专家。每张 GPU 管理 2 个路由专家和 1 个共享专家。</p></li><li><p>• 计算-通信重叠 (Computation-Communication Overlapping) </p></li></ul><p style=\"text-align: justify;\">大规模跨节点 EP 引入了巨大的通信开销。为了解决这个问题，DeepSeek 采用了 双批次重叠策略 (dual-batch overlap strategy)。 简单来说，就是把一个大的请求 Batch 分成两个 Micro-Batch，交替执行。这样，一个 Micro-Batch 的通信开销就可以巧妙地隐藏在另一个 Micro-Batch 的计算过程中！</p><p style=\"text-align: justify;\">以下是预填充阶段的计算-通信重叠示意图：</p><p class=\"t-img-caption\"><img src=\"https://static.tigerbbs.com/853213d98b58e869d80bbc872e2aa296\" tg-width=\"1346\" tg-height=\"318\"/></p><p style=\"text-align: justify;\">解码阶段也采用了类似的策略，但更加精细，将 Attention 层进一步细分为两步，使用了 五阶段流水线 (5-stage pipeline)，实现更流畅的通信-计算重叠</p><p class=\"t-img-caption\"><img src=\"https://static.tigerbbs.com/fb27cc58ba62d232e7c5024d5b477d3c\" tg-width=\"1336\" tg-height=\"350\"/></p><p style=\"text-align: justify;\">想了解更多计算-通信重叠的细节？ 猛戳这里：https://github.com/deepseek-ai/profile-data (DeepSeek 官方性能分析数据仓库)</p><blockquote><p style=\"text-align: justify;\">2.最优负载均衡 (Optimal Load Balancing) ⚖️</p></blockquote><p style=\"text-align: justify;\">大规模并行 (DP + EP) 带来的另一个挑战就是 负载均衡。 一旦某个 GPU 成为瓶颈，整个系统的性能都会被拖累。为了最大化资源利用率，DeepSeek 团队在负载均衡方面也做了很多优化，主要包括以下三个方面：</p><p style=\"text-align: justify;\">a. 预填充负载均衡器 (Prefill Load Balancer)</p><ul style=\"\"><li><p>• 关键问题： 不同 DP 实例的请求数量和序列长度不同，导致核心注意力计算和分发发送负载不均衡。</p></li><li><p>• 优化目标：<br/>* 平衡 GPU 之间的核心注意力计算负载 (核心注意力计算负载均衡)。<br/>* 均衡每个 GPU 的输入 Token 数量 (分发发送负载均衡)，防止特定 GPU 成为性能瓶颈。</p></li></ul><p style=\"text-align: justify;\">b. 解码负载均衡器 (Decode Load Balancer)</p><ul style=\"\"><li><p>• 关键问题： 不同 DP 实例的请求数量和序列长度不均，导致核心注意力计算 (与 KVCache 使用量相关) 和分发发送负载差异。</p></li><li><p>• 优化目标：<br/>* 平衡 GPU 之间的 KVCache 使用量 (核心注意力计算负载均衡)<br/>* 均衡每个 GPU 的请求数量 (分发发送负载均衡)</p></li></ul><p style=\"text-align: justify;\">c. 专家并行负载均衡器 (Expert-Parallel Load Balancer)</p><ul style=\"\"><li><p>• 关键问题： 对于 MoE 模型，存在一些天生高负载的专家，导致不同 GPU 上的专家计算负载不均衡。</p></li><li><p>• 优化目标：<br/>* 平衡每个 GPU 上的专家计算负载 (即，最小化所有 GPU 的最大分发接收负载)。</p></li></ul><h2 id=\"id_2867931366\">系统架构一览!DeepSeek 在线推理系统概览</h2><p class=\"t-img-caption\"><img src=\"https://static.tigerbbs.com/ffb15a20e3ec96a0590ed6029f1334c1\" tg-width=\"1350\" tg-height=\"630\"/></p><p style=\"text-align: justify;\">整个 DeepSeek 在线推理系统架构清晰明了，各个组件协同工作，保证了高性能和稳定性。</p><h2 id=\"id_460851006\">硬核数据说话!) DeepSeek 在线服务性能统计 </h2><p style=\"text-align: justify;\">DeepSeek V3/R1 推理服务全部部署在 H800 GPU 上，并采用了与训练一致的精度策略：</p><ul style=\"\"><li><p>• 矩阵乘法和分发传输** 使用 FP8 格式</p></li><li><p>• 核心 MLA 计算和组合传输** 使用 BF16格式</p></li></ul><p style=\"text-align: justify;\">保证了最佳服务性能！</p><p style=\"text-align: justify;\">根据统计数据 (UTC+8 02/27/2025 12:00 PM to 02/28/2025 12:00 PM)：</p><p style=\"text-align: justify;\">单 H800 节点平均吞吐量： 预填充阶段约 73.7k tokens/s (输入，包含缓存命中)，解码阶段约14.8k tokens/s (输出)！</p><ul style=\"\"><li><p>• 成本利润率高达 545%！ 这简直逆天！</p></li><li><p></p><p class=\"t-img-caption\"><img src=\"https://static.tigerbbs.com/8eadd7daca6e10675a5053556adaafb4\" tg-width=\"1326\" tg-height=\"474\"/></p></li></ul><p style=\"text-align: justify;\">其他关键数据：</p><ul style=\"\"><li><p>• 总输入 Tokens：608B，其中 342B (56.3%) 命中 On-disk KV 缓存</p></li><li><p>• 总输出 Tokens：168B。</p></li><li><p>• 平均输出速度：20-22 tokens/秒。</p></li><li><p>• 平均每个输出 Token 的 KVCache 长度：4,989 tokens</p></li></ul><p class=\"t-img-caption\"><img src=\"https://static.tigerbbs.com/4e8b21a5c5119e946b8950bf7c994714\" tg-width=\"1350\" tg-height=\"528\"/></p><p style=\"text-align: justify;\">DeepSeek 还根据白天和晚上的服务负载动态调整推理节点数量，实现资源的最优利用！</p><h2 id=\"id_602653476\">写在最后：</h2><p style=\"text-align: justify;\">DeepSeek V3/R1 推理系统通过 跨节点专家并行 (EP)、计算-通信重叠 和 精细的负载均衡策略，实现了惊人的性能和效率！ 这不仅展现了 DeepSeek 强大的技术实力，也为大模型推理系统的优化提供了宝贵的经验</p><p style=\"text-align: justify;\">只能说deepseek太牛了，再让我震惊一会！</p></body></html>","source":"lsy1713840592850","collect":0,"html":"<!DOCTYPE html>\n<html>\n<head>\n<meta http-equiv=\"Content-Type\" content=\"text/html; charset=utf-8\" />\n<meta name=\"viewport\" content=\"width=device-width,initial-scale=1.0,minimum-scale=1.0,maximum-scale=1.0,user-scalable=no\"/>\n<meta name=\"format-detection\" content=\"telephone=no,email=no,address=no\" />\n<title>DeepSeek王炸开源第六弹：全面揭秘V3/R1推理系统秘密，成本利润率高达545%！</title>\n<style type=\"text/css\">\na,abbr,acronym,address,applet,article,aside,audio,b,big,blockquote,body,canvas,caption,center,cite,code,dd,del,details,dfn,div,dl,dt,\nem,embed,fieldset,figcaption,figure,footer,form,h1,h2,h3,h4,h5,h6,header,hgroup,html,i,iframe,img,ins,kbd,label,legend,li,mark,menu,nav,\nobject,ol,output,p,pre,q,ruby,s,samp,section,small,span,strike,strong,sub,summary,sup,table,tbody,td,tfoot,th,thead,time,tr,tt,u,ul,var,video{ font:inherit;margin:0;padding:0;vertical-align:baseline;border:0 }\nbody{ font-size:16px; line-height:1.5; color:#999; background:transparent; }\n.wrapper{ overflow:hidden;word-break:break-all;padding:10px; }\nh1,h2{ font-weight:normal; line-height:1.35; margin-bottom:.6em; }\nh3,h4,h5,h6{ line-height:1.35; margin-bottom:1em; }\nh1{ font-size:24px; }\nh2{ font-size:20px; }\nh3{ font-size:18px; }\nh4{ font-size:16px; }\nh5{ font-size:14px; }\nh6{ font-size:12px; }\np,ul,ol,blockquote,dl,table{ margin:1.2em 0; }\nul,ol{ margin-left:2em; }\nul{ list-style:disc; }\nol{ list-style:decimal; }\nli,li p{ margin:10px 0;}\nimg{ max-width:100%;display:block;margin:0 auto 1em; }\nblockquote{ color:#B5B2B1; border-left:3px solid #aaa; padding:1em; }\nstrong,b{font-weight:bold;}\nem,i{font-style:italic;}\ntable{ width:100%;border-collapse:collapse;border-spacing:1px;margin:1em 0;font-size:.9em; }\nth,td{ padding:5px;text-align:left;border:1px solid #aaa; }\nth{ font-weight:bold;background:#5d5d5d; }\n.symbol-link{font-weight:bold;}\n/* header{ border-bottom:1px solid #494756; } */\n.title{ margin:0 0 8px;line-height:1.3;color:#ddd; }\n.meta {color:#5e5c6d;font-size:13px;margin:0 0 .5em; }\na{text-decoration:none; color:#2a4b87;}\n.meta .head { display: inline-block; overflow: hidden}\n.head .h-thumb { width: 30px; height: 30px; margin: 0; padding: 0; border-radius: 50%; float: left;}\n.head .h-content { margin: 0; padding: 0 0 0 9px; float: left;}\n.head .h-name {font-size: 13px; color: #eee; margin: 0;}\n.head .h-time {font-size: 11px; color: #7E829C; margin: 0;line-height: 11px;}\n.small {font-size: 12.5px; display: inline-block; transform: scale(0.9); -webkit-transform: scale(0.9); transform-origin: left; -webkit-transform-origin: left;}\n.smaller {font-size: 12.5px; display: inline-block; transform: scale(0.8); -webkit-transform: scale(0.8); transform-origin: left; -webkit-transform-origin: left;}\n.bt-text {font-size: 12px;margin: 1.5em 0 0 0}\n.bt-text p {margin: 0}\n</style>\n</head>\n<body>\n<div class=\"wrapper\">\n<header>\n<h2 class=\"title\">\nDeepSeek王炸开源第六弹：全面揭秘V3/R1推理系统秘密，成本利润率高达545%！\n</h2>\n\n<h4 class=\"meta\">\n\n\n2025-03-01 16:55 北京时间&nbsp;&nbsp;&nbsp;<a href=https://mp.weixin.qq.com/s?__biz=Mzg3MTkxMjYzOA==&mid=2247502603&idx=1&sn=ca83bb0148d854b6a2266021cf26606d&chksm=cfc556cbed868bd48140d0090fda548537400bbcdbf5a3e42d6d3bb3f7d8a2338c5f2c56469d&mpshare=1&scene=23&srcid=0301o7sl2uvTeZvwyDZg6NU0&sharer_shareinfo=af5706b0d11227263611c9616a4ce25c&sharer_shareinfo_first=af5706b0d11227263611c9616a4ce25c#rd><strong>AI寒武纪</strong></a>\n\n\n</h4>\n\n</header>\n<article>\n<div>\n<p>DeepSeek V3/R1推理系统通过跨节点专家并行 (EP)、计算-通信重叠和精细的负载均衡策略，实现了惊人的性能和效率。简单来说，EP就像是“多人协作”，把模型中的“专家”分散到多张 GPU 上进行计算，大幅提升Batch Size，榨干 GPU 算力，同时专家分散，降低内存压力，更快响应。本来以为DeepSeek开源周连续五天的开源项目已经结束了，万万没想到DeepSeek还有one ...</p>\n\n<a href=\"https://mp.weixin.qq.com/s?__biz=Mzg3MTkxMjYzOA==&mid=2247502603&idx=1&sn=ca83bb0148d854b6a2266021cf26606d&chksm=cfc556cbed868bd48140d0090fda548537400bbcdbf5a3e42d6d3bb3f7d8a2338c5f2c56469d&mpshare=1&scene=23&srcid=0301o7sl2uvTeZvwyDZg6NU0&sharer_shareinfo=af5706b0d11227263611c9616a4ce25c&sharer_shareinfo_first=af5706b0d11227263611c9616a4ce25c#rd\">Web Link</a>\n\n</div>\n\n\n</article>\n</div>\n</body>\n</html>\n","type":0,"thumbnail":"https://static.tigerbbs.com/6912f480d0a5aead184bbc80e00929ae","relate_stocks":{},"source_url":"https://mp.weixin.qq.com/s?__biz=Mzg3MTkxMjYzOA==&mid=2247502603&idx=1&sn=ca83bb0148d854b6a2266021cf26606d&chksm=cfc556cbed868bd48140d0090fda548537400bbcdbf5a3e42d6d3bb3f7d8a2338c5f2c56469d&mpshare=1&scene=23&srcid=0301o7sl2uvTeZvwyDZg6NU0&sharer_shareinfo=af5706b0d11227263611c9616a4ce25c&sharer_shareinfo_first=af5706b0d11227263611c9616a4ce25c#rd","is_english":false,"share_image_url":"https://static.laohu8.com/e9f99090a1c2ed51c021029395664489","article_id":"1153894248","content_text":"DeepSeek V3/R1推理系统通过跨节点专家并行 (EP)、计算-通信重叠和精细的负载均衡策略，实现了惊人的性能和效率。简单来说，EP就像是“多人协作”，把模型中的“专家”分散到多张 GPU 上进行计算，大幅提升Batch Size，榨干 GPU 算力，同时专家分散，降低内存压力，更快响应。本来以为DeepSeek开源周连续五天的开源项目已经结束了，万万没想到DeepSeek还有one more thing ，补了一个王炸开源项目第六弹：深度揭秘DeepSeek V3/R1 推理系统背后的秘密本号第一时间给大家划个重点V3/R1系统设计原则：效率至上！DeepSeek V3/R1 推理系统的核心目标非常明确：更高吞吐量，更低延迟！ 为了实现这两个目标，DeepSeek 团队祭出了一个大招 —— 跨节点专家并行 (Expert Parallelism, EP)！专家并行 (EP) 是什么神仙操作？简单来说，EP就像是“多人协作”，把模型中的“专家”分散到多张 GPU 上进行计算。这样做有两大好处：• 大幅提升 Batch Size，榨干 GPU 算力！ ???? 更大的 Batch Size 意味着 GPU 矩阵运算效率更高，推理吞吐量自然水涨船高！• 专家分散，降低内存压力，更快响应！ ⚡️ 每个 GPU 只需处理一小部分专家，减少了内存访问需求，延迟也就降下来啦！当然，EP 也不是完美无瑕的，它也带来了新的挑战：1. 跨节点通信！ ???? 专家分散在不同节点，节点间的通信就成了性能瓶颈。DeepSeek 团队必须精心设计计算流程，让通信和计算“无缝衔接”，最大化效率！2. 多节点数据并行 (DP) + 负载均衡！ ⚖️ EP 本身就涉及多节点，再加上数据并行，负载均衡就显得尤为重要！必须保证所有 GPU 都“吃饱喝足”，避免出现“木桶效应”。硬核技术揭秘！如何应对 EP 带来的挑战？DeepSeek 团队为了解决 EP 带来的复杂性，可谓是下足了功夫！他们主要从以下几个方面入手：1.规模化跨节点专家并行 (Large-scale Cross-node Expert Parallelism (EP))DeepSeek V3/R1 模型参数量巨大，专家数量也相当惊人 (256个专家中只有8个被激活！)。这种高稀疏性决定了模型需要 超大的 Batch Size 才能充分发挥性能。 因此，大规模跨节点 EP 是必然选择！为了适应预填充 (prefill) 和解码 (decode) 阶段的不同特点，DeepSeek 采用了不同程度的并行策略：• 预填充阶段 [Routed Expert EP32, MLA/Shared Expert DP32]： 每个部署单元跨越 4 个节点，拥有 32 个冗余路由专家。每张 GPU 管理 9 个路由专家和 1 个共享专家。• 解码阶段 [Routed Expert EP144, MLA/Shared Expert DP144]： 每个部署单元扩展到 18 个节点，依然是 32 个冗余路由专家。每张 GPU 管理 2 个路由专家和 1 个共享专家。• 计算-通信重叠 (Computation-Communication Overlapping) 大规模跨节点 EP 引入了巨大的通信开销。为了解决这个问题，DeepSeek 采用了 双批次重叠策略 (dual-batch overlap strategy)。 简单来说，就是把一个大的请求 Batch 分成两个 Micro-Batch，交替执行。这样，一个 Micro-Batch 的通信开销就可以巧妙地隐藏在另一个 Micro-Batch 的计算过程中！以下是预填充阶段的计算-通信重叠示意图：解码阶段也采用了类似的策略，但更加精细，将 Attention 层进一步细分为两步，使用了 五阶段流水线 (5-stage pipeline)，实现更流畅的通信-计算重叠想了解更多计算-通信重叠的细节？ 猛戳这里：https://github.com/deepseek-ai/profile-data (DeepSeek 官方性能分析数据仓库)2.最优负载均衡 (Optimal Load Balancing) ⚖️大规模并行 (DP + EP) 带来的另一个挑战就是 负载均衡。 一旦某个 GPU 成为瓶颈，整个系统的性能都会被拖累。为了最大化资源利用率，DeepSeek 团队在负载均衡方面也做了很多优化，主要包括以下三个方面：a. 预填充负载均衡器 (Prefill Load Balancer)• 关键问题： 不同 DP 实例的请求数量和序列长度不同，导致核心注意力计算和分发发送负载不均衡。• 优化目标：* 平衡 GPU 之间的核心注意力计算负载 (核心注意力计算负载均衡)。* 均衡每个 GPU 的输入 Token 数量 (分发发送负载均衡)，防止特定 GPU 成为性能瓶颈。b. 解码负载均衡器 (Decode Load Balancer)• 关键问题： 不同 DP 实例的请求数量和序列长度不均，导致核心注意力计算 (与 KVCache 使用量相关) 和分发发送负载差异。• 优化目标：* 平衡 GPU 之间的 KVCache 使用量 (核心注意力计算负载均衡)* 均衡每个 GPU 的请求数量 (分发发送负载均衡)c. 专家并行负载均衡器 (Expert-Parallel Load Balancer)• 关键问题： 对于 MoE 模型，存在一些天生高负载的专家，导致不同 GPU 上的专家计算负载不均衡。• 优化目标：* 平衡每个 GPU 上的专家计算负载 (即，最小化所有 GPU 的最大分发接收负载)。系统架构一览!DeepSeek 在线推理系统概览整个 DeepSeek 在线推理系统架构清晰明了，各个组件协同工作，保证了高性能和稳定性。硬核数据说话!) DeepSeek 在线服务性能统计 DeepSeek V3/R1 推理服务全部部署在 H800 GPU 上，并采用了与训练一致的精度策略：• 矩阵乘法和分发传输** 使用 FP8 格式• 核心 MLA 计算和组合传输** 使用 BF16格式保证了最佳服务性能！根据统计数据 (UTC+8 02/27/2025 12:00 PM to 02/28/2025 12:00 PM)：单 H800 节点平均吞吐量： 预填充阶段约 73.7k tokens/s (输入，包含缓存命中)，解码阶段约14.8k tokens/s (输出)！• 成本利润率高达 545%！ 这简直逆天！其他关键数据：• 总输入 Tokens：608B，其中 342B (56.3%) 命中 On-disk KV 缓存• 总输出 Tokens：168B。• 平均输出速度：20-22 tokens/秒。• 平均每个输出 Token 的 KVCache 长度：4,989 tokensDeepSeek 还根据白天和晚上的服务负载动态调整推理节点数量，实现资源的最优利用！写在最后：DeepSeek V3/R1 推理系统通过 跨节点专家并行 (EP)、计算-通信重叠 和 精细的负载均衡策略，实现了惊人的性能和效率！ 这不仅展现了 DeepSeek 强大的技术实力，也为大模型推理系统的优化提供了宝贵的经验只能说deepseek太牛了，再让我震惊一会！","news_type":1,"symbols_score_info":{}},"isVote":1,"tweetType":1,"viewCount":838,"commentLimit":10,"likeStatus":false,"favoriteStatus":false,"reportStatus":false,"symbols":[],"verified":2,"subType":0,"readableState":1,"langContent":"EN","currentLanguage":"EN","warmUpFlag":false,"orderFlag":false,"shareable":true,"causeOfNotShareable":"","featuresForAnalytics":[],"commentAndTweetFlag":false,"andRepostAutoSelectedFlag":false,"upFlag":false,"length":18,"optionInvolvedFlag":false,"xxTargetLangEnum":"ORIG"},"commentList":[],"isCommentEnd":true,"isTiger":false,"isWeiXinMini":false,"url":"/m/post/408790378217904"}