Qwen3.6-35B-A3B Q4 262k上下文，8GB 3070 Ti上可达+30tps

..而且凭借8GB显存，我甚至可以把上下文推到320K、400K、512K，没错……甚至1M。不过超过150k后速度会明显下降，所以除非确实需要更大上下文，否则我不会这么做。这里使用的是APEX-I-Quality或Q4\_K\_XL量化，两者都优于Q4\_K\_M（对于超过512k上下文则使用IQ4\_NL\_XL）。我总共有32GB DDR4-2666内存，略高于DDR4的最低要求。我看到很多拥有更好GPU和更多显存的用户效率反而更低，不得不将上下文降到64k甚至更低才能维持不错的tps，我不明白为什么。但到目前为止，我通过调优学到了两点。第一，由于35B-A3B是一个MoE模型，运行时只需约3.5B参数在显存中。8GB足够容纳活跃模型层（约3GB）+ GPU缓冲区（约2GB）+ q8\_0格式的262144 KV缓存（2.56GB）。虽然有点紧张，但可行。调整引擎参数，比如强制所有层都在显存，或者其他运行时参数如sm、fa等，反而会拖慢模型速度，或者耗尽我的显存和系统内存。例如看这张截图，有人误解MoE必须完全放入显存才能最优运行。https://preview.redd.it/cpc4r9q7cr2h1.png?width=1197&format=png&auto=webp&s=89bd03a4537825b862472009225a7a99b7fbd8b4 第二，就像Windows 11在游戏方面表现糟糕一样，那些“增强体验”也对LLM推理有影响。在终端下运行紧凑型Linux（我选择了Ubuntu Server）只会占用约800MB系统内存和几乎没有显存，相比之下Windows 11给了我+25%的tps提升！以下是相同llama.cpp参数的一些数据：Windows上 * 推理速度<27 tps，且超过100k后快速下降，实际上从输出前几千个token就开始下降。 * 系统内存占用超过28GB，如果调整llama.cpp的其他参数，立刻就会被填满（约31GB），拖慢tps。 * 我能稳定运行的最高上下文是512k，使用turbo quant 4 KV缓存。在Ubuntu Server上（两天前全新双系统安装，安装在我最快NVMe的一个160GB分区上） * 推理速度约34 tps，且不会下降，生成token时经常达到约37 tps！ * 系统内存占用22GB，留出整整8GB系统内存让我运行i3wm/x11及任何所需软件（不使用任何消耗GPU的华丽合成器或应用，因为那会占用宝贵的显存）。 * 在IQ4\_NL\_XL和turbo4 KV缓存上，我成功达到了1M上下文。目前为止已经足够好了。但我有一个较旧的小GPU，可以连接用于操作系统，同时让3070 Ti完全专用于LLM。--------------------两份配置都以编码为主，在Windows 11下也能运行，但剩余内存会少很多。256K上下文的主配置：llama-server \ -m Qwen3.6-35B-A3B-Q4_K_XL.gguf \ --jinja \ --parallel 1 \ --temp 0.7 \ --top-k 20 \ --top-p 0.95 \ --min-p 0 \ --reasoning-budget 4096 \ -n 32768 \ --no-context-shift \ --no-mmap \ -c 262144 \ --cache-type-k q8_0 \ --cache-type-v q8_0 \ --host 0.0.0.0 以及512K上下文配置：llama-server \ -m Qwen3.6-35B-A3B-Q4_K_XL.gguf \ --jinja \ --parallel 1 \ --temp 0.7 \ --top-k 20 \ --top-p 0.95 \ --min-p 0 \ --reasoning-budget 4096 \ -n 32768 \ --no-context-shift \ --no-mmap \ -c 524288 \ --rope-scale 2 \ --rope-scaling yarn \ --yarn-orig-ctx 262144 \ --cache-type-k turbo4 \ --cache-type-v turbo4 \ --host 0.0.0.0 希望有人觉得有用。我爱这个社区，我也在Qwen3.7-35B-A3B等待室里和大家一起焦急地啃指甲哈哈哈。