先记住一条分层CodeBlock Loading...硬件/互联：GPU、SM、HBM、host memory、PCIe、NVLink、RDMA；决定可用算力、带宽和通信路径。runtime：负责把模型权重、算子、调度、批处理、KV cache 和 GPU worker 组织起来执行；例如 vLLM、TensorRT-LLM、SGLang、Triton backend。gateway/router：接入认证、限流、路由、负载均衡、重试、流式转发；它通常不执行 Transformer forward，也不拥有 runtime 的全部调度状态。平台：Kubernetes 放置和维护 Pod/Service 等对象；Ray 调度任务/Actor 和逻辑资源；KubeRay 用 CRD 管理 Ray 集群与作业。观测与评测：Prometheus 负责可抓取的指标时序，OpenTelemetry 统一 traces/metrics/logs 的采集语义；压测工具才是 workload 的测量端。1. 硬件、CUDA 与性能术语中文解释学习边界Host / DeviceCPU 及其内存是 host；GPU 及其显存是 device。CPU 代码可以发起 GPU kernel、内存拷贝并等待完成。“GPU 可见”不等于程序已经把工作放在 GPU 上；还要看 kernel、数据和同步。SM / CUDA core / kernelSM 是 GPU 执行线程块的硬件单元；kernel 是在 device 上启动的函数。线程块由 SM 调度。kernel 启动、同步和访存都会影响端到端时间，不能只看理论 FLOPS。HBM / global memory / shared memory / registerHBM 通常承载模型权重和 KV cache；global memory 可被所有 SM 访问；shared memory 是线程块内的片上共享空间；register 是线程私有。算力受限与带宽/访存受限是不同瓶颈；decode 常更容易暴露权重/KV 访存和同步成本。Occupancy可驻留在 SM 上的线程束/线程块相对硬件上限的占用程度。occupancy 高不等于性能一定高；还要看内存带宽、指令效率、访存合并和实际并行度。FLOPS、带宽、arithmetic intensityFLOPS 表示算术吞吐，内存带宽表示单位时间搬运数据量，arithmetic intensity 是每搬运一个字节对应的计算量。Roofline 是性能上界分析工具，不是实测利用率；应把 kernel、通信、调度和 API 开销分开测。CUDA stream / asynchronousstream 是有序 GPU 工作队列；许多 CUDA 操作可异步发起，必要时用事件或同步建立依赖。“函数返回”不代表 GPU 已完成；计时必须正确同步。来源：CUDA Programming Model、CUDA C++ Programming Guide。2. 分布式训练与通信术语中文解释不要混淆rank / world size / process grouprank 是进程在通信组中的编号；world size 是组内进程数；process group 定义参与哪些通信。rank 不是 GPU 编号，映射需要显式确认；不同 group 可有不同成员。collective需要组内所有 rank 按一致顺序参与的通信操作。常见有 Broadcast、AllReduce、AllGather、ReduceScatter、AlltoAll。AllReduce 是通信语义，不是算法；Ring/Tree 是实现方式，NCCL 是通信库。AllReduce各 rank 提供数据，做求和等规约后，每个 rank 都收到相同结果。DDP 常用它同步梯度。必须保证 count、dtype、调用顺序和 rank 参与一致，否则可能 hang、崩溃或数据错误。AllGather / ReduceScatterAllGather 把各 rank 数据拼接后发给所有 rank；ReduceScatter 先规约，再把不同分片发给各 rank。ReduceScatter + AllGather 在语义上可组成 AllReduce，但内存形态和通信开销仍要实测。DDP / FSDPDDP 通常每进程持有完整模型并同步梯度；FSDP 将参数、梯度和优化器状态分片，并在需要时聚合/释放。二者都是 PyTorch 训练抽象，不等同于 Kubernetes/Ray 的作业调度。DP（Data Parallel）不同副本处理不同数据，参数副本通过梯度同步保持一致；在推理服务中常指多个独立 engine/副本处理不同请求。训练 DP 与服务 DP 的目标相似但状态不同；服务 DP 的 KV cache 通常是每实例独立的。TP（Tensor Parallel）把单层的权重/计算张量切到多个 GPU，GPU 需要频繁通信协同完成一次 forward。TP 不是“多起几个副本”；它形成一个逻辑模型实例，通信拓扑很关键。PP（Pipeline Parallel）把不同层/阶段放到不同 GPU，micro-batch 在阶段间流动。PP 的气泡、stage 负载不均和激活保存不同于 TP 的层内通信。EP（Expert Parallel）MoE 的 experts 分布在不同 rank，token 按路由发往对应 expert，典型通信是 AlltoAll。EP 只描述 experts 的并行方式；attention 层仍可能采用 TP/DP，不能把 EP 当成 DP 或 TP 的同义词。来源：PyTorch Distributed、NCCL Overview、NCCL Collective Operations。3. 模型执行与 LLM 推理术语中文解释工程提示training vs inferencetraining 有 forward、loss、backward、梯度和 optimizer update；inference 通常只做 forward 和采样，不更新权重。训练吞吐常以 samples/tokens per second 和 step time 看；服务还要看排队、首 token 和流式间隔。prefill把用户输入 prompt 的一批 token 送入模型，计算上下文表示并建立 KV cache。往往更偏大矩阵计算；长 prompt 主要影响 TTFT 和显存占用。decode自回归地逐步生成新 token；每步用新 query 访问已有上下文的 KV cache。常是小计算 + 大量权重/KV 访存；受带宽、batch、cache 布局和调度影响。KV cache保存已处理 token 的 Key/Value，避免 decode 时反复计算历史 token。它不是模型权重，也不是“缓存完整响应”；大小随上下文 token、层数、KV heads、head dimension、dtype 增长。MHA / GQA / MQAMHA 每个 query head 有对应 KV heads；GQA 多个 query heads 共享一组 KV heads；MQA 进一步共享为极少 KV heads。减少 KV heads 通常降低 KV cache 和 decode 访存，但不等于减少 query heads 或模型全部计算。continuous / in-flight batching请求不必等到整批结束，调度器可在迭代间加入/退出请求，使不同请求的 prefill/decode 共同利用 GPU。batch size、并发、队列等待和 token 预算共同决定吞吐/延迟；不要只看静态 batch。paged KV cache / prefix caching将 KV cache 按块管理，减少连续大块内存要求；prefix caching 复用相同前缀的已计算 KV。命中率、块大小、租约/回收策略和多副本路由都会改变收益；cache 命中不等于请求直接返回。quantization / speculative decodingquantization 用更低精度存储或计算；speculative decoding 先由 draft 生成候选，再由 target 验证。量化主要影响权重/计算/带宽，未必自动缩小 KV cache；加速取决于模型、硬件和接受率。来源：vLLM Architecture Overview、vLLM Data Parallel Deployment、vLLM Serve/KV cache options、SGLang 文档、TensorRT-LLM 文档。4. LLM 推理服务与平台运维model execution runtime：加载权重、执行算子、管理 GPU worker、调度请求和 KV cache。vLLM 官方架构明确把 Engine Core 的职责描述为 scheduler、KV cache 和 GPU worker 协调。inference server：为一个或多个模型提供协议、模型实例、批处理、健康检查和指标；Triton 的 dynamic batching 会在排队窗口内组合请求，并可配置 preferred batch size / queue delay。gateway / router：在客户端与后端 runtime 之间做鉴权、路由、限流、重试、故障摘除和流式代理。它可以按负载或 KV-cache locality 选择 backend，但不因此变成 inference runtime。Kubernetes Pod / Deployment / Service：Pod 是可调度的运行单元；Deployment 管理无状态副本的期望状态；Service 提供稳定的服务发现/访问入口。Kubernetes 负责资源编排与生命周期，不负责 Transformer 的 TP/PP 计算语义。Ray task / actor / logical resource：Ray task 是可调度函数调用，Actor 是有状态计算实体；Ray 用逻辑 CPU/GPU/自定义资源表达调度需求。Ray Train 可建立训练 worker group 并接入 PyTorch Distributed。KubeRay：Kubernetes 上管理 Ray 的 operator；核心 CRD 是 RayCluster、RayJob、RayService。它连接平台生命周期与 Ray 运行时，但不替代 PyTorch/NCCL 的 collective。autoscaling / admission / backpressure：扩缩容改变容量，admission 控制是否接收请求，backpressure 让上游感知队列或资源不足；三者都不是“把单个模型算得更快”。来源：Triton Dynamic Batching、Triton Metrics、Kubernetes Concepts、Ray Resources、KubeRay on Kubernetes。5. 评测与可观测性指标指标含义边界throughput单位时间完成的请求、输入 token 或输出 token 数。必须写清 request/s、input tok/s 还是 output tok/s，以及并发、输入/输出长度、batch 和是否含排队。latency一个请求从某个起点到终点的耗时。client latency、gateway latency、server request latency、model compute latency 不是同一个量。TTFTTime to First Token，从请求发出/接收到首个输出 token 的时间。受网络、队列、prefill 和首包发送影响，不等于纯 prefill kernel 时间。ITL / TPOT相邻输出 token/流式响应之间的时间，常用来描述 decode 体验；具体命名和分母需看工具定义。不要把平均 ITL 直接当作整请求 latency；输出长度和流式聚合会影响结果。p50 / p95 / p99延迟分布的中位数、95/99 分位。tail latency 不是平均值；应说明时间窗口、样本量、压测稳定阶段和 quantile 计算方法。queue time / compute time请求在调度队列等待的时间 / backend 执行及相关计算时间。总延迟变大可能是容量或 admission 问题，而不是 kernel 变慢。Prometheus counter/gauge/histogram/summarycounter 单调累计，gauge 可升可降，histogram 按 bucket 统计分布，summary 直接暴露客户端侧 quantile。latency 分布通常优先考虑 histogram；不要把 summary 的 quantile 跨实例简单平均。trace / span / metric / logtrace 描述一次跨服务因果链；span 描述其中一个操作；metric 是可聚合数值；log 是事件/记录。OTel 是采集与语义标准，不等于后端存储；应通过 trace id、request id 和模型/版本标签关联。SLO / error budgetSLO 是服务目标（如可用性、TTFT p99、成功率）；error budget 是允许的失败/违约额度。指标是观测事实，SLO 是面向用户的目标；GPU utilization 高不代表 SLO 达标。来源：Prometheus Metric Types、Prometheus Histograms and Summaries、OpenTelemetry Signals、OpenTelemetry Semantic Conventions、Triton GenAI-Perf Metrics。6. 最容易混淆的边界：一页复习训练 ≠ 推理：训练有反向传播和参数更新；推理通常没有。服务端的 DP/TP/PP 是执行部署语义，不能直接套用训练中的梯度同步解释。runtime ≠ gateway：runtime 执行模型并管理调度/KV cache；gateway 负责入口和流量治理。一个 gateway 可以代理多个 runtime，一个 runtime 也可被多个入口访问。throughput ≠ latency：提高并发和 batching 可能提高 token/s，却让排队和 p99 变差；必须在同一 workload 下同时报告两者。DP/TP/PP/EP 不同维度：DP 复制并处理不同样本/请求；TP 切单层张量；PP 切层；EP 切 MoE experts。组合部署时要说明每个维度作用在哪些层和通信组。prefill ≠ decode：prefill 处理已有 prompt 并建立 cache；decode 逐 token 生成并复用 cache。两者可以联合调度，也可以在 P/D disaggregation 中拆到不同实例。KV cache ≠ prefix cache ≠ response cache：KV cache 是模型中间状态；prefix cache 是对相同前缀的 KV 复用；response cache 是对最终结果/响应的缓存，命中语义、失效条件和正确性边界不同。模型并行 ≠ 多副本：TP/PP/EP 共同组成一个跨 GPU 的执行实例；DP 多为多个副本/engine。Kubernetes 的 replica 数量不能单独说明模型并行方式。GPU utilization ≠ 有效吞吐：利用率采样高可能来自通信、拷贝或低效 kernel；应结合 tokens/s、queue time、TTFT/ITL、显存、NCCL 时间和错误率判断。7. 建议的工程学习顺序先用 CUDA 理解 host/device、memory hierarchy、stream、同步和带宽/算力瓶颈。再用 PyTorch Distributed + NCCL 练习 rank、process group、AllReduce/AllGather/ReduceScatter，并观察错误顺序导致的 hang。读一个 runtime 的请求路径：API → scheduler → prefill/decode → KV cache → model forward → sampling → stream response。用 Triton 或 vLLM 做固定模型、固定输入/输出长度、固定并发的压测，分别记录 throughput、TTFT、ITL、p50/p95/p99 和 queue/compute。最后把 runtime 放进 Kubernetes/Ray，明确每一层负责的对象、状态、故障和扩缩容边界，再用 OTel/Prometheus 关联端到端请求。
先记住一条分层
1. 硬件、CUDA 与性能
术语
中文解释
学习边界
Host / Device
CPU 及其内存是 host；GPU 及其显存是 device。CPU 代码可以发起 GPU kernel、内存拷贝并等待完成。
“GPU 可见”不等于程序已经把工作放在 GPU 上；还要看 kernel、数据和同步。
SM / CUDA core / kernel
SM 是 GPU 执行线程块的硬件单元；kernel 是在 device 上启动的函数。线程块由 SM 调度。
kernel 启动、同步和访存都会影响端到端时间，不能只看理论 FLOPS。
HBM / global memory / shared memory / register
HBM 通常承载模型权重和 KV cache；global memory 可被所有 SM 访问；shared memory 是线程块内的片上共享空间；register 是线程私有。
算力受限与带宽/访存受限是不同瓶颈；decode 常更容易暴露权重/KV 访存和同步成本。
Occupancy
可驻留在 SM 上的线程束/线程块相对硬件上限的占用程度。
occupancy 高不等于性能一定高；还要看内存带宽、指令效率、访存合并和实际并行度。
FLOPS、带宽、arithmetic intensity
FLOPS 表示算术吞吐，内存带宽表示单位时间搬运数据量，arithmetic intensity 是每搬运一个字节对应的计算量。
Roofline 是性能上界分析工具，不是实测利用率；应把 kernel、通信、调度和 API 开销分开测。
CUDA stream / asynchronous
stream 是有序 GPU 工作队列；许多 CUDA 操作可异步发起，必要时用事件或同步建立依赖。
“函数返回”不代表 GPU 已完成；计时必须正确同步。
来源：
CUDA Programming Model、
CUDA C++ Programming Guide。
2. 分布式训练与通信
术语
中文解释
不要混淆
rank / world size / process group
rank 是进程在通信组中的编号；world size 是组内进程数；process group 定义参与哪些通信。
rank 不是 GPU 编号，映射需要显式确认；不同 group 可有不同成员。
collective
需要组内所有 rank 按一致顺序参与的通信操作。常见有 Broadcast、AllReduce、AllGather、ReduceScatter、AlltoAll。
AllReduce 是通信语义，不是算法；Ring/Tree 是实现方式，NCCL 是通信库。
AllReduce
各 rank 提供数据，做求和等规约后，每个 rank 都收到相同结果。DDP 常用它同步梯度。
必须保证 count、dtype、调用顺序和 rank 参与一致，否则可能 hang、崩溃或数据错误。
AllGather / ReduceScatter
AllGather 把各 rank 数据拼接后发给所有 rank；ReduceScatter 先规约，再把不同分片发给各 rank。
ReduceScatter + AllGather 在语义上可组成 AllReduce，但内存形态和通信开销仍要实测。
DDP / FSDP
DDP 通常每进程持有完整模型并同步梯度；FSDP 将参数、梯度和优化器状态分片，并在需要时聚合/释放。
二者都是 PyTorch 训练抽象，不等同于 Kubernetes/Ray 的作业调度。
DP（Data Parallel）
不同副本处理不同数据，参数副本通过梯度同步保持一致；在推理服务中常指多个独立 engine/副本处理不同请求。
训练 DP 与服务 DP 的目标相似但状态不同；服务 DP 的 KV cache 通常是每实例独立的。
TP（Tensor Parallel）
把单层的权重/计算张量切到多个 GPU，GPU 需要频繁通信协同完成一次 forward。
TP 不是“多起几个副本”；它形成一个逻辑模型实例，通信拓扑很关键。
PP（Pipeline Parallel）
把不同层/阶段放到不同 GPU，micro-batch 在阶段间流动。
PP 的气泡、stage 负载不均和激活保存不同于 TP 的层内通信。
EP（Expert Parallel）
MoE 的 experts 分布在不同 rank，token 按路由发往对应 expert，典型通信是 AlltoAll。
EP 只描述 experts 的并行方式；attention 层仍可能采用 TP/DP，不能把 EP 当成 DP 或 TP 的同义词。
来源：
PyTorch Distributed、
NCCL Overview、
NCCL Collective Operations。
3. 模型执行与 LLM 推理
术语
中文解释
工程提示
training vs inference
training 有 forward、loss、backward、梯度和 optimizer update；inference 通常只做 forward 和采样，不更新权重。
训练吞吐常以 samples/tokens per second 和 step time 看；服务还要看排队、首 token 和流式间隔。
prefill
把用户输入 prompt 的一批 token 送入模型，计算上下文表示并建立 KV cache。
往往更偏大矩阵计算；长 prompt 主要影响 TTFT 和显存占用。
decode
自回归地逐步生成新 token；每步用新 query 访问已有上下文的 KV cache。
常是小计算 + 大量权重/KV 访存；受带宽、batch、cache 布局和调度影响。
KV cache
保存已处理 token 的 Key/Value，避免 decode 时反复计算历史 token。
它不是模型权重，也不是“缓存完整响应”；大小随上下文 token、层数、KV heads、head dimension、dtype 增长。
MHA / GQA / MQA
MHA 每个 query head 有对应 KV heads；GQA 多个 query heads 共享一组 KV heads；MQA 进一步共享为极少 KV heads。
减少 KV heads 通常降低 KV cache 和 decode 访存，但不等于减少 query heads 或模型全部计算。
continuous / in-flight batching
请求不必等到整批结束，调度器可在迭代间加入/退出请求，使不同请求的 prefill/decode 共同利用 GPU。
batch size、并发、队列等待和 token 预算共同决定吞吐/延迟；不要只看静态 batch。
paged KV cache / prefix caching
将 KV cache 按块管理，减少连续大块内存要求；prefix caching 复用相同前缀的已计算 KV。
命中率、块大小、租约/回收策略和多副本路由都会改变收益；cache 命中不等于请求直接返回。
quantization / speculative decoding
quantization 用更低精度存储或计算；speculative decoding 先由 draft 生成候选，再由 target 验证。
量化主要影响权重/计算/带宽，未必自动缩小 KV cache；加速取决于模型、硬件和接受率。
来源：
vLLM Architecture Overview、
vLLM Data Parallel Deployment、
vLLM Serve/KV cache options、
SGLang 文档、
TensorRT-LLM 文档。
4. LLM 推理服务与平台运维
来源：
Triton Dynamic Batching、
Triton Metrics、
Kubernetes Concepts、
Ray Resources、
KubeRay on Kubernetes。
5. 评测与可观测性指标
指标
含义
边界
throughput
单位时间完成的请求、输入 token 或输出 token 数。
必须写清 request/s、input tok/s 还是 output tok/s，以及并发、输入/输出长度、batch 和是否含排队。
latency
一个请求从某个起点到终点的耗时。
client latency、gateway latency、server request latency、model compute latency 不是同一个量。
TTFT
Time to First Token，从请求发出/接收到首个输出 token 的时间。
受网络、队列、prefill 和首包发送影响，不等于纯 prefill kernel 时间。
ITL / TPOT
相邻输出 token/流式响应之间的时间，常用来描述 decode 体验；具体命名和分母需看工具定义。
不要把平均 ITL 直接当作整请求 latency；输出长度和流式聚合会影响结果。
p50 / p95 / p99
延迟分布的中位数、95/99 分位。
tail latency 不是平均值；应说明时间窗口、样本量、压测稳定阶段和 quantile 计算方法。
queue time / compute time
请求在调度队列等待的时间 / backend 执行及相关计算时间。
总延迟变大可能是容量或 admission 问题，而不是 kernel 变慢。
Prometheus counter/gauge/histogram/summary
counter 单调累计，gauge 可升可降，histogram 按 bucket 统计分布，summary 直接暴露客户端侧 quantile。
latency 分布通常优先考虑 histogram；不要把 summary 的 quantile 跨实例简单平均。
trace / span / metric / log
trace 描述一次跨服务因果链；span 描述其中一个操作；metric 是可聚合数值；log 是事件/记录。
OTel 是采集与语义标准，不等于后端存储；应通过 trace id、request id 和模型/版本标签关联。
SLO / error budget
SLO 是服务目标（如可用性、TTFT p99、成功率）；error budget 是允许的失败/违约额度。
指标是观测事实，SLO 是面向用户的目标；GPU utilization 高不代表 SLO 达标。
来源：
Prometheus Metric Types、
Prometheus Histograms and Summaries、
OpenTelemetry Signals、
OpenTelemetry Semantic Conventions、
Triton GenAI-Perf Metrics。
6. 最容易混淆的边界：一页复习
7. 建议的工程学习顺序