nerkyor

/

Qwen3.6-35B-A3B-DSV4Pro-Thinking-Distill-GGUF

like 10

我用的是一张32G PCIE V100，
模型：Qwen3.6-35B-A3B-DSV4Pro-Distill-MTP-Q4_K_M-imatrix.gguf
llama.cpp: B9803
kv cache: q8_0
编程工具：OpenCode

没有陷入思考死循环，工具调用、编码任务也完成的很好，牛逼！

根据运行日志分析如下：

这次日志显示 MTP 依然配置为预测 3 个 Token。

值得关注的是，当前对话的上下文长度已经非常巨大，达到了 122,000+ Token（例如 n_tokens = 122582）。在如此长上下文的压力下，MTP 的表现依然非常平稳。

以下是本次日志的具体数据解析：

1. Task 14894

• 本次任务接受率：75.64% (draft acceptance = 0.75641)
  • 接受的 Token 数 / 生成的草稿 Token 数：59 / 78
  • 平均接受长度：3.27
  • 按位置的接受率：(0.808, 0.731, 0.731)
    • 第 1 个预测 Token 接受率：80.8%
    • 第 2 个预测 Token 接受率：73.1%
    • 第 3 个预测 Token 接受率：73.1%

2. Task 14923

• 本次任务接受率：78.50% (draft acceptance = 0.78495)
  • 接受的 Token 数 / 生成的草稿 Token 数：438 / 558
  • 平均接受长度：3.35
  • 按位置的接受率：(0.898, 0.774, 0.683)
    • 第 1 个预测 Token 接受率：89.8%
    • 第 2 个预测 Token 接受率：77.4%
    • 第 3 个预测 Token 接受率：68.3%

3. 全局累计统计（截至 Task 14923 结束）

• 整体累计接受率：86.73% （累计生成 44,361 个，累计接受 38,476 个）
• 累计平均接受长度：3.60
• 累计按位置接受率：(0.933, 0.865, 0.804)
  • 累计第 1 个预测 Token 接受率：93.3%
  • 累计第 2 个预测 Token 接受率：86.5%
  • 累计第 3 个预测 Token 接受率：80.4%

总结与观察

1. 超长上下文支持：在当前任务中，上下文长度达到了约 122k Token。即便在如此庞大的 KV Cache（Checkpoint 大小已达约 191.5 MiB）和极长的序列长度下，模型的推理性能和 MTP 的预测准确度并没有出现明显的退化。
2. 高水准的长期表现：从超过 14,000 次草稿预测（共 44,361 个草稿 Token）的长期统计来看，86.73% 的整体累计接受率说明该 MTP 模型在 3-Token 配置下，表现是相当稳健和高效的。

速度分析：

通过对您提供的五组日志进行纵向和横向对比，可以清晰地分析出该系统在 Prompt Evaluation（预填充/Prefill） 和 Decode（生成/评估） 两个阶段的速度表现，以及上下文长度、MTP（多Token预测）对速度的实际影响。

一、 Prompt Eval（预填充/首字延迟）速度分析

Prompt Eval 负责处理输入的 Prompt 并构建最初的 KV Cache。其速度表现呈现出以下规律：

1. 随着 Prompt 长度增加，Token 处理效率提升（吞吐量增加）

由于 GPU 硬件在计算大矩阵时更具并行优势，Prompt 越长，每秒处理的 Token 数（t/s）通常越高：

• 极短 Prompt（15 tokens）：速度较慢，约为 53 ~ 62 t/s（单 Token 耗时约 16 ~ 18 ms）。
• 中等 Prompt（40 ~ 47 tokens）：速度提升，约为 206 ~ 233 t/s（单 Token 耗时约 4 ~ 4.8 ms）。
• 较长 Prompt（161 ~ 254 tokens）：在短上下文下，处理速度最高可达 293 ~ 487 t/s（单 Token 耗时仅 2.05 ~ 3.41 ms）。

2. 超长上下文对 Prompt Eval 的负面影响

即使处理相同长度的 Prompt，如果系统中已经存在极长的上下文（巨大的 KV Cache），Prompt 处理速度也会受到一定的拖累：

• Task 5296（上下文约 4.7万 Token）：输入 161 tokens，速度为 293.15 t/s。
• Task 14923（上下文约 12.2万 Token）：输入 161 tokens，速度下降至 200.16 t/s。
• 分析：这是由于随着上下文变长，新 Prompt 的 Token 在进行自注意力（Self-Attention）计算时，需要与极其庞大的已有 KV Cache 进行配对计算，计算复杂度和内存带宽开销增加，导致速度有所下降。

二、 Decode（文本生成）速度分析

Decode 负责逐个（或通过 MTP 逐组）生成后续文本。此阶段受 MTP 接受率 和 上下文长度 的双重影响极为明显。

1. MTP 配置及接受率对生成速度的提升

在短上下文（<2000 tokens）中，不同 MTP 深度配置下的生成速度对比：

• MTP-4（预测 4 个，接受率 86.36%）（Task 7）：速度最高，达 150.09 t/s。
• MTP-3（预测 3 个，接受率 89.21%）（Task 101）：速度次之，达 139.92 t/s。
• MTP-2（预测 2 个，接受率 93.14%）（Task 14）：速度为 133.55 t/s。
• 分析：高接受率的 MTP 能够让模型在一次前向传播中产出更多 Token。当接受率保持在 85% 以上时，预测深度越深（如 MTP-4），带来的解码吞吐量上限越高。

2. 超长上下文对生成速度的瓶颈效应（核心观察）

随着上下文（KV Cache）的无限膨胀，即便 MTP 的接受率依然维持在不错的水准，生成速度也会出现明显的下滑：

• **短上下文 (<2k)**：速度约为 133 ~ 150 t/s（单 Token 耗时约 6.6 ~ 7.5 ms）。
• **中长上下文 (约 4.7万)**（Task 5296）：速度降至 76.72 t/s（单 Token 耗时约 13.03 ms）。此时 MTP 接受率较低（57.21%）也是导致变慢的原因之一。
• **超长上下文 (约 12.2万)**（Task 14923）：速度进一步降至 74.44 t/s（单 Token 耗时约 13.43 ms）。
• 分析：在 12.2万 的超长上下文下，即使 MTP 接受率依然高达 **78.50%**，生成速度也仅能达到 74.44 t/s。这是由于长上下文带来的 KV Cache 极度庞大（Task 14923 对应的 Checkpoint 占用达 191.515 MiB）。在 Decode 阶段，GPU 的访存带宽（Memory Bandwidth）成为了主要瓶颈，每次生成都需要将这近 200 MiB 的数据从显存读取到计算单元中。如果没有 MTP 技术的加速，此时的纯单字解码速度可能会降得更低。

三、 总结与系统特性

1. 上下文缓存机制的高效性：
   在 4.7万 和 12.2万 这样的超长上下文切换时，日志中频繁出现 restored context checkpoint 和 created context checkpoint（耗时仅十几毫秒，如 0.37.315.912 附近）。这表明 llama.cpp 的 Prompt Cache（槽位保存与恢复） 机制工作非常高效，避免了对这 12万 Token 的全量重新评估（Prefill），极大地节省了启动时间。
2. 性能拐点：
   对于该硬件系统，当上下文长度低于数千 Token 时，可以轻松实现 130 ~ 150 t/s 的极速解码；而当上下文延伸至 10万+ 级别时，受限于硬件的显存带宽瓶颈，解码速度会缩水至约 74 ~ 76 t/s 左右。尽管如此，在 MTP 的辅助下，即使在 12万 上下文下，依然维持了超越普通单字解码的生成速度。