大模型推理吞吐与答题精度对比评测：速度优先还是质量优先

在大模型落地过程中，团队最常遇到的一类分歧是：到底应该把资源倾斜给推理吞吐，还是倾斜给答题质量？ 这两者在同一条技术栈上往往呈现出明显的“此消彼长”。本文以一次针对某类大模型的本地部署实测数据为线索，围绕“高吞吐推理配置”（下称方案A）与“高质量答题配置”（下称方案B）展开对比，分析二者在性能表现、能力边界、适用场景与选型依据上的核心差异。

需要说明的是，方案A与方案B并非两个不同的模型产品，而是同一模型能力在不同工程配置与调用策略下的两种典型取向：方案A强调并发吞吐与首 token 时延的可控性，方案B强调输出格式严格性、复杂推理完整性与结果可校验性。理解这两条路线的差异，比争论“哪个更强”更有实际价值。

一、对比背景：为什么需要区分这两类配置

大模型推理的工程实践里，有一个常被低估的事实：模型能力测试的通过率，与推理服务的吞吐指标，几乎不共享同一套优化目标。

• 追求吞吐时，服务端倾向于提高批处理规模、放宽并发上限、压缩单请求的思考步数，用更少的 token 换更高的 QPS；
• 追求质量时，调用侧倾向于增加工具调用轮次、强化格式约束、允许多步校验与重试，用更多的 token 换更高的结果正确率。

原始实测数据恰好展示了这一矛盾：在速度侧，单并发 Prefill 峰值可达约 757 tok/s，Decode 稳定在 23.8–28.7 tok/s；但在能力侧，严格判定下总分仅 9/25 PASS（36.0%），大量失分并非逻辑错误，而是格式与精度细节不达标。这说明性能指标好看，并不等于答题结果可用。

二、对象定义：方案A与方案B分别是什么

方案A：高吞吐推理配置。 以服务端批处理与并发调度为核心优化对象，关注 Prefill 吞吐、Decode 稳定性、TTFT 随并发的变化曲线，以及显存利用率下的最大并发承载能力。其典型特征是：单请求处理链路短、批处理窗口大、对输出格式不做强约束。

方案B：高质量答题配置。 以调用侧策略与输出规范为核心优化对象，关注工具调用循环的完整性、SQL/代码等结构化产出的正确性、格式严格匹配率，以及复杂多步推理的收敛性。其典型特征是：允许多轮工具调用、强调 system prompt 约束、对结果做执行校验与重试。

两者解决的是不同问题：方案A解决“服务能不能扛住流量”，方案B解决“答案能不能直接用”。

三、相同点分析

尽管取向不同，两类配置在底层逻辑上有若干共性：

1. 共享同一套模型权重与推理引擎，差异主要来自调度参数、批处理策略与调用侧提示工程，而非模型本身的能力边界；
2. 都受显存与 KV Cache 容量约束，高并发与长上下文都会挤压可用 KV 空间，二者在资源上是竞争关系；
3. 都以 token 为基本计量单位，吞吐优化本质是提升单位时间 token 产出，质量优化本质是提升单位 token 的信息有效性；
4. 都需要可观测性支撑，包括延迟分布、错误率、重试率与结果校验通过率，否则无法判断优化是否真正生效。

四、核心差异分析

1. 技术架构与资源管理

方案A的核心在服务端的批处理调度：Prefill 阶段通过更大的批处理窗口提升吞吐，Decode 阶段通过并发调度提升整体 token 产出。实测显示，单并发 Prefill 在 2k–32k 区间维持 629–758 tok/s 且无明显长度衰减，说明长上下文对 Prefill 吞吐的影响有限；但并发上升后衰减明显——2 并发约下降 30%–45%，4 并发约下降 50%，6 并发在 2k 场景下从 688 降至 228，降幅约 63%。瓶颈定位在批处理并发上限设置过低：当并发超过该阈值时请求进入排队，长 Prefill 请求相互阻塞，导致 TTFT 恶化、吞吐被均摊。

方案B的核心在调用侧的编排：通过多步工具调用循环（生成 → 执行 → 校验 → 修正）提升结果正确率。实测中 25 题全部自主完成工具调用循环，复杂多表 JOIN 与窗口函数均能正确写出，说明该路线在结构化任务上具备可行性；但其代价是 token 消耗随任务难度快速上升——简单题平均约 2 步、约 2.2k+0.2k token，难题平均 6.1 步，单题最高达 17 步、55.5k token。

2. 性能表现维度

维度	方案A（吞吐优先）	方案B（质量优先）
Prefill 单并发	约 757 tok/s（4k），2k–32k 区间 629–758 tok/s	非核心指标，通常被多轮调用稀释
并发衰减	2 并发 -30%~-45%，6 并发约 -63%	受重试与多步调用影响，有效并发更低
Decode 单并发	23.8–28.7 tok/s，稳定	非核心指标，关注端到端完成时间
TTFT	随长度线性上升，32k 时 51.5s（1 并发）→186.4s（6 并发）	单请求链路更长，首字节到可用结果间隔更大
主要瓶颈	批处理并发上限与 KV 显存	格式约束强度与重试策略
成本结构	单位 token 成本低，适合规模化	单位任务 token 消耗高，适合高价值任务

