NVIDIA AI/GPU Networking 面试两天冲刺作战手册

岗位：System Software Architect, AI and GPU Networking
面试时间：2026-06-15 20:00-22:00 GMT+8
当前目标：用 2 天周末把 JD 技术要求恢复到“面试可深挖、能画图、能 debug、最好有实战证据”的状态。

0. 这份文档怎么用

你要的不是“CV 包装文档”，而是：

1. JD 要求什么技能。
2. 你 CV 里有什么对应证据。
3. 哪些是真匹配，哪些是短板。
4. 面试会问哪些技术问题。
5. 面试官顺着每个技能点会怎么继续深挖。
6. 每个深挖点需要什么实验、代码、benchmark 或架构图作为证据。
7. 到什么程度才算“掌握”，不是只知道概念。

这份文档不要按“任务数量”读。正确读法是：

先看 JD 技能点。
再看你 CV 里能接上的证据。
然后准备这个技能点下的追问链。
最后才做对应的延展任务/实验。

也就是说，任务不是主线。任务只是为了支撑面试回答的证据。

这里的“2 天完全掌握”定义为面试验收标准：

• 能画出核心 data path / control path。
• 能解释关键机制，不只是背定义。
• 能回答二级、三级追问。
• 能给出 debug checklist。
• 至少对 CUDA/NCCL/LLM serving 做出可运行实验或完整实验设计。
• 对 RDMA/UCX/GPUNetIO 这种需要硬件环境的内容，能说明真实搭建方法、可观测指标、失败时怎么排查。

现实边界：

• 2 天内不可能真正成为 UCX/NIXL/GPUNetIO 内核专家。
• 但可以达到这个岗位首轮技术面试需要的“系统架构级掌握”：知道每层解决什么问题、数据怎么走、哪里会慢、怎么验证。

当前准备环境：

• 你现在有一台 Windows GPU 机器，这是本次准备的主环境。
• Windows 原生负责：NVIDIA driver、CUDA Toolkit、Nsight Systems / Nsight Compute GUI、CUDA Samples。
• WSL2 Ubuntu 负责：Linux CUDA CLI、Python/vLLM、UCX/NCCL 工具、接近 NVIDIA AI infra 的 Linux 工作流。
• 没有 RDMA/RoCE/NVIDIA NIC/DOCA 环境时，不硬装 GPUNetIO；这部分用架构图、实验设计、debug checklist 补齐。

推荐目录：

learning-cuda/
  NVIDIA_Interview_Master_Plan_Deep_CN.md
  labs/
    llm_serving/
    cuda_profiling/
    nccl_tests/
    ucx_rdma_notes/
    diagrams/

1. JD 技能要求总表：JD 要什么、你有什么、怎么补

1.0 主索引：按 JD 技能点组织，而不是按任务组织

你现在复习时应该把每个技能点当成一条面试主线：

flowchart LR
    JD[JD 技能要求] --> CV[CV 里的对应证据]
    CV --> Match[匹配点和短板]
    Match --> Q[面试官会问什么]
    Q --> Deep[二级/三级追问]
    Deep --> Evidence[需要什么证据]
    Evidence --> Task[延展任务/实验/图]

下面这张表是全篇文档的主入口。
后面的 CUDA/vLLM/NCCL/UCX 实验都只是这张表最后一列的证据来源。

如果时间不够，只按这个优先级准备：

P0:
  AI inference/model serving
  CUDA/Nsight/GPU performance
  NCCL/collectives
  UCX/RDMA/GPUDirect

P1:
  Dynamo/NIXL
  GPUNetIO
  System architecture/prototype

P2:
  GR00T/Physical AI
  ROCm/Metal/MPS/Vulkan/WebGPU 对照

1.0.1 每个技能点应该怎么复习

每个技能点都按同一个模板准备，不要先陷入实验细节：

1. JD 原话是什么？
2. 这个技能在系统里解决什么问题？
3. 我 CV 里哪段经历可以接上？
4. 我不能夸大的边界是什么？
5. 面试官第一问是什么？
6. 面试官第二层会追到哪里？
7. 如果给一个故障场景，我怎么 debug？
8. 我有什么实验/图/benchmark 能支撑？
9. 我最后怎么用英文 60-90 秒回答？

对应到文档：

1.0.2 面试追问树：问题是主线，任务是延展

下面这些是你真正要准备的“问题链”。
每条问题链最后才对应实验、代码或图。

A. AI inference / model serving

flowchart TB
    A[LLM request path 是什么] --> B[prefill 和 decode 区别]
    B --> C[TTFT / TPOT / P99 分别代表什么]
    C --> D[TTFT 高怎么 debug]
    C --> E[TPOT 高怎么 debug]
    C --> F[P99 高怎么 debug]
    D --> G[queueing / scheduler / prefill / KV allocation]
    E --> H[decode loop / KV cache / memory bandwidth / collectives]
    F --> I[batching / admission control / tail latency]
    G --> J[延展: vLLM benchmark]
    H --> J
    I --> J

你要形成的回答能力：

我不是只知道 vLLM 这个名字。
我能把 serving 请求拆成阶段，并把每个指标映射到具体瓶颈。
如果 TTFT/TPOT/P99 异常，我知道先看什么、后看什么。

B. Dynamo / NIXL

flowchart TB
    A[Dynamo 是什么] --> B[为什么 distributed inference 需要 orchestration]
    B --> C[NIXL 是什么]
    C --> D[为什么 inference state movement 和 collective 不一样]
    D --> E[NIXL vs NCCL]
    D --> F[KV cache movement]
    F --> G[transfer slow 怎么 debug]
    G --> H[延展: KV movement data path / NIXL lifecycle]

你要形成的回答能力：

NIXL 不是 NCCL 的替代品。
NIXL 更像 inference data/state movement layer。
典型场景是 prefill/decode disaggregation 或 KV cache transfer。

C. NCCL / collectives / parallelism

flowchart TB
    A[NCCL 是什么] --> B[collective 是什么]
    B --> C[all-reduce / all-gather / reduce-scatter]
    C --> D[DP / TP / PP / FSDP 分别用什么通信]
    C --> E[small message vs large message]
    E --> F[latency-bound vs bandwidth-bound]
    D --> G[slow all-reduce 怎么定位]
    F --> G
    G --> H[rank mapping / topology / transport / NCCL_DEBUG]
    H --> I[延展: nccl-tests all_reduce_perf]

你要形成的回答能力：

我不会把所有通信慢都说成 NCCL bug。
我会先看 message size、rank、topology、transport、是否能用 nccl-tests 复现。

D. RDMA / RoCE / UCX / GPUDirect

flowchart TB
    A[传统 TCP path 为什么慢] --> B[RDMA 是什么]
    B --> C[为什么需要 registered memory]
    C --> D[QP / CQ / MR 是什么]
    B --> E[RoCE 为什么难]
    B --> F[UCX 是什么]
    F --> G[UCX transport 怎么选]
    B --> H[GPUDirect RDMA 是什么]
    H --> I[GPU-NIC direct path 需要什么条件]
    G --> J[UCX/RDMA 慢怎么 debug]
    I --> J
    J --> K[延展: ucx_info / data path 图 / slow-path checklist]

你要形成的回答能力：

我能画清楚 CPU-staged TCP path、RDMA path、GPUDirect RDMA path。
我也能诚实说明本机没有 RDMA/NIC/DOCA 时不能验证什么。

E. GPUNetIO

flowchart TB
    A[GPUNetIO 是什么] --> B[它和 GPUDirect RDMA 区别是什么]
    B --> C[为什么要 GPU-centric networking]
    C --> D[什么时候值得用]
    D --> E[什么时候不值得用]
    C --> F[代价和风险是什么]
    F --> G[debug 难点是什么]
    G --> H[延展: CPU-centric vs GPU-centric path 图]

你要形成的回答能力：

GPUNetIO 不是所有网络问题的默认答案。
只有当 CPU-mediated networking 成为关键路径，并且 GPU 直接消费网络数据时，它才可能值得考虑。

F. CUDA / Nsight / GPU performance

flowchart TB
    A[CUDA execution model] --> B[thread / block / grid / warp]
    B --> C[memory hierarchy]
    C --> D[global / shared / pinned memory]
    D --> E[coalescing / tiling / copy overlap]
    E --> F[memory-bound vs compute-bound]
    F --> G[Nsight Systems vs Nsight Compute]
    G --> H[GPU utilization 低怎么定位]
    H --> I[延展: CUDA memory / matmul / pinned copy 实验]

你要形成的回答能力：

我先用 Nsight Systems 找 critical path。
再用 Nsight Compute 看具体 kernel 的 memory、occupancy、stall、instruction 指标。

G. System architecture / prototype

flowchart TB
    A[给一个优化方向] --> B[先定义 hypothesis]
    B --> C[找 baseline]
    C --> D[做 microbenchmark]
    D --> E[做最小 prototype]
    E --> F[接入 end-to-end workload]
    F --> G[看 TTFT / TPOT / P99 / throughput / cost]
    G --> H[决定是否进 roadmap]

你要形成的回答能力：

Architect 不是只会说概念。
我会把优化假设、验证指标、风险、fallback、维护成本一起放进判断。

1.1 这个岗位到底按 C++ 还是 Python 准备？

按 JD 原文判断，不是二选一。JD 写的是：

Strong programming background in C++, Python, and ideally CUDA or other GPU programming models.

所以结论是：

语言要求：C++ 和 Python 都要。
面试主战场：C++ / CUDA / Linux systems。
实验和自动化工具：Python / Bash。
加分项：CUDA 或其他 GPU programming models。

为什么不是“只准备 Python”：

• 这是 System Software Architect, AI and GPU Networking，不是普通 Python AI application engineer。
• JD 关注 runtime systems、communication libraries、GPU networking、data movement、prototype、performance optimization。
• UCX、NCCL、GPUNetIO、CUDA、RDMA 这些底层栈主要是 C/C++/CUDA/Linux 语境。
• JD 同时要求 AI frameworks，所以 Python 也重要，但它更偏 PyTorch/vLLM/JAX/TensorFlow 集成、benchmark、实验 orchestration、数据分析和自动化。

为什么也不能说“只要 C++”：

• JD 明确写了 Python。
• AI framework 生态主要靠 Python 暴露接口。
• vLLM、PyTorch、benchmark scripts、实验数据分析会大量用 Python。
• Architect 面试会看你能不能快速 prototype，而 Python 是最快的验证工具。

你面试中要表现出的语言层次：

按面试准备优先级排序：

1. C++/CUDA/Linux systems：最高优先级，因为这是岗位底层技术可信度。
2. Python：必须会，用来跑 AI framework、vLLM benchmark、自动化实验。
3. Bash/Linux tooling：必须会，用来串起 nvidia-smi、nsys、ncu、nccl-tests、ucx_info。

准备优先级：

flowchart TB
    Role[JD Role: System Software Architect AI/GPU Networking]
    Role --> Core[C++ / CUDA / Linux Systems]
    Role --> Support[Python / Bash Tooling]
    Core --> CUDAExp[CUDA Memory / Kernel Profiling]
    Core --> Comm[NCCL / UCX / RDMA Concepts]
    Core --> Runtime[Runtime / Data Movement Design]
    Support --> VLLM[vLLM Serving Benchmark]
    Support --> Automation[Benchmark Automation]
    Support --> Analysis[Result Parsing / Plotting]

你应该这样回答语言问题：

The JD asks for both C++ and Python, ideally with CUDA or another GPU programming model. I would position myself as a systems engineer who can work in C++/CUDA/Linux for performance-critical runtime and communication paths, while using Python for AI framework integration, serving benchmarks, experiment orchestration, and analysis.

如果面试官问你更强的是 C++ 还是 Python，建议回答：

My production background includes both C++ and Python, but for this NVIDIA role I would emphasize systems-level C++ experience, performance-sensitive code paths, and my ability to use Python/Bash to build fast benchmark and diagnostic workflows. I would not present myself as only a Python ML application engineer.

你这两天的代码准备也按这个分工：

• C++/CUDA：至少准备/跑一个 CUDA memory access 或 copy benchmark。
• Python：跑或设计 vLLM benchmark，整理 TTFT/TPOT/P99。
• Bash：记录环境、运行命令、组织 labs/ 输出。

1.2 CUDA 对应的 AMD / macOS 技术怎么理解

JD 主线是 NVIDIA，所以面试准备仍然以 CUDA / NCCL / UCX / GPUDirect / GPUNetIO 为主。
但你有 Vulkan/WebGPU、跨平台 GPU/graphics 经验，可以用 AMD/macOS 技术做类比，证明你理解的是 GPU computing 的共性，而不是只背 CUDA 名词。

核心原则：

面试主语言：CUDA / NVIDIA stack。
迁移类比：AMD ROCm/HIP、Apple Metal/MPS、Vulkan/WebGPU。
不要把 AMD/macOS 讲成这个岗位主技术栈。

技术映射表：

怎么在面试里使用这段经验：

My hands-on GPU experience includes Vulkan/WebGPU-style profiling and GPU workload analysis. I understand that CUDA is the primary stack for this NVIDIA role, so I use those experiences as transferable mental models: GPU execution hierarchy, memory locality, async command execution, profiling timelines, and bottleneck isolation. I would still validate NVIDIA-specific behavior with CUDA, Nsight Systems, Nsight Compute, NCCL, and UCX.

如果面试官问“你不是 CUDA production，很大问题吗？”，可以这样答：

I would be explicit that my production GPU-adjacent work is not CUDA-kernel production ownership. The transferable part is my understanding of GPU workload behavior, profiling, memory/resource trade-offs, and systems debugging. For this role, I am closing the NVIDIA-specific gap by running CUDA/Nsight experiments and mapping my Vulkan/WebGPU mental model to CUDA execution, memory hierarchy, and profiling tools.

两天内的学习优先级：

1. 先用 CUDA/Nsight 跑实验，因为这是 NVIDIA 面试主线。
2. AMD/macOS 只作为对照理解，不花时间搭 ROCm/Metal 环境。
3. 面试里只在被问到“你过去 GPU 经验怎么相关”时讲 AMD/macOS/Vulkan/WebGPU 类比。
4. 讲完类比后立刻落回 NVIDIA：CUDA、Nsight、NCCL、UCX、GPUDirect。

2. 证据实验库：为 JD/CV 追问准备可验证材料

这一章不是新的主线目录，也不是让你机械完成一堆学生作业。
它的作用只有一个：当面试官顺着 JD/CV 技能点追问时，你能拿出“我跑过/我知道怎么跑/我知道怎么看结果”的证据。

所以这一章应该这样使用：

先回到第 1 章，确定当前技能点。
再判断面试官可能追问什么。
最后只做能支撑这个追问的实验。

阅读顺序应该是：

flowchart LR
    A[JD 技能点] --> B[CV 对应证据]
    B --> C[面试追问]
    C --> D[选择实验]
    D --> E[跑代码/看指标]
    E --> F[形成回答证据]
    F --> G[回到 Q&A]

实验优先级：

2.1 你的环境分工：Windows 原生 + WSL2 Ubuntu

flowchart TB
    Win[Windows GPU Machine]
    Native[Windows Native]
    WSL[WSL2 Ubuntu]

    Native --> Driver[NVIDIA Driver / nvidia-smi]
    Native --> CUDAWin[CUDA Toolkit for Windows]
    Native --> NsightGUI[Nsight Systems / Nsight Compute GUI]
    Native --> Samples[CUDA Samples / Visual Studio]

    WSL --> LinuxCUDA[Linux CUDA CLI]
    WSL --> Python[vLLM / Python Benchmarks]
    WSL --> NCCL[NCCL Tests if Available]
    WSL --> UCX[UCX Tools if Available]

推荐优先级：

1. 先确认 Windows 原生 nvidia-smi、nvcc、Nsight 可用。
2. 再确认 WSL2 Ubuntu 里 nvidia-smi 可用。
3. 如果 WSL2 能看到 GPU，后续 vLLM/NCCL/UCX 尽量放 WSL2。
4. 如果 WSL2 暂时不可用，不要卡太久；CUDA/Nsight 先用 Windows 原生跑，Linux 生态内容写实验设计。

2.2 Windows 原生环境检查

在 PowerShell 里跑：

nvidia-smi
nvcc --version
python --version
where nsys
where ncu

你要记录：

Windows environment:
  GPU model:
  Driver version:
  CUDA version:
  Python version:
  Nsight Systems available: yes/no
  Nsight Compute available: yes/no

怎么看结果：

• nvidia-smi 能显示 GPU：driver OK。
• nvcc --version 能显示 CUDA：CUDA Toolkit OK。
• where nsys / where ncu 能找到路径：Nsight CLI 可用。
• 如果 Nsight CLI 找不到，但 GUI 已安装，也可以先用 GUI。

2.3 WSL2 Ubuntu 环境检查

在 WSL2 Ubuntu 里跑：

nvidia-smi
python3 --version
uname -a
which nvcc || true
which nsys || true
which ncu || true

你要记录：

WSL2 environment:
  nvidia-smi works: yes/no
  Python version:
  nvcc available: yes/no
  nsys available: yes/no
  ncu available: yes/no

怎么看结果：

• WSL2 中 nvidia-smi 能看到 GPU：可以跑 Linux CUDA/Python GPU workflow。
• WSL2 中没有 nvcc 但能看到 GPU：仍可跑部分 Python GPU workload，但 CUDA 编译实验需要安装 toolkit。
• WSL2 中看不到 GPU：vLLM/NCCL/UCX 实操会受限，先做 Windows CUDA/Nsight + Linux 实验设计。

2.4 环境检查结果怎么判断

不用先创建任何文档。你现在只需要看命令输出，并判断这台机器能跑什么。

最重要的是这四个结论：

最理想结果：

Windows:
  nvidia-smi works
  nvcc works
  Nsight Systems / Compute available

WSL2:
  nvidia-smi works
  python3 works
  optional: nvcc / nsys / ncu available

如果只有 Windows CUDA 可用，也够你完成最关键的 CUDA/Nsight 主线。
如果 WSL2 也能看到 GPU，再继续做 vLLM/NCCL/UCX。

2.5 任务链 1：CUDA / Nsight，证明你能做 GPU 性能定位

这不是孤立的 CUDA 入门练习。它对应 JD 的这些考察点：

• C++ / Python, ideally CUDA or other GPU programming models
• performance profiling and optimization
• defining and using hardware features
• design and prototype features and optimizations

也对应你 CV 里的这些点：

• Vulkan/WebGPU/GPU workload profiling。
• C++/Python/Linux。
• performance-sensitive path、bottleneck isolation、diagnostic tooling。

你要用这组任务证明三件事：

1. 我知道 GPU 程序慢在哪里要分层看。
2. 我会用 Nsight Systems 看全局 timeline。
3. 我会用 Nsight Compute 看 kernel 内部瓶颈。

任务结构：

flowchart TB
    JD[JD: CUDA or GPU programming + profiling + hardware features]
    CV[CV: Vulkan/WebGPU profiling + C++/Python/Linux + bottleneck isolation]
    Goal[Goal: prove GPU performance debugging ability]

    JD --> Goal
    CV --> Goal

    Goal --> T1[Task 1: Memory Access Pattern]
    Goal --> T2[Task 2: Shared Memory Tiling]
    Goal --> T3[Task 3: Host-Device Transfer]
    Goal --> T4[Task 4: Nsight Workflow]

    T1 --> M1[Metrics: kernel time, bandwidth, load efficiency, stalls]
    T2 --> M2[Metrics: occupancy, shared memory, global load/store]
    T3 --> M3[Metrics: H2D/D2H time, overlap, sync gaps]
    T4 --> M4[Metrics: timeline, CUDA API, kernel detail]

    M1 --> Q1[追问: coalescing / memory-bound / layout]
    M2 --> Q2[追问: shared memory / occupancy / bank conflict]
    M3 --> Q3[追问: pinned memory / DMA / stream overlap]
    M4 --> Q4[追问: Systems vs Compute / critical path]

    Q1 --> Evidence[面试证据: I can locate GPU bottlenecks by measurement]
    Q2 --> Evidence
    Q3 --> Evidence
    Q4 --> Evidence

2.5.0 这组任务里的技术词汇是什么

2.5.1 任务 1：coalesced vs uncoalesced memory access

任务说明：

你要知道是什么：

• GPU global memory 访问不是“每个 thread 随便读都一样快”。
• 相邻 thread 访问连续地址时，硬件可以合并 memory transaction，带宽更高。
• stride/random/uncoalesced access 会造成更多 memory transaction，吞吐下降。

实际怎么跑：

代码文件：memory_access.cu

#include <cuda_runtime.h>
#include <cstdio>
#include <cstdlib>

#define CHECK_CUDA(call) do {                                      \
    cudaError_t err = (call);                                      \
    if (err != cudaSuccess) {                                      \
        std::fprintf(stderr, "CUDA error %s:%d: %s\n",             \
                     __FILE__, __LINE__, cudaGetErrorString(err)); \
        std::exit(1);                                              \
    }                                                             \
} while (0)

__global__ void coalesced_copy(const float* __restrict__ in,
                               float* __restrict__ out,
                               int n) {
    int i = blockIdx.x * blockDim.x + threadIdx.x;
    if (i < n) {
        out[i] = in[i];
    }
}

__global__ void strided_copy(const float* __restrict__ in,
                             float* __restrict__ out,
                             int n,
                             int stride) {
    int i = blockIdx.x * blockDim.x + threadIdx.x;
    if (i < n) {
        int idx = (i * stride) % n;
        out[i] = in[idx];
    }
}

float run_coalesced(const float* d_in,
                    float* d_out,
                    int n,
                    int blocks,
                    int threads,
                    int repeat) {
    cudaEvent_t start, stop;
    CHECK_CUDA(cudaEventCreate(&start));
    CHECK_CUDA(cudaEventCreate(&stop));
    CHECK_CUDA(cudaEventRecord(start));
    for (int r = 0; r < repeat; ++r) {
        coalesced_copy<<<blocks, threads>>>(d_in, d_out, n);
    }
    CHECK_CUDA(cudaEventRecord(stop));
    CHECK_CUDA(cudaEventSynchronize(stop));
    CHECK_CUDA(cudaGetLastError());
    float ms = 0.0f;
    CHECK_CUDA(cudaEventElapsedTime(&ms, start, stop));
    CHECK_CUDA(cudaEventDestroy(start));
    CHECK_CUDA(cudaEventDestroy(stop));
    return ms / repeat;
}

float run_strided(const float* d_in,
                  float* d_out,
                  int n,
                  int blocks,
                  int threads,
                  int repeat,
                  int stride) {
    cudaEvent_t start, stop;
    CHECK_CUDA(cudaEventCreate(&start));
    CHECK_CUDA(cudaEventCreate(&stop));
    CHECK_CUDA(cudaEventRecord(start));
    for (int r = 0; r < repeat; ++r) {
        strided_copy<<<blocks, threads>>>(d_in, d_out, n, stride);
    }
    CHECK_CUDA(cudaEventRecord(stop));
    CHECK_CUDA(cudaEventSynchronize(stop));
    CHECK_CUDA(cudaGetLastError());
    float ms = 0.0f;
    CHECK_CUDA(cudaEventElapsedTime(&ms, start, stop));
    CHECK_CUDA(cudaEventDestroy(start));
    CHECK_CUDA(cudaEventDestroy(stop));
    return ms / repeat;
}

int main() {
    const int n = 1 << 26;          // 67M floats, about 256 MB
    const int repeat = 50;
    const int threads = 256;
    const int blocks = (n + threads - 1) / threads;
    const int stride = 32;
    const size_t bytes = size_t(n) * sizeof(float);

    float* h = static_cast<float*>(std::malloc(bytes));
    for (int i = 0; i < n; ++i) h[i] = float(i % 1024);

    float *d_in = nullptr, *d_out = nullptr;
    CHECK_CUDA(cudaMalloc(&d_in, bytes));
    CHECK_CUDA(cudaMalloc(&d_out, bytes));
    CHECK_CUDA(cudaMemcpy(d_in, h, bytes, cudaMemcpyHostToDevice));

    float coalesced_ms = run_coalesced(d_in, d_out, n, blocks, threads, repeat);
    float strided_ms = run_strided(d_in, d_out, n, blocks, threads, repeat, stride);

    double gb = double(bytes) / 1e9;
    std::printf("coalesced: %.3f ms, %.2f GB/s\n", coalesced_ms, gb / (coalesced_ms / 1000.0));
    std::printf("strided  : %.3f ms, %.2f GB/s, stride=%d\n", strided_ms, gb / (strided_ms / 1000.0), stride);

    CHECK_CUDA(cudaFree(d_in));
    CHECK_CUDA(cudaFree(d_out));
    std::free(h);
    return 0;
}

Windows PowerShell：

nvcc -O3 memory_access.cu -o memory_access.exe
.\memory_access.exe
ncu .\memory_access.exe

WSL2 Ubuntu：

nvcc -O3 memory_access.cu -o memory_access
./memory_access
ncu ./memory_access

程序里写两个 kernel：

kernel A:
  out[i] = in[i]
  连续访问，预期 coalesced。

kernel B:
  out[i] = in[i * stride]
  或通过 index table 做 scattered access，预期 uncoalesced。

固定变量：

数据大小相同。
block size 相同。
重复次数相同。
只改变 memory access pattern。

怎么看结果：

• coalesced 版本 kernel time 更低。
• effective bandwidth 更高。
• uncoalesced 版本可能出现更多 memory dependency / memory throttle。

怎么读 Nsight Compute：

• 看 memory throughput 是否接近硬件能力。
• 看 global load/store efficiency 或 memory transaction 相关指标。
• 看 warp stall reason 是否指向 memory dependency。
• 如果 SM compute utilization 不高但 memory stall 高，说明 memory-bound。

对方可能追问：

• 什么是 memory coalescing？
• 为什么 LLM/GPU networking 也关心 memory layout？
• 如果 GPU utilization 不高但 kernel 很慢，怎么判断是不是 memory-bound？

你可以这样回答：

Memory coalescing means adjacent threads access adjacent memory so the GPU can combine memory transactions. If access is strided or scattered, effective bandwidth drops. I would validate this with Nsight Compute by checking memory throughput, global load efficiency, and warp stall reasons. In inference or networking data paths, layout still matters because KV cache blocks, tensors, and network buffers all eventually become memory access patterns.

2.5.2 任务 2：naive matmul vs tiled shared-memory matmul

任务说明：

你要知道是什么：

