SuperBigMango

空闲时间翻阅之前的U盘文件，发现高中时期军事社团活动上给大家出的战术想定题目，内容很经典，来自于美方军校的真实题目（应该是），很多都是针对治安战总结出来的相关题目，基本规模控制在班排级别（这也可以理解，毕竟学员出来也要从基层干起）；这其中有些题目还比较有参考价值，因此我将他们整合成一篇博客，供大家参考阅读~ 城市作战情况：你第六陆战队1营A连1排的排长，美军正在进行一次进攻行动，这是在荒废的沙漠国家Kartiq进行的联合作战的一部分。联合国军（淡泊注：美国鬼子还真会做梦阿，哈哈。）此举就是要推翻Kartiqi的极权独裁者并被这一地区带来稳定和安宁。K军队抵抗轻微。一般老百姓蔑视他们的领袖，但是同时他们也对美军在这一地区的存在不安。本地人通常会避开美军但是还没有公开反对过美军。但是，如果确信的他们正在变成军事的行动直接的目标,他们会发动起义保家卫国。在意识到这种可能后，Kartiqi的部队为了把老百姓拉进冲突而在城市中增加了活动次数 。在一个星期以前本团夺取了Rikala 的城镇。1营被赋予在本城恢复秩序的任务，而本团的其他军队仍推向北方（淡泊注：听起来像是纳西里耶发生过的故事）。...

环境说明本文记录在一台单机 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 更偏训练、预训练、继续预训练、模型并行和分布式训练验证。 停止已有占用显存进程如果机器上正在运行的占用显存的服务，需要先停止，释放GPU。 1docker ps 如果看到正在运行的 vLLM 容器，例如 qwen36-vllm，执行： 1dock...

本文记录在 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 都可能被拖慢。 这也是大规模训练网络最棘手的地方：平均吞吐量很高并不够，最慢的那条路径、最晚到达的那个包，才...