HAMi 源码导读
跟着一个 Pod，走完它从 kubectl apply 到在 GPU 上跑起来的全过程。
为什么需要一条主线
HAMi 的代码量不大，核心逻辑只有几千行。难的是它由三个独立进程组成：
调度器扩展器、设备插件、容器里的 CUDA 劫持库。
主链路主要靠 Kubernetes 注解里的字符串传话；NUMA refit 是一个例外，
设备插件会直接请求调度器的 /refit 接口。
单独读任何一个组件，都会卡在「这个值是谁写进来的」。 所以这里的顺序不按目录结构走，而是按一个 Pod 实际经过的路径走。
limits: nvidia.com/gpu: 1, nvidia.com/gpumem: 3000schedulerName 改成 hami-scheduler，补默认值，拦非法请求CUDA_DEVICE_MEMORY_LIMIT_0=3000m，挂载 libvgpu.so，释放节点锁cuMemAlloc，超过 3000MB 返回 OOM；算力用令牌桶限速目录
怎么读
每章的结构固定：先给一张源码地图，然后按执行顺序拆关键函数， 中间穿插可以直接操作的模拟器。 学习目标是可勾选的，勾完自动记进度，存在浏览器本地。
核心逻辑大多是纯内存函数，不需要 GPU，也不需要 Kubernetes 集群。
在 Linux 或 WSL2 下，打分、Fit 筛选、注解编解码都能用 go test 直接跑。
项目自带的表驱动用例（score_test.go 有 4600 行）比任何文档都完整，
改一个输入跑一次，比读十遍代码快。
建议按顺序读。第 01、02、05 章是主干，后面反复要用； 第 09、10 章第一遍看懂原理就行，等真要改那块时再回来。
所有 GitHub 链接和 文件:行号 引用都指向 commit
347502f（2026-09-03），
上游后续改动不会让链接跳错行。本地对照时先 git checkout 347502f。
换版本只需改 assets/js/site.js 顶部的 SOURCE，
换版本后行号会漂移，需要重新校对。