Running DeepSeek-V4-Flash and Kimi-K3 on Consumer Hardware with SSD Expert Pack

发表时间: 2026-08 · Blog post by WiCi AI Team, SGLang Team (lmsys.org)

原文: https://lmsys.org/blog/2026-08-29-sglang-ssd-expert-pack

作者与机构：WiCi AI Team, SGLang Team（2026年8月29日）

速读

一句话结论 SGLang 提出了面向 MoE 模型的 SSD Expert Pack 方案，通过将专家权重物理重组为连续对齐数据块、利用直接 I/O 消除页缓存拷贝并配合 GPU 显存缓存，在单张 32 GB 显存的 RTX 5090 消费级显卡上成功实现了 DeepSeek-V4-Flash 与约 1 TB 体量 Kimi-K3 的无损全量推理。

要解决什么问题 DeepSeek-V4-Flash 与 Kimi-K3 等超大 MoE 模型的参数总量远超单张消费级 GPU 显存，常规部署需多卡或数百吉字节甚至太字节的系统内存。MoE 计算本身稀疏，单 token 仅激活少数专家，但为支持动态路由，全量专家池必须随时可用。原有以 GGUF 为代表的张量级格式中，同一专家的门控、上投影与下投影权重分散在文件各处甚至多文件中，导致路由命中后产生多次零碎读取；更严重的是，传统基于操作系统页缓存（Page Cache）的读取路径为“SSD -> 页缓存 -> 锁页内存 -> GPU”，其中页缓存到锁页内存是一次由 CPU 执行的同步内存拷贝，既严重消耗主机内存带宽，又引入了内核到用户态的同步延迟。由于专家选择必须在上一层计算完成后才能确定，这种低效的文件读取与内存拷贝直接落在了 MoE 推理的关键路径上，导致 GPU 发生严重停顿等待。

怎么做的 核心思路是将 NVMe SSD、主机内存与显存构建为分级存储体系，全量专家存放在 SSD，显存仅缓存高频专家，在不剪枝、不合并、不替换专家且保持 Top-K 不变的前提下消除传输开销。该方法由三个关键部件构成：一是 Expert Pack 物理重组。离线将每个层级的专家角色权重合并为物理连续且按 4096 字节对齐的专家块，运行时依据元数据直接计算偏移量进行单次读取，省去张量查表：

$$\text{expert\_offset} = \text{data\_start} + (\text{layer} \times \text{num\_experts} + \text{expert}) \times \text{expert\_stride}$$


二是基于直接 I/O（O_DIRECT）的直通传输路径。传统文件读取耗时为：

$$T = T(\text{SSD} \to \text{page cache}) + T(\text{page cache} \to \text{pinned}) + T(\text{pinned} \to \text{GPU}) + T(\text{sync})$$
方案通过对齐读取偏移、长度与锁页缓冲区（Pinned Memory，即锁定在物理内存中的主机缓冲区），直接将 SSD 数据读入锁页缓冲区，彻底消除了页缓存到锁页缓冲区的 CPU 同步拷贝，耗时简化为 $T = T(\text{SSD} \to \text{pinned}) + T(\text{pinned} \to \text{GPU})$。三是按字节预算管理的 GPU 专家缓存。显存中以完整专家为粒度管理，可用槽位由显存空间动态决定：
$$\text{slot\_count} = \lfloor \min(\text{requested\_cache}, \text{free\_vram} - \text{reserve}) / \text{expert\_payload\_bytes} \rfloor$$
替换策略结合使用频率与最近使用时间（LFU/LRU 混合），保护当前步激活专家，且只读权重驱逐无需写回。未命中时单步耗时为 $T_{\text{step}} \approx T(\text{miss delivery}) + T(\text{GPU compute})$。

效果如何 评测基于配备 Intel Ultra5 230F CPU、32 GB 内存、TiPro9000 2 TB SSD 及 RTX 5090 32 GB 显卡的单机环境，采用单并发端点模式在 5 个 Alpaca 和 5 个 MMLU 请求上各生成 200 个 token。DeepSeek-V4-Flash 对比基于 Ollama 0.33.1（内置 llama.cpp）的原生加载；Kimi-K3（38 个分片，约 1009.51 GB）对比开启 CPU 专家执行（--cpu-moe）路线的 llama.cpp。量化结果显示：DeepSeek-V4-Flash 的首字填充在 Alpaca 和 MMLU 上分别提升 2.28 倍与 3.39 倍，解码分别提升 6.92 倍（0.288 增至 1.992 tokens/s）与 6.55 倍（0.282 增至 1.846 tokens/s），独立专家缓存命中率为 54.2% 与 46.4%；Kimi-K3 的首字填充提升 6.96 倍与 5.80 倍，解码提升 3.30 倍与 3.52 倍。局限与代价在于：离线建包需额外耗时与空间，DeepSeek 建包需 5–10 分钟，Kimi-K3 需 29 分 42 秒且原始分片与生成包共占约 1.814 TiB（2 TB 硬盘余量极小，推荐 4 TB）；系统强依赖 O_DIRECT 与 4096 字节对齐契约，不满足则初始化报错退出；当前未命中的加载传输仍处在计算关键路径上，尚未流水线重叠；且不提供 KV 缓存的 SSD 卸载。

一、主要贡献

DeepSeek-V4-Flash 与 Kimi-K3 等超大规模混合专家（MoE）模型的全量参数容量远远超出了单张消费级 GPU 的显存（VRAM）容量上限。传统的本地部署方案通常需要多卡集群或者数百 GB 乃至数 TB 的宿主机内存（Host RAM），从而在顶尖大模型能力与消费级本地硬件之间形成了极高的门槛。

