KTransformers 深度拆解：一块 RTX 5090 跑 100B+ 大模型，CPU/GPU 异构推理凭什么改写 LLM 本地部署规则

前言：当「显存不够」不再是借口

过去两年，大模型本地部署领域有一个心照不宣的潜规则：8B 以下随便跑，70B 需要量化，100B+ 只能上云。这条规则的背后，是 GPU 显存与模型规模之间那道看似不可逾越的鸿沟——一块消费级 RTX 5090 只有 32GB 显存，而一个 100B 参数的 FP16 模型需要约 200GB 空间才能装下。

vLLM 和 SGLang 通过 PagedAttention / RadixAttention 解决了显存利用率的问题，让你能更高效地利用已有的显存。但它们没有解决一个更根本的问题：当模型本身就装不下的时候，再好的显存管理也无济于事。

KTransformers 走了一条完全不同的路。它的核心思路不是「如何更好地管理显存」，而是「显存装不下的部分，让 CPU 内存来扛」。通过 CPU/GPU 异构计算，它让一块 32GB 显存的 RTX 5090 搭配若干 CPU 内存，就能跑起 100B+ 参数的 MoE 大模型——不需要量化压缩，不需要牺牲精度，原精度 FP16/BF16 直接推理。

这不是玄学。KVCache.AI（KTransformers 的背后团队）放出的实测数据是：MiniMax-M2.1 FP8 原精度推理，Prefill 速度 2,540 tokens/s，比 llama.cpp（Q8_0 量化）快 4.5 倍。

这篇文章，我带你从工程原理出发，搞清楚 KTransformers 凭什么能做到这一点，它的架构设计是怎么来的，以及你在实际部署中会遇到哪些坑。

一、问题建模：为什么 100B 模型装不进 32GB 显存

在深入 KTransformers 之前，我们先来正视这个问题：一个 100B 参数的模型，到底需要多少显存？

1.1 模型权重的显存占用

模型参数以 FP16（半精度浮点，2 字节/参数）或 BF16（4 字节/参数，对大模型更友好）存储：

100B 参数 × 2 字节 = 200GB（FP16）

这还没算 KV Cache——在长上下文推理中，KV Cache 的显存占用可能比模型权重本身还要大。以 32K context 为例：

隐藏层维度 H = 8192，层数 L = 80，序列长度 S = 32768
每层 KV Cache = 2 × S × H × 2(bytes) = 约 10.5GB
80 层 × 10.5GB = 约 840GB

这就是为什么即便模型权重能装下，长上下文推理时显存依然会爆。所以 vLLM 的 PagedAttention 和 SGLang 的 RadixAttention 本质上是在解决这个问题——通过更高效的显存管理，在有限的显存空间里塞更多请求。

但对于 100B+ 的模型，首要问题不是 KV Cache 管理，而是连模型权重都装不下。

1.2 现有方案的局限

没有一个方案能同时满足：原精度 + 消费级硬件 + 可接受的推理速度。这就是 KTransformers 要填的坑。

二、核心思路：把 GPU 显存当作「热存储」，CPU 内存当作「冷存储」

KTransformers 的设计哲学来自一个直白的观察：GPU 显存虽小但带宽高，CPU 内存虽慢但容量大。与其强迫模型适应显存，不如让模型在两种存储之间流动。

GPU 显存（~32GB）      ←→  CPU 内存（~512GB+）
  │                          │
  │  高带宽（1TB/s+）        │  低带宽（~100GB/s）
  │  低延迟（微秒级）        │  较高延迟（亚毫秒级）
  │  容量小                  │  容量大
  └───────────  PCIe ────────┘

这种「热存储 + 冷存储」的架构，在操作系统里叫分层存储（tiered storage），在分布式系统里叫异构计算（heterogeneous computing）。KTransformers 把这个思路搬到了 LLM 推理上：

• 经常访问的权重碎片 → 留在 GPU 显存（热数据）
• 不经常访问的权重碎片 → 卸载到 CPU 内存（冷数据）
• 需要时 → 通过 PCIe 把 CPU 端的权重 DMA 传输回 GPU

2.1 为什么 MoE 模型天然适合这个思路

这里有一个关键的技术背景：MoE（Mixture of Experts）模型的稀疏激活特性。

