HotPin：用控制理论思维突破 MoE 模型的推理内存墙

大模型推理的内存需求正在走向一个矛盾：MoE 模型的参数量动辄数百亿甚至上千亿，但消费级硬件的 RAM 上限在过去五年几乎没有质变——一张显卡 24GB，一台笔记本电脑 32GB，已是多数工程师的日常。

2026 年 7 月，一位机械工程背景的开发者（HN: LozzKappa）用约 50 行 C++ 代码，以一套来自控制理论的直觉，将 gpt-oss:120b MoE 模型的内存占用从 58.5GB 压到了 19.1GB，输出与全量加载完全一致（SHA-256 验证）。这项技术被命名为 HotPin。

本文将从工程实现的角度，拆解 HotPin 的核心原理、边界条件与适用场景。

一、MoE 推理的内存墙

首先需要理解为什么 MoE 模型推理如此消耗内存。以 gpt-oss:120b 为例，这是一个 MoE 架构，总参数量 120B，但每次前向传播只激活其中一部分参数（约 12B）。

传统的理解：MoE 只需将激活的 expert 加载到内存中即可，未激活的部分可以留在磁盘上。

实际的困境：模型权重文件的大小不仅取决于参数量，还取决于数据精度和存储格式。gpt-oss:120b 在 fp16 下的权重文件约 58.5GB。即使使用 4-bit 量化，也需要约 15GB。对于一块 24GB 的消费级显卡来说，由于 KV cache 和其他运行时开销，实际上留给权重的空间不足 20GB——所以即便是量化版本，在单卡上运行 120B 模型也非常吃力。

标准方案是 model sharding（跨多 GPU 分片）或 offloading（将权重按需从 CPU RAM 拷贝到 GPU）。但这两种方法要么需要额外的硬件，要么受限于 PCIe 带宽。

HotPin 的思路完全不同：它不尝试加速模型，而是通过操作系统原生的内存管理机制，精确地只保留计算需要的权重在物理 RAM 中。

二、HotPin 的核心原理

HotPin 基于两个关键观察：

1. MoE 的 expert 使用率是高度倾斜的：在任意输入上，路由网络通常只会激活 top-2 或 top-3 的 expert。但不同的输入可能激活不同的 expert 子集。通过预先 profiling 一批代表性输入，可以确定哪些 expert 被最频繁地调用（"热 expert"）。
2. 操作系统原生的 mmap + mlock 可以精确控制页级驻留：mmap 将文件映射到虚拟地址空间，只有被访问的页面才会触发缺页中断并加载到物理内存。mlock 可以将特定页面"钉"在物理 RAM 中防止被换出。

算法流程

HotPin 的推理流程分为三个阶段：

阶段 1：Profiling（离线）

# 伪代码：HotPin 的 expert 频率分析
expert_hits = defaultdict(int)
for sample in profiling_dataset:
    for layer in model.layers:
        routing_weights = layer.router(sample)
        selected_experts = top_k(routing_weights, k=2)
        for expert_id in selected_experts:
            expert_hits[(layer_idx, expert_id)] += 1

# 按热度排序
hot_experts = sorted(expert_hits.items(), key=lambda x: -x[1])
# 保留最热的 X% expert，直到占满可用内存预算
# 剩余 expert 的页面保持在 mmap 状态，访问时自动缺页加载

阶段 2：mmap 映射（启动时）

将整个模型权重文件通过 mmap(fd, size, PROT_READ, MAP_SHARED, ...) 映射到虚拟地址空间。此时不消耗物理 RAM——只有虚拟地址空间的保留。

阶段 3：mlock 热 expert（启动时）

对于 profiling 阶段标记为"热"的 expert，通过 mlock(page_addr, page_size) 将其页面强制锁定到物理 RAM 中。关键是计算准确的页面偏移——HotPin 直接操作 mmap 返回的指针，通过 llama.cpp 的 tensor 元数据计算出每个 expert 对应权重在 mmap 文件中的精确字节范围，然后对齐到页面边界执行 mlock。

性能数据

模型	磁盘大小	标准加载所需 RAM	HotPin 后 RAM	节省比例	推理速度（CPU only）
gpt-oss:120b	58.5 GB	58.5 GB	19.1 GB	67%	3.84 tok/s
qwen3:30b-a3b	21.6 GB	21.6 GB (min)	10.4 GB	42%	6.12 tok/s
deepseek-v3:671b (评估中)	404 GB	404 GB	~130 GB (预估)	68%	N/A

测试平台：AMD Ryzen AI 9 HX 370 (Zen5, AVX512)，23.6 GB 总 RAM。所有输出经 SHA-256 验证，与全量加载比特级别完全一致。

三、为什么这只有 50 行代码？

值得强调的是，HotPin 的核心 patch 只有约 50 行 C++ 代码，因为大部分工作被操作系统接管了：

// HotPin 的核心逻辑（简化）
// 1. mmap 模型文件
float* weights = (float*)mmap(nullptr, file_size, PROT_READ,
                              MAP_SHARED | MAP_POPULATE, fd, 0);

// 2. 计算 expert 的页面偏移
for (auto& expert : hot_experts) {
    size_t start_page = expert.offset / page_size;
    size_t end_page = (expert.offset + expert.size + page_size - 1) / page_size;
    
    // 3. mlock 钉住热 expert 的页面
    for (size_t page = start_page; page < end_page; page++) {
        mlock(weights + page * page_size / sizeof(float), page_size);
    }
}

mlock 不是预测性的——它只是告诉内核"这些页面必须始终在物理内存中"。当推理过程中访问到不在 RAM 中的页面时，操作系统会自动从 mmap 的文件中读取（通过缺页中断），不需要应用层做任何额外的预取逻辑——除非工程上希望主动优化。

