Roger-Lv's space

一句话结论：所谓「推理调度」，不是一个调度器，而是五层彼此看不见的决策。每一层能做什么，完全由它能看见什么信息决定——把决策放错层，不是效果差一点，而是根本做不成。 K8s 调度器只看得见整数设备：它知道「还剩几张卡」，不知道每张卡的 KV Cache 水位、队列深度、模型是否加载完； Gang 层保证多卡模型「一起上车」，但它读不到 PodGroup 的调度结果； 拓扑层约束落点，而 GPU 互联的约束（TP 整除、MIG 不可跨实例通信）是硬约束，不是偏好； 路由器是唯一能看见「请求」的一层——公共前缀、活动请求数、队列深度只有它知道； 引擎内部再决定请求进哪个 batch，这一层 K8s 完全看不见。 这篇是一次「责任边界」的梳理。主线是一次推理请求穿过五层调度器时，每一层的可见性与决策权；对照组是 Kthena（Volcano 子项目，v1.0）的源码——它的每一层都做了明确取舍，恰好把边界照了出来。 同时，近期有一篇流传较广的公众号文章《从部署 vLLM 到 AI 基础设施：Kubernetes 推理平台生产级落地、容量设计与性能优化》，整体框架（容量、调度、弹...

在一套兼容的 NVIDIA 环境里，部署一个大模型可能只需要一条命令： 123vllm serve /models/Qwen \ --tensor-parallel-size 1 \ --max-model-len 32768 换到国产 GPU 上，同样的模型、同样的 Python 代码，却可能遇到一长串看似互不相关的问题：PyTorch 认不出设备；权重能加载但执行 Attention 时异常退出；BF16 正常而 FP8 不被支持；单卡能跑但 Tensor Parallel 起不来；能出字但速度远低于预期；短上下文正常而长上下文 OOM；CUDA Graph、投机解码、MoE 这些优化全部不可用。 这些问题指向同一个根源：大模型推理并不直接跑在 GPU 硬件上，而是跑在一整套软硬件协同的执行体系上。 换一张卡，换掉的是整条链路。 一、模型不认识 GPU 以 Transformer 为例，无论 Qwen、DeepSeek 还是 GLM，模型首先描述的是一组数学计算——线性变换 Y=XWY = XWY=XW、注意力 softmax(QKT/d)V\mathrm{sof...

这份试卷流传得挺广。它的定位很明确：不考概念背诵，而是把你直接扔进万卡集群的线上事故现场。题目质量整体在线——很多题干描述的现象（GPU 满载 100% 却无输出、单卡 OOM 引发连锁雪崩、Xid 静默故障）确实是生产里真实会遇到的东西。 但做下来发现一个问题：有 12 处题干前提站不住。有些是命名错误（DualPipe-V2 不存在），有些是职责错配（把节点健康探测的活儿算到调度器头上），还有些是版本演进导致的自然过时——最典型的是题目按 DeepSeek-V2/V3 的 MLA 配置（潜变量 512 + 解耦 RoPE 64）给 DeepSeek-V4 出题，可 V4 已经不用 MLA 了。 所以本文分两部分：先逐题给答案与解析，再把 12 处勘误集中列出。答案都尽量追到一手来源（NVIDIA 官方文档、PyTorch / vLLM 源码、Linux 内核定义、模型官方 config.json），而不是靠印象作答。 一、题目勘误汇总（先看这个） 先集中列出题干本身的问题，避免读者照着错前提记结论。 # 位置 问题 正确表述 1 判断 2 称 NCCL_DEB...

推理服务最常见的崩溃形态是这样的：系统平稳运行了很久，突然因为一条长文本请求 CUDA OOM，整个实例挂掉。 直觉上会去怪权重太大或 KV Cache 爆了。但权重是启动时就固定的，KV Cache 有 PagedAttention 分页管理、增长是缓坡——它们都不解释「瞬间」这两个字。 真正的元凶是第三类显存：中间激活张量。 一、显存的三类「性格」 把推理时的 GPU 显存按行为特征分成三类，很多 OOM 问题会立刻变得清楚： 类型 内容 增长方式 管理手段 常驻水位 模型权重 启动即固定，不随负载变 量化、张量并行 线性累积 KV Cache 随 token 数 O(S)O(S)O(S) 缓坡上涨 PagedAttention 分页、前缀缓存、KV 量化 瞬时峰值 中间激活张量 单步内 O(S)O(S)O(S) 甚至 O(S2)O(S^2)O(S2) 尖峰 Chunked Prefill、FlashAttention 中间激活张量指的是前向计算过程中、每层算子之间临时产生并立即消费的那部分张量。它们既不是常驻显存的权重，也不是需要长期保留的 KV...

一句话结论：GPU 在容器里的可见性，不是由 --gpus 或 --device 这一层的写法决定的，而是由最外层那一次分配定死的——下游每一层都只能在集合内部重分配，一张也变不出来。 三条推论： rootless 影响的不是 request/limit 生效（那发生在宿主机的 kubelet / device plugin 进程里），而是运行时能不能把设备节点塞进去； privileged 与 device 是两条正交的轴，且 privileged 的默认行为是连设备一起给你——「门全开但屋里没东西」必须靠显式 opt-out 才能达成； dind 里 --gpus all 的 all 永远是局部 all——它能重分配外层给它的集合，但一张也变不出来。 这篇是《容器运行时拆解·补篇》的续篇。原篇把 runc create 之后的世界切成四个侧面——权限、记账、I/O、退出；这篇顺着同一条责任链往下走，聚焦读者最常追问的三个场景。 本文路线 全文分四段，可以按需跳读： 段落 章节 回答什么 ① 原理 一 ~ 六 三个时刻怎么切；privileged 与 de...

一句话结论：从 IOMMU（硬件地址翻译与 DMA 隔离）→ VFIO（设备直通框架）→ SR-IOV（PCIe 级切分）→ MIG（硅片级硬切分）→ vGPU（软件时间片调度）这条链路，构成了 GPU 虚拟化的完整技术栈。「IOMMU 划边界、VFIO 做移交」这条直通链路，是所有 GPU 沙盒和具身仿真基础设施绕不开的地基。 本文按「技术原理 → 两大落地场景 → 一个真实落地案例 → 决策树」四层展开，并把各技术支持的功能以表格汇总。 所有技术描述核对自 Linux 内核文档、NVIDIA 官方文档、Intel/AMD 官方文档与各项目仓库。核对中发现原稿有二十余处需要更正，其中三处是实质性错误，已在文中以 ⚠️ 标注。 一、技术原理层：从 IOMMU 到 vGPU 1.1 IOMMU：硬件级安全边界 IOMMU 是提供地址翻译与设备隔离的硬件单元：对设备发出的 DMA 做 IOVA → HPA 翻译与访问保护，并提供中断重映射；隔离以 IOMMU group 为粒度。Intel 侧叫 VT-d，AMD 侧叫 AMD-Vi。 Linux VFIO 内核文档原文： ...

一句话结论：Ubuntu 镜像里根本没有内核。 它不是一个「完整的 Linux 系统」，只是一份 rootfs——打包好的用户态二进制和库文件。容器里的进程发起的每一个 syscall 都直接打到宿主机内核上，namespace 只是给进程一个「看起来像独立系统」的视图，不是真的给它装了一个内核。 而 Kata 和 Firecracker 之所以「有自己的内核」，是因为它们在容器外多加了一层 VM，VM 里需要一份 guest kernel 来承载上面的容器——整个链路里只发生了一次虚拟化，不是嵌套。 本文的机制描述与实测数据核对自 Docker Registry 实际镜像内容、Linux 内核文档与 man pages、glibc 与 kmod 源码、Kata Containers 与 Firecracker 官方文档。核对中发现原稿有十余处需要更正，其中一处是流传很广的机制错误，已在文中以 ⚠️ 标注。 一、把「Linux 系统」拆开看：内核和用户态是两件事 日常说「Ubuntu 22.04」这个概念，其实打包了两个完全独立的东西： 组成部分 具体内容 来源 放在...

从微信记录到蒸馏自己：蒸馏工作流全教程 1. Target 本文是关于从MAC/Windows电脑上通过各种使用痕迹（尤其是微信）蒸馏出自己完整人格/习惯的教程 你可以直接让claude code读这个网页链接，让它告诉你该怎么一步步操作，包括后续如果遇到问题也可以问claude code 2. Process 其中微信提取聊天记录这部分网上的相关工具基本上已经下架（🐧的法务你是知道的） 需要用到的工具包括： claude code / codex等本地Agent工具 用于提取微信聊天记录的工具： weflow未删减版：用于获取密钥（这个网盘中有对应教程，这个网盘随时可能会删） 点击链接：https://pan.baidu.com/s/1UUr-w-a2taGbQKDDon0hzQ 提取码：sqhh 这一步如果顺利是可以拿到聊天记录的，就不用考虑2.2这一步了；如果在最后一步有问题，记得把提取出来的密钥保存下来，后续2.2 有用 另外网上也有其他教程，可以自己探索下如何拿到密钥 https://github.com/Roger-Lv/wechat-extract...

一句话结论：重庆不是我的退路，是我的解馋点。这两件事我花了很久才分清。 一、卤鹅 2025 年 4 月，我老家荣昌突然出名了。 起因是一个被叫作「卤鹅哥」的人，追着来中国的外国网红投喂卤鹅。事情本身很荒诞，效果很实在——那阵子荣昌的卤鹅店销量翻了 4000%，五一还没到我就在猜人流量要爆。 我当时在外地。看到消息的第一反应不是自豪，是困惑。因为我发现自己跟卤鹅哥是小学校友。这条信息对我没有任何用处，但那天我盯着屏幕看了很久。 荣昌是个什么样的地方？在 2025 年之前，它的名片是猪。荣昌猪，中国三大地方猪种之一，我从小听这个词听到麻木。卤鹅当然也吃，但说实话，我从来没觉得它是我们那儿最值得说出口的东西——因为它太不家常了。家常的是猪油、是腊肉、是外婆坛子里的东西。卤鹅是要专门去买的，是逢年过节、有人从老家来、或者自己馋得受不了的时候，才会想起来的那一类。 结果它火了。 那之后我每次回家，行李箱里都要塞两只。北京的朋友吃过一次之后开始点名要。我后来总结出一句：提个卤鹅堪比偷渡——真空包装、冰袋、泡沫箱，过安检的时候总觉得会有人拦我。 二、解馋 我给重庆下过一个很刻薄的判断：重庆...

一句话结论：把 RoCEv2 网络配成无损只是让集群「能跑起来」，真正吃掉算力的在后面——几万张卡在几个月里不停地出故障、掉速、Hang 住，而你要在没有用户配合、看不到业务代码的情况下，判断这一次的锅是硬件、是网络还是调度。 这篇给一套可执行的方法：四个监控平面分工排查、五类故障定性定位、RoCE 三种典型病的判据、三板斧的调优顺序，最后落一份巡检清单。 开场先看一个真实场景。 某集群上一个 2048 卡预训练任务，MFU 长期在 38% 上下波动。团队查了两周网络：PFC 计数正常、ECN 标记率正常、交换机上零丢包、ib_write_bw 端到端带宽也达标。 最后在 DCGM 的 SM Clock 指标上发现问题——256 台机器里有一台的 8 张卡，SM 时钟长期跑在 1.1GHz，其他机器都是 1.9GHz。这台机器是慢节点，它在每一个 AllReduce 里拖后腿，整条 ring 都要等它。换掉之后 MFU 回到 45%，而且不再波动。 这类问题在交换机上永远查不到，因为网络侧所有计数都是干净的。 边界说明：文中命令以 NVIDIA DCGM 与 nvidia-...