🤖 解构极速权重同步:从内存寻址到流⽔线引擎

背景

在 KCD Hangzhou 的活动中有幸跟百炼的于文渊大佬做了交流,得知在模型同步可以考虑 p2p 分发的方式。于是做了一个简单的调研,发现 Kimi 开源的推理引擎 Mooncake 也提供了类似的方法,就花时间阅读了下源码,共涉及 Mooncakecheckpoint-engine 两个项目。 实话说,本人对 AI 硬件与内核联动相关领域并不熟悉,因此在阅读源码过程中,有很多专业性的技术了解甚少,理解起来十分吃力。好在如今有 Copilot 协助,才得以完成代码阅读。在这个过程中也发现一个很有意思的阅读源码的方法:

  1. 在 VSCode 中让 Github Copilot 进行辅助阅读源码,针对不明白的点,及时提问
  2. 等所有细节都整理清楚后,将与 Copilot 的聊天内容导入到 NotebookLM 中
  3. 在 NotebookLM 中,再次对内容进行梳理,NotebookLM 也会主动引导提问
  4. 对 NotebookLM 每轮返回的结果进行评估,如果符合预期则保存为 note
  5. 在 NotebookLM 中,将所有保存的 note 作为 source,然后通过「Slide Deck」生成 Slide

接下来,我将使用生成的 Slide,来分析大模型 p2p 分发的逻辑。

核⼼挑战:⼤模型时代下的权重更新瓶颈

通过「内存注册」,提供硬件可直接操作的物理地址

优化二:零拷贝与内核旁路,告别开销

利用 RDMA 和 NVLink & CUDA IPC 技术,实现内存和硬件之间的直接流动,完全绕过 CPU 和操作系统内核。

优化三:利用 P2P 以及流水异步化机制,压榨并行

这里需要补充一点,在 checkpoint-engine 中 P2P 只在 h2d 阶段获取原始权重时才会用到,其余权重同步逻辑均由 NCCL 库来实现。

KCD Hangzhou 2025

周末作为志愿者参加了 KCD Hangzhou 的活动,活动地址在浙大紫荆港边上,离公司不远。

谈谈几点收获

这次志愿者工作被安排在签到台,最直观的好处就是可以跟大佬面对面,在这个过程中结识了 Kong 上海的负责人黄总、蚂蚁 Kata infra 团队的大佬们、通义实验室百炼平台负责人于总、蚂蚁 Nydus 容器团队的工程师。

在深入的沟通中,也了解到了在 AI 热的大背景下,目前国内大厂顶尖的 infra 团队在虚拟化层、镜像交付层、MaaS 调度层正在推进哪些工作以及遇到了哪些挑战。

关于 MaaS

百炼平台的 MaaS 无疑是顶级的,托管了众多不同类型、不同规格的模型。百炼在底层资源层面采用了 K8s 来进行统一纳管,在上层则自研了诸如 DashServing、DashMesh、DashScaler 等组件。在这个技术框架下,他们发现了一个问题,目前 K8s 只提供了基于 Pod 生命周期的管理,没有提供基于 Model 的生命周期管理。这样会导致在模型切换时,如果直接使用 K8s 的原语,那么只能对 Pod 进行重建,这样切换模型的开销是巨大的,特别是 Pod 可能会被调度到其他节点,另外,模型的装载与卸载相比在 Serving 服务内做也会有一定的开销。因此,在分享中提出了灵魂拷问,「在 AI 推理的背景下,是否一定需要 K8s?」

会后也请教了在 MaaS 层如何做到高效的模型切换,特别是在加载 DeepSeek-V3 这类超大模型。解决方案是通过 P2P 从其他节点获取模型文件,同时需要少量 hack 读取 safetensors 相关的代码。这个思路让我恍然大悟(后面发现 Mooncake 也是这么做的)。回到我们自己推理业务场景,ComfyUI 会加载很多不同种类的模型,加载时均需要将模型从磁盘读取到内存,然后再放到 GPU 显存中,这中间的开销是巨大的(关于详细细节后续文章中展开)。那么,有没有可能构建一个内存级 p2p 网络来分发这些模型?

关于 Nydus

Nydus 是一个非常好的点子,在 AI 的场景下,镜像中大部分文件是没有改变的,例如,一些 python 库的 so 大文件等。Nydus 打破原本 docker 镜像按文件系统层打包存储的逻辑,改为按照文件分块进行存储,从而避免了重复文件反复下载的问题。前几周正好在研究,但是有些顾虑大厂开源项目后续维护问题。会上也问了目前蚂蚁内部使用情况(80% 以上),以及例如 nydusd 挂导致 fuse hang 住的等运维问题解决手段。关于后续规划的 ModelPack,感觉有点类似 Ollama,这块个人觉得蚂蚁内部应该不太会去推进,应用场景太小。

「非线性成长」摘录

1. 关于成长

成长的三个阶段:

  • 如何在这个世界上生存,并学会依靠规则去赢得基本竞争
  • 如何能够看到更大的世界
  • 如何在看到更大的世界后担负起更大的责任,赢得更大的荣耀和认可,创造更大的社会价值