但 HotPin 确实额外使用了 posix_fadvise(fd, offset, len, POSIX_FADV_WILLNEED) 来提示内核即将访问哪些区域，让内核提前发起 IO。这是可选的优化，约带来 15% 的额外加速。

四、关键边界条件：碟 > 缸 还是 缸 > 碟

HotPin 的作者特别强调了一个重要的工程洞察：当磁盘需要的页超过了可用物理 RAM 时，mlock 热页的策略不仅节省内存，而且比普通 mmap 更快。

经典的虚拟内存直觉是：如果物理 RAM 足够装下整个文件，mmap 后把所有内容 mlock 住就是最佳性能。但如果物理 RAM 无法装下全部，部分页面必然会在访问时触发缺页中断从磁盘读取——这是慢的来源。

HotPin 的加速原理如下：在普通 mmap 模式下，所有页面都是平等的——热页面和冷页面都可能被换出（如果内存压力大），冷页面的访问同样可能触发缺页。而在 HotPin 中，热页被 mlock 后永远不会被换出，冷页面则仅在被访问时才按需加载。

当 disk > RAM 时：

• 普通 mmap：热冷页面混在一起竞争 RAM，热页可能被不相关页面污染
• HotPin：热页独占 RAM 预算，冷页按需加载——热页命中率约 100%，冷页延迟被大量减少的热页缺页抵消

作者的测试表明，在这种边界条件下，HotPin 相对普通 mmap 有约 +45% 的端到端速度提升。

当 disk ≤ RAM 时情况相反——全量 mlock 是最佳选择，HotPin 只会增加无意义的开销。所以 HotPin 的适用范围上限是模型权重 > 可用 RAM。

五、局限性讨论

HotPin 是一个非常巧妙但有其适用边界的解决方案：

1. CPU-only 推理：HotPin 目前基于 llama.cpp 实现，主要针对 CPU 推理场景。对于 GPU 推理，模型权重必须常驻在 GPU VRAM 中，无法利用 mmap + mlock 的按需加载——除非使用 unified memory，但 NVLink 延迟远小于 NVMe，unified memory 在 GPU 场景下收益有限。

2. Profiling 的代表性：HotPin 的效果完全取决于 profiling 阶段选择的 expert 是否覆盖了实际推理中的热点。如果生产流量模式与 profiling 时使用的样本分布差异很大，热专家命中率会下降，导致频繁的缺页中断和性能退化。对于变化较大的工作负载，可能需要定期重新 profiling。

3. 不受 OS 内存压力的影响：当系统内存在 HotPin 之外还被其他进程使用，物理 RAM 的可用量可能减少，此时冷页面的加载可能因为 IO 竞争而延迟。HotPin 本身不感知外部内存压力。

4. 启动延迟：对 58.5GB 的文件进行 mmap + mlock 热 expert 需要一定时间（实测约 3-5 秒），好在这是一次性开销，推理过程中不会再出现。

六、延伸思考：控制理论在大模型工程中的应用

HotPin 的作者在 HN 上分享了自己发现这项技术的过程：他的本职工作是一名机器人控制工程师，日常处理的是嵌入式系统中有限 memory 下的实时传感器数据流处理。LLM 的内存管理问题在他的视角中，与嵌入式系统的内存调度挑战几乎是同构的。

"当我被告知一个 120B 模型需要 60GB RAM 才能运行时，我的第一反应不是'there is not enough memory'，而是'which parts of the model actually need to be resident in memory at any given time?'"

这恰好是控制理论的核心思维方式：不是增加系统容量来适应负载，而是通过精确理解负载的访问模式来优化现有容量的利用率。

这种跨领域移植的思维方式，在 AI 基础设施工程中越来越有价值。例如：

• KV cache 管理：借鉴 CPU cache 的 LRU/LFU/SRrip 算法来管理 attention 的 KV 条目
• MoE 的路由负载均衡：借鉴负载均衡中的 Power-of-Two-Choices 算法（DeepSeek 的 Auxiliary Loss 本质上就是负载均衡损失）
• 推理调度：借鉴实时操作系统中的 EDF（Earliest Deadline First）调度进行推理请求的优先级管理

对于专注于 AI 工程化的团队来说，值得关注的是：下一个突破可能不会来自深度学习论文，而是来自嵌入式系统、操作系统内核、或者控制理论——HotPin 正是这一趋势的最新例证。

七、落地建议

对于希望在自己的部署环境中尝试 HotPin 的团队：

1. 评估模型的适合性：HotPin 最适合权重 > 可用 RAM 的 MoE 模型。Dense 模型不适用，因为 dense 模型的所有参数都会被激活，没有"冷 expert"的概念。
2. 选择合适的硬件：CPU 推理场景，建议使用配备高速 NVMe SSD（PCIe 4.0/5.0）的机器，缺页加载延迟主要受 SSD 顺序读取速度限制。
3. 验证 profiling 覆盖率：建议用生产环境实际流量（而非随机文本）做 profiling，并在上线后监控缺页率（通过 perf 或 sar -B）。
4. 考虑混合策略：对于延迟敏感的交互式场景，可以结合 HotPin + 量化（4-bit）：进一步降低单个 expert 的大小，使更多"温 expert"也能被 mlock 到 RAM 中。

相关阅读

• vLLM 架构深度解析：从 PagedAttention 到生产级推理引擎
• 大模型推理中的存储 I/O 瓶颈与分布式缓存优化实战
• 推理模型的计算效率革命：Early Stopping 与自适应推理时延优化

---

参考资料：LozzKappa "HotPin — Lossless MoE Inference on 23.6GB RAM" (HN Jul 25, 2026)；github.com/LozzKappa/hotpin-llm；Linux mlock(2) / mmap(2) man pages