状态：草案（2026-10-07），知识图谱文章。 本文没有进行新的测量，而是将同一系列其他文章中 作者亲自测量的值与 文档确认的内容编纂为一张图。数字旁标注了出自哪篇文章及测量时的条件。由于所有测量均在一两个小模型、单张 GPU（8GB 级别）、一次性单节点集群上进行，因此请重点关注 形态与原理，而非绝对数值。基于文档或未经测量的内容标记为“基于文档”、“未实测”。 编写规则：以实测数据为基础，未能测量的内容标记为“未实测”。
目录
- 1. 如何阅读本文
- 2. 一张图总览：八个分层
- 3. 第 1 层：GPU 与硬件，速度上限来自何处
- 4. 第 2 层：Kubernetes 的 GPU 栈
- 5. 第 3 层：调度与多租户
- 6. 第 4 层：LLM 推理引擎，用数字去理解
- 7. 第 5 层：网络
- 8. 第 6 层：存储与模型部署
- 9. 第 7 层：可观测性与故障诊断
- 10. 第 8 层：控制器与部署自动化（Kubernetes 工程师的工具）
- 11. 测量方法：贯穿所有分层的技术
- 12. 4 周学习路径
- 13. 实战与面试中常见的问题
- 14. 本图谱未涉及的内容
- 参考：本图谱的依据文章
- 确认日期
1. 如何阅读本文
ML·AI 基础设施不是单一领域，而是 多层叠加的领域。不了解 GPU 内存带宽，就无法解释推理数字；不了解 Kubernetes 调度器，就不知道 GPU 任务为什么会卡住；不了解可观测性，就无法修复这两者。本文总结了每一层的“核心必知内容”，并串联了深度阅读文章。
阅读顺序分为两种：
- ML·AI 基础设施工程师： 先阅读第 2~5 节（硬件、栈、调度、推理），然后转到第 9 节的测量方法。
- Kubernetes 工程师： 先阅读第 3、4、8 节（栈、调度、控制器），再通过第 2 节和第 5 节来补足 GPU 与通用资源的区别。
2. 一张图总览：八个分层
| 分层 | 核心问题 | 代表工具与概念 | 深度阅读文章 |
|---|---|---|---|
| 1. GPU 与硬件 | 是什么决定了速度上限 | 内存带宽、计算吞吐量、VRAM 配置 | 第 21 篇、第 11 篇 |
| 2. Kubernetes 的 GPU 栈 | GPU 是如何触达 Pod 的 | 驱动、Toolkit、Device Plugin、GPU Operator、直通（Passthrough） | 第 3 篇、第 13 篇 |
| 3. 调度与多租户 | 多个团队和任务如何共享 GPU | Kueue、Volcano、协同调度（Gang Scheduling）、配额、抢占 | 第 10 篇、第 9 篇 |
| 4. LLM 推理引擎 | 是什么决定了吞吐量与延迟 | 连续批处理、KV 缓存、前缀缓存、Chunked Prefill、量化、LoRA | 第 4 篇、第 5 篇、第 14 篇、第 15 篇 |
| 5. 网络 | 服务扩展与 GPU 间通信 | CNI、kube-proxy 对比 Cilium、服务网格、RDMA、NCCL | 第 2 篇、第 7 篇 |
| 6. 存储与模型部署 | 权重和 KV 放在哪里 | 模型缓存、冷启动、KV 卸载、权重保护 | 第 8 篇、第 16 篇 |
| 7. 可观测性与故障诊断 | 观察什么以及何时发出警报 | DCGM、XID、TTFT·ITL 分位数、服务器指标 | 第 17 篇、第 18 篇、第 11 篇、 第 25 篇 |
| 8. 控制器与部署自动化 | 如何维持声明式状态 | CRD、Operator、GitOps | 第 9 篇 |
3. 第 1 层：GPU 与硬件，速度上限来自何处
应当了解的内容
- Token 生成的速度上限由内存带宽决定。 每生成一个 Token，都要完整读取一次各层的权重，因此
초당 토큰 수 ≤ 메모리 대역폭 ÷ 가중치 바이트是访存密集型任务。 - 输入（提示词）处理的速度上限由计算能力决定。 当同时计算大量 Token 时，多个 Token 会复用相同的权重。
- VRAM 由权重、KV 缓存、激活值和 CUDA 图（CUDA Graph）共同分摊占用。 在推理服务中，决定吞吐量的通常是 KV 缓存所剩余的份额。
- 消费级 GPU 与数据中心 GPU 的诊断功能有所不同。 可能缺少 ECC、行重映射（Row Remapping）或性能剖析指标。
- 容器的 CUDA 版本不能超过宿主机驱动决定的上限。 如果上传镜像后启动失败，首先应检查驱动版本。
亲自测量的数字 （第 21 篇、第 11 篇）
| 确认项目 | 结果 |
|---|---|
| 四个大小、精度各异的模型的生成速度 × 权重大小 | 达到测得带宽（250GB/s）的 86%~98% |
| 将精度减半（从 bf16 到 fp8） | 权重缩小了 1.7 倍，但速度只提升了 1.54 倍（随着 Token 固定的开销占比增加，收益有所下降） |
| 输入处理（1,024 个 Token 以上） | 约为测得矩阵乘法吞吐量的 75%~80%，比同一模型的生成速度快 65~127 倍 |
| 三种消费级 GPU 的 ECC 与页面退役（Page Retirement） | 全为 N/A |
| 行重映射 | 三种中仅有一种返回了数值（需要区分 0 与 N/A） |
常见陷阱
- 没有将测量值与硬件极限进行对比。 当输入处理速度达到 GPU 计算极限的 20 倍时，我们借此意识到了前缀缓存命中的错误（第 14 篇、第 21 篇）。
- 将 PCIe 代际处于闲置降级状态误认为是降频。 必须施加负载后重新读取（第 11 篇）。
grep Xid排查错误的日志行。同时捕获网卡驱动的芯片修订行以及非 Xid 的 GPU 驱动错误。 使用NVRM: Xid进行缩小定位（第 11 篇）。
4. 第 2 层：Kubernetes 的 GPU 栈
应当了解的内容
- GPU 是一种扩展资源（Extended Resource）。 只能以整数请求，请求值与限制值必须相等，且不支持超分（Overcommit）与共享。
- 软件栈是自下而上构建的。 宿主机内核模块（驱动）、容器运行时工具包、Device Plugin（资源宣告）、节点标签（GFD）、监控（DCGM exporter）。GPU Operator 会将这些一次性全部安装好。
- 不同的共享方式，其隔离级别也不同。 时间分片（Time-slicing）不隔离内存，MIG 仅在支持的 GPU 上通过硬件划分，而软件方式（如 HAMi 等）会拦截 CUDA 调用（基于文档，第 3 篇与第 10 篇）。
- 也可以将 GPU 整体直通给虚拟机。 此时宿主机无法使用该 GPU，因此需要以节点为单位将 GPU 划分为容器专用或虚拟机专用（第 13 篇）。
- 明确驱动、Toolkit 和 Operator 的职责分工，可以加快故障排查速度。 失败在哪一层，会根据症状（
nvidia-smi失败、Pod 处于 Pending、容器启动失败）而有所不同。
常见陷阱
- 在未确定是由 Operator 安装宿主机驱动还是宿主机本已存在的情况下，直接部署 Operator。 两者会发生冲突（第 3 篇）。
- 新的 CUDA 镜像无法在旧驱动上启动。 实际上，CUDA 13 镜像在 CUDA 12 系列驱动上因初始化错误（Error 804）而失败（作者的测试，本文仅讨论通用原理）。
- GPU Pod 因节点内存请求总和过高而陷入 Pending。 即使 GPU 空闲，如果通用资源（内存）不足，也无法调度。应首先阅读等待原因消息。
5. 第 3 层：调度与多租户
应当了解的内容
- 默认调度器是以单个 Pod 为单位进行决策的。 需要多个 Pod 同时启动才有意义的工作负载（分布式训练、多节点推理），会导致部分 Pod 获取资源后互相等待。
- 协同调度（Gang Scheduling）有两种方式。 Kueue 按工作负载单位检查配额，在获得批准前不创建 Pod；而 Volcano 则通过独立调度器在 Pod 组能够满足最小数量时才统一分配资源。
- 配额、借用、归还与抢占是设计问题。 通过策略来规定谁可以借用剩余资源，以及当拥有者返回时谁会被驱逐。
- LeaderWorkerSet 提供了组级别的恢复机制。 在多节点推理中，如果其中一个 Rank 消失，其余 Rank 将失去意义，因此默认做法是重建整个组。
亲自测量的数字 （第 10 篇、第 9 篇）
| 确认项目 | 结果 |
|---|---|
| 两个各需 4 个 Pod 的任务争夺 8 个资源（默认调度器） | 在 60 秒内各自占有 2 个并陷入停滞（死锁） |
| 相同情况下的 Kueue、Volcano | 仅接受一个任务并在约 2~4 秒内运行 4 个 Pod，不存在仅部分运行的状态 |
| 删除已被接受的任务后，等待任务启动的时间 | Kueue 3.0~3.6 秒，Volcano 3.6~4.2 秒 |
| 在 LeaderWorkerSet 中删除一个 Worker 时 | 同组的 3 个 Pod 全部重新创建，其他组保持不变（约 2 秒） |
| 仅使用 LeaderWorkerSet 且资源不足时 | 仅 Leader 处于 Running 状态，Worker 处于 Pending，且无协同调度 |
常见陷阱
- 在没有协同调度的情况下提交大型任务。 任务会占用资源并互相等待，导致集群闲置。
- 在不了解终止宽限期（Termination Grace Period）的情况下测量抢占与归还时间。 如果被驱逐的 Pod 忽略终止信号，它会耗尽整个宽限期（默认 30 秒）才结束，导致测量值变成了宽限期（第 10 篇中的实际经历）。
- 迷信“以相同优先级同时提交就能决定先后顺序”。 哪一个任务先被接受，每次并不完全相同。
6. 第 4 层：LLM 推理引擎，用数字去理解
这是被询问最多、测量最多的分层。我们在 8GB 级单张 GPU 上使用 1.7B 模型对 vLLM 和 SGLang 进行了测量（第 5 篇、第 14 篇、第 15 篇）。
应当了解的内容
- 连续批处理（Continuous Batching）让并发请求分摊了权重读取成本。 因此，提高并发度会使总吞吐量几乎成正比增长，直到在 KV 缓存容量处拐弯下降。
- 每个 Token 的 KV 大小可以通过公式计算。
2 × 층 × KV 헤드 × head_dim × 바이트. 并发上限可以估算为KV 용량 ÷ 요청당 토큰。 - 前缀缓存（Prefix Caching）可跳过公共前缀的输入处理。 对于在前方固定了系统提示词和文档的服务而言，这是性价比最高的优化。
- Chunked Prefill 决定了长输入中断其他用户 Token 的时间。
- 量化分为两种。 权重量化改变速度（读取字节数），KV 量化改变容量（容纳的 Token 数量）。
- LoRA 在单一基座模型上加载小型适配器进行推理。 同时使用的适配器数量与槽位（Slot）数量的关系决定了性能。
亲自测量的数字
| 确认项目 | 结果 | 文章 |
|---|---|---|
| 服务器日志中的 KV 容量 ÷ Token 数量 | 每个 Token 约 114,900 字节，在公式计算值 114,688 字节的 0.2%~0.3% 以内 | 第 14 篇 |
| 并发请求从 1 增至 16 | 总吞吐量提升 14~15 倍，单请求速度下降 8%~14% | 第 21 篇 |
| 并发从 32 增至 64（输入 512） | 初次测得服务器吞吐量从 831 降至 787 tok/s，首字延迟（TTFT）从 666ms 增至 5.7 秒，达 8.6 倍。重启服务器三次后，根据 KV 容量（从 22,048 到 26,560 tokens），时间分散在 2.1 到 5.7 秒之间 | 第 14 篇 |
| KV 8 位量化 | 相同内存下承载 1.9 倍的 token，长输入（2,048 tokens）并发 16 时 TTFT 从 4.0 秒降至 0.94 秒 | 第 14 篇 |
| 前缀缓存（公共 3,000 tokens） | 首字延迟从 394ms 降至 28ms，关闭时为 393ms | 第 14 篇 |
| 当长输入（3,500 tokens）插入时的最大 token 间隔 | 512 tokens 分块时为 69ms，2,048 tokens 约 227ms，8,192 tokens 为 445ms | 第 14 篇 |
| 同类测试中的 SGLang 默认行为 | 即使将分块减小到 512，仍为 472ms（处理整个输入的时间），开启混合分块后才能达到 69ms | 第 5 篇 |
| 两个引擎的纯吞吐量 | 并发 1~64 时在 ±5% 范围内（受带宽限制的小模型） | 第 5 篇 |
| 使用 LoRA 适配器请求的吞吐量 | 以 48 个请求为基准，减少约 10%（单个适配器）到 12.5%（混合两个）（5 次重复的中位数，单次测得的 17.9% 混入了预热值），保持开启 LoRA 本身是没有开销的 | 第 15 篇 |
| 用 2 个槽位服务 3 个适配器 | 吞吐量降至 4 个槽位时的 56% | 第 15 篇 |
| 服务器重启 | 35~55 秒（权重加载 4~6 秒），首次启动由于编译需要 71 秒 | 第 14 篇 |
实战准则
- 并发限制应设在 KV 能够容纳的请求数附近。 超过该值吞吐量不会增加，只会增加 TTFT。
- TTFT 查看 p95，token 间隔（ITL）查看 p99。 即使中位数正常，尾部延迟也很大（ITL p99 达 223ms）。
- 在比较引擎之前，先对齐默认设置。 相同名称的选项默认值也可能不同（分块大小、混合分块、内存设置）。
- 将前缀重叠的请求发送到同一个实例。 缓存存在于实例内部（第 8 篇，参考文档）。
7. 第 5 层：网络
需要了解的内容
- 随着服务数量增加，iptables 规则也会增加。 Cilium 的 eBPF 使用映射（map）查询代替规则来实现服务负载均衡。
- 服务网格会为每个请求增加代理跳数。 在 LLM 服务中，首字延迟需要几百毫秒，因此这个开销很小，但在按 token 流式传输响应或短调用中可能会显现出来。
- GPU 间的通信是单独的一层。 NCCL 负责集合通信，而在节点之间，RDMA（InfiniBand 或 RoCE）会绕过 CPU。
- RDMA 常见故障在于配置。 锁定内存限制（memlock）、MTU 不匹配、GID 选择、PFC·ECN。
实测数据 （第 2 篇、第 7 篇）
| 验证项目 | 结果 |
|---|---|
| Istio Sidecar（mTLS） | 每个请求增加约 2.2ms。加密约占 8%，其余为代理开销，其中 HTTP 解析约占 39%（即使改用无解析的 L4 仍会残留 +1.35ms）。gRPC 为 +3.4ms，100MiB 响应导致吞吐量下降 3.5~4.5 倍，流式事件间隔（20ms）不受影响 |
| 超出 conntrack 限制的 4,000 个并发连接 | 在限制 2,048 下有 1,913 个成功（= 限制 - 现有条目），其余未被拒绝而直接被默默丢弃 |
| 在刚创建 1 万个服务后连接新服务 | kube-proxy 侧需 45 秒（两次中一次），Cilium 侧 0.25 秒 |
| iptables 规则达到 11 万行 | 同一节点内新连接的平均延迟仅增加约 0.05ms（小于通常认知） |
| 软件 RDMA（rxe） | 同一台机器的 TCP 比 RDMA 写入快约 8 倍（用于概念验证），以太网 MTU 为 1500 时 active_mtu 1024 |
| 普通用户的锁定内存限制为 64·1,024KiB | 1MiB 内存注册以 Failed to create MR 失败，从 8,192KiB 开始成功 |
常见陷阱
- 仅从数据平面延迟的角度理解“服务多时 iptables 很慢”。 在此环境中，差距悬殊的关键在于一次性批量更新规则的时机。
- 相信数值重复出现的表格。 连接尝试限制曾将测量值固定在两个数值上（应当对工具的分辨率保持怀疑）。
8. 第 6 层：存储与模型部署
需要了解的内容
- 权重文件大小约为
파라미터 수 × 바이트。 如果是 70B bf16 则为 140GB，因此需要共享缓存或镜像策略，避免每个节点都下载一遍。 - 冷启动是拉取镜像、下载模型、加载、编译和预热的总和。 在自动扩缩容设计中，这个总和就是新 Pod 接收流量所需的时间。
- 将 KV 卸载到 GPU 之外（CPU、磁盘、远程）可以更长时间地重用前缀。 但前提是加载时间必须比重新计算短才划算。
- 权重加密可以防止存储泄露和篡改，但无法保护运行时的内存。
实测数据 （第 8 篇、第 16 篇、第 14 篇）
| 验证项目 | 结果 |
|---|---|
| 以相同顺序重新读取 10 个无法完全放入 GPU 的文档（约 5 万个 tokens） | 使用 LMCache（CPU 卸载）使 TTFT 从 576ms 降至 48.6ms，首次读取时的存储开销约为 4% |
| 如果 LMCache 的 CPU 容量小于工作集（约 1.49GB） | 则收益为 0（在 0.5GB、1.0GB 时命中率为 0），1.5GB 时将 600ms 降至 39ms（命中率 98%）。上下文越长收益越大，6,414 tokens 时约有 19 倍提升 |
| 盈亏平衡命中率 | 约 4%（根据该测试的值计算） |
| 使用 AES-256-GCM 加密权重文件 | 文件大小增加约 0.00005%，解密速度 0.78~0.95 GB/s（纯计算 1.8~2.2 GB/s） |
| 密文篡改 1 字节，分块顺序调换 | 两者均被拒绝解密（InvalidTag）。如果没有 AAD，将无法检测到调换、裁剪以及跨文件的分块调换 |
| 关闭 AES 硬件加速时 | 解密慢 4~7 倍（从 2.0 降至 0.47、0.29 GB/s）。线程数停留在 2 个，但进程可扩展至 8 个 |
| 将解密后的权重放在内存卷中并启动服务器（0.6B 模型） | 约 2.3 秒的解密时间叠加在服务器准备就绪（约 28 秒）之前。被篡改的文件在服务器启动前就会被拒绝 |
| 在运行时加载 LoRA 适配器（6.4MB） | 无需重启服务器，耗时在 0.2 秒以内（文档警告生产环境慎用） |
9. 第 7 层：可观测性与故障诊断
需要了解的内容
- GPU 指标分为三个层级。 硬件层（DCGM：利用率、功耗、温度、时钟限制原因、XID）、服务器层（队列、KV 利用率、抢占数）、服务层（TTFT、ITL、错误率）。
- 只看利用率会被欺骗。 受内存带宽限制的服务器，即使利用率很高也可能几乎没有进行有效计算。
- XID 是 GPU 驱动程序留在内核日志中的错误编号。 普通账户可能无法访问
dmesg，因此通常使用journalctl -k。 - Cilium 和 DCGM 的指标非常多，基数（cardinality）就是成本。 标签组合决定了时间序列的数量（第 17 篇、第 18 篇）。
- 告警应将症状（TTFT 尾部延迟）与根因（VRAM 趋势、时钟限制）分开。
- 追踪（Trace）是贯穿单个请求的信号。 vLLM 会为每个请求在单个 Span 中记录等待、预填充（prefill）和解码时间的属性，仅凭这一点就能区分慢请求是因为等待还是计算。开启的开销在误差范围内，而要捕获慢请求，需要的不是概率采样，而是尾部采样（Tail Sampling）（第 25 篇）。
常见陷阱
- 将 N/A 和 0 视为等同。 不支持的指标显示为 N/A 而不是 0（第 11 篇）。
- 在不知道每次服务器重启时 KV 容量都会变化的情况下，直接用内存数值进行比较。 应当按每个 token 的字节数进行比较（第 14 篇）。
10. 第 8 层：控制器与部署自动化（Kubernetes 工程师的工具）
需要了解的内容
- 基于级别的调节（Level-triggered）。 读取当前状态而非事件，将其与期望状态进行比较并进行调整。即使漏掉事件，下一次调节也会将其修正。
- 幂等性。 如果状态已经匹配，则不应写入任何内容。
- 所有权引用（Owner Reference）与 Finalizer。 子资源会在所有者被删除时一同清理，而 Finalizer 则在清理完成后才允许删除。
- CRD 的核心在于架构与验证设计。 简单规则使用 CEL，复杂规则使用 Webhook。
- 如果在 GitOps 中由其他控制器修改了 Git 中编写的字段，将会发生冲突。 HPA 与
replicas,ignoreDifferences（第 9 篇）。
实测数据 （第 9 篇）
| 验证项目 | 结果 |
|---|---|
| CEL 验证 | 空字符串模型名称在创建阶段被 model must not be empty 拒绝 |
| LWS 滚动更新 | 从序号较大的组开始，每次更新一组（maxUnavailable 1 为默认值） |
运营商的实际运行行为（删除子资源时的恢复时间、幂等性、Finalizer、重复执行、重试）将结合第 9 篇中实际测试的结果进行后续更新。
11. 测量方法：贯穿所有层的技术
整个系列中最宝贵的不是数字，而是 质疑数字的瞬间。
| 遇到的问题 | 教训 |
|---|---|
| 输入处理速度达到 GPU 计算极限的 20 倍 | 与硬件极限进行对比。 原因是通过重复相同句子导致前缀缓存命中了 |
| “并发 1, 16”实际上是 3 倍，48 个请求 | 确认工具参数的具体作用。 使表述与实际请求数保持一致 |
| 数值重复出现的表格 | 对测量工具的分辨率保持怀疑 |
| 30 秒的终止宽限期混入了抢占时间 | 检查是否混入了非预期测量目标的时间段 |
只保留表头的 grep 导致看不到结果 |
不使用会掩盖结果的过滤器 |
| 以 root 身份进行的测试未能复现故障 | 使用要复现的条件（普通用户）进行测试 |
| 两个引擎同名选项的默认值不同 | 在比较前通过日志对齐设置 |
并将以下三点养成习惯： 每个请求使用不同的输入, 进行重复与分布测试（不对单次测量结果下定论）， 在数值旁记录环境与方法.
12. 4 周学习路径
如果是自学，建议遵循此顺序。每周的产出应当是 一张亲手测得的表格。
| 周 | 主题 | 实践内容 | 产出物 |
|---|---|---|---|
| 1 | GPU 与服务引擎 | 用 vLLM 部署一个小模型（1~2B），将不同大小和精度下的生成速度乘以权重字节数，并与带宽进行对比 | “速度 × 权重与带宽对比”表 |
| 2 | 负载与缓存 | 将并发从 1 提升至 64，测量吞吐量、TTFT p95、ITL p99，验证 KV 容量公式与拐点，测试开启和关闭前缀缓存 | 并发曲线与 KV 计算 |
| 3 | Kubernetes GPU 与调度 | 在临时集群中使用假扩展资源制造资源死锁，并用 Kueue 和 Volcano 解决；亲手编写控制器（如 kopf）来测量子资源删除恢复时间 | 死锁复现与解决、恢复时间 |
| 4 | 可观测性、故障与安全 | 读取 DCGM 指标并构建能区分 N/A 与 0 的仪表盘、设置 XID 告警规则、测量权重加解密速度 | 指标列表与告警规则草案 |
仅在临时环境（虚拟机中的 k3s、临时 Pod）中进行，测试结束后销毁。切勿在生产服务集群中首次尝试。
13. 现场与面试高频问题
- 如何估算 LLM token 生成速度的上限？ 内存带宽 ÷ 权重字节数。在四个模型上测得的带宽达到了 86%~98%。
- 服务器的并发请求上限是多少？ KV 缓存 Token 数 ÷ 每个请求的 Token 数。超过该值后吞吐量不会增加，且 TTFT 会激增 8 倍。
- 前缀缓存什么时候效果显著？ 公共前缀较长的服务。在 3,000 个 Token 的情况下，首 Token 延迟从 394ms 降至 28ms。
- 如何减少长输入打断其他请求的情况？ 减少分块预填充（Chunked Prefill）的块大小，并确认引擎的默认行为（是否采用混合分块）。
- GPU 任务停止了，但 GPU 却处于闲置状态。为什么？ 没有进行联合调度（Gang Scheduling），导致部分 Pod 获取了资源（死锁），或者通用资源（内存）不足导致处于 Pending 状态。
- 如何实现联合调度？ Kueue 通过工作负载单位进行批准，Volcano 通过 Pod 组的最小数量进行控制。
- GPU 共享方式有哪些？ 时间分片（无内存隔离）、MIG（硬件分片，需受支持的 GPU）、软件方式（拦截调用）。
- 容器无法启动。CUDA 镜像和驱动怎么处理？ 容器中的 CUDA 版本不能超过宿主机驱动的上限。
- 服务网格的延迟开销是多少？ 在此环境中，每个请求约有 2.2ms 的开销，其中加密约占 8%。
- 在服务多个 LoRA 适配器时需要注意什么？ 同时使用的适配器数量与槽位数量。如果槽位不足，吞吐量将减半。
- 对权重进行加密可以保护什么？ 存储泄露和篡改。无法防止运行时的内存泄露。
- 如果在 Operator 中漏掉了事件会发生什么？ 基于状态电平（Level-triggered）的调谐会重新读取当前状态进行匹配（由定时器或重新同步机制恢复）。
- 性能测试结果异常时首要做的事情是什么？ 与硬件极限进行对比。
14. 本指南未涵盖的内容
- 训练基础设施。 分布式训练（数据并行、张量并行、流水线并行）、检查点（Checkpoint）、数据加载器以及训练过程中的故障恢复，在本系列中均未进行测量（未实测）。
- 数据中心 GPU、NVLink·NVSwitch、InfiniBand 实机硬件，以及数百个节点规模的调度器吞吐量。
- 大模型（数十B及以上）与多 GPU 服务的量化数据。本文中的服务数据均基于 1.7B 的单个模型。
- 服务（Serving）之外的 ML 平台（特征存储、实验管理、流水线编排）。
参考：本指南所依据的文章
第 2 篇（混合 GPU 集群与网络）、第 3 篇（GPU Operator）、第 4 篇（LLM 推理与 vLLM）、第 5 篇（vLLM 与 SGLang）、第 6 篇（分布式推理）、第 7 篇（RDMA）、第 8 篇（存储与 KV 卸载）、第 9 篇（CRD 与 Operator）、第 10 篇（多租户调度）、第 11 篇（GPU 故障诊断）、第 13 篇（GPU 直通）、第 14 篇（vLLM 负载与 KV 缓存）、第 15 篇（LoRA 服务）、第 16 篇（权重保护）、第 17 篇（DCGM 指标）、第 18 篇（Cilium 指标）、第 21 篇（速度原理）。
确认日期
截至 2026-10-07。数据遵循各文章中的“确认的版本与日期”（vLLM 0.31.0、SGLang 0.5.21、Kueue 0.20.0、Volcano 1.15.3、LeaderWorkerSet 0.11.1 等）。