SGLang 团队联合 WiCi AI 团队提出了基于 SSD 后端支持的 Expert Pack 技术路径，将显存瓶颈问题转化为存储层级管理问题：

  1. 核心设计理念：将 SSD-LLaMA 的核心思想引入 MoE 推理，将未容纳于显存与宿主机内存中的路由专家（routed experts）保留在 NVMe SSD 上；鉴于路由器（router）每个 token 仅激活极少数专家，运行时系统仅将未被 GPU 缓存命中且被选中的专家实时按需搬运至 GPU。
  2. 权重重组与直接 I/O（Direct I/O）：提出 Expert Pack 物理布局，将每一层中每个专家的权重重新组织为直接可寻址的连续专家数据块（contiguous expert block）。运行时通过直接 I/O（O_DIRECT）将专家块直接加载到对齐的锁页内存（pinned host buffer）中，彻底消除了内核页缓存（page cache）到锁页内存的额外同步内存拷贝开销，随后异步传输（H2D）至 GPU 缓存。
  3. 保持无损计算与准确性：该路径完全改变的是权重的存储与传输机制，而非模型的数学计算过程。其不剪枝、不替换、不合并、不跳过任何被选中的专家，也不降低 Expert Top-K 数量。
  4. 低门槛消费级硬件实证：在单台消费级 PC 硬件（Intel Ultra5 230F CPU、32 GB 内存、TiPro9000 2 TB SSD、单张 RTX 5090 32 GB VRAM）上，成功实现了 DeepSeek-V4-Flash 以及经过验证的纯文本 Kimi-K3 模型的高效运行。

二、背景知识与核心观察

MoE 计算的稀疏性与模型总体容量的非稀疏性矛盾。混合专家模型将前馈网络（FFN）切分为多个专家。对于每一个输入 token，路由器在对所有专家打分后，仅选择一个很小的子集参与该 token 的计算，其余专家在此次计算中完全处于空闲状态。然而，路由器的选择在不同 token 以及不同 prompt 之间是高度动态变化的，这意味着尽管任何时刻活跃的工作集（working set）非常小，完整的专家池仍然必须随时待命并保持可用。虽然量化可以压缩权重文件体积，但无法消除存储完整专家池的刚性需求。因此，MoE 推理表现出两大核心特性：其一，单 token 的计算在结构上是稀疏的；其二，必须被存储并随时提供服务的专家总容量极其庞大。这正是将 SSD 作为后备层（backing tier）的合理性所在：它提供了远超消费级 VRAM 或 RAM 的容量，且现代 PCIe 5.0 NVMe SSD 的连续带宽足以支撑起经过精心设计的专家传输流水线。但必须强调，只有当物理布局、读取路径和缓存策略与专家级访问模式完全契合时，SSD 容量才能真正转化为可执行的模型内存。

容量-成本维度的极度不对称性。将完整专家池完全放置于 VRAM 或 DRAM 在消费级场景下在经济上迅速变得不可行。容量成本对比清晰地揭示了这种权衡取舍：

DeepSeek-V4-Flash 与 Kimi-K3 在对数坐标下的容量成本对比
DeepSeek-V4-Flash 与 Kimi-K3 在对数坐标下的容量成本对比

该图展示了 DeepSeek-V4-Flash 与 Kimi-K3 仅考虑存储容量时的成本下限（非整机价格）。它并不意味着 SSD 和 DRAM 具有相同的延迟，也不代表仅购买一块 SSD 就足以运行模型，而是证明了：利用 SSD 承担海量容量负担，同时用有限的 GPU 显存作为活跃工作集的高速缓存，能够实质性降低顶尖 MoE 大模型的本地硬件门槛。

SGLang 的 SSD Expert Pack 系统架构构想。SSD-LLaMA 的核心思想是将 SSD、RAM 和 VRAM 作为运行时统一受控的存储层级进行协同管理。完整的专家池驻留在高容量存储层，有限的 VRAM 则保留具有最高观测复用率的专家。SGLang 的 Expert Pack 是在该 MoE 运行时内部对这一专家中心化思想的关键工程落地：

  • 第一，Expert Pack 将 (layer, expert) 对构造成独立寻址的连续物理专家块；
  • 第二，利用 O_DIRECT 与内存对齐的锁页缓冲区，消除操作系统页缓存暂存带来的额外内存拷贝；
  • 第三，构建按字节预算管理的 LFU/LRU GPU 专家缓存，用于留存高复用率的完整专家。
    与原版 SSD-LLaMA 论文相比，SGLang 的实现更加以 GPU 为中心：锁页宿主机内存仅用作有界的传输暂存区（staging area），而非持久化的宿主机专家缓存，且该特性不需要原论文涉及的 CPU 专家执行或无损 CUDA 解压缩机制，从而使得系统特性边界更加清晰聚焦。

原生 GGUF 格式加载路径的技术局限与瓶颈。在原生的 GGUF 或多分卷（multi-shard）张量物理布局中，单个专家的 gate、up 和 down 权重往往散落分布在文件的不同物理区域或跨越多个分卷。一次路由器命中可能会引发数次微小的离散 I/O 读取、张量名称字典检索以及多次内存暂存操作。如果采取显式的按需直接读取，虽然能避免投机性预取的误判开销，但会将完整的 SSD I/O 与 H2D 延迟直接暴露在当前 MoE 层的计算关键路径上，GPU 在路由器得出结果后必须完全阻塞等待所选专家加载完毕。而投机预取并不能根本解决问题：一方面，由于路由结果完全依赖前序计算，真正的目标专家往往无法提前足够长时间获知；另一方面，预测错误会徒增 SSD 带宽占用、耗尽暂存空间并污染 GPU 缓存，且最终仍必须回退读取真正被选中的专家。因此，SGLang 的策略首先是物理重组专家权重，其次是极限压缩每一次不可避免的缓存缺失（cache miss）代价。