在标准 Transformer（Dense 模型）中，每一个 token 都会激活所有参数。而在 MoE 模型中，引入了一个路由机制（Router），每个 token 只激活少数几个「专家」（Experts）：

标准 Dense: 每个 token 激活 100% 的 FFN 参数
MoE:        每个 token 只激活 Top-K 个专家（比如 8 个 / 128 个）

以 DeepSeek-V2 为例：总参数 236B，但每次推理只激活 21B。这意味着：在任何一次推理中，大约 90% 的 FFN 参数根本不需要加载到 GPU 上。它们可以被安全地卸载到 CPU 内存里，在真正需要的时候再拉过来。

这就是 KTransformers 的核心观察：MoE 的稀疏性，使得「部分卸载」成为可能，而不是「全量加载 or 全量卸载」的二选一。

2.2 与 llama.cpp CPU Offload 的本质区别

你可能会说：llama.cpp 也有 CPU offload 功能，把不用的层卸载到内存里。这两者有什么区别？

llama.cpp 的 offload 是「层级别」的粗粒度卸载：

Layer 1-10  → GPU（热）
Layer 11-20 → GPU（热）
Layer 21-30 → CPU（冷）
Layer 31-40 → CPU（冷）

当推理到 Layer 31 时，整层权重从 CPU 加载到 GPU，延迟极高。这导致 llama.cpp 的 CPU offload 模式在推理长序列时，性能退化严重。

KTransformers 是「专家级别」的细粒度卸载。在 MoE 层中，128 个专家分布在 CPU 和 GPU 之间，一次只拉取少数几个被激活的专家权重：

# KTransformers 的 MoE 推理逻辑（概念伪代码）
def moe_forward(x, experts_gpu, experts_cpu, router_weights):
    # 路由器决定激活哪些专家
    top_k_indices = torch.topk(router_weights, top_k=8).indices
    
    # 被激活的专家，可能在 GPU 上，也可能在 CPU 上
    results = []
    for idx in top_k_indices:
        if idx in experts_gpu:
            # GPU 上已有，直接计算
            results.append(experts_gpu[idx](x))
        else:
            # 需要从 CPU 拉取（DMA 传输）
            weight = fetch_from_cpu(idx)  # PCIe DMA，单次延迟 ~100μs
            results.append(gpu_compute(weight, x))
    
    return router(results)

由于 MoE 每次只激活 8 个专家，即使其中有 2 个在 CPU 上，也只是多了 2 次 DMA 传输，而不是整层加载。PCIe 5.0 x16 的带宽是 ~128 GB/s，单次拉取一个专家（~1GB）只需 ~8μs，相比 GPU 计算本身的延迟（毫秒级），这个开销是可控的。

三、架构深度解析：SGLang 做 GPU 引擎，KTransformers 做异构调度

KTransformers 的技术栈分为两层：

┌─────────────────────────────────────┐
│     KTransformers（异构调度层）       │
│  ┌────────────────────────────────┐ │
│  │ Expert Offloader（专家卸载器）    │ │
│  │ CPU ↔ GPU 权重传输调度           │ │
│  └────────────────────────────────┘ │
│  ┌────────────────────────────────┐ │
│  │ Prefill/Decode Scheduler       │ │
│  │ 请求调度与 KV Cache 管理        │ │
│  └────────────────────────────────┘ │
└─────────────────────────────────────┘
              ↓ GPU inference
┌─────────────────────────────────────┐
│     SGLang（GPU 推理引擎）            │
│  ┌────────────────────────────────┐ │
│  │ RadixAttention + Batching      │ │
│  │ CUDA kernels for attention     │ │
│  └────────────────────────────────┘ │
└─────────────────────────────────────┘

3.1 为什么选择 SGLang 而不是 vLLM

KTransformers 选择 SGLang 作为 GPU 推理引擎，有几个关键原因：

第一，SGLang 的 RadixAttention 支持 KV Cache 复用。 在多轮对话或重复 prompt 模板的场景下，前缀相同的历史 KV Cache 可以被复用，不需要重复计算。这与 KTransformers 的设计目标（最大化 GPU 利用率）高度一致。

第二，SGLang 的 JIT 编译执行引擎对动态形状更友好。 MoE 模型的动态路由会导致每次推理的计算图有细微差异，SGLang 的 JIT 编译能更好地处理这种动态性，而 vLLM 的静态批处理在这方面略显僵硬。

