Roger-Lv's space

在深度学习的世界里，优化器就是模型的“导航员”。我们熟悉 Adam、AdamW，也听说过 SGD（随机梯度下降）。但最近，一个名为 Muon 的新型优化器引起了轰动，特别是在训练大规模模型（如 LLM）和生成模型（如 GAN）时表现惊艳。 Muon 的核心秘密武器不是复杂的神经网络结构，而是一个古老的数学技巧——牛顿-舒尔茨迭代。 今天，我们就来拆解一下：这个牛顿-舒尔茨迭代到底是什么？Muon 是如何用它来“驯服”梯度的？以及这其中涉及到的动量、正交和奇异值到底又是什么？ 一、什么是牛顿-舒尔茨迭代？ 简单来说，牛顿-舒尔茨迭代是一种极其高效的矩阵求逆（或近似求逆）算法。 在数学上，如果你想求一个矩阵 AAA 的逆矩阵 A−1A^{-1}A−1，通常需要做复杂的矩阵分解（如 SVD），计算量非常大。但牛顿-舒尔茨迭代提供了一个简单的迭代公式： Xk+1=Xk(2I−AXk)X_{k+1} = X_k (2I - A X_k) Xk+1​=Xk​(2I−AXk​) 其中 XkX_kXk​ 是我们对逆矩阵的猜测，III 是单位矩阵。 为什么它这么好用？ 速度极快：它不需要复杂...

在当今大模型推理优化领域，推测解码（Speculative Decoding） 已成为降低推理延迟、提升吞吐的主流技术之一。然而，随着业务的发展和模型的演进，一个显著的趋势正在显现：Draft Model（草稿模型）正在变得越来越大。 这一变化引发了一系列资源分配的矛盾，也促使我们重新思考推理架构的设计。本文将探讨一种新的架构思路——将 Speculator 从 Target Model 中分离出去，构建“Speculator as a Service”。 一、矛盾：为何要将 Speculator “请”出去？ 在传统的推测式解码架构中，Draft Model 和 Target Model 通常部署在同一个推理实例甚至同一个 GPU 上。这在早期 Draft Model 极小时（如极小的 GPT 或 ngram 模型）是合理的。但现在的趋势发生了变化： Draft Model 变大带来的收益递增：为了追求更高的接受率和更长的平均接受长度，业界倾向于使用能力更强、参数量更大的 Draft Model。 算力资源的“零和博弈”：GPU 的算力是有限的。如果 Draft Mode...

本文基于 Tiny-FSDP 项目源码整理。该项目用极简的 PyTorch 代码同时实现了 DDP、ZeRO-3、FSDP 三种分布式策略，是把大模型分布式训练「拆开看」的绝佳教材。我借它准备大模型 Infra 岗面试，把 FSDP 的每一个关键点都讲透。 一、为什么需要 FSDP：从 DDP 的显存瓶颈说起 https://zhuanlan.zhihu.com/p/694288870 https://zhuanlan.zhihu.com/p/2010127853522540210 面试时第一个常问的问题就是：「DDP 为什么训不动大模型？」 1.1 DDP 的显存模型 DDP（Distributed Data Parallel）是最朴素的数据并行：每张卡上都有一份完整的模型参数 + 梯度 + 优化器状态，只是各卡处理不同的数据 batch，反向传播后用 all-reduce 把梯度同步一致。 对于一个有 PPP 个参数的模型、NNN 张卡，每张卡的显存占用是： 显存项 DDP 每卡占用 参数（FP16 + FP32 master） ≈6P\approx 6P≈...

apis 仓库的 proto→Go gRPC 代码生成流程 本文以 apis 仓库（gitlab.infini-ai.com/mizar/apis）真实代码为例，讲清从一份 .proto 一路生成到 Go gRPC 代码的完整流程：protoc 工具链、各 protoc-gen-* 插件、go_package/module= 如何决定落地路径、grpc-gateway 怎么把 HTTP 反代到 gRPC、CI 怎么守门保证生成物与 proto 同步。 读完你能回答"protoc 和 protoc-gen-go 是什么关系"“一份 proto 怎么同时产出消息结构/gRPC stub/HTTP 网关/校验/深拷贝/mock”“为什么 CI 跑 make generate && git diff 能卡住没同步的提交”。 一、apis 仓库的定位：proto 作为 single source of truth apis 是一个多服务 API 定义仓库——所有对外的 RPC/HTTP 接口、消息结构、字段校验，都以 pb/<group>...

容器里的 PID 1 与僵尸进程——dumb-init / tini / k8s pause 全解 本文把"容器里 PID 1 为什么是个问题、僵尸进程怎么来的、dumb-init/tini 怎么兜、k8s pause 和 shareProcessNamespace 怎么协作"一次讲清。读完你能回答面试官"为什么容器里 Python/Java 当 PID 1 会漏僵尸"“dumb-init 和 tini 干了什么”"k8s pause 容器是不是 PID 1"“shareProcessNamespace 开不开有啥区别”。 前置：fork/exec/wait、僵尸 vs 孤儿的基础见本人《操作系统接口》篇。本文只讲容器场景。 一、僵尸进程快速回顾（容器视角） 子进程 exit 后内核不能立刻释放 task_struct——父进程可能要查退出码，于是子进程留一个"僵尸"状态（Z）：代码/数据/堆栈都释放了，只剩 task_struct 和退出码等父进程 wait 收尸。父进程 wait/waitp...