原生 GGUF 无法直接使用专家级 Direct I/O 的深层机制。原生 GGUF 是以单个张量为核心的模型容器，而非面向专家级 Direct I/O 设计的存储格式。其元数据与张量载荷均围绕独立张量构建，单个专家的三个组成张量在磁盘上没有物理连续性保证。原始加载路径通常依赖解析器、mmap 或带缓冲的文件读取接口，应用层看到的是基于内核页缓存的可分页映射，而非预先分配且严格对齐的直接 DMA 目标地址。Linux 下启用直接 I/O（O_DIRECT）对调用者有严格的底层契约限制：

  • 文件偏移量必须与底层存储和文件系统的块大小（通常为 4096 字节）严格对齐；
  • 读取长度必须是该对齐块大小的整数倍；
  • 用户传入的内存缓冲区起始地址也必须满足硬件对齐要求。
    原生 GGUF 文件内的任意张量切片无法满足上述专家级契约：偏移未对齐、长度非对齐块倍数、专家三张量不连续。若强行使用带 padding 的多次读取再在内存中重组拼接，则彻底失去了性能优势，重蹈了多次 I/O 与额外组装内存拷贝的覆辙。Expert Pack 充当了离线转换的角色，它将一个层/专家对的所有角色整合为单个带 padding、严格对齐的专家块，并在 manifest 中记录确切偏移与长度，配合对齐锁页缓冲区，使得运行时无需迁就原生 GGUF 即可享受 Direct I/O 带来的性能红利。

三、方法细节

3.1 Expert Pack：按专家组织权重

连续物理专家块组织形式。SGLang Expert Pack v1 将单个 (layer, expert) 对视为一个独立的完整专家单位。例如一个 DeepSeek 专家包含 gate、up 和 down 三种角色张量。Manifest 元数据文件精确记录了每个角色张量的边界、数据格式、完整性校验信息以及其在 Expert Pack 中的起始物理偏移量。

其物理数据块布局逻辑如下所示：

Expert Pack 物理数据块布局：包含连续的专家字节流与显式的块对齐填充
Expert Pack 物理数据块布局：包含连续的专家字节流与显式的块对齐填充

免查字典的恒定时间物理偏移寻址。在运行时，系统完全不再需要在文件内根据张量名称进行遍历检索。运行时能够直接依据 Pack 的固定元数据结构，通过简单的数学计算推导出任意专家的物理起始偏移量：

$$expert\_offset = data\_start + (layer \times num\_experts + expert) \times expert\_stride$$


专家内部各角色张量的相对偏移同样在元数据中经过预校验。因此，仅需一次 manifest 查找即可精准解析出整套专家的完整读取字节区间。运行时还可以根据配置参数 read_splits，将该读取区间拆分为受控数量的并行异步 I/O 子任务进行并发读取。

物理权重重排与模型数学的一致性解耦。该布局仅改变了权重在 SSD 上的物理排列次序，绝不改变张量内部的数据内容、量化格式（quantization format）、动态路由决策逻辑或底层模型的数学定义。针对 Kimi-K3 模型，系统构建了专用的 GGML Expert Pack 适配器，其验证输入包含 38 个分卷的 Q2_K GGUF 格式分片，重组后的路由专家在 gate/up 角色上保持 Q2_K，在 down 角色上保持 Q3_K。

Direct I/O 的严格物理对齐约束校验。Direct I/O 机制决不允许像常规 read() 那样传入任意的文件偏移、读取长度或内存指针。SGLang 运行时在初始化阶段会对以下三项执行严格的边界契约检查：

  • 每一个专家的物理 Pack 起始偏移量；
  • 每一个实际下发的读取区间的起始地址与总读取长度；
  • 每一个锁页暂存缓冲区（pinned staging buffer）的用户空间虚拟地址。
    当前的工程实现强制检查 4096 字节（4 KB）物理对齐。一旦发现 Pack 布局或暂存缓冲区未能满足该契约，初始化过程会直接报错中止（fail-closed），杜绝在推理过程中隐式回退到未经对齐优化的非受控回退路径。

3.2 核心优化：消除 页缓存 -> 锁页内存 的二次数据拷贝

传统缓冲 I/O 路径的同步拷贝开销剖析。在常规的文件读取路径中，I/O 请求必须通过操作系统的内核页缓存进行中转：

传统文件读取路径：同步的内核页缓存到锁页内存拷贝，随后执行异步 H2D 传输
传统文件读取路径：同步的内核页缓存到锁页内存拷贝，随后执行异步 H2D 传输

操作系统页缓存是内核统一管理的文件系统缓存，其物理页不可直接作为 CUDA 发起异步主机到设备（H2D）传输的源地址。为了发起异步 cudaMemcpyAsync，应用程序必须在用户态预先分配并锁定一块锁页内存（pinned host memory）。因此，传统流程必须先由 CPU 执行一次同步内存拷贝，将数据从页缓存物理页读出并写入到该锁页内存区中，随后才能提交 H2D 传输指令。从应用层来看，这一页缓存至锁页内存的传递是一次纯粹由 CPU 主导的同步内存搬运：CPU 必须全量读取专家数据并重新写入锁页区，对于体积庞大的专家参数而言，这极大地消耗了宿主机内存总线带宽，并引入了内核态到用户态的额外同步延迟屏障。

Expert Pack 采用 Direct I/O 的直通传输机制。当配置参数 direct_io=True 时，SGLang 运行时以 O_DIRECT 标志打开 Expert Pack 文件，并直接将预先分配、严格对齐的锁页暂存缓冲区作为读取操作的目标内存地址：

Expert Pack 直接 I/O 路径：对齐的锁页宿主机缓冲区在 MoE 计算前直接供给 GPU 专家缓存
Expert Pack 直接 I/O 路径：对齐的锁页宿主机缓冲区在 MoE 计算前直接供给 GPU 专家缓存

由于文件系统读取的目标地址本身就是 CUDA 原生支持的锁页内存，因此传统路径中必经的中间拷贝步骤被彻底从数据通路中剥除：

$$\text{page cache} \to \text{pinned memory} \quad (\text{已彻底消除})$$

端到端时间开销模型的理论对比。该设计并非对拷贝操作本身的微观加速，而是实现了数据通路的直接剪枝。简化的理论开销模型表述如下：

