SuperBigMango

NVBandwidth 是 NVIDIA 官方提供的 GPU 带宽测试工具，用于测量 CPU↔GPU、GPU↔GPU、GPU 显存读写、Copy Engine、SM 拷贝内核等路径的实际带宽。NVBandwidth 的测试结果可以帮助分析 vLLM 使用 TP/PP 多卡推理时，GPU 间通信是否成为性能瓶颈。 本文档记录在 Ubuntu 24 Desktop/Server 环境下，针对 4 张 NVIDIA RTX 4090，使用 原生环境安装 CUDA Toolkit 13.2、编译并测试 NVIDIA NVBandwidth 的完整流程。 本文档不使用 Docker 进行测试，适用于希望在宿主机上直接运行 nvbandwidth 的场景。 环境说明当前测试环境： 项目 配置 操作系统 Ubuntu 24 GPU 4 × NVIDIA GeForce RTX 4090 NVIDIA 驱动版本 595.71.05 CUDA Toolkit 目标版本 CUDA Toolkit 13.2 测试工具 NVIDIA NVBandwidt...

背景在一台 Ubuntu 24.04 服务器上，机器插入了两张高速网卡，每张网卡提供两个光模块口，因此一共有四个可配置的高速网口。计划为四个网口分别配置如下 IP 地址： 网口 IP 地址 隔离命名空间 ens3f0np0 10.0.0.101/24 ns101 ens3f1np1 10.0.0.102/24 ns102 ens6f0np0 10.0.0.103/24 ns103 ens6f1np1 10.0.0.104/24 ns104 最终目标是将四个光口都接入交换机，并让这些 IP 之间的访问必须经过物理网口出到交换机，再由交换机转发回来，而不是被 Linux 本机网络栈直接在机内转发。 在正式接交换机之前，先用两根光纤做点对点连通性测试： 12ens3f0np0 <----光纤----> ens3f1np1ens6f0np0 <----光纤----> ens6f1np1 也就是： 12ns101 / 10.0.0.101 <----> ns102 / 10.0.0.102ns103 / 10.0.0.1...

核心流程梳理主要流程函数 RunAsync：总调度，分三步 RunPreCopy：准备数据，部分rank与邻居先做一次规约或拷贝 RunAllReduceHDOptim：主规约过程，分多步，每步与不同邻居通信 RunFinalStep：处理非2的幂次时的收尾 关键数据结构 userMemIn：用户输入数据 **outputMem_**：算法内部buffer，存放中间结果 userMemOut：最终输出 links：与其他rank的通信链路 **meshStreams_**：多stream支持 以4个NPU为例（rankSize=4, base=2, nSteps=2） 每个NPU初始有自己的输入数据 目标：所有NPU最终都拿到全局规约（如sum）结果 4个NPU的AllReduce通信过程步骤分解步骤0：数据准备（RunPreCopy） 每个NPU把自己的输入数据拷贝到outputMem_ 某些NPU与邻居先做一次规约或数据交换 步骤1：第一次规约（step=1） 每个NPU与“距离为1”的邻居（rank异或1）交换数据并做规约...

摘要这次问题的表象是：GitHub 贡献图里 Mango03111/Mango03111.github.io 仓库的 commit contributions 不断上涨，早期看起来像是 3 月 11 日单日统计异常，后来发现所有与这个博客仓库相关的提交日期都在按不同倍数增长。最终确认：博客仓库存在 源码分支 hexo 和 部署分支 main 两套历史；main 原本既是 GitHub Pages 发布分支，又是仓库默认分支。GitHub 会把默认分支上的 commit 纳入贡献统计，因此部署产物分支上的 Site updated 提交被计入贡献图。再叠加 GitHub Pages / Actions 的构建触发，贡献图出现了逐步重复计数的现象。 关键词：GitHub Contributions、GitHub Pages、Hexo、默认分支、部署分支、Actions、pages-build-deployment、.deploy_git 最终有效处理是： 关闭仓库 GitHub Actions 后，异常贡献不再继续上涨。 将仓库默认分支从部署分支 main 切换为源码...

适用对象：根据用户提供的颚式破碎机设计说明书，建立一套可用于课程设计、毕业设计展示和基本运动仿真的 SolidWorks 简化装配体。建模目标：外形结构完整、主要尺寸有据可依、装配关系清楚、运动链能够实现“飞轮/偏心轴旋转—动颚复摆—破碎腔开合”的基本功能。 1. 说明书使用说明本说明书用于指导 SolidWorks 建模人员完成 PE250×400 复摆颚式破碎机简化运动装配体 的建模。文档中的尺寸分为两类： 类型 含义 使用原则 原文尺寸 用户提供的设计说明书中已经计算或明确给出的尺寸 应优先采用 建模补充尺寸 原文未给出，但为了完成三维建模、保证装配不干涉而补充的推荐尺寸 可根据实际建模情况微调 需要特别说明的是：原设计说明书属于设计计算书，并不是完整工程图。因此，不能将说明书中的所有尺寸机械地直接照搬为三维模型尺寸。机架总长、动颚体外形、轴承座、调整座、推力板孔距、带轮宽度、电机外形等尺寸需要根据装配关系进行合理补充。 2. 建模对象与总体要求2.1 建模对象建模对象为： PE250×400 复摆颚式破碎机 该机型主要由以下部分组成：...

