这个主题不是按机制聚起来的，而是按同一块硅在加速系统里被同时当作三种互相扣减的东西用聚起来的。既有的部署类主题都以 GPU 或集群为组织轴，而这十份材料的共同点是：它们各自把主机 CPU 当作一等资源来处理，却对"CPU 应该多做还是少做"给出了互斥的答案。
第一重身份是配置面——一组在开机时就固定、运行时不可见、且按负载类别分化的固件旋钮。EPYC 9005 的调优指南暴露 44 个字段、25 张 workload 表，但真正承重的偏离只有约 30 格，集中在 SMT、L3-as-NUMA、NPS、TDP/PPT 与 APBDIS 五个旋钮上 [amd-epyc-9005-bios-tuning-guide]。这份文档同时提供了本主题唯一的 HPC-vs-AI 单一厂商内对照：HPC / Telco / EDA 一族是全书信息密度最高的（约 11 格承重偏离，且 EDA 是唯一动 xGMI 与 DF C-States 的配方），而 AI/ML 一列除 Determinism=Power + TDP/PPT=OPN Max 外与 RDBMS 完全同构 [amd-epyc-9005-bios-tuning-guide]。
第二重身份是瓶颈面——主机软件栈成为加速器的限速环节。生产集群日志（4.65M 条 salloc 记录、约 1,400 节点）显示 H100 节点的 CPU-to-GPU 配比 P25 仅 0.25，即 1 核服务 4 张卡 [2603.22774]；在这种配比下 tokenization 占 TTFT 高达 50%，调度广播的 dequeue() 从 12 ms 膨胀到 228 ms（19×，是同期 GPU decode 44 ms 的 5.2 倍）[2603.22774] [2603.22774]。更激进的证据来自共置干扰实验：pbzip2 打满主机核心后 vLLM 吞吐掉 3.8×、P99 TTFT 膨胀 139×，而大页只减少 16% dTLB miss 且无延迟改善，Intel CAT 完全消除 LLC 争用却只把 P99 ITL 改善不到 4% [2604.07609] [2604.07609]。
第三重身份是算力面——主动把 attention、KV 与内存层级交给主机核心和主机 DRAM。这条线的立论物理是同一条：GPU 与 CPU 的算力差约 100× 但内存带宽差仅约 3×，而 decode attention 是 memory-bandwidth-bound，所以应当 compute near data on CPU [2403.11421]。
Agent 场景是三重身份正面相撞的地方。 Agent 循环是短轮次、工具重、控制面重的，不是吞吐绑定的：工具执行最高占端到端延迟 88%，而 GPU 越强瓶颈移向 CPU 越快（Toolformer 的推理占比从 88% 降到 77%，SWE-Agent 的 Bash 执行从 38% 升到 65%）[2511.00739] [2511.00739]。于是同一批核心要同时承担配置面固定下来的资源上限、控制面的每轮开销、以及被主动派下来的计算——这三者在 agent 负载上第一次没有富余可以互相掩盖。
| category | paper count | representative |
|---|---|---|
| framework | 5 | 2403.11421（FastDecode，全卸载到远程 CPU）；2411.01142（NEO，本机部分卸载）；2506.03296（APEX，延迟同步）；2511.14510（CLO，反向的 CPU-light）；2604.07609（Blink，把 CPU 逐出数据面） |
| agent | 3 | 2511.00739（agent 执行的 CPU 侧刻画 + 微批调度）；2603.18897（PASTE，按工具调用模式驱动的 CPU-GPU 重叠）；2602.21477（Pancake，主机侧分层记忆与 ANN） |
| cluster | 1 | 2603.22774（多卡推理中 CPU 诱发的减速与集群配比普查） |
| hardware | 1 | amd-epyc-9005-bios-tuning-guide（固件配置面，唯一的厂商侧实体） |
framework 一栏内部本身就是分裂的：其中四篇（2403.11421 / 2411.01142 / 2506.03296）主张给 CPU 更多工作，而 2604.07609 主张把它彻底移出稳态回路 [2604.07609]，2511.14510 则在同一类 offloading 系统内部反过来把 CPU 参与度压到 4 个线程 [2511.14510]。这条内部分裂是本主题存在的主要理由，见 §6.2。
| 时间 | entity | 一行贡献 | 里程碑意义 |
|---|---|---|---|
| 2024-03 | 2403.11421 | S-Part/R-Part 分解，KVCache 完全移出 GPU，用多节点远程 CPU 的聚合带宽顶住单卡，达 vLLM 的 1.88–5.04× [2403.11421] | 算力面的范式定义者："CPU 内存带宽与 GPU 的差距远小于算力差距"成为该方向的公理 [2403.11421] |
| 2024-11 | 2411.01142 | 部分卸载到本机 CPU + 非对称流水，T4 上 7.5×、H100 上仅 14.3%，并用贪心回退保证不劣于 GPU-only [2411.01142] [2411.01142] | 转折点：把"需要一个 CPU 集群"降级为"用随卡附送的主机核心"，同时用 T4→H100 的收益衰减暴露了这条线的硬件依赖 |
| 2025-06 | 2506.03296 | 统一 batch + 跨迭代延迟同步取代批次切分，把 CPU 计算窗口从一次 GPU attention 拉长到整个迭代周期，对 NEO 最高 +72% [2506.03296] | 给出了这条线唯一的解析判据：Asymmetric Pipelining 需 $N_C \ge 13\%\,N_G$，实测 $<10\%$ [2506.03296] |
| 2025-11 | 2511.00739 | 首次从 CPU 侧系统刻画 agent 执行，给出 $r(BS)$ 分析框架与 $B_{cap} \approx 1\text{–}2\times$ 核数的微批上限 [2511.00739] | 转折点：瓶颈面第一次进入 agent 类目，并把结论表述为"不再是更多 GPU，而是 CPU-GPU 平衡" [2511.00739] |
| 2025-11 | 2511.14510 | 在 KVCache offloading 内部反向操作：head 粒度近似缓存 + GDRCopy 零拷贝 + GPU 轮询同步，4 个 CPU 线程即饱和 PCIe 4.0 [2511.14510] [2511.14510] | 反向端点：证明"用 CPU 存"不必等于"用 CPU 管"，把管理开销从解码延迟的 36.2% 压到可忽略 [2511.14510] |
| 2025-12 | amd-epyc-9005-bios-tuning-guide | v2.2 定稿：把功耗仲裁、NUMA 划分、fabric P-state 写成用户可见的选择，但零基准、零性能曲线 [amd-epyc-9005-bios-tuning-guide] | 配置面的唯一成文物；同时是本主题唯一一份没有任何第三方兑现层的资料 [amd-epyc-9005-bios-tuning-guide] |
| 2026-02 | 2602.21477 | 把 agent 记忆的 ANN 索引当作被管理资源：FSM 缓存 + 跨 agent 混合图 + GPU-CPU 动态协同，记忆操作占比从 82%+ 降到 3.2% [2602.21477] | 把算力面从 attention 扩展到主机侧数据结构，并第一次给出 CPU 插入缓冲与 GPU kernel launch 的显式交叉点 [2602.21477] |
| 2026-03 | 2603.18897 | 用工具调用的控制流模式驱动投机执行，把工具等待压进 LLM 思考窗口，端到端降 48.5%、tool stall 减 67% [2603.18897] [2603.18897] | agent 侧的重叠范式：CPU 侧被主动加载（0.02 core-sec / 每秒延迟收益）而不是被卸载 [2603.18897] |
| 2026-03 | 2603.22774 | 用 attacker-victim 设计与集群日志把"CPU 配比错了会怎样"量化成 1.36–5.40× TTFT [2603.22774] | 瓶颈面的定价者：把一个架构议题翻译成今天就能执行的运维动作 [2603.22774] |
| 2026-04 | 2604.07609 | DPU 前端 + GPU 常驻持久调度器，稳态完全不用主机 CPU；干扰下 TTFT 膨胀 0.92–1.14× 而基线 1.54–18.84× [2604.07609] | 激进端点：证明"减少 → 掩盖 → 消除"这条轨迹的终点可实现，代价是放弃前缀复用、抢占、KV 分层与超显存模型 [2604.07609] [2604.07609] |
2403.11421 → 2411.01142 → 2506.03296 是同一条被后继者反复纠错的谱系：NEO 批判 FastDecode 的对称流水浪费 GPU 内存且让 GPU 空等 CPU [2411.01142]，APEX 又证明 NEO 的批次切分把 GPU linear op 翻倍 [2506.03296]。而 2511.14510 与 2604.07609 是从这条谱系外部反向进入的两个否定。
三条互不相干的根，在"主机核心是稀缺且必须显式核算的资源"这一点上汇合，然后按"CPU 该多做还是少做"分叉。
三个结构性事实值得单列。其一，根 A 与根 B/C 的分野是可观测性而非精度：配置面的输入是字段与默认值表，因此可以在开机前决定，代价是它对 GPU 拓扑完全失明——25 张表里没有一格提到 GPU、P2P、ACS 或 GPUDirect [amd-epyc-9005-bios-tuning-guide]；根 B/C 的输入是运行时插桩，因此只能对已启动的系统求值。其二，根 C 内部的分叉点在 2403.11421：它同时长出"继续加大 CPU 承担"（被 2411.01142 与 2506.03296 接手）与"CPU 只做搬运不做管理"（2511.14510 独立走出）两支，后者的证据是同类系统里 CPU 缓存管理本身就占解码延迟 36.2%、cudaStreamSynchronize 还额外制造数十至数百微秒气泡 [2511.14510]。其三，汇合点是实质性的：$T \approx L\times(\max\{T_{l_0},T_{ca_1}\} + \max\{T_{l_1}+T_{ga_0},T_{ca_0}\})$ 的两个 max 项 [2411.01142]、$N_G/N_C < 2T_{glinear}/T_{gatt} + 3 + T_{gatt}/T_{glinear}$ 的判定边界 [2506.03296]、以及 $r(BS)=T(2^n)/T(2^{n-1})$ 的饱和度量 [2511.00739]，三者都是"把主机侧的一段时间与 GPU 侧的一段时间放进同一个不等式"，而不是笼统地说 CPU 慢。
(a) 配置面的功耗耦合决定了算力面能不能同时开。 指南的核心物理是一条封闭预算 $P_{\text{core}} + P_{\text{unc}} \le P_{\text{PPL}}$，因此降 xGMI 速率、强制窄链路、降内存频率这些 uncore 降级动作省下的每一瓦都会回流给 core boost [amd-epyc-9005-bios-tuning-guide] [amd-epyc-9005-bios-tuning-guide]。这条耦合与算力面的关系是直接的：把 attention 交给主机核心意味着 core 侧功耗上升，而 CLO 与 Pancake 的收益又都建立在 PCIe / 传输通道保持满速上（4 线程逼近 GDRCopy 峰值 21.21 GB/s [2511.14510]，异步 cluster 扩展的传输成本远超计算成本 [2602.21477]）。但没有任何一篇论文测过这条耦合。 指南自己一个性能数字都没有 [amd-epyc-9005-bios-tuning-guide]，而且 f_alg 依赖未公开的 per-part binning，"headroom varies from part to part" 之后不再展开 [amd-epyc-9005-bios-tuning-guide]。论文侧最接近的量是主机整机功耗（所有系统都在 1.1–1.4 kW，Blink 的能效结论本质是吞吐结论的重述 [2604.07609]）与 CPU 动态能耗占系统总动态能耗最高 61% [2511.00739]，两者都不分解到 core / uncore。一条未被检验的厂商断言本身就是本主题的一项发现，见 §7 OC3。
(b) 配置面把 NUMA 决定权交出去，运行时又把它拿回来。 指南明确 BIOS → UEFI → OS/hypervisor → application 四层覆盖，并点名 numad 会推翻 physcpubind/membind、numa_balancing 会搬走 task [amd-epyc-9005-bios-tuning-guide]；它也直接把"推理 server 的 NUMA-local KV cache"列为必须与这两者互斥的软件之一 [amd-epyc-9005-bios-tuning-guide]。这正是瓶颈面那一侧的隐藏前提：2603.22774 的 oversubscription 场景是在 (#GPUs+1) 核上同时跑 Rayon tokenizer 线程池、EngineCore 与 N 个 worker 进程 [2603.22774]，而它从未测过限制 tokenizer 并行度或做 pinning 这条零成本路径 [2603.22774]。也就是说配置面已经给出了工具，瓶颈面的论文没有把它当作对照组。
(c) 算力面的收益与 GPU 档次强反相关，而配置面对此毫无分化。 NEO 的实测是 T4 上 7.5×、A10G 上 6.4–26%、H100 上仅 14.3% [2411.01142]；APEX 只覆盖 T4 与 A10，并自陈按其 $S \approx \rho_c\rho_t$ 模型 GPU 越强收益越小 [2506.03296]。更尖锐的是判据本身的硬件依赖：支撑 $N_C < 10\%\,N_G$ 的那张图用的是 V100 + 两颗 2017 年入门级 EPYC 7251，而评测平台是 Xeon 6342/6130，因此"decode-only 下 Asymmetric Pipelining 无用"是硬件预算的产物而不是物理定律 [2506.03296]。整条计算重定位路线的证据集中在中端 GPU 上，而产业部署集中在高端 GPU 上 [2506.03296]。指南的 25 张表对这一维度完全沉默——AI/ML 列拿到的全部内容就是"把功耗放开" [amd-epyc-9005-bios-tuning-guide]。
(d) 同一份 slack 被 agent 侧的两个机制同时认领。 2511.00739 的结论是主机核心在 $BS=128$ 时已经 over-subscribe（$\rho_{CPU}$ 达 3.18），必须靠 $B_{cap}$ 把并发压回 0.89–1.13 [2511.00739]；PASTE 的投机执行则恰恰要消费剩余核心（每减少 1 秒延迟花 0.02 core-seconds）[2603.18897]。两者在 5–100 并发会话内共存，但在更高并发 × 多候选投机下 slack 假设可能不成立 [2603.18897]。这条张力是可解的而非原则性的：一个联合调度器在 authoritative 与 speculative 之间动态分核，就是把 $r(BS)$ 纳入投机预算的约束 [2603.18897] [2511.00739]。目前没人做。
(e) 同一个 kernel，两篇 agent 论文开出相反的硬件处方。 2511.00739 把 CPU 视为一等且配置不足的资源，并只把"用 GPU-based ANN 替代 CPU ENNS"列为假设性的算法方向 [2511.00739]；Pancake 直接把热点 ANN 簇搬上 GPU 拿到 >3× 检索加速 [2602.21477]。矛盾根源是数据驻留区间不同：前者的 88% 来自 115 GB C4 语料上的 FAISS flat search，这个规模根本放不进显存，因此 CPU 是被迫的 [2602.21477]；Pancake 的 GPU 收益只适用于 5–15 GB 的热点簇，其余仍在 CPU 上 [2602.21477]。两者在各自区间内都正确，分歧在于哪个区间是典型的。
(f) Python 是三条线共同的隐藏变量。 NEO 发现 GIL 使 CPU data plane kernel 不能与 GPU control plane 的 kernel launching 并行，被迫把 Triton 换成 CUDA C++ [2411.01142]；APEX 为此专门用 gil_scoped_release 加双线程架构，并且需要 ≥8× 的 CPU:GPU 请求比才能摊薄线程开销 [2506.03296]；2511.00739 的 CPU 并行化饱和结论同样部分归因于 GIL，其自身附录也测到多线程比多进程慢 1.8× [2511.00739]。Blink 从相反方向给出了同一变量的量级：BlueField-3 的 ARM A78 主频低于 Xeon，其 SIMD tokenizer 却比 HuggingFace 快 8–19.7×，这个差距揭示的是 Python/HuggingFace 路径开销而非硬件差距 [2604.07609]。如果工具与数据面改用原生实现，$r(128)$ 可能远大于 1，微批调度的价值随之下降 [2511.00739]。也就是说本主题相当一部分"CPU 慢"的证据，测的是运行时生态而不是硅。
C1 — 主机核心是被系统性欠配的，而不是被用错的。 生产集群 H100 节点 P25 配比 0.25，科研集群约 60% 任务配比 < 8 [2603.22774]；Blink 记录核心 pinning 会吃掉全部可用核心（6 核/GPU × 8 GPU = 48 核）[2604.07609]；APEX 的整个生效窗口要求并发高到 CPU:GPU ≥ 8:1 [2506.03296]；配置面则连"AI/ML 该配多少核"这个问题都没提出 [amd-epyc-9005-bios-tuning-guide]。
C2 — 加速器越强，主机侧占比越高。 GPU 升级后 Toolformer 的推理占比从 88% 降到 77%、SWE-Agent 的 Bash 执行从 38% 升到 65% [2511.00739]；MoE 模型因每 token 只激活一小部分参数、单步 GPU 时间短而编排成本不变，Blink 的相对收益被放大到 P99 TTFT 3.45×、吞吐 +37% [2604.07609]；反过来算力面的收益随 GPU 变强而衰减 [2411.01142]。同一个趋势同时抬高瓶颈面的价值、压低算力面的价值。
C3 — 主机侧的成本项在所有既有性能模型里都缺席，且量级与被建模项相当。 控制面 dequeue 的 228 ms 与 GPU decode 的 44 ms 同量级甚至更大 [2603.22774]；Blink 自陈缺少 $T_{\text{TTFT}}$ 与 $T_{\text{TPOT}}$ 的分解式，因此无法判断在其他硬件上 graph cache 与 120-launch 窗口是否仍是正确设计点 [2604.07609]；FastDecode 的性能模型只给框架不给完整推导 [2403.11421]；Pancake 完全没有 recall、遍历成本或缓冲区陈旧度的界 [2602.21477]。
C4 — 静态阈值是这条线上普遍的、未做敏感性分析的软肋。 $B_{cap} \approx 1\text{–}2\times$ 核数与 $E_{cap,shared}=32$ 是经验值 [2511.00739]；APEX 的 8× 请求比阈值只由 "empirical evaluation" 支撑 [2506.03296]；Pancake 的 $B_{insert}=128$ 与 $\alpha_{et}\in[0.6,0.8]$ 同样无消融，且整个 Tier-3 论证建立在单一平台测出的 256–512 交叉点上 [2602.21477]；CLO 的 $\hat{s}_i$、$D_i$、$N_{\text{persist}}$ 全部来自离线 profiling，在线负载漂移后需要重测 [2511.14510]；而配置面本身就是一整套没有测量桥梁的静态取值 [amd-epyc-9005-bios-tuning-guide]。
D1 — 该把 CPU 逐出数据面，还是该往上压更多工作？这是本主题的中轴，而且是一条真冲突。
三个位置及其成立条件：
| 位置 | 代表 | 成立条件（由各自证据界定） | 不成立时会怎样 |
|---|---|---|---|
| 逐出：CPU 只做 provisioning，稳态由 DPU + GPU 自治 | 2604.07609 | 主机被共置负载污染，且模型与 KV 能全驻显存 [2604.07609]；此时基线掉到 28–64% 吞吐而它保持 99–100% [2604.07609] | 独占机器下机制级收益只有 1.31–3.45×，落在同类结构性工作的量级序列低端 [2604.07609]；超显存模型直接不支持 |
| 压更多：attention/KV 主动搬到主机核心与主机 DRAM | 2403.11421 / 2411.01142 / 2506.03296 | 显存是绑定约束、GPU 相对弱、输出足够长。收益与 CPU 内存带宽近似成正比（g5.2xl 12.2% → g5.16xl 79.3%，带宽翻倍则收益翻倍）[2411.01142] | 短输出时开销大于收益、可能劣于基线 [2411.01142]；短序列下多加 CPU 节点反而更慢（8 sockets 低于 4 sockets）[2403.11421] |
| 只搬不管：用主机 DRAM 存，但把管理与同步都放回 GPU | 2511.14510 | 管理开销本身已经是主要成本项（同类系统 26.9–36.2%），且 PCIe 是稀缺资源 [2511.14510] | PCIe 5.0 / NVLink 或 CXL 会直接改变 prefetch 与常驻的平衡点 [2511.14510] |
这不是"各说各话"。 Blink 与 FastDecode 对 CPU 的定位互斥，两者的部署假设也不同（前者优化共置环境下的尾延迟与能效，后者是无 SLO 讨论的离线式吞吐优化，延迟为基线 3.5× 且需要独占多节点 CPU + InfiniBand）[2604.07609]。但这个对立产生了一个可检验的推论：把 attention 计算与全部 KVCache 带宽都放在 CPU 上的系统，在 CPU 共置下应当是最脆弱的——Blink 测到的 TLB invalidation → page walk 进 DRAM → LLC 污染放大链条会直接打在 R-Worker 的有效带宽上。没有任何一篇论文测过这个组合 [2604.07609]。同样的空白从算力面一侧也被指出：NEO 假设 CPU 资源完全可用于 attention offloading，但云环境里同一批核心还在跑 batch gathering、tokenization 与调度 [2411.01142]。这条分歧目前不可判定，因为没人在同一系统上同时扫共置干扰强度与卸载比例。
D2 — 主机侧的减速到底是配给问题还是架构问题？ 2603.22774 的可操作结论是配给：+16 vCPU ≈ +1.5% 实例成本换 1.36–5.40× TTFT [2603.22774]。Blink 的立场是配给不够：在核心 pinning、大页、LLC 分区全部试过之后，主机编排开销仍然膨胀，因此根因是架构而非资源争用 [2604.07609]。两者的证据都有缺口。 2603.22774 的最少 CPU 基线定在 (#GPUs+1) 核，低于框架自陈的最小并发进程数，多个场景直接 200 s 超时，因此 5.40× 的上端其实是"病态状态 vs 正常运行"而非 CPU scaling 曲线——真正的 scaling 很平，8→16 核仅 12%、16→32 核仅 8% [2603.22774]；而且这条杠杆在固定形态的云实例上不可直接兑现 [2603.22774]。反过来 Blink 的隔离证明只覆盖主机侧干扰：DPU 是一台没有任何共置负载的独立机器 [2604.07609]。可判定的中间地带是存在的：让主机参与度随实测干扰水平在线伸缩，用硬件计数器判定主机是否可信 [2604.07609]，目前无人探索。
D3 — 结构性论断有没有被自己的数据支持。 2603.22774 最强的那条论断（广播竞争 ∝ TP degree，因此加核心治不好）恰恰是唯一未被自身数据支持的：19× dequeue 膨胀只在 TP=4 单点测得，而端到端加速比在 8 GPU 上系统性低于 4 GPU，8 个 case 无一例外 [2603.22774]。对照 2506.03296：它把同类判断写成一条可代入的不等式并做了代数验证 [2506.03296]，但那条不等式的常数又来自最不利的 CPU [2506.03296]。本主题里没有一条"结构性"论断同时具备形式化与跨硬件验证。
十个实体里九篇是论文、一篇是厂商配置手册，两类证据不能按同一标准读。指南零基准、零图表、零性能曲线，全文唯一带真实数字的输出是一段 numactl -H 采样，而它自身不自洽（四个节点容量比约 1:2:3:1，与 NPS4 的对称象限交织直接矛盾）[amd-epyc-9005-bios-tuning-guide]。把它的可形式化部分逐条验算，六项里两项直接失败、两项存疑：NPS 通道数不守恒，Windows CPU group 规则的不等号方向写反 [amd-epyc-9005-bios-tuning-guide]。但这不意味着可以丢掉它。 它真正不可替代的是字段之间的耦合网络——x2APIC 要求 IOMMU 开启、SEV 关后再开需 power cycle、APBDIS 覆盖 DfPstate 这类约束无法从白皮书推出，也不会被基准论文测出 [amd-epyc-9005-bios-tuning-guide]。
论文侧的不对称是另一种形状：基线被选择性削弱。Blink 为"受控对比"关掉了全部基线的 chunked prefill、prefix caching 与 CPU offloading，而它选的负载本身高度可缓存 [2604.07609]；Pancake 的 4.29× 是对功能性记忆库测的，对真正的向量数据库只剩 1.9–4.2× [2602.21477]；APEX 从未与本簇内更强的竞争解法做对照 [2506.03296]；CLO 用 RetroInfer 当精度天花板，而后者在部分配置上反超全注意力 [2511.14510]。读法：厂商文档的问题是没有数字，论文的问题是数字的分母是自选的。
为什么难。 这不是"没人做"，而是配置面的粒度是每次开机一份，而两类负载对同一个字段的要求方向相反。指南给 HPC / EDA / NIC 关 SMT，理由是"neutral to negative performance impacts on some workloads, especially HPC"，并把 NPS4（每象限 3 通道）推荐给 HPC 与高并行负载 [amd-epyc-9005-bios-tuning-guide] [amd-epyc-9005-bios-tuning-guide]。agent 侧的约束是另一个方向：吞吐饱和点由核心数决定，$B_{cap} \approx 1\text{–}2\times$ 核数，超过就 over-subscribe [2511.00739]；而 tokenizer 的 Rayon 线程池默认会 spawn 与物理核心数相当的线程 [2603.22774]。关 SMT 把逻辑核腰斩，直接压低这两个上限；细化 NPS 又会同时改变节点计数与交织粒度（后者只由 NPS 决定，与 L3-as-NUMA 正交）[amd-epyc-9005-bios-tuning-guide]。没有任何一篇论文在扫过 SMT 或 NPS 的前提下测过 agent 负载——2603.22774 的全部实验都在 SMT 关闭下进行，且未覆盖高核心数 EPYC [2603.22774]。
需要哪些类目协作。 hardware（暴露分区拓扑）+ framework（把核心数与 NUMA 域纳入调度器输入）+ agent。指南本身给出了一条现成的先验：34 个字段在全部 19 个 workload 列里恒为 Default，承重偏离只落在 10 个旋钮上，把搜索空间收缩到这 10 维后一次贝叶斯优化在可接受机时内可完成 [amd-epyc-9005-bios-tuning-guide]。难度视界：1–2 年——工具全部现成，缺的是有人把厂商指南当搜索先验用。
为什么难。 算力面的每一个机制都需要一个足够长的窗口才能把 CPU 侧时间藏进去，而 agent 轮次结构上不提供这个窗口。APEX 的收益分三段：短输出（50–200 token）对 NEO 仅 +5%，中等（200–500）+17%–31%，长输出（>500）才达 +37% 并进入平台期 [2506.03296]；NEO 在短输出时可能略差于基线，因为尝试卸载的开销超过收益 [2411.01142]，而这一点在充满短工具调用响应的 agent 负载上会累积成显著开销 [2411.01142]。FastDecode 更极端：它完全不处理 prefill [2403.11421]，而 agent 循环恰恰是反复重新 prefill 的。同一侧的 CLO 也承认自己的时间窗口正在被 PCIe 5.0/CXL 与 HBM 容量增长两侧挤压 [2511.14510]。
已有的部分尝试为何不够。 agent 侧现有的两个机制都绕开了卸载而选择重叠：COMB 用微批 + 重叠区间构建 P50-P90 前沿 [2511.00739]，PASTE 用工具调用模式做投机以把工具工作提前到思考窗口 [2603.18897]。两者都不改变每轮的绝对计算量，因此不解决"CPU 到底该分担多少 attention"的问题。可迁移的部分是有的：把跨迭代延迟同步的深度从 1 推广到 $k$，CPU 窗口变成 $k\cdot T_{iter}$、内存开销随 $k$ 线性增长，这条 trade-off 曲线目前完全空白 [2506.03296]；而在 prefill-decode 解耦后的 decode 池内部做卸载（那里按构造 $\rho_t = 1$）也没人做过 [2506.03296]。难度视界：2–3 年，主要障碍是 agent 侧论文与卸载侧论文用的负载定义不通约。
为什么难。 配置面把功耗写成三个用户可设参数（TDP、PPT、Determinism），但真正决定收益的三个量都不可见：该颗硅的 bin 质量、算法允许的最大频率、以及 uncore 各子系统在给定负载下的实际功耗占比 [amd-epyc-9005-bios-tuning-guide]。这使"降 xGMI 换 core boost"成为一条无法从文档推算、只能在自己机群上重建的曲线。论文侧没有人补这一层：本主题九篇论文里报告能耗的只有两篇，且都只到整机或系统级粒度 [2604.07609] [2511.00739]。
为什么这条断言的真伪很重要。 如果它在 GPU 主机上成立，那么算力面（core 侧吃满）与瓶颈面（NIC 中断与 host-to-device 供数吃跨 socket 带宽）在功耗预算上是直接互斥的；如果不成立，配置面里最有分量的那条因果链就要作废。已有的怀疑是明确的：在 GPU 服务器里 CPU core 频率通常不是瓶颈，EDA 那套 xGMI 四件套照搬过去收益方向可能整体反号，而指南没有任何一句限定这套推理的适用范围 [amd-epyc-9005-bios-tuning-guide]。
需要哪些类目协作。 hardware（分解 core / uncore 功耗）+ framework（把 DVFS 与调度阶段对齐）+ cluster（机架级预算）。最直接的一步是把微批调度与 CPU DVFS 结合——GPU 阶段降频、CPU 阶段全速 [2511.00739]；CPU 与 GPU 功耗预算的跨器件联合分配则整个空白 [amd-epyc-9005-bios-tuning-guide]。难度视界：3–5 年，因为它要求的是厂商暴露 per-part 功耗-频率曲线，而这是一条商业决策而非技术决策。
为什么难。 判断一个瓶颈是物理的还是实现遗留的，没有系统化方法，而本主题的多条结论恰好卡在这条界线上。GIL 使 CPU 数据面与 GPU 控制面无法并行，NEO 因此把 Triton 换成 CUDA C++ [2411.01142]；APEX 需要 ≥8× 请求比才能摊薄 Python 线程开销 [2506.03296]；而同一个 tokenizer 换成原生 SIMD 实现后，在更低主频的 ARM 核上比 HuggingFace 快 8–19.7× [2604.07609]。若工具生态整体迁向原生并行，$r(BS)$ 可能远大于 1，微批调度的前提消失 [2511.00739]；88% 这个数字本身也依赖 worst-case 的 FAISS flat search 配置，生产环境常用 IVF/HNSW 或 GPU-FAISS [2511.00739]。
已有的部分尝试为何不够。 唯一被反复提到的零成本对照——限制 tokenizer 并行度、pin engine 进程——从未被任何一篇做成对照组 [2603.22774]；把 tokenization 卸载到可编程网络数据面或 GPU 的三条既有路线也从未与"加核心"做过成本对照 [2603.22774]。难度视界：不收敛——这是随框架代际周期性复发的问题，每一代运行时都会重新制造一批这样的开销，也重新制造一批为它们建模的工作。
为什么难。 本主题几乎每个系统都有一个"在哪一侧算更划算"的交叉点，而每个交叉点都只在一台机器上测过。Pancake 的 $B_{insert}=128$ 被刻意设在 256–512 vectors/cluster 这个 GPU 优势交叉点以下，理由是那里 GPU 延迟被 kernel launch 而非计算主导 [2602.21477]；但同一批证据也显示这类交叉点随 GPU 世代剧烈移动 [2602.21477]。CLO 的全部设计假设 PCIe 4.0 带宽稀缺，而 PCIe 5.0 或 CXL 会改变 prefetch 与常驻缓存的平衡点 [2511.14510]，其评测平台（48 GB HBM + PCIe 4.0）也不是生产主流 [2511.14510]。
已有的部分尝试为何不够。 $r(BS)$ 是目前唯一一个被明确设计成"在你自己的机器上重测"的度量 [2511.00739]，把它移植到 Pancake 的交叉点参数上就能消掉那条攻击 [2602.21477]。但 $r(BS)$ 本身是 workload-specific 的经验值，它把重测成本显式化了，没有降低它。难度视界：1–2 年——这是本主题里最接近可解的一条，因为需要的只是把自校准接口标准化，而不是新的建模能力。
总体判定：瓶颈面已可生产采用，配置面已生产但无法验证，算力面仍是 research-frontier 且窗口在收窄。
证据一：三重身份的采纳成本差三个数量级，而与价值密度不成正比。 最低一端是改一个配比参数——+16 vCPU 换 1.36–5.40× TTFT，无代码改动，且其诊断对象是已被广泛部署的生产代码路径 [2603.22774] [2603.22774]；但这条杠杆只在裸机/Slurm 与自建集群上真正可用 [2603.22774]。中间一端是 agent 侧的调度改造，COMB 与 MAS 可直接集成进现有调度器层，不需要改 GPU kernel [2511.00739]，PASTE 是 ~12K 行的 sidecar、约 250 MB 内存加 1–3 核、对已有运行时零侵入 [2603.18897]。最高一端是换掉整个后端并采购 BlueField-3 加 200 Gbps 链路，同时接受功能面大幅退化 [2604.07609]。
证据二：算力面这条线的开源记录是本主题最弱的一档。 FastDecode 与 APEX 均未公开代码 [2506.03296]，NEO 承诺开源但未给 URL [2411.01142]，CLO 的 3417 行 CUDA/C++ 加 1555 行 Python 未开源 [2511.14510]，Blink 无公开仓库 [2604.07609]，Pancake 亦然 [2602.21477]。这条线的核心壁垒——跨迭代状态一致性、GIL 绕过、CUDA event/stream 编排——恰恰是最需要开源才能被信任和复用的那类工程 [2506.03296]。
证据三：配置面的问题不是不成熟，是不可证伪。 修订史从 2024-06 的 NDA 版走到 v2.2，中间三次改的都是默认值本身，18 个月的持续修订说明它确实在被 OEM 与部署团队使用，修订是被现场问题驱动的 [amd-epyc-9005-bios-tuning-guide]。但 Chapter 5 的四条命令只能验证设置是否生效，不能验证设置是否正确 [amd-epyc-9005-bios-tuning-guide]，而 GPU 侧至今没有等价的可交付抽象——用户只能在两个固定功耗点的 SKU 之间选 [amd-epyc-9005-bios-tuning-guide]。
趋势方向：瓶颈面加速，算力面减速，配置面停滞。 瓶颈面在 12 个月内从 cluster 类目扩散到 agent 与 framework 三个类目，并且各自占据了"CPU 参与度"这条轴上互不重叠的位置。算力面的收益与 GPU 显存和带宽的增长严格反相关 [2411.01142]，而其判据的常数又来自最不利的硬件 [2506.03296]——这两条同时收窄它的适用区间。结论：判断一篇新的主机侧工作是否有增量，最有效的单一问题是"它把主机核心数、主机带宽、共置干扰这三个量中的哪几个写进了模型"；目前没有一篇写全了三个。
| 邻接主题 | 边界在哪里模糊 | 处理建议 |
|---|---|---|
| 集群部署 / 容量规划 | 2603.22774 的对象是集群配比，方法是端到端 attacker-victim 实验 [2603.22774]；任何部署主题都会主张这篇 | 双挂但分工：部署主题取其配比结论与成本核算，本主题取其"主机控制面是每轮热路径"的机理 |
| KV cache 管理 / 长上下文 | 2511.14510 与 2506.03296 的直接对象都是 KV 的存放与搬运 [2511.14510] | 保持双挂。若再进来 2–3 篇 KV 分层工作而它们不触及主机侧管理开销，应把那一支留给 KV 主题，本主题只保留 CPU 参与度这一侧 |
| Agent serving 调度 | 2511.00739 与 2603.18897 的调度机制本身属于 agent serving，本主题只取其 CPU 资源核算的一面 [2511.00739] | 边界建议按被管理的资源划：管队列与准入的归 agent serving，管核心与主机带宽的归本主题 |
| 持久化执行 / device-resident 控制回路 | 2604.07609 的 GPU 常驻持久调度器与 120-launch 窗口恢复可被任何引擎单独吸收，不需要 DPU [2604.07609] | 双挂：持久化执行主题取其 device 侧机制，本主题取其"主机干扰免疫"这一评测轴 |
| Agent 记忆系统 | 2602.21477 的三层结构里只有 Tier-3 属于本主题，前两层是索引与图结构 [2602.21477] | 只取 Tier-3。若 agent 记忆方向再积累 2 篇，应把索引侧完整让给记忆主题 |
两处刻意留白。 其一，本主题不覆盖 GPU 侧的功耗与分区演化——tag_filter 里的 numa / NUMA / power-management / infinity-fabric 足够宽，但主机 NPS 与设备侧 NPS 的联合分区目前完全无人研究，等那一支进来时应在 §4 的根 A 之外新增一条根，而不是改写既有结论 [amd-epyc-9005-bios-tuning-guide]。其二，tag_filter 刻意排除了 scheduling 与 serving 这类通用标签——本主题的收录判据是"主机 CPU 本身是被优化或被核算的对象"，而不是"这篇论文里有 CPU 参与"；否则整个 serving 文献都会落进来。合并或扩容时唯一需要改写的是 §2 的分布表与 §6.2 的三位置表。
| Entity | Categories | Role in topic | Key contribution |
|---|---|---|---|
| [amd-epyc-9005-bios-tuning-guide] · [amd-epyc-9005-bios-tuning-guide] | hardware | 配置面的唯一成文物 | 44 字段 × 19 具名 workload、约 30 格承重偏离；封闭 package power 预算与 NUMA 双轴解耦；本主题唯一无第三方兑现层的资料，其可形式化部分六项检查里两项失败 |
| [2603.22774] · [2603.22774] | cluster | 瓶颈面的诊断与定价者 | 集群配比普查（H100 P25=0.25）+ attacker-victim 量化（1.36–5.40× TTFT）；tokenization 占 TTFT 50%、控制面 dequeue 19× 膨胀 |
| [2604.07609] · [2604.07609] | framework | 轴的激进端点 | DPU + GPU 常驻调度器实现稳态 CPU-free；给出"标准隔离手段全部失效"的系统性排除；新增"共置干扰免疫"这一评测轴 |
| [2403.11421] · [2403.11421] | framework | 算力面的范式定义者 | S-Part/R-Part 分解与 compute-near-data 公理；代价是延迟 3.5×、无 prefill、需要独占 CPU 集群与 InfiniBand |
| [2411.01142] · [2411.01142] | framework | 算力面的落地化 | 本机部分卸载 + 非对称流水 + 贪心回退；证明绑定约束是 CPU 内存带宽而非核数（带宽翻倍则收益翻倍） |
| [2506.03296] · [2506.03296] | framework | 算力面的唯一解析判据 | 跨迭代延迟同步把 CPU 窗口拉长到整个迭代；Inequality (6) 给出 $N_C \ge 13\%\,N_G$ 的成立条件，但常数取自最不利的 CPU |
| [2511.14510] · [2511.14510] | framework | 算力面内部的反向端点 | 证明"用 CPU 存"不必等于"用 CPU 管"：head 粒度近似缓存 + 零拷贝 + GPU 轮询同步，4 线程饱和 PCIe 4.0 |
| [2511.00739] · [2511.00739] | agent | agent regime 的瓶颈刻画 | 工具执行占端到端 88%、GPU 越强瓶颈移向 CPU 越快；$r(BS)$ 是本主题唯一显式为"在你自己机器上重测"设计的度量 |
| [2603.18897] · [2603.18897] | agent | agent regime 的重叠机制 | 用工具调用模式驱动投机执行，tool stall 减 67%；把主机核心当作被主动消费的 slack，与微批调度争同一份资源 |
| [2602.21477] · [2602.21477] | agent | 算力面扩展到主机数据结构 | 主机 DRAM 插入缓冲 + 热点簇上 GPU；给出 CPU 缓冲搜索与 GPU kernel launch 的显式交叉点，并与 CPU 侧调度处方正面相反 |
按 §6 的分歧轴再钻一层：