• naive matmul 每次从 global memory 读大量重复数据。
• tiled matmul 把一块数据放进 shared memory，让一个 block 内的 threads 复用。
• 这体现了 GPU 优化的核心思想：提高 data reuse，减少 global memory traffic。

实际怎么跑：

代码文件：matmul_tiling.cu

#include <cuda_runtime.h>
#include <cstdio>
#include <cstdlib>
#include <cmath>

#define CHECK_CUDA(call) do {                                      \
    cudaError_t err = (call);                                      \
    if (err != cudaSuccess) {                                      \
        std::fprintf(stderr, "CUDA error %s:%d: %s\n",             \
                     __FILE__, __LINE__, cudaGetErrorString(err)); \
        std::exit(1);                                              \
    }                                                             \
} while (0)

constexpr int TILE = 16;

__global__ void matmul_naive(const float* A,
                             const float* B,
                             float* C,
                             int n) {
    int row = blockIdx.y * blockDim.y + threadIdx.y;
    int col = blockIdx.x * blockDim.x + threadIdx.x;
    if (row >= n || col >= n) return;

    float sum = 0.0f;
    for (int k = 0; k < n; ++k) {
        sum += A[row * n + k] * B[k * n + col];
    }
    C[row * n + col] = sum;
}

__global__ void matmul_tiled(const float* A,
                             const float* B,
                             float* C,
                             int n) {
    __shared__ float As[TILE][TILE];
    __shared__ float Bs[TILE][TILE];

    int row = blockIdx.y * TILE + threadIdx.y;
    int col = blockIdx.x * TILE + threadIdx.x;
    float sum = 0.0f;

    for (int t = 0; t < n; t += TILE) {
        int a_col = t + threadIdx.x;
        int b_row = t + threadIdx.y;

        As[threadIdx.y][threadIdx.x] =
            (row < n && a_col < n) ? A[row * n + a_col] : 0.0f;
        Bs[threadIdx.y][threadIdx.x] =
            (b_row < n && col < n) ? B[b_row * n + col] : 0.0f;

        __syncthreads();

        for (int k = 0; k < TILE; ++k) {
            sum += As[threadIdx.y][k] * Bs[k][threadIdx.x];
        }

        __syncthreads();
    }

    if (row < n && col < n) {
        C[row * n + col] = sum;
    }
}

float time_naive(const float* d_A,
                 const float* d_B,
                 float* d_C,
                 int n,
                 dim3 grid,
                 dim3 block,
                 int repeat) {
    cudaEvent_t start, stop;
    CHECK_CUDA(cudaEventCreate(&start));
    CHECK_CUDA(cudaEventCreate(&stop));
    CHECK_CUDA(cudaEventRecord(start));
    for (int r = 0; r < repeat; ++r) {
        matmul_naive<<<grid, block>>>(d_A, d_B, d_C, n);
    }
    CHECK_CUDA(cudaEventRecord(stop));
    CHECK_CUDA(cudaEventSynchronize(stop));
    CHECK_CUDA(cudaGetLastError());
    float ms = 0.0f;
    CHECK_CUDA(cudaEventElapsedTime(&ms, start, stop));
    CHECK_CUDA(cudaEventDestroy(start));
    CHECK_CUDA(cudaEventDestroy(stop));
    return ms / repeat;
}

float time_tiled(const float* d_A,
                 const float* d_B,
                 float* d_C,
                 int n,
                 dim3 grid,
                 dim3 block,
                 int repeat) {
    cudaEvent_t start, stop;
    CHECK_CUDA(cudaEventCreate(&start));
    CHECK_CUDA(cudaEventCreate(&stop));
    CHECK_CUDA(cudaEventRecord(start));
    for (int r = 0; r < repeat; ++r) {
        matmul_tiled<<<grid, block>>>(d_A, d_B, d_C, n);
    }
    CHECK_CUDA(cudaEventRecord(stop));
    CHECK_CUDA(cudaEventSynchronize(stop));
    CHECK_CUDA(cudaGetLastError());
    float ms = 0.0f;
    CHECK_CUDA(cudaEventElapsedTime(&ms, start, stop));
    CHECK_CUDA(cudaEventDestroy(start));
    CHECK_CUDA(cudaEventDestroy(stop));
    return ms / repeat;
}

int main() {
    const int n = 1024;
    const int repeat = 5;
    const size_t bytes = size_t(n) * n * sizeof(float);

    float* h_A = static_cast<float*>(std::malloc(bytes));
    float* h_B = static_cast<float*>(std::malloc(bytes));
    for (int i = 0; i < n * n; ++i) {
        h_A[i] = float((i % 13) - 6) / 13.0f;
        h_B[i] = float((i % 17) - 8) / 17.0f;
    }

    float *d_A = nullptr, *d_B = nullptr, *d_C = nullptr;
    CHECK_CUDA(cudaMalloc(&d_A, bytes));
    CHECK_CUDA(cudaMalloc(&d_B, bytes));
    CHECK_CUDA(cudaMalloc(&d_C, bytes));
    CHECK_CUDA(cudaMemcpy(d_A, h_A, bytes, cudaMemcpyHostToDevice));
    CHECK_CUDA(cudaMemcpy(d_B, h_B, bytes, cudaMemcpyHostToDevice));

    dim3 block(TILE, TILE);
    dim3 grid((n + TILE - 1) / TILE, (n + TILE - 1) / TILE);

    float naive_ms = time_naive(d_A, d_B, d_C, n, grid, block, repeat);
    float tiled_ms = time_tiled(d_A, d_B, d_C, n, grid, block, repeat);

    double flops = 2.0 * double(n) * double(n) * double(n);
    std::printf("N=%d\n", n);
    std::printf("naive: %.3f ms, %.2f GFLOP/s\n",
                naive_ms, flops / (naive_ms / 1000.0) / 1e9);
    std::printf("tiled: %.3f ms, %.2f GFLOP/s\n",
                tiled_ms, flops / (tiled_ms / 1000.0) / 1e9);

    CHECK_CUDA(cudaFree(d_A));
    CHECK_CUDA(cudaFree(d_B));
    CHECK_CUDA(cudaFree(d_C));
    std::free(h_A);
    std::free(h_B);
    return 0;
}

Windows PowerShell：

nvcc -O3 matmul_tiling.cu -o matmul_tiling.exe
.\matmul_tiling.exe
ncu .\matmul_tiling.exe

WSL2 Ubuntu：

nvcc -O3 matmul_tiling.cu -o matmul_tiling
./matmul_tiling
ncu ./matmul_tiling

写两个版本：

A:
  naive C = A x B
  直接从 global memory 读。

B:
  tiled C = A x B
  每个 block 把 tile 放入 shared memory，然后复用。

矩阵规模：

512x512 / 1024x1024 / 2048x2048
按你的 GPU 能力选择，先从小规模保证正确，再扩大。

测什么：

kernel time
achieved occupancy
shared memory usage
global memory load/store throughput
SM utilization

怎么看结果：

• tiled 版本通常更快，但 tile size 不一定越大越好。
• shared memory 用太多可能降低 occupancy。
• occupancy 高不代表一定快，要结合 memory throughput 和 stall reason 看。

怎么读 Nsight Compute：

• 如果 global memory load 明显下降，说明 tiling 起作用。
• 如果 shared memory 使用增加但 occupancy 大幅下降，要解释资源 trade-off。
• 如果 stall reason 指向 memory dependency，说明仍可能 memory-bound。
• 如果 compute pipeline utilization 高，才更接近 compute-bound。

对方可能追问：

• shared memory 为什么快？
• occupancy 是什么，为什么不是越高越好？
• bank conflict 是什么？
• 你怎么判断一个 kernel 是 memory-bound 还是 compute-bound？

你可以这样回答：

Shared memory is on-chip and much lower latency than global memory, so tiling can improve data reuse. But shared memory and registers are limited resources; using too much can reduce occupancy. I would not optimize for occupancy alone. I would check whether the kernel is memory-bound or compute-bound using Nsight Compute metrics such as memory throughput, SM utilization, and warp stall reasons.

2.5.3 任务 3：pageable vs pinned host-device copy

任务说明：

你要知道是什么：

• CPU host memory 默认通常是 pageable。
• GPU DMA 更喜欢 pinned/page-locked memory。
• pinned memory 可以提高 H2D/D2H copy 性能，也更适合 async copy 和 compute overlap。

实际怎么跑：

代码文件：h2d_copy.cu

#include <cuda_runtime.h>
#include <cstdio>
#include <cstdlib>

#define CHECK_CUDA(call) do {                                      \
    cudaError_t err = (call);                                      \
    if (err != cudaSuccess) {                                      \
        std::fprintf(stderr, "CUDA error %s:%d: %s\n",             \
                     __FILE__, __LINE__, cudaGetErrorString(err)); \
        std::exit(1);                                              \
    }                                                             \
} while (0)

float time_copy(void* dst,
                const void* src,
                size_t bytes,
                cudaMemcpyKind kind,
                cudaStream_t stream,
                int repeat) {
    cudaEvent_t start, stop;
    CHECK_CUDA(cudaEventCreate(&start));
    CHECK_CUDA(cudaEventCreate(&stop));
    CHECK_CUDA(cudaEventRecord(start, stream));
    for (int r = 0; r < repeat; ++r) {
        CHECK_CUDA(cudaMemcpyAsync(dst, src, bytes, kind, stream));
    }
    CHECK_CUDA(cudaEventRecord(stop, stream));
    CHECK_CUDA(cudaEventSynchronize(stop));
    float ms = 0.0f;
    CHECK_CUDA(cudaEventElapsedTime(&ms, start, stop));
    CHECK_CUDA(cudaEventDestroy(start));
    CHECK_CUDA(cudaEventDestroy(stop));
    return ms / repeat;
}

void init_buffer(float* p, int n) {
    for (int i = 0; i < n; ++i) {
        p[i] = float(i % 1024);
    }
}

int main() {
    const int n = 1 << 26;          // 67M floats, about 256 MB
    const int repeat = 20;
    const size_t bytes = size_t(n) * sizeof(float);

    float* pageable = static_cast<float*>(std::malloc(bytes));
    float* pinned = nullptr;
    float* d_buf = nullptr;

    CHECK_CUDA(cudaMallocHost(&pinned, bytes));
    CHECK_CUDA(cudaMalloc(&d_buf, bytes));
    init_buffer(pageable, n);
    init_buffer(pinned, n);

    cudaStream_t stream;
    CHECK_CUDA(cudaStreamCreate(&stream));

    float pageable_h2d = time_copy(d_buf, pageable, bytes, cudaMemcpyHostToDevice, stream, repeat);
    float pageable_d2h = time_copy(pageable, d_buf, bytes, cudaMemcpyDeviceToHost, stream, repeat);
    float pinned_h2d = time_copy(d_buf, pinned, bytes, cudaMemcpyHostToDevice, stream, repeat);
    float pinned_d2h = time_copy(pinned, d_buf, bytes, cudaMemcpyDeviceToHost, stream, repeat);

    double gb = double(bytes) / 1e9;
    std::printf("size: %.2f GB, repeat=%d\n", gb, repeat);
    std::printf("pageable H2D: %.3f ms, %.2f GB/s\n",
                pageable_h2d, gb / (pageable_h2d / 1000.0));
    std::printf("pageable D2H: %.3f ms, %.2f GB/s\n",
                pageable_d2h, gb / (pageable_d2h / 1000.0));
    std::printf("pinned   H2D: %.3f ms, %.2f GB/s\n",
                pinned_h2d, gb / (pinned_h2d / 1000.0));
    std::printf("pinned   D2H: %.3f ms, %.2f GB/s\n",
                pinned_d2h, gb / (pinned_d2h / 1000.0));

    CHECK_CUDA(cudaStreamDestroy(stream));
    CHECK_CUDA(cudaFree(d_buf));
    CHECK_CUDA(cudaFreeHost(pinned));
    std::free(pageable);
    return 0;
}

Windows PowerShell：

nvcc -O3 h2d_copy.cu -o h2d_copy.exe
.\h2d_copy.exe
nsys profile .\h2d_copy.exe

WSL2 Ubuntu：

nvcc -O3 h2d_copy.cu -o h2d_copy
./h2d_copy
nsys profile ./h2d_copy

写两个版本：

A:
  malloc/new 分配 host buffer
  cudaMemcpy 或 cudaMemcpyAsync

B:
  cudaHostAlloc 或 cudaMallocHost 分配 pinned host buffer
  cudaMemcpyAsync

可选 C:
  pinned memory + separate stream + kernel
  观察 copy 和 kernel 是否 overlap。

Nsight Systems 看什么：

• memcpy H2D/D2H 的时间。
• kernel 和 memcpy 是否重叠。
• 是否有不必要的 cudaDeviceSynchronize。
• CPU 是否在等待 GPU。

怎么读效果：

• pinned copy 通常更快，尤其是较大 buffer。
• 如果 async copy 没有 overlap，检查是否用了 pinned memory、是否用了不同 stream、是否有同步阻塞。
• 如果 timeline 上 GPU 有空洞，说明可能是 CPU launch/copy/sync 等待。

对方可能追问：

• pinned memory 为什么更适合 DMA？
• async copy 为什么有时没有 overlap？
• CUDA stream 和 event 是什么？
• data movement 为什么在 AI/GPU networking 岗位重要？

你可以这样回答：

Pinned memory avoids page migration during DMA and allows more efficient host-device transfers. For overlap, I need pinned memory, separate streams where appropriate, and no unnecessary global synchronization. This matters for AI/GPU networking because many bottlenecks are not pure compute; they come from data movement across CPU, GPU, NIC, and memory hierarchy.

2.5.4 任务 4：Nsight Systems vs Nsight Compute workflow

任务说明：

你要知道是什么：

Nsight Systems:
  看整个应用 timeline。
  解决 “时间花在哪里？”

Nsight Compute:
  看单个 CUDA kernel 细节。
  解决 “这个 kernel 为什么慢？”

实际怎么跑：

Windows PowerShell：

nsys profile .\your_cuda_program.exe
ncu .\your_cuda_program.exe

WSL2 Ubuntu：

nsys profile ./your_cuda_program
ncu ./your_cuda_program

Windows GUI 也可以：

Nsight Systems GUI:
  看 CPU thread、CUDA API、kernel launch、memcpy、stream、sync gap。

Nsight Compute GUI:
  看 selected kernel 的 occupancy、memory throughput、warp stalls、shared memory、instruction mix。

对方可能追问：

• 如果 P99 latency 高，你会先用 Systems 还是 Compute？
• 如果 GPU utilization 低，你怎么定位？
• 如果 kernel 很慢，你下一步看什么？

你可以这样回答：

I start with Nsight Systems because it shows the end-to-end timeline: CPU work, CUDA API calls, kernel launches, memory copies, stream synchronization, and idle gaps. If a specific kernel dominates, I switch to Nsight Compute to inspect occupancy, memory throughput, warp stalls, and instruction mix. This prevents optimizing a kernel that is not actually on the critical path.

2.5.5 这组任务最终要形成的面试证据

你不用夸大成 CUDA production owner。你要形成这个可信表述：

My production GPU-adjacent experience is not CUDA-kernel ownership, but I validated the CUDA profiling workflow directly. I can separate application timeline issues from kernel-level bottlenecks, and I understand memory coalescing, shared-memory tiling, pinned memory transfer, stream overlap, and the difference between Nsight Systems and Nsight Compute.

2.6 任务链 2：LLM Serving / vLLM，证明你理解 inference runtime 指标

这组任务对应 JD 的这些考察点：

• inference and model serving
• AI workloads
• throughput, latency, memory efficiency
• runtime systems
• Dynamo / NIXL / data movement

也对应你 CV 里的：

• LLM inference integration。
• KV cache、batching、speculative decoding。
• observability、replayability、correctness validation。

任务结构：

flowchart TB
    JD[JD: inference/model serving + throughput + latency + memory efficiency]
    CV[CV: LLM inference integration + KV cache + batching + observability]
    Goal[Goal: prove runtime-level serving understanding]

    JD --> Goal
    CV --> Goal

    Goal --> T1[Task 1: Run or design vLLM benchmark]
    T1 --> T2[Task 2: Vary input length]
    T1 --> T3[Task 3: Vary output length]
    T1 --> T4[Task 4: Vary request rate]
    T1 --> T5[Task 5: Connect KV cache to NIXL]

    T2 --> M2[Metric: TTFT / prefill time / queueing]
    T3 --> M3[Metric: TPOT / decode latency / total latency]
    T4 --> M4[Metric: throughput / P99 / saturation point]
    T5 --> M5[Metric: GPU memory / KV pressure / transfer dependency]

    M2 --> Q2[追问: high TTFT debug]
    M3 --> Q3[追问: bad TPOT debug]
    M4 --> Q4[追问: throughput vs latency trade-off]
    M5 --> Q5[追问: NIXL vs NCCL / KV movement]

    Q2 --> Evidence[面试证据: I can decompose serving bottlenecks by stage]
    Q3 --> Evidence
    Q4 --> Evidence
    Q5 --> Evidence

2.6.0 这组任务里的技术词汇是什么

2.6.1 任务 1：跑或设计 vLLM serving benchmark

任务说明：

优先在 WSL2 Ubuntu 跑：

python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
pip install vllm
python -m vllm.entrypoints.openai.api_server \
  --model Qwen/Qwen2.5-0.5B-Instruct \
  --host 0.0.0.0 \
  --port 8000

另一个终端跑：

python -m vllm.benchmarks.benchmark_serving \
  --backend openai \
  --model Qwen/Qwen2.5-0.5B-Instruct \
  --dataset-name random \
  --num-prompts 100 \
  --random-input-len 512 \
  --random-output-len 128 \
  --request-rate 4

如果你想一次跑完整矩阵，可以写这个脚本。

代码文件：run_vllm_matrix.sh

#!/usr/bin/env bash
set -euo pipefail

MODEL="${MODEL:-Qwen/Qwen2.5-0.5B-Instruct}"
HOST="${HOST:-127.0.0.1}"
PORT="${PORT:-8000}"
NUM_PROMPTS="${NUM_PROMPTS:-100}"

INPUT_LENS=(128 512 2048)
OUTPUT_LENS=(64 128 512)
REQUEST_RATES=(1 4 16)

mkdir -p results/vllm

for input_len in "${INPUT_LENS[@]}"; do
  for output_len in "${OUTPUT_LENS[@]}"; do
    for rate in "${REQUEST_RATES[@]}"; do
      out="results/vllm/in_${input_len}_out_${output_len}_r_${rate}.log"
      echo "Running input=${input_len}, output=${output_len}, request_rate=${rate}"
      python -m vllm.benchmarks.benchmark_serving \
        --backend openai \
        --base-url "http://${HOST}:${PORT}" \
        --model "${MODEL}" \
        --dataset-name random \
        --num-prompts "${NUM_PROMPTS}" \
        --random-input-len "${input_len}" \
        --random-output-len "${output_len}" \
        --request-rate "${rate}" | tee "${out}"
    done
  done
done

怎么跑：

chmod +x run_vllm_matrix.sh
./run_vllm_matrix.sh

怎么看输出文件：