线性成长模式:认为一个人的成长是由单一维度的要素来驱动的,只要在单一维度上持续地努力,随着时间推移就一定能够持续获得成长。例如,我们只要多读书,就一定能够掌握很多知识;我们只要多跑步,一定就会变得强壮。

非线性成长模式:认为一个人的成长是有很多不同维度的要素来驱动的,并且个人成长轨迹不太可能呈现为简单的直线上扬的成长模式。S 型曲线是「有序」的非线性成长模式中最常见和最容易被我们借鉴的。

  1. 一个环境长期越稳定,线性法则在其中就越适用;相反,如果一个环境变化越快、越频繁,则非线性法则越容易在其中起主导作用。
  2. 找到某些在非线性的世界中适用的基本规律和法则,对于你的成长至关重要。
  3. 任何个体或组织,本质上都需要线性法则和非线性法则交替发生作用,才能更好地驱动其发展和成长。

如果你所在的环境势能正在衰减,你的成长可能还会停滞,甚至倒退。

让你在合适的时候被放入一个合适的环境中去,你会获得巨大的提升和进步。

在任何领域内,只要变化和变革始终存在着,就总会有人站在新的机会上快速崛起。

每一种游戏都拥有它的规则,只有洞悉了那些稳定不变的规则,你才能知道如何在规则约定的范围内更好地“赢”

让自己不断到竞争更加激烈、压力更大的一线战场上,在竞争中不断赢得胜利,取得成绩。

2. 关于职业成长通关

要想在职业成长中通关,进入到更高的层次,需要具备两个条件:

  1. 获得稳定可观的收入的能力
  2. 拥有自己的核心竞争力和不可替代性

两种通关路径:

  1. 依靠某种技能成为一个业内顶级、位于 Top 3%- 5% 的专家
  2. 优秀的商业操盘手,通过商业经营让一家公司或一个业务的商业价值能够持续得到放大、收益更多并且效率更高

🌟🌟 一个人或者组织要想追求成长和发展,需要持续在两个维度上有所提升和突破,一个是线性维度上的提升(如增加自己某项技能的熟练程度),另一个则是非线形维度的提升(如升级自己的认知或升级自己的思维模式、组织系统、商业赛道等)

试着在线性维度上变得更强,是不断给自己打补丁,二试着更换认知、组织形态等,在非线形维度上获得提升,则是给自己更换操作系统。

🌟 真正的佛家信徒更倾向于认为,唯有先成功入世者,方可真正出世。

技能提升的靠谱方式:

  1. 自己尝试着刻意练习并依靠自我学习进行突破
  2. 尝试着参与到一个能给你提供实践机会的组织或团队中,义务为其劳动,并获得指导
  3. 参与某个能够给你提供大量真实实践机会和高质量反馈的课程

在职业成长中,总有一些大多数人不会选择的机会,其中可能蕴含着跃迁式的成长机会。

  1. 伴随着新技术,新模式出现,短期发展还完全不确定
  2. 你主动挑起大家都认为“很坑”,“很碎”,“摊子很烂”,无人愿意接手的项目,然后干出来了

这个世界是公平的,当你追求远高于他人的成长,若你不是天赋异禀,那你一定要比他人负担更大的风险和压力,才有可能。

成为头部的 20% 需要什么?被大部分人认可的代表作。

“实践—反馈—调整认知—再实践—再反馈”

顶级专家是以某种能够持续创造价值的技能来作为自己的赛道,而商业操盘手则是以某个特定的行业来作为自己的赛道

如果想要成为一个头部选手,一个人必须具备两个前提条件

  1. 你已经具备某些在该领域获得成功的“独特”能力或经验
  2. 你清晰地给自己定义了一个竞争赛道

🌟 一个人在职业成长路径上要想实现通关,往往不是一蹴而就的,需要先设定某个目标,不断努力和实践,并在此过程中不断检视和思考,经历反复多次的迭代,最终找到自己的独特价值和优势。

🌟 技能曲线上的成长:如何把一件事做好做对,商业认知/系统思考层面上的成长:如何才能更多地去做对的事。

3. 关于商业世界

一家企业的基本功能和目标,就是追求盈利和商业价值最大化。

🌟 商业世界里,决定胜负的关键词:价值、效率。

始终关注价值,而非具体问题的执行路径、难度和过往经验。

始终思考和关注现有工作流程及业务链条中效率可以提升 2 倍以上的可能性和机会。

在商业世界里,作为个人也好公司也好,我们都需要拥有自己的壁垒和核心竞争里,让他人难以模仿和超越。

两个重要的思考习惯

  1. 当你面临一件事要不要做,或者遇到某个问题很难被解决的时候,要优先关注“事情被解决后的价值有多大”,而非具体问题的执行路径、难度和过往经验。
  2. 始终思考和关注现有工作流程及业务链条中效率可以提升 2 倍以上的可能性和机会。

竞争策略三级思考法:

你所在的行业/业务有哪些基本规律?

你所处的平台/生态内有什么竞争规则/常见玩法?

