3. CPU推理性能核心概念

在金融模型推理场景中，CPU 往往承担着低延迟请求、批量预处理、特征工程以及中小模型在线服务等任务。与 GPU 不同，CPU 的性能瓶颈通常不在峰值算力，而在“数据搬运效率”与“指令执行效率”的平衡。理解指令集、缓存层次、内存带宽、并行度、延迟与吞吐量这六个核心概念，是后续做性能剖析与调优的前提。

一、核心原理：CPU 推理性能的六个支点

指令集决定了 CPU 能以多宽的“车道”处理数据。金融推理中常见的矩阵乘、向量点积、激活函数，若能用上 AVX-512、AVX2 或 AMX 等 SIMD 指令，单周期可处理 8～64 个浮点元素。指令集还包含 FMA（融合乘加），它把乘法和加法合并为一条指令，既减少指令数又提升数值精度。

缓存层次是 CPU 性能的“隐形战场”。L1 通常 32～64KB、延迟约 4～5 周期；L2 约 256KB～2MB、延迟约 12～20 周期；L3 共享、可达数十 MB、延迟约 40～70 周期；而主存延迟高达 200～300 周期。金融模型权重若无法驻留缓存，推理速度会被内存访问拖垮。

内存带宽决定单位时间能从主存搬多少数据。CPU 内存带宽通常为 50～200GB/s，远低于 GPU 的 1～3TB/s。对于大模型推理，权重读取量巨大，带宽往往先于算力成为瓶颈。

并行度包含指令级并行（ILP）、数据级并行（SIMD）和线程级并行（多核/超线程）。金融推理中，批处理可提升数据级并行，多路请求可提升线程级并行，但并行度受限于缓存容量与内存带宽。

延迟与吞吐量是一对需要权衡的指标。延迟指单次请求从输入到输出的耗时，吞吐量指单位时间完成的请求数。在线风控、实时报价场景重延迟；离线批量评分、日终清算重吞吐量。二者常此消彼长：增大批处理提升吞吐量，却可能拉高单请求延迟。

二、方法流程：从指标到调优的闭环

性能优化不是盲目调参，而应遵循“度量—定位—假设—验证”的闭环。以下流程适用于金融模型 CPU 推理调优：

1. 建立基线：在固定硬件、固定输入下测量延迟 P50/P99 与吞吐量 QPS，记录 CPU 利用率、缓存命中率、内存带宽占用。
2. 定位瓶颈：用 perf stat 观察 IPC、缓存缺失率、分支预测失败率；用 perf top 找到热点函数。
3. 提出假设：若 L3 缺失率高，则怀疑权重未驻留缓存；若 IPC 低且内存带宽饱和，则怀疑带宽瓶颈。
4. 实施优化：调整线程数、批大小、数据布局、指令集编译选项，或引入量化降低权重体积。
5. 回归验证：重新测量，确认延迟与吞吐量是否改善，避免“优化一处、劣化另一处”。

# 示例：用 perf 观察推理进程的缓存与 IPC 指标
perf stat -e cycles,instructions,cache-references,cache-misses,\
LLC-loads,LLC-load-misses,mem-loads,mem-stores \
-p $(pgrep -f "finance_infer") sleep 10

# 输出关注点：
#   instructions per cycle (IPC)  < 1.0  → 可能受内存或分支拖累
#   LLC-load-misses 比例高        → 权重未驻留 L3
#   mem-loads 带宽接近上限        → 内存带宽瓶颈

三、案例/场景：信用评分模型的 CPU 推理调优

某消费金融公司部署了一个基于 XGBoost + 小型 MLP 的信用评分模型，单请求延迟要求 P99 小于 20ms。初始版本使用单线程、批大小 1，实测 P99 为 35ms，QPS 仅 120。分析发现：MLP 权重约 8MB，L3 为 16MB，但多线程竞争导致缓存抖动；同时每请求都重新分配内存，造成额外开销。

优化措施包括：将批大小调整为 8 以提升 SIMD 利用率；使用 OMP_NUM_THREADS=4 限制线程数，减少缓存争用；将权重预加载并做内存对齐；启用 -march=native 让编译器生成 AVX2/FMA 指令。优化后 P99 降至 14ms，QPS 提升至 480，且 CPU 利用率从 95% 降至 70%，说明瓶颈从算力转移到了更健康的带宽与缓存层面。

四、误区与复盘