KCD Hangzhou + OpenInfra Days China 2025,云原生,人工智能,开源,大模型,KCD Hangzhou 2025 组委会,OpenInfra 中国用户组, 照片直播 | KCD HANGZHOU OPENINFRA DAYS CHINA 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 网络来分发这些模型？ ...

部署体验 以 Nvidia 4090 + Nvidia-driver-580 驱动为例： Copy git clone https://github.com/deepseek-ai/DeepSeek-OCR.git && cd DeepSeek-OCR conda create -n ocr python=3.12 conda install cuda-toolkit=12.8 pip install torch==2.8.0 torchvision==0.23.0 torchaudio==2.8.0 --index-url https://download.pytorch.org/whl/cu128 pip install -r requirement.py python DeepSeek-OCR-master/DeepSeek-OCR-hf/run_dpsk_ocr.py 也可以直接体验：https://huggingface.co/spaces/merterbak/DeepSeek-OCR-Demo 模型架构 总体包含两个部分「DeepEncoder」和「LLM」。其中「DeepEncoder」由 「SAM」+「CLIP」模型结构组成，而「LLM」使用的是 DeepSeek-3B。 模型推理过程如下： 将输入的图片进行切分，得到 n 个 16x16 patches 图片块 使用 SAM 模型获取局部的 attention，并采用 16x 的下采样将 vision token 压缩到 n/16 个 将 vision token 逐个输入到 CLIP 模型，得到图片块的 Embedding 将图片块的 Embedding 和 Prompt 对应的 Embedding 合并作为输入，喂给 DeepSeek-3B ...

1. 关于成长 成长的三个阶段： 如何在这个世界上生存，并学会依靠规则去赢得基本竞争 如何能够看到更大的世界 如何在看到更大的世界后担负起更大的责任，赢得更大的荣耀和认可，创造更大的社会价值 线性成长模式：认为一个人的成长是由单一维度的要素来驱动的，只要在单一维度上持续地努力，随着时间推移就一定能够持续获得成长。例如，我们只要多读书，就一定能够掌握很多知识；我们只要多跑步，一定就会变得强壮。 非线性成长模式：认为一个人的成长是有很多不同维度的要素来驱动的，并且个人成长轨迹不太可能呈现为简单的直线上扬的成长模式。S 型曲线是「有序」的非线性成长模式中最常见和最容易被我们借鉴的。 一个环境长期越稳定，线性法则在其中就越适用；相反，如果一个环境变化越快、越频繁，则非线性法则越容易在其中起主导作用。 找到某些在非线性的世界中适用的基本规律和法则，对于你的成长至关重要。 任何个体或组织，本质上都需要线性法则和非线性法则交替发生作用，才能更好地驱动其发展和成长。 如果你所在的环境势能正在衰减，你的成长可能还会停滞，甚至倒退。 让你在合适的时候被放入一个合适的环境中去，你会获得巨大的提升和进步。 在任何领域内，只要变化和变革始终存在着，就总会有人站在新的机会上快速崛起。 每一种游戏都拥有它的规则，只有洞悉了那些稳定不变的规则，你才能知道如何在规则约定的范围内更好地“赢” 让自己不断到竞争更加激烈、压力更大的一线战场上，在竞争中不断赢得胜利，取得成绩。 2. 关于职业成长通关 要想在职业成长中通关，进入到更高的层次，需要具备两个条件： 获得稳定可观的收入的能力 拥有自己的核心竞争力和不可替代性 两种通关路径： 依靠某种技能成为一个业内顶级、位于 Top 3%- 5% 的专家 优秀的商业操盘手，通过商业经营让一家公司或一个业务的商业价值能够持续得到放大、收益更多并且效率更高 🌟🌟 一个人或者组织要想追求成长和发展，需要持续在两个维度上有所提升和突破，一个是线性维度上的提升（如增加自己某项技能的熟练程度），另一个则是非线形维度的提升（如升级自己的认知或升级自己的思维模式、组织系统、商业赛道等） 试着在线性维度上变得更强，是不断给自己打补丁，二试着更换认知、组织形态等，在非线形维度上获得提升，则是给自己更换操作系统。 🌟 真正的佛家信徒更倾向于认为，唯有先成功入世者，方可真正出世。 技能提升的靠谱方式： 自己尝试着刻意练习并依靠自我学习进行突破 尝试着参与到一个能给你提供实践机会的组织或团队中，义务为其劳动，并获得指导 参与某个能够给你提供大量真实实践机会和高质量反馈的课程 在职业成长中，总有一些大多数人不会选择的机会，其中可能蕴含着跃迁式的成长机会。 伴随着新技术，新模式出现，短期发展还完全不确定 ...

