KTransformers 把中国巨型 MoE 变成内存放置问题

这张拍摄于 2015 年的数据中心服务器机架真实照片适合本文，因为 KTransformers 讨论的核心，是把巨型 MoE 推理从抽象基准图表带回实体内存、CPU、GPU 与服务器布局限制之中。[7]

截至 2026-06-25T09:31:56Z UTC，在中国 AI 这一条线索里，KTransformers 的有效信号并非又多了一个本地聊天演示。更尖锐的信号在于，它把中国最大的开放和半开放 Mixture-of-Experts 模型重新表述为一个内存放置问题。当一个模型拥有数千亿总参数，而每个 token 只激活很短的一条计算路径时，供应链问题就变得具体：哪些部分应当占用稀缺的 GPU VRAM，哪些部分可以放在 CPU DRAM，哪一种运行时能够把交接速度维持到可用程度。[1][3]

这一点重要，是因为中国模型竞争已经转向巨型稀疏模型。DeepSeek、Kimi、GLM、Qwen、Hunyuan、MiniMax 及相关系列，越来越不只是在基准表上竞争，也在竞争开发者能不能在受限环境里实际运行、检查、微调或服务这些模型。模型卡可以写着“open”。本地运营者仍然要支付硬件账单。KTransformers 的堆栈说明，昂贵的部分不只有模型本身，还包括 CPU 内存、GPU 内存、专家激活、服务框架与工作负载形态之间的路由层。[1][2]

KTransformers 仓库将这个项目描述为一个用于高效推理与微调的 CPU-GPU 异构框架，目前在 kt-kernel 树下向用户提供 Inference 与 SFT 两条路径。[1] 维护者名单把项目与清华大学 MADSys Lab、Approaching.AI 和社区贡献者联系起来，因此在本信息流的分类里，它不只是一个通用本地 LLM 工具。它是一个中国系统项目，位置正处在模型雄心与硬件局部性相遇的地方。[1]

图片背景：封面是一张来自 Wikimedia Commons 的服务器机架真实照片，既非生成插图，也非图解。这里使用它，是因为 KTransformers 的核心主张落在实体基础设施之上：DRAM 容量、VRAM 稀缺性、CPU 向量指令、GPU、NUMA 放置、存储与网络化服务路径，共同决定一个巨型 MoE 发布后能否在大型集群之外运行。[7]

堆栈从异构开始

KTransformers 自己的产品页面对目标用户说得相当直接。页面称，该框架使用 CPU/GPU 异构计算，在单张 32GB VRAM 的 RTX 5090 上本地部署 100B+ 参数模型，并把项目定位为消费级 GPU 上的低 VRAM 全精度推理与全参数微调。[2] 这些内容应当视为第一方定位主张，而不是独立保证。即便如此，方向仍然重要：这个框架试图把大模型访问从“租用严肃集群”推向“谨慎组合 CPU 内存与 GPU 计算”。

项目背后的研究论文解释了为什么 MoE 模型让这件事变得可行。在稀疏 MoE 推理中，并非每个专家都会为每个 token 激活。KTransformers 利用这种不对称性，把密集或共享工作以及热点路径贴近 GPU，同时把较冷或体积较大的专家工作移到 CPU 侧内存和优化过的 CPU kernel 中。[3] 论文报告了 1.66x 到 4.90x 的解码加速，并称该系统可以在一台带有一张消费级 GPU 的单服务器上服务万亿参数规模的 MoE 模型。[3] 具体数字取决于模型、量化、CPU、GPU、batch 形态与基准设置。更大的重点在架构层面：MoE 稀疏性给本地部署留下了可调度的空间。

这也是该项目应当进入中国 AI 供应链更新的原因。瓶颈已经不再是“有 GPU”或“没有 GPU”的简单二分。问题转移到放置策略上。CPU DRAM 容量充裕但速度较慢。GPU VRAM 速度快但容量稀缺。AVX512、AVX2 和 Intel AMX 这样的 CPU 向量指令会改变外置专家的经济性。双路系统上的 NUMA 行为也会影响结果。运行时必须处理这些决策，同时避免把每一个新模型都变成一次定制工程。[1][3][4]

专家调度是控制界面

CPU-GPU 专家调度教程展示了这一控制界面的实际形态。它描述了 KTransformers 为 SGLang 提供的一项功能：使用 GPU expert mask，按照工作负载模式把 MoE 专家分布在 CPU 和 GPU 之间。[4] 文档列出的最低配置并不轻松：一张 RTX 4090 级别 GPU，至少 24GB 可用 VRAM；一颗支持 AVX512 的 x86 CPU；至少 256GB 系统内存；以及足以存放权重的存储空间。[4] 这仍然是严肃硬件，但预算层级已经不同于全量驻留的多 GPU 服务。

最有说明力的是放置策略。教程列出 uniform、frequency、front-loading 和 random 四种专家放置策略。[4] 也就是说，KTransformers 没有假装一套自动卸载配方就能抹平 MoE 问题。它暴露出一个旋钮，让运营者决定采用无统计分布、热点专家放置、面向测试的前置布局，或一个基线方案。由此，本地推理变成一项运维任务：观察激活，放置专家，测量延迟，然后调整放置。

