24G 显卡跑 35B MoE：Qwen3.6 的显存压缩极限

架构解析：24G 显卡跑 35B MoE 的显存压缩极限

在 24G 显卡上运行 35B 参数的 MoE 模型，显存压缩的极限在哪里？Qwen3.6 的 MoE 架构和 llama.cpp 的量化支持，让这一目标成为可能。

很多人对 MoE（混合专家）架构有一个致命的误解：既然每次推理只激活部分专家，那显存占用是不是也变小了？答案是绝对不行。这就好比一个拥有 35 名厨师的餐厅，虽然每桌客人只由 3 名厨师同时掌勺（稀疏激活降低了计算量），但所有 35 名厨师都必须站在厨房里待命（权重必须完整驻留显存）。如果厨师不在场，客人点菜时就无法响应。因此，MoE 模型的显存占用取决于总参数量，而非激活参数量。

对于主角模型 qwen3.6-35b-a3b，其总参数量为 35B。在 FP16 精度下，权重体积约为 70GB，这远超任何消费级显卡的极限。要将其塞进本地硬件，唯一的出路是量化压缩。

量化压缩：从 70GB 到 22GB 的跨越

量化是将高精度浮点数转换为低精度整数的过程。在 llama.cpp 生态中，GGUF 格式提供了多种量化级别，如 Q4_0、Q5_K_M、Q8 等。其中，Q4_K_M 是平衡精度与体积的黄金标准。

根据规格数据，qwen3.6-35b-a3b 在 Q4_K_M 量化后，模型权重体积约为 22.0GB。这是一个关键的物理锚点。它意味着，无论你的显卡多强，如果显存装不下这 22.0GB 的权重，模型就无法加载。

这里必须澄清一个常见的框架混淆：
– GGUF 格式（包含 Q4_K_M 等量化）：主要配合 llama.cpp、Ollama 或 MLX 使用。
– safetensors 格式：主要配合 vLLM、SGLang 使用。
– bitsandbytes：这是 transformers 库中的动态量化后端（NF4/FP4），用于 safetensors 格式，不能直接加载 GGUF 的 Q4_K_M 文件。

因此，若要在本地部署 Q4_K_M 量化的 Qwen3.6 35B，llama.cpp 或基于其底层的 Ollama 是最自然的选择。

显存预算：24G 显卡的残酷现实

现在，让我们回到标题中的核心矛盾：24G 显卡。

我们已知 Q4_K_M 权重为 22.0GB。除了权重，推理还需要 KV Cache（键值缓存）和系统开销。
– 系统开销：约 1.5 GB（用于 CUDA 上下文、临时缓冲区等）。
– KV Cache：取决于上下文长度。以 4K 上下文为例，KV Cache 约为 0.3 GB。

让我们计算一下 4K 上下文下的总显存占用：
$$ \text{总占用} = \text{权重} (22.0\text{GB}) + \text{KV Cache} (0.3\text{GB}) + \text{系统开销} (1.5\text{GB}) = 23.8\text{GB} $$

23.8GB > 16GB。

这意味着，24G 显卡无法完整加载 Q4_K_M 量化的 Qwen3.6 35B 模型。即使你将所有层都卸载到 GPU（-ngl 999），显存也会溢出。llama.cpp 虽然支持 CPU+GPU 混合推理，但将 22GB 权重的大部分放在 CPU 上，会导致推理速度极慢，失去部署意义。

那么，24G 显卡能承载的模型规模上限是多少？
– 如果坚持使用 Q4_K_M 量化，24G 显卡适合部署总参数量在 7B-8B 左右的模型（权重约 4-22GB，加上 KV Cache 和开销，总占用在 6-8GB 左右，留有充足余量）。
– 对于 35B 的 MoE 模型，24GB 显卡（如 RTX 4090 / 3090 / 5090）是最低门槛。

让我们看 24GB 显卡在 4K 上下文下的表现：
– 总占用：23.8GB
– 剩余空间：0.5 GB – 23.8GB = -24GB

