先说结果：DavidAU 的 Qwen3.8-27B LOW-MTP-IQ4_XS 配合 KVMem CUDA 双卡源码构建，已经实际处理并回答 240,056-token 的请求；后来保存的启动配置设为 262,144-token 逻辑上下文。一次接近满窗的 20 点远距离检索，实际输入 241,838 token，答对 15/20。所以“能塞进 256K”和“能精确找回 256K 中每个细节”是两回事。现在 27B 容器暂时停着，腾出 GPU 给另一项 150B 实验；下面都是此前实测，不是当前实时跑分。

大家关心的出字速度：早期纯文本测试中，生成约 31.0–34.0 tok/s；94K 输入时为 31.0 tok/s，240K 输入时为 34.0 tok/s。 相应 prefill 约 452–461 tok/s。这些数字来自 16K KVMem budget、4K 生成预留、关闭思考的配置。后来保存的 32K budget＋开启 low 思考配置没有同条件重测，不能直接沿用这个生成速度。

硬件、模型和部署

最后保存的配置关键参数如下，供同类硬件参考；显卡型号、驱动和空余显存不同，不能直接照抄：

--device CUDA0,CUDA1 --split-mode layer --tensor-split 1,2 --gpu-layers all
--ctx-size 262144 --parallel 1 --flash-attn on
--cache-type-k q4_0 --cache-type-v q4_0
--batch-size 1024 --ubatch-size 128
--kvmem-budget 32768 --kvmem-gen-reserve 32768
--kvmem-mtp-state replay --spec-type draft-mtp --spec-draft-n-max 2
--enable-thinking --reasoning-effort low

KVMem 进程里 CUDA0 是 3070 8GB、CUDA1 是 3060 12GB；1,2 让更多层落在 3060，给 3070 留出空间。它不是显存精确的 1:2 切分，因为 KV、计算缓冲和 MTP 也占显存。262144 是逻辑窗口；32768 GPU budget 是历史 KV 的工作预算，超出的历史需要主机内存和检索机制。后来的 32768 generation reserve 也限定单次回复最多约 32K token，思考 token 算在里面。

这个模型也是视觉语言模型。我后来加了同仓库的 F16 mmproj 和 image-min-tokens 1024，图片内容识别已验证。以下长上下文基准主要来自更早的纯文本、16K budget、4K 生成预留、思考关闭配置；不要把它们当成上面最终 32K budget＋思考开启配置的跑分。

长上下文与速度：输入确实跑完了

在 1:2 分配、16K budget 的纯文本配置上，我用服务器返回的实际 token 数核对：

请求完成后显存快照约为 3060 已用 10,407 MiB、3070 已用 4,903 MiB；分别还剩约 1.55 GiB 和 2.99 GiB。这是快照，不是带 Plex 转码时的峰值保证。KVMem 把更长的历史放到主机内存，GPU 显存不随逻辑上下文线性增长。

为了像第二篇帖子那样区分“容量”和“召回”，我又用固定 2:3 分配、同一份输入、20 个只出现一次的随机标记做对照；这个测试刻意让事实缺少语义线索，比较苛刻：

两种量化在每档错的是同几个位置。单次实验不能证明原因，但提醒我不要把更大的量化当成 KVMem 远距检索的万能补丁。Q4_K_S 在偏向 3060 的 1:2 分配下甚至无法为每张卡建起 KV 工作块；改成 2:3 才能加载，近 256K 请求后 3060 只剩约 750 MiB。因此我保留 LOW 量化，获得更大的资源余量。这个 20 点实验只能评估孤立事实召回，不能直接当作编程质量排名。

从两篇帖学到、以及这台机器不同的地方

第一篇的 q8_0 KV 跑分来自 AMD 7900 XTX 24GB、Full-KV、HIP build；作者也补测了同一 build 的 q4/q8，prefill 几乎一样。我们这里是 NVIDIA 12GB＋8GB、KVMem、q4_0 K/V，不能把 607 tok/s 的数字或 q8 配置直接迁过来。我在本机曾只把 K 从 q4_0 改 q8_0、V 仍 q4_0：约 94K 的 10 题都为 10/10，没测到收益，资源还更紧。

第二篇最有价值的提示是：实际填满输入、量显存/主机内存、测远距离召回，并分开看 TTFT、decode 和 E2E。我们的 256K 测试也确实暴露了 5 题没看出的检索漏失。我试过把 KVMem budget 从 16K 提到 32K；早期 240K 单项测得 prefill 从约 467 降到 400 tok/s，5 题仍都是 5/5。后续视觉/编程用途仍采用 32K 工作预算，但这并不等于已经证明它能改善极端 needle 召回。

真实长编程任务还踩了两个客户端坑。约 145K 上下文的冷 prefill 曾接近 500 秒；客户端原来的 300 秒流式空闲超时会取消请求，缓存没暖起来，重试又从头开始。把这个本地模型连接的超时改为 900 秒后才稳定。另一个是生成预留：低于任务所需时会在长代码输出中途截断。提高到 32K 是保险，实际更有效的办法仍是让 agent 分块写文件。后续同一编程任务的重复测试还显示，关闭思考明显比低强度思考差；low 与 medium 的微小分数差异没有稳定复现，所以最后保存的配置默认开启 low。这些设置变化后的速度仍需与上面的基准分开看。

对我而言，这套方案的价值是把 media server 闲置时的 3060＋3070 变成可用的本地长上下文编程服务，同时保留对显存余量、检索错误和客户端超时的清醒认识。欢迎同样用小显存双卡的朋友交流：尤其想看大家在相同输入长度下对 KVMem budget、needle recall、真实跨文件编程任务和 Plex 并发的复测。