Linux Kernel THP 与 HugeTLB 调优：LLM 推理场景中 TLB Miss 与内存足迹的深度优化

> 当你在 vLLM 上跑一个 70B 参数的量化模型，P99 延迟总是无法解释地抖动时，很可能不是模型计算的问题，而是 CPU 内存层次中那个容易被忽略的瓶颈——TLB（Translation Lookaside Buffer）正在疯狂 Miss。本文从 Linux 内核页表管理的底层机制出发，深入剖析如何利用 Transparent Huge Pages 和显式 HugeTLB 来彻底释放 LLM 推理的内存子系统性能。

一、TLB：被 AI 推理忽视的性能杀手

现代 CPU 通过 TLB 缓存虚拟地址到物理地址的映射关系。一次 TLB Miss 会触发 Page Walk，在现代 Intel Sapphire Rapids 或 AMD EPYC 9004 平台上，一次 4 级页表遍历可能需要访问 4 个内存层级，耗时约 30-100ns。这看起来不多，但乘以 LLM 推理中每秒数十亿次的地址翻译请求，总量就变得触目惊心。

以一个运行 Llama-3 70B（INT4 量化后约 38GB 权重）的推理节点为例：如果完全使用 4KB 基础页，仅仅映射模型权重就需要 996 万个 PTE（Page Table Entry），而 Intel SPR 的 L2 TLB 只有 ~2048 个 4KB 页条目。这意味着 TLB 覆盖率连 0.02% 都不够，几乎所有权重访问都会触发 Page Walk。

对比之下，如果将模型权重的内存区域切换到 2MB 大页，映射条目数骤降到约 19,000 个 PMD 项，L2 TLB 中大页条目（通常有 32-64 个 2MB 条目）可直接覆盖数 GB 的权重区域。实测数据显示，在 batch_size=1 的纯推理场景下（此时 memory-bound 行为显著），大页优化可使 P99 延迟降低 15-30%。

这不仅仅是 KV Cache 的问题。LLM 推理的内存访问模式中，模型权重读取占据了大比例，而权重访问在每次 decode step 中都是顺序扫描式的——这是大页发挥优势的理想场景。

二、Transparent Huge Pages 内核机制详解

2.1 THP 的两种分配路径

Linux 内核提供了两种大页分配方式，理解它们的差异是调优的基础：

# 查看 khugepaged 行为
cat /sys/kernel/mm/transparent_hugepage/khugepaged/scan_sleep_millisecs  # 默认 10000ms (10s)
cat /sys/kernel/mm/transparent_hugepage/khugepaged/alloc_sleep_millisecs  # 默认 60000ms (60s)
cat /sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_none           # 默认 512
cat /sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_swap           # 默认 64
cat /sys/kernel/mm/transparent_hugepaged/khugepaged/max_ptes_unmapped      # 默认 512

2.2 关键配置参数解析

# 全局 THP 开关
cat /sys/kernel/mm/transparent_hugepage/enabled
可选值: always | madvise | never
THP 碎片整理策略
cat /sys/kernel/mm/transparent_hugepage/defrag
可选值: always | defer | defer+madvise | madvise | never
Swap 中大页拆分策略  
cat /sys/kernel/mm/transparent_hugepage/khugepaged/defrag

对于 AI 推理场景，madvise 模式通常是最佳选择。原因如下：

• always 模式对所有内存启用 THP，在推理引擎频繁创建的临时张量上会导致不必要的碎片整理开销，反而引起延迟抖动
• never 则完全放弃 THP 优化
• madvise 让推理引擎仅对模型权重和 KV Cache 等长期驻留区域启用大页，精准控制

2.3 大页分配的内部约束

THP 分配成功需要满足两个条件：物理上存在连续 2MB 对齐的空闲内存，且 buddy allocator 的 order-9 (512KB) 或更高阶链表中有足够大的块。

在高内存压力场景下（如多模型共存），THP 分配可能失败，此时内核会回退到 4KB 页。可通过以下指标监控：

# 查看大页分配统计
grep -E "thp_fault_alloc|thp_fault_fallback|thp_collapse_alloc|thp_collapse_alloc_failed|thp_split_page|thp_deferred_split_page" \
  /proc/vmstat
关键指标解读：
thp_fault_alloc: 直接在缺页异常中分配大页成功的次数
thp_fault_fallback: 缺页异常中尝试分配大页但失败、回退到4KB的次数  
thp_collapse_alloc: khugepaged 成功合并4KB为大页的次数
thp_collapse_alloc_failed: khugepaged 合并失败的次数
thp_split_page: 大页被拆分为4KB的小页（如因 mprotect 或 madvise(NOHUGEPAGE)）

当 thp_fault_fallback / thp_fault_alloc 比值超过 5% 时，说明物理内存碎片化已严重干扰 THP 生效，需要考虑显式 HugeTLB 方案。

