Sequence 02 - 从零学习到满足 JD + CV 要求
Top

Sequence 02 - 从零学习到满足 JD + CV 要求

这份路线适合“以前做过,但很多忘了”的状态。目标不是从零变专家,而是在短时间内恢复系统性理解、能讲项目、能回答深挖、能做实验。

1. 总学习地图

flowchart TB
    Start[从零恢复] --> Base[基础层]
    Base --> GPU[GPU/CUDA 层]
    Base --> AI[AI Serving 层]
    Base --> Net[Networking/Data Movement 层]
    GPU --> Profile[Profiling & Optimization]
    AI --> Runtime[Runtime / KV / Scheduling]
    Net --> Comm[NCCL / UCX / RDMA / NIXL]
    Profile --> Architect[System Architecture]
    Runtime --> Architect
    Comm --> Architect
    Architect --> Interview[项目讲解 + Q&A + Scenario]

2. 学习阶段

Stage 1:先恢复系统工程语言

你要先能讲这些词,不然 JD 后面的技术都讲不深:

概念 必须理解到什么程度
latency / throughput / P99 平均值不够,tail latency 决定服务体验。
bottleneck / critical path 不要凭感觉优化,要先找关键路径。
queueing / backpressure 高并发系统里请求排队和反压如何造成尾延迟。
memory bandwidth / copy / DMA 很多 GPU/network 瓶颈不是算力,而是数据搬运。
profiling 先 timeline,再局部细节;先证据,再优化。
prototype 先假设、基线、microbenchmark,再端到端验证。

最小输出:

我会把任何性能问题先拆成:
请求路径 -> 队列 -> compute -> memory/copy -> network/communication -> synchronization -> tail latency。

Stage 2:AI inference/model serving

学习顺序:

flowchart LR
    Req[Request] --> Queue[Queueing]
    Queue --> Tokenize[Tokenization]
    Tokenize --> Schedule[Scheduler]
    Schedule --> Prefill[Prefill]
    Prefill --> KV[KV Cache Allocation]
    KV --> Decode[Decode Loop]
    Decode --> Stream[Streaming Output]

必须掌握:

主题 学习目标
Prefill 输入 prompt 一次性计算,生成 KV cache。长 prompt 会拉高 TTFT。
Decode 逐 token 生成,反复读 KV cache。影响 TPOT。
TTFT Time To First Token,受排队、调度、prefill、KV allocation 影响。
TPOT Time Per Output Token,主要看 decode loop、KV 访问、collectives。
P99 tail latency,受队列、batching、干扰、资源饱和影响。
KV cache inference state,长上下文和高并发时是显存和数据移动问题。
Continuous batching 提高 GPU 利用率,但可能影响公平性和 P99。

学完能回答:

A serving request is not just a model call. I would break it into queueing, tokenization, scheduling, prefill, KV allocation, decode, and streaming. TTFT usually reflects queueing and prefill; TPOT reflects decode efficiency; P99 reflects saturation, batching, and tail behavior.

Stage 3:CUDA/GPU profiling

学习顺序:

flowchart TB
    CUDA[CUDA Basics] --> Exec[thread/block/grid/warp]
    Exec --> Memory[global/shared/pinned memory]
    Memory --> Pattern[coalescing/tiling/copy overlap]
    Pattern --> Metrics[memory-bound vs compute-bound]
    Metrics --> Tools[Nsight Systems vs Nsight Compute]

必须掌握:

主题 学习目标
CUDA kernel CPU launch,GPU 执行。
warp NVIDIA 常见 32 threads lockstep 执行。
coalescing 相邻线程访问连续地址,提高 memory transaction 效率。
shared memory block 内 on-chip memory,用于 tiling 和 data reuse。
pinned memory page-locked host memory,更适合 DMA 和 async copy。
stream/event 异步队列和计时/同步机制。
Nsight Systems 看端到端 timeline。
Nsight Compute 看单 kernel 内部瓶颈。