这 22GB 的剩余空间极其紧张，几乎无法扩展上下文长度。如果上下文增加到 8K，KV Cache 升至 0.7 GB，总占用变为 24.2GB，超出 24GB 显卡容量。因此，在 24GB 显卡上运行 Qwen3.6 35B Q4_K_M，必须严格限制上下文长度在 4K 以内，或者使用 KV Cache 量化技术来压缩 KV 体积。

如何评估你的硬件？

检查显卡显存：
< 16GB：无法运行 Q4_K_M 35B 模型。
16GB：无法运行 Q4_K_M 35B 模型（总占用 23.8GB > 16GB）。
24GB：可运行，但仅限 4K 上下文，剩余空间仅 0.2 GB。
32GB：可运行 4K-16K 上下文，剩余空间充足（4K 剩余 0.2 GB）。
48GB+：可运行长上下文（32K+），体验流畅。
选择量化级别：
Q4_K_M：推荐。体积 22.0GB，精度损失小，适合 24GB+ 显卡。
Q5_K_M：体积更大（约 26-28GB），需要 32GB+ 显卡。
Q8：体积 35GB，需要 48GB+ 显卡，精度接近 FP16。
框架选择：
llama.cpp：最灵活，支持 -ngl 控制 GPU 层数，适合手动调优。
Ollama：基于 llama.cpp，开箱即用，适合快速部署。
vLLM/SGLang：主要处理 safetensors 格式，若需使用 GGUF，需确认版本支持，但主路径仍是 safetensors。

总结

Qwen3.6 的 35B MoE 架构在 24G 显卡上无法以 Q4_K_M 量化完整运行。显存压缩的极限在于：权重必须完整驻留，而 Q4_K_M 的 22.0GB 权重加上系统开销和 KV Cache，总占用至少 23.8GB。因此，24GB 显卡是运行该模型的最低门槛，且需严格控制上下文长度。对于追求更高上下文或更流畅体验的用户，32GB 或 48GB 显卡是更合理的选择。

下一章，我们将深入探讨如何在 24GB 显卡上优化 KV Cache，以突破 4K 上下文的限制，实现更长的对话能力。

部署环境与前置条件：llama.cpp 的编译与配置

在确认了 24GB 显卡是运行 Qwen3.6-35B-A3B 的最低硬件门槛后，接下来的挑战是如何让 llama.cpp 正确“认识”并高效利用这块显卡。很多部署失败并非源于模型本身，而是编译选项缺失或运行时参数配置不当。对于 MoE 架构而言，由于所有专家权重必须完整驻留显存，任何配置上的疏忽都可能导致显存溢出或性能断崖式下跌。

编译阶段：启用 CUDA 与 FP16 支持

llama.cpp 默认编译可能仅包含 CPU 支持，或者 CUDA 支持不完整。为了确保 Q4_K_M 量化模型在 NVIDIA 显卡上获得最佳性能，必须在编译时显式启用 CUDA 后端，并开启 FP16 支持。FP16 支持对于 MoE 模型尤为重要，因为它能显著减少中间计算结果的显存占用，从而为 KV Cache 留出更多空间。

以下是标准的编译指令。请注意，-DGGML_CUDA 是启用 GPU 加速的核心开关，而 -DGGML_CUDA_F16 则允许内核使用半精度浮点数，这在 24GB 显存的紧张环境下是提升吞吐量的关键。

bash
# 清理旧构建
make clean

# 编译 llama.cpp，启用 CUDA 和 FP16 支持
# 假设 CUDA 安装在 /usr/local/cuda
CMAKE_ARGS="-DGGML_CUDA=ON -DGGML_CUDA_F16=ON" make -j

如果编译过程中出现关于 cublas 或 cudnn 的警告，通常不影响基本功能，但建议确保系统已安装对应版本的 CUDA Toolkit。编译完成后，生成的 llama-cli 和 llama-server 二进制文件将具备完整的 GPU 推理能力。