旅行真正留下来的，往往不是目的地；而是某个清晨的光线、风经过街道的声音，和那一刻恰好安静下来的自己。有些瞬间并不盛大；可能只是一杯咖啡、一段车程、一场日落，或某条没有名字的小路；但正因为足够普通，才更容易被记很久；于是把沿途看到的风景、情绪和零散片段，都留在了这里；这一路的片段，需要认真收藏~ 2026年五一劳动节终南山、五台山，飞驰人生3转场： 📷 前往「Mango的相册 · Mango游记」，查看完整旅行照片。

本文改写自 OpenAI 官方工程博客《Supercomputer networking to accelerate large scale AI training》与论文《Resilient AI Supercomputer Networking using MRC and SRv6》。目标是用博客化的方式解释：为什么大规模 AI 训练需要新的网络协议，MRC 如何与多平面拓扑、SRv6 源路由一起，把“网络故障”从训练中断事件变成可被系统自动绕开的背景噪声。 论文链接：Resilient AI Supercomputer Networking using MRC and SRv6 问题不是平均带宽，而是最慢那一次通信在同步预训练中，成千上万甚至十万级 GPU 按训练 step 锁步推进。每个 step 中，GPU 之间要执行数据并行、张量并行、流水线并行、专家并行等多种通信。理想状态下，通信被尽量隐藏在计算之后；但现实里，只要某一次传输成为“长尾”，整个 step 都可能被拖慢。 这也是大规模训练网络最棘手的地方：平均吞吐量很高并不够，最慢的那条路径、最晚到达的那个包，才...

安装 Ubuntu 24.04 LTS 后，ToDesk 远程控制软件可能会出现无法正常被控的问题。表面上看，设备在线、软件也能启动，但其他电脑发起远控时，连接进度条会卡住，甚至进入黑屏状态。 本文记录一次 Ubuntu 24.04 环境下 ToDesk 远控异常的排查和解决过程。 问题现象系统环境如下： 系统版本：Ubuntu 24.04.1 LTS ToDesk 版本：4.7.2.0 遇到的问题主要有： Ubuntu 电脑可以正常使用 ToDesk 去远控其他设备，但偶尔会出现窗口闪烁。 其他电脑也能看到这台 Ubuntu 设备在线，但发起远控后无法真正进入桌面。连接进度条可能卡在一半，也可能卡到 100% 后黑屏。 与此同时，Ubuntu 被控端会提示“正在被远控”，但实际上控制端并不能看到桌面，也无法正常操作。 也就是说，ToDesk 的连接似乎已经建立，但远程画面没有正常传输出来。 问题原因Ubuntu 24.04 默认使用的显示管理器通常是 gdm3。在本次问题中，ToDesk 在 gdm3 环境下可以启动，也可以显示设备在线，但作为被控端时无法正常输出远程桌...

董小姐董小姐吉他谱，宋冬野的一首歌，歌曲为4/4拍的节奏，选用C调和弦进行编配，弹奏时变调夹4品即可保持与原曲一样的调式E调，当然也可以根据实际情况自己微调变调夹品数。《董小姐》吉他弹唱谱完整曲谱共3张图片六线谱；一把木吉他，一个感人的故事，一曲平和但打动人心的旋律，一首充满诗意的民谣歌曲，值得反复推敲的歌词能停在唇边，能落在心里。 安河桥

摘要MoE 推理系统里最难建模的部分，往往不是拓扑本身，而是计算与通信的真实组织方式。同样是 expert parallelism，Prefill 更像高吞吐、大批量、长计算核与长尾通信的重叠问题；Decode 则更像低时延、小步长、高频短通信的尾延迟问题。两者虽然都属于推理阶段，但在时间线上几乎表现为两种不同系统。 本文基于 DeepSeek 开源的 DeepEP、profile-data 中的 PyTorch Profiler 轨迹以及 shallowsim 中的性能分析脚本，重新梳理 DeepSeek-V3 / R1 架构家族在 MoE 推理中的关键行为特征。文章重点关注三个问题： DeepEP 到底解决了什么问题 Prefill 和 Decode 的计算-通信模式为何截然不同 这些真实数据对后续仿真建模意味着什么 如果你关心的是 MoE 推理中的 all-to-all、双 micro-batch 重叠、SM 占用方式，或者希望在仿真器里更接近真实系统行为，这篇文章可以作为一份系统性的背景材料。 引言在做 MoE 推理系统建模时，最难的部分往往不是“网络拓扑怎...