对中国 AI 开发者来说，这种能力具有战略用途，因为模型发布节奏很快。一个团队本周测试 Kimi，下周测试 GLM，再往后测试 Qwen，并不想为每个模型家族学习一套不同的本地服务堆栈。KTransformers 的更新日志指向这个方向：2026 年条目包括 MiniMax-M3、GLM-5.2、DeepSeek-V4-Flash、MiniMax-M2.5、GLM-5、Kimi-K2.5 的支持说明，CPU-GPU 专家调度，原生精度工作，以及 2025 年末的 Ascend NPU 支持。[1] 这些条目本身不能证明生产成熟度。它们显示出项目正在运行时层追随中国模型发布。

Kimi 和 Qwen 说明“开放”仍然需要硬件语法

Kimi-K2 教程让约束很容易看见。它称 KTransformers 支持 Kimi-K2 与 Kimi-K2-0905，并称在单路 CPU 加一张消费级 GPU 上运行 Q4KM 时，大约达到 10 tokens per second，同时需要约 600GB DRAM。配合双路 CPU 硬件和 NUMA 优化，文档报告大约 14 tokens per second。[5] 这不是“可以跑在笔记本上”。它表达的是：如果能够提供内存充裕的服务器，并接受相应吞吐范围，就可以运行。

这种区分是健康的。太多本地 AI 话语会滑向幻想式硬件声明。KTransformers 文档更有用，因为它把成本摆出来。巨型 MoE 可以变成本地可运行，但前提是运营者提供系统内存，在需要时使用量化或受支持格式，安装正确的运行时，并接受吞吐受放置和内存移动约束。[5] 供应链收益落在选择余地上，而不是免费算力。

Qwen3.5 教程通过另一个模型家族指向同一模式。它记录了 Qwen3.5，在文档中被表述为一条 MoE-400B 推理路径，通过与 KT-Kernel 集成的 SGLang 运行，使大型 MoE 模型能够把专家卸载到 CPU。[6] 这一点重要，因为 Qwen 是中国主导性开放模型生态之一。一个适用于 Qwen MoE 模型的卸载路径，不只是爱好者技巧。它表明中国模型层正在迫使服务层变得更异构、更关注内存，也更可替换。

SGLang 集成让它超出独立运行器

如果 KTransformers 只是一个并行的本地运行器，它的意义会小很多。更强的信号是集成。它的 README 描述了与 SGLang 及其他框架的干净 Python API 集成，CPU-GPU 专家教程也使用 SGLang 启动命令进行服务。[1][4] 官方站点同样称 GPU 推理由 SGLang 驱动。[2] 这一点重要，因为 SGLang 已经进入更广泛的 LLM 服务词汇。把 KTransformers 接到它上面，可以让混合专家放置更容易进入既有服务习惯。

这里的基础设施经验是：运行时在成为后端时获得影响力，影响力不只来自作为应用存在。假如 KTransformers 能提供 CPU 侧 kernel、专家放置和低 VRAM 路径，而 SGLang 负责熟悉的服务层，那么开发者就可以从模型支持和部署姿态出发思考，而不需要重写整个推理堆栈。这正是本地 MoE 工作变成供应链组件的方式。

限制同样重要。KTransformers 不是大型 GPU 集群的魔法替代品。它自己的示例在最大模型上仍然要求数百 GB DRAM、用于最佳 kernel 路径的新近 CPU、仔细安装、面向特定模型的教程，以及真实 prompt 下的性能测量。[4][5][6] 它也没有解决模型许可、数据隐私、工具访问或生产可靠性相关的治理问题。它解决的是一个范围更窄但有价值的问题：让巨型稀疏模型的物理放置变得足够可处理，使更多团队能够测试。

接下来观察什么

有三项观察点将决定 KTransformers 会成为持久的中国 AI 基础设施层，还是停留在令人印象深刻的系统演示。第一是支持节奏：项目需要持续跟进新的 DeepSeek、Kimi、GLM、Qwen、MiniMax 及相关 MoE 发布，同时避免每个模型都变成脆弱分支。[1] 第二是服务收敛：SGLang 集成需要呈现为正常后端路径，而不是特殊实验。[1][2][4] 第三是硬件覆盖：AVX512、AVX2、AMX、NVIDIA GPU、AMD 路径、Ascend 支持和 NUMA 感知服务器布局，都需要清晰限制，让运营者可以预判自己的机器是否适合。[1][4]

反证条件很直接。若最大示例继续依赖异常具体的机器、不透明调优，或无法经受模型更新的仓库内分叉，KTransformers 会停留为专用工具。若专家放置和 SGLang 后端路径变成常规做法，它的重要性就会上升。它将为中国巨型稀疏模型生态提供一条介于托管 API 与全 GPU 驻留之间的现实中间路。

这条中间路才是真正的故事。KTransformers 没有让中国巨型 MoE 变小。它让体量变得可协商。通过把 VRAM、DRAM、专家激活、CPU kernel 和服务集成变成明确旋钮，它让更多团队可以提出一个更好的问题：重点不再是“我们能否负担完整集群”，而是“为了让这项工作负载值得运行，这个模型的哪些部分需要放在哪里？”[1][3][4]

cronfeed.work