被测服务：http://192.168.67.202:8000（vLLM 0.27.1，OpenAI 兼容 API）
模型：qwen3.8-27b-int4（Qwen3 混合思考模型，INT4 量化，max_model_len = 131072）
评测时间：2026-09-16 22:27–23:30（本地时间，UTC+8；服务进程已运行约一天）
评测规模：15 轮单连续会话长链（660 次模型调用，峰值上下文 44,776 tokens）+ 基线 13 请求 + 思考模式对照 54 调用 + 对照实验 222 调用，全程约 1,100 次模型调用

（备注：DSH：已设置会话70%的压缩、未安装任何Agent调用工具）

一、结论摘要（TL;DR）

二、测试环境与方法

2.1 服务端信息

2.2 指标定义

• TTFT：请求发出 → 首个非空 delta（content 或 tool_call）的间隔。
• 总延迟：请求发出 → 流结束。
• out_tps（有效输出速率）：completion_tokens / (总延迟 − TTFT)。
• 冷 prefill 速率：prompt_tokens / 冷请求 TTFT；热请求（前缀缓存命中）TTFT 单独统计。
• 所有请求 temperature=0、top_p=1、SSE 流式 + stream_options.include_usage=true，逐请求记录 usage。

2.3 任务设计

三类任务，同一会话内连续 15 轮，上下文逐轮累积（单会话长链，正是 Agent 长任务的真实形态）：

反馈策略（贴近真实 Agent 框架）：最终答案不合规则回灌 feedback 重试（最多 2 次）；单轮预算 = 期望步数 + 20；连续 5 次传输错误判该轮失败。

对照组：

• 基线：无工具、固定 128-max 输出的 prefill/decode 扫描，512→99k tokens 共 6 档、13 请求（2–3 重复，首请求为冷）。
• 思考对照：同一 T1(n=24) 任务、全新会话，enable_thinking ON vs OFF 各 1 轮。
• T2 对照：全新短上下文（无前序轮历史）单独跑 n=32/40/28/24，用于区分"长上下文污染"与"模型内在能力边界"，并逐记录 calculator 表达式以精确定位漂移点。
• T3 修正版：扩充知识库至 21 条（消除截断），终答改为 last_capital 字符串（消除字符计数），全新会话 5 轮 n=12→20。

说明：冒烟测试（2 轮 18 步）与正式运行共用日志文件，分析脚本已按首个 setup 时间戳过滤，正式运行 15 轮 660 次调用全部独立于冒烟数据。

三、稳定性结果

3.1 传输层：0 故障

传输层在整个评测窗口（含长上下文 44.8k、含外部负载尖峰时段）没有任何一次失败。vLLM 的 HTTP/SSE 层可靠性完全满足 Agent 长链需求。

3.2 主评测 15 轮总览

轮次   任务   N    期望步  实际步   结果    用时(s)
 1    T1    24     25      26     ✓      46.3
 2    T1    28     29      30     ✓      66.5
 3    T1    32     33      34     ✓      78.4
 4    T1    36     37      38     ✓     123.1
 5    T1    40     41      42     ✓     100.5
 6    T2    24     25      25     ✓      91.8
 7    T2    28     29      29     ✓      66.8
 8    T2    32     33      54     ✗     159.7   (final_wrong×2 + 超预算)
 9    T2    36     37      58     ✗     136.4   (final_wrong + 超预算)
10    T2    40     41      62     ✗     185.8   (final_wrong + 超预算)
11    T3    12     25      46     ✗     152.5   (final_wrong×2 + 超预算)
12    T3    14     29      50     ✗     139.1   (超预算, 无最终答案)
13    T3    16     33      54     ✗     155.6   (final_wrong + 超预算)
14    T3    18     37      58     ✗     140.6   (final_wrong + 超预算)
15    T3    20     41      62     ✗     ~150    (final_wrong + 超预算)

合计: 15 轮 / 660 次模型调用 / 通过 7 轮 (46.7%) / nudge 9 次 / 传输错误 0
事件: final_wrong ×9, step_budget_exceeded ×8

分任务通过率：T1 = 5/5（100%），T2 = 2/5（40%），T3 = 0/5（0%）

3.3 T1：完全稳定（5/5），仅存在无害的协议偏差

5 轮全部一次通过、0 nudge。唯一系统性偏差：每轮比期望多 1 次 calculator 调用——模型在取完 N 条记录后，倾向用一次 calculator 把所有值加总（而非心算），再给出最终 JSON。这是协议偏差而非故障（结果全部正确），说明该模型对"数值计算交给工具"的偏好很强，对 Agent 系统是好事。

3.4 T2：可靠性在 n≥32 处出现"悬崖"——且是模型内在弱点

T2 全部 10 次尝试的完整矩阵（含全新会话对照）：

总计 4/10 通过。三个关键事实：

