8GB显存跑Qwen 3.8 Flash Next：实测900 t/s

在本地跑大模型，显存往往是最硬的约束。一位Reddit用户用8GB VRAM的笔记本显卡和32GB内存，把Qwen 3.8 Flash Next跑到了最高900+ t/s的提示处理速度和30+ t/s的生成速度，并且在实际编码任务中超过了此前使用的Qwen 3.6 35B A3B微调版本。这套方案的核心是Strata——一个把模型权重分散到VRAM、内存和SSD上的推理框架。

硬件与框架：把125B模型塞进8GB显存

发帖者的配置并不豪华：RTX 5060 Laptop（8GB VRAM）、Ryzen 9 8945HX（16核32线程）、32GB DDR5-5200内存，以及一块读写约5200/4200 MiB/s的1TB SSD，PCIe Gen 4 x8，系统为Linux。此前Strata在社区里被讨论时，通常需要12GB VRAM起步，因此8GB能否复现类似效果，是这篇分享最直接的看点。

Strata的思路不是把模型完整放进显存，而是让常驻的专家留在VRAM里，放不下的专家通过--mmap-experts映射到SSD，KV缓存则在VRAM和内存之间分配。发帖者用的是Qwen 3.8 Flash Next的Gyro S量化版本，理由是它在质量与速度之间平衡最好——此前尝试的GSQ-RCO Coder、GSQ-RCO IQ2_XS等量化要么陷入重复循环，要么非英语能力明显吃力。

据发帖者说明，Strata本身不影响回答质量，它只负责资源分配和专家驻留；真正决定输出质量的是量化版本。

MoE（混合专家）架构是理解这套方案的前提。Qwen 3.8 Flash Next 属于 MoE 模型，总参数量达 125B，但每次推理只激活其中一小部分“专家”网络。这意味着显存中不需要同时容纳全部专家权重，未被激活的专家可以留在内存或 SSD 上，按需换入。Strata 的 --mmap-experts 正是利用了这一特性：它把专家权重以内存映射文件的方式放在 SSD 上，GPU 只在命中对应专家时才读取相应分片。MoE 的稀疏激活让“125B 模型跑在 8GB 显存上”在理论上成立，而稠密模型即便做同样的卸载，速度也会因为每层都必须读取全部权重而崩溃。

GGUF 与 K-quant 量化是另一条线索。文中提到的 Gyro S、GSQ-RCO IQ2_XS 等版本，本质上是对模型权重做低位宽压缩（如 2-4 bit），以牺牲少量精度换取体积和带宽的大幅下降。量化位宽越低，SSD 和内存的读取压力越小，但质量退化也越明显——发帖者遇到的重复循环和非英语能力下降，正是低比特量化的典型副作用。

关键参数：调对两个值，性能提升最明显

发帖者给出了完整的配置，并强调对他这套硬件而言，收益最大的两个参数是--vram-reserve-mib和STRATA_RESIDENT_HEADROOM_GIB。前者为其他任务预留显存，500是能跑通的下限，但他建议用900；后者预留内存给系统，Windows用户应设得更高。

其他值得注意的设置包括：

• --kv-resident 20480：KV缓存分配下限，值越低留给显存的余量越大。
• --pcie-frac 0.35：控制每层VRAM未命中时GPU经PCIe读取的比例，可用./setup.sh --calibrate校准。
• 不启用MTP：虽然能提升生成速度，但会占用显存并拉低提示处理速度，对这套配置并不划算；10GB以上显存可以再考虑。
• Vision放在CPU上跑：每张图约1-2秒，但节省的显存相当可观，且Strata把Vision放在独立进程，可以被换出而不明显拖累模型。

在Linux上，他还建了独立的32GB swap分区，并用systemd的MemorySwapMax=0把服务进程钉在内存里，避免大上下文和会话缓存把服务换出导致读写性能抖动。

KV 缓存是长上下文推理的显存大户。Transformer 在生成每个 token 时，需要缓存此前所有 token 的 Key 和 Value 向量，避免重复计算。上下文越长，KV 缓存越大，262K 上下文下可轻易达到数十 GB。--kv-resident 20480 指定的是常驻 KV 缓存的下限（单位 MiB），Strata 会把超出部分放到内存中，GPU 按需读取。这也解释了为什么大上下文下开 --parallel 风险很高：多个并发会话各自持有一份 KV 缓存，显存和内存会被同时挤爆。