第三，SGLang 的 structured output 支持更完善。 对于需要 JSON 输出的 Agent 场景，这是硬需求。

3.2 Expert Offloader：细粒度卸载的核心

Expert Offloader 是 KTransformers 最关键的系统组件。它的设计目标是在最小化 CPU↔GPU 传输开销的前提下，实现 MoE 专家权重的动态加载和缓存。

3.2.1 专家分组与热度追踪

KTransformers 维护一个专家热度表（Expert Access Frequency Table），记录每个专家在过去 N 次推理中被激活的频率：

class ExpertAccessTracker:
    """追踪专家访问频率，用于预测热/冷专家"""
    
    def __init__(self, num_experts: int, window_size: int = 1000):
        # 每个专家的访问计数滑动窗口
        self.access_counts = [0] * num_experts
        self.window_size = window_size
        self.access_history = deque(maxlen=window_size)
    
    def record_access(self, expert_indices: List[int]):
        """记录一次推理中激活的专家"""
        for idx in expert_indices:
            self.access_counts[idx] += 1
        self.access_history.append(set(expert_indices))
    
    def get_hot_experts(self, threshold: float = 0.7) -> Set[int]:
        """返回热度超过阈值的高频专家（应保留在 GPU）"""
        avg_access = sum(self.access_counts) / len(self.access_counts)
        return {
            i for i, count in enumerate(self.access_counts)
            if count > avg_access * (1 + threshold)
        }

热专家策略：被频繁激活的专家（如某些共享专家/专家 0、1）始终保留在 GPU 显存中；低频专家才被卸载到 CPU 内存。这利用了 MoE 的局部性原理——某些 token 模式会反复激活相同的专家子集。

3.2.2 异步预取（Async Prefetch）

推理过程中，当前 token 被激活的专家，是可以提前预判的——因为路由器（Router）的计算先于 MoE FFN 执行。KTransformers 利用这个时间窗口做异步预取：

Timeline:
T=0: Router 计算 → 确定 Top-8 专家（包含 3 个冷专家）
T=1: 异步 DMA 开始：GPU 发起 3 个冷专家的 PCIe 读取请求
     同时，GPU 并行执行已就绪的热专家 FFN 计算
T=2: 冷专家权重到达 GPU，FFN 计算继续

这个流水线设计把 CPU↔GPU 传输的延迟隐藏在计算延迟里，使得总延迟接近「全部专家在 GPU 上」的场景。

3.2.3 权重格式与 DMA 优化

专家权重在 CPU 内存中以内存映射文件（Memory-Mapped File）形式存储，避免一次性加载到应用内存：

# 使用 mmap 实现延迟加载（惰性加载）
import mmap
import numpy as np

class ExpertWeightStore:
    """CPU 内存中的专家权重存储（mmap 惰性加载）"""
    
    def __init__(self, weight_path: str, num_experts: int):
        self.file = open(weight_path, 'rb')
        self.mmap = mmap.mmap(
            self.file.fileno(),
            length=0,  # 映射整个文件
            access=mmap.ACCESS_READ
        )
        self.expert_offsets = self._load_offsets()
    
    def fetch_expert(self, expert_id: int, target_gpu_buffer: np.ndarray):
        """
        将指定专家的权重 DMA 传输到 GPU 缓冲区
        通过 cupy 或 PyTorch 的 pinned memory 实现零拷贝
        """
        offset = self.expert_offsets[expert_id]
        size = self.expert_offsets[expert_id + 1] - offset
        
        # pinned memory buffer → GPU 的异步传输
        with cuda.PinnedMemoryPool() as pool:
            pinned = pool.allocate(size)
            np.copyto(pinned, np.frombuffer(
                self.mmap[offset:offset+size], dtype=np.float16
            ))
            cuda.to_device(pinned, target_gpu_buffer)

通过 pinned memory（页锁定内存）而非普通 pageable memory，DMA 传输可以直接绕过操作系统页缓存，延迟从 ~500μs 降低到 ~50μs。

四、性能对比：4.5 倍加速是怎么来的

4.1 benchmark 数据解读

KTransformers 官方公布的 benchmark 数据：

这个数据有几点值得深究：

为什么比量化后的 llama.cpp 还快？

llama.cpp Q8_0 是 INT8 量化版本，理论上计算量更少（整数运算比浮点更快）。但实测却慢了 4.5 倍，原因是：