运行时配置：层数卸载与上下文控制

编译完成后，运行时参数的配置决定了模型如何映射到硬件上。这里有一个常见的误区：--no-mmap 参数常被误解为“强制将模型加载进显存”，但实际上它只是禁用了内存映射（Memory-Mapped Files），让操作系统直接将权重文件读入 RAM，而非通过虚拟内存页表。对于 MoE 模型，我们真正需要控制的是哪些层被卸载到 GPU。

使用 --n-gpu-layers（或简写 -ngl）参数，我们可以指定卸载到 GPU 的层数。对于 Qwen3.6-35B-A3B，由于总权重约 22.0GB，而 24GB 显卡在扣除 1.5GB 系统开销后，剩余空间非常紧张。如果我们将所有层都卸载到 GPU，加上 KV Cache，极易超出显存限制。

根据【显存预算权威表】，在 4K 上下文下，总占用为 23.8GB。这意味着在 24GB 显卡上，我们几乎没有余量。因此，策略是：尽量多卸载层到 GPU，但保留少量层在 CPU 上作为缓冲，或者严格限制上下文长度。然而，由于 MoE 的特性，部分卸载可能导致性能下降，因为专家权重需要在 CPU 和 GPU 之间频繁传输。

更稳妥的做法是，先尝试将所有层卸载到 GPU，并设置较小的上下文长度，观察显存占用情况。如果发生 OOM（Out of Memory）错误，则逐步减少 --n-gpu-layers 的值。

bash
# 示例：运行 Qwen3.6-35B-A3B Q4_K_M 模型
# 假设模型文件名为 qwen3.6-35b-a3b-q4_k_m.gguf
# 初始尝试：所有层卸载到 GPU，上下文设为 4K
./llama-cli -m qwen3.6-35b-a3b-q4_k_m.gguf \
            --n-gpu-layers 999 \
            --ctx-size 4096 \
            --no-mmap \
            --threads 8

注意：--no-mmap 在此处用于确保权重直接加载到内存，避免潜在的页错误延迟，但这并不改变显存占用的物理事实。如果 24GB 显卡在 4K 上下文下仍报 OOM，说明系统开销或 KV Cache 的实际占用略高于理论值，此时应尝试将 --n-gpu-layers 降低至 95% 左右，或进一步减小 --ctx-size。

验证部署：显存监控与性能基准

部署成功后，第一步是验证显存占用是否符合预期。使用 nvidia-smi 实时监控显存使用情况，确保其稳定在 23.8GB 左右（4K 上下文）。如果显存占用显著高于此值，可能是 KV Cache 分配过大或存在其他进程占用。

bash
# 在另一个终端监控显存
watch -n 1 nvidia-smi

接下来，进行简单的性能测试。对于 Qwen3.6-35B-A3B，实测吞吐在低并发下约为 75.4 t/s，高并发下可达 1304.6 t/s。在本地单用户场景下，我们关注的是单流吞吐。如果实测吞吐远低于 75.4 t/s，可能意味着部分层未能有效卸载到 GPU，或 CPU 与 GPU 之间的数据传输成为瓶颈。

此时，应检查 --n-gpu-layers 的设置。如果降低层数后吞吐提升，说明之前的配置导致了过多的 CPU-GPU 数据交换。反之，如果降低层数后吞吐下降，则说明 GPU 计算能力未被充分利用，应尝试增加层数。

常见陷阱与规避

混淆 --no-mmap 与 GPU 卸载：再次强调，--no-mmap 不控制 GPU 层数。如果只设置 --no-mmap 而不设置 --n-gpu-layers，模型可能完全在 CPU 上运行，导致性能极低。
忽视 KV Cache 量化：默认 KV Cache 使用 FP16，占用较大。如果上下文长度超过 4K，建议启用 KV Cache 量化（如 --cache-type-k q8_0），以显著降低显存占用，从而在 24GB 显卡上支持更长的上下文。
未清理旧进程：如果之前有未完全退出的 llama.cpp 进程，它们可能仍占用显存，导致新进程无法启动。务必使用 pkill llama-cli 或检查 nvidia-smi 中的进程列表。

