面向当前 AI Infra 学习任务的 Python 最小知识集：从对象绑定、类型注解和工程结构，到 NumPy Shape、view/copy、broadcasting、Benchmark 与 asyncio。
~/blog
文章
在 Apple M5 Pro 上运行 Qwen3-4B，拆分 Prefill 与 Decode 延迟，排查 Prompt Cache 污染和 vLLM Metal 安装故障，并留下可复现脚本、CSV、日志与验收结果。
阶段 1 的 AI Infra 学习产出：从一条看似简单的推理请求出发，理解 tokenizer、scheduler、prefill、KV Cache、decode、streaming 与 Serving 指标，并用本地实践验证这套心智模型。
生活中会遇到各种各样的问题，教会我正确解法（做法）的人很多，因为他们做过，那么遇到从未遇到过的问题该怎么解答？从算法解题、投机解码、NP 问题和实践论出发，思考候选答案是如何被提出、验证并不断更正的。
之前做过 15445 Bustub、6.s081 xv6 这类项目，其实已经接触过构建工具了。 比如在 xv6 里经常执行： 在 Bustub 里经常执行： 但如果只是照着项目文档跑命令，很容易形成一种感觉： 我会用这些命令，但不知道它们到底在帮我做什么。 这篇文章想系统学习一下现代 C++ 项目的构建工具，重点...
背景 前面已经学习了几组基础： 这些内容已经覆盖了一个 KV Cache 系统的很多核心问题： 接下来要学习的是调度和负载均衡。 调度解决的问题是： 负载均衡解决的问题是： 在普通 Web 服务里，负载均衡可能只是把请求均匀打到多台机器。但在训练-推理一体存储和 KV Cache 场景里，调度要复杂得多。 因为请...
背景 前面已经学习了几组基础： 这些内容更偏系统正确性：对象状态要清楚，远程调用要可靠，副本要一致，故障后要能恢复。 接下来进入更贴近 KV Cache 工作内容的一组：缓存策略、迁移与淘汰。 KV Cache 系统的核心矛盾是： 所以系统必须不断做决策： 这篇文章的目标是：理解 KV Cache / Block...
背景 前面已经学习了几组基础： 这些内容让我们能理解： 接下来要学习的是故障处理。 分布式系统和单机系统最大的区别之一是：故障是常态，不是例外。 在单机程序里，一个函数失败可能直接返回错误；但在分布式系统里，故障往往是不完整、不确定、局部发生的。例如： 这篇文章的目标是：理解分布式系统里会发生哪些故障，以及 KV...
背景 前面已经学习了几组基础： 这些内容解决了几个问题： 接下来要学习的是副本和一致性。 在分布式系统里，数据通常不会只放一份。只放一份会有明显问题： 所以系统会把数据复制到多个节点，这就是副本。 但副本一旦出现，就会带来另一个问题： 对 KV Cache 和 BlockGroup 来说，这个问题尤其重要。因为...
背景 前面学习了两组基础： 这两组解决的是底层问题：系统为什么会慢、远程调用为什么会失败、为什么接口要考虑 timeout、retry 和幂等。 接下来这一组更贴近 KV Cache 系统本身： 之所以把这两组放在一起，是因为它们在真实系统里经常不能分开看。 以 BlockGroup 为例，它不仅是一组 KV C...
背景 学习分布式系统时，一个非常重要的转变是：不能再把函数调用理解成本地调用。 在单机程序里，调用一个函数通常是： 但在分布式系统里，调用另一个模块经常意味着通过网络访问另一台机器上的服务。这时一次“函数调用”会变成： 因此，远程调用不是本地调用。它更慢，也更容易失败。 对训练-推理一体存储和 KV Cache...
背景 学习分布式系统时，很容易一开始就看到 Raft、Paxos、CAP、一致性、分布式事务这些概念。但如果底层基础没有建立起来，这些概念会比较悬空。 对我现在的实习方向来说，组内工作内容和训练-推理一体存储、KV Cache 相关。这个场景里，分布式问题经常不是先表现为“算法问题”，而是先表现为： 这些问题背后...
背景 刚开始实习时，组内方向是训练-推理一体存储，尤其是围绕 KV Cache 做存储、调度、迁移或复用，那么“分布式”不是一个单独的理论章节，而是会贯穿在每一次请求、每一份缓存、每一次节点故障和每一个性能指标里。 我目前的目标不是一下子掌握所有分布式系统，而是先建立一张够用的地图： 这篇博客先从这些问题出发，总...
在 C++ 中，类型转换是一个很常见但也很容易写出隐患的知识点。对于初学者来说，最熟悉的可能是 C 风格强转： 但是在 C++ 项目中，更推荐使用 C++ 提供的四种显式类型转换： 它们分别表达不同的转换意图，比 C 风格强转更清晰，也更容易在代码审查和调试时发现问题。 本文会从 C 风格强转的问题开始，依次介绍...
C++ 线程库解决什么问题？ C++11 开始，标准库正式引入多线程支持，主要提供： 它解决的问题包括： C++ 线程库不是直接操作 Linux pthread，而是在标准层面提供了一套跨平台接口。
在理解了左值、右值和移动语义之后，继续学习一下完美转发，这些概念都看过很多次，但是每隔一段时间都会有一定遗忘，现在写下这篇文章记录一下这部分内容，方便下次复习。
1. HTTPS 加密过程解读 这是之前面试中遇到的问题，当时没有完全回答上来，暴露出我对 HTTPS 的理解还很不足，这篇文章记录一下我重新学习 HTTPS 协议的过程，方便复习和更好地理解。 HTTP 在传输数据的过程中，所有的数据都是明文传输，比如客户端向服务端发送了密码等信息，中间者可以很轻易地劫持。HT...
作为 xv6 的最后一个核心大实验，Lab 9 (mmap) 标着硬核的 "Hard" 难度。但从本质上讲，它其实是 Lab 3（缺页中断）和 Lab 8（文件系统）的融合。 mmap 和 munmap 系统调用允许 UNIX 程序对自己的地址空间进行极其细致的控制。通过将磁盘文件直接映射到内存中，程序可以像读写...
文件系统是操作系统中最复杂的组件之一，它需要管理磁盘块的分配、维护文件层级结构、处理并发访问，最重要的是：必须能够从系统崩溃中安全恢复。在这个 Lab 中，我们将深入 xv6 的文件系统内部，完成两个扩展任务：增加文件最大容量（支持大文件）以及实现软链接（Symbolic links）。 此 Lab 包含两个任务...
虽然锁能够解决多进程同步问题，但是多核计算机在高度锁竞争的情况下会出现这种并行性差的现象。在这个 Lab 中，将重新设计代码来提高并行性，涉及到修改数据结构和锁策略来减少争用。 此 Lab 包含两个任务，分别是修改内存分配和缓冲区缓存代码。
一个操作系统运行的进程可能比这个计算机的CPU数量多，因此操作系统需要规划如何在进程间共享CPU。理想状态下要让这个过程对于用户进程来说是透明的，让每个进程有一种自己单独拥有一个CPU的错觉。
在前几个lab中提到过COW（写时复制），比如fork一个进程后，子进程与父进程使用同样的指令和数据。如果每次都复制一份父进程的数据，在一些情况下子进程创建后调用exec，原本被复制的数据根本没有被使用过就被直接覆盖，在这种情况下就白白浪费了这次复制，并且复制也会有很大的开销，会拖慢系统执行的速度。 为了提高系统...
操作系统的一个重要功能是中断，用户进程通过trap机制让操作系统进行必要的工作。本次实验将探索系统调用是如何使用trap来实现。
页表是最流行的内存管理机制，操作系统通过页式管理可以为每个进程提供私有地址空间和内存，页表决定了内存地址的意义以及可访问的物理地址范围。 这样的机制使xv6能够隔离不同进程的地址空间和在简单物理内存中复用地址（虚拟地址相同物理地址不同）。 本次试验还会涉及到trampoline机制，这一部分我认为十分有趣。
Lab2 实现了两个系统调用层面的功能，在开始写代码之前要求先读完 xv6-book 的 Chapter 2 and Sections 4.3 and 4.4 of Chapter 4，以及相关的源文件，花了两天不到的时间。 做完这次实验可以深入理解 OS 的用户态、内核态的隔离，以及系统调用。
记录一下写 6.s081 Lab1 的过程，还有在这个实验中学到的新的知识。 这一次实验的内容为 Xv6 and Unix Utilities，实现一些基本 Unix 工具，通过这个过程了解 xv6 系统的结构，以及是如何运行的，建立对其的基本认识。