开源权重模型能当Agent廉价层吗？实测出炉

在构建AI Agent时，用开源权重模型作为「廉价层」来处理低风险任务，是降低运营成本的热门思路。但这条路真的好走吗？博主Mike在webofmike.com上发布了一项实测：通过agentgateway统一路由，把两个本地开源模型与Claude Sonnet 5放在同一个60题Agent工具调用风险基准上对比。结果出人意料——成本确实归零了，但代价换了个维度出现。

测试是怎么设计的

整个实验搭建在agentgateway v1.6.0上，这是一个统一网关，对外提供与OpenAI兼容的/v1/chat/completions接口。网关背后挂了三个后端：一个27.3B参数的qwen3.8（Q4_K_M量化，262K上下文，由本地Ollama提供），一个32.9B参数的nemotron-3.5-lightning（稀疏MoE架构，1M上下文），以及作为前沿基线的claude-sonnet-5。

测试任务复用了jev-benchmark的60题手工标注集，要求模型将每次工具调用分类为readonly、destructive、privileged或exfiltration四档，其中34题清晰、14题模糊、12题对抗性。复用同一套题目，意味着结果可以直接与之前的基准以及confidence-routed-agents实验做对照。

作者特别澄清了一点：此处从Ollama库拉取的qwen3.8（27.3B）与社区热议的125B参数「Qwen3.8 Flash Next」并非同一模型，仅仅是名称前缀相似，两者不能混用引用。

Q4_K_M量化是GGUF格式下常见的4比特量化方案，字母K代表采用k-quant分层量化策略，M指medium档位。它在保留约4.5比特/权重的平均精度下，把模型体积压到接近FP16的四分之一，是消费级硬件本地推理最常用的折中档位。代价是复杂推理和长上下文任务上会有可测量的精度损失，因此基准结论不能直接外推到FP16或INT8版本。

**稀疏MoE（Mixture of Experts）**指前馈层被拆成多个专家，每个token只激活其中一小部分，因此32.9B总参数每次前向实际计算的参数量远小于稠密模型。它让模型在维持大容量知识的同时降低单位推理算力，但显存仍需容纳全部专家权重，且路由与调度会带来额外开销和延迟抖动。

OpenAI兼容端点指网关按OpenAI的请求/响应schema暴露接口，使客户端无需改动即可接入任意后端。这是一种最低公共分母式抽象：它统一了messages、max_tokens、finish_reason等字段，却无法表达各厂商的私有能力（如Ollama的think、Anthropic的扩展思考）。本文遇到的推理开关失效，正是该抽象层丢弃后端特有参数的典型后果。

意外踩坑：OpenAI兼容路径关不掉思考

两个Ollama模型默认都是推理模型，会先生成reasoning字段再给出结论。Ollama原生的/api/chat端点支持"think": false参数，能干净地跳过思考直接回答；但agentgateway的Ollama provider走的是OpenAI兼容端点，该端点完全忽略think参数。

结果就是：模型把全部max_tokens预算耗在半截未完成的reasoning字段上，content返回空字符串，finish_reason为length，而HTTP状态码依然是200。作者通过网关直连和绕过网关直连两种方式都复现了同样的结果。这个路径上唯一的调节手段是把max_tokens调大——实测用了700（qwen3.8）和900（nemotron-3.5-lightning），但仍然无法覆盖所有情况。

**推理模型（reasoning model）**在输出最终答案前会先生成一段内部思维链，通常以独立字段返回（Ollama的reasoning、OpenAI的reasoning_content）。这段内容同样计入max_tokens总预算，但当预算在思考中途耗尽时，不同服务端行为不一致：有的直接截断并返回空content，有的仍带HTTP 200。对上游路由器而言，这就变成了一个「成功但无用」的响应。

**finish_reason: length**表示生成因触达max_tokens上限而终止，而非自然结束（stop）。它是判断输出是否被截断的唯一可靠信号，因此生产环境的路由逻辑不应只看状态码，而应同时检查finish_reason与content是否非空，并把length加空内容视为硬失败而非可解析结果。