你面对怎样的竞争对手,有什么机会或优势?利用自己的独特之处制定更适合自己的策略

Github Copilot remote-ssh 支持 Claude 系列模型

背景

最近这段时间,由于开发过程中都会用到 GPU 卡且对配置也有较高的要求,自己的开发机已经无法满足需求,所以索性就把开发环境搬到了公司的云产品上。开发方式:在本地的 Mac-mini 上通过 VSCode remote-ssh 连接到机器上进行开发。但是遇到了一个奇怪的问题,Github copilot 中 Claude 系列模型消失了。而同样的方式连接到自己的 4090 开发机没遇到这个问题。分析了下,觉得可能是网络的出口有关系,4090 开发机在公司环境,默认走香港线路,而公司的云机,默认走国内线路。不经联想到最近 Anthropic 对 Claude 模型提出的新限制,不禁挺佩服 Anthropic 对规则的坚持🤦。

原因分析

公司的 GPU 云机所在机房在国内,虽然也有科学上网代理,但是由于白名单中未对相关域名放开,所以还是默认走国内出口,由于 Anthropic 官方的限制要求,导致在获取模型列表时,无法获取到 Claude 模型。

解决思路

方案比较简单,就是对远程 VSCode Server 设置 http.proxy,将所有流量回传到 Mac-mini 上的 Clash 上,由 Clash 来转发流量从新加坡出口去请求模型列表。具体步骤如下:

  1. 在本地 .ssh/config 配置中,找到需要远程连接的主机,增加 RemoteForward 配置。有了这个配置,就会在 ssh 连接时,自动创建端口转发,将 remote 机器上所有请求 7897 端口的流量都转发到 local 机器的 127.0.0.1:7897 上。

ComfyUI 模型加载分析 & 自定义量化算子

背景

前文提到 musubi-tunner 作者自己实现了 block-wise fp8 scaling,并且代码非常精简,但是 ComfyUI 还没有对此进行支持。而在 https://github.com/kohya-ss/musubi-tuner/issues/634 中也提到了想要使用 ComfyUI 来体验 block-wise fp8 scaling。

ComfyUI 接触也有一段时间,决定来手搓一个插件。在搓插件之前,需要先理解 ComfyUI 当前加载模型的逻辑。在 ComfyUI 中,官方提供了加载 diffusion 模型的节点 UNetLoader、加载 LoRA 模型的节点 LoraLoader、以及运行模型的节点 KSampler。

这里还有一点提下,VSCode + 单步调试 + Github Copilot 简直是查看 Python 代码的绝佳组合,非常高效。

模型加载过程图

三个核心节点:

  1. UNETLoader:从硬盘读取模型文件,根据文件内容判断模型类型,并生成模型对象,最终加载模型到 cpu 上,得到 ModelPatcher
  2. LoraLoader:从硬盘读取模型文件,并将模型数据保存在 ModelPatcher 的 object_patches 字段中
  3. KSampler:将 ModelPatcher 中存放的 lora 权重合并到 model 上,随后加载到 GPU 上,最后运行推理

自定义算子,加载 block wise scaled 模型

场景一:参考 kijai 大神的做法,先使用 block wise scaling 方法将 QwenImage 量化后导出模型文件,然后在使用 ComfyUI 时加载量化后的模型。

fp8 量化的几种姿势

背景

今年以来,在图像视频领域,开源的 AIGC 模型参数规模越来越大,例如,QwenImage 达到了 20B,Wan2.2 达到了 27B(High-Noise 和 Low-Noise 专家各占用 14B)。参数规模越大,就意味着需要更多的显存来加载模型,需要更多的算力来进行模型推理。而此时如果你想将这些 SOTA 模型运行在更加经济的消费级显卡时,就需要对模型进行量化(可以理解为压缩)。对于一张 24GB 显存的 4090 显卡而言,如果想要加载 QwenImage 20B 模型,就必须将模型权重量化到 fp8 精度。具体估算方式如下:

使用 Notion-Hugo 构建个人博客

为什么会想要构建个人博客并且还是通过 Notion 的方式?

「零秒思考」后的结果:

  1. Notion 中毒用户,馋 Notion 的编辑器
  2. 对 Notion 中记录的内容做一个系统整理并输出,尽量使用图的形式来展示
  3. 记录个人的思考、成长以及展示自己的能力,以便后续回顾
  4. 希望每篇博客都有自己的拍摄的一张照片,记录生活的点滴

为什么选择 Hugo?

对 Hugo 这个项目接触比较早,大部分代码使用 Golang 实现,后续可操作性更强。

虽然「元否」和 Notion-Hugo 的作者都给出了比较详细的说明,但是在实际配置过程中,还需要熟悉 Github action、Cloudflare builder 等概念,以便理解何时触发网站构建以及发布。梳理了一个架构图以便快速理解原理,为后续优化提供思路。

https://github.com/HEIGE-PCloud/Notion-Hugo 在将 Notion 的 page 转换成 markdown 格式时,如果遇到图片,会将原始 URL 的方式写入到 markdown 文件中,而这个 URL 是有防盗链的,1 小时后便会过期,导致图裂。