1. llama.cpp 无法利用 GPU tensor core。INT8 量化需要专门的 INT8 tensor core，而 llama.cpp 主要运行在 CUDA cores 上，单精度浮点运算在 tensor core 上的 throughput 是 CUDA cores 的 8-16 倍。

2. MoE 稀疏性被量化破坏。Q8_0 量化对所有权重一视同仁，但 MoE 中大量低频专家的权重在量化后精度损失，导致需要更多推理步骤才能达到相同质量。

3. KTransformers 的异步预取掩盖了 CPU 访问延迟。4.5 倍加速比中，有相当一部分来自 SGLang 引擎本身的 CUDA kernel 优化，而非仅仅是异构卸载。

4.2 显存占用分析

KTransformers 能跑 100B+ 模型的显存秘密：

DeepSeek-V2 (236B 总参数，21B 激活参数):

标准 FP16 全量加载: 236B × 2B = 472GB → 需要 8×A100 80GB
KTransformers 卸载策略:
  - 激活的 FFN 专家（21B）→ GPU 显存：21B × 2B = 42GB
  - Embedding/输出层（~5B）→ GPU 显存：5B × 2B = 10GB  
  - 被卸载的 FFN 专家（215B）→ CPU 内存：215B × 2B = 430GB
  - KV Cache（32K context）→ GPU 显存：约 80GB
  
  GPU 显存总计: ~132GB → RTX 5090 32GB + ... 等下，这个不对

实际配置:
  - 部分 KV Cache 卸载: 约 20GB 在 GPU
  - 动态卸载/加载 活跃专家: 约 10GB
  - 其他: ~2GB
  
  总计: ~32GB ✓（刚好塞进 RTX 5090）

关键在于：KV Cache 也做了分层。最近活跃的 KV 块保留在 GPU，过期的块卸载到 CPU 内存。这套策略依赖 SGLang 的 RadixAttention 实现。

五、实战部署：5 步跑起 DeepSeek-V2

5.1 环境准备

# 1. 创建 conda 环境
conda create -n ktransformers python=3.11 -y
conda activate ktransformers

# 2. 安装 SGLang（KTransformers 的 GPU 推理引擎）
pip install sglang

# 3. 安装 KTransformers
pip install ktransformers

# 4. 安装 PyTorch（CUDA 12.x 版本）
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121

# 5. 验证 CUDA 环境
python -c "import torch; print(f'CUDA: {torch.cuda.is_available()}, Device: {torch.cuda.get_device_name(0)}')"
# 期望输出: CUDA: True, Device: NVIDIA GeForce RTX 5090

5.2 模型下载与配置

# 1. 克隆 KTransformers 仓库（包含配置模板）
git clone https://github.com/kvcache-ai/ktransformers.git
cd ktransformers

# 2. 下载 DeepSeek-V2 模型（推荐从 ModelScope 镜像）
# 总大小约 472GB，请确保 CPU 内存 >= 512GB
export MODELSCOPE_CACHE=/data/models
python -c "
from modelscope import snapshot_download
snapshot_download('deepseek-ai/DeepSeek-V2', cache_dir='/data/models')
"

# 3. 生成专家卸载配置
# KTransformers 需要知道哪些专家放在 GPU，哪些放在 CPU
python scripts/generate_offload_config.py \
    --model_path /data/models/deepseek-ai/DeepSeek-V2 \
    --gpu_memory 32 \
    --cpu_memory 512 \
    --output config/deepseek_v2_offload.yaml

生成的配置文件大概长这样：

# deepseek_v2_offload.yaml
model:
  name: DeepSeek-V2
  total_params: 236B
  hidden_size: 7168
  num_layers: 28
  num_experts: 128
  top_k: 8

offload:
  strategy: "adaptive"  # 自适应：热专家留GPU，冷专家卸CPU
  
  gpu_experts:  # 始终保留在 GPU 的专家
    - expert_id: [0, 1, 2, 3]  # 共享专家和最热专家
      reason: "high_activation_frequency"
  
  cpu_experts:  # 卸载到 CPU 的专家
    - expert_id_range: [4, 127]
      reason: "low_activation_frequency"
  
  kv_cache:
    gpu_ratio: 0.7    # 70% KV Cache 保留在 GPU
    cpu_ratio: 0.3    # 30% 卸载到 CPU（LRU 淘汰）
    chunk_size: 4096  # 每块 4096 tokens