需要强调：TTFT 的恶化主因是排队而非计算本身，这意味着单纯提升算力未必改善体验，调整调度参数往往更有效。

3. 功能能力与结果质量

方案B的实测结果揭示了一个关键现象：失分主要来自格式而非逻辑。在严格判定（行数、列数、列名、首行全部匹配）下通过率为 36.0%，其中 trivial 8/8、easy 1/2、medium 0/2、hard 0/13；若将精度放宽到 1e-6，通过率可升至约 22/25（88%）。这说明大量“失败”本质是 ROUND(…,2) 之类的格式要求未被遵守，属于提示约束问题而非推理能力问题。

结构性失败集中在少数题型：多表加折扣 CTE 场景下列名不符、环比窗口函数返回 0 行且列名不符、渠道口径理解偏差导致份额计算错误。这类问题无法靠放宽精度解决，需要示例引导与口径说明。

4. 接入方式与改造量

方案A的接入改造集中在服务端：调整批处理并发上限与批 token 上限，需权衡显存占用（实测显存利用率已达 0.91，KV 接近上限）。改造量小，但对稳定性影响直接。

方案B的接入改造集中在调用侧：强化 system prompt 中的格式与精度要求、为窗口函数类题型提供示例 SQL、增加结果校验环节。改造不涉及服务端，但需要针对业务题型持续迭代提示模板。

5. 运维与观测

方案A关注延迟分位数、排队深度、KV 使用率与并发曲线；方案B关注任务完成率、重试率、格式校验通过率与单任务 token 消耗。两者应纳入同一套监控体系，否则容易出现“吞吐达标但业务方不买单”或“质量达标但成本失控”的割裂。

五、对比表格汇总

对比维度	方案A：高吞吐推理配置	方案B：高质量答题配置
优化目标	吞吐、并发承载、TTFT 可控	结果正确率、格式严格性、可校验性
关键参数	批处理并发上限、批 token 上限、显存利用率	system prompt 约束、工具调用轮次、重试策略
优势	单位 token 成本低，适合规模化服务	结构化任务可用性高，复杂推理可收敛
劣势	格式与精度细节易失分	token 消耗高，端到端时延长
典型风险	高并发下排队导致 TTFT 恶化	提示约束不足导致“逻辑对、格式差”
适用场景	高 QPS 对话、批量生成、内容分发	数据分析、报表生成、结构化问答

六、典型场景选择

• 面向大量终端用户的对话类应用：优先方案A。用户对首 token 时延敏感，对格式严格性要求低，吞吐与并发承载是核心指标。
• 数据分析与报表生成类任务：优先方案B。结果需要直接入库或对账，列名、精度、行数必须严格匹配，多花 token 换取可直接使用的结果更划算。
• 混合场景：可采用分层策略，简单意图走方案A，识别为结构化任务后切换到方案B，避免全量任务都付出高质量成本。

示意性伪代码如下：

if is_structured_task(query):
    result = run_with_tool_loop(query, max_steps=8, strict_format=True)
    if not validate(result):
        result = retry_with_example(query)
else:
    result = run_fast(query, batch_window=large)

七、选型建议

1. 先明确成功标准：若成功标准是“用户不等待”，选方案A；若成功标准是“结果可直接消费”，选方案B。
2. 不要用吞吐指标评价质量路线，也不要用严格通过率评价吞吐路线，二者评价体系不同。
3. 高并发场景优先调调度参数：提升批处理并发上限与批 token 上限可改善高并发吞吐，但需同步评估显存余量，避免 KV 打满引发新的排队。
4. 格式类失分优先用提示工程解决：在 system prompt 中明确“必须严格按题面要求做精度与格式处理”，对窗口函数类题型给出示例，成本远低于更换模型。
5. 口径类错误需要业务对齐：渠道定义、统计口径等属于业务语义问题，应通过术语表与示例固化，而非依赖模型自行推断。

八、迁移与使用注意事项

• 数据与接口兼容：从吞吐路线切换到质量路线时，调用链路从单次请求变为多轮工具调用，接口超时、重试与幂等设计需同步调整。
• 成本预期重置：质量路线的单任务 token 消耗可能数倍于吞吐路线，容量规划需按任务数而非请求数估算。
• 稳定性风险：多步调用放大了失败面，需为每一步设置超时与降级策略，避免单点阻塞拖垮整体。
• 评测口径统一：严格匹配与放宽精度会带来数倍通过率差异，对外报数时必须声明判定标准，避免误导决策。
• 显存边界：提高并发上限会挤占 KV 空间，长上下文与高并发叠加时风险最高，建议压测后再上线。

九、总结

方案A与方案B并非优劣之分，而是优化目标不同导致的能力取舍：前者用调度换吞吐，后者用 token 换正确率。实测数据表明，吞吐侧的单并发表现稳定、瓶颈集中在并发调度；质量侧的失分集中在格式与口径，而非推理能力本身。选型时应先定义成功标准，再匹配对应路线，并通过统一监控与评测口径确保优化真正转化为业务价值。对于大多数团队而言，分层混合策略往往是更现实的起点。