ls results/vllm
grep -E "Successful requests|Request throughput|Output token throughput|Mean TTFT|Median TTFT|P99 TTFT|Mean TPOT|Median TPOT|P99 TPOT" results/vllm/*.log

如果装不顺，不要卡死。你仍然要能说清实验矩阵：

input length: 128 / 512 / 2048
output length: 64 / 128 / 512
request rate: 1 / 4 / 16
metrics: TTFT / TPOT / P99 / throughput / GPU memory

怎么看效果：

• benchmark 输出里找 latency 指标、throughput 指标、请求成功率。
• 同时用另一个 WSL2 终端跑 watch -n 1 nvidia-smi，观察 GPU memory 和 utilization。
• 如果 GPU memory 很高但 throughput 不升，可能是 batch/KV/cache pressure。
• 如果 GPU utilization 低但 latency 高，可能是 scheduler、CPU、tokenizer、data movement、同步等待。

2.6.2 任务 2：改变 input length，解释 TTFT / prefill

任务说明：

你要知道是什么：

• input prompt 越长，prefill 越重。
• TTFT 包含 queueing、tokenization、scheduling、prefill、KV allocation。

怎么看结果：

• input length 从 128 到 2048，TTFT 通常增加。
• 如果 TTFT 在高并发下暴涨，可能是 queueing/scheduler/admission control。

具体怎么跑：

python -m vllm.benchmarks.benchmark_serving \
  --backend openai \
  --model Qwen/Qwen2.5-0.5B-Instruct \
  --dataset-name random \
  --num-prompts 100 \
  --random-input-len 128 \
  --random-output-len 128 \
  --request-rate 4

python -m vllm.benchmarks.benchmark_serving \
  --backend openai \
  --model Qwen/Qwen2.5-0.5B-Instruct \
  --dataset-name random \
  --num-prompts 100 \
  --random-input-len 2048 \
  --random-output-len 128 \
  --request-rate 4

追问：

• TTFT 高怎么查？
• Prefill 为什么 compute-heavy？
• Prefill/decode disaggregation 为什么会引入 KV transfer？

回答：

I separate TTFT into queueing, scheduling, tokenization, prefill execution, KV allocation, and any transfer before decode starts. Longer prompts mainly increase prefill work. Under high load, queueing and batching can dominate. If prefill and decode are disaggregated, KV cache movement can also affect when decode can start.

2.6.3 任务 3：改变 output length，解释 TPOT / decode

任务说明：

你要知道是什么：

• decode 每次生成一个 token。
• output 越长，decode step 越多。
• decode 反复读 KV cache，memory/cache behavior 很重要。

怎么看结果：

• output length 从 64 到 512，总延迟上升。
• TPOT 如果变差，要看 decode kernel、KV cache access、collectives、synchronization。

具体怎么跑：

python -m vllm.benchmarks.benchmark_serving \
  --backend openai \
  --model Qwen/Qwen2.5-0.5B-Instruct \
  --dataset-name random \
  --num-prompts 100 \
  --random-input-len 512 \
  --random-output-len 64 \
  --request-rate 4

python -m vllm.benchmarks.benchmark_serving \
  --backend openai \
  --model Qwen/Qwen2.5-0.5B-Instruct \
  --dataset-name random \
  --num-prompts 100 \
  --random-input-len 512 \
  --random-output-len 512 \
  --request-rate 4

追问：

• Decode 为什么 latency-sensitive？
• TPOT 高怎么查？
• KV cache 为什么影响 decode？

回答：

Decode is iterative and generates one token per step, so per-token latency directly affects user-visible streaming speed. I would debug bad TPOT by isolating the decode loop, checking KV cache access, memory bandwidth, synchronization, and any tensor-parallel collective communication.

2.6.4 任务 4：改变 request rate，解释 throughput vs P99

任务说明：

你要知道是什么：

• request rate 增加，batching 可能提高 GPU utilization。
• 但超过系统承载点后，queueing 和 P99 会变差。
• throughput 和 latency 是 trade-off。

怎么看结果：

• request rate 从 1 到 4 到 16。
• 初期 throughput 上升。
• 过高时 P99/TTFT 变差。

具体怎么跑：

for r in 1 4 16; do
  python -m vllm.benchmarks.benchmark_serving \
    --backend openai \
    --model Qwen/Qwen2.5-0.5B-Instruct \
    --dataset-name random \
    --num-prompts 100 \
    --random-input-len 512 \
    --random-output-len 128 \
    --request-rate $r
done

追问：

• 怎么设置 admission control？
• GPU utilization 高但 P99 差，可能是什么？
• continuous batching 的利弊？

回答：

Higher request rate can improve batching and throughput until the system saturates. After that, queueing and tail latency dominate. I would track throughput, TTFT, TPOT, and P99 together, not only average latency. Continuous batching improves utilization but can introduce interference and fairness issues.

2.6.5 任务 5：把 KV cache 连接到 NIXL / data movement

任务说明：

你要知道是什么：

• KV cache 是每层 attention 的历史 key/value。
• 长 context、大 batch、多 worker 会让 KV cache 成为 memory 和 data movement 问题。
• 如果 prefill/decode 在不同 worker，KV cache 可能需要转移，这就连接到 NIXL。

追问：

• NIXL 为什么和 inference 有关？
• NIXL 和 NCCL 的区别？
• KV transfer 慢会影响什么指标？

回答：

KV cache is inference state, not just a temporary tensor. In disaggregated serving, prefill workers may produce KV blocks that decode workers need to consume. That creates an inference data movement problem. NIXL is relevant there because it abstracts movement of KV cache or request state, while NCCL is for collectives across ranks.

2.7 任务链 3：NCCL / Collectives，证明你理解多 GPU 通信

这组任务对应 JD 的：

• communication libraries
• NCCL / collectives
• parallelism
• throughput and latency optimization

也对应你 CV 里的：

• distributed systems、communication-path diagnosis。
• backpressure、tail latency、observability。

任务结构：

flowchart TB
    JD[JD: communication libraries + parallelism + throughput/latency]
    CV[CV: distributed systems + communication-path diagnosis + tail latency]
    Goal[Goal: prove multi-GPU communication reasoning]

    JD --> Goal
    CV --> Goal

    Goal --> T1[Task 1: Run all-reduce benchmark]
    Goal --> T2[Task 2: Interpret small vs large messages]
    Goal --> T3[Task 3: Reason about topology]
    Goal --> T4[Task 4: Map collectives to DP/TP/FSDP]

    T1 --> M1[Metrics: algbw, busbw, message size]
    T2 --> M2[Metrics: latency-bound vs bandwidth-bound]
    T3 --> M3[Signals: PCIe, NVLink, IB, RoCE, rank mapping]
    T4 --> M4[Patterns: all-reduce, all-gather, reduce-scatter]

    M1 --> Q1[追问: what is all-reduce]
    M2 --> Q2[追问: why small and large messages differ]
    M3 --> Q3[追问: slow rank / topology / transport]
    M4 --> Q4[追问: DP vs TP vs FSDP communication]

    Q1 --> Evidence[面试证据: I can isolate communication bottlenecks]
    Q2 --> Evidence
    Q3 --> Evidence
    Q4 --> Evidence

2.7.0 这组任务里的技术词汇是什么

2.7.1 任务 1：跑 all-reduce benchmark

任务说明：

如果 WSL2/Linux 环境可用：

git clone https://github.com/NVIDIA/nccl-tests.git labs/nccl_tests/nccl-tests
cd labs/nccl_tests/nccl-tests
make MPI=0
./build/all_reduce_perf -b 8 -e 128M -f 2 -g 1

带日志版本：

NCCL_DEBUG=INFO ./build/all_reduce_perf -b 8 -e 128M -f 2 -g 1

建议再写一个脚本，避免每次忘记参数和日志保存。

代码文件：run_nccl_allreduce.sh

#!/usr/bin/env bash
set -euo pipefail

NCCL_TESTS_DIR="${NCCL_TESTS_DIR:-labs/nccl_tests/nccl-tests}"
GPUS="${GPUS:-1}"
BEGIN_SIZE="${BEGIN_SIZE:-8}"
END_SIZE="${END_SIZE:-128M}"
FACTOR="${FACTOR:-2}"

mkdir -p results/nccl

if [ ! -x "${NCCL_TESTS_DIR}/build/all_reduce_perf" ]; then
  echo "all_reduce_perf not found, building nccl-tests..."
  mkdir -p "$(dirname "${NCCL_TESTS_DIR}")"
  git clone https://github.com/NVIDIA/nccl-tests.git "${NCCL_TESTS_DIR}" 2>/dev/null || true
  make -C "${NCCL_TESTS_DIR}" MPI=0
fi

echo "GPU topology:"
nvidia-smi topo -m || true

echo "Running NCCL all_reduce_perf with GPUS=${GPUS}"
NCCL_DEBUG=INFO "${NCCL_TESTS_DIR}/build/all_reduce_perf" \
  -b "${BEGIN_SIZE}" \
  -e "${END_SIZE}" \
  -f "${FACTOR}" \
  -g "${GPUS}" 2>&1 | tee "results/nccl/all_reduce_g${GPUS}.log"

怎么跑：

chmod +x run_nccl_allreduce.sh
./run_nccl_allreduce.sh

如果是多 GPU Linux 机器：

GPUS=2 ./run_nccl_allreduce.sh
GPUS=4 ./run_nccl_allreduce.sh

怎么看输出：

grep -E "NCCL INFO|out-of-place|in-place|algbw|busbw" results/nccl/all_reduce_g1.log

每个参数是什么：

如果只有单 GPU：

• 结果主要是 sanity，不代表真实多 GPU 通信。
• 但你仍然能解释 benchmark 怎么扩展到多 GPU/多节点。

怎么读效果：

• 输出按 message size 分行，看 size 增大时 time、algbw、busbw 如何变化。
• 小 size 下带宽低不奇怪，因为 latency/launch overhead 占主导。
• 大 size 下带宽应该更接近硬件路径能力。
• NCCL_DEBUG=INFO 可帮助判断用了什么 transport，但单 GPU时信息有限。

2.7.2 任务 2：解释 small message vs large message

任务说明：

怎么看结果：

• 小 message：latency、launch overhead、progress overhead 更明显。
• 大 message：bandwidth、PCIe/NVLink/NIC/fabric 更明显。
• algbw：用户 payload 视角的算法带宽。
• busbw：按 collective traffic pattern 估算的总线带宽。

追问：

• all-reduce 慢一定是 NCCL bug 吗？
• 为什么小包和大包瓶颈不一样？
• 怎么定位 slow rank？

回答：

I would not assume a 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. Small messages are often latency dominated, while large messages are bandwidth and topology dominated.

2.7.3 任务 3：把 NCCL 连接到 parallelism

任务说明：

你要能说：

追问：

• tensor parallel inference 为什么需要 communication？
• NCCL 和 NIXL 的区别？
• GPU utilization 低但 network 忙，可能是什么？

回答：

NCCL provides collective tensor communication across ranks. It is central to distributed training and can also appear in tensor-parallel inference. NIXL is different: it moves inference state such as KV cache between workers. If GPU utilization is low but network is busy, I would check whether communication or data movement is on the critical path, whether transfers are too small, and whether compute overlaps with communication.

2.8 任务链 4：UCX / RDMA / GPUDirect，证明你知道真实集群边界

这组任务对应 JD 的：

• UCX
• RDMA / RoCE
• GPUDirect
• data movement
• GPU networking

也对应你 CV 里的：

• communication-path diagnosis。
• Linux systems。
• cross-layer debugging。

任务结构：

flowchart TB
    JD[JD: UCX + RDMA/RoCE + GPUDirect + data movement]
    CV[CV: communication-path diagnosis + Linux systems + cross-layer debugging]
    Goal[Goal: prove realistic GPU networking boundary and debug reasoning]

    JD --> Goal
    CV --> Goal

    Goal --> T1[Task 1: Check what this machine can validate]
    Goal --> T2[Task 2: Draw TCP vs RDMA vs GPUDirect path]
    Goal --> T3[Task 3: Build slow-path checklist]

    T1 --> M1[Signals: ucx_info, RDMA device, GPU visibility, DOCA/NIC availability]
    T2 --> M2[Concepts: CPU staging, registered memory, NIC DMA, GPU memory]
    T3 --> M3[Checklist: transport, memory type, registration, topology, progress, fabric]

    M1 --> Q1[追问: what can you validate locally]
    M2 --> Q2[追问: RDMA vs TCP / GPUDirect RDMA]
    M3 --> Q3[追问: slow UCX transfer / GPU waiting on network]

    Q1 --> Evidence[面试证据: I know the real cluster boundary and debug path]
    Q2 --> Evidence
    Q3 --> Evidence

2.8.0 这组任务里的技术词汇是什么

2.8.1 任务 1：先确认本机能验证什么

任务说明：

WSL2 里尝试：

ucx_info -v
ucx_info -d

如果有 UCX perftest：

ucx_perftest -t tag_bw -s 1048576 localhost

建议写一个检查脚本，把“我这台机器到底能验证什么”一次性打印出来。

代码文件：check_ucx_gpu_networking.sh

#!/usr/bin/env bash
set -euo pipefail

mkdir -p results/ucx

echo "== OS =="
uname -a | tee results/ucx/os.log

echo
echo "== GPU visibility =="
if command -v nvidia-smi >/dev/null 2>&1; then
  nvidia-smi | tee results/ucx/nvidia_smi.log
  nvidia-smi topo -m | tee results/ucx/topology.log || true
else
  echo "nvidia-smi not found"
fi

echo
echo "== UCX version =="
if command -v ucx_info >/dev/null 2>&1; then
  ucx_info -v | tee results/ucx/ucx_version.log
  ucx_info -d | tee results/ucx/ucx_devices.log
else
  echo "ucx_info not found. On Ubuntu you may try: sudo apt install ucx-utils"
fi

echo
echo "== RDMA devices =="
if command -v ibv_devinfo >/dev/null 2>&1; then
  ibv_devinfo | tee results/ucx/ibv_devinfo.log
else
  echo "ibv_devinfo not found. On Ubuntu you may try: sudo apt install rdma-core ibverbs-utils"
fi

echo
echo "== Kernel RDMA devices =="
if [ -d /sys/class/infiniband ]; then
  find /sys/class/infiniband -maxdepth 2 -type l -o -type d | tee results/ucx/sys_infiniband.log
else
  echo "/sys/class/infiniband not found"
fi

echo
echo "Interpretation:"
echo "- If only TCP/shared-memory resources are visible, this machine can learn UCX tooling but cannot validate real RDMA."
echo "- If RDMA devices are visible, continue with ucx_perftest across two hosts."
echo "- GPUDirect RDMA requires compatible GPU, RNIC, driver, topology, and fabric; WSL2 GPU visibility alone is not enough."

怎么跑：

chmod +x check_ucx_gpu_networking.sh
./check_ucx_gpu_networking.sh

怎么看输出：

cat results/ucx/ucx_version.log
cat results/ucx/ucx_devices.log
cat results/ucx/topology.log
cat results/ucx/ibv_devinfo.log

命令含义：

怎么看结果：

• 能看到 UCX 版本和设备：可以做工具层学习。
• 没有 RDMA device：不能验证真实 RDMA/RoCE。
• 没有 NVIDIA NIC/DOCA：不能验证真实 GPUNetIO。
• WSL2 能看到 GPU，不代表具备 GPUDirect RDMA。

怎么读效果：

• ucx_info -v 看版本和 build 信息。
• ucx_info -d 看有哪些 transport/resource。
• 如果只看到 TCP/shared memory，不代表 UCX 不重要，只代表本机没有 RDMA fabric。
• 如果有 RDMA device，再进一步看是否支持 GPU buffer direct path。

2.8.2 任务 2：画清 TCP vs RDMA vs GPUDirect

任务说明：

flowchart TB
    subgraph TCPPath[TCP / CPU-Staged Path]
        G1[GPU Memory] --> H1[Host Staging Memory]
        H1 --> CPU[CPU / Kernel Networking]
        CPU --> NIC1[NIC]
        NIC1 --> NET[Network]
        NET --> NIC2[Remote NIC]
        NIC2 --> H2[Remote Host Staging]
        H2 --> G2[Remote GPU Memory]
    end

    subgraph GDRPath[GPUDirect RDMA Path]
        GG1[GPU Memory] --> RNIC1[RNIC]
        RNIC1 --> RNET[RDMA Network]
        RNET --> RNIC2[Remote RNIC]
        RNIC2 --> GG2[Remote GPU Memory]
    end

追问：

• RDMA 为什么需要 registered memory？
• RoCE 为什么配置复杂？
• GPUDirect RDMA 和 GPUNetIO 区别？
• UCX 在这里是什么角色？

回答：

RDMA allows the NIC to directly access registered memory, reducing CPU and kernel involvement in the data path. GPUDirect RDMA extends this idea to GPU memory when the hardware, driver, topology, and fabric support it. UCX is a transport abstraction that can use RDMA, TCP, shared memory, and CUDA-aware paths underneath.

2.8.3 任务 3：准备 UCX/RDMA slow-path checklist

任务说明：

慢了先查：

selected transport:
  RDMA / TCP fallback / shared memory / CUDA IPC

memory type:
  CPU pageable / CPU pinned / GPU memory

message size:
  small latency dominated / large bandwidth dominated

registration:
  repeated registration / registration cache

topology:
  GPU-NIC affinity / PCIe / NUMA

progress:
  polling / completion / progress thread

fabric:
  RoCE PFC/ECN/QoS / IB counters / congestion

面试回答：

On my Windows GPU machine, I can validate CUDA profiling and local serving behavior. For RDMA/RoCE, GPUDirect RDMA, and GPUNetIO, I would need the right NIC, driver, and fabric. I would still prepare the data-path diagrams, benchmark design, and debug checklist so I can explain exactly how I would validate them in a real cluster.

2.9 可选对照环境搭建：ROCm / Metal / MPS / Vulkan / WebGPU

这一节不是 NVIDIA 面试主线，但可以帮助你把“CUDA 之外的 GPU 技术”放到同一张地图里。
使用原则：

有对应机器才搭。
没有对应机器就只读概念和对照表。
不要为了 AMD/macOS 环境耽误 CUDA/NVIDIA 主线。

2.9.1 AMD ROCm / HIP 环境

适用场景：

• 你有 AMD GPU。
• 想理解 CUDA 对应到 AMD 生态怎么做。
• 想了解 HIP kernel、ROCm profiling、RCCL/NCCL 类比。

不适用：

• 你只有 NVIDIA GPU。
• 你现在主要准备 NVIDIA 面试。
• 你没有 AMD ROCm 支持列表里的 GPU。

ROCm 和 CUDA 的关系：

flowchart LR
    CUDA[CUDA / NVIDIA] --> HIP[HIP: CUDA-like Portability Layer]
    HIP --> ROCm[ROCm Runtime and Libraries]
    ROCm --> AMDGPU[AMD GPU]
    CUDA --> CUDART[CUDA Runtime]
    CUDART --> NVIDIAGPU[NVIDIA GPU]

Linux ROCm 通用搭建步骤：

# 1. 确认 GPU
lspci | grep -i 'amd\|vga\|display'

# 2. 确认系统版本和 kernel
uname -a
lsb_release -a

# 3. 按 AMD ROCm 官方 Linux install/quick-start 文档选择对应 OS 版本
#    不要随便复制旧命令，因为 ROCm repo/package 名会随版本变化。

# 4. 安装 ROCm 后，加入权限组，常见是 render/video
sudo usermod -aG render,video $USER

# 5. 重新登录或 reboot 后验证
rocminfo
hipcc --version

Windows ROCm/HIP SDK 思路：

# 1. 确认 AMD Adrenalin driver / AMD GPU 正常
# 2. 安装 AMD HIP SDK for Windows
# 3. 打开 Developer Command Prompt 或 PowerShell
hipcc --version

ROCm PyTorch 验证思路：

python3 - <<'PY'
import torch
print(torch.__version__)
print(torch.cuda.is_available())
print(torch.cuda.get_device_name(0) if torch.cuda.is_available() else "no rocm device")
PY

注意：PyTorch 在 ROCm 后端里仍常通过 torch.cuda namespace 暴露设备，这是历史 API 兼容，不代表它在用 NVIDIA CUDA。

ROCm 学习验收：

• 能解释 HIP 是 CUDA-like programming model。
• 能解释 ROCm 是 AMD GPU compute software stack。
• 能解释 RCCL 类似 NCCL 的 collective 角色。
• 能说清：这只是迁移类比，NVIDIA 面试仍要回到 CUDA/NCCL/Nsight。

2.9.2 macOS Metal 环境

适用场景：

• 你有 Mac，尤其是 Apple Silicon。
• 想理解 Apple GPU 的 compute / graphics API。
• 想把 Metal threadgroup、command queue、GPU counters 类比到 CUDA。

Metal 和 CUDA 的关系：

flowchart LR
    CUDA[CUDA Kernel] --> CUDAStream[CUDA Stream / Event]
    CUDAStream --> Nsight[Nsight Profiling]
    Metal[Metal Compute Kernel] --> CommandQueue[Command Queue / Command Buffer]
    CommandQueue --> XcodeTools[Xcode Metal Debugger / Instruments]

macOS Metal 基础搭建：

# 1. 安装 Xcode
#    从 App Store 或 Apple Developer 下载。

# 2. 安装 Command Line Tools
xcode-select --install

# 3. 验证 Xcode 工具链
xcodebuild -version
xcrun -sdk macosx metal -v
xcrun -sdk macosx metallib -v

最小学习路径：

1. 用 Xcode 创建 macOS App 或 Command Line Tool。
2. 添加 .metal shader 文件。
3. 创建 MTLDevice、MTLCommandQueue、MTLBuffer。
4. 编译 compute pipeline。
5. 提交 command buffer。
6. 用 Xcode GPU tools / Instruments 看 timeline 和 counters。

Metal 学习验收：

• 能解释 MTLDevice 类似 GPU device handle。
• 能解释 command queue / command buffer 类似异步 GPU command submission。
• 能解释 threadgroup memory 类似 CUDA shared memory。
• 能解释 Xcode GPU tools 对应 Nsight 的一部分 profiling/debug 能力。

2.9.3 macOS MPS / MPSGraph / PyTorch MPS

这里有三个容易混淆的词：

Metal:
  Apple GPU graphics/compute API。

Metal Performance Shaders, MPS:
  Apple 提供的高性能 GPU kernels / primitives。

MPSGraph:
  面向 tensor/graph computation 的 API，可用于 ML-style compute graph。

PyTorch MPS backend:
  PyTorch 在 Apple Silicon/macOS 上使用 Metal/MPS 加速 tensor 操作的后端。

MPS / PyTorch MPS 搭建：

# 1. macOS + Apple Silicon 或支持的 Apple GPU 环境
python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip

# 2. 安装 PyTorch
#    按 PyTorch 官方 selector 选择 macOS / MPS 对应命令
pip install torch torchvision torchaudio

# 3. 验证 MPS backend
python - <<'PY'
import torch
print(torch.__version__)
print("mps built:", torch.backends.mps.is_built())
print("mps available:", torch.backends.mps.is_available())
if torch.backends.mps.is_available():
    x = torch.randn(1024, 1024, device="mps")
    y = x @ x
    print(y.device, y.shape)
PY

MPS 学习验收：

• 能解释 MPS 是 Apple tuned GPU kernels/primitives。
• 能解释 PyTorch MPS backend 是 framework-level acceleration。
• 能解释它和 CUDA 的共同点：tensor 操作下沉到 GPU。
• 能解释它和 CUDA 的不同点：CUDA 更底层、更贴近 NVIDIA GPU programming stack；MPS 更 Apple platform-specific。

2.9.4 Vulkan SDK 环境

适用场景：

• 你想理解跨平台显式 GPU API。
• 你想把 Vulkan queue/command buffer/memory barrier 的经验类比到 CUDA stream/sync/memory model。
• 你已有 Vulkan/WebGPU 经验，可以用来解释 GPU workload profiling 的迁移能力。

Vulkan 和 CUDA 的关系：

flowchart TB
    Vulkan[Vulkan]
    Vulkan --> Instance[Instance / Physical Device / Logical Device]
    Vulkan --> Queue[Queue / Command Buffer]
    Vulkan --> Memory[Explicit Memory Management]
    Vulkan --> Shader[SPIR-V Shader]

    CUDA[CUDA]
    CUDA --> Device[CUDA Device]
    CUDA --> Stream[Stream / Kernel Launch]
    CUDA --> CUDAMemory[Global / Shared / Pinned Memory]
    CUDA --> Kernel[CUDA Kernel]

Windows Vulkan SDK：

# 1. 从 LunarG Vulkan SDK 官方页面下载安装器
# 2. 安装后打开新的 PowerShell
echo $env:VULKAN_SDK
vulkaninfo --summary
glslangValidator --version

Linux Vulkan SDK：

# 1. 从 LunarG 下载 Linux SDK tarball，解压到固定目录
# 2. source SDK 环境脚本，具体路径按下载版本
source ~/vulkan-sdk/*/setup-env.sh

# 3. 验证
echo $VULKAN_SDK
vulkaninfo --summary
glslangValidator --version

macOS Vulkan SDK：

# 1. 从 LunarG 下载 macOS Vulkan SDK
# 2. 安装后打开新的 shell
echo $VULKAN_SDK
vulkaninfo --summary
glslangValidator --version

Vulkan 学习验收：

• 能解释 Vulkan 是 explicit graphics/compute API。
• 能解释 command buffer / queue / memory barrier。
• 能把 Vulkan profiling 经验迁移到 CUDA timeline、kernel launch、sync、memory movement。
• 能明确说：Vulkan 不是 NVIDIA AI networking 主线，只是 GPU systems 经验的旁证。

2.9.5 WebGPU 环境

WebGPU 有两条路线：

Browser WebGPU:
  用 Chrome/Edge/Safari/Firefox 等浏览器跑 WebGPU JS/WGSL。

Native WebGPU:
  用 Dawn 或 wgpu-native / wgpu 在 native app 里使用 WebGPU-like API。

WebGPU 和底层 API 的关系：

flowchart TB
    WebGPU[WebGPU API / WGSL]
    WebGPU --> Dawn[Dawn in Chromium]
    WebGPU --> WGPU[wgpu / wgpu-native]
    Dawn --> D3D12[Direct3D 12 on Windows]
    Dawn --> Metal[Metal on macOS]
    Dawn --> Vulkan[Vulkan on Linux/Windows]
    WGPU --> D3D12
    WGPU --> Metal
    WGPU --> Vulkan

Browser WebGPU 最小搭建：

# 1. 安装现代 Chrome/Edge/Safari/Firefox
# 2. 建一个本地目录
mkdir webgpu-test
cd webgpu-test

# 3. 写 index.html / main.js / shader.wgsl
# 4. 用本地 server 打开，不要直接 file://
python3 -m http.server 8080

# 5. 浏览器访问
# http://localhost:8080

浏览器里验证：

if (!navigator.gpu) {
  console.log("WebGPU not available");
} else {
  const adapter = await navigator.gpu.requestAdapter();
  const device = await adapter.requestDevice();
  console.log(adapter, device);
}

Native WebGPU 路线：

• C/C++：看 Dawn，它是 Chromium 的 WebGPU implementation。
• Rust：看 wgpu，它可以跑在 Vulkan、Metal、D3D12 等 backend 上。
• 面试准备不建议周末硬搭 native WebGPU，除非你已经有项目基础。

WebGPU 学习验收：

• 能解释 WebGPU 是现代浏览器 GPU API，不是 WebGL。
• 能解释 WGSL shader、GPUAdapter、GPUDevice、command encoder。
• 能解释 WebGPU 的 portability：底层可能映射到 D3D12、Metal、Vulkan。
• 能把 WebGPU 经验迁移到“explicit GPU command submission、buffer management、profiling/debug 思维”。

2.9.6 对 NVIDIA 面试怎么讲这些对照环境

正确讲法：

I have used or studied cross-platform GPU stacks such as Vulkan/WebGPU, and I understand the analogous AMD ROCm/HIP and Apple Metal/MPS ecosystems. For this NVIDIA role, I would treat them as transferable mental models: GPU execution hierarchy, command submission, memory locality, profiling, and synchronization. But the concrete stack I would prepare and validate for this role is CUDA, Nsight, NCCL, UCX, and NVIDIA GPU networking.

不建议讲法：

我会 Metal，所以不用学 CUDA。
我懂 WebGPU，所以可以直接做 NCCL/UCX。
ROCm 和 CUDA 一样，所以不用区分。

面试官真正想听的是：

• 你知道 CUDA 是主线。
• 你知道不同 GPU API 的共性和差异。
• 你能从已有 Vulkan/WebGPU/Metal 经验迁移到 CUDA profiling。
• 你不会把平台特定能力混为一谈。

2.10 接下来每个技能怎么读

从第 3 章开始，每个技能都按这个顺序读：

flowchart LR
    A[先看能跑什么实验] --> B[解释技术名词]
    B --> C[JD 要求什么级别]
    C --> D[你的 CV 对应什么]
    D --> E[怎么实际跑和看结果]
    E --> F[面试会怎么问]
    F --> G[你怎么回答]

注意：后面章节有些历史小标题仍然叫“JD 要求是什么 / CV 里有什么 / 面试会问什么”，但你的阅读方式应该按本章执行：先用环境和实验建立直觉，再读概念和 Q&A。

3. 核心数据移动学习路径：UCX / NIXL / GPUNetIO

这一章把单独文档里的 UCX/NIXL/GPUNetIO 学习路径合并进主文档。你后面遇到这三个词，就先回来看这一章。

学习目标不是背定义，而是建立三层直觉：

UCX:
  transport abstraction，解决“怎么高效搬 bytes”。

NIXL:
  inference data movement，解决“怎么搬 KV cache / request state / inference buffers”。

GPUNetIO:
  GPU-centric networking，解决“怎么让 GPU 更直接参与网络 data-plane”。

3.1 推荐学习顺序

flowchart LR
    A[先有环境直觉: Windows GPU + WSL2] --> B[UCX: Transport Abstraction]
    B --> C[NIXL: Inference Data Movement]
    C --> D[GPUNetIO: GPU-Centric Networking]
    D --> E[三者对比]
    E --> F[Debug Checklist]
    F --> G[面试 60 秒回答]

为什么是这个顺序：

• 先学 UCX，因为它是更底层的 communication/transport abstraction。
• 再学 NIXL，因为 NIXL 可能使用 UCX 这种 transport backend，但它的语义是 inference data movement。
• 最后学 GPUNetIO，因为它不是普通通信库，而是让 GPU 参与 network data-plane。

3.2 先看三者在系统里的位置

flowchart TB
    Serving[LLM Serving / Distributed Inference]
    Runtime[Dynamo / vLLM / Custom Runtime]
    NIXL[NIXL: Inference Data Movement]
    NCCL[NCCL: GPU Collectives]
    UCX[UCX: Transport Abstraction]
    RDMA[RDMA / RoCE / InfiniBand]
    TCP[TCP]
    SHM[Shared Memory]
    CUDAIPC[CUDA IPC]
    GPUNetIO[GPUNetIO: GPU-Centric Network Data Plane]
    NIC[NIC / BlueField / ConnectX]
    GPU[GPU Memory / CUDA Kernel]

    Serving --> Runtime
    Runtime --> NIXL
    Runtime --> NCCL
    NIXL --> UCX
    NCCL --> UCX
    UCX --> RDMA
    UCX --> TCP
    UCX --> SHM
    UCX --> CUDAIPC
    GPUNetIO --> NIC
    GPUNetIO --> GPU
    NIC --> GPU

这张图要记住：

• UCX 更偏底层 transport。
• NIXL 更偏推理状态/数据搬运。
• GPUNetIO 更偏 GPU 参与网络 data-plane。
• NCCL 是对照项：它做 collective，不等于 NIXL。

3.3 UCX：先跑什么、再理解什么

3.3.1 你先实际做什么

在 WSL2 Ubuntu 里先试：

ucx_info -v
ucx_info -d

如果没有安装 UCX，不要卡太久。你先记录：

UCX installed: yes/no
RDMA device visible: yes/no
GPU visible in WSL2: yes/no
Can validate real RDMA: yes/no

3.3.2 UCX 是什么

UCX，Unified Communication X，是高性能通信框架。它给上层 runtime 提供统一通信抽象，让应用不用直接处理每种底层 transport。

它可以抽象：

• TCP。
• RDMA over InfiniBand。
• RoCE。
• shared memory。
• CUDA IPC。
• CUDA-aware GPU buffer transfer。

一句话：

UCX is a high-performance communication framework that abstracts multiple transports such as RDMA, TCP, shared memory, and CUDA-aware paths.

3.3.3 UCX 为什么出现

没有 UCX 时，上层系统要自己处理：

flowchart TB
    App[Application]
    TCPPath[Manual TCP]
    RDMAVerbs[Manual RDMA Verbs]
    SHMPath[Manual Shared Memory]
    CUDAPath[Manual CUDA IPC / GPU Buffer Path]
    Completion[Manual Progress / Completion]

    App --> TCPPath
    App --> RDMAVerbs
    App --> SHMPath
    App --> CUDAPath
    App --> Completion

有 UCX 后：

flowchart TB
    App[Application / Runtime]
    UCXAPI[UCX API]
    Select[UCX Selects Protocol and Transport]
    TCPPath[TCP]
    RDMAPath[RDMA]
    SHMPath[Shared Memory]
    CUDAPath[CUDA IPC / CUDA-Aware Path]

    App --> UCXAPI
    UCXAPI --> Select
    Select --> TCPPath
    Select --> RDMAPath
    Select --> SHMPath
    Select --> CUDAPath

UCX 的价值：