$$\text{传统路径时间开销: } T = T(\text{SSD} \to \text{page cache}) + T(\text{page cache} \to \text{pinned}) + T(\text{pinned} \to \text{GPU}) + T(\text{sync})$$

$$\text{Expert Pack Direct I/O 开销: } T = T(\text{SSD} \to \text{pinned}) + T(\text{pinned} \to \text{GPU})$$

尽管 O_DIRECT 并不能改变 SSD 硬件本身的物理读带宽上限，但它在端到端链路中削减了一次完整的宿主机内存遍历（host-memory traversal），由此带来了多维度的系统级收益：

  • 减少了一次全量宿主机内存读取和一次全量写入，显著缓解了 CPU 占用率与宿主机内存带宽竞争压力；
  • 消除了内核页缓存与用户态暂存空间之间的多次同步握手开销；
  • 避免了巨大的专家权重载荷冲刷操作系统的页缓存，不会挤占宿主机其他不相关服务或数据的内存空间；
  • 使得就绪的完整专家数据块能够立即进入异步 H2D 传输队列；
  • 为模型中所有的层与专家对复用了高度标准化、可预测的专家级 I/O 契约。

需要说明的是，消除页缓存拷贝的技术收益仅在 direct_io=True 开启时成立。当前 SGLang Expert Pack 加载器及针对 DeepSeek/Kimi 的 RTX 5090 启动脚本默认均开启此选项；若显式关闭该选项，系统仍会回退至传统页缓存与额外暂存拷贝路径。

3.3 GPU/VRAM 专家缓存：将活跃工作集贴近计算核心

以完整专家为粒度的缓存条目管理。GPU 缓存是将高频专家访问转化为本地 VRAM 高速命中的关键机制。与针对细粒度张量碎片的缓存不同，Expert Pack 的缓存条目严格以单个完整专家为最小单位，每个缓存槽位（slot）必须同时容纳对应 (layer, expert) 对的全部 gate、up 和 down 参数。这是由于在 MoE 计算中，一旦某个专家被激活，必须依赖其所有角色张量协同参与运算，若只缓存部分角色，依然会触发缺失惩罚并强制发生磁盘 I/O，无法真正消除关键路径上的等待。

基于字节预算而非专家数量的动态容量推导。考虑到不同模型以及不同适配器下每个专家的参数字节尺寸存在差异，缓存容量采用动态字节预算进行严格约束。运行时根据实际可用的显存空间推导最大可用槽位数量：

$$usable\_vram = \min(requested\_cache, free\_vram - reserve)$$

$$slot\_count = \lfloor usable\_vram / expert\_payload\_bytes \rfloor$$
公式中的预留显存 reserve 用于保护模型非 MoE 部分参数、CUDA 运行时环境、激活值显存（activations）以及系统其他非缓存静态显存分配。如果在扣除预留后计算出的 slot_count 无法容纳单次前向传播中完整的 Top-K 专家工作集，系统在初始化阶段将强制抛出异常失败。这一防御机制明确确立了显存预算契约：专家缓存绝不允许侵占当前 MoE 计算核心运转所必需的基础显存。

缓存命中与缺失的精细化状态机流转。

  • 缓存命中状态：当路由器选择的专家已驻留显存时，运行时直接复用该现役槽位，完全跳过针对该专家的 Expert Pack 磁盘读取与 H2D 传输操作。若该专家由上一轮尚未完全收尾的异步传输填充，系统通过底层的 CUDA Event 机制设置同步流依赖，严密防止消费者算子读取到处于半写入状态的未就绪槽位。
  • 缓存缺失状态：当发生未命中时，淘汰算法选出受害者槽位（victim slot），运行时通过 Direct I/O 将完整专家从 SSD 读入一个可复用的对齐锁页宿主机暂存缓冲区，随后提交异步 H2D 拷贝将其灌入 GPU 槽位，只有在异步传输 CUDA Event 确认完全就绪后，该槽位才会被发布（publish）给计算流可见。

结合访问频率与新鲜度的 LFU/LRU 混合淘汰策略。运行时系统持续维护每个 (layer, expert) 的历史激活频次及最近访问时间戳。高频激活的热点专家享有更高的保留权重，极难被直接逐出；在访问频次相近的候选条目之间，最近最久未使用的冷条目将被优先选为淘汰目标。尤为关键的是，当前推理步骤中被 Top-K 命中的所有正在执行或即将执行的专家受到强制驻留保护，绝对禁止被选作淘汰受害者，从原理上杜绝了缓存将本轮算子即将使用的计算工作集误淘汰的情况发生。

源数据只读不可变带来的无回写（Zero Write-back）特性。由于 SSD 上的 Expert Pack 源数据属于只读不可变数据，GPU 显存中被淘汰的专家槽位无需执行任何写回（write-back）操作，其全量权重随时可以依据固定偏移量从 SSD 再次确定性地重建。这一特性使得 VRAM 专家缓存的管理机制显著优于常规的脏数据（dirty-page）缓存系统，无需维护复杂的脏标记与写回状态机，从而使替换逻辑完全纯粹地服务于专家复用价值的最大化。

细粒度运行时可观测性与遥测计数器。运行时暴露了丰富的底层计数器，用于精准诊断与解耦性能瓶颈：

  • cache_hits 与 cache_misses：记录去重后的键命中与缺失情况；
  • cache_evictions：记录缓存条目被逐出的累计次数；
  • pack_read_bytes：记录从 Expert Pack 读取的物理磁盘字节总数；
  • h2d_bytes：记录从主机到设备传输的专家总字节数；
  • fallback_count 与 io_errors：分别用于记录诊断回退和底层 I/O 错误。
    这些指标使得研发人员能够快速辨析系统瓶颈究竟归属于缓存还是底层 I/O：低命中率反映出 VRAM 显存预算不足或当前负载的时间局部性较差；而若命中率极高但同时伴随着异常庞大的 pack_read_bytes 与 h2d_bytes，则意味着在特定阶段工作集突发性地超出了当前缓存容量；io_errors 报告真正的底层 I/O 硬件或契约失效，fallback_count 为辅助诊断遥测，两者均非单纯的缓存性能指标。