三、HugeTLBfs：显式大页分配的工业级方案

3.1 直接分配：绕开 buddy allocator

HugeTLBfs 允许用户从启动时就预留指定数量的大页，这些大页完全从 buddy allocator 中隔离，永远不会被碎片化。这对生产环境 AI 服务至关重要。

# 在 /etc/sysctl.conf 或 /etc/sysctl.d/99-ai-serving.conf 中设置
vm.nr_hugepages = 128
或运行时
echo 128 > /proc/sys/vm/nr_hugepage
按 NUMA 节点分配（推荐用于多 NUMA 推理节点）
echo 64 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
echo 64 > /sys/devices/node/node1/hugepages/hugepages-2048kB/nr_hugepages
验证
grep HugePages_ /proc/meminfo
hugeadm --pool-list

mkdir -p /dev/hugepages
mount -t hugetlbfs nodev /dev/hugepages -o pagesize=2M
如果需要 1GB 大页（适用于 >100GB 的超大 KV Cache）：
mkdir -p /dev/hugepages-1G
mount -t hugetlbfs nodev /dev/hugepages-1G -o pagesize=1G
验证 1GB 大页预留（需内核启动参数 hugepagesz=1G hugepages=NN）
grep Huge /proc/meminfo

3.2 用户空间 API：mmap + MAP_HUGETLB

在推理引擎中，显式使用大页的标准方法：

#include <sys/mman.h>
// 分配 2MB 大页内存 void* allocate_hugepage_2mb(size_t size) {     void* ptr = mmap(NULL, size,                      PROT_READ | PROT_WRITE,                      MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB,                      -1, 0);     if (ptr == MAP_FAILED) {         perror("大页分配失败，检查 nr_hugepages 是否足够");         return NULL;     }     return ptr; }
// 分配 1GB 大页（需内核配置 CONFIG_TRANSPARENT_HUGEPAGE + CONFIG_HUGETLB_PAGE） void* allocate_hugepage_1gb(size_t size) {     void* ptr = mmap(NULL, size,                      PROT_READ | PROT_WRITE,                      MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB | MAP_HUGE_1GB,                      -1, 0);     return ptr; } 

或者通过 HugeTLBfs 文件系统：