通过正确编译 llama.cpp 并精细调整运行时参数，我们可以在 24GB 显卡上稳定运行 Qwen3.6-35B-A3B。然而，4K 上下文的限制对于许多实际应用场景来说仍然偏短。下一章，我们将深入探讨如何在 24GB 显卡上优化 KV Cache，以突破 4K 上下文的限制，实现更长的对话能力。

量化策略：Q4_0 与 Q5_K_M 的显存与性能权衡

在本地部署 Qwen3.6-35B-A3B 时，量化级别的选择直接决定了你的显卡能否“装得下”以及跑得“快不快”。这里存在一个经典的工程权衡：更低的比特数意味着更小的文件体积和更少的显存占用，但同时也伴随着更高的精度损失。对于 MoE（混合专家）架构而言，这一点尤为关键，因为无论激活多少专家，全部专家权重必须完整驻留显存。这意味着，显存占用由总参数量决定，而非激活参数量。

显存占用的物理边界

首先，我们要明确 Q4_0 和 Q5_K_M 在显存上的差异。Q4_K_M 是 GGUF 格式中一种平衡性较好的量化方案，其权重约为 22.0GB。而 Q4_0 是一种更激进的 4-bit 量化，通常比 Q4_K_M 更小；Q5_K_M 则提供了更高的精度，体积略大。

然而，我们必须面对一个残酷的物理事实：Q4_K_M 量化后的 Qwen3.6-35B-A3B 权重约为 22.0GB。根据显存预算权威表，加上 1.5GB 的系统开销和 4K 上下文的 22GB KV Cache，总占用约为 23.8GB。

这意味着，24GB 显卡（如 RTX 4060 Ti 16G）根本无法完整加载 Q4_K_M 甚至 Q4_0 的 Qwen3.6-35B-A3B。
* 24GB 显卡在 4K 上下文下的剩余空间为 -7.8GB（即缺口 7.8GB）。
* 即使使用更小的 Q4_0，其权重虽略小于 22.0GB，但依然远超 24GB 显卡的容量上限。

因此，本章的核心论点需要修正为：在 24GB 显卡上，Q4_0 和 Q5_K_M 均无法完整驻留显存，必须依赖 CPU+GPU 混合推理（Offloading）。而在 24GB 显卡（如 RTX 4090/3090）上，Q4_K_M 是可行的基线，Q5_K_M 则可能因显存不足而需要降级或缩短上下文。

24GB 显卡：混合推理的无奈与技巧

如果你只有 24GB 显卡，想要运行 Qwen3.6-35B-A3B，唯一的路径是 llama.cpp 的 CPU+GPU 混合推理。此时，-ngl（GPU Layers）参数变得至关重要。

Q4_0 vs Q5_K_M 在混合推理中的表现：
Q4_0：由于权重更小，你可以将更多的层卸载到 GPU（-ngl 值更高），从而减少 CPU 参与计算的层数，提升整体吞吐。
Q5_K_M：权重更大，留给 GPU 的空间更少，必须将更多层留在 CPU 上。CPU 的内存带宽通常远低于 GPU，这会导致推理速度显著下降。

代码示例：24GB 显卡上的混合推理配置

# 假设使用 llama.cpp 的 llama-cli
# 注意：-ngl 控制卸载到 GPU 的层数，需根据实际显存调整
# 24GB 显卡，Q4_0 权重约 20-21GB（估算），需大量 CPU 参与

# 尝试将尽可能多的层放入 GPU，但需监控 nvidia-smi
# 如果 OOM，减少 -ngl 值
llama-cli -m qwen3.6-35b-a3b-q4_0.gguf \
          -ngl 20 \
          -c 4096 \
          -t 8 \
          --no-mmap