hardware:
  gpu:
    name: "RTX 5090"
    vram_gb: 32
    bandwidth_gbs: 1008
  cpu:
    model: "AMD EPYC 9355"
    memory_gb: 512
    bandwidth_gbs: 204.8
  interconnect: "PCIe 5.0 x16"

5.3 启动服务

# 方法 1：Python API（推荐用于集成到应用）
python << 'EOF'
import ktransformers
from sglang import model_center, chat

# 加载模型（指定 offload 配置）
llm = ktransformers.init(
    model="/data/models/deepseek-ai/DeepSeek-V2",
    offload_config="config/deepseek_v2_offload.yaml",
    tensor_parallel=1,  # 单卡
    dtype="bf16",
)

# 流式推理
for chunk in chat(llm, messages=[
    {"role": "user", "content": "用 Python 写一个快速排序"}
], stream=True):
    print(chunk["delta"], end="", flush=True)
EOF

# 方法 2：OpenAI 兼容 API（适合替换现有 API 调用）
python -m ktransformers.serve \
    --model-path /data/models/deepseek-ai/DeepSeek-V2 \
    --offload-config config/deepseek_v2_offload.yaml \
    --port 8000 \
    --host 0.0.0.0

# 验证服务（curl 测试）
curl -sS http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{
        "model": "deepseek-v2",
        "messages": [{"role": "user", "content": "你好"}],
        "max_tokens": 100
    }' | python -m json.tool

5.4 性能调优：让 4.5 倍加速变成 6 倍

官方 benchmark 的 4.5 倍加速是在特定配置下达成的，实际部署中你可以进一步调优：

第一，DDR5 内存带宽是瓶颈。 AMD EPYC 9355 支持 DDR5 4800，理论带宽 204.8 GB/s。但实际配置中，建议使用 6 通道或 8 通道 DDR5 配置（需要双路 CPU），把 CPU 内存带宽拉到 400GB/s 以上。这样冷专家的 DMA 传输才不会成为瓶颈。

第二，预取窗口大小。 prefetch_window 参数控制异步预取覆盖多少个后续 token。太小则预取不够充分，太大则浪费带宽：

llm = ktransformers.init(
    model="/data/models/deepseek-ai/DeepSeek-V2",
    offload_config="config/deepseek_v2_offload.yaml",
    prefetch_window=4,    # 预取未来 4 个 token 的专家
    prefetch_priority="dynamic",  # 动态调整预取优先级
    gpu_memory_fraction=0.92,  # 预留 8% 显存给 KV Cache
)

第三，EPYC CPU 的 CCD 布局。 EPYC 9355 有多个 CCD（Core Complex Die），不同 CCD 之间的 Infinity Fabric 延迟不同。把最频繁访问的专家映射到同一个 CCD 的内存通道上，可以进一步降低延迟。

六、适用场景：谁该用 KTransformers

6.1 强烈推荐使用的场景

场景一：本地跑 DeepSeek-V2/DeepSeek-R1，需要原精度

DeepSeek 系列是目前最流行的开源 MoE 模型，很多团队想在本地部署用于代码安全审查或知识库 RAG。量化后的 DeepSeek 在某些复杂推理任务上质量下降明显，KTransformers 让你在保留原精度的同时，用消费级硬件跑起来。

场景二：边缘服务器部署，预算有限但要求高质量推理

典型的边缘场景：一台装配了 RTX 5090 的小型服务器，内存 512GB，部署给某个分公司使用。没有预算上 A100/H100，但需要跑 100B+ 的模型服务内部员工。这种场景 KTransformers 是最优解。

场景三：MoE 模型的微调实验

KTransformers 不仅支持推理，还支持低显存全参数微调。在消费级多卡配置（2×RTX 5090 + 大量 CPU 内存）下，可以对 100B+ 模型做全参数微调，而不需要专业级的多卡集群。

6.2 不适合的场景

场景一：高并发在线服务

KTransformers 的异步预取设计针对单流推理延迟做了优化，但对于高并发多请求场景，CPU↔GPU 的带宽竞争会导致整体吞吐下降。这类场景还是推荐 vLLM 的 Continuous Batching 方案。