PCIe 带宽是专家卸载方案的隐形瓶颈。RTX 5060 Laptop 走 PCIe Gen 4 x8，理论带宽约 16 GB/s，远低于显存带宽。--pcie-frac 控制的是每层 VRAM 未命中时，GPU 经 PCIe 直接读取的比例；比例越高，命中率可能提升，但 PCIe 传输会成为新瓶颈。./setup.sh --calibrate 会实测本机 PCIe 与 SSD 的实际吞吐，给出建议值，这也是为什么照搬参数有风险——不同主板的 PCIe 通道数和 SSD 性能差异会直接改变最优配置。

实测速度：262K上下文下仍有800+ t/s

发帖者给出了两套配置的实测区间。Chat配置（单会话）在262K上下文下提示处理800-970 t/s、生成30-40 t/s；131K上下文下提示处理930-1,040 t/s、生成30-45 t/s。Agentic配置（多会话与委派）在262K上下文下为520-740 t/s和30-40 t/s，131K上下文下为670-890 t/s和30-45 t/s。

作为对照，他此前的Qwen 3.6 35B A3B在llama.cpp上、显存受限专家布局且关闭MTP/Vision时，提示处理为630-680 t/s、生成27-35 t/s。也就是说，新方案在更小的显存占用下，提示处理速度反而更高，生成速度也略有优势。

如果要在多会话场景下使用本地模型，发帖者提醒不要在大上下文（131K以上）时开--parallel，那会同时吃掉大量显存和内存，轻则速度骤降，重则OOM。更稳妥的是--conversation-cache：把有限数量的会话挂起，顺序恢复，避免切换会话时重读长上下文。相关参数包括缓存大小4096 MiB、槽位2个、最小缓存token数8000、保留最小空闲内存1024 MiB。

**提示处理（prompt processing / prefill）与生成（decode）**是两个性质不同的阶段。提示处理是并行计算：输入几千到几十万 token 时，GPU 可以一次性批量处理，吞吐高，主要受算力和显存带宽限制；生成阶段则是逐 token 自回归，每一步都要读取全部激活权重和 KV 缓存，天然是串行瓶颈，因此生成速度通常只有提示处理速度的几十分之一。文中 900+ t/s 与 30+ t/s 的差距正是这一规律的体现。对长上下文编码代理而言，提示处理速度往往比生成速度更影响体感——每次新会话都要重新读入大量上下文，prefill 慢会直接拖垮交互节奏。

质量验证：编码代理任务中的实际表现

发帖者没有跑标准化基准，而是用一周时间在真实任务上对比，包括在Pi Agent环境中做的宝塔、Flappy Bird克隆和鹈鹕等测试，其中鹈鹕测试还比较了不同的reasoning_effort设置。他对比的对象是当前在用的Cyber-Tiel 35B A3B（基于Ornith 1.5 Heretic），后者常出现重复循环，所以他从Tiel换到了Cyber-Tiel。

结论是他的编码代理已全部换成这个模型，开发速度和代码质量都有明显提升。由于保密原因，更多测试无法公开，他也把更广泛的基准测试留给社区。发帖者同时抛出一个问题：在代理任务上，Qwen 3.6 35B A3B是否还有继续使用的价值。

需要提醒的是，这套配置高度依赖具体硬件和系统调优，照搬参数有风险——设置不当可能影响系统稳定性或让模型陷入重度swap。Windows用户应下调内存分配，吞吐会明显下降，但OOM风险也随之降低。如果你有超过8GB显存，可以尝试Gyro M/L等更高位量化，并把这份配置当作起点而非终点。

常见问题

8GB显存真的能跑Qwen 3.8 Flash Next吗？ 按发帖者的配置可以，前提是用Strata做专家卸载、把部分专家映射到SSD，并选用Gyro S这类低比特量化。

生成速度30 t/s够用吗？ 对本地编码和代理任务而言属于可用区间，提示处理速度才是长上下文场景更关键的指标，这套配置在131K上下文下仍能保持较高水平。

Windows能用吗？ 可以，但要给系统留更多内存，吞吐会下降，稳定性优先。发帖者的全部测试均在Linux上完成。