-ngl 20：这是一个起始值，需根据 nvidia-smi 监控显存占用动态调整。如果显存溢出，降低此值。
--no-mmap：禁用内存映射，强制权重直接读入内存，避免页错误导致的延迟，但在混合推理中需谨慎使用，因为它可能增加 RAM 压力。

性能影响：
在 24GB 显卡上，Q4_0 的混合推理速度通常优于 Q5_K_M，因为 Q4_0 允许更高的 GPU 卸载比例。然而，两者的绝对速度都受限于 CPU 内存带宽，远低于 24GB 显卡上的纯 GPU 推理。

24GB 显卡：Q4_K_M 的甜蜜点与 Q5_K_M 的困境

对于 24GB 显卡（RTX 4090/3090），Q4_K_M 是标准配置。
* Q4_K_M：总占用 23.8GB（4K 上下文），剩余 0.2 GB。这非常紧张，但可行。
* Q5_K_M：权重略大于 22.0GB（例如 24-25GB），加上系统开销和 KV Cache，总占用将超过 24GB。
* 在 4K 上下文下，Q5_K_M 的总占用可能达到 25-26GB，导致 24GB 显卡无法运行，24GB 显卡也面临 OOM 风险。
* 若强行运行 Q5_K_M，必须缩短上下文（如 2K）或启用 KV Cache 量化，但这会牺牲长对话能力。

代码示例：24GB 显卡上的 Q4_K_M 纯 GPU 推理

# 24GB 显卡，Q4_K_M 权重 22.0GB
# 4K 上下文，KV Cache 0.3GB，系统开销 1.5GB，总占用 23.8GB
# 剩余 0.5 GB，非常紧张，建议监控显存

llama-cli -m qwen3.6-35b-a3b-q4_k_m.gguf \
          -ngl 999 \
          -c 4096 \
          -t 8 \
          --no-mmap

-ngl 999：将所有层卸载到 GPU，实现纯 GPU 推理。
-c 4096：4K 上下文，KV Cache 占用 0.3 GB。

性能对比：
* Q4_K_M：在 24GB 显卡上，可实现纯 GPU 推理，吞吐稳定在 75.4-1304.6 t/s（取决于并发和硬件）。
* Q5_K_M：在 24GB 显卡上，若无法完整加载，则需回退到混合推理，速度大幅下降。若通过缩短上下文勉强加载，精度提升有限，但显存风险高。

如何选择？

24GB 显卡：
推荐 Q4_0：更小的权重允许更高的 GPU 卸载比例，混合推理速度更快。
避免 Q5_K_M：权重过大，导致更多层留在 CPU，速度显著下降，且精度提升在混合推理中不明显。
预期：速度受 CPU 内存带宽限制，远低于 24GB 显卡。
24GB 显卡：
推荐 Q4_K_M：标准配置，纯 GPU 推理，性能稳定，显存占用 23.8GB（4K 上下文）。
谨慎 Q5_K_M：显存紧张，可能 OOM。若必须使用，需缩短上下文或启用 KV Cache 量化，但收益有限。
32GB+ 显卡：
推荐 Q5_K_M 或 Q8：显存充足，可加载更高精度量化，获得更好的精度和性能平衡。

测试与验证

要验证你的选择，建议使用 nvidia-smi 监控显存占用，并使用 llama-bench 测试推理速度。

# 测试 Q4_K_M 在 24GB 显卡上的性能
llama-bench -m qwen3.6-35b-a3b-q4_k_m.gguf \
            -ngl 999 \
            -c 4096 \
            -p 128 \
            -n 128

-p 128：提示长度 128 tokens。
-n 128：生成 128 tokens。
输出：将显示 prompt processing 和 token generation 的速度（t/s）。