基准结果：准确率之外的隐藏成本

60题单轮测试的核心数据如下：

指标	claude-sonnet-5	qwen3.8	nemotron-3.5-lightning
有效回答率	59/60 (98.3%)	54/60 (90.0%)	27/60 (45.0%)
已答准确率	55/59 (93.2%)	53/54 (98.1%)	27/27 (100%)
全量准确率	55/60 (91.7%)	53/60 (88.3%)	27/60 (45.0%)
延迟 p50	1,080ms	18,885ms	6,512ms
延迟 p95	1,412ms	42,368ms	8,571ms
每次调用成本	$0.000704	$0	$0

需要注意「全量准确率」的口径：凡是没有产出可解析答案的调用（content为空）一律计为错误，因为生产环境中的路由器拿到HTTP 200加空字符串，根本无法做任何决策分发。

nemotron：答得准，但只答一半

nemotron-3.5-lightning是最引人注目的数据点。它一旦给出答案就100%正确（27/27），中位延迟6.5秒还比qwen3.8快得多。但它只回答了45%的调用——剩下55%的情况里，模型在推理中途耗尽900 token预算，什么有效内容都没吐出来。这不是「偶尔答错」，而是一个通过该接口经常「说不完」的模型。

qwen3.8：更可用，但慢得离谱

qwen3.8是两者中更实用的选择：90%的调用能给出答案，已答准确率98.1%。但「廉价」不能只看美元——延迟同样是成本。中位18.9秒、p95超过42秒，比Claude Sonnet 5在同任务上的1.08秒中位慢了15到20倍。一个为交互式Agent循环服务的置信度路由架构，只有在廉价层真的在关键维度上「廉」才有意义。而在本测试中，先崩掉的维度是时间，不是金钱。

按难度切分：难题消耗更多预算

三个模型在34道清晰题上都是100%正确。nemotron的无效回答集中在更难的切片上——14道模糊题只答了3道，12道对抗题也只答了3道。这符合直觉：难题需要更多推理token，而预算恰好在最需要它的地方耗尽。

**置信度路由（confidence routing）**指在Agent前挂一个分类器或廉价模型，先判断当前工具调用属于readonly还是destructive等风险档位，再决定是否需要前沿模型复核。它的前提是廉价层能在延迟预算内返回可判定信号——一旦廉价层在交互循环里耗时十几秒甚至更久，超时或降级就会把请求全部打回前沿模型，路由省下的成本被抵消，用户体验还更差。因此评估廉价层必须同时看三个维度：有效回答率、已答准确率和尾延迟（p95），而不是单看单价。

p50与p95是延迟分位数：p50（中位数）代表典型体验，p95代表慢尾。Agent循环对尾延迟尤其敏感，因为一次超时可能触发重试或回退，把单次调用成本成倍放大。qwen3.8的p95高达42秒，意味着二十分之一的请求会让整个Agent回合显著变慢，这也是它即便准确率接近Claude、仍难以承担交互式廉价层角色的关键原因。

这说明了什么，又不说明什么

首先需要界定边界：这是单一60题分类任务、在单台Apple M4 Max上的结果，并非开源模型与前沿模型的普遍性结论。Ollama模型的$0成本对于已经购置且闲置的硬件而言是真实的，但不适用于按小时计费的云GPU实例——后者本文未做测试。

其次，本实验暴露的失败模式特定于agentgateway的Ollama provider走OpenAI兼容端点这一路径。如果直接调用Ollama原生API并让think: false生效，大概率能弥合大部分回答率差距。但那样就脱离了网关治理——没有预算控制、没有统一访问日志、没有路由策略，而这恰恰是置信度路由Agent中设置网关的全部理由。继续提高max_tokens也能覆盖更多用例，代价是最难的那些题p95延迟进一步恶化。两者都是需要主动权衡的工程取舍，而非上线前顺手调掉的疏忽。

对于正在考虑把开源权重模型接入Agent廉价层的团队，这篇实测给出的建议很明确：先验证你的接口路径是否支持关闭推理，再评估延迟是否满足交互要求，最后才看账单。