学完能回答:

I start with Nsight Systems to locate the end-to-end critical path. If a kernel dominates, I use Nsight Compute to inspect memory throughput, occupancy, warp stalls, instruction mix, and shared-memory behavior.

Stage 4:NCCL/parallelism

学习顺序:

flowchart TB
    Collective[Collective Communication] --> AR[All-Reduce]
    Collective --> AG[All-Gather]
    Collective --> RS[Reduce-Scatter]
    AR --> DP[Data Parallel]
    AG --> TP[Tensor Parallel]
    RS --> FSDP[FSDP / ZeRO]
    TP --> Debug[Slow communication debug]
    DP --> Debug
    FSDP --> Debug

必须掌握:

主题 学习目标
rank / world size 分布式通信参与者和总规模。
all-reduce 每个 rank 输入,聚合后每个 rank 得到结果。
all-gather 收集所有 rank 的分片。
reduce-scatter reduce 后分片发回各 rank。
algbw / busbw nccl-tests 输出中的算法带宽和总线带宽。
small vs large message 小消息看 latency/overhead,大消息看 bandwidth/topology。

学完能回答:

I would not assume slow all-reduce is an NCCL bug. I would first check message size, rank mapping, topology, selected transport, and whether the issue reproduces in nccl-tests.

Stage 5:UCX/RDMA/GPUDirect/NIXL/GPUNetIO

学习顺序:

flowchart TB
    TCP[TCP CPU-staged path] --> RDMA[RDMA]
    RDMA --> UCX[UCX transport abstraction]
    RDMA --> GDR[GPUDirect RDMA]
    UCX --> NIXL[NIXL inference data movement]
    GDR --> GPUNetIO[GPUNetIO GPU-centric networking]
    NIXL --> Serving[Prefill/Decode/KV movement]
    GPUNetIO --> Packet[GPU participates in packet/data path]

必须掌握:

技术 学习目标
RDMA RNIC 直接访问 registered memory,减少 CPU/kernel involvement。
RoCE 在 Ethernet 上跑 RDMA,需要 lossless/congestion 配置。
UCX 抽象 TCP/RDMA/shared memory/CUDA-aware path。
GPUDirect RDMA NIC 直接访问 GPU memory,需要硬件/driver/topology/fabric 支持。
NIXL inference data/state movement,典型是 KV cache/state transfer。
GPUNetIO GPU-centric networking,适合 GPU 直接消费网络数据的场景。

学完能回答:

UCX is a transport abstraction. NIXL is more tied to inference state movement, such as KV transfer. NCCL is for collectives. GPUDirect RDMA is a data path where RNIC can directly access GPU memory. GPUNetIO goes further toward GPU-centric packet/data processing.

3. 7 天恢复计划

主题 输出
Day 1 JD/CV 匹配 + 项目梳理 能讲 3 个核心项目,每个 3 分钟。
Day 2 AI serving 画 serving request path,回答 TTFT/TPOT/P99。
Day 3 CUDA/Nsight 跑或读 CUDA memory/pinned copy 实验,能解释指标。
Day 4 NCCL/parallelism 讲 all-reduce、DP/TP/FSDP,读 nccl-tests 输出。
Day 5 UCX/RDMA/GPUDirect 画 TCP/RDMA/GDR path,准备 slow-path checklist。
Day 6 NIXL/GPUNetIO/Dynamo 讲清与 NCCL/UCX 的区别,准备边界回答。
Day 7 Mock Q&A 按 sequence-06 逐题口述。

4. 最小合格标准

你至少要做到:

1. 每个 CV 项目能讲:背景、架构、你做什么、瓶颈、指标、复盘。
2. 每个 JD 技术能讲:是什么、解决什么问题、怎么 debug。
3. CUDA/vLLM/NCCL/UCX 至少有一个实验或实验设计。
4. 对没有生产经验的技术,能说清学习路径和验证方法。
Top