当前计算与传输流水线的执行依赖模型。在目前的工程实现中，专家缓存缺失处理依然被放置在驱动 MoE 计算的关键路径之上。其执行步骤顺序展开如下：

  1. acquire() 函数首先将路由器输出的专家选中 ID 拷贝回 CPU 端；
  2. CPU 端等待所有发往 SSD 的异步读取 Future 全部就绪；
  3. 将对齐锁页缓冲区内的专家数据分发并排入专家级异步 H2D 传输流；
  4. 强制当前计算用 CUDA 流等待上述 H2D 传输事件触发标记；
  5. 在传输事件全部标记就绪后，apply() 函数才正式发射 MoE 计算 Kernel。
    尽管不同缺失专家之间的磁盘读取与 H2D 传输可在供给阶段相互重叠执行，但目前的实现版本尚未实现将下一层的专家搬运与当前层的 MoE 计算重叠（overlap）。因此，当前的单步端到端延迟模型为：

    $$T_{\text{step}} \approx T(\text{miss delivery}) + T(\text{GPU compute})$$


    其中 $T(\text{miss delivery})$ 聚合了路由 ID 准备、SSD 读取、锁页暂存、H2D 提交以及同步等待专家可用所需的耗时。若命中率达 100%，则该项耗时中的 SSD 读与 H2D 传输可完全归零。跨步（cross-step）流水线重叠机制目前尚未在此执行路径中合并。

四、实验环境

  1. 硬件基础配置：

    • 系统平台：单台消费级 PC 桌面硬件。
    • 处理器（CPU）：Intel Ultra5 230F。
    • 系统内存（Host RAM）：32 GB。
    • 存储介质（SSD）：长江存储致态 TiPro9000 2 TB NVMe SSD（PCIe 5.0）。
    • 显卡（GPU）：NVIDIA GeForce RTX 5090（32 GB VRAM）。

  2. 软件栈与代码版本：

    • SGLang：基于分支 support_deepseek-v4_and_kimi-k3_on_ssd，固定 Commit 为 81c9f837f19ff8dfe1a9fcd1abfc6069dd28d2ec。
    • 基线系统 1（Ollama）：Ollama 0.33.1，其内置托管的 llama.cpp runner 提交版本为 d222767c7。
    • 基线系统 2（llama.cpp）：编译版本 commit 为 5fff128451d7603857597ee1fc18ac1dfb90f148，启用 --cpu-moe 进行 CPU 专家卸载计算。
    • 底层依赖：Linux 环境，支持 O_DIRECT（4 KB 对齐），Python 3 环境，jq，Hugging Face CLI。

  3. 评测数据集与负载属性：

    • 评测模式：代表端点推理（endpoint inference）而非批处理服务（batched serving），10 个固定请求严格按顺序单并发串行下发，当前请求完全返回后才发射下一请求。
    • 数据样本构成：共 10 个测试用例，包含 5 条 Alpaca 任务请求和 5 条 MMLU 多学科选择题/推理请求。
    • 解码超参数：所有测试统一采用 temperature=0，默认 EOS 截断处理，严格生成 200 个 completion tokens。

  4. 模型与权重参数：

    • DeepSeek-V4-Flash：原模型为单文件 Ollama MXFP4 GGUF 格式 blob（155.10 GB），生成的 Expert Pack 大小为 147.18 GB。分配约 21 GiB VRAM 专家缓存（cache_vram_mib=21504，预留 cache_vram_reserve_mib=2048），设置 12 个暂存槽位（stage_slots=12），4 线程拆分读取（read_splits=4）。
    • Kimi-K3：原模型为 38 个分卷的 Q2_K GGUF 分片，文件总大小 1009.51 GB（约 1.01 TB），生成的 Expert Pack 大小为 985.61 GB。显存专家缓存分配 5 GiB（cache_vram_mib=5120，预留 cache_vram_reserve_mib=1536），设置 16 个暂存槽位（stage_slots=16），单线程直接读取（read_splits=1），全 92 个路由层均执行 Top-16 专家计算。

五、实验结果

5.1 权重格式转换体积对比

模型名称 原始权重文件形态 原始权重体积 Expert Pack 生成体积
DeepSeek-V4-Flash 1 个 Ollama MXFP4 GGUF blob 155.10 GB 147.18 GB
Kimi-K3 38 个 Q2_K GGUF 分卷分片 1009.51 GB (~1.01 TB) 985.61 GB

注：上述体积仅指经校验的权重实际载荷，Pack 索引文件、锁文件及 manifest 元数据体积单独计算。

5.2 DeepSeek-V4-Flash 性能表现（对比 Ollama 基线）

测试包含 5 个 Alpaca 和 5 个 MMLU 样本，生成上限 200 tokens。性能速率图表展示如下：

DeepSeek-V4-Flash SGLang 与基线在 Alpaca 和 MMLU 数据集上的 Prefill 与 Decode Token 速率对比
DeepSeek-V4-Flash SGLang 与基线在 Alpaca 和 MMLU 数据集上的 Prefill 与 Decode Token 速率对比

对比 Ollama 基线，SGLang 在 Alpaca 任务上的 Prefill 提速 2.28倍，在 MMLU 任务上提速 3.39倍；而在 Decode 解码阶段，提速幅度分别达到了 6.92倍 与 6.55倍。各数据集的详细算术平均速率（tokens/s）如下表所示：

数据集 (n=5) 基线 Prefill 速率 SGLang Prefill 速率 Prefill 加速比 基线 Decode 速率 SGLang Decode 速率 Decode 加速比
Alpaca 1.108 tok/s 2.532 tok/s 2.28x 0.288 tok/s 1.992 tok/s 6.92x
MMLU 1.223 tok/s 4.141 tok/s 3.39x 0.282 tok/s 1.846 tok/s 6.55x