通过对比不同量化级别的 llama-bench 结果，你可以直观看到 Q4_0 和 Q5_K_M 在速度上的差异，并结合 nvidia-smi 的显存占用，做出最适合你硬件和需求的选择。

下一章，我们将深入探讨如何在 24GB 显卡上优化 KV Cache，以突破 4K 上下文的限制，实现更长的对话能力。

推理优化：上下文长度与批处理大小的调优

在确定了 Q4_K_M 量化模型能“装进”显卡后，我们面临下一个挑战：如何跑得更快？在 24GB 显存的硬件限制下，上下文长度（Context Length）和批处理大小（Batch Size）是决定推理吞吐量的两个核心杠杆。这就像驾驶一辆载重有限的卡车，你需要决定是拉一车长距离的货物（长上下文），还是多跑几趟短途（高并发批处理），或者两者兼得但都要牺牲一部分负载。

上下文长度的显存代价

KV Cache（键值缓存）是 Transformer 模型推理时的“记忆体”，它的大小与序列长度成正比。对于 35B 的 MoE 模型，虽然激活参数少，但 KV Cache 的大小取决于注意力层数和头数，与激活参数量无关，因此不能指望“稀疏激活”来节省这部分显存。

根据显存预算权威表，Q4_K_M 权重占用 22GB，系统开销 1.5 GB。这意味着留给 KV Cache 的空间极其有限。
– 4K 上下文：KV Cache 占用 0.3 GB，总占用 23.8GB。
– 8K 上下文：KV Cache 占用 0.7 GB，总占用 24.2GB。
– 16K 上下文：KV Cache 占用 1.3 GB，总占用 24.8GB。

这里出现了一个关键矛盾：24GB 显卡无法容纳该模型的 4K 上下文。
查看显存预算表，24GB 显卡在 4K 上下文下的剩余空间为 -7.8GB，8K 为 -8.2GB。这意味着，如果你强行在 24GB 显卡上运行 35B Q4_K_M 模型并开启 4K 上下文，显存会直接溢出（OOM）。

⚠️ 重要修正与硬件建议：
前文提到“24G 显卡跑 35B”，这在物理上对于 Q4_K_M 量化（22GB 权重）是不成立的。22GB 权重 + 1.5GB 系统开销 = 1.5 GB，已经超过 24GB 显卡的总容量。
因此，本章的调优策略必须基于24GB 及以上的显卡（如 RTX 3090/4090/5090）。在 24GB 显卡上：
– 4K 上下文剩余 0.2 GB（极度紧张，几乎无余量）。
– 8K 上下文剩余 -0.2 GB（溢出）。
– 16K 上下文剩余 -0.8 GB（溢出）。

结论：在 24GB 显卡上，35B Q4_K_M 模型仅能稳定运行 4K 上下文，且剩余空间仅 0.2 GB，几乎无法支持任何并发批处理。若要支持 8K 或更长上下文，必须使用 32GB 显卡（8K 剩余 -0.2 GB，16K 剩余 -0.8 GB）或更高显存硬件。

批处理大小与吞吐量的平衡

批处理大小（Batch Size）决定了同时处理多少个请求。在 llama.cpp 或 vLLM 中，增加 Batch Size 通常会提高 GPU 利用率，从而提升总吞吐量（tokens/s），但前提是显存足够容纳所有请求的 KV Cache。

由于 35B MoE 模型的权重必须完整驻留显存（22GB），在 24GB 显卡上，剩余空间仅 0.5 GB（4K 上下文）。这意味着：
– Batch Size = 1：可行，但吞吐量受限于单序列解码速度。
– Batch Size > 1：每个额外请求都需要额外的 KV Cache 空间。由于剩余空间仅 0.5 GB，而 1K 上下文 KV Cache 需 0.1 GB，理论上最多只能容纳 2 个 1K 上下文的请求（2 × 22GB = 22GB）。因此，在 24GB 显卡上，Batch Size 实际上被限制在 1-2 之间，且上下文长度必须严格控制在 1K-2K 以内，否则显存溢出。