1. n≤28 基本可靠（5/7），n≥32 全部失败（0/5）——主评测长上下文与全新短上下文同样全败，排除"长上下文污染"作为主因，这是模型对长重复序列的内在能力边界。
2. 失败机理已精确定位（对照 C1 逐记录 calculator 参数）：B 序列是 7 元素周期（[18,31,44,57,70,83,5] 重复 4–5 遍）。模型前 28 步（前 4 个完整周期）每一步完全正确，第 29 步（第 5 个周期的第 1 个元素）把 B 读成了 31 而非 18——即在印刷的重复列表上索引错位，之后链值持续漂移（304 ≠ 真值 109，且不等于任何中间真值）。调用次数本身是对的（32 次），纯粹是"从重复列表里取错第几个"。
3. 偶发"工具固化/失控"：C5（n=24，历史上 2 次通过过的长度）一次出现 44 次 calculator 调用、越过目标后持续续算且始终不产出最终答案直到预算耗尽；R10 主评测同样失控。即即使任务难度可靠，模型仍有 ~1/3 概率进入重复调用循环（n=24 上 1/3）。

3.5 T3：主评测 0/5 的主要原因是评测侧缺陷 + 字符计数弱点；修正后 4/5

逐轮分析显示一个统一模式：每轮前 24 步（12 组 search+log）执行完全正确，之后才出问题。查明原因有三层：

1. 评测侧缺陷（我方）：知识库只有 12 条，n>12 的轮（R12–R15）关键词列表被截断成同样的 12 个，而期望答案仍按 n 计算 count——模型即使把 prompt 里全部 12 个关键词做对，count 也与"期望"不符 → 结构性必败。
2. 字符计数是 LLM 硬弱点：终答含 total_chars（12 句事实的字符总数）。模型无法心算精确字符数，转而在结尾连打 calculator（把每句长度当字面量代入求和）：R11 连打 3 次（361/385，真值 399）、R12 连打 25 次仍无最终答案、R13–R15 类似。即"精确字符计数"这一要求本身超出了模型的可靠能力。
3. 长上下文叠加：此时上下文已达 26–45k tokens，含 7 个前序轮的全部工具往来，上述弱点在长上下文下更容易触发（R11 反馈后甚至重新搜索 12 遍关键词做"复核"）。

修正版 T3（21 条知识库消除截断；终答改为 last_capital 字符串，不要求任何算术；全新短上下文）：

4/5 通过，且通过的轮步数与期望分毫不差（2N+1 一次不多一步）。结论：T3 这类双工具顺序工作流本身对该模型是可靠的；主评测 T3 的 0/5 = 我方设计缺陷 × 字符计数弱点 × 长上下文三重叠加，而非工作流能力缺失。r1 的固化再次印证 §3.4 的"工具固化"模式（10 次 T3 类运行中出现 2 次：R12 与 r1，均发生在完成全部工具工作之后）。

3.6 稳定性总结论

四、速度结果

4.1 基线：prefill 与缓存（13 请求，512–99k tokens）

* 该档首版 padding 估算不足，实际 34.6k；后补 65k/99k 两档。

要点：

• 冷 prefill 实测 1.3–3.1k tok/s（随 chunked-prefill 与负载波动），100k 上下文冷启动 ~32s，65k ~48s——超长上下文的冷启动是该服务的主要延迟来源。
• 前缀缓存收益巨大且稳定：重复前缀的热请求 TTFT 恒定在 1.3–2.0s（无论前缀 2k 还是 99k），比冷 prefill 快 10–24 倍。对"系统提示词+工具定义固定、历史累积"的 Agent 长会话，vLLM 的前缀缓存把每步成本压到只 prefill 增量——这正是本次主评测 500+ 步仍能保持 2.3s/步的根本原因。
• 1024 档的"冷"快/慢倒挂与 99k 热请求 194s 尖峰均指向同一原因：评测窗口存在间歇外部负载（§4.4）。

[冷/热 TTFT]

[基线速率]

4.2 解码速率：77 tok/s 均值，受"输出可预测性"显著调制

• 主评测 660 步：out_tps 均值 77.0，p50 78.3，p95 88.7，min 1.8（该点即 38.4s 尖峰步）。
• 对照诊断（同服务同窗口，~500–900 tokens 上下文）：

  输出类型	实测 tok/s
  工具调用 JSON（~40 tok，高可预测）	98.9 – 101.6
  自然语言摘要（22–38 tok）	61.2
  强制重复词（63 tok）	46.5

• 机理：服务端开启 4 位 MTP 投机解码（整体接受率 ~62%，pos0 77%）。工具调用 JSON 结构高度可预测 → 草稿接受率高 → 有效速率接近 100 tok/s；自由 prose 接受率低 → 60 上下；评测初期基线窗口的 24–29 tok/s 则是外部负载压制（同窗口诊断重测已恢复 46–100）。
• 对 Agent 负载的含义：该服务上"以工具调用为主的 Agent 循环"比"长文生成"更快，这是投机解码的结构性红利。