5.3 Kimi-K3 性能表现（对比 llama.cpp 基线）

测试使用完全相同的 10 个测试样本，严格固定生成 200 个 completion tokens，确保生成长度、终止条件与 prompt 完全一致。对比图表如下：

Kimi-K3 SGLang 与 llama.cpp 在 Alpaca 和 MMLU 数据集上的 Prefill 与 Decode Token 速率对比
Kimi-K3 SGLang 与 llama.cpp 在 Alpaca 和 MMLU 数据集上的 Prefill 与 Decode Token 速率对比

相对于采用 CPU 专家卸载计算的 llama.cpp 基线，SGLang 的端到端推理优势极度显著：Prefill 阶段在 Alpaca 上提速 6.96倍，在 MMLU 上提速 5.80倍；Decode 阶段提速分别为 3.30倍 和 3.52倍。

5.4 专家缓存命中率与 SSD 数据吞吐遥测分析

遥测指标基于 acquire() 阶段去重后的唯一 (layer, expert) 访问键进行计算。单 token 的 SSD 吞吐量指标统计了包含 Prefill 与 Decode 阶段在内的 pack_read_bytes 算术平均总和除以生成的 completion tokens。

DeepSeek-V4-Flash 遥测指标如图所示：

DeepSeek-V4-Flash SGLang 唯一键 VRAM 缓存命中率与单生成 Token 平均 SSD 流量
DeepSeek-V4-Flash SGLang 唯一键 VRAM 缓存命中率与单生成 Token 平均 SSD 流量
  • 缓存命中率：Alpaca 数据集平均唯一键命中率为 54.2%，MMLU 数据集为 46.4%。
  • SSD 流量开销：单生成 token 对应的 SSD 物理读取量在 Alpaca 上平均为 1.66 GB（十进制 GB），在 MMLU 上平均为 2.04 GB。

Kimi-K3 遥测指标如图所示：

Kimi-K3 SGLang 唯一键 VRAM 缓存命中率与单生成 Token 平均 SSD 流量
Kimi-K3 SGLang 唯一键 VRAM 缓存命中率与单生成 Token 平均 SSD 流量
  • 缓存命中率：Alpaca 数据集平均唯一键命中率为 17.0%，MMLU 数据集为 22.7%。
  • SSD 流量开销：单生成 token 对应的平均 SSD 物理流量在 Alpaca 上为 22.10 GB，在 MMLU 上为 27.63 GB。
  • 差异原因分析：Kimi-K3 与 DeepSeek 之间的命中率与 I/O 差异符合理论预期。一方面，Kimi-K3 的配置受限于宿主机环境，仅为其 GPU 专家缓存分配了 5 GiB 显存（DeepSeek 分配了约 21 GiB）；另一方面，两者的模型架构、专家物理单体尺寸、总层数（Kimi 共 92 个路由层，Top-16）以及路由分布特征存在本质差异。

综合结果表明，端到端性能的巨大飞跃并非归功于某一个微观拷贝算子的孤立提升，而是四项系统性协同作用的结果：

  1. Expert Pack 将碎片化离散张量转化为大块连续的物理专家读取；
  2. Direct I/O 彻底消除了操作系统页缓存向锁页内存的二次复制；
  3. 锁页暂存为 CUDA H2D 传输提供了原生的无中转数据源；
  4. GPU 专家缓存机制在命中时完全抹去了底层的磁盘 I/O 与传输开销。

六、补充细节：正确性边界与复现指南

6.1 正确性边界与语义一致性审计

确定性的非近似推理契约。Expert Pack 是一种纯粹的权重物理布局重构与传输吞吐优化技术，绝非有损的近似推断算法。其严格遵循以下正确性契约：

  • 路由器选中的每一个专家都必须得到真实物理执行；
  • 模型原生的 Expert Top-K 数量保持绝对不变；
  • 绝不允许将选中的专家动态降级替换为当前已驻留显存的其他热点专家；
  • 绝不剪枝、绝不跳过、绝不融合任何激活专家；
  • 对生成生成的 Pack 与 Manifest 进行严格的结构、张量维度及密码学 Hash 校验；
  • 显式上报 fallback_count 与 io_errors，严禁静默吞没底层 I/O 故障。
    在跨领域 Prompt 的实际比对中，DeepSeek-V4-Flash 的输出与 Ollama 基线保持了完全一致的语义质量；Kimi-K3 严格匹配了 200-token 的 SGLang 参考输出，全模型 92 个路由层全部以 Top-16 规格精确执行，且记录的 io_errors 为 0。

6.2 详细复现指南

测试采用的 10 个固定评测请求详见下表：

序号 样本编号 ID 数据集归属 Prompt 核心内容
1 alpaca-37246 Alpaca Summarize the movie "Toy Story"
2 mmlu-abstract_algebra-14 MMLU 求 $S_{10}$ 元素的最大可能阶数（选择题：A. 6, B. 12, C. 30, D. 105）并简要解释
3 alpaca-50812 Alpaca 根据给定的物品列表（铅笔、纸、马克笔）建议一项有趣的活动
4 mmlu-moral_disputes-8315 MMLU 关于 Hardin 所述“棘轮效应（ratchet effect）”概念的选择题与解释
5 alpaca-9907 Alpaca 将西班牙语短语 "El sol no brilla hoy" 翻译为英文
6 mmlu-high_school_macroeconomics-3940 MMLU 关于政府借贷挤出效应（crowding-out effect）最佳描述的选择题
7 alpaca-40699 Alpaca 举出一个人工智能算法中可能存在的偏见（bias）实例
8 mmlu-professional_law-10971 MMLU 关于土地挖掘、侧向支撑权（lateral support）诉讼判决的专业法律案例选择题
9 alpaca-34440 Alpaca 使用三文鱼、牛油果、菠菜三种食材设计一道餐厅菜单菜品
10 mmlu-jurisprudence-6660 MMLU 关于反驳伦理相对主义对人权敌视的最强法理学论据选择题
1. DeepSeek-V4-Flash 复现流程
  • 基线启动：