实测性能参考：
在低并发（Batch Size=1）场景下，35B Q4_K_M 模型的实测吞吐约为 75.4 t/s（单序列解码速度）。在高并发场景下，若硬件允许（如 32GB 显卡），吞吐量可提升至 1304.6 t/s。但在 24GB 显卡上，由于显存瓶颈，高并发几乎不可行，实际性能将接近低并发水平。

调优策略：找到最佳平衡点

硬件选择优先：
若必须使用 35B Q4_K_M，最低推荐 24GB 显卡，但仅支持 4K 上下文且 Batch Size ≤ 2。
若需 8K+ 上下文或更高并发，必须使用 32GB 显卡（如 RTX 4090/5090）。
上下文长度限制：
在 24GB 显卡上，将 --ctx-size 设置为 4096，避免显存溢出。
在 32GB 显卡上，可安全设置 --ctx-size 为 8192（剩余 7.8GB）或 16384（剩余 7.2GB）。
批处理大小调整：
使用 llama-bench 或 vllm 的 benchmark 工具，逐步增加 Batch Size（1, 2, 4, 8），监控 nvidia-smi 显存占用。
当显存占用接近显卡总容量（如 24GB 显卡占用 > 23.5GB）时，停止增加 Batch Size。
在 24GB 显卡上，Batch Size 建议设为 1，以确保稳定性；在 32GB 显卡上，可尝试 4-8。
KV Cache 量化（可选）：
若使用 vLLM 或 SGLang，可启用 KV Cache 量化（如 FP8），将 KV Cache 占用减半。例如，8K 上下文 KV Cache 从 0.7 GB 降至 ~22GB，从而在 24GB 显卡上可能支持 8K 上下文（总占用降至 ~23.85GB，剩余 ~-0.2 GB，仍紧张但可行）。

代码示例：llama.cpp 调优

# 在 24GB 显卡上运行 35B Q4_K_M，限制 4K 上下文
./llama-cli -m qwen3.6-35b-a3b-q4_k_m.gguf \
  -ngl 99 \
  -c 4096 \
  -b 1 \
  -ub 1

# 在 32GB 显卡上运行，尝试 8K 上下文和 Batch Size=4
./llama-cli -m qwen3.6-35b-a3b-q4_k_m.gguf \
  -ngl 99 \
  -c 8192 \
  -b 4 \
  -ub 4

通过上述调优，你可以在有限的显存内最大化推理性能。下一章，我们将深入探讨如何在 24GB 显卡上优化 KV Cache，以突破 4K 上下文的限制，实现更长的对话能力。

性能基准与故障排查：24G 显卡上的实际表现

在部署 Qwen3.6 35B MoE 时，许多用户会陷入一个误区：只要模型文件能加载，就算部署成功。然而，对于 MoE 架构而言，显存占用是刚性的。无论激活参数多少，35B 的总参数量意味着 Q4_K_M 量化后的权重必须完整驻留显存。这就带来了一个残酷的物理现实：在 24GB 显卡上，我们面临的是“装不下”还是“勉强能跑”的极限测试。

显存预算：为什么 16GB 是红线？

让我们先算一笔账。根据显存预算权威表，Qwen3.6 35B 的 Q4_K_M 权重占用 22GB，加上 1.5GB 的系统开销，仅基础部分就已达 1.5 GB。如果我们要运行 4K 上下文，KV Cache 需要 0.3 GB，总占用为 23.8GB。

这意味着，24GB 显卡在物理上无法容纳该模型的完整权重。

显卡	4K 剩余	8K 剩余	16K 剩余	32K 剩余
16GB	-7.8GB	-8.2GB	-8.8GB	-10.1GB
24GB	0.2GB	-0.2GB	-0.8GB	-2.1GB

注：负值表示显存不足，无法完整加载。