• 统一接口。
• 根据环境选择 transport。
• 减少上层系统直接写 RDMA verbs 的复杂度。
• 支持 CPU/GPU memory 相关通信路径。

3.3.4 UCX 的 JD 要求级别

这个岗位不一定要求你写 UCX 源码，但要求你能做到：

• 知道 UCX 是 transport abstraction。
• 知道 UCX 可以走 RDMA/TCP/shared memory/CUDA-aware path。
• 知道 UCX 慢了怎么查。
• 知道 UCX 和 NIXL/NCCL 的层次区别。

3.3.5 UCX 怎么看结果

如果 ucx_info -d 能跑，你看：

• 有哪些 transport/device。
• 有没有 RDMA 相关设备。
• 有没有 CUDA/GPU memory 相关支持。
• 如果只有 TCP/shared memory，也要能解释：本地机器不是 RDMA 集群，不代表 UCX 概念不成立。

UCX 慢了的 debug 图：

flowchart TB
    Slow[UCX Transfer Slow] --> Transport{Selected Transport?}
    Transport --> RDMAPath[RDMA Expected?]
    Transport --> TCPFallback[TCP Fallback?]
    Slow --> Memory{Memory Type?}
    Memory --> CPU[CPU Memory]
    Memory --> GPU[GPU Memory]
    GPU --> Direct{Direct GPU Path?}
    Direct --> GDR[GPUDirect RDMA]
    Direct --> Staging[CPU Staging]
    Slow --> Size{Message Size?}
    Size --> Small[Small: Latency / Progress]
    Size --> Large[Large: Bandwidth / Topology]
    Slow --> Reg[Registration Overhead]
    Slow --> Topo[GPU-NIC / NUMA Topology]
    Slow --> Congestion[Fabric Congestion]

面试回答：

UCX is a lower-level transport abstraction. If a UCX transfer is slow, I would first check the selected transport and memory type, then message size, registration overhead, GPU-NIC topology, progress/completion behavior, and fabric congestion.

3.4 NIXL：先理解 KV movement，再理解库

3.4.1 你先实际做什么

NIXL 两天内不建议硬跑源码作为主目标。你先用 vLLM 或实验设计建立 LLM serving 直觉：

input length: 128 / 512 / 2048
output length: 64 / 128 / 512
request rate: 1 / 4 / 16
metrics: TTFT / TPOT / P99 / throughput / GPU memory

然后画这个路径：

flowchart LR
    Req[Request] --> Router[Router]
    Router --> PWorker[Prefill Worker on GPU A]
    PWorker --> KV[KV Cache Blocks]
    KV --> Move[NIXL Transfer KV / State]
    Move --> DWorker[Decode Worker on GPU B]
    DWorker --> Tokens[Generated Tokens]

3.4.2 NIXL 是什么

NIXL，NVIDIA Inference Xfer Library，是面向 AI inference framework 的数据传输库。它重点解决推理系统里的 data movement，尤其是：

• KV cache。
• request state。
• inference buffers。
• GPU memory / CPU memory / storage 之间的数据移动。

一句话：

NIXL is an inference-oriented data movement library for moving KV cache, request state, or buffers across GPU, host, network, and storage backends.

3.4.3 为什么 LLM inference 需要 NIXL

LLM serving 不是单次模型调用，而是：

flowchart LR
    Req[Request] --> Tok[Tokenization]
    Tok --> Sched[Scheduler]
    Sched --> Prefill[Prefill]
    Prefill --> KV[KV Cache]
    KV --> Decode[Decode Loop]
    Decode --> Out[Streaming Output]

Prefill 和 decode 的资源特征不同：

• prefill 处理 prompt，通常 compute-heavy。
• decode 每次生成一个 token，latency-sensitive，反复读 KV cache。

如果系统把 prefill worker 和 decode worker 拆开，就会出现 KV cache / request state movement。NIXL 正是为这种 inference data movement 提供抽象。

3.4.4 NIXL 的 JD 要求级别

JD 点名 NIXL，面试要求你至少能做到：

• 知道 NIXL 不是 NCCL。
• 知道 NIXL 和 KV cache / inference state movement 有关。
• 知道 NIXL 可以使用 UCX/RDMA/storage 等 backend 思路。
• 能解释 NIXL transfer 慢怎么查。

3.4.5 NIXL transfer lifecycle

flowchart LR
    A[Describe Source Buffer] --> B[Describe Destination Buffer]
    B --> C[Create Transfer Descriptor]
    C --> D[Select Backend]
    D --> E[Submit Async Transfer]
    E --> F[Poll / Check Completion]
    F --> G[Reuse / Release Resources]

解释：

• source buffer：KV/state 在哪里，是 GPU memory 还是 CPU memory。
• destination buffer：要搬到哪里，是否已经分配。
• transfer descriptor：source、destination、size、offset、backend preference。
• backend：UCX/RDMA、TCP、storage、local copy 等。
• async transfer：理想情况下和 compute overlap。
• completion：decode 不能无意义等待 transfer。
• reuse：避免频繁 registration 和 metadata allocation。

3.4.6 NIXL vs NCCL

flowchart TB
    subgraph NIXLPath[NIXL]
        P[Prefill Worker] --> KV[KV Cache / Request State]
        KV --> Transfer[Point-to-Point Transfer]
        Transfer --> D[Decode Worker]
    end

    subgraph NCCLPath[NCCL]
        R0[Rank 0 Tensor] --> Collective[All-Reduce / All-Gather / Reduce-Scatter]
        R1[Rank 1 Tensor] --> Collective
        R2[Rank 2 Tensor] --> Collective
        Collective --> Result[Collective Result]
    end

一句话：

NCCL is for collective tensor communication across ranks. NIXL is for inference-oriented point-to-point or state movement, such as KV cache transfer between prefill and decode workers.

3.4.7 NIXL 慢了怎么看

flowchart TB
    Slow[NIXL Transfer Slow] --> Granularity{Transfer Granularity}
    Granularity --> SmallBlocks[Too Many Small KV Blocks]
    Granularity --> Batch[Can Batch / Merge?]
    Slow --> Backend{Actual Backend}
    Backend --> UCXPath[UCX / RDMA]
    Backend --> TCPFallback[TCP Fallback]
    Backend --> StoragePath[Storage Backend]
    Slow --> Memory{Memory Type}
    Memory --> GPU[GPU Memory]
    Memory --> CPU[CPU Memory]
    Slow --> Overlap{Overlap with Compute?}
    Overlap --> Blocking[Decode Waiting]
    Overlap --> Async[Async Transfer]
    Slow --> Topology[GPU / NIC / NUMA / Node Placement]
    Slow --> Completion[Completion / Progress Overhead]

Debug checklist：

• KV block 是否太碎。
• 是否可以 batch transfer。
• backend 是否选对。
• 是否 fallback。
• 是否 CPU staging。
• registration 是否复用。
• transfer 是否和 compute overlap。
• decode 是否等 KV。
• prefill/decode placement 是否合理。

面试回答：

For NIXL, I would first verify what data is being moved, its granularity, and the actual backend path. Many small KV-block transfers, repeated registration, CPU staging, lack of overlap with decode, or backend fallback can dominate.

3.5 GPUNetIO：先区分它和 GPUDirect RDMA

3.5.1 你先实际做什么

GPUNetIO 需要 DOCA/NVIDIA NIC/driver 环境，两天内不建议硬搭。如果没有对应硬件，你要完成三件事：

• 画 CPU-centric vs GPU-centric networking。
• 写 GPUNetIO vs GPUDirect RDMA 对比。
• 写一个 prototype design 和 metrics。

3.5.2 GPUNetIO 是什么

GPUNetIO 是 NVIDIA DOCA 体系里的 GPU-centric networking programming model/API。它让 CUDA kernel 更直接参与网络 data-plane，例如处理 network-visible buffers、polling completion、或和 RDMA/DMA queue 交互。

一句话：

GPUNetIO is a GPU-centric networking programming model that lets CUDA kernels participate more directly in network data-plane work.

3.5.3 为什么需要 GPU-centric networking

传统 CPU-centric path：

flowchart LR
    NIC[NIC Receives Data] --> CPU[CPU Polls / Processes]
    CPU --> Staging[CPU Metadata / Staging / Coordination]
    Staging --> GPU[GPU Consumes Data]

GPU-centric path：

flowchart LR
    NIC[NIC / DOCA Queue / Network Buffer] --> GPUKernel[CUDA Kernel Polls or Processes]
    GPUKernel --> GPUWork[GPU Consumes or Transforms Data]

目标：

• 减少 CPU data-plane involvement。
• 让 GPU 更快看到网络数据。
• 对某些 real-time / low-latency / packet processing 场景降低延迟。

3.5.4 GPUNetIO vs GPUDirect RDMA

flowchart TB
    subgraph GDR[GPUDirect RDMA]
        NIC1[NIC] --> GPUMem1[GPU Memory]
    end

    subgraph GNI[GPUNetIO]
        NIC2[NIC / DOCA Queue] --> Kernel[CUDA Kernel]
        Kernel --> GPUMem2[GPU Memory / GPU Processing]
    end

必须记住：

GPUDirect RDMA = NIC can access GPU memory.
GPUNetIO = GPU can participate in network processing.

3.5.5 GPUNetIO 的 JD 要求级别

JD 点名 GPUNetIO，但不一定要求你有生产经验。你至少要能做到：

• 清楚说明 GPUNetIO 解决什么问题。
• 清楚区分 GPUNetIO 和 GPUDirect RDMA。
• 能说什么时候值得用，什么时候不值得用。
• 能设计 prototype 和 metrics。

什么时候值得用：

flowchart TB
    Start[Consider GPUNetIO?] --> DataGPU{Is network data consumed by GPU?}
    DataGPU -- No --> No1[Usually Not Worth It]
    DataGPU -- Yes --> CPUPath{Is CPU-mediated networking on critical path?}
    CPUPath -- No --> No2[Profile More Before Using]
    CPUPath -- Yes --> Regular{Is processing regular and GPU-friendly?}
    Regular -- No --> No3[CPU May Be Better]
    Regular -- Yes --> Prototype[Build GPUNetIO Prototype]
    Prototype --> Measure[Measure P99 / Throughput / GPU Cost]

3.5.6 GPUNetIO 慢了怎么看

flowchart TB
    Slow[GPUNetIO Not Helping] --> Baseline{Was CPU Path Really Bottleneck?}
    Baseline --> NoCPU[If No, GPUNetIO May Not Help]
    Slow --> GPUCost{GPU Polling Cost?}
    GPUCost --> SM[SM Occupancy / Kernel Interference]
    Slow --> Queue[Queue / Completion Handling]
    Slow --> Sync[Memory Visibility / Fences / Barriers]
    Slow --> Granularity[Packet / Batch Granularity]
    Slow --> Metrics[End-to-End P50 / P99 / Throughput]
    Slow --> Fallback[Fallback / Operational Complexity]

Debug checklist：

• baseline CPU path 是否真的是瓶颈。
• GPU polling kernel 是否抢占主 compute。
• queue 是否积压。
• completion 是否及时。
• memory visibility/fence 是否正确。
• batch 粒度是否合理。
• p99 是否真的改善。
• GPU utilization 是否被副作用拉高。

面试回答：

GPUNetIO is not something I would use by default. I would first prove CPU-mediated networking is on the critical path and the network data is consumed by GPU workloads. Then I would prototype it and compare p99 latency, throughput, CPU savings, GPU occupancy cost, and operational complexity.

3.6 三者面试对比

flowchart TB
    Question[What problem am I solving?]
    Question --> Bytes[Move bytes efficiently across transports]
    Question --> Inference[Move inference KV/state/buffers]
    Question --> GPUDataPlane[Move network data-plane work closer to GPU]

    Bytes --> UCX[UCX]
    Inference --> NIXL[NIXL]
    GPUDataPlane --> GPUNetIO[GPUNetIO]

面试标准回答：

UCX is a lower-level communication framework that abstracts transports such as RDMA, TCP, shared memory, and CUDA-aware paths. NIXL is a higher-level inference data movement library focused on moving KV cache, request state, or buffers in AI inference systems. GPUNetIO is different again: it is a GPU-centric networking programming model that lets GPU kernels participate in network data-plane work.

如果问怎么选择：

I would start from the critical path. If the issue is low-level transport performance, memory type, RDMA/TCP fallback, or GPU-NIC topology, I would look at UCX. If the issue is KV cache or request state movement between inference workers, I would look at NIXL. If CPU-mediated network data-plane processing is on the critical path and the data is consumed by GPU, I would consider GPUNetIO.

3.7 你的 CV 怎么接这一章

你没有 UCX/NIXL/GPUNetIO 生产 owner 经验，所以不要硬装。正确接法：

My direct production ownership is not UCX/NIXL/GPUNetIO internals.
My transferable experience is performance-sensitive systems, GPU profiling,
communication-path diagnosis, and architecture/prototype validation.
For this role, I would map each technology to the data path it optimizes,
run local CUDA/serving experiments where possible, and prepare cluster-level
benchmark designs for RDMA, NIXL transfer, and GPUNetIO.

4. 技能 1：AI Inference / Model Serving

4.1 JD 要求是什么

JD 里的关键词：

• inference and model serving
• throughput
• latency
• memory efficiency
• AI workloads
• runtime systems
• communication libraries

实际考察：

• 你是否知道 LLM serving 不只是“调用模型”。
• 你是否理解 prefill/decode 的 workload 差异。
• 你是否理解 KV cache 是 memory 和 data movement 问题。
• 你是否能按 TTFT/TPOT/P99 拆性能问题。

4.2 你 CV 里有什么

匹配点：

• OKX AI risk-control / LLM engineering。
• online inference path。
• KV cache、speculative decoding、batching。
• observability、replayability、correctness validation。

风险点：

• 如果只讲 LLM agent / retrieval / application，会显得离岗位太上层。
• 要把经历转成 runtime、scheduler、memory、communication、profiling 语言。

4.3 面试会问什么

基础问题：

• What is prefill and decode?
• What is KV cache?
• What is TTFT and TPOT?
• What is continuous batching?
• What is paged attention?
• What is speculative decoding?

深入问题：

• 为什么 decode 比 prefill 更 latency-sensitive？
• 为什么 KV cache 会成为显存瓶颈？
• prefill/decode disaggregation 会带来什么 data movement 问题？
• 如果 TTFT 很高，你怎么查？
• 如果 TPOT 很差，你怎么查？
• throughput 和 P99 latency 怎么权衡？

系统设计问题：

• 如果让你优化 multi-node LLM serving，你第一步看什么指标？
• 如果 GPU utilization 低，但网络很忙，可能是什么原因？

4.4 必须掌握的机制

4.4.1 LLM Serving 不是一次模型调用

LLM serving 是一个在线系统，不是简单的：

request -> model.generate() -> response

真正的 serving 路径包含：

• 接入层：接收请求、鉴权、限流、排队。
• tokenizer：把文本转成 token，通常在 CPU 上做。
• router/scheduler：决定请求进入哪个 worker、和哪些请求组成 batch。
• prefill：处理 prompt，生成初始 KV cache。
• KV cache 管理：分配、写入、分页、复用、迁移、释放。
• decode loop：逐 token 生成。
• sampling：top-k/top-p/temperature 等采样。
• streaming：把 token 流式返回用户。
• metrics/tracing：记录 TTFT、TPOT、P99、GPU util、cache usage。

这个岗位关心的是中间这些系统层：

scheduler
prefill/decode
KV cache
data movement
GPU memory
communication
profiling

完整路径：

flowchart LR
    Client[Client] --> FE[Frontend]
    FE --> Tok[Tokenizer]
    Tok --> Router[Router]
    Router --> Sched[Scheduler]
    Sched --> Prefill[Prefill Worker]
    Prefill --> KV[KV Cache Write]
    KV --> Move{KV Transfer?}
    Move -- No --> Decode[Decode Worker]
    Move -- Yes --> NIXL[NIXL / Transfer]
    NIXL --> Decode
    Decode --> Stream[Streaming Tokens]

4.4.2 Prefill 到底做什么

Prefill 的输入是一整段 prompt tokens。它要做：

prompt text
-> tokenizer
-> prompt tokens
-> embedding
-> transformer layer 0 attention/MLP
-> transformer layer 1 attention/MLP
-> ...
-> write K/V for every layer
-> produce state/logits for first decode step

特点：

• token 数多。
• GEMM/attention 计算量大。
• 更容易组成大 batch。
• 更偏 compute-heavy。
• 主要影响 TTFT。
• 会产生后续 decode 依赖的 KV cache。

常见瓶颈：

• prompt 太长。
• batch 中长短 prompt 混合导致 padding/调度不均。
• prefill worker 排队。
• tensor parallel communication。
• GPU memory 临时激增。

4.4.3 Decode 到底做什么

Decode 是循环：

while not finished:
    read KV cache for previous tokens
    run current-token attention/MLP
    sample next token
    append new K/V to KV cache
    stream token to client

特点：

• 每次通常只生成一个 token。
• 每一步依赖前一步，串行性强。
• 反复读 KV cache。
• 更容易 memory-bandwidth-sensitive。
• 更容易被 scheduler overhead 和 synchronization 影响。
• 主要影响 TPOT 和用户感知的流式速度。

4.4.4 TTFT / TPOT / Throughput / P99

TTFT：

TTFT =
frontend queue
+ tokenizer
+ scheduler wait
+ prefill
+ KV allocation / transfer
+ first decode
+ first token streaming

解释：

• TTFT 是用户等第一个 token 的时间。
• 长 prompt 通常会拉高 TTFT。
• scheduler queueing 和 prefill 负载也会拉高 TTFT。
• prefill/decode 分离时，KV transfer 也会进入 TTFT。

TPOT：

TPOT =
decode scheduling
+ KV cache read
+ decode kernel
+ communication if parallel/disaggregated
+ sampling
+ streaming

解释：

• TPOT 是每个 output token 的平均生成时间。
• decode 阶段主导 TPOT。
• KV cache 读、decode kernel、通信和同步都会影响 TPOT。

Throughput：

tokens/sec = total generated tokens / wall-clock time
requests/sec = completed requests / wall-clock time

P99：

P99 latency = 99% requests finish below this latency

P99 常见来源：

• queueing。
• 长 prompt / 长 output。
• cache pressure。
• worker imbalance。
• network transfer。
• synchronization。
• client backpressure。

4.4.5 KV cache 机制

KV cache 公式：

KV bytes =
2 * layers * batch * sequence_length * kv_heads * head_dim * bytes_per_element

为什么是 2：

• Key tensor。
• Value tensor。

为什么和 layers 成正比：

• 每一层 transformer 都有自己的 attention K/V。

为什么和 sequence_length 成正比：

• 每个历史 token 都需要保存 K/V。
• 上下文越长，KV cache 越大。

为什么和 batch 成正比：

• 每个并发请求都有自己的上下文和 KV。

MHA / GQA / MQA 对 KV 的影响：

• MHA：每个 query head 有自己的 K/V，KV heads 多。
• GQA：多个 query heads 共享一组 K/V，KV heads 变少。
• MQA：更多 query heads 共享更少 K/V，KV cache 更小。

KV cache 的系统问题：

• 容量：显存装不下更多并发。
• 碎片化：不同 request 长度不同，连续内存难管理。
• 带宽：decode 每步都读 KV。
• 迁移：prefill 和 decode 分离时 KV 要跨 worker/GPU/node。
• offload：放到 CPU/NVMe 可以省显存，但增加 latency。

4.4.6 Continuous batching / paged attention / speculative decoding

Continuous batching：

• 静态 batching 是一批请求一起开始、一起结束。
• LLM decode 中每个请求 output 长度不同，静态 batch 会浪费。
• Continuous batching 允许请求在 token boundary 动态加入/退出。
• 目标是提高 decode GPU utilization。

Paged attention：

• 把 KV cache 按 block/page 管理。
• 避免为每个 request 分配大块连续显存。
• 减少 fragmentation。
• 支持更多并发和变长 sequence。

Speculative decoding：

• 用小模型 draft 先猜多个 token。
• 大模型 target 验证这些 token。
• 如果接受率高，可以减少昂贵大模型 decode steps。
• 代价是 draft/verify 额外开销和系统复杂度。

4.4.7 Prefill/decode disaggregation

为什么要分离：

• prefill 更适合大 batch、compute-heavy。
• decode 更适合低延迟循环、memory/scheduler-sensitive。
• 不同 worker pool 可以分别优化。

代价：

prefill worker generates KV
-> KV metadata/block ownership
-> KV transfer/exposure
-> decode worker waits for KV
-> decode starts

风险：

• TTFT 增加。
• TPOT 抖动。
• 网络热点。
• cache ownership 复杂。
• worker failure recovery 复杂。

面试关键句：

Prefill/decode disaggregation improves resource specialization, but it turns KV cache into a distributed data movement problem.

4.5 标准英文回答

Prefill vs Decode：

Prefill processes the prompt and builds KV cache, so it is usually more compute-heavy and easier to batch. Decode generates tokens step by step, repeatedly reads KV cache, and is more latency-sensitive. In distributed serving, if prefill and decode are separated, KV cache transfer becomes a data movement problem.

KV cache：

KV cache is both a memory-capacity problem and a data-movement problem. Its size scales with layers, sequence length, concurrency, KV heads, head dimension, and dtype. In disaggregated serving, KV cache may need to move between prefill and decode workers, so I would track cache footprint, fragmentation, placement, transfer latency, TTFT, and TPOT.

High TTFT debug：

I would break TTFT into queueing, tokenization, scheduling, prefill, KV allocation or transfer, first decode, and streaming. Then I would compare normal and slow requests by prompt length, worker placement, batch composition, and cache pressure.

4.6 周末怎么实战搭建

目标：跑出或至少设计一个 LLM serving benchmark，能讲 TTFT/TPOT/P99。

推荐 GPU 环境：

nvidia-smi
python3 --version
pip install vllm

如果 GPU 显存足够，可用小模型：

python -m vllm.entrypoints.openai.api_server \
  --model Qwen/Qwen2.5-0.5B-Instruct \
  --host 0.0.0.0 \
  --port 8000

压测思路：

python -m vllm.benchmarks.benchmark_serving \
  --backend openai \
  --model Qwen/Qwen2.5-0.5B-Instruct \
  --dataset-name random \
  --num-prompts 100 \
  --random-input-len 512 \
  --random-output-len 128 \
  --request-rate 4

你要记录：

• input length
• output length
• request rate
• TTFT
• TPOT
• throughput
• P95/P99
• GPU utilization
• GPU memory usage

如果没 GPU：

• 不要假装跑过。
• 准备实验设计和预期现象：
  • prompt length 变长，TTFT 上升。
  • output length 变长，decode 总时间上升。
  • concurrency 变高，queueing 和 P99 可能上升。
  • KV cache 压力变大，显存占用上升。

4.7 掌握验收

你必须能做到：

• 手画 LLM serving path。
• 90 秒讲 prefill/decode/KV cache。
• 给出 high TTFT / bad TPOT debug checklist。
• 如果有 GPU，展示一次 benchmark 参数和指标。
• 如果没 GPU，能完整讲实验怎么设计、预期结果是什么。

5. 技能 2：Dynamo / NIXL

5.1 JD 要求是什么

JD 直接点名：

• NVIDIA Dynamo
• NVIDIA NIXL
• runtime systems
• communication libraries
• inference/model serving
• data movement

实际考察：

• 你是否知道 NVIDIA 的 distributed inference stack。
• 你是否知道 NIXL 不是 NCCL。
• 你是否能解释 KV cache movement 为什么需要 transfer abstraction。

5.2 你 CV 里有什么

匹配点：

• CV 写了正在 deepening Dynamo/NIXL/UCX concepts。
• 有 LLM inference path、KV cache、batching 背景。
• 有通信路径诊断方法。

缺口：

• 没有 Dynamo/NIXL production ownership。
• 需要用架构图和 data movement 语言补足。

5.3 面试会问什么

• What is Dynamo?
• How is Dynamo different from vLLM or TensorRT-LLM?
• What is NIXL?
• Why is NIXL useful for inference?
• How is NIXL different from NCCL?
• How is NIXL related to UCX?
• What can make a NIXL transfer slow?

5.4 必须掌握的机制

5.4.1 Dynamo 是什么

Dynamo 可以理解成 NVIDIA 面向大规模生成式 AI 推理的 distributed inference orchestration layer。它不是单个 CUDA kernel，也不是单个模型 runtime；它更像把一堆推理相关组件组织起来的系统层：

• 请求入口：接收用户请求，做 admission control、routing、priority。
• 调度层：决定请求去哪个 worker，如何 batch，如何拆分 prefill/decode。
• Worker 层：真正执行 prefill 或 decode，可以挂接 TensorRT-LLM、vLLM、SGLang 等 backend engine。
• 状态和数据移动层：处理 KV cache、intermediate state、GPU buffer、storage/network movement。
• 观测层：暴露 TTFT、TPOT、queueing、GPU utilization、transfer latency、worker health。

面试里不要把 Dynamo 说成“另一个 vLLM”。更准确的表达是：

vLLM / TensorRT-LLM / SGLang 更接近模型执行引擎或 serving backend。
Dynamo 更强调 distributed serving 的 orchestration、routing、disaggregation 和 data movement。

如果对方追问“为什么需要 Dynamo 这种层”，你要从 production serving 的复杂性回答：

• 单机推理优化不等于集群推理优化。
• Prefill 和 decode 的资源特征不同，放在一起会互相干扰。
• KV cache 不是普通 tensor，它是跨请求生命周期存在的 inference state。
• 多 GPU/多节点场景下，瓶颈可能不在 matmul，而在 queueing、KV movement、network、memory pressure。
• 需要一个系统层把 backend engine、调度策略、数据移动、观测、failure handling 统一起来。

5.4.2 Dynamo 在 LLM serving 里解决什么问题

LLM serving 的核心难点不是“跑一次模型”，而是持续处理很多长短不同的请求。问题包括：

• 请求长度差异：有的 prompt 128 tokens，有的 8K tokens。
• 输出长度差异：有的输出 20 tokens，有的输出 2K tokens。
• Prefill 和 decode 不同：prefill 计算密集，decode memory/cache/latency 敏感。
• KV cache 占用大：batch 越大、context 越长，KV cache 越容易成为容量瓶颈。
• 多租户：不同用户、不同优先级、不同 SLA 混在一起。
• 异构环境：不同 GPU、不同网络、不同 worker health。