[解码 vs 上下文]

4.3 长链过程中的延迟-上下文关系（主评测 15 轮）

[TTFT vs 上下文]

[时间线]

按上下文四分位统计（660 步）：

要点：

• 上下文从 771 增长到 44,776（131k 上限的 34.2%），TTFT 仅从 ~0.6s 温和升至 ~2.3s，前缀缓存 + chunked prefill 下延迟随上下文的退化非常平缓（Q1→Q4 仅 +18%）。
• 解码速率几乎不随上下文下降（75.9→77.1），说明该硬件配置下注意力开销在 45k 内尚未成为瓶颈。
• 按任务：T1（峰值 16.5k 上下文）总延迟均值 2.4s；T2 2.8s；T3 3.0s（26–45k 上下文）——500 步长链全程平均 ~2.8s/步，无恶化趋势。

4.4 尾延迟与共享负载风险（本评测最重要的速度警示）

评测窗口内共捕获 3 次 TTFT 尖峰，均与外部负载相关（尖峰后的下一步立即恢复正常 1.3–1.5s）：

同期解码速率也从 ~100 跌至 24–29 tok/s。结论：该 vLLM 实例在评测期间并非独占 GPU；空闲/轻载时性能优秀（§4.1–4.3），但并发竞争下 p99 延迟可达 p95 的 60–70 倍。若用于生产 Agent 服务，必须：独占/预留 GPU，或配置 --max-num-seqs 限流 + 优先级调度，否则长上下文请求会被任意突发流量长时间饿死。

4.5 思考模式（thinking ON vs OFF，同一 T1 n=24 任务、全新会话）

[思考对照]

结论：在此 27B INT4 服务上，对工具密集型 Agent 任务开启 thinking 是负优化——单步延迟 ×2.8、token 成本 ×5，且本样本中 ON 失败 / OFF 通过（n=1 每臂，方向性结论，样本有限但差距量级明确）。thinking 的价值应留给"需要多步推理且无现成工具"的开放式问题，而非"逐步调工具"的执行型 Agent 循环。

五、综合结论与建议

5.1 该服务作为 Agent 长链后端的总体评级

5.2 可操作建议

1. Agent/工具任务关闭 enable_thinking（本次实测 2.8× 延迟、5× token、且准确率更好）。
2. 重构"长重复链"任务：T2 类任务的失败点是"从印刷的 7 周期重复列表里取第 i 个"。让 prompt 给出增量公式（如 B_i = ((i×13 mod 91)+5)）代替列表、或把 4–5 步合并为一次批量工具调用（chain 工具），可把 32–40 步任务压到 <10 步，绕开该模型的索引弱点。
3. 不要要求模型心算精确字符数/大数：需要时提供专用工具（len()、sum()），否则会出现"连打 calculator"固化或错误终答（本次 2/10 的 T3 类运行因此失控）。
4. GPU 隔离/限流：若该实例面向多租户，启用 --max-num-seqs、请求优先级，或为长上下文 Agent 会话单独实例；验收标准建议以 p99 TTFT（而非 p95）为准——本评测 p99/p95 ≈ 16×。
5. 利用前缀缓存：固定系统提示+工具定义、按轮追加历史的组织方式已被验证能把 500 步会话的单步成本压在 2–3s；避免每轮重排历史顺序（会摧毁缓存命中）。
6. 容量规划：131k 上限下 500 步链仅用 34%；若单步输出变长（>100 tok），建议预算上限 250–300 步或中途做历史压缩。

5.3 评测局限性

• 单实例、单日（~70 分钟）评测；服务进程已运行一天，/metrics 累计计数器含评测前流量，服务端吞吐总量为近似值。
• 评测期间存在间歇外部负载（无法远程排除），§4.1/§4.4 已分别标注轻载与受扰数据。
• 思考对照每臂 n=1（方向性结论）；T2 对照每档 1–3 次重复。
• 主运行期间每 2 轮抓取的 KV-cache /metrics 因解析器早期 bug 为空，改用评测前后快照（评测后残留占用 <12%、空闲归零）与 TTFT 冷/热对比间接表征缓存行为。

附录

A. 文件清单（vllm_longchain_eval/）

B. 复现方法

cd vllm_longchain_eval
.venv/bin/python eval_harness.py       # 15 轮长链 + 基线 + 思考对照 (~35 min)
.venv/bin/python extra_baseline.py     # 65k/99k 扩展基线 (~5 min)
.venv/bin/python t2_control.py ctrl2   # T2 边界对照 (n=40/28/24, ~5 min)
.venv/bin/python t3_fixed.py           # T3 修正版 (~6 min)
.venv/bin/python analyze.py            # stats.json + 8 图