不以学过多少概念衡量进度，而以系统能否运行、指标能否测量、实验能否复现、结论能否解释衡量进度。
这是一份学习承诺和实验设计，而不是成果汇报。我目前没有完成过类似的 AI Infra 实验，但愿意用半年时间，把陌生的系统问题拆成一个个可以验证的小问题。
我计划从 2026 年 12 月 28 日开始系统学习 AI Infra。第一阶段暂定到 2027 年 3 月 31 日，共 94 天；如果项目值得继续，完整路线将延长到 24 周。
第一阶段每天计划投入 4 小时学习和实践 AI Infra、4 小时进行算法训练，并且每周至少完成一个可以验收的技术结果。按照日历计算，这相当于约 752 小时的总计划，强度接近一份全职工作。
01为什么选择 AI Infra
第一次看到完整的 AI Infra 学习路线 时，我最直接的感受不是清晰，而是庞大。
从 Linux、Python、PyTorch，到 CUDA、算子优化、分布式训练、推理服务、模型压缩、性能分析，几乎每个方向都能继续展开成一条独立路线。如果把路线图当作一张必须从头到尾刷完的课程表，半年时间很可能只够不断“入门”，却做不出一个完整成果。
把路线图当作地图和词典，而不是线性教材。
我的目标不是在短时间内成为“全栈 AI Infra 工程师”，而是选择一个足够窄、能够运行实验、又能继续深入研究的问题。在这个问题的牵引下，缺什么就学什么。
02为什么聚焦 LLM 推理资源与安全
我希望自己的入门方向能够兼顾三个条件：
- 能在个人或有限算力条件下缩小规模完成；
- 同时体现系统、网络安全和实验能力；
- 与我感兴趣的研究团队近期方向存在连接。
清华大学网络研究院李琦老师的官方介绍将其研究领域概括为“互联网和网络安全、人工智能驱动的网络安全与人工智能安全”。这意味着，仅仅部署一个模型接口还不够；如果能围绕推理服务中的资源、可用性和安全问题展开，项目会有更明确的研究意味。
其中，Engorgio 工作给了我一个具体切入口。它研究如何通过特定提示词增加自回归大模型的推理成本和输出长度，从而影响服务可用性。这个问题把大模型、推理系统、GPU 资源、服务质量和安全威胁连接到了一起。
与此同时，vLLM 和 PagedAttention 提供了一个现实的推理系统实验平台。PagedAttention 关注动态增长的 KV cache 如何造成内存浪费，以及怎样用类似操作系统分页的方式提高内存利用率和服务吞吐。对初学者来说，这是一个很好的系统切入口：它既包含模型机制，也包含内存管理、调度、批处理和服务指标。
项目：InferGuard
InferGuard: Measuring Resource Abuse and Compute-Aware Admission Control for LLM Inference Services
中文暂定为：面向大语言模型推理服务的资源滥用测量与计算感知准入控制。
项目代码目前保存在私人仓库：github.com/Triwoods2333/inferguard
03我究竟想研究什么
InferGuard 的核心问题不是“怎样攻击一个模型”，而是：
当不同请求消耗的推理资源差异很大时，如何正确测量这种差异，量化它对正常用户的影响，并设计比简单请求限流更合理的保护策略？
我暂时提出三个可以被实验验证或推翻的假设。
假设一：相同请求速率不代表相同计算成本
两个用户每秒都发送一个请求，但输入长度、生成预算和实际输出长度可能完全不同。只按照“每秒请求数”限流，无法准确描述 GPU 计算和 KV cache 压力。
假设二：接近饱和时，高成本请求会放大尾延迟
高成本请求未必在任何负载下都会伤害其他用户。真正值得测量的是：在什么并发、到达率和请求混合比例下，正常请求的 P95 或 P99 延迟开始显著恶化。
假设三：可解释的计算感知策略可能优于请求限流
如果根据输入长度、生成预算和历史成本对请求进行粗粒度估计，再实施计算预算、队列隔离或配额控制，可能在相近的正常用户代价下取得更好的保护效果。
04需要测量哪些指标
为了让项目不沦为“凭感觉调参数”，我会优先建立统一的测量口径。
| 指标 | 含义 | 我希望回答的问题 |
|---|---|---|
| TTFT | Time to First Token，首个 Token 延迟 | 请求排队和 Prefill 是否变慢 |
| TPOT | Time per Output Token，单个输出 Token 时间 | Decode 阶段是否受到资源竞争 |
| Throughput | 每秒完成的请求数或 Token 数 | 系统整体处理能力如何变化 |
| P50/P95/P99 | 延迟分位数 | 平均表现和尾部用户体验是否同时恶化 |
| GPU Memory | GPU 显存占用 | KV cache 和批处理是否接近容量边界 |
| GPU Utilization | GPU 利用率 | 系统是否进入持续饱和 |
| Queue Length | 等待队列长度 | 延迟增长是否来自排队 |
| Rejection Rate | 被拒绝请求比例 | 防御是否只是把问题变成大量拒绝 |
所有图表都应该能够从原始 CSV 或结构化日志重新生成，而不是只保留截图。
0513 周冲刺：完成第一个研究闭环
从 2026 年 12 月 28 日至 2027 年 3 月 31 日，目标不是完成整个 AI Infra 知识体系，而是得到一个可以演示、可以解释、可以重复的项目闭环。
W1—W4：基础与推理服务基线
前四周解决两个问题：Transformer 推理为什么会消耗这些资源，以及我采集的指标是否可靠。
- 补齐 Linux、Python、PyTorch、Git 和基本容器知识；
- 手写简化版 Attention 和 Decoder Block；
- 理解 MHA、GQA、RMSNorm、RoPE 和 KV cache；
- 估算参数量、激活、KV cache 和计算量；
- 使用 PyTorch Profiler 观察算子和 CPU/GPU 活动；
- 部署 0.5B—3B 的小模型服务；
- 建立并发请求生成器；
- 测量 TTFT、TPOT、吞吐和延迟分位数；
- 比较串行、批处理和不同并发配置。
验收标准不是“看完多少视频”，而是在固定版本和参数下，能够连续三次运行同一组基准实验，并解释主要指标为什么变化。
W5—W7：威胁建模、机制复现与干扰量化
这一阶段将阅读 Engorgio，并把论文问题缩小到个人条件可以完成的实验规模。
- 明确攻击者能力、正常用户、保护资产和成功指标；
- 区分输入长度、输出预算、实际生成长度、请求速率和并发；
- 构造正常请求和受控的高成本请求；
- 比较单独运行与混合运行的资源表现；
- 扫描高成本请求比例、并发和到达率；
- 记录正常请求的 P95/P99、吞吐下降和拒绝率；
- 至少重复三次关键实验，保留异常点和负结果。
这一阶段最重要的交付物是一条可信的实验结论：高成本请求在什么条件下造成了多大影响，以及为什么。
W8—W10：防御基线与计算感知策略
在证明问题存在之后，我会先实现简单防御：
max_tokens限制；- 输入长度限制；
- 请求超时；
- 请求速率限制；
- 并发限制。
然后实现 InferGuard 的核心原型：
- 根据输入长度、生成预算和历史测量估计请求成本；
- 为用户或租户分配 Token/Compute Budget；
- 将普通请求和高风险请求放入不同队列；
- 尝试简单的加权公平或配额策略。
核心比较是：在正常用户代价相近的条件下，Compute-Aware Policy 是否优于简单 Rate Limit？
W10 将冻结主要变量，完成参数扫描、重复实验、敏感性分析和组件消融。每个结论都必须有对照组，所有图都必须可以由脚本从原始数据重建。
W11—W13：网络视角、工程封装与成果展示
如果主实验已经稳定，我会加入一个受控的网络视角：
- 记录请求流、突发、租户和队列遥测；
- 学习 PCAP、Flow、Burst 等网络流量表示；
- 阅读 TrafficFormer 和 TrafficLLM；
- 可选实现一个小型的 PCAP → Flow → Burst 预处理管线。
这里最重要的原则是：扩展不能稀释主项目。 在 2027 年 3 月 31 日之前不会尝试完整的多卡 TrafficFormer 预训练，最多进行代码阅读、Checkpoint 推理或小规模微调。
最后两周将集中完成：
- 项目目录和依赖整理；
- 一键运行和一键绘图脚本；
- 数据字典与实验配置；
- README 和技术报告；
- 3—5 分钟备份演示视频；
- 10 页以内的项目汇报 Slides；
- 1 分钟和 5 分钟两套项目介绍；
- 两轮模拟问答与 Demo 故障演练。
2027 年 3 月 29 日至 31 日只用于复测、备份和状态恢复，不再增加新功能。
06后 11 周：把路线延伸到 24 周
如果前三个月的主项目值得继续，后 11 周将依次展开。
W14—W16：深入推理调度
- 阅读 vLLM 请求生命周期；
- 理解 Scheduler、Block Manager 和 Metrics；
- 加入必要的 Instrumentation；
- 学习公平队列、Backpressure、Preemption 和 SLA；
- 将准入规则扩展成真正的调度策略原型。
W17—W19：流量基础模型
- 建立 PCAP → Flow → Burst → Token 的数据管线；
- 阅读 TrafficFormer 数据表示和代码；
- 使用已有 Checkpoint 做推理；
- 在小数据集上进行单卡微调；
- 研究低标签和跨域条件下的泛化能力。
W20—W22：可编程网络数据面
- 学习 P4/eBPF 和 Match-Action Pipeline；
- 理解寄存器、Sketch 和线速处理约束；
- 阅读 NetBeacon 与 Brain-on-Switch；
- 尝试简化模拟器或最小数据面 Demo；
- 形成“网络入口 → 准入 → 推理 → 遥测 → 反馈”的端到端设计。
W23—W24：研究提案与成果化
- 整理 Related Work；
- 明确现有方法的 Gap；
- 把系统现象转化为可证伪的研究假设；
- 补充关键消融实验；
- 完成 4—6 页研究提案；
- 尝试提交 Issue、PR 或可复现开源包。
07每天八小时怎样安排
AI Infra：4 小时
- 1 小时：理论、文档或论文；
- 2 小时：代码实现；
- 0.5 小时：测量、调试或数据检查；
- 0.5 小时：实验日志与结果解释。
算法训练：4 小时
- 0.5 小时：错题回看；
- 1 小时：概念和模板；
- 2 小时：独立编码或限时训练；
- 0.5 小时：复盘复杂度、边界和错误模式。
算法路线大致为：
| 周次 | 主题 |
|---|---|
| W1—W3 | 数组、字符串、哈希、链表、栈队列、二分、双指针、滑动窗口 |
| W4—W6 | 树、堆、图搜索、并查集、拓扑排序、贪心、前缀和与区间 |
| W7—W10 | 动态规划、最短路、最小生成树、回溯、位运算、数论与模拟 |
| W11—W13 | 综合限时题、完整计时训练、错题回炉与稳定输出流程 |
周日仍然保留计划时间，但不再堆新概念，而是用于重跑实验、整理文档、错题回炉和周测，降低频繁切换造成的消耗。
08给项目设置三级终点
为了避免“没有完成全部计划就等于失败”，InferGuard 设置三个成果等级。
保底版本
- 小模型推理服务能够运行；
- Workload Generator 能够控制并发和长度；
- TTFT、TPOT、吞吐、尾延迟和显存指标完整；
- 实现至少三种简单限制策略；
- 有 README、图表和演示程序。
标准版本
- 完成资源滥用机制级复现；
- 量化正常请求受到的影响；
- 实现 Compute-Aware Admission Control；
- 有公平的基线、重复实验和消融；
- 陌生人能够按照文档复现最小结果。
挑战版本
- 修改或扩展 vLLM Scheduler；
- 加入公平队列和多租户隔离；
- 完成 TrafficFormer 小规模微调；
- 探索 P4 或数据面智能；
- 形成研究提案或开源贡献。
2027 年 3 月 31 日之前只强制要求完成保底版本，并尽量争取标准版本。挑战版本失败不会影响主项目成立。
09最大风险不是技术，而是范围失控
这个计划最大的风险并不是“我现在没有经验”，而是同时学习过多方向。因此，我给自己设定以下规则：
- 主实验不稳定，不启动 TrafficFormer 和 P4 扩展；
- 不从头训练大模型；
- 不同时学习 CUDA Kernel、编译器和分布式训练；
- 连续三天完成率低于 70%，先缩小实验矩阵和算法题量；
- 先保证可重复，再追求更漂亮的性能数字；
- 报告负结果和失败案例，不只挑选最好看的曲线；
- 所有攻击性负载只能在自有或明确授权环境中运行；
- W12 以后冻结架构，只修影响演示和结论的关键问题。
如果没有 NVIDIA GPU，我会先完成 CPU、模拟器、数据处理和测量框架，再短时使用租用或实验室 GPU 运行核心实验。硬件规模必须写进报告，结论不能超过实际实验能够支持的范围。
10如何让这份计划持续提醒我
我已经为项目建立了私人 GitHub 仓库，并准备通过以下方式记录进度：
docs/progress-log.md：记录每周结果；docs/decisions/：记录重要范围和方法决策；- GitHub Weekly Progress Issue：记录验收目标、证据和阻塞；
experiments/configs/：保存实验配置；plans/：保存 24 周和每日计划表；- Commit：证明代码、实验和文档确实发生过变化。
每周复盘只回答七个问题：
- 本周原本要交付什么？
- 实际完成了什么？
- 证据在哪里？
- 哪个指标发生了变化？
- 什么失败了？
- 是否需要缩小范围？
- 下周唯一的验收目标是什么？
11结语
我现在还没有做过这类实验，也无法保证计划会完全按照表格执行。但这并不妨碍我先做出一个可验证的承诺：
不以“学过多少概念”衡量进度，而以“能否运行、能否测量、能否复现、能否解释”衡量进度。
如果 24 周之后，我最终只完成了一个规模不大的推理服务实验，但能够清楚解释 Transformer 推理资源、KV cache、连续批处理、尾延迟、威胁模型、对照实验和策略取舍，那么这段学习就是成功的。
这篇文章也会持续更新。等项目真正开始后，我希望它不再只是一份路线图，而能逐渐变成一份诚实的实验记录。