在128 GB M5 Max上运行Qwen3.8-Flash-Next（79 GB，2-bit）以350K上下文持续3.5小时——速度与上下文深度权衡，100轮对话，一张图表

设置：MacBook Pro M5 Max，128 GB统一内存，macOS 26.5.2 · llama.cpp b10686（Metal，12线程，批处理2048，flash-attn，kv-unified，ngram-mod spec decode） · Qwen3.8-Flash-Next UD-Q2_K_XL（Unsloth），78.9 GB · 通过YaRN从原生262,144扩展至358,400令牌的上下文槽，使用fp16 KV。权重加全350K KV在默认96 GB GPU显存限制内——无需sysctl破解。会话：一个槽位，100轮对话，两次对话。对话1通过前缀复用从0增长到48K上下文；在约20分钟空闲后，槽位仅保留5.5K系统前缀，因此下一轮冷预填充了整个105K提示，耗时333秒——本次运行中最长的预填充——对话继续增长到169,425上下文，这是会话最深点（350K是槽位容量，从未填满）。槽位重置；对话2增长到约125K，我在此处停止捕获。图表：x轴=每个测量发生的槽位上下文大小；y轴=打印令牌/秒，对数尺度（两个阶段跨度约2个数量级）。绿色=提示处理，红色=令牌生成。点=进行中的检查点，方块=每轮最终值。无平滑，无拟合。预填充（绿色）：平滑的顶线是冷预填充——在第一个检查点（5.6K上下文）为1,561 t/s，随着KV填充，在111K时降至318 t/s。下方的绿色带表示正常轮次：每个深度有几千个新令牌（77–854 t/s，达到169K上下文），因为前缀复用意味着只有增量被预填充。解码（红色）：一个平滑的下降——小上下文时约30–35 t/s → 45K时约21 → 100–125K时13–15 → 169K时11.5 t/s。在约140K处降至7.7 t/s是由于macOS低功耗模式；仍可用。关于解码数字的一个注意事项：它们是在启用ngram-mod spec decode时的有效吞吐量（草稿接受率根据内容在0–81%之间），而非基础模型速度。实用解读：通过前缀复用，一轮的预填充仅需几秒钟；5.5分钟的预填充仅在空闲间隙后发生了一次。解码在达到169K上下文时仍保持交互性。体验：在前约100K上下文时表现强劲。超过后，在长尾任务中，开始混淆用户消息与自身先前输出（角色混淆），且随使用加剧。排除的因素：KV量化（运行fp16）和rope外推（最差轮次远低于原生262K）。剩余嫌疑：2位量化和/或预览模型的长上下文质量。