insmod 实操指南——从写一个内核模块到加载运行 本文讲清 insmod：它干什么、内核模块（.ko）是什么、insmod 与 modprobe 的区别、模块签名这个最常见的坑，并给一个可直接照抄跑通的 hello world 模块从编写→编译→加载→验证→卸载全流程。 前置：ring0/ring3、内核态概念见本人《x86 体系结构基础》篇。内核模块就是跑在 ring0、和内核同地址空间的代码。 一、insmod 是什么、内核模块又是什么 **内核模块（Loadable Kernel Module, LKM）**是一段可动态加载到内核地址空间、跑在 ring0 的代码，扩展内核功能而不需重启、不需重编内核。文件后缀 .ko（kernel object）。典型用途：设备驱动、文件系统、网络协议、安全 hook（如 alcor-chaos 的 libnvml-hijack/libixml-hijack 就是劫持库的内核态配合件）。 insmod（insert module）是用户态命令，把一个 .ko 文件加载进内核。它本质是调一次 init_module(2) / fi...

PaaS 平台 GPU 资源复用与超卖技术深度解析 目录 背景与动机 技术架构概览 核心技术实现 自定义Container Runtime实现容器间GPU共享 ShadowPod与虚拟设备实现Pod级GPU复用 Steal GPU动态超卖机制 多GPU类型适配 关键数据结构 核心代码解析 模拟面试问答 背景与动机 业务需求 在PaaS平台的实际运营中，我们遇到了两类核心问题： 用户侧需求： 推理服务实例资源利用率低：部分推理服务只占用1卡资源，但存在浪费 开发机资源紧张：租户内资源有限，多用户开发机需要共享GPU 平台侧需求： 提升集群资源利用率 对已分配但空闲的GPU进行超卖 增加平台收入和毛利率 技术选型 经过对市场现有方案的调研： 方案类型 代表方案 局限性 厂商官方解决方案 Nvidia MIG、MPS、vGPU 授权成本高；场景局限；不便于整合不同厂商 API劫持隔离方案 vCUDA、OrionX、cGPU 侵入业务层；开发维护难度大；存在性能损失 轻量调度共享方案 gpushare-device-plugin 依赖调度逻辑变更...

PaaS 平台 GPU 资源复用与超卖探索 背景&动机 PaaS平台用户使用上的需求： 部分推理服务的实例占用的资源较少，即使只占用1卡也存在浪费，因此希望将多个推理服务的实例部署到同一个GPU上，从而节约成本。 由于租户内资源有限，往往只有一两个节点，但有十几个用户的开发机。因此希望支持多个用户的开发机共用一个节点的GPU。 PaaS平台侧从提高集群利用率、增加收入和毛利率的角度出发，也存在下面的需求： 通过对未分配/已分配空闲GPU超卖进一步增加收入 在节点GPU资源全部调度分配后，以CPU任务的方式继续超卖节点的CPU和内存资源 为了满足用户需求，需要支持GPU复用功能，吸引用户使用平台，同时为了提升集群资源利用率和毛利率，需要进一步探索闲时复用方案，对于已经售卖但处于空闲状态的资源进行超卖。 本文将介绍PaaS侧在解决上面的问题过程中，在GPU资源的复用与超卖方面的一些探索。所谓复用或者超卖，都建立在把同一个GPU同时分配给多个实例的基础上，属于一种GPU共享技术。 GPU共享一般是指在多个用户或应用程序之间共享GPU资源的技术。这种技术通过虚拟化、...

LLM Agent 安全——攻击面、代表性论文与防御体系 本文是 LLM Agent 安全方向的论文调研综述。目标：让你在面试时能讲清"agent 安全和纯 LLM 安全有什么本质区别"“indirect prompt injection 为什么是 agent 的头号威胁”“instruction hierarchy / spotlighting / sandbox 这些防御各自的边界在哪”“为什么 prompt injection 至今没有银弹”。 内容基于公开论文与 OWASP LLM Top 10 等。每节标注代表性论文，便于顺藤摸瓜深读。 一、为什么 Agent 安全是全新量级的问题 纯 LLM（聊天机器人）最坏也就"说了不该说的话"。Agent 不一样：它会调工具、读写文件、发邮件、花钱、改系统。攻击面从"文本输出"扩到"真实世界副作用"，量级跳升。 Agent 和纯 LLM 安全的三点本质差异： 有动作、有副作用：Agent 拿着 API key、shell、浏览器、信用卡。一次被...

MCP 安全与 Prompt Injection 攻防实战 本文是《LLM Agent 安全》篇的补充实战篇，聚焦两个最该会落地的子题：MCP（Model Context Protocol）生态的 tool poisoning 风险与防护、以及 Prompt Injection 的真实 payload 案例 + 防御代码级落地（Spotlighting / Instruction Hierarchy / 参数校验 / human-in-the-loop）。读完你能回答"MCP 工具描述怎么藏毒"“Rug pulling 是什么”“spotlighting 代码怎么写”“为什么 base64 编码也能防一阵”。 前置：攻击面分类、indirect PI、无银弹根因见《LLM Agent 安全》篇。本文不重复理论，只讲实战形态与落地。 一、MCP 为什么是新的高危攻击面 MCP（Model Context Protocol）让 agent 能像装浏览器扩展一样接外部工具/数据源——stdio、HTTP、SSE 本地或远程 server 暴露 tools/...