Dynamo 类系统通常会把问题拆成：

request routing
-> scheduling / batching
-> prefill placement
-> KV cache ownership / transfer
-> decode placement
-> backend execution
-> metrics / autoscaling / failure handling

面试回答时，要把 Dynamo 放在“系统架构”层，而不是“某个具体 kernel 优化”层。

flowchart TB
    Req[User Request] --> Dynamo[Dynamo: Distributed Inference Orchestration]
    Dynamo --> Router[Router / Scheduler]
    Router --> Workers[Prefill / Decode Workers]
    Workers --> Backend[Backend: TensorRT-LLM / vLLM / SGLang]
    Workers --> NIXL[NIXL: Inference Data Movement]
    NIXL --> UCX[UCX]
    NIXL --> GDS[GPUDirect Storage]
    NIXL --> Storage[Storage]
    UCX --> RDMA[RDMA / RoCE / InfiniBand]
    UCX --> TCP[TCP]

5.4.3 NIXL 是什么

NIXL 可以理解成 NVIDIA 面向 inference workload 的 data movement library/abstraction。它关注的是“推理过程中各种状态和数据怎么在 GPU、CPU、网络、存储之间高效移动”。

它解决的问题不是 collective communication，而是 inference state transfer：

• prefill worker 生成 KV cache，decode worker 需要消费。
• GPU memory 里的 buffer 需要跨 GPU/跨节点移动。
• 一些数据可能来自 storage，例如 checkpoint、cache block、offloaded state。
• 上层不应该在每个场景里手写 UCX/RDMA/GDS 细节。

可以这样理解分层：

Application / Serving system
    |
    |  wants to move KV blocks / inference buffers
    v
NIXL
    |
    |  selects or abstracts transport/storage backend
    v
UCX / RDMA / TCP / GPUDirect Storage / local memory

如果面试官问“为什么不用自己直接调 UCX/RDMA”，回答重点是：

• 上层 serving 关心的是 inference object，比如 KV block、source/destination buffer、transfer completion。
• UCX/RDMA 关心的是低层 transport endpoint、registered memory、work request、completion。
• 直接把 UCX/RDMA 暴露给 serving scheduler，会让系统复杂度、可移植性、debug 成本变高。
• NIXL 的价值是把 data movement 抽象成 serving-friendly 的接口，同时可以接不同 backend。

5.4.4 为什么 inference 需要专门的数据移动抽象

训练里的典型通信是 collective：

all-reduce gradients
reduce-scatter tensor shards
all-gather parameters/activations

推理里的典型数据移动更像 point-to-point 或 state movement：

prefill GPU A 生成 request X 的 KV blocks
decode GPU B 需要 request X 的 KV blocks
worker C 要恢复或迁移 request state
cache manager 要把 block 从 GPU memory offload 到 CPU/storage

这些 movement 的特征：

• object 更碎：KV blocks 可能按 page/block 管理。
• 生命周期更动态：request 来了创建，请求结束释放，迁移时移动。
• 和调度耦合强：移动慢会直接影响 TTFT/TPOT。
• 需要异步：transfer 要和 compute overlap，否则 GPU 或网络会空等。
• backend 多样：同机 GPU、跨节点 RDMA、CPU staging、storage 都可能出现。

所以 NIXL 的核心价值不是“比 NCCL 更快”，而是“语义不同、抽象不同、优化目标不同”。

5.4.5 NIXL transfer lifecycle

NIXL transfer lifecycle：

describe/register source buffer
describe/register destination buffer
create transfer descriptor
select backend
submit async transfer
poll/check completion
reuse/release resource

每一步你都要知道是什么意思：

1. describe/register source buffer：告诉底层这块源内存在哪里，大小多少，是否需要注册/pin，能不能被 NIC 或 backend 访问。
2. describe/register destination buffer：告诉底层写到哪里，是否是 GPU memory、CPU memory、storage-backed buffer。
3. create transfer descriptor：构造一次 transfer 的元信息，包括 source、destination、length、offset、backend preference、flags。
4. select backend：根据拓扑和能力选择 UCX/RDMA、TCP、GDS 或本地 copy。
5. submit async transfer：提交后不要同步等待，理想情况是让 compute 和 transfer overlap。
6. poll/check completion：通过 completion queue 或 progress engine 确认 transfer 完成。
7. reuse/release resource：频繁注册/释放很贵，应该复用 metadata、buffer、registration。

面试追问“transfer 慢怎么办”，你要逐层拆：

application object size
-> batching / block layout
-> source/destination memory type
-> registration/cache behavior
-> selected backend
-> topology
-> async overlap
-> completion/progress
-> network congestion

5.4.6 NIXL vs NCCL

NIXL vs NCCL：

不要只背表格，要能解释“为什么不能互相替代”：

• NCCL 强在多个 GPU 之间做 collective communication，典型是训练或 tensor-parallel inference 里的 all-reduce/all-gather/reduce-scatter。
• NIXL 强在 inference runtime 需要移动某个 request 的状态，比如 KV cache block、buffer、storage data。
• NCCL 的通信参与者通常是一组 rank，操作有 collective 语义。
• NIXL 的参与者更像 source/destination endpoint，操作更像 transfer 语义。
• NCCL 更像“大家一起做一次数学/张量集合操作”；NIXL 更像“把这个 inference object 从这里搬到那里”。

一句话回答：

NCCL is for collective tensor communication across ranks; NIXL is for inference-oriented data movement such as KV cache or request state transfer. They can both use high-performance transports, but their semantics and integration points are different.

5.4.7 NIXL 和 UCX 的关系

UCX 是通信框架，提供 unified communication abstraction，底层可走 RDMA、TCP、shared memory、CUDA IPC 等 transport。

NIXL 可以把 UCX 当成 transport backend，但 NIXL 关注的上层语义更贴近 inference data movement。

类比：

NIXL: I need to move this inference buffer/KV object.
UCX: I can send/put/get bytes between endpoints efficiently.
RDMA: NIC can directly move data to/from registered memory.

如果被问“UCX 已经抽象 transport 了，为什么还要 NIXL”，答：

• UCX 抽象的是 communication transport。
• NIXL 抽象的是 inference data movement lifecycle。
• Serving system 需要知道 request state、KV block、GPU/storage buffer、completion semantics。
• NIXL 可以在 UCX 之上组织更适合推理系统的 API 和 resource management。

5.4.8 NIXL 慢的典型原因

你要准备一个 debug checklist：

1. Transfer 太碎：每个 KV block 太小，per-transfer overhead 高。
2. 没有 batch transfer：大量小 transfer 没有合并。
3. 频繁 registration：memory registration 反复发生，耗时明显。
4. Backend 选错：本来应该 RDMA/GDR，实际走 TCP 或 CPU staging。
5. 拓扑不佳：GPU 和 NIC 不在同一 PCIe root complex，跨 NUMA。
6. 没有 overlap：decode 等 transfer，transfer 等 compute，pipeline 断开。
7. Completion 开销高：polling/progress 模型不合适。
8. 网络拥塞：RoCE fabric 下 PFC/ECN/QoS 配置不佳。
9. Buffer layout 不好：KV block layout 导致 copy/packing 开销。
10. Synchronization 过多：每次 transfer 后全局 sync，破坏并发。

英文回答模板：

I would first verify the actual transport path and memory type, then check transfer granularity, registration reuse, topology, and overlap with compute. If the workload issues many small KV-block transfers, the bottleneck may be per-transfer overhead rather than raw bandwidth. I would also check whether the transfer silently falls back to TCP or CPU staging.

5.4.9 这个技能和你 CV 怎么接

你的 CV 不是 Dynamo/NIXL owner，所以回答时不要假装 production ownership。最稳的说法是：

I have not owned Dynamo/NIXL in production, but my relevant experience is in
performance-sensitive serving systems, GPU profiling, and communication-path
debugging. For this role, I would approach Dynamo/NIXL as a runtime/data-movement
architecture problem: identify the serving critical path, isolate KV/state
movement, measure backend behavior, and validate with microbenchmarks plus
end-to-end serving metrics.

这样既诚实，又把经验迁移到 JD 需要的能力上。

5.5 标准英文回答

Dynamo is the distributed inference orchestration layer. It coordinates routing, scheduling, prefill/decode workers, backend engines, and data movement. NIXL is the inference data movement abstraction, especially useful for moving KV cache or inference state. UCX can be a lower-level transport backend. NCCL provides collective communication, while NIXL focuses more on inference-oriented point-to-point data movement.

5.6 周末怎么实战学习

2 天内不建议试图完整部署 Dynamo。目标是掌握架构和数据路径。

实战产出：

• 画 Dynamo -> NIXL -> UCX/RDMA/GDS 图。
• 写一页 NIXL transfer lifecycle。
• 写一个 KV cache transfer 场景：

prefill worker on GPU0
-> writes KV blocks
-> decode worker on GPU1/node1 needs KV
-> NIXL describes source/destination
-> UCX/RDMA backend transfers
-> decode starts

你要解释慢点：

• registration overhead。
• too many small transfers。
• backend selection wrong。
• no overlap with compute。
• synchronization。
• topology。
• progress/completion overhead。

5.7 掌握验收

• 能解释 Dynamo vs backend engine。
• 能解释 NIXL vs NCCL。
• 能解释 NIXL 和 KV cache movement 的关系。
• 能解释 NIXL transfer 慢怎么查。

6. 技能 3：NCCL / Collectives / Parallelism

6.1 JD 要求是什么

JD 关键词：

• AI communication libraries
• NCCL, UCX, MPI and equivalents
• AI scaling
• Parallelism of AI frameworks
• deep learning training workloads

6.2 你 CV 里有什么

匹配点：

• 分布式系统通信路径诊断。
• 高并发、routing、backpressure、tail latency。
• NCCL concepts 学习。

缺口：

• 没有明确多 GPU/NCCL production 经验。
• 需要用 nccl-tests 或至少完整 debug playbook 弥补。

6.3 面试会问什么

• What is NCCL?
• What is all-reduce?
• Why is all-reduce important for data parallel training?
• What is reduce-scatter?
• What is all-gather?
• Ring all-reduce vs tree all-reduce?
• DP/TP/PP/FSDP 的通信模式是什么？
• all-reduce 随节点数增加非线性变慢怎么查？

6.4 必须掌握的机制

6.4.1 NCCL 是什么

NCCL = NVIDIA Collective Communication Library。

它解决的问题：

• 多 GPU 之间要交换 tensor。
• 多节点训练时要同步 gradients。
• tensor parallel / FSDP 等并行策略需要频繁通信。
• 通信要利用 NVLink、NVSwitch、PCIe、InfiniBand、RoCE 等拓扑。

NCCL 不是：

• 不是训练框架。
• 不是模型 serving framework。
• 不是 UCX。

NCCL 是：

• GPU collective communication library。
• 提供 all-reduce、all-gather、reduce-scatter 等 collective。
• 关注 GPU-GPU 高性能通信。

6.4.2 Collective 语义

Collectives：

broadcast: one rank -> all ranks
reduce: all ranks -> one rank
all-reduce: all ranks -> all ranks
reduce-scatter: reduce then scatter shards
all-gather: gather shards to all ranks
all-to-all: every rank sends distinct data to every other rank

更具体解释：

• broadcast：一个 rank 有数据，所有 rank 都拿到。
• reduce：所有 rank 提供数据，结果只到一个 rank。
• all-reduce：所有 rank 提供数据，所有 rank 都拿到 reduce 后结果。
• reduce-scatter：先 reduce，再把结果切片分给不同 rank。
• all-gather：每个 rank 有一片，最后所有 rank 都拿到完整结果。
• all-to-all：每个 rank 给每个其他 rank 发不同内容，网络压力最大。

6.4.3 All-reduce 为什么重要

Data parallel training 中：

GPU0: model replica + batch shard -> gradient0
GPU1: model replica + batch shard -> gradient1
GPU2: model replica + batch shard -> gradient2
GPU3: model replica + batch shard -> gradient3

all-reduce(gradient0..3)
-> every GPU gets same averaged/summed gradient
-> every GPU updates weights consistently

如果 all-reduce 慢：

• GPU 计算完 backward 后等待通信。
• scaling efficiency 下降。
• 节点越多，同步成本越明显。

6.4.4 Ring all-reduce

Ring all-reduce 两个阶段：

Phase 1: reduce-scatter
Phase 2: all-gather

直觉：

• 把大 buffer 切成 chunks。
• 每个 rank 只和相邻 rank 通信。
• reduce-scatter 后，每个 rank 拿到一部分 reduced result。
• all-gather 后，每个 rank 拿到完整 result。

每个 rank 传输量近似：

2 * (N - 1) / N * message_size

优点：

• 大消息 bandwidth utilization 好。
• 每个 rank 持续发送/接收。

缺点：

• step 数随 rank 增加。
• 小消息 latency 可能差。
• slow link / bad topology 会拖累整体。

Parallelism：

Ring all-reduce：

flowchart LR
    RS[Reduce-Scatter Phase] --> AG[All-Gather Phase]
    AG --> Full[Every Rank Has Full Reduced Result]

6.4.5 Parallelism 怎么对应通信

Data Parallel：

• 切 data batch。
• 每个 GPU 有完整模型。
• backward 后同步 gradients。
• 通信：all-reduce / reduce-scatter。

Tensor Parallel：

• 切 layer 内 tensor/matrix。
• 每个 GPU 算一部分。
• layer 内需要合并结果。
• 通信：all-reduce / all-gather / reduce-scatter。
• 风险：通信频率高，容易进 critical path。

Pipeline Parallel：

• 切 layers。
• GPU0 跑前几层，GPU1 跑后几层。
• micro-batch 在 stage 间流动。
• 通信：activation / gradient transfer。
• 风险：pipeline bubble。

FSDP：

• shard parameters、gradients、optimizer states。
• forward 前 all-gather params。
• backward 后 reduce-scatter grads。
• 目标：省显存。
• 代价：更多通信。

6.4.6 Slow all-reduce 怎么定位

先分类：

单机慢还是多机慢？
小 message 慢还是大 message 慢？
所有 collective 慢还是只有 all-reduce 慢？
是否和节点数非线性相关？

小 message 慢：

• latency。
• launch overhead。
• algorithm choice。
• CPU/proxy thread。
• synchronization。

大 message 慢：

• bandwidth。
• link speed。
• congestion。
• topology。
• transport fallback。

单机慢：

• PCIe topology。
• NVLink/NVSwitch。
• rank mapping。
• GPU peer access。

多机慢：

• IB/RoCE。
• GPU-NIC affinity。
• network congestion。
• TCP fallback。
• switch oversubscription。

工具：

NCCL_DEBUG=INFO
NCCL_DEBUG_SUBSYS=INIT,GRAPH,COLL,NET
nvidia-smi topo -m
nccl-tests all_reduce_perf
network counters
Nsight Systems

6.5 标准英文回答

All-reduce reduces data across ranks and returns the result to every rank. In data-parallel training, it synchronizes gradients. Ring all-reduce is bandwidth-efficient for large messages because it uses reduce-scatter followed by all-gather, but small-message latency can suffer as rank count grows. If all-reduce is slow, I would compare single-node and multi-node behavior, sweep message sizes, inspect NCCL logs, rank mapping, GPU-NIC affinity, topology, and network counters.

6.6 周末怎么实战搭建

如果有 NVIDIA GPU：

git clone https://github.com/NVIDIA/nccl-tests.git
cd nccl-tests
make MPI=0
./build/all_reduce_perf -b 8 -e 128M -f 2 -g 1

如果有多 GPU：

./build/all_reduce_perf -b 8 -e 1G -f 2 -g 2
./build/all_reduce_perf -b 8 -e 1G -f 2 -g 4

记录：

• message size
• time
• algbw
• busbw
• number of GPUs
• 是否单机

设置 debug：

export NCCL_DEBUG=INFO
export NCCL_DEBUG_SUBSYS=INIT,GRAPH,COLL,NET
./build/all_reduce_perf -b 8 -e 128M -f 2 -g 1

如果没 GPU：

• 阅读 nccl-tests all_reduce_perf 输出格式。
• 准备 message-size sweep 的实验设计。
• 准备 single-node vs multi-node 的排查顺序。

6.7 掌握验收

• 能画 all-reduce。
• 能解释 reduce-scatter + all-gather。
• 能解释 DP/TP/PP/FSDP 通信差异。
• 能给 slow all-reduce debug checklist。
• 最好能拿出一次 nccl-tests 输出或实验设计。

7. 技能 4：RDMA / RoCE / UCX / GPUDirect

7.1 JD 要求是什么

JD 关键词：

• networking
• storage
• UCX
• defining and using hardware features
• performance profiling and optimization

7.2 你 CV 里有什么

匹配点：

• 高并发通信路径。
• routing、queueing、backpressure、tail latency。
• Linux 系统诊断。

缺口：

• gRPC/Kafka 不是 RDMA/NCCL。
• 需要承认没做过大规模 RDMA GPU cluster，但能讲 data path 和 debug。

7.3 面试会问什么

• RDMA 和 TCP 有什么区别？
• RDMA 为什么低延迟？
• 为什么需要 memory registration？
• QP/CQ/MR 是什么？
• RoCE 为什么需要 PFC/ECN？
• UCX 是什么？
• UCP/UCT 是什么？
• UCX 慢怎么查？
• GPUDirect RDMA 解决了什么 copy？
• GPU-NIC affinity 为什么重要？

7.4 必须掌握的机制

7.4.1 TCP 为什么相对慢

传统 TCP socket 路径通常包含：

• application buffer。
• syscall。
• kernel TCP/IP stack。
• kernel buffers。
• NIC DMA。
• remote kernel stack。
• remote application buffer。

问题：

• CPU 参与多。
• kernel data path 长。
• copy / buffer management 多。
• latency 更高。
• 高吞吐时 CPU 开销明显。

这不是说 TCP 不好，而是 AI/HPC 场景里，GPU/节点之间的高频大流量通信需要更低 overhead 的路径。

7.4.2 RDMA 是什么

RDMA = Remote Direct Memory Access。

核心思想：

让 NIC 直接读写本地/远端已经注册的 memory
减少 kernel data path
减少 CPU copy
降低 latency
提高 throughput

RDMA 的关键不是“网络更快”，而是：

• data path 更短。
• CPU involvement 更少。
• memory 已注册，NIC 可以 DMA。

TCP vs RDMA：

flowchart TB
    subgraph TCP[TCP Path]
        A[Application] --> K[Kernel TCP/IP Stack]
        K --> B[Kernel Buffers]
        B --> N[NIC]
        N --> Net[Network]
        Net --> RK[Remote Kernel]
        RK --> RA[Remote Application]
    end
    subgraph RDMA[RDMA Path]
        M[Registered Memory] --> R[RNIC DMA]
        R --> Net2[Network]
        Net2 --> RR[Remote RNIC DMA]
        RR --> RM[Remote Registered Memory]
    end

7.4.3 为什么需要 memory registration

NIC 不能随便访问进程内存。memory registration 做几件事：

• pin 住内存，避免被 OS 移走。
• 建立虚拟地址到物理地址 / DMA 地址映射。
• 给 NIC 一个访问 key。
• 定义这块 memory 的访问权限。

代价：

• registration 本身有开销。
• 高频注册/注销会很慢。
• 高性能系统通常复用 registered buffers。

7.4.4 RDMA verbs 对象

RDMA objects：

MR = Memory Region
QP = Queue Pair
CQ = Completion Queue
WQE = Work Queue Element
CQE = Completion Queue Entry
PD = Protection Domain

更具体：

• MR：注册过的内存区域。
• QP：Queue Pair，包含 send queue / receive queue。
• CQ：Completion Queue，完成事件放这里。
• WQE：提交给 queue 的 work request。
• CQE：完成后的 completion entry。
• PD：隔离资源权限的 protection domain。

RDMA write 流程：

1. allocate local buffer
2. register local memory -> lkey
3. get remote address and rkey
4. create/connect QP
5. post RDMA write WQE
6. RNIC DMA reads local memory
7. packets cross network
8. remote RNIC writes remote memory
9. CQE appears
10. application polls completion

7.4.5 RoCE 为什么麻烦

RoCE = RDMA over Converged Ethernet。

它把 RDMA 跑在 Ethernet 上，但 Ethernet 默认不是 lossless。RDMA 对 packet loss 很敏感，所以 RoCE 常需要：

• PFC：Priority Flow Control。
• ECN：Explicit Congestion Notification。
• congestion control。
• switch buffer / QoS 配置。

常见问题：

• congestion 导致 tail latency。
• PFC 配错导致 head-of-line blocking。
• incast 造成 packet drop 或 pause storm。
• 网络共享导致抖动。

面试关键句：

RoCE gives RDMA semantics over Ethernet, but it requires careful congestion and lossless-network configuration. Otherwise performance can collapse under congestion.

7.4.6 UCX 是什么

UCX = Unified Communication X。

它解决的问题：

• 上层框架不想自己适配 RDMA、TCP、shared memory、CUDA IPC 等多种 transport。
• UCX 提供统一通信抽象。
• 根据 message size、memory type、topology 选择 transport。

UCX layering：

Application
-> UCP: high-level protocol API
-> UCT: low-level transport API
-> Transport: RDMA / TCP / shared memory / CUDA IPC

分层：

• UCP：高层 protocol API。应用通常用这一层。
• UCT：底层 transport API。更靠近硬件能力。
• UCS：工具/基础设施层。

UCP 里常见概念：

• worker。
• endpoint。
• tag send/recv。
• active message。
• RMA。
• atomic。
• progress。

7.4.7 GPUDirect RDMA 是什么

没有 GPUDirect RDMA：

NIC -> host memory -> GPU memory

有 GPUDirect RDMA：

NIC -> GPU memory

它解决：

• host memory staging。
• CPU copy/coordination overhead。
• GPU-to-GPU 跨节点通信路径过长。

注意：

• CPU control path 仍然存在。
• GPU memory 仍需 registration/mapping。
• GPU-NIC topology 很重要。
• 软件栈必须真的启用 direct path。

GPUDirect RDMA：

flowchart TB
    subgraph Without[Without GPUDirect]
        NIC1[NIC] --> Host[Host Memory]
        Host --> GPU1[GPU Memory]
    end
    subgraph With[With GPUDirect RDMA]
        NIC2[NIC] --> GPU2[GPU Memory]
    end

7.4.8 UCX/RDMA 慢怎么查

排查顺序：

1. transport selected?
2. TCP fallback?
3. RDMA active?
4. GPU memory recognized?
5. memory registration overhead?
6. message size small or large?
7. worker progress delayed?
8. NUMA placement?
9. GPU-NIC topology?
10. congestion counters?

不同症状：

• 小消息慢：latency、progress、CPU scheduling、endpoint overhead。
• 大消息慢：bandwidth、link speed、congestion、PCIe topology。
• GPU memory 慢：没有 GPUDirect、fallback staging、registration/mapping。
• 多节点慢：RoCE/IB fabric、PFC/ECN、switch contention。

7.5 标准英文回答

RDMA reduces CPU and kernel involvement in the data path by allowing the NIC to directly access registered memory. Compared with TCP sockets, it can reduce copies and latency. The trade-off is complexity: memory registration, queue pairs, completion handling, topology, and congestion configuration all become important. For UCX, I would first check selected transport, TCP fallback, GPU memory handling, registration overhead, progress, message size, and topology.

7.6 周末怎么实战搭建

真正 RDMA 需要 IB/RoCE 网卡和网络，周末不一定有。你可以做两层准备：

可实操层：

$ # Linux GPU machine
ucx_info -d
ucx_info -v

如果能装 UCX perftest：

ucx_perftest -t tag_bw -s 1048576 localhost
ucx_perftest -t tag_lat -s 8 localhost

可解释层：

• 画 TCP path vs RDMA path。
• 画 GPUDirect RDMA path。
• 准备 UCX slow transfer checklist。

UCX/RDMA 慢查什么：

selected transport
TCP fallback
RDMA active
GPU memory support
memory registration
message size
worker progress
NUMA
GPU-NIC topology
network congestion

7.7 掌握验收

• 能解释 TCP vs RDMA。
• 能解释 QP/CQ/MR。
• 能解释 UCX UCP/UCT。
• 能解释 GPUDirect RDMA。
• 能给 UCX/RDMA 慢的 debug checklist。

8. 技能 5：GPUNetIO

8.1 JD 要求是什么

JD 直接提到 GPUNetIO。它考察你是否理解 GPU-centric networking，而不是只知道传统 CPU networking。

8.2 你 CV 里有什么

匹配点：

• GPU workload profiling。
• 通信路径诊断。
• 系统性能优化。

缺口：

• 没有 GPUNetIO 实战。
• 需要能清楚说明它解决什么问题、何时值得用、何时代价太大。

8.3 面试会问什么

• What is GPUNetIO?
• How is GPUNetIO different from GPUDirect RDMA?
• Why put networking work closer to GPU?
• When is GPUNetIO not a good fit?

8.4 必须掌握的机制

8.4.1 GPUNetIO 是什么

GPUNetIO 可以理解为 NVIDIA DOCA 体系里让 GPU 更直接参与网络数据处理的一套 programming model/API。它关注的是 GPU-centric networking：不是所有网络 packet/data 都必须先由 CPU 处理完，再交给 GPU。

传统路径通常是：

NIC receives packets
-> CPU driver / kernel / user-space networking stack
-> CPU prepares metadata or copies data
-> GPU consumes data

GPU-centric path 的目标是：

NIC / DOCA-managed memory / queues
-> GPU kernel polls or processes network-visible data
-> GPU directly consumes or transforms data

关键点：

• GPUDirect RDMA 是 data-path capability：NIC 能直接读写 GPU memory。
• GPUNetIO 是 programming model：让 GPU kernel 更主动地参与网络收发、polling、metadata processing。
• DOCA 是更大的 SDK/framework，GPUNetIO 是其中面向 GPU 网络处理的部分能力。

面试里最重要的是不要把 GPUNetIO 和 GPUDirect RDMA 混为一谈。

flowchart TB
    subgraph CPUPath[CPU-Centric Networking]
        NIC1[NIC Receives Packet] --> CPU[CPU Polls / Processes]
        CPU --> Meta[CPU Coordinates Metadata / Copy]
        Meta --> GPU1[GPU Consumes Data]
    end
    subgraph GPUPath[GPU-Centric Networking]
        NIC2[NIC / DOCA Buffers] --> Kernel[CUDA Kernel Polls / Processes]
        Kernel --> GPU2[GPU Consumes Network Data Directly]
    end