OLLAMA_HOST=127.0.0.1:11435 ollama serve >/tmp/deepseek-ollama.log 2>&1 &
  • 拉取模型与构建 Pack：
    通过 ollama pull frob/deepseek-v4-flash-0731 拉取模型 blob（SHA-256 为 947ac34...，Manifest SHA-256 为 882b139...）。
    执行构建脚本转换物理布局：
cd /path/to/sglang-latest-deepseek-v4-kimi-k3-ssd
python3 -m pip install -e 'python'
python3 tools/expert_pack/prepare_deepseek_pack.py \
  --gguf /path/to/deepseek-v4-flash-0731.gguf \
  --model-config /path/to/deepseek-v4-flash-config.json \
  --safety-margin-gib 16
  • 元数据生成校验：
python3 examples/runtime/deepseek_v4/benchmark_deepseek_5090.py \
  --gguf /path/to/deepseek-v4-flash-0731.gguf \
  --validate-only
  • 启动 SGLang 服务端：
GGUF=/path/to/deepseek-v4-flash-0731.gguf
ARTIFACT_DIR=${XDG_CACHE_HOME:-$HOME/.cache}/sglang-expert-pack/deepseek-v4-flash/<fingerprint>
MODEL_META="$ARTIFACT_DIR/model-meta"
PACK_PATH="$(dirname "$GGUF")/DeepSeek-V4-Flash.expert-pack"
MANIFEST_PATH="$(dirname "$GGUF")/DeepSeek-V4-Flash.expert-pack.manifest.json"
STATS_PATH="$ARTIFACT_DIR/deepseek-v4-expert-pack.stats.json"
SOURCE_SHA256="$(jq -r '.source.sha256' "$MANIFEST_PATH")"
OLLAMA_MANIFEST_SHA256="$(jq -r '.model.model_identity_sha256 // .model.ollama_manifest_sha256' "$MANIFEST_PATH")"
CONFIG_SHA256="$(jq -r '.model.config_sha256' "$MANIFEST_PATH")"

python3 -m sglang.launch_server \
  --model-path "$MODEL_META" \
  --tokenizer-path "$MODEL_META" \
  --trust-remote-code \
  --load-format expert_pack \
  --model-loader-extra-config "{\"pack_path\":\"$PACK_PATH\",\"manifest_path\":\"$MANIFEST_PATH\",\"source_path\":\"$GGUF\",\"source_sha256\":\"$SOURCE_SHA256\",\"ollama_manifest_sha256\":\"$OLLAMA_MANIFEST_SHA256\",\"config_sha256\":\"$CONFIG_SHA256\",\"cache_vram_mib\":21504,\"cache_vram_reserve_mib\":2048,\"stage_slots\":12,\"read_splits\":4,\"direct_io\":true,\"stats_flush_interval\":43,\"stats_path\":\"$STATS_PATH\"}" \
  --attention-backend dsv4 \
  --tp-size 1 --ep-size 1 \
  --disable-cuda-graph --disable-flashinfer-autotune \
  --disable-shared-experts-fusion --skip-server-warmup \
  --max-running-requests 1 --mem-fraction-static 0.96 \
  --watchdog-timeout 1800 --host 127.0.0.1 --port 30001
2. Kimi-K3 复现流程

  • 权重与分词器下载：
    使用 hf download 从 Blackfrost-AI/KIMI-K3-Q2_K-GGUF-ABLITERATED 下载 38 个 Q2_K 分卷分片；从 moonshotai/Kimi-K3（commit: 9f62e4e）下载分词器及配置文件。

  • Pack 离线转换与元数据准备：

cd /path/to/sglang-latest-deepseek-v4-kimi-k3-ssd
python3 tools/expert_pack/prepare_kimi_pack.py \
  --gguf /path/to/kimi-k3/KIMI-K3-MXP4-DERISKED-Q2_K-00001-of-00038.gguf \
  --model-config /path/to/kimi-k3-tokenizer/config.json \
  --safety-margin-gib 2

python3 examples/runtime/kimi_k3/benchmark_kimi_k3_5090.py \
  --gguf /path/to/kimi-k3/KIMI-K3-MXP4-DERISKED-Q2_K-00001-of-00038.gguf \
  --max-new-tokens 200 --direct-io --read-splits 1 --prepare-only
  • 启动 SGLang 运行时：
GGUF_DIR=/path/to/kimi-k3
PACK_PATH="$GGUF_DIR/KIMI-K3-MXP4-DERISKED-Q2_K.expert-major.pack"
ARTIFACT_DIR="${XDG_CACHE_HOME:-$HOME/.cache}/sglang-expert-pack/kimi-k3/<fingerprint>"
MODEL_META="$ARTIFACT_DIR/model-meta"
MANIFEST_PATH="$ARTIFACT_DIR/kimi-k3-expert-pack.manifest.json"
STATS_PATH="$ARTIFACT_DIR/kimi-k3-expert-pack.stats.json"

python3 -m sglang.launch_server \
  --model-path "$MODEL_META" \
  --tokenizer-path "$MODEL_META" \
  --trust-remote-code \
  --load-format expert_pack \
  --model-loader-extra-config "{\"pack_path\":\"$PACK_PATH\",\"manifest_path\":\"$MANIFEST_PATH\",\"cache_vram_mib\":5120,\"cache_vram_reserve_mib\":1536,\"stage_slots\":16,\"read_splits\":1,\"direct_io\":true,\"stats_flush_interval\":92,\"stats_path\":\"$STATS_PATH\",\"verify_pack_sha256\":false}" \
  --tp-size 1 --ep-size 1 \
  --disable-cuda-graph --disable-shared-experts-fusion \
  --disable-radix-cache --mamba-radix-cache-strategy no_buffer \
  --disable-overlap-schedule --skip-server-warmup \
  --chunked-prefill-size 64 --watchdog-timeout 1800 \
  --max-running-requests 1 --mem-fraction-static 0.98 \
  --host 127.0.0.1 --port 30001
  • 启动 llama.cpp 基线服务：