背景 最近这段时间，由于开发过程中都会用到 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 来转发流量从新加坡出口去请求模型列表。具体步骤如下： 在本地 .ssh/config 配置中，找到需要远程连接的主机，增加 RemoteForward 配置。有了这个配置，就会在 ssh 连接时，自动创建端口转发，将 remote 机器上所有请求 7897 端口的流量都转发到 local 机器的 127.0.0.1:7897 上。 Copy Host comfy HostName ngb1.dc.huixingyun.com User root Port 53727 PubkeyAuthentication yes IdentityFile ~/.ssh/id_rsa RemoteForward 7897 127.0.0.1:7897 在 VSCode 的 Remote-ssh 配置中设置 http.proxy ...

背景 前文提到 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 代码的绝佳组合，非常高效。 模型加载过程图 三个核心节点： UNETLoader：从硬盘读取模型文件，根据文件内容判断模型类型，并生成模型对象，最终加载模型到 cpu 上，得到 ModelPatcher LoraLoader：从硬盘读取模型文件，并将模型数据保存在 ModelPatcher 的 object_patches 字段中 KSampler：将 ModelPatcher 中存放的 lora 权重合并到 model 上，随后加载到 GPU 上，最后运行推理 自定义算子，加载 block wise scaled 模型 场景一：参考 kijai 大神的做法，先使用 block wise scaling 方法将 QwenImage 量化后导出模型文件，然后在使用 ComfyUI 时加载量化后的模型。 ...

背景 今年以来，在图像视频领域，开源的 AIGC 模型参数规模越来越大，例如，QwenImage 达到了 20B，Wan2.2 达到了 27B（High-Noise 和 Low-Noise 专家各占用 14B）。参数规模越大，就意味着需要更多的显存来加载模型，需要更多的算力来进行模型推理。而此时如果你想将这些 SOTA 模型运行在更加经济的消费级显卡时，就需要对模型进行量化（可以理解为压缩）。对于一张 24GB 显存的 4090 显卡而言，如果想要加载 QwenImage 20B 模型，就必须将模型权重量化到 fp8 精度。具体估算方式如下： Copy num_params = 20 * 2^30 fp8_size = 1 byte total_size = num_params * fp8_size = 20 * 2^30 * 1 byte = 20 GBytes 最近 musubi-tuner 的作者正在比较不同 fp8 量化方式对图片生成结果的影响，正好我对 ComfyUI 模型使用的 fp8_e4m3、fp8_e4m3fn、fp8_e5m2 等不同的 fp8 精度也一知半解，于是决定做一次系统的学习与整理。 关于精度与量化 浮点精度相信大家都不陌生，只不过接触比较多可能是 float32 单精度浮点数或者 float64 双精度浮点数。简单来说，浮点数的表示分为「符号位」、「指数位」、「尾数位」三个部分，如上图所示，其中每个色块代表一个 bit。你会发现 float8 精度有两个表示方式，fp8_e4m3 和 fp8_e5m2，不同的表示意味着不同的取值范围。 而所谓的量化，其实是将数值从较大的精度范围（bf16）缩小到较小的精度范围（fp8_e4m3）；反量化则刚好相反。 ...