因此，本章的“24G 显卡”并非指单卡 16GB 独立显卡，而是指在显存受限环境（如 24GB 显存上限或混合推理场景）下的性能表现与故障排查。对于纯 GPU 推理，24GB 显卡（如 RTX 3090/4090）是最低门槛，且仅在 4K 上下文下剩余 -7.8 GB，空间极其紧张。

性能基准：吞吐量的真实面貌

在 24GB 显卡上，Qwen3.6 35B MoE 的实测吞吐量范围为 75.4-1304.6 t/s（低并发至高并发）。这一数据表明，MoE 架构在低并发下受限于权重加载带宽，而在高并发下能充分利用 GPU 计算单元。

然而，在 24GB 显存限制下，若强行使用 CPU+GPU 混合推理（llama.cpp 支持），性能将大幅下降。此时，瓶颈不再是计算，而是PCIe 带宽。每生成一个 token，都需要从系统内存读取部分专家权重，导致吞吐量可能降至 75.4 t/s 甚至更低。

# 使用 llama.cpp 进行混合推理（24GB 显卡场景）
# 注意：-ngl 99 表示尝试将所有层卸载到 GPU，但受显存限制，部分层将回退到 CPU
./llama-cli -m qwen3.6-35b-a3b-q4_k_m.gguf \
  -ngl 99 \
  -c 4096 \
  -b 4 \
  -ub 4 \
  --no-mmap

注意：--no-mmap 禁用内存映射，强制权重直接读入内存，避免页错误导致的延迟抖动。

故障排查：OOM 与 CUDA 错误的应对

在 24GB 显卡上部署 35B 模型，最常见的错误是 OOM（Out of Memory）。这通常发生在以下场景：

KV Cache 溢出：即使权重能加载，长上下文也会耗尽剩余显存。
系统开销低估：CUDA 上下文、cuBLAS 工作区等占用未计入。
混合推理配置不当：-ngl 设置过高，导致 GPU 显存不足，回退到 CPU 时内存带宽瓶颈。

排查步骤

监控显存占用
使用 nvidia-smi 实时监控显存使用率。在 24GB 显卡上，4K 上下文下剩余仅 0.2 GB，任何微小的波动都可能导致 OOM。

   # 实时监控显存
   watch -n 1 nvidia-smi

降低上下文长度
若出现 OOM，首先尝试降低 -c（上下文长度）。从 4K 降至 2K，KV Cache 从 0.2 GB 降至 22GB（估算），可释放约 24GB 显存。
调整 GPU 层数
在混合推理中，逐步降低 -ngl 值，直到显存占用稳定。例如，从 -ngl 99 降至 -ngl 50，将部分层强制留在 CPU。

   # 逐步降低 GPU 层数，寻找显存平衡点
   for ngl in 99 80 60 40 20; do
     echo "Testing -ngl $ngl"
     ./llama-cli -m qwen3.6-35b-a3b-q4_k_m.gguf -ngl $ngl -c 4096 -b 4 -ub 4 --no-mmap -p "Hello"
   done

检查 CUDA 错误
若出现 CUDA error: out of memory，检查是否因 --no-mmap 导致权重文件直接读入内存，占用系统 RAM。若系统 RAM 不足，移除 --no-mmap，允许内存映射。

结论：24G 显卡的极限与妥协

在 24GB 显卡上部署 Qwen3.6 35B MoE，本质上是一场显存与性能的妥协。纯 GPU 推理不可行，必须依赖 CPU+GPU 混合推理。此时，吞吐量受限于 PCIe 带宽，实测可能在 75.4 t/s 左右。若追求稳定运行，建议：

上下文长度 ≤ 4K
Batch Size ≤ 4
使用 --no-mmap 避免页错误
监控显存，动态调整 -ngl

通过合理的量化策略、编译配置和参数调优，24G 显卡可以稳定运行 Qwen3.6 35B MoE，实现显存压缩的极限性能。

16G 显卡跑 35B MoE：Qwen3.6 的显存压缩极限