/path/to/llama.cpp/build/bin/llama-server \
  -m /path/to/kimi-k3/KIMI-K3-MXP4-DERISKED-Q2_K-00001-of-00038.gguf \
  -ngl -1 --cpu-moe --host 127.0.0.1 --port 8081 \
  -t 16 -tb 16 --threads-http 16 -np 1 -c 4096 \
  --no-warmup --metrics \
  --log-file /path/to/kimi-k3-llama-cpp/server.log

七、补充细节：条件与局限性

SSD 容量冗余与构建准备耗时。Expert Pack 格式转换需要在磁盘上额外占用与模型权重相当的空间。构建 DeepSeek-V4-Flash 的 Pack 约耗时 5–10 分钟，首次运行端到端准备约需 8–15 分钟。Kimi-K3 规模更大，其实测构建耗时为 29 分 42 秒，首次就绪时间约为 35–45 分钟。Kimi-K3 的 38 个原始分卷与转换后的 Pack 合计占用约 1.814 TiB；尽管测试使用的是 2 TB 磁盘，但在实际部署中推荐配置 4 TB 规格的 SSD 以获得充裕的可用存储空间。

直接 I/O 的平台约束与强失败机制。O_DIRECT 需要宿主操作系统和文件系统底层提供严格支持，并强依赖于物理偏移、读取长度以及缓冲区虚拟地址的 4 KB 边界对齐。SGLang 在运行时初始化期间采取严密的快速失败（fail-closed）准则，若环境缺乏 Direct I/O 支持或数据排布不合规，程序直接中止，绝不妥协为伪装的 Direct I/O 运行。

缓存敏感度与不同负载适应性。

  • 若分得的 GPU 专家缓存过小，会加剧未命中概率，迫使 SSD 读取与 H2D 传输更频繁地落入计算关键路径；
  • 提示词风格或下游任务领域的剧变会导致活跃热点专家工作集漂移，针对某一特定 prompt 集合构建的热专家分布无法保证适配全域场景；
  • 若 GPU 自身显存已足够完全容纳全量专家池，则 Expert Pack 机制纯属多余，不应在此类场景下开启；
  • 若推理负载整体受限于 GPU 计算本身（compute-bound），则抹除主机数据拷贝所带来的边际性能收益可能会被计算耗时所掩盖；
  • 若使用的 SSD 随机读性能低劣、主控排队严重或发热掉速严重，盲目增大 read_splits 与暂存槽位数可能会引发内部排队拥堵与内存压力，反而劣化吞吐表现。

当前功能模块边界定位。当前特性的核心完全定位于路由专家的 SSD 供给与 GPU 缓存管理。它暂不提供 KV-Cache 的 SSD 卸载支持，亦未重构底层请求批处理调度策略。它作为一项显式自选特性（--load-format expert_pack）提供，而非全局替代 SGLang 原有的通用模型加载后端。

八、结论

SSD Expert Pack 技术路径并非简单地将显存空间替换为慢速的外部磁盘，而是深度围绕 MoE 稀疏激活特质构建的高性能协同交付系统：

$$\text{Router 选出局部专家} \to \text{Expert Pack 解析物理偏移} \to \text{Direct I/O 读入对齐锁页内存} \to \text{异步 H2D 灌入 GPU 缓存} \to \text{计算核心即刻调用}$$

消除操作系统“页缓存到锁页内存”的同步数据搬运，是一项容易被常规软件栈忽略、但在极限带宽场景下具有决定性意义的端到端系统优化。借助 Direct I/O 与对齐锁页缓冲区，SGLang 成功将 SSD-LLaMA 的核心思想工程化注入到前沿开源推理引擎中。在单张消费级 RTX 5090 与高速 NVMe SSD 的组合上，DeepSeek-V4-Flash 和 Kimi-K3 展现出了极高的运行实用性与响应速率，彻底改变了超大参数 MoE 模型的本地硬件供给范式。

九、方法细节引用汇总

引用标记 / 文献名称 文中引用段落位置 原文核心描述与分析
SSD-LLaMA 摘要（Abstract）前言引用 “SGLang brings the core idea of SSD-LLaMA to MoE inference: keep routed experts that do not fit in VRAM and host RAM on an NVMe SSD, load only the experts selected by the router, and use Expert Pack layout, direct I/O, pinned staging, asynchronous H2D transfers, and a GPU cache to turn SSD capacity into a practical backing tier.”（将 SSD-LLaMA 的核心思想引入 MoE 推理架构中）
SSD-LLaMA 第 1 节（Introduction - SGLang's SSD Expert Pack approach） “The central SSD-LLaMA idea is to manage SSD, RAM, and VRAM as a runtime-controlled storage hierarchy... The current SGLang path does not claim to reproduce every mechanism in the SSD-LLaMA paper. SGLang's implementation is GPU-centric: pinned host memory is a bounded transfer staging area, not a persistent host expert cache, and the current feature does not require the paper's CPU expert execution or lossless CUDA decompression.”（明确指出继承其多级分层存储思想，但划定了工程边界，摒弃了其 CPU 专家执行与 CUDA 压缩机制，改为轻量暂存流水线）
GGUF 规范 / GGML 第 2 节、第 3 节与第 9 节 分析了原生 GGUF 张量容器布局在面对直接 I/O 与连续专家切片时的结构性缺陷，并在实现中针对 Kimi-K3 研发了专门的 GGML Expert Pack 格式适配器（38 卷 Q2_K/Q3_K）。
Linux Direct I/O (O_DIRECT) 规范 第 2 节、第 4 节 引用 POSIX/Linux 底层标准契约，指出 O_DIRECT 对文件物理偏移、读取尺寸以及用户空间暂存区地址的严格对齐约束（4096 字节）。