Qwen3.6-35B-A3B APEX 在单张 RTX 3090 上——充分发挥其潜力

我使用的资源： - https://github.com/ikawrakow/ik_llama.cpp - 作为参考的 llama.cpp 分支 - https://github.com/spiritbuun/buun-llama-cpp - 用于测试 TurboQuant 功能 - https://huggingface.co/mudler - 模型来源 - https://github.com/noonghunna/club-3090 - 速度参考、基准测试和配置指南 我的目标 我最近入手了一张 RTX 3090，试图找到运行 Qwen3.6-35B-A3B 模型的最佳配置。我的优先级很明确： - 尽可能高的质量，且不牺牲良好的速度 - 至少 128k 上下文，以处理长文档和长代理流程 速度基准测试 我测试了两个 llama.cpp 分支（club-3090 推荐的 ik_llama 和 spiritbuun 分支），搭配两种主要的 APEX 模型版本（I-Compact 和 I-Quality）。以下是生成速度结果，所有测试均使用 128k 上下文。 | 引擎 | APEX 模型 | KV 缓存 | decode_TPS（叙事） | decode_TPS（代码） | |------|-----------|---------|-------------------|-------------------| | ik_llama | I-Compact | q8_0 / q5_0 | ~146 | ~146 | | spiritbuun | I-Compact | turbo8 / turbo4 | ~142 | ~141 | | spiritbuun | I-Quality | turbo8 / turbo4 | ~137 | ~137 | | ik_llama | I-Quality | q8_0 / q5_0 | ~137 | ~137 | 分析： ik_llama 搭配 I-Compact 是无可争议的速度之王。然而，spiritbuun 搭配 I-Quality 和 turbo8/turbo4 缓存，其速度与 ik_llama 搭配 I-Quality 相同。 质量对比 以下是来自 APEX 仓库的 Qwen3.5-35B-A3B 官方数据对比表。注意：这是官方 APEX 基准测试。我尚未找到 3.6 版本的特定基准数据，但 APEX 各层级之间的相对性能应该保持一致。 | 模型 | 大小 | PPL ↓ | KL 均值 ↓ | KL 最大值 ↓ | HellaSwag ↑ | tg128 (t/s) ↑ | |------|------|-------|-----------|-------------|-------------|---------------| | BF16（参考） | 64.6 GB | 6.537 | — | — | 82.5% | 30.4 | | APEX I-Quality | 21.3 GB | 6.552 | 0.0102 | 5.59 | 83.5% | 62.3 | | UD-Q4_K_XL | 20.7 GB | 6.554 | 0.0097 | 3.14 | 83.0% | 58.1 | | APEX I-Compact | ~17 GB | 6.857 | 0.0451 | 8.76 | 83.5% | — | 从纸面数据看，APEX I-Quality 和 UD-Q4_K_XL 几乎一模一样：相同的困惑度（6.552 vs 6.554），相似的 KL 指标。但关键在于：APEX I-Quality 生成速度更快（62.3 vs 58.1 t/s，约快 7%），同时 HellaSwag 分数略高（83.5% vs 83.0%）。 APEX I-Compact 是效率之王：仅约 17 GB，提供出色的质量和最高速度，并且可以将上下文推到 256k 而不触发 OOM。它在 HellaSwag 上甚至与 I-Quality 持平（83.5%）。 为什么 turbo8/turbo4 优于 q8_0/q5_0 turbo8 是 spiritbuun 分支引入的新型 KV 缓存编解码器。作者（@spiritbuun）在 X（Twitter）上发布了 turbo8 与传统 q8_0 缓存的对比基准： | 上下文 | turbo8 tg/s vs q8_0 | turbo8 平均 KLD vs q8_0 KLD | |--------|---------------------|----------------------------| | 2048 | 31.34 +1.9% | 0.007717 -12% | | 8192 | 30.22 +3.6% | 0.009450 -8% | | 16384 | 29.40 +6.7% | 0.005235 -14% | | 32768 | 28.06 +15% | 0.003594 -8% | 来源：https://x.com/spiritbuun/status/2062164396789412256 turbo8 始终更快，且 KLD 总是更低。在更长上下文中差距拉大，32k token 时速度提升达 15%。推荐非对称使用 turbo4（turbo8 用于 Keys，turbo4 用于 Values），以获得最佳平衡。 注意 1：PR #72 - spiritbuun 必需项 要让 spiritbuun 发挥最佳性能，你需要应用我提交给该仓库的 PR #72。之前的一次改动引入了一条“快速路径”，导致预填充期间 CUDA 图捕获失效，造成约 38% 的 prompt eval 回归。该 PR 添加了一个保护机制，确保快速路径仅用于单 token 解码，从而恢复预填充吞吐量。 注意 2：MTP - 我的体验 在我的测试中，I-Quality 模型虽然支持 MTP（多 token 预测），但禁用 MTP 时实际速度更快。这可能是因为添加 MTP 头改变了内存布局，或者 MTP 版本的量化脚本优化更好。我还发现，在我的设置中 MTP 对这个模型没有带来好处。你可能会看到速度峰值，但预填充几乎总是变慢，生成也经常变慢。这一点已被其他人记录，其理由也合理：这些小型的 MoE 模型速度极快，因此 MTP 实际上可能拖累性能而非提升。所以，如果你追求最高速度，请尝试禁用 MTP（只需省略该标志）。 启动命令 ik_llama + I-Compact（最高速度） ```bash !/bin/bash /root/ik_llama.cpp/build/bin/llama-server \ -m /models/Qwen3.6-35B-A3B-APEX-MTP-I-Compact.gguf \ -b 4096 -ub 1024 \ --cache-ram 4096 \ --parallel-tool-calls \ --recurrent-ckpt-mode auto --merge-qkv \ -c 196608 -np 1 --no-mmap --mlock \ -ctk q8_0 -ctv q5_0 \ -vhad -vhad -ngl 99 \ --jinja --reasoning-budget 0 --flash-attn on \ --host 0.0.0.0 --port 8000 ``` spiritbuun + I-Quality + turbo8/turbo4（最佳质量/上下文） ```bash !/bin/bash /root/buun-llama-cpp/build/bin/llama-server \ -m /models/Qwen3.6-35B-A3B-APEX-MTP-I-Quality.gguf \ --host 0.0.0.0 --port 8000 \ --no-warmup \ -c 131072 \ -np 1 \ --no-mmap --mlock \ -ctk turbo8 -ctv turbo4 \ --jinja --reasoning-budget 0 \ --flash-attn on ``` 最后感想 我此前用旧款 3060 发过类似的帖子。我必须说，turbo8/turbo4 用于 KV 缓存时，速度与我那篇文章中报告的结果（turbo4/turbo4）相近，但 keys 采用 turbo8 后一致性更佳。 P.S. 我使用了 Hermes Agent（本文将 Quality 模型作为主模型）进行翻译和排版。