1. 为什么？ 为什么会想要构建个人博客并且还是通过 Notion 的方式？ 「零秒思考」后的结果： Notion 中毒用户，馋 Notion 的编辑器 对 Notion 中记录的内容做一个系统整理并输出，尽量使用图的形式来展示 记录个人的思考、成长以及展示自己的能力，以便后续回顾 希望每篇博客都有自己的拍摄的一张照片，记录生活的点滴 为什么选择 Hugo？ 对 Hugo 这个项目接触比较早，大部分代码使用 Golang 实现，后续可操作性更强。 2. 架构图 虽然「元否」和 Notion-Hugo 的作者都给出了比较详细的说明，但是在实际配置过程中，还需要熟悉 Github action、Cloudflare builder 等概念，以便理解何时触发网站构建以及发布。梳理了一个架构图以便快速理解原理，为后续优化提供思路。 3. 遇到的问题 https://github.com/HEIGE-PCloud/Notion-Hugo 在将 Notion 的 page 转换成 markdown 格式时，如果遇到图片，会将原始 URL 的方式写入到 markdown 文件中，而这个 URL 是有防盗链的，1 小时后便会过期，导致图裂。 Copy https://prod-files-secure.s3.us-west-2.amazonaws.com/dc681554-1505-4cec-9a8f-844b66d5dcc8/4e9385da-92e0-4c4a-9ba1-871eb116b2e5/DSCF9506_preview.jpeg?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=ASIAZI2LB466SETVVHQ7%2F20250927%2Fus-west-2%2Fs3%2Faws4_request&X-Amz-Date=20250927T010113Z&X-Amz-Expires=3600&X-Amz-Security-Token=IQoJb3JpZ2luX2VjEBEaCXVzLXdlc3QtMiJHMEUCIBgl6TamR&X-Amz-Signature=d9be103faf2f37cf40ca1481c3dd906b8aa9e47d57bf05b8195d9929f53eebcc&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject 考虑到 Notion-Hugo 的转换脚本是通过 nodejs 来实现的，对我来说二开的难度较大，另外整体逻辑也不复杂，最终决定自己来重新搭建一套。在 Github 中找到了多个使用 python 来实现 notion2md 的库，经过对比和少量的 hack，完成了第一版转换脚本：https://github.com/polym/notion2md 4. 其他核心点 以下是 Github Action workflow Copy name: Build and Deploy Blog on: # 每天凌晨 1 点自动触发 schedule: - cron: '0 17 * * *' # 北京时间 01:00 # 允许手动触发 workflow_dispatch: jobs: build-deploy: runs-on: ubuntu-latest permissions: contents: write steps: - name: Checkout code uses: actions/checkout@v3 # Hugo 主题库拉取 - name: Update git submodules run: | git submodule update --init --recursive - name: Set up Python uses: actions/setup-python@v4 with: python-version: '3.x' - name: Install dependencies run: | sudo apt-get update sudo apt-get install -y make pip install -r py/requirements.txt - name: Install latest Hugo run: | wget https://github.com/gohugoio/hugo/releases/download/v0.151.0/hugo_0.151.0_linux-amd64.deb -O hugo.deb sudo dpkg -i hugo.deb hugo version # 指定 NOTION DB 和 NOTION TOKEN - name: Set up environment variables run: | echo "NOTION_DB_ID=${{ secrets.NOTION_DB_ID }}" > .env echo "NOTION_TOKEN=${{ secrets.NOTION_TOKEN }}" >> .env echo "NOTION_DB_ID=${{ secrets.NOTION_DB_ID }}" >> $GITHUB_ENV echo "NOTION_TOKEN=${{ secrets.NOTION_TOKEN }}" >> $GITHUB_ENV - name: Build blog run: | make convert && make build # 自动提交 hugo-site/content 中的内容 - name: Commit updated content uses: stefanzweifel/git-auto-commit-action@v6 with: commit_message: Sync content with Notion file_pattern: 'hugo-site/content/' 5. 后续的思考 需要去解决 Notion 中特殊块到 Markdown 的连接 ...