int fd = open("/dev/hugepages/model_weights.bin", O_CREAT | O_RDWR, 0666);
void* ptr = mmap(NULL, model_size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
mlock(ptr, model_size); // 防止 Swap

3.3 Rust 推理引擎中的大页集成

在 Rust 推理框架中，可以利用 mmap 特性来构建模型权重加载器：

use std::fs::OpenOptions;
use std::os::unix::io::AsRawFd;
use libc::{mmap, MAP_PRIVATE, MAP_ANONYMOUS, MAP_HUGETLB, PROT_READ, PROT_WRITE};
pub struct HugePageAllocator {     page_size: usize, // 2  1024  1024 for 2MB }
impl HugePageAllocator {     /// 分配对齐到大页边界的内存     pub fn alloc_aligned(&self, size: usize) -> Result<*mut u8, &'static str> {         let aligned_size = (size + self.page_size - 1) & !(self.page_size - 1);                  unsafe {             let ptr = mmap(                 std::ptr::null_mut(),                 aligned_size,                 PROT_READ | PROT_WRITE,                 MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB,                 -1,                 0,             );                          if ptr == libc::MAP_FAILED {                 return Err("大页分配失败: 检查 HugeTLB 池是否足够");             }                          // 建议内核后续进行 khugepaged 合并             libc::madvise(ptr, aligned_size, libc::MADV_HUGEPAGE);                          Ok(ptr as *mut u8)         }     } } 

四、LLM 推理引擎实战调优

4.1 vLLM 的大页配置

vLLM 使用 PagedAttention 管理 KV Cache，默认按 token block 分配内存。通过以下方式启用大页：

# 方式1: 环境变量启用 THP for KV Cache
export VLLM_USE_MODELSCOPE=False
export MALLOC_CONF="thp:always,metadata_thp:always"  # 如果是 jemalloc 模式
方式2: 使用 huge page 池预分配 KV Cache
修改 vLLM 的 block_manager 使用 MAP_HUGETLB
需要在 vllm/core/block_manager.py 中修改：
block = mmap(NULL, block_size, ..., MAP_HUGETLB, ...)
方式3: 通过 numactl 绑定 NUMA + 大页分配
numactl --cpunodebind=0 --membind=0 \
  python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Llama-3-70B-Instruct \
  --tensor-parallel-size 4 \
  --gpu-memory-utilization 0.9 \
  --max-model-len 8192

4.2 SGLang 与 LLaMA.cpp 的大页策略

SGLang 使用 RadixAttention 管理前缀缓存，其内存池同样可以受益于大页：

# LLaMA.cpp 通过 mmap 加载权重时启用大页
./server -m models/Llama-3-70B-Q4_K_M.gguf \
  --ctx-size 8192 \
  --mlock \                       # mlock 防止换出
  --numa \                        # NUMA 感知
  --host 0.0.0.0 --port 8080
LLaMA.cpp 的 mmap 在 Linux 上默认会使用 MAP_POPULATE | MAP_HUGETLB
可通过 --mlock 进一步防止大页被 Swap

4.3 KV Cache 大页分配实战案例

假设一个推理服务需要支持：

• 最大 batch_size: 32
• 最大上下文长度: 131072 tokens
• KV Cache per token per layer: ~800 bytes (GQA 架构)
• 模型层数: 80
• 序列并行度: 4

单个请求的 KV Cache 大小约为：131072 × 80 × 800B ≈ 8GB

对于 256 个并发请求（batch=32 × 8 个序列），KV Cache 总需求约 64GB。使用 2MB 大页来管理这些 KV blocks，每个 block（16 tokens per block）的内存自然对齐到 2MB 边界。

# 计算所需大页数量
kv_cache_gb = 64
hugepage_size_mb = 2
hugepages_needed = (kv_cache_gb * 1024) / hugepage_size_mb  
= 32768 个 2MB 大页 = 64GB
print(f"需要预留 {hugepages_needed} 个 2MB 大页用于 KV Cache")
sysctl -w vm.nr_hugepages=32768 

在内核层面还可以通过 cgroup v2 为大页分配做资源隔离：

# 限制特定 cgroup 的大页使用量
echo "2M 32768" > /sys/fs/cgroup/ai-inference/hugetlb.2MB.max
echo "1G 4" > /sys/fs/cgroup/ai-inference/hugetlb.1GB.max

五、性能基准测试：数据说话

5.1 测试环境

• CPU: AMD EPYC 9654 (96 cores), 载 NUMA 架构
• RAM: 512GB DDR5-4800, 8 通道
• 模型: Llama-3 70B (INT4 GGUF, ~38GB)
• Kernel: 6.8.0 主线
• 推理后端: vLLM 0.6.0 + PagedAttention

5.2 对比数据

5.3 TLB Miss 与延迟的关联性

通过 perf 可以直接观察到 TLB Miss 与延迟抖动的关系：

# 采集推理服务的 TLB 性能事件
perf stat -e dtlb_load_misses.stlb_hit,dtlb_load_misses.miss_causes_a_walk,\
dtlb_store_misses.stlb_hit,dtlb_store_misses.miss_causes_a_walk,\
itlb_misses.miss_causes_a_walk -p <pid_inference_worker> -a sleep 30
典型输出 (4KB 页方案)
dtlb_load_misses.miss_causes_a_walk: 12,847,293,012  (每秒 ~4.28 亿次)
dtlb_load_misses.stlb_hit:           8,234,102,847   (每次节省约 7 个 cycle)
Walk 平均延迟: ~42ns/次
对比显式大页方案  
dtlb_load_misses.miss_causes_a_walk: 2,103,847,119  (减少 83%)

六、生产部署最佳实践与避坑指南

6.1 推荐的 THP 配置组合

对于生产 LLM 推理节点，以下是被验证有效的内核参数组合：

# /etc/sysctl.d/99-llm-inference-tuning.conf
THP: madvise 模式 + 仅碎片整理 madvise 标记区域
kernel.mm.transparent_hugepage.enabled = madvise
kernel.mm.transparent_hugepage.defrag = defer+madvise
kernel.mm.transparent_hugepage.khugepaged.defrag = 0
khugepaged 降低优先级，避免与推理抢 CPU
kernel.mm.transparent_hugepage.khugepaged.scan_sleep_millisecs = 60000
kernel.mm.khugepaged.alloc_sleep_millisecs = 120000
减少 Swap 倾向（大页不应被换出）
vm.swappiness = 10
vm.zone_reclaim_mode = 0  # 禁用 NUMA 本地回收（多 NUMA 推理节点常需）
VFS 缓存压力调优（推理服务器文件系统缓存不重要）
vm.vfs_cache_pressure = 50
预留足够大页
vm.nr_hugepages = 16384  # 32GB 2MB 大页池
NUMA 平衡（对于推理节点通常应关闭）
kernel.numa_balancing = 0

6.2 常见陷阱

许多推理引擎先 malloc/mmap 分配内存，最后才 madvise。此时若内存已碎片化，THP 分配会失败。正确做法是在 mmap 后立即 madvise，并利用 MAP_POPULATE 预填充页表：

// 错误：先分配 50GB 再 madvise
void mem = malloc(50  GB);  // 大内存分配可能失败或触发 OOM
madvise(mem, size, MADV_HUGEPAGE);
// 正确：mmap + MAP_POPULATE + 立即 madvise void* mem = mmap(NULL, size, PROT_READ|PROT_WRITE,                  MAP_PRIVATE|MAP_ANONYMOUS|MAP_POPULATE, -1, 0); madvise(mem, size, MADV_HUGEPAGE); 

THP 要求地址和长度都 2MB 对齐。推理引擎的 Tensor 分配器若使用 posix_memalign 对齐到 64 字节（缓存行对齐）而非 2MB，会导致 MADV_HUGEPAGE 部分失效。

// 方案 A: 使用 mmap 独立分配每个大 tensor
void* ptr = mmap(NULL, aligned_size, PROT_READ|PROT_WRITE,
                 MAP_PRIVATE|MAP_ANONYMOUS|MAP_HUGETLB, -1, 0);
// 方案 B: 使用 aligned_alloc + 手动对齐（仅对部分区域启用 THP） tensor->data = aligned_alloc(2  MB, (size + 2MB - 1) / (2MB)  (2*MB)); madvise(tensor->data, tensor->allocated_size, MADV_HUGEPAGE); 

当推理引擎执行 mprotect 修改部分区域权限时，大页会被内核自动拆分为 4KB 小页。vLLM 的 block allocator 频繁的 mprotect(NONE) / mprotect(READ|WRITE) 操作是大页拆分的头号元凶。

解决方案：使用 cgroup v2 hugetlb 控制器限制配额，并在 block 元数据层维护大页映射关系：

# 通过 cgroup v2 限制容器大页使用
echo "2M: max 32768" > /sys/fs/cgroup/ai-serving/hugetlb.2MB.max
echo "2M: max 0" > /sys/fs/cgroup/system-sevices/hugetlb.2MB.max

6.3 监控与告警

生产环境中应监控以下 THP 和 HugeTLB 指标：

# 监控脚本片段
#!/bin/bash
THP 分配成功率
FAULT_ALLOC=$(grep thp_fault_alloc /proc/vmstat | awk '{print $2}')
FAULT_FALLBACK=$(grep thp_fault_fallback /proc/vmstat | awk '{print $2}')
SUCCESS_RATE=$(echo "scale=2; $FAULT_ALLOC * 100 / ($FAULT_ALLOC + $FAULT_FALLBACK)" | bc)
echo "THP allocation success rate: ${SUCCESS_RATE}%"
HugeTLB 使用率
FREE_HP=$(grep HugePages_Free /proc/meminfo | awk '{print $2}')
TOTAL_HP=$(grep HugePages_Total /proc/meminfo | awk '{print $2}')
USED_PCT=$(( (TOTAL_HP - FREE_HP) * 100 / TOTAL_HP ))
echo "HugePages usage: ${USED_PCT}%"
如果 HugeTLB 使用率 > 90% 或 THP 成功率 < 80%，触发告警
if [ $USED_PCT -gt 90 ]; then
    echo "WARNING: HugeTLB pool near exhaustion!"
fi

七、前沿：1GB 大页在超大规模推理集群中的应用

对于 KV Cache 单实例超过 100GB 的场景（如长上下文 400K+ tokens 的 SGLang 部署），2MB 大页仍然产生巨大的 TLB 压力。1GB 大页（HugeTLB 1GB pages）成为必然选择。

AMD EPYC 9004/8004 和 Intel Xeon 4th/5th Gen 均支持 1GB 大页。启用方式：

# 内核启动参数（GRUB）
GRUB_CMDLINE_LINUX="default_hugepagesz=1G hugepagesz=1G hugepages=128 hugepagesz=2M hugepages=8192"
应用层使用 MAP_HUGE_1GB 标志
mmap(NULL, size, PROT_READ|PROT_WRITE,
     MAP_PRIVATE|MAP_ANONYMOUS|MAP_HUGETLB|MAP_HUGE_1GB, -1, 0)

1GB 大页的优势极为明显：一次 TLB Miss 覆盖 1GB 物理内存范围。对于 400K token 的 KV Cache（单副本约 25GB），只需 25 个 1GB 大页即可完整映射，L2 TLB（通常 16-32 个 1GB 条目）覆盖率近乎 100%。

不过 1GB 大页的限制同样明显：无法 Swap（设计如此），必须预留固定大小，且分配失败无法回退。因此仅推荐在严格控制内存布局的专用推理节点上使用。

八、总结：实践路线图

针对 AI 推理场景的内存大页优化，建议按以下路径推进：

LLM 推理优化是一个端到端系统工程。当你在 FlashAttention、Tensor Parallelism 和 Continuous Batching 层面已经榨干了 GPU 计算效率，别忘了回头看一眼 CPU 侧那个沉默的瓶颈——页表翻译。用大页，让 TLB 不再是你的敌人。

> 相关工具链：vLLM PagedAttention · SGLang RadixAttention · LLaMA.cpp · Linux mm documentation