8.4.2 为什么需要 GPU-centric networking

在很多传统服务里，CPU 处理网络完全合理，因为 CPU 擅长控制逻辑、协议处理、系统调用、内存管理。但 AI/GPU networking 场景有几个变化：

• 数据最终消费者是 GPU。
• 数据量大，CPU copy/staging 会成为瓶颈。
• 延迟敏感，CPU critical path 上的调度、interrupt、copy 都可能增加 jitter。
• GPU kernel 可能需要尽快看到网络到达的数据。
• 某些 workloads 需要 packet/data processing 和 GPU compute 紧密耦合。

所以 GPUNetIO 的目标不是“永远替代 CPU networking”，而是在特定场景下减少 CPU 在 critical path 上的参与，让 GPU 直接处理网络相关数据。

典型收益：

• 减少 CPU critical path。
• 降低 packet/data processing latency。
• GPU 直接消费网络数据。
• 减少 CPU-GPU synchronization。
• 某些场景可以更好地 overlap network and GPU compute。

8.4.3 GPUNetIO vs GPUDirect RDMA

这是高概率追问。

可以这样答：

GPUDirect RDMA allows the NIC to directly access GPU memory. GPUNetIO goes further at the programming-model level: it enables GPU kernels to participate in networking work such as polling or processing network-visible buffers. GPUDirect RDMA is about the data path; GPUNetIO is about how the GPU is programmed into the networking pipeline.

8.4.4 什么时候值得用

GPUNetIO 不是万金油。你要能说出使用条件：

适合：

• 网络数据最终在 GPU 上处理。
• CPU involvement 明显在 latency critical path 上。
• packet/data processing 比较规则，适合 GPU 并行处理。
• 端到端 profiling 证明 CPU polling/copy/sync 是瓶颈。
• workload 对 tail latency 或 throughput 极端敏感。
• 系统环境允许使用 DOCA/NVIDIA networking stack。

不适合：

• 业务逻辑复杂、分支多、状态机重，更适合 CPU。
• 数据量小，CPU path 已经足够快。
• CPU 不是瓶颈，瓶颈在 GPU compute、memory bandwidth 或网络 fabric。
• 系统需要强可移植性，不能依赖特定 NIC/driver/DOCA 环境。
• 团队没有维护 GPU-side networking code 的能力。

面试官如果问“你会不会直接建议用 GPUNetIO”，不要直接说会。更强的回答是：

I would first profile the CPU-centric path. If CPU polling/copy/synchronization
is on the critical path and the data is consumed by GPU anyway, I would prototype
GPUNetIO. Otherwise the extra complexity may not be justified.

8.4.5 GPUNetIO 的代价和风险

代价：

• 编程复杂。
• debug 难。
• 环境依赖强。
• 占用 GPU cycles。
• 可观测性比普通 CPU networking 更难。
• GPU kernel polling 可能影响 SM 资源和其他 compute kernel。
• 错误处理、backpressure、completion semantics 更复杂。
• 和 CUDA stream/event、NIC queue、memory consistency 的关系需要非常清楚。

这里有一个很重要的系统设计点：

把工作从 CPU 移到 GPU，不代表免费。
它只是把瓶颈从 CPU path 转移到 GPU resource / memory consistency / queue management。

所以设计时必须比较：

• CPU saved time。
• GPU cycles consumed。
• Latency improvement。
• Throughput improvement。
• Tail latency。
• Operational complexity。
• Debuggability。

8.4.6 面试会怎么深挖

可能追问 1：如果 GPU kernel 在 poll network queue，会不会浪费 GPU？

回答：

Yes, polling can consume GPU resources. That is why I would only use it when CPU involvement is truly on the critical path and the latency/throughput gain justifies the SM occupancy cost. I would measure whether the polling kernel interferes with main compute kernels.

可能追问 2：GPUNetIO 和 DPDK 像不像？

回答：

Conceptually both try to reduce traditional kernel-networking overhead and expose a lower-level data path. But DPDK is CPU/user-space packet processing, while GPUNetIO is about bringing the GPU into the networking path, especially when the data will be consumed by GPU workloads.

可能追问 3：GPUNetIO 在 LLM serving 里一定有用吗？

回答：

Not necessarily. LLM serving bottlenecks are often scheduling, KV cache memory, decode efficiency, or collective communication. GPUNetIO is relevant only if network data handling or CPU-mediated data movement becomes part of the critical path. I would not assume it helps without profiling.

可能追问 4：如果网络到 GPU 了，为什么还需要 CPU？

回答：

CPU may still handle control-plane logic, request routing, admission control, error handling, and orchestration. GPUNetIO is mainly about optimizing selected data-plane work, not removing CPU from the whole system.

8.4.7 两天内怎么补到面试可用

周末不建议硬搭完整 GPUNetIO，因为环境依赖太强，可能浪费时间。你要做的是构建“评估能力”：

1. 画清 CPU-centric path 和 GPU-centric path。
2. 明确 GPUDirect RDMA 与 GPUNetIO 区别。
3. 写一个 prototype design，而不是声称跑过生产。
4. 准备回答“什么时候不用”。

最小 prototype design：

Goal:
  Reduce CPU involvement in network-to-GPU data path.

Baseline:
  NIC -> CPU/user-space networking -> CPU metadata processing -> cudaMemcpy / GPU consume.

Prototype:
  Use DOCA/GPUNetIO-compatible path where GPU kernel polls/processes network-visible buffers.

Metrics:
  end-to-end latency, p99 latency, CPU utilization, GPU occupancy,
  network throughput, GPU kernel interference, dropped/backpressured work.

Decision:
  Ship only if p99/throughput improves enough and GPU-side cost is acceptable.

8.4.8 和你 CV 怎么接

你的强项是 performance/debug/system architecture，不是 GPUNetIO API 细节。可以这样接：

My direct production experience is not GPUNetIO-specific, but I have worked on
performance-sensitive data paths, GPU profiling, and communication bottleneck
analysis. For GPUNetIO, I would evaluate it as a data-plane optimization:
first prove CPU-mediated networking is on the critical path, then prototype
GPU-centric polling/processing, and finally compare p99 latency, throughput,
GPU occupancy, and operational complexity.

8.5 标准英文回答

GPUNetIO is not just GPUDirect RDMA. GPUDirect RDMA enables NIC access to GPU memory, while GPUNetIO gives a programming model for GPU-centric networking. I would use it only when reducing CPU involvement in the critical path produces measurable latency or throughput benefits.

8.6 周末怎么学习

不建议周末搭完整 DOCA/GPUNetIO 环境。目标是能讲清：

• CPU-centric path。
• GPU-centric path。
• GPUDirect RDMA vs GPUNetIO。
• 使用场景和代价。

产出：

• 画上面的 Mermaid 图。
• 写 5 句英文解释。
• 准备“不熟但知道怎么评估”的回答。

8.7 掌握验收

• 能解释 GPUNetIO 是 programming/API framework。
• 能解释 GPUDirect RDMA 是 data-path capability。
• 能说什么时候值得用，什么时候不值得用。

9. 技能 6：CUDA / Nsight / GPU Performance

9.1 JD 要求是什么

JD 要求：

• C++ / Python。
• ideally CUDA or other GPU programming models。
• performance profiling and optimization。
• defining and using hardware features。

9.2 你 CV 里有什么

匹配点：

• Vulkan/WebGPU。
• Nsight/RenderDoc。
• GPU workload profiling。
• C++/Python/Linux。

缺口：

• CUDA kernel 经验不够明确。
• Nsight Compute 证据不足。

你的跨平台 GPU 经验怎么迁移：

面试表达重点：

不要说“我做过 Vulkan/WebGPU，所以等于会 CUDA”。
要说“我理解 GPU workload profiling 和 memory/resource trade-off，
现在用 CUDA/Nsight 把这些经验映射到 NVIDIA stack”。

英文回答：

My prior GPU-adjacent work was more Vulkan/WebGPU and profiling oriented rather than CUDA production ownership. The transferable part is understanding GPU timelines, memory/resource trade-offs, dispatch behavior, and bottleneck isolation. For this role, I would validate the NVIDIA-specific side with CUDA kernels, Nsight Systems, Nsight Compute, and communication benchmarks.

9.3 面试会问什么

• CUDA execution model 是什么？
• grid/block/thread/warp/SM 是什么？
• GPU memory hierarchy 是什么？
• memory coalescing 是什么？
• occupancy 为什么不是越高越好？
• warp divergence 是什么？
• shared memory bank conflict 是什么？
• Nsight Systems vs Nsight Compute？
• 怎么判断 memory-bound vs compute-bound？
• pinned memory 为什么重要？

9.4 必须掌握的机制

9.4.1 CUDA execution model

CUDA 代码以 kernel 的形式运行在 GPU 上。

层次：

kernel launch
-> grid
-> block
-> thread
-> warp
-> SM

解释：

• grid：一次 kernel launch 的所有 blocks。
• block：一组 threads，可以共享 shared memory，可以 __syncthreads()。
• thread：编程视角的执行单元。
• warp：通常 32 个 threads，是硬件调度基本单位。
• SM：Streaming Multiprocessor，执行 warps。

为什么 GPU 需要很多 threads：

• GPU memory latency 高。
• 当一个 warp 等 memory，SM 可以切到其他 ready warp。
• 这叫 latency hiding。

flowchart TB
    Kernel[Kernel Launch] --> Grid[Grid]
    Grid --> Block[Thread Blocks]
    Block --> Thread[Threads]
    Thread --> Warp[Warps]
    Warp --> SM[Streaming Multiprocessors]

9.4.2 GPU memory hierarchy

从快到慢：

register
shared memory
L1/L2 cache
global memory / HBM
host memory
remote memory / storage / network

Registers：

• 每个 thread 私有。
• 最快。
• 数量有限。
• register pressure 过高会降低 occupancy。

Shared memory：

• block 内共享。
• 程序员显式使用。
• 适合 tile / reuse。
• 可能有 bank conflict。

Global memory：

• GPU 显存。
• 容量大。
• latency 高。
• coalescing 很重要。

Host memory：

• CPU 内存。
• GPU 访问更慢。
• H2D/D2H copy 成本高。
• pinned memory 可提升 DMA/copy 性能。

Memory hierarchy：

flowchart TB
    Thread[Thread] --> Reg[Registers]
    Block[Thread Block] --> Shared[Shared Memory]
    SM[SM] --> L1[L1 Cache]
    L1 --> L2[L2 Cache]
    L2 --> Global[Global GPU Memory / HBM]
    Global --> Host[Host Memory]

9.4.3 常见 CUDA 性能问题

Memory coalescing：

• 一个 warp 内连续 threads 访问连续地址。
• 可以合并 memory transaction。
• 不 coalesced 会导致更多 memory transaction。

Warp divergence：

• 同一个 warp 的 threads 走不同 branch。
• GPU 可能串行执行不同路径。
• 有些 lanes inactive，效率下降。

Shared memory bank conflict：

• shared memory 分 bank。
• 同一 warp 多个 threads 访问同一 bank 的不同地址会冲突。
• 访问被串行化。

Occupancy：

• active warps / max active warps。
• 高 occupancy 可以隐藏 latency。
• 但不是越高越好。
• 更多 registers/shared memory 可能降低 occupancy，但减少 global memory access，整体更快。

Pinned memory：

• page-locked host memory。
• 支持更高效 DMA。
• 支持更可靠的 async copy。
• 比 pageable memory 更适合 H2D/D2H 大量传输。

CUDA stream：

• 一条有序执行队列。
• 不同 streams 可能 overlap。
• 可用于 copy/compute overlap。

CUDA event：

• 计时。
• stream 间同步。
• 判断 async operation 完成。

9.4.4 Nsight Systems vs Nsight Compute

Nsight workflow：

Nsight Systems:
  timeline, CPU/GPU overlap, memcpy, sync, idle gaps

Nsight Compute:
  kernel metrics, occupancy, memory throughput, warp stalls

Nsight Systems 看系统级 timeline：

• CPU thread。
• CUDA API。
• kernel launch。
• H2D/D2H memcpy。
• synchronization。
• GPU idle gap。
• copy/compute overlap。

Nsight Compute 看单 kernel：

• occupancy。
• SM utilization。
• memory throughput。
• warp stall reasons。
• instruction mix。
• shared memory behavior。
• source-level metrics。

正确 workflow：

先用 Nsight Systems 找时间花在哪里
-> 如果是 kernel 慢
-> 用 Nsight Compute 看 kernel 为什么慢
-> 根据 memory-bound / compute-bound 选择优化方向

9.4.5 Memory-bound vs compute-bound

Memory-bound 症状：

• memory bandwidth 接近上限。
• SM compute utilization 不高。
• warp stall reason 指向 memory dependency。
• 优化 arithmetic 没用。

优化方向：

• coalesced access。
• 减少 global load/store。
• shared memory tiling。
• 改 data layout。
• vectorized load/store。

Compute-bound 症状：

• SM compute pipeline utilization 高。
• memory bandwidth 不饱和。
• tensor core / instruction throughput 是瓶颈。

优化方向：

• 使用 tensor cores。
• 提高 arithmetic intensity。
• 改 tile size。
• 减少 instruction overhead。
• loop unrolling。

9.4.6 三个周末实验要证明什么

实验 1：coalesced vs uncoalesced memory access。

证明：

• 同样数据量，连续访问比 stride/random 访问快。
• memory transaction 数影响 bandwidth。

实验 2：naive matmul vs tiled shared-memory matmul。

证明：

• shared memory reuse 可以减少 global memory load。
• tile size 会影响性能。

实验 3：pageable vs pinned memory copy。

证明：

• pinned memory H2D/D2H bandwidth 更好。
• async copy/overlap 依赖 pinned memory。

9.5 标准英文回答

I start with Nsight Systems because it tells me where time goes in the whole pipeline. If a kernel dominates, I switch to Nsight Compute to understand why that kernel is slow. If memory bandwidth is saturated and compute units are underutilized, I treat it as memory-bound. If compute pipelines are saturated and memory is not, I treat it as compute-bound.

9.6 周末怎么实战搭建

如果有 NVIDIA GPU：

实验 1：coalesced vs uncoalesced memory access。

目标：

• 证明 memory access pattern 影响 bandwidth。

实验 2：naive matmul vs tiled shared memory matmul。

目标：

• 证明 shared memory reuse。

实验 3：pageable vs pinned memory copy。

目标：

• 证明 pinned memory 支持更高效 DMA / async copy。

工具：

nvcc --version
nvidia-smi
nsys profile ./your_program
ncu ./your_kernel

如果没有 GPU：

• 写出实验设计。
• 写出预期结果。
• 准备 Nsight Systems/Compute 分别会看什么指标。

9.7 掌握验收

• 能画 CUDA execution 和 memory hierarchy。
• 能解释 occupancy trade-off。
• 能解释 memory-bound vs compute-bound。
• 能解释 Nsight Systems vs Compute。
• 能说明你的 Vulkan/WebGPU 经验相关但不是 CUDA production。

10. 技能 7：System Architecture / Prototype / Roadmap

10.1 JD 要求是什么

JD 说 senior architect 要：

• translate business needs into workable technology solutions。
• produce detailed technical work and high-level architectural designs。
• design and prototype features and optimizations。
• evaluate new technologies against roadmap and business value。

10.2 你 CV 里有什么

强匹配：

• Staff/Tech Lead。
• performance-sensitive production paths。
• diagnostic tooling。
• observability。
• replayability。
• release safety。
• cross-team debugging。

10.3 面试会问什么

• 如果优化 multi-node LLM serving，你先看什么指标？
• 如果 P99 latency 抖动，你怎么定位？
• 如果 GPU utilization 低但网络忙，可能是什么？
• 如何设计 prototype 验证 communication optimization？
• 如何判断一个优化值得进入 roadmap？

10.4 标准方法

10.4.1 Architect 面试真正考什么

这个岗位不是纯 CUDA kernel engineer，也不是纯 backend engineer。System Software Architect 的核心考察是：

• 能不能把业务目标翻译成系统指标。
• 能不能识别真正 critical path。
• 能不能把复杂系统拆成可验证的 prototype。
• 能不能判断一个优化是“实验室漂亮”还是“生产可落地”。
• 能不能跨 runtime、network、GPU、observability、deployment 做 trade-off。

所以你回答系统设计题时，不能只说“我会优化”。你要表现出下面这条链路：

business/SLA target
-> workload characterization
-> critical path
-> metrics
-> baseline
-> hypothesis
-> microbenchmark
-> prototype
-> end-to-end validation
-> rollout/roadmap decision

10.4.2 标准拆解框架

1. Define hypothesis
2. Identify critical path
3. Choose metrics
4. Build microbenchmark
5. Measure baseline
6. Implement prototype
7. Validate end-to-end
8. Stress test
9. Decide ship / iterate / reject

每一步具体是什么：

1. Define hypothesis：先说假设，不要上来就改系统。例如“P99 高可能来自 KV transfer blocking decode”。
2. Identify critical path：画请求路径，看时间花在哪里，区分 queueing、compute、communication、memory、sync。
3. Choose metrics：TTFT、TPOT、P99、throughput、GPU utilization、network bandwidth、CPU utilization、memory pressure。
4. Build microbenchmark：隔离通信/拷贝/collective，不受完整服务干扰。
5. Measure baseline：先拿基线，否则无法证明优化有效。
6. Implement prototype：只实现最小变更，证明假设，不追求完美产品化。
7. Validate end-to-end：回到真实 serving workload，看是否真的改善用户指标。
8. Stress test：看高并发、长上下文、失败、抖动、资源压力。
9. Decide ship / iterate / reject：基于收益、复杂度、风险、维护成本做路线图判断。

10.4.3 例题：设计 multi-node LLM serving 优化

面试官可能问：

We have multi-node LLM serving with high tail latency. How would you approach it?

强回答结构：

I would start by separating TTFT and TPOT, because they point to different
parts of the serving path. Then I would break the request path into queueing,
prefill, KV cache allocation or transfer, decode, collective communication,
and network/data movement. I would measure each stage before proposing an
optimization.

具体步骤：

1. 先确认 workload：

   • prompt length distribution。
   • output length distribution。
   • request rate。
   • model size。
   • GPU count and topology。
   • tensor parallel / pipeline parallel setting。
   • single-node or multi-node。

2. 拆指标：

   • TTFT 高：可能是 queueing、prefill 慢、KV allocation、prefill worker overloaded。
   • TPOT 高：可能是 decode 慢、memory bandwidth、KV cache access、collective communication。
   • P99 高：可能是 batch interference、straggler、network congestion、GC/cache eviction、synchronization。
   • GPU utilization 低：可能是 scheduler、CPU bottleneck、network wait、small batch。
   • GPU utilization 高但 throughput 差：可能是 memory-bound、bad kernel efficiency、KV cache pressure。

3. 做 prototype：

   • 如果 prefill 和 decode 干扰，尝试 disaggregation。
   • 如果 KV movement 慢，评估 NIXL/UCX/RDMA path。
   • 如果 tensor parallel collective 慢，跑 nccl-tests 验证 all-reduce/all-gather。
   • 如果 CPU 在 data path，评估 GPUDirect/GPUNetIO。
   • 如果 kernel 慢，用 Nsight Compute 看 memory/coalescing/occupancy。

4. 验证：

   • microbenchmark 证明单点有效。
   • serving benchmark 证明 TTFT/TPOT/P99 有效。
   • soak test 证明不会在长时间运行中内存碎片或 tail latency 爆炸。

10.4.4 例题：如何判断 NIXL/Dynamo 优化是否值得进 roadmap

不要只说“性能更好”。roadmap 判断要有产品和工程视角：

Impact:
  Does it improve customer-visible metrics such as TTFT, TPOT, P99, throughput, or cost per token?

Scope:
  Is it useful for one special workload or a broad set of inference deployments?

Complexity:
  Does it introduce new runtime dependencies, new failure modes, or operational burden?

Risk:
  What happens on fallback? Can we disable it? Does it affect correctness?

Maintainability:
  Can the team debug and evolve it? Are metrics and traces good enough?

Compatibility:
  Does it work across GPU generations, NICs, drivers, and cloud/on-prem environments?

英文回答：

I would not put a technology on the roadmap only because a microbenchmark improves. I would require end-to-end serving impact, clear fallback behavior, acceptable operational complexity, and evidence that the improvement applies to an important class of workloads.

10.4.5 例题：P99 latency 抖动怎么定位

先不要猜，分层：

client side
-> ingress / queue
-> scheduler
-> prefill
-> KV cache allocation / transfer
-> decode
-> collective communication
-> GPU kernel
-> network/storage
-> response streaming

每层看什么：

• Client/ingress：请求是否 bursty，是否有 retry storm。
• Scheduler：batch 是否过大，priority 是否导致 starvation。
• Prefill：长 prompt 是否阻塞短 prompt。
• KV cache：是否频繁 evict、recompute、move、fragmentation。
• Decode：是否有 straggler request 拖慢 batch。
• NCCL：collective 是否出现慢 rank。
• RDMA/UCX：是否 fallback、拥塞、registration overhead。
• GPU kernel：是否 memory-bound、occupancy 低、stream synchronization。
• CPU：是否单线程 scheduler、serialization、GC、logging。

面试回答：

For P99, I would avoid averaging everything. I would correlate per-request traces with GPU and network timelines. Tail latency often comes from queueing, stragglers, synchronization, or resource contention, so I would inspect stage-level latency distribution rather than only mean latency.

10.4.6 例题：GPU utilization 低但网络忙

可能原因：

• GPU 在等数据，network/data movement 在 critical path。
• Transfer 太碎，带宽看起来忙但有效吞吐低。
• CPU scheduler 或 completion handling 慢，GPU 没拿到 ready work。
• KV cache movement 没有和 decode overlap。
• Multi-node collective 等慢 rank。
• PCIe/NUMA/topology 导致 GPU-NIC path 不佳。
• Backend fallback 到 TCP 或 CPU staging。

回答结构：

I would check whether the GPU is waiting on communication or scheduling.
Then I would look at transfer granularity, overlap, topology, and actual
transport selection. High network activity does not necessarily mean useful
payload bandwidth; it can also be overhead from many small transfers or retries.

10.4.7 Prototype 设计模板

以后遇到任何 architecture/design 问题，都用这个模板：

Problem:
  What user-visible metric is bad?

Hypothesis:
  Which subsystem is likely on the critical path?

Baseline:
  What is the current metric and under what workload?

Microbenchmark:
  What isolated test proves the subsystem behavior?

Prototype:
  What minimal change tests the idea?

Integration:
  How does it fit into runtime/scheduler/data path?

Metrics:
  Which numbers must improve?

Failure mode:
  What if it fails, degrades, or cannot use fast path?

Rollout:
  Can it be guarded by config/feature flag?

Decision:
  Ship, iterate, or reject based on impact vs complexity.

10.4.8 和你 CV 怎么接

你的 CV 强项是“把复杂 production path 做成可诊断、可观测、可落地”。你要把它翻译到 NVIDIA JD：

At OKX I worked on performance-sensitive AI/infrastructure paths where the
main challenge was not just writing code, but making the system measurable,
debuggable, and safe to evolve. For this NVIDIA role, I would apply the same
approach to GPU networking and inference runtime: identify the critical path,
build focused benchmarks, add observability, validate end-to-end impact, and
turn successful prototypes into maintainable roadmap items.

10.5 标准英文回答

My prototype approach is hypothesis-driven. I isolate the communication or data movement pattern first, validate with a microbenchmark, then integrate into an end-to-end serving path. I would not trust a microbenchmark alone; the final decision should be based on realistic workload metrics, operational complexity, and whether it improves TTFT, TPOT, P99, throughput, or memory efficiency.

10.6 掌握验收

• 能从 vague problem 拆到 measurable path。
• 能说出 microbenchmark 和 end-to-end validation 的区别。
• 能说出 roadmap 判断标准：impact、scope、cost、risk、maintainability。

11. 两天周末实战冲刺计划

目标：两天内达到“面试深挖可回答 + 有实战证据/实验设计”的状态。

这里的“完全掌握”指面试验收意义上的掌握：

• 能从第一性原理解释概念，不只背名词。
• 能画出数据路径和系统边界。
• 能说出典型瓶颈和 debug 顺序。
• 能把你的 CV 项目迁移到 JD 技术能力上。
• 能给出最小实验设计或已经跑过的 benchmark。
• 被追问 3 层时不崩：定义、机制、trade-off、debug、prototype。

两天学习路径：

flowchart LR
    A[CUDA Execution and Memory] --> B[Nsight Profiling]
    B --> C[NCCL Collectives]
    C --> D[RDMA and UCX]
    D --> E[GPUDirect and GPUNetIO]
    E --> F[LLM Serving Path]
    F --> G[KV Cache and Data Movement]
    G --> H[Dynamo and NIXL]
    H --> I[System Architecture Answers]
    I --> J[Mock Interview]

学习顺序的原因：

• 先学 CUDA/Nsight：所有 GPU 性能讨论最终都会落到 kernel、memory、stream、profiling。
• 再学 NCCL：多 GPU AI workload 的通信基本绕不开 collective。
• 再学 RDMA/UCX/GPUDirect：跨节点通信和 data movement 是 JD 重点。
• 再学 LLM serving：这个岗位是 AI and GPU Networking，不是单纯网络库。
• 最后学 Dynamo/NIXL/GPUNetIO：这些 NVIDIA stack 名词必须放在前面基础上理解。

每个主题按同一个模板学习：

1. What is it?
2. Why does it exist?
3. What is the critical path?
4. What metrics prove it works?
5. What makes it slow?
6. How do I debug it?
7. What would I say in an interview?
8. What tiny experiment can I run or design?

你的当前环境：Windows GPU 机器怎么用

你现在有一台 Windows GPU 机器，这正好可以把“只会讲概念”升级成“能跑实验 + 能解释结果”。建议分工：

flowchart TB
    Win[Windows GPU Machine]
    Native[Windows Native Environment]
    WSL[WSL2 Ubuntu Environment]
    Native --> Driver[NVIDIA Driver / nvidia-smi]
    Native --> CUDAWin[CUDA Toolkit on Windows]
    Native --> NsightGUI[Nsight Systems / Nsight Compute GUI]
    Native --> VSSamples[Visual Studio / CUDA Samples]
    WSL --> LinuxCLI[Linux CUDA CLI]
    WSL --> Python[vLLM / Python Benchmarks]
    WSL --> NCCL[NCCL Tests if Available]
    WSL --> UCX[UCX Tools if Available]

