WARP：把万亿参数大模型装进消费级硬件

一个尴尬的现实：大模型需要"大机房"

想象一下：你想在本地跑一个能力接近 GPT-4 水平的模型，结果发现——它需要 1.4 TB 的存储空间、64 GB 起步的内存，推理速度还不到每秒 1 个 token。这不是科幻设定，而是 Kimi K3（2.78 万亿参数）的真实需求。消费级硬件根本跑不动它，行业主流方案是将模型部署在云端服务器上——但这意味着数据必须离开你的机器，隐私、延迟、费用的问题随之而来。

有没有可能换一种思路？

WARP（Weight-Aware Runtime and Paging，原名 WASTE） 的核心洞察是：MoE（混合专家）模型的参数虽然天文数字，但每次推理只需要激活其中 4% 的"专家"。与其把整个模型塞进内存，不如让大部分参数留在高速 NVMe 磁盘上，只实时读取当前 token 需要的少数专家权重。

这样一来，一块 64 GB 内存的 MacBook Pro，真的可以跑完整版的 Kimi K3——虽然只有 0.6 token/s，但它是一个完整的、未蒸馏的 2.78T 模型。

核心技术：专家流式加载 + 智能缓存

WARP 的架构可以用生活中的例子来理解：假设你要读一本百科全书，不需要把全书都放在桌上——你只需要把当前正在读的几页放在桌上，其他的放在书架上，用到哪页再去取。WARP 把 RAM 变成一个"桌面缓存"，NVMe SSD 变成"书架"，而模型权重就是"书页"。

具体实现上，项目采用了几个关键优化：

3-bit 残差向量量化（VQ）：专家权重使用 3-bit 量化压缩存储空间，而对推理更敏感的共享权重保留 4-8 bit，在压缩率和精度之间取得平衡。实测最终 logits 与 PyTorch 参考实现误差在 3.6e-06 以内。

预测性提前读取（Lookahead Router）：在当前 token 实际路由决策之前，预测下一层需要哪些专家，提前开始磁盘读取。真实路由结果不变，只是改变了时序——读取和计算并行进行。

Kimi Delta Attention（KDA）：K3 的线性注意力机制和压缩 KV cache 大幅降低了上下文开销：4K 上下文只需要 0.21 GB KV cache，而传统方法需要 11.25 GB。这让 K3 可以在 29.19 GB 内存占用下启动。

GPU 跳过：WARP 完全不使用 GPU。创始人 Marco Bambini 的判断是：对于这种规模的大模型，GPU 显存反而成为瓶颈（需要将数据在不同设备间反复搬运），纯 CPU + SIMD 向量指令（AVX2/AVX512、ARM NEON/i8mm）在大内存机器上效率更高。

支持的模型：从 K3 到 GLM-5.3

WARP 目前支持多款主流大模型：

GLM-5.3 和 Kimi K3 支持多模态（图像+文本），WARP 通过 --image 参数接受图片输入。DeepSeek-V4.1 的视觉塔已实现并通过 oracle 验证，但当前容器为纯文本版本。

代码架构：C 语言"零依赖"推理引擎

WARP 的代码库完全使用 C 语言编写，没有任何第三方运行时依赖（Python、Node.js 等都不需要），核心引擎仅依赖标准 C 库（libm、libpthread）。这带来了几个优势：

极低的内存开销：没有语言运行时和垃圾回收的额外消耗，内存使用完全可控。

跨平台能力：支持 Linux（x86_64、ARM64）、macOS（Apple Silicon）、Windows（MinGW），GitHub CI 在四个平台上验证构建正确性。

可嵌入式：可以编译为静态库或动态库集成到其他应用中，提供 C API。

代码组织结构清晰：src/ 下包含核心推理引擎（waste.c）、模型文件解析（model.c）、分词器（tokenizer.c）、多模态视觉处理（vision.c）、各类 SIMD 优化（simd_avx2.c、simd_avx512.c、kda_neon.c）等；cli/ 提供命令行工具；serve/ 提供 Python API 服务器。

值得注意的是，项目明确表示"代码由 LLM 编写，人类负责想法、假设、优先级、测试和决策"。创始团队利用 Opus 5 进行迭代开发，而 WARP 的终极目标是"让 K3 本地运行来改进 WARP 自己"——一个用大模型帮助改进大模型推理引擎的递归目标。

部署门槛：不适合所有人

需要直说的是：WARP 并不适合普通用户。

首先，存储是硬性瓶颈。K3 的转换容器 982 GB，冷启动单个 token 需要读取约 17 GB 数据。实测内部 NVMe SSD 速度为 12.78 GB/s，而 USB 外置硬盘盒仅有 0.94 GB/s——差了 13 倍。WARP 官方明确建议将模型容器放在内部 NVMe 上，不支持将就。

其次，编译门槛不低。项目没有 Docker/Compose 支持，必须通过 Makefile 从源码构建。在 macOS 上需要安装 Xcode Command Line Tools，在 Linux 上需要 GCC、make 和 Python 3（用于运行工具脚本），Windows 则需要 MinGW-w64。构建过程本身不算复杂，但需要一定的基础设施知识。

第三，小内存机器反而可能更慢。当可用内存不足以容纳 expert cache 时，cache hit 会变成 page fault，导致吞吐量骤降 8 倍。官方测试显示，将 expert cache 从 17.32 GB 扩大到 29.32 GB 时，hit rate 上升但 decode 速度从 0.63 tok/s 跌到 0.07 tok/s——因为操作系统开始 swap，机械磁盘 IO 拖垮了整体。

行业意义：探索本地推理的边界

WARP 代表了一个重要的技术方向：在云端推理和设备端小模型之间，探索中间地带的可能性。它不追求极致性能，而是探索"用消费级硬件接近云端模型能力"的工程极限。

从 2026 年 7 月创建至今不到 3 个月，项目已获得 2439 颗星、11 个 open issues、185 个 fork，说明社区关注度不低。主要贡献者 Marco Bambini 是 SQLite Cloud 的 CTO，有着深厚的 C 语言和数据库背景，这让 WARP 的工程实现质量有保障。

核心贡献者约 10 人，代码主要由少数活跃开发者维护，整体风格偏向精雕细琢而非快速迭代。WARP 的定位不是"通用推理框架"，而是"特定算法（MoE 专家流式加载）的深度优化引擎"——这意味着它的适用场景有明确边界，但对于边界内的场景，它做到了极致。

使用建议

如果你有一台内存充足（64 GB+）的 Mac 或 Linux 工作站，想本地运行未经蒸馏的万亿参数模型，WARP 是目前少有的开源方案之一。建议从 DeepSeek-V4.1-Flash（552B） 或 GLM-5.3-Flash（313B） 开始，这两款模型内存需求较低（4-5 GB），推理速度可达 3-4 token/s，体验相对可接受。Kimi K3 则更适合技术爱好者，用于探索本地推理的工程极限——它更多的是一个"可以做到"的证明，而非日常可用的工具。