SuperBigMango

环境说明本文记录在一台单机 4 卡 RTX 4090 服务器上，通过 Docker 部署 NVIDIA Megatron-LM，并完成从环境安装、NCCL 通信验证到 GPT 小模型训练测试的完整流程。 本机环境如下： 123456操作系统：Ubuntu 24 DesktopGPU：4 × NVIDIA GeForce RTX 4090NVIDIA Driver：595.71.05容器运行环境：Docker + NVIDIA Container ToolkitMegatron 路线：NVIDIA/Megatron-LM 主线版本基础镜像：nvcr.io/nvidia/pytorch:26.01-py3 Megatron-LM 主要用于大模型训练和并行训练实验，和 vLLM 的定位不同：vLLM 更偏推理部署，Megatron-LM 更偏训练、预训练、继续预训练、模型并行和分布式训练验证。 停止已有 vLLM 容器如果机器上正在运行的占用存的服务，需要先停止，释放GPU。 1docker ps 如果看到正在运行的 vLLM 容器，例如 qwen36-vllm，执行： 1doc...

本文记录在 Ubuntu 24 Desktop 系统上，使用 Docker + vLLM 部署 Qwen3.6-35B-A3B-FP8 大模型的完整流程。测试硬件为 4 张 RTX 4090 24GB，宿主机 NVIDIA 驱动版本为 595.71.05；本安装记录仅在此平台上经过验证，其余平台请按照自身需求调整策略。 本文目标是形成一套可复现的部署教程，因此只保留核心步骤，省略无意义的试错过程。 环境说明本次部署环境如下： 1234567操作系统：Ubuntu 24 Desktop显卡：4 × NVIDIA RTX 4090 24GBNVIDIA 驱动：595.71.05部署方式：Docker + vLLM OpenAI API Server模型：Qwen/Qwen3.6-35B-A3B-FP8模型存放目录：~/model服务端口：8000 由于 4 张 4090 总显存为 96GB，推荐优先使用 FP8 版本模型，即： 1Qwen/Qwen3.6-35B-A3B-FP8 不建议一开始直接部署 BF16 原版，因为 35B BF16 权重和 KV Cache 会带来更大的显...

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转场： 秦岭国家动物园： 露营烧烤： 后海： 2026年清明节骊山（骊哈顿）：

本文改写自 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 环境下可以启动，也可以显示设备在线，但作为被控端时无法正常输出远程桌...