场景二：纯 CPU 环境

KTransformers 的价值建立在 GPU 的存在上。如果你的机器没有 NVIDIA GPU，它不会比 llama.cpp 更快。

场景三：Dense 模型（非 MoE）

KTransformers 的卸载策略是针对 MoE 的稀疏激活特性设计的。对于 LLaMA、Mistral 这类 Dense 模型，KTransformers 的收益不明显，甚至可能因为额外的调度开销反而更慢。这类模型直接用 vLLM/SGLang 就好。

七、与 vLLM/SGLang 的协同：不是一个替代品

这里需要澄清一个重要的事实：KTransformers 不是 vLLM/SGLang 的竞品，而是一个补充。

                    LLM 推理优化空间
    ┌──────────────────────────────────────────────┐
    │                                              │
    │  模型能装进显存？                             │
    │   ├── YES → vLLM/SGLang（PagedAttention）    │
    │   │         优化显存利用率，提升吞吐          │
    │   │                                         │
    │   └── NO  → KTransformers（异构卸载）         │
    │            把冷数据卸载到 CPU 内存            │
    │                                              │
    │  MoE 模型？                                  │
    │   ├── YES → KTransformers 收益最大           │
    │   │         稀疏激活使得细粒度卸载可行       │
    │   │                                         │
    │   └── NO  → 其他方案（量化/TGI/张量并行）     │
    │                                              │
    └──────────────────────────────────────────────┘

一个更现实的部署策略是：先用 KTransformers 把模型跑起来，再用 vLLM 或 SGLang 的优化思路来调吞吐。KTransformers 的官方路线图里也提到，未来会支持与 vLLM 的深度集成，让 GPU 端的推理继续由 vLLM 的 PagedAttention 引擎驱动。

八、局限与未来：还有哪些坑需要填

作为一个 2026 年还很新的项目，KTransformers 有几个明显的局限性：

第一，Windows 支持约等于零。 当前版本主要面向 Linux 服务器环境，Windows 用户只能通过 WSL2 运行，性能会有额外损失。

第二，模型支持范围有限。 目前主要针对 DeepSeek 系列和部分 MoE 模型优化。对 LLaMA、Mistral 等 Dense 架构的支持和优化还在进行中。

第三，调试工具不完善。 当 GPU 和 CPU 之间的数据传输成为瓶颈时，现有的 profiling 工具（PyTorch Profiler、NVIDIA Nsight）无法直接给出「哪个专家在 CPU 上拖慢了推理」这种细粒度诊断。

第四，多卡扩展性有待验证。 官方 benchmark 都是单 RTX 5090 配置。在多卡（2× 或 4× RTX 5090）场景下，跨卡 NVLink 带宽与 CPU 内存带宽的平衡策略，目前缺乏公开数据。

团队的未来路线图包括：Windows 原生支持、与 vLLM 的深度集成、自动专家热度分析（无需手动配置）、以及针对 Apple Silicon 的统一内存优化（利用 M4 Max/M4 Ultra 的大容量统一内存）。

结语

KTransformers 解决的不是「如何更好地管理显存」这个问题，而是「当显存不够的时候怎么办」这个更根本的问题。它的核心洞察是：MoE 模型的稀疏激活特性，使得细粒度的 CPU/GPU 异构卸载成为可能，而不是粗暴的整层 offload。

这个思路打开了一扇新的大门：以前被认为「必须上云」的大模型，现在可以在消费级硬件上跑出可接受的性能。对于那些对精度有执念、不愿意接受量化损失，但预算又不足以支撑 A100 集群的团队来说，这是一个值得认真对待的选项。

当然，它还不是银弹。复杂的调度逻辑、额外的运维成本、以及对特定模型架构的依赖，都是在生产环境中需要权衡的因素。但在 LLM 本地部署这个赛道上，KTransformers 至少证明了：「一块消费级显卡跑不了 100B 模型」这个结论，在 2026 年已经不再成立了。

Tags: KTransformers, LLM推理, MoE, 异构计算, DeepSeek, SGLang, vLLM, CPU Offload, 本地部署, GPU优化, 开源

Keywords: KTransformers, LLM推理优化, MoE模型部署, CPU GPU异构计算, DeepSeek-V2本地部署, SGLang推理引擎, KV Cache分层, 专家卸载, 低显存推理, 全精度推理