推荐路线：

• Windows 原生：确认 driver、CUDA Toolkit、Nsight GUI、CUDA Samples。
• WSL2 Ubuntu：跑 Linux 风格实验，优先用于 vLLM、Python benchmark、UCX/NCCL 工具。
• 如果 WSL2 里 nvidia-smi 能看到 GPU，就把主要实验放到 WSL2。
• 如果 WSL2 暂时不可用，就先用 Windows 原生完成 CUDA/Nsight 实验，同时把 UCX/NIXL/GPUNetIO 做成设计和 debug playbook。

这台机器可以覆盖：

• CUDA execution / memory / kernel profiling。
• Nsight Systems 和 Nsight Compute 的基本工作流。
• vLLM 小模型 serving benchmark，前提是 WSL2 + CUDA + Python 环境顺。
• UCX 工具级学习，前提是 WSL2 下能安装 UCX。

这台机器大概率不能完整覆盖：

• 真实多节点 RDMA/RoCE。
• 真实 GPUDirect RDMA fabric。
• 完整 DOCA/GPUNetIO 环境，除非机器有合适的 NVIDIA NIC/DOCA/driver。

面试中可以这样说：

I used my Windows GPU machine for CUDA profiling, local GPU experiments, and WSL2-based Linux workflows. For true multi-node RDMA/RoCE and GPUNetIO validation, I would need the right NIC, driver, and fabric, so I prepared benchmark designs and debug checklists in addition to local CUDA and serving experiments.

Day 1：2026-06-13，底层通信 + CUDA

09:00-10:00：搭环境

Windows PowerShell 先检查：

nvidia-smi
nvcc --version
python --version
where nsys
where ncu

WSL2 Ubuntu 再检查：

nvidia-smi
nvcc --version
python3 --version
uname -a

判断规则：

• Windows 能跑 nvidia-smi：driver OK。
• Windows 能跑 nvcc --version：Windows CUDA Toolkit OK。
• WSL2 能跑 nvidia-smi：Linux CUDA workflow OK，优先用它跑 vLLM/NCCL/UCX。
• WSL2 不能跑 nvidia-smi：先别耗太久，Windows 原生做 CUDA/Nsight，Linux 生态实验写 design。

这一小时你要得到的结论：

Windows:
  GPU 是否可见
  CUDA Toolkit 是否可用
  Nsight Systems / Compute 是否可用

WSL2:
  GPU 是否可见
  Python 是否可用
  Linux CUDA/NCCL/UCX 工具链是否值得继续尝试

验收：

• 你知道自己能跑哪些实验，不能跑哪些实验。
• 不能跑的实验必须写出 benchmark design，不留空。

10:00-12:00：NCCL / Collectives

学习目标：

• all-reduce。
• reduce-scatter/all-gather。
• DP/TP/PP/FSDP。
• slow all-reduce debug。

先学概念：

collective:
  all ranks participate in one communication operation.

all-reduce:
  reduce values across ranks, then make the result available on every rank.

reduce-scatter:
  reduce values across ranks, then scatter shards of the result.

all-gather:
  gather shards from all ranks so every rank has the full tensor.

rank:
  one participant process/GPU.

world size:
  number of ranks.

ring:
  bandwidth-efficient algorithm; latency grows with number of ranks.

必须会手算 all-reduce：

rank0: [1, 2]
rank1: [3, 4]
rank2: [5, 6]

sum all-reduce result on every rank:
[1+3+5, 2+4+6] = [9, 12]

和 AI workload 的对应：

data parallel training:
  all-reduce gradients

tensor parallel inference:
  all-reduce partial results or all-gather shards depending on layer layout

FSDP:
  reduce-scatter gradients, all-gather parameters

实战：

git clone https://github.com/NVIDIA/nccl-tests.git labs/nccl_tests/nccl-tests
cd labs/nccl_tests/nccl-tests
make MPI=0
./build/all_reduce_perf -b 8 -e 128M -f 2 -g 1

产出：

• labs/nccl_tests/results.md
• 记录 command、GPU 数、message size、algbw/busbw。
• 写 10 行总结：小 message vs 大 message 可能瓶颈。

结果文件必须解释：

small message:
  latency and launch overhead dominate.

large message:
  bandwidth, topology, protocol, and NIC/PCIe/NVLink dominate.

algbw:
  algorithmic bandwidth from user payload perspective.

busbw:
  estimated hardware bus bandwidth after accounting for collective traffic pattern.

面试验收：

• 你能 90 秒解释 all-reduce。
• 你能解释为什么 all-reduce 慢不一定是 NCCL bug。
• 你能给出 debug 顺序：message size、rank、topology、transport、env、contention。

13:00-15:00：RDMA / UCX / GPUDirect

学习目标：

• TCP vs RDMA。
• MR/QP/CQ。
• UCX UCP/UCT。
• GPUDirect RDMA。

先学概念：

TCP:
  general-purpose reliable byte stream through kernel networking stack.

RDMA:
  remote direct memory access; NIC can move data directly between registered memory regions.

RoCE:
  RDMA over Converged Ethernet; needs careful fabric/QoS/lossless or congestion control setup.

InfiniBand:
  purpose-built high-performance interconnect commonly used in HPC/AI clusters.

UCX:
  unified communication framework; chooses transports such as shared memory, TCP, RDMA, CUDA IPC.

GPUDirect RDMA:
  NIC directly reads/writes GPU memory, avoiding CPU staging copy.

必须能画出两条路径：

flowchart TB
    subgraph Without[Without GPUDirect RDMA]
        G1[Local GPU Memory] --> H1[Local CPU Staging Memory]
        H1 --> N1[Local NIC]
        N1 --> Net[Network]
        Net --> N2[Remote NIC]
        N2 --> H2[Remote CPU Staging Memory]
        H2 --> G2[Remote GPU Memory]
    end

    subgraph With[With GPUDirect RDMA]
        GG1[Local GPU Memory] --> NN1[Local NIC]
        NN1 --> RNet[RDMA Network]
        RNet --> NN2[Remote NIC]
        NN2 --> GG2[Remote GPU Memory]
    end

实战/实验设计：

在 WSL2 Ubuntu 里优先尝试：

ucx_info -d
ucx_info -v

Windows GPU 机器的现实边界：

• 如果没有 InfiniBand/RoCE NIC，就不能验证真实 RDMA fabric。
• 如果没有合适的 GPU-NIC 拓扑和 driver，就不能验证真实 GPUDirect RDMA。
• 但你仍然可以用 WSL2 学 UCX 工具、transport abstraction、debug checklist。
• 面试里要诚实区分“本地 CUDA/vLLM/Nsight 已实操”和“RDMA/GPUDirect/GPUNetIO 已准备实验设计”。

如果没有 UCX：

• 画 TCP/RDMA/GPUDirect 图。
• 写 UCX slow transfer checklist。

产出：

• labs/notes/rdma_ucx_gpudirect.md

结果文件必须包含：

What path am I assuming?
  TCP / RDMA / GPUDirect RDMA / unknown

What memory type?
  CPU pageable / CPU pinned / GPU memory

What can make it slow?
  registration, fallback, topology, small messages, congestion, sync, progress

What evidence would prove GPUDirect?
  topology support, driver support, UCX/CUDA support, benchmark showing direct GPU buffer transfer

必须能说：

RDMA reduces CPU and kernel involvement in the data path by allowing the NIC to directly access registered memory...

面试验收：

• 你能解释 RDMA 不是“更快的 TCP”，而是不同的数据路径。
• 你能解释 memory registration 为什么存在。
• 你能解释 UCX 是抽象 transport，不是 NCCL 替代品。
• 你能解释 GPUDirect RDMA 是 NIC 访问 GPU memory。

15:00-18:00：CUDA / Nsight

学习目标：

• execution model。
• memory hierarchy。
• Systems vs Compute。
• memory-bound vs compute-bound。

先学概念：

thread:
  smallest execution unit in CUDA programming model.

warp:
  32 threads execute together under SIMT.

block:
  group of threads scheduled to one SM.

grid:
  all blocks launched by one kernel.

SM:
  streaming multiprocessor; executes warps and manages registers/shared memory.

global memory:
  large but high latency.

shared memory:
  on-chip, low latency, manually managed per block.

register:
  fastest per-thread storage, but too many registers can reduce occupancy.

实战：

• 写/准备 3 个 CUDA 实验：
  • coalesced vs uncoalesced。
  • naive matmul vs tiled matmul。
  • pageable vs pinned copy。

你的 Windows GPU 机器具体做法：

flowchart TB
    CUDAExp[CUDA / Nsight Experiments]
    WinNative[Windows Native]
    WSL2[WSL2 Ubuntu]
    WinNative --> Samples[CUDA Samples / Visual Studio Build]
    WinNative --> NsightGUI[Nsight Systems / Nsight Compute GUI]
    WSL2 --> NVCC[nvcc CLI Compile]
    WSL2 --> NSYS[nsys CLI Timeline]
    WSL2 --> NCU[ncu CLI Kernel Metrics]
    CUDAExp --> WinNative
    CUDAExp --> WSL2

Windows PowerShell 路线：

nvidia-smi
nvcc --version
nsys --version
ncu --version

WSL2 路线：

nvidia-smi
nvcc --version
nsys --version
ncu --version

产出：

• labs/cuda_profiling/experiment_plan.md
• 如果能跑，附 nsys 或 ncu 命令和结果。

实验计划必须这样写：

Experiment 1: coalesced vs uncoalesced memory access
Hypothesis:
  coalesced access improves effective memory bandwidth.
Metric:
  kernel time, memory throughput, global load efficiency.

Experiment 2: naive matmul vs tiled matmul
Hypothesis:
  shared memory tiling reduces global memory traffic.
Metric:
  kernel time, achieved occupancy, memory throughput, FLOP/s.

Experiment 3: pageable vs pinned host-to-device copy
Hypothesis:
  pinned memory improves H2D/D2H transfer throughput and enables better async behavior.
Metric:
  memcpy time, overlap with kernel, stream timeline.

面试验收：

• 你能说明 Nsight Systems 看 timeline，Nsight Compute 看 kernel。
• 你能解释 memory-bound 和 compute-bound。
• 你能解释 coalescing、occupancy、shared memory、stream overlap。

20:00-22:00：口头 mock 1

必须练：

• What is all-reduce?
• How to debug slow NCCL?
• TCP vs RDMA?
• UCX vs NCCL?
• Nsight Systems vs Nsight Compute?
• Memory-bound vs compute-bound?

练习方式：

每题先 30 秒短答。
然后补 90 秒细答。
最后补一个 "how I would validate/debug"。

例子：

Question:
  How would you debug slow NCCL all-reduce?

30s:
  I would first isolate whether it is message-size, topology, transport,
  or contention related by running nccl-tests and checking per-rank behavior.

90s:
  I would compare small and large messages, verify GPU topology with nvidia-smi topo,
  check whether NCCL uses NVLink, PCIe, IB, or sockets, look for slow ranks,
  and correlate with workload traces. If it only happens in the application,
  I would check synchronization, stream usage, and overlap.

Validation:
  nccl-tests baseline, app trace, NCCL_DEBUG logs, topology check.

Day 2：2026-06-14，LLM serving + NVIDIA stack + 项目接入

09:00-11:30：LLM Serving

学习目标：

• request path。
• prefill/decode。
• KV cache。
• TTFT/TPOT/P99。
• high TTFT / bad TPOT debug。

先学概念：

request path:
  tokenizer -> scheduler -> prefill -> KV cache -> decode loop -> detokenize/stream

prefill:
  process prompt tokens in parallel; compute-heavy; produces KV cache.

decode:
  generate one token per step; latency-sensitive; repeatedly reads KV cache.

KV cache:
  stored keys/values for prior tokens; avoids recomputing attention history.

TTFT:
  time to first token; dominated by queueing and prefill.

TPOT:
  time per output token; dominated by decode efficiency and memory/cache behavior.

continuous batching:
  dynamically mixes requests at different decode steps to keep GPU busy.

paged attention:
  manages KV cache in blocks/pages to reduce fragmentation and improve utilization.

实战：

优先在 WSL2 Ubuntu 里跑，因为 vLLM/Linux/Python/CUDA 生态更顺：

python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
pip install vllm
python -m vllm.entrypoints.openai.api_server \
  --model Qwen/Qwen2.5-0.5B-Instruct \
  --host 0.0.0.0 \
  --port 8000

另一个终端：

python -m vllm.benchmarks.benchmark_serving \
  --backend openai \
  --model Qwen/Qwen2.5-0.5B-Instruct \
  --dataset-name random \
  --num-prompts 100 \
  --random-input-len 512 \
  --random-output-len 128 \
  --request-rate 4

如果 Windows 原生有 GPU 但 WSL2/vLLM 不顺：

• 不要把时间耗死在安装。
• 用 Windows 原生完成 CUDA/Nsight 实验。
• LLM serving 部分写 benchmark design：
  • input len: 128/512/2048。
  • output len: 64/128/512。
  • request rate: 1/4/16。
  • 观察 TTFT/TPOT/P99/GPU memory。

产出：

• labs/llm_serving/benchmark_notes.md

benchmark notes 必须包含：

Experiment matrix:
  input length: 128 / 512 / 2048
  output length: 64 / 128 / 512
  request rate: 1 / 4 / 16

Expected behavior:
  longer input -> higher TTFT
  longer output -> longer total latency and more decode steps
  higher request rate -> better throughput until queueing/P99 worsens
  longer context -> more KV cache memory pressure

Debug interpretation:
  high TTFT -> queueing, prefill, KV allocation
  high TPOT -> decode, KV access, memory bandwidth, collectives
  high P99 -> stragglers, batching, network, synchronization, cache pressure

面试验收：

• 你能把 LLM serving 画成路径图。
• 你能解释 prefill/decode 为什么性质不同。
• 你能解释 KV cache 大小怎么估。
• 你能解释 TTFT、TPOT、P99 各自指向什么瓶颈。

13:00-15:00：Dynamo / NIXL / GPUNetIO

学习目标：

• Dynamo orchestration。
• NIXL data movement。
• NIXL vs NCCL。
• GPUNetIO vs GPUDirect RDMA。

先学概念：

Dynamo:
  distributed inference orchestration layer.

NIXL:
  inference data movement abstraction, especially for KV/state/buffer transfer.

NCCL:
  collective communication library for GPU tensors/ranks.

UCX:
  transport abstraction that can use RDMA/TCP/shared memory/CUDA-aware paths.

GPUNetIO:
  GPU-centric networking programming model; GPU can participate in network data processing.

产出：

• 画 Dynamo -> NIXL -> UCX/RDMA/GDS。
• 写 NIXL transfer lifecycle。
• 写 GPUNetIO when useful / when not useful。

必须写出的三段英文：

Dynamo:
  Dynamo is an orchestration layer for distributed inference. It coordinates
  routing, scheduling, worker placement, backend engines, and data movement.

NIXL:
  NIXL is an inference-oriented data movement abstraction. I would associate
  it with moving KV cache or request state across GPU, host, network, or storage
  backends.

GPUNetIO:
  GPUNetIO is a GPU-centric networking programming model. It is useful only
  when CPU-mediated networking is on the critical path and the data is consumed
  by GPU workloads.

面试验收：

• 你能解释 Dynamo 不是 vLLM。
• 你能解释 NIXL 不是 NCCL。
• 你能解释 GPUNetIO 不是 GPUDirect RDMA。
• 你能给出什么时候不用它们。

15:00-17:00：项目故事接入技术问题

目标：

把 CV 只作为证据，不作为主线。

每个项目写 90 秒回答：

1. OKX AI inference：接 LLM serving path。
2. gRPC/Kafka：接 communication-path diagnosis。
3. Vulkan/WebGPU：接 GPU profiling。
4. Native Addon/SIMD：接 hot-path optimization。
5. Advantest：接 hardware-software debugging。

产出：

• labs/notes/project_story_90s.md

每个项目故事必须按这个结构写：

Context:
  What system did I work on?

Problem:
  What was slow, unreliable, or hard to debug?

Action:
  What did I measure, design, or implement?

Technical depth:
  Which subsystem did I touch? GPU, networking, runtime, profiling, observability?

Result:
  What changed? latency, throughput, reliability, debug time, release safety?

Mapping to NVIDIA:
  How does this experience transfer to AI/GPU networking architecture?

示例：OKX AI inference 连接 JD：

My relevant experience is not only using AI models, but building and debugging
performance-sensitive inference paths. In NVIDIA's context, I would extend that
mindset to GPU inference serving: trace the request path, separate prefill and
decode metrics, monitor KV cache pressure, and evaluate communication/data
movement bottlenecks with microbenchmarks and end-to-end serving metrics.

20:00-22:00：口头 mock 2

按真实面试顺序：

1. Tell me about yourself。
2. Pick one project and go deep。
3. Prefill vs decode。
4. KV cache bottleneck。
5. NIXL vs NCCL。
6. Slow all-reduce debug。
7. TCP vs RDMA。
8. CUDA profiling。
9. Design a prototype for communication optimization。
10. Ask interviewer questions。

Mock 2 验收标准：

For each answer:
  1 sentence definition
  3-5 sentence mechanism
  1 trade-off
  1 debug/prototype method
  1 connection to your CV or JD

如果一道题答不出，立刻回到这个模板：

I would break it down by data path and metrics.
First, I would identify where the data lives and moves.
Second, I would measure the relevant latency/throughput/resource metric.
Third, I would isolate the subsystem with a microbenchmark.
Finally, I would validate the change end-to-end before calling it a win.

12. 最终验收清单

面试前必须全部过一遍。

12.1 技术图

必须能手画：

• LLM serving request path。
• Prefill -> KV cache -> decode。
• Dynamo -> NIXL -> UCX/RDMA/GDS。
• Ring all-reduce。
• TCP vs RDMA。
• GPUDirect RDMA。
• GPUNetIO CPU-centric vs GPU-centric。
• CUDA memory hierarchy。

12.2 Debug playbooks

必须能口头给 checklist：

• high TTFT。
• bad TPOT。
• low GPU utilization。
• slow NCCL all-reduce。
• UCX/RDMA slow transfer。
• CUDA kernel slow。

12.3 标准英文短答

必须背熟：

• self intro 60 秒。
• biggest strength。
• biggest gap。
• prefill vs decode。
• KV cache。
• NIXL vs NCCL。
• slow all-reduce debug。
• TCP vs RDMA。
• UCX layering。
• Nsight Systems vs Compute。

12.4 实战证据

最好有：

• nccl-tests 输出或实验设计。
• CUDA profiling 实验或实验设计。
• vLLM benchmark 输出或实验设计。
• Mermaid 图。
• project story 90 秒稿。

13. Mermaid 图集

13.1 LLM Serving Request Path

flowchart LR
    Client[Client Request] --> FE[Frontend]
    FE --> Tok[Tokenizer]
    Tok --> Router[Router]
    Router --> Sched[Scheduler]
    Sched --> Prefill[Prefill Worker]
    Prefill --> KV[KV Cache Allocation / Write]
    KV --> Move{KV Transfer Needed?}
    Move -- No --> Decode[Decode Worker]
    Move -- Yes --> NIXL[NIXL Transfer]
    NIXL --> Decode
    Decode --> Stream[Streaming Tokens]

13.2 TCP vs RDMA

flowchart TB
    subgraph TCPPath[TCP Path]
        App[Application] --> Kernel[Kernel TCP/IP Stack]
        Kernel --> NIC[NIC]
        NIC --> Net[Network]
        Net --> RKernel[Remote Kernel]
        RKernel --> RApp[Remote App]
    end
    subgraph RDMAPath[RDMA Path]
        Mem[Registered Memory] --> RNIC[RNIC DMA]
        RNIC --> Net2[Network]
        Net2 --> RRNIC[Remote RNIC DMA]
        RRNIC --> RMem[Remote Registered Memory]
    end

13.3 GPUDirect RDMA

flowchart TB
    subgraph Without[Without GPUDirect]
        NIC1[NIC] --> Host[Host Memory]
        Host --> GPU1[GPU Memory]
    end
    subgraph With[With GPUDirect RDMA]
        NIC2[NIC] --> GPU2[GPU Memory]
    end

13.4 NCCL Slow All-Reduce Debug

flowchart TB
    Slow[Slow All-Reduce] --> Scope{Single-node or Multi-node?}
    Scope -- Single-node --> Local[PCIe / NVLink / NVSwitch]
    Scope -- Multi-node --> Fabric[IB / RoCE Fabric]
    Slow --> Size{Small or Large Message?}
    Size -- Small --> Latency[Latency / Algorithm / Launch]
    Size -- Large --> BW[Bandwidth / Congestion]
    Slow --> Logs[NCCL_DEBUG Logs]
    Logs --> Transport[Transport Selection]
    Transport --> Rank[Rank Mapping]
    Rank --> Affinity[GPU-NIC Affinity]
    Affinity --> Counters[Network Counters]

14. 高频追问 Q&A（含回答）

这一章是面试前最后背诵用的。每个回答都按同一结构：中文理解、英文回答、如果被继续追问怎么接。

14.1 What is the end-to-end path of an LLM inference request?

中文理解：

一个 LLM 请求不是“调用一次模型”这么简单。它通常经过 tokenizer、scheduler、prefill、KV cache 写入、decode loop、detokenize/streaming。系统瓶颈可能出现在任何一段。

英文回答：

An LLM serving request usually goes through tokenization, scheduling, prefill, KV cache allocation or write, decode iterations, and streaming output. Prefill processes the prompt and creates KV cache, while decode generates one token at a time and repeatedly reads the KV cache. I would measure TTFT, TPOT, throughput, P99 latency, GPU utilization, and memory pressure to understand the serving bottleneck.

继续追问怎么接：

• 如果 TTFT 高，看 queueing、prefill、KV allocation。
• 如果 TPOT 高，看 decode、KV access、memory bandwidth、collectives。
• 如果 P99 高，看 straggler、batch interference、network、sync。

14.2 Prefill 和 decode 有什么区别？

中文理解：

Prefill 处理 prompt，输入 token 多，可以并行做 attention 和矩阵计算，通常更 compute-heavy。Decode 每步只生成一个 token，但要不断读历史 KV cache，更 latency-sensitive，也更容易被 memory bandwidth、KV layout、batching 影响。

英文回答：

Prefill processes all prompt tokens and produces the KV cache. It is usually more compute-heavy and strongly affects time to first token. Decode generates one token per iteration, repeatedly reading the KV cache, so it is latency-sensitive and often limited by memory bandwidth, cache layout, batching, and synchronization.

继续追问怎么接：

This is why prefill/decode disaggregation can be useful: prefill and decode have different resource profiles, so separating them can reduce interference. But it introduces KV transfer and scheduling complexity, so I would only do it if end-to-end TTFT/TPOT/P99 improve.

14.3 KV cache 是什么，为什么重要？

中文理解：

Transformer 每层 attention 都会生成 K/V。自回归 decode 时，历史 token 的 K/V 不需要重复计算，可以缓存下来。KV cache 让 decode 快很多，但它会占用大量 GPU memory，也会带来 block management、fragmentation、transfer/offload 问题。

英文回答：

KV cache stores the key and value tensors for previous tokens in each transformer layer. During decode, the model can reuse those cached K/V tensors instead of recomputing attention history. It is critical for decode performance, but it can become a memory capacity and data movement bottleneck, especially for long context, large batch size, or prefill/decode disaggregation.

继续追问怎么接：

I would estimate KV memory from layers, KV heads, head dimension, sequence length, batch size, and dtype. If KV cache becomes the bottleneck, I would look at paging/block allocation, fragmentation, eviction/offload, transfer granularity, and whether decode is blocked on KV movement.

14.4 How would you debug high TTFT?

中文理解：

TTFT 是用户等到第一个 token 的时间。它不只是 prefill 时间，还包括排队、调度、tokenizer、batching、KV allocation、worker placement。

英文回答：

I would break TTFT into queueing time, scheduling time, tokenization, prefill execution, KV cache allocation, and any data movement before decode starts. If TTFT is high only under load, I would first suspect queueing or batching. If it is high for long prompts, I would focus on prefill compute and KV allocation. I would use per-request tracing rather than only aggregate averages.

继续追问怎么接：

• 长 prompt 触发：prefill compute、attention、KV memory。
• 高并发触发：scheduler、queueing、admission control。
• 多节点触发：worker placement、KV transfer、network。

14.5 How would you debug bad TPOT?

中文理解：

TPOT 是每个输出 token 的时间，主要反映 decode loop。Decode 是一步一步生成 token，所以任何同步、KV cache 访问、collective、慢 rank 都会影响它。

英文回答：

I would first isolate the decode loop and measure per-token latency distribution. Then I would check KV cache access, memory bandwidth, batch composition, synchronization, and any collective communication in tensor-parallel execution. If TPOT is bad only at scale, I would check NCCL collectives, GPU-NIC topology, and whether data movement overlaps with compute.

继续追问怎么接：

A useful distinction is whether the decode kernel itself is slow, or decode is waiting on communication, scheduling, or memory movement. Nsight Systems can show the timeline, and Nsight Compute can explain kernel-level stalls.

14.6 What is NCCL, and why is all-reduce important?

中文理解：

NCCL 是 NVIDIA 的 GPU collective communication library。All-reduce 把所有 rank 的 tensor 做 reduce，然后让每个 rank 都拿到结果。在分布式训练里用于 gradient synchronization，在 tensor parallel inference 里也可能用于合并 partial results。

英文回答：

NCCL is NVIDIA's library for GPU collective communication. All-reduce reduces tensors across ranks and distributes the result back to every rank. It is central to distributed training for gradient synchronization, and it can also appear in tensor-parallel inference depending on how the model is partitioned.

继续追问怎么接：

If all-reduce is slow, I would check message size, rank mapping, topology, whether it uses NVLink, PCIe, InfiniBand, RoCE, or sockets, and whether the issue appears in nccl-tests or only inside the application.

14.7 NIXL 和 NCCL 的区别是什么？

中文理解：

NCCL 是 collective communication，参与者是一组 rank，操作是 all-reduce/all-gather/reduce-scatter。NIXL 更偏 inference data movement，移动的是 KV cache、request state、buffer，通常是 point-to-point 或 object/state movement。

英文回答：

NCCL is for collective tensor communication across ranks, such as all-reduce, all-gather, and reduce-scatter. NIXL is an inference-oriented data movement abstraction, especially for moving KV cache, request state, or buffers across GPU, host, network, or storage backends. They may both use high-performance transports, but their semantics and integration points are different.

继续追问怎么接：

I would use NCCL when the operation is a collective across ranks. I would think about NIXL when the serving runtime needs to move inference state, for example from a prefill worker to a decode worker.

14.8 Dynamo 和 vLLM/TensorRT-LLM 的区别是什么？

中文理解：

vLLM/TensorRT-LLM 更像 backend engine，负责模型执行、kernel、batching、attention 优化等。Dynamo 更像 distributed inference orchestration，负责 routing、scheduler、worker coordination、data movement、disaggregation 等系统层问题。

英文回答：

I think of vLLM or TensorRT-LLM as backend engines that execute the model efficiently. Dynamo is more of a distributed inference orchestration layer. It coordinates routing, scheduling, worker placement, prefill/decode disaggregation, backend engines, observability, and data movement.

继续追问怎么接：

The reason such an orchestration layer matters is that multi-node inference bottlenecks are not only kernel-level. They can come from queueing, scheduling, KV cache movement, network transfer, worker imbalance, or failure handling.

14.9 RDMA 为什么比传统 TCP path 更适合 AI/GPU networking？

中文理解：

TCP 走通用 kernel networking stack，CPU 参与多，copy/context switch/interrupt 可能增加 overhead。RDMA 允许 NIC 直接访问 registered memory，减少 CPU 和 kernel involvement。对大规模 GPU 通信和低延迟数据移动更重要。

英文回答：

RDMA allows the NIC to move data directly between registered memory regions, reducing CPU and kernel involvement in the data path. Compared with a traditional TCP path, this can reduce latency, CPU overhead, and extra copies. For AI/GPU networking, this matters because large tensors or inference state often need to move between GPUs and nodes efficiently.

继续追问怎么接：

RDMA is not automatically faster in every case. Registration overhead, small messages, topology, congestion, fallback path, and synchronization can still dominate.

14.10 UCX 是什么？它和 NCCL/NIXL 的关系是什么？

中文理解：

UCX 是统一通信框架，抽象不同 transport，比如 shared memory、TCP、RDMA、CUDA-aware path。NCCL 是 collective library，NIXL 是 inference data movement abstraction，它们可以使用 UCX 或类似底层 transport 思路，但语义不同。

英文回答：

UCX is a communication framework that abstracts multiple transports such as shared memory, TCP, RDMA, and CUDA-aware paths. NCCL provides GPU collective communication semantics. NIXL provides inference-oriented data movement semantics. UCX is closer to a lower-level transport abstraction, while NCCL and NIXL expose higher-level communication or data movement models to AI runtimes.

继续追问怎么接：

If a UCX transfer is slow, I would verify selected transport, GPU memory support, registration behavior, message size, topology, progress model, and whether it silently falls back to TCP or CPU staging.

14.11 GPUDirect RDMA 和 GPUNetIO 的区别是什么？

中文理解：

GPUDirect RDMA 是能力：NIC 能直接读写 GPU memory。GPUNetIO 是 programming model：让 GPU kernel 更主动参与网络数据处理，例如 polling/processing network-visible buffers。

英文回答：

GPUDirect RDMA enables the NIC to directly access GPU memory. GPUNetIO is a GPU-centric networking programming model that allows GPU kernels to participate in network data processing. GPUDirect RDMA is mainly about the data path; GPUNetIO is about how the GPU is programmed into the networking pipeline.

继续追问怎么接：

I would consider GPUNetIO only if CPU-mediated networking is on the critical path and the data is consumed by GPU workloads. Otherwise the added programming and debugging complexity may not be justified.

14.12 Nsight Systems 和 Nsight Compute 分别看什么？

中文理解：

Nsight Systems 看全局 timeline：CPU、GPU、CUDA API、kernel launch、memcpy、stream、同步。Nsight Compute 看单个 kernel 为什么慢：memory throughput、occupancy、warp stalls、instruction mix、shared memory。

英文回答：

I use Nsight Systems first to understand where time goes across the whole application: CPU work, CUDA API calls, GPU kernels, memcpy, streams, and synchronization. If a specific kernel dominates, I use Nsight Compute to inspect kernel-level metrics such as memory throughput, occupancy, warp stalls, instruction mix, and shared memory behavior.

继续追问怎么接：

Systems answers "where is the time spent?" Compute answers "why is this kernel slow?"

14.13 Memory-bound 和 compute-bound 怎么判断？

中文理解：

Memory-bound 是等内存：带宽接近上限、SM compute 不满、warp stall 指向 memory dependency。Compute-bound 是算力满：compute pipeline 饱和、memory bandwidth 不是瓶颈。

英文回答：

If memory bandwidth is close to the hardware limit while compute utilization is low or stalls point to memory dependency, I treat it as memory-bound. If compute pipelines are saturated and memory bandwidth is not the limiting factor, I treat it as compute-bound. The optimization direction is different: memory-bound workloads need better data locality, coalescing, tiling, or reduced memory traffic, while compute-bound workloads need better arithmetic efficiency or tensor-core utilization.

继续追问怎么接：

For memory-bound CUDA code, I would check coalescing, global memory traffic, shared-memory tiling, data layout, and unnecessary loads/stores.

14.14 如果 GPU utilization 低但网络很忙，你怎么判断？

中文理解：

这说明 GPU 可能在等数据，不代表网络有效利用高。也可能是 transfer 太碎、CPU completion 慢、RDMA fallback、拓扑差、collective 慢 rank、KV movement 没 overlap。

英文回答：

I would check whether the GPU is waiting on communication or scheduling. High network activity does not necessarily mean useful payload bandwidth; it can come from many small transfers, retries, or inefficient data movement. I would inspect transfer granularity, transport selection, GPU-NIC topology, completion/progress overhead, and whether communication overlaps with GPU compute.

继续追问怎么接：

I would correlate GPU timeline, network counters, UCX/NCCL logs, and application-level request traces. The goal is to identify whether the critical path is network bandwidth, per-transfer overhead, synchronization, or scheduling.

14.15 如何设计一个 communication optimization prototype？

中文理解：

Architect 岗位喜欢问 prototype，不要直接说“我会实现”。要先定义假设、指标、baseline、microbenchmark，再集成到 end-to-end workload。

英文回答：

I would start with a clear hypothesis, such as KV transfer blocking decode or collective communication limiting TPOT. Then I would measure a baseline, build a microbenchmark to isolate the communication pattern, implement the smallest prototype, and finally validate it in an end-to-end serving workload. I would judge success by TTFT, TPOT, P99 latency, throughput, resource usage, and operational complexity.

继续追问怎么接：

A microbenchmark alone is not enough. It proves a subsystem behavior, but the roadmap decision should depend on realistic workload impact, failure modes, fallback behavior, and maintainability.

14.16 你没有直接生产 NIXL/GPUNetIO 经验，怎么弥补？

中文理解：

不要硬装有经验。要诚实承认直接 production ownership 不足，然后强调你的可迁移能力：performance path、GPU profiling、communication debugging、prototype、observability、system architecture。

英文回答：

I have not owned NIXL or GPUNetIO in production directly. My relevant experience is in performance-sensitive systems, GPU profiling, communication-path diagnosis, and building debuggable infrastructure. For this role, I would ramp up by mapping each NVIDIA component to the data path it optimizes, building focused microbenchmarks, validating behavior with traces, and then connecting the result to end-to-end inference metrics.

继续追问怎么接：

The way I reduce risk is to be explicit about what I know, what I need to validate, and how I would measure it. I would not claim a technology helps until I can show the critical path and the metric improvement.

14.17 如果让你 30 天 ramp up，你会怎么做？

中文理解：

这是对 senior architect 的成熟度考察。答案要包含学习、实验、代码、业务、团队沟通。

英文回答：

In the first 30 days, I would map the serving and networking architecture, identify the key metrics and bottlenecks the team cares about, and reproduce the main benchmarks locally. I would then go deep on one data movement path, such as KV transfer or collective communication, and build a small prototype or diagnostic improvement. My goal would be to contribute something measurable while building the mental model for the broader roadmap.

继续追问怎么接：

• 第 1 周：读架构、跑 benchmark、理解 metrics。
• 第 2 周：复现一个 bottleneck。
• 第 3 周：做一个 microbenchmark/prototype。
• 第 4 周：端到端验证并写 design doc。

15. 反问面试官

优先问 2-3 个：

• Is this role more focused on inference serving, training communication, or general GPU networking infrastructure?
• What are the most important bottlenecks you are seeing today in distributed inference data movement?
• For this role, is the expected contribution more around architecture exploration, prototype implementation, or performance debugging?
• How do you evaluate whether a communication optimization is successful: microbenchmark results, end-to-end serving metrics, or customer workload traces?
• For someone joining with strong systems/performance experience but less direct NIXL/UCX production experience, what would be the most important ramp-up path in the first 3 months?

16. 补充：GR00T / Physical AI / Robotics Foundation Model

这一节放在末尾，是因为 GR00T 不是这个 JD 的主线。
这个 JD 的主线仍然是：

C++ / Python / CUDA
GPU profiling
AI inference / model serving
NCCL / UCX / NIXL / GPUDirect / GPUNetIO
data movement and distributed GPU systems

但是你最近学习了 GR00T，它可以作为面试中的加分项，尤其在 NVIDIA 语境下可以体现你对 Physical AI、robotics foundation model、synthetic data、real-time inference 和 GPU edge deployment 的关注。

注意回答边界：

不要把 GR00T 说成这个岗位的核心要求。
不要把自己包装成 robotics expert。
应该把它作为 NVIDIA AI platform / inference workload 的一个例子来讲。

16.1 GR00T 是什么

GR00T 全称通常写作 Generalist Robot 00 Technology。
NVIDIA 现在公开的主线叫 NVIDIA Isaac GR00T，它是面向 humanoid / generalist robot 的 robot foundation model 和开发平台。

截至我在线查到的公开资料，NVIDIA 官方 GitHub 当前主版本已经写到 Isaac GR00T N1.7。官方描述里，GR00T N1.7 是一个 open vision-language-action model，也就是 VLA 模型，用于 generalized humanoid robot skills。它可以接收语言、图像、机器人状态等多模态输入，然后输出机器人动作，用于 manipulation tasks。

一句话理解：

GR00T = 给机器人用的 foundation model。
它不是普通 LLM，也不是纯视觉模型，而是 Vision-Language-Action 模型。
输入是语言 + 视觉 + 机器人本体状态。
输出不是文字，而是动作/action。

面试时可以这样说：

I understand GR00T as NVIDIA's robotics foundation model direction for Physical AI. Unlike a text-only LLM, it is a vision-language-action model that maps multimodal observations and language instructions to robot actions. I would connect it to this role mainly through inference serving, GPU acceleration, data movement, and deployment constraints rather than claiming it is the core networking workload.

16.2 GR00T 的位置：它属于 NVIDIA 哪条战略线

NVIDIA 的 AI 可以粗略分成几条线：

flowchart TB
    NVIDIA[NVIDIA AI Platform]

    NVIDIA --> DataCenter[Data Center AI]
    NVIDIA --> GenAI[Generative AI]
    NVIDIA --> PhysicalAI[Physical AI]
    NVIDIA --> Omniverse[Simulation / Omniverse]
    NVIDIA --> Edge[Edge AI / Jetson]

    DataCenter --> Serving[LLM Serving / Dynamo / NIXL]
    DataCenter --> Networking[NCCL / UCX / GPUDirect / GPUNetIO]

    PhysicalAI --> GR00T[Isaac GR00T]
    PhysicalAI --> IsaacLab[Isaac Lab]
    PhysicalAI --> Cosmos[Cosmos / World Models]
    PhysicalAI --> Robots[Humanoid Robots]

    GR00T --> VLA[Vision-Language-Action Model]
    GR00T --> Policy[Robot Policy]
    GR00T --> Deployment[Real-Time Robot Deployment]

对这个 JD 的意义：

16.3 GR00T N1 / N1.5 / N1.7 简单演进

公开资料里几个关键版本：

不要死背版本号，应该记住演进方向：

更强的 VLM grounding
更多样的数据来源
更好的 cross-embodiment generalization
更实用的 fine-tuning / inference / deployment workflow
更接近真实机器人闭环控制

16.4 GR00T 的核心技术词汇

16.5 GR00T 的模型结构怎么理解

按公开资料，GR00T N1/N1.x 可以理解成两层系统：

flowchart LR
    Lang[Language Instruction]
    Img[Camera Images]
    State[Robot Proprioception]

    Lang --> VLM[VLM / Vision-Language Backbone]
    Img --> VLM
    State --> StateEnc[State Encoder]

    VLM --> Fusion[Multimodal Fusion]
    StateEnc --> Fusion

    Fusion --> ActionModel[Action Transformer / Diffusion or Flow Matching Head]
    ActionModel --> ActionChunk[Continuous Action Chunk]
    ActionChunk --> Controller[Robot Controller]
    Controller --> Robot[Robot Motion]

用面试语言讲：

GR00T is not just a perception model. The VLM backbone encodes language and visual observations, while the action model generates continuous robot actions conditioned on visual-language embeddings and robot state. The hard part is not only model accuracy, but also real-time inference, embodiment-specific action spaces, safety, and closed-loop deployment.

关键点：

• 输入不是单一 prompt，而是多模态 observation。
• 输出不是 token，而是连续动作。
• 推理不是“离线生成一次文本”，而是闭环控制中的实时 policy call。
• 评估不是 BLEU/accuracy，而是任务成功率、动作误差、闭环稳定性、实时性。

16.6 GR00T 和普通 LLM / vLLM serving 的区别

可以这样回答：

Compared with LLM serving, GR00T-style serving has a tighter control-loop requirement. The output is continuous action rather than text tokens, so latency, jitter, sensor-to-action delay, and safety matter more. From a systems perspective, I would still decompose the path into input preprocessing, GPU inference, data movement, postprocessing, and actuator/control integration.

16.7 GR00T 的数据路径

GR00T 的核心不是只训练一个模型，还包括数据采集、数据生成、fine-tuning、评估、部署。

flowchart TB
    RealRobot[Real Robot Demonstrations]
    HumanVideo[Human Ego Videos]
    Sim[Simulation Data]
    Synthetic[Synthetic Trajectories / DreamGen]

    RealRobot --> Format[Convert to Robot Data Format]
    HumanVideo --> Format
    Sim --> Format
    Synthetic --> Format

    Format --> Pretrain[Pretraining / Post-training]
    Pretrain --> FT[Fine-tune on Embodiment / Task]
    FT --> OpenLoop[Open-loop Evaluation]
    OpenLoop --> ClosedLoop[Closed-loop Simulation / Real Robot]
    ClosedLoop --> Deploy[Policy Server / Robot Controller Deployment]

你要理解每一步的问题：

16.8 如果你想本地学习 GR00T，怎么搭建

你的主环境是 Windows + WSL2 + NVIDIA GPU。
GR00T 这类项目建议优先放到 WSL2 Ubuntu 或 Linux GPU 机器里，不建议 Windows 原生折腾。

本地学习目标不要一上来就 fine-tune 大模型。两天内更现实的目标：

1. 跑通仓库环境检查。
2. 理解数据格式。
3. 跑一个 open-loop inference / evaluation。
4. 看懂 policy server/client 的调用方式。
5. 能解释如果上真机器人，需要补哪些组件。

参考流程：

mkdir -p labs/gr00t
cd labs/gr00t
git clone https://github.com/NVIDIA/Isaac-GR00T.git
cd Isaac-GR00T

按官方仓库当前 README，项目使用 uv 管理环境。典型方向是：

# WSL2 Ubuntu / Linux
python3 --version
nvidia-smi

# 安装 uv，具体以官方 README 为准
curl -LsSf https://astral.sh/uv/install.sh | sh

# 进入仓库后安装依赖
uv sync

如果你只想先学习架构，不一定要马上下载大模型权重。先看这些目录/概念：

gr00t/
  policy/
  eval/
  experiment/
examples/
demo_data/
getting_started/

如果能跑模型，优先尝试：

open-loop evaluation:
  用 demo_data 对比 predicted action 和 ground truth action。

policy server:
  启动 GR00T policy server。
  client 发送 observation。
  server 返回 action。

面试里不需要说“我完整训练了 GR00T”。更可信的说法是：

I studied the GR00T stack at the level of model architecture, data format, inference workflow, and deployment constraints. I focused on how a VLA policy differs from text LLM serving and what systems issues appear in real-time robot inference.

16.9 GR00T 和 CUDA / TensorRT / profiling 的关系

GR00T 本身是上层 robotics foundation model，但真正落地时仍然会遇到你正在准备的底层问题。

flowchart LR
    Sensor[Camera / Robot State]
    Pre[Preprocess]
    Model[VLA Model Inference]
    Post[Action Postprocess]
    Ctrl[Robot Controller]
    Act[Actuators]

    Sensor --> Pre --> Model --> Post --> Ctrl --> Act

    Model --> CUDA[CUDA Kernels]
    Model --> TRT[TensorRT Export]
    Model --> Memory[GPU Memory]
    Model --> Profile[Nsight Profiling]

你可以把它和当前 JD 连接成：

可以这样讲：

GR00T is a robotics workload, but the systems questions are familiar: how to minimize sensor-to-action latency, avoid unnecessary CPU-GPU copies, profile GPU inference, and deploy with an optimized runtime such as TensorRT when needed.

16.10 GR00T 和 NIXL / NCCL / UCX / GPUNetIO 的关系

这块要谨慎。
不要强行说 GR00T 依赖 NIXL 或 GPUNetIO。公开资料里，GR00T 主线是 robot foundation model、data pipeline、fine-tuning、evaluation、deployment。NIXL/NCCL/UCX/GPUNetIO 是这个 JD 的 GPU communication/data movement 主线。

合理连接方式：

面试推荐说法：

I would not claim GR00T directly depends on NIXL or GPUNetIO without checking the production stack. The safe connection is that GR00T is another AI inference workload where GPU acceleration, data movement, profiling, and low-latency deployment matter. For multi-GPU training or fine-tuning, NCCL can be relevant. For edge or robotics deployment, TensorRT and end-to-end latency profiling are more directly relevant.

16.11 两天内怎么快速掌握 GR00T 到可面试程度

目标不是成为 robotics expert，而是能清楚回答：

GR00T 是什么？
为什么它是 VLA，不是普通 LLM？
它的数据、训练、推理、部署路径是什么？
它和 NVIDIA GPU system/inference stack 有什么关系？
我能怎么本地验证一小部分？

Day 1：理解架构和数据

Day 1 结束你要能说：

GR00T is a VLA policy model for robots. It takes visual observations, language instructions, and robot state, then predicts continuous action chunks. The learning problem is harder than text generation because the model must work with embodiment-specific state/action spaces and closed-loop physical execution.

Day 2：连接系统和面试回答

Day 2 结束你要能说：

My GR00T study helped me understand NVIDIA's Physical AI direction. For this role, I would connect it to the systems side: GPU inference, profiling, low-latency deployment, data movement, and distributed training/fine-tuning where applicable.

16.12 GR00T 面试可能被追问什么

Q1：GR00T 是什么？

中文要点：

• NVIDIA Isaac GR00T 是 robot foundation model / development platform。
• 当前公开主线是 GR00T N1.x，N1.7 是近期公开版本。
• 它是 VLA：vision-language-action。
• 输入语言、视觉、机器人状态，输出动作。

英文回答：

GR00T is NVIDIA's robotics foundation model direction for Physical AI. It is a vision-language-action model for generalist robot skills. Instead of generating text tokens like an LLM, it consumes language instructions, visual observations, and robot proprioceptive state, then predicts continuous robot actions or action chunks.

Q2：GR00T 和普通 LLM 最大区别是什么？

中文要点：

• LLM 输出 token；GR00T 输出 action。
• LLM 主要优化文本质量和 serving latency；GR00T 还要考虑闭环控制、安全、实时性。
• GR00T 输入包含 robot state 和视觉。

英文回答：

The biggest difference is the output and the deployment loop. An LLM generates tokens, while GR00T-style VLA policies generate robot actions. That means latency, jitter, closed-loop stability, embodiment-specific state/action spaces, and safety become central concerns.

Q3：GR00T 为什么需要 synthetic data / world models？

中文要点：

• 真实机器人 demonstration 贵、慢、危险、覆盖不足。
• 仿真和 world model 可以扩展任务、场景、物体和动作。
• 但 synthetic data 有 sim-to-real gap，需要真实数据和闭环评估验证。

英文回答：

Robot data is expensive and slow to collect, especially for humanoids. Synthetic data and world-model-generated trajectories can broaden task and environment coverage. The risk is sim-to-real gap, so I would treat synthetic data as a scaling tool, not a replacement for real-world validation.

Q4：GR00T 的系统瓶颈可能在哪里？

中文要点：

• sensor preprocessing。
• CPU-GPU copy。
• VLA inference。
• action postprocess/controller。
• policy server/client 网络延迟。
• closed-loop jitter。

英文回答：

I would break the bottleneck down into sensor preprocessing, CPU-GPU transfer, model inference, action postprocessing, controller integration, and policy server-client latency. For a robot, average latency is not enough; jitter and worst-case delay can affect stability and safety.

Q5：如果让你 profile GR00T inference，你怎么做？

中文要点：

• 先 Nsight Systems 看 end-to-end timeline。
• 再 Nsight Compute/TensorRT profiler 看模型 kernel。
• 分 sensor-to-action latency。
• 看 CPU-GPU copy、同步、GPU idle、batching 是否合理。

英文回答：

I would start with an end-to-end sensor-to-action timeline using Nsight Systems: preprocessing, H2D copies, model inference, D2H or action transfer, and controller calls. If model inference dominates, I would inspect TensorRT or CUDA kernel-level metrics. The goal is to reduce both latency and jitter, not just improve average throughput.

Q6：GR00T 和这个 System Software Architect 岗位有什么关系？

中文要点：

• 不是核心 JD，但体现 NVIDIA AI platform 视野。
• 关系点是 inference runtime、GPU acceleration、profiling、deployment、data movement。
• 主线仍然是 CUDA/NIXL/NCCL/UCX/GPUDirect/GPUNetIO。

英文回答：

I see GR00T as a useful context for NVIDIA's Physical AI direction, but not the core of this specific role. The connection is systems-level: GPU inference, profiling, optimized deployment, and data movement. For this job, I would still focus my preparation on CUDA, inference serving, NIXL, NCCL, UCX, GPUDirect, and GPUNetIO.

Q7：GR00T 会用到 NCCL 吗？

中文要点：

• 多 GPU 训练/fine-tuning 可能通过 PyTorch distributed 用 NCCL。
• 单机/单机器人 inference 不一定需要 NCCL。

英文回答：

NCCL can be relevant for multi-GPU training or fine-tuning, but I would not assume it is required for single-policy inference. For deployment, TensorRT and end-to-end latency profiling are more directly relevant. For training, distributed data/model parallelism can bring NCCL into the path.

Q8：GR00T 会用到 NIXL 吗？

中文要点：

• 公开资料主线没有显示 GR00T 依赖 NIXL。
• NIXL 更直接对应 distributed LLM inference 的 KV/state movement。
• 不能乱说。

英文回答：

I would not claim GR00T directly uses NIXL without checking the actual stack. NIXL is more directly tied to distributed inference state movement, such as KV cache transfer. GR00T is still relevant as an inference workload, but the safer connection is GPU acceleration, data movement, and low-latency deployment.

16.13 你可以在面试中怎么自然提到 GR00T

不要主动把话题拉太远。可以在以下场景轻轻带到：

场景 1：被问 “你了解 NVIDIA 最近哪些方向？”

Besides data center inference and GPU networking, I also looked at NVIDIA's Physical AI direction, especially Isaac GR00T. My takeaway is that robotics foundation models create a different inference workload: multimodal input, continuous action output, and tight latency/jitter constraints.

场景 2：被问 “你怎么看未来 AI workload？”

I think AI workloads are moving beyond text generation into agents and Physical AI. GR00T is a good example: the system problem is not only model quality, but also real-time inference, data movement, sensor-to-action latency, and deployment on constrained GPU platforms.

场景 3：被问 “你为什么对 NVIDIA 感兴趣？”

NVIDIA is interesting because the platform spans from data center inference and networking to Physical AI. GR00T is one example where model, simulation, GPU acceleration, and deployment all meet. For this role, I am especially interested in the systems layer that makes these workloads efficient and reliable.

16.14 参考来源

• NVIDIA Isaac GR00T GitHub: https://github.com/NVIDIA/Isaac-GR00T
• NVIDIA GR00T N1.7 model card: https://huggingface.co/nvidia/GR00T-N1.7-3B
• NVIDIA Research GR00T N1.5: https://research.nvidia.com/labs/gear/gr00t-n1_5/
• GR00T N1 paper: https://arxiv.org/abs/2503.14734
• GR00T-Dreams / DreamGen GitHub: https://github.com/NVIDIA/GR00T-Dreams
• GR00T Whole-Body Control docs: https://nvlabs.github.io/GR00T-WholeBodyControl/

17. 参考资料

• NVIDIA Dynamo documentation: https://docs.nvidia.com/dynamo
• NVIDIA Dynamo blog: https://developer.nvidia.com/blog/introducing-nvidia-dynamo-a-low-latency-distributed-inference-framework-for-scaling-reasoning-ai-models/
• NIXL GitHub: https://github.com/ai-dynamo/nixl
• NVIDIA NIXL blog: https://developer.nvidia.com/blog/enhancing-distributed-inference-performance-with-the-nvidia-inference-transfer-library/
• NVIDIA DOCA GPUNetIO docs: https://docs.nvidia.com/doca/sdk/DOCA-GPUNetIO/index.html
• NVIDIA DOCA UCX docs: https://docs.nvidia.com/doca/sdk/DOCA-UCX/index.html
• OpenUCX docs: https://openucx.org/documentation/
• NVIDIA NCCL documentation: https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/
• NVIDIA CUDA Programming Guide: https://docs.nvidia.com/cuda/cuda-programming-guide/index.html
• NVIDIA CUDA Best Practices Guide: https://docs.nvidia.com/cuda/cuda-c-best-practices-guide/
• NVIDIA Nsight Compute docs: https://docs.nvidia.com/nsight-compute/
• NVIDIA Nsight Systems: https://developer.nvidia.com/nsight-systems