单卡24GB跑35B Agent Team：Int4量化与多智能体协作实战

单卡跑 Agent Team 这件事，过去一年里我试过不下十次，每次都被显存按在地上摩擦。直到最近拿到 Apodex-1.1-mini 这个 35B 的通用推理加智能体模型，用 Int4 量化压到 18GB，在一张消费级 24GB 卡上把多智能体协作流程完整跑通，我才觉得这条路真的走通了。标题里那句"35B 开源逼近 1T 级别闭源模型"听起来像营销话术，但我实测下来，在 Agent Team 这类需要多轮工具调用、任务拆解、结果汇总的场景里，它的表现确实超出我对 35B 量级的预期。这篇就把我从环境准备、量化落地、Agent Team 编排到踩坑排查的完整链路摊开讲，适合手里只有单卡、又想玩多智能体协作的开发者参考，也适合正在评估"到底要不要上大模型"的团队做选型对照。

1. 为什么 35B 加 Int4 是单卡 Agent 的甜点区

1.1 显存账要先算清楚，别上来就下载权重

很多人拿到模型第一件事就是git clone权重，然后发现加载到一半 OOM，白等几小时。我习惯先把显存账算明白再动手。一个模型的显存占用大致分三块：权重、KV Cache、运行时开销。权重这块，35B 参数在 FP16 下是 70GB 左右，BF16 同理，单卡 24GB 根本放不下；Int8 大约 35GB，还是超；Int4 理论上是 17.5GB，加上量化 scale 和 zero-point 的额外开销，实测落在 18GB 上下，这就给 KV Cache 和运行时留出了约 5 到 6GB 的空间。

KV Cache 的算法得单独说，因为它直接决定你能开多长的上下文、能并发几个 Agent。公式是2 × 层数 × 隐藏维度 × 序列长度 × 批大小 × 精度字节。以 35B 量级常见的 48 到 64 层、隐藏维度 5120 到 6144 来估算，序列长度 8K、批大小 1、FP16 精度下，KV Cache 大概在 1.5 到 2.5GB。如果你要同时跑三四个 Agent 并行，批大小上去，这块会迅速膨胀。所以我的经验是：Int4 权重 18GB 是入场券，真正决定你能不能跑 Agent Team 的是 KV Cache 的预算管理。

提示：别信"18GB 就能随便跑"这种说法。18GB 只是权重，Agent Team 场景下多轮对话历史会不断累积，上下文长度是动态增长的，必须给 KV Cache 留足余量。

1.2 35B 逼近 1T 的说法，在 Agent 场景里怎么理解

"逼近 1T"这个表述容易被误读成通用能力全面对标。我的实测体会是：在结构化推理、工具调用格式遵循、多步任务拆解这三类 Agent 核心能力上，一个训练得当的 35B 模型确实能咬住大模型很大一部分表现，因为 Agent 任务对"知识广度"的依赖远低于对"指令遵循和格式稳定性"的依赖。你让模型写一首冷门题材的诗，35B 会露怯；但你让它把"查天气→判断是否带伞→生成提醒"这条链路按 JSON 格式输出，它稳得很。

这背后的逻辑是：Agent 场景的 token 分布高度集中在少数几类模式上——工具名、参数名、状态标记、任务分解的固定句式。35B 的容量足够把这些模式学扎实，而 1T 模型的优势主要体现在长尾知识和复杂开放域推理上，这些在 Agent Team 的流水线里反而用得不多。所以标题里这个对比，放在 Agent 语境下是成立的，但你要是拿它去做开放式知识问答，别指望有 1T 的体验。这个预期管理很重要，不然落地时落差会很大。

1.3 单卡跑 Agent Team 的真实瓶颈不在算力

我一开始以为瓶颈是推理速度，实测下来发现不是。单卡跑 Agent Team，真正的瓶颈是串行等待。一个 Agent 调工具、等返回、再推理，这中间的延迟叠加起来，比单次推理慢得多。35B Int4 在 24GB 卡上的解码速度，实测大概 15 到 25 token/s（取决于序列长度和批大小），单看不算快，但 Agent 流程里大量时间花在工具调用往返和上下文重组上，推理反而不是最拖后腿的。

这就引出一个关键设计取舍：Agent Team 的并行度要和显存预算匹配，不能盲目堆 Agent 数量。我试过开 6 个 Agent 并行，结果 KV Cache 爆了，触发频繁的换入换出，整体反而比 3 个 Agent 串行还慢。后面会详细讲我怎么定这个数量。

2. Int4 量化的落地细节：从权重到能跑起来

2.1 量化方案的选择：GPTQ、AWQ 还是 GGUF

这一步坑最多。市面上主流的 Int4 量化路线有三条：GPTQ、AWQ、GGUF（Q4 系列）。我在 Apodex-1.1-mini 上三条都试过，结论是Agent 场景优先选 AWQ 或 GPTQ 的 GPU 原生格式，GGUF 更适合 CPU 或混合推理的兜底方案。

原因在于 Agent Team 需要频繁的短序列、多批次推理，GPU 原生量化格式在批处理和 KV Cache 管理上更成熟，vLLM 这类推理框架对 AWQ/GPTQ 的支持也更完整。GGUF 的优势是部署简单、跨平台好，但在高并发短请求场景下，它的调度开销会吃掉一部分性能。我实测同样 3 个 Agent 并行，AWQ 版本的首 token 延迟比 GGUF Q4_K_M 低约 30%，这个差距在多轮工具调用里会被放大。

注意：不同量化版本对模型能力的折损不一样。AWQ 在 Agent 的格式遵循上折损最小，我测下来 JSON 输出合法率比某些粗糙的 GPTQ 版本高不少。选量化版本时，别只看体积，要拿你的实际 Agent 任务做一轮格式合法率测试。

2.2 加载配置：几个必须手动调的参数

权重下载好之后，加载配置里有几个参数直接决定能不能跑起来。我用的是 vLLM 作为推理后端，核心配置如下：

python -m vllm.entrypoints.openai.api_server \ --model /path/to/apodex-1.1-mini-awq \ --quantization awq \ --dtype float16 \ --max-model-len 8192 \ --gpu-memory-utilization 0.92 \ --max-num-seqs 4 \ --enable-prefix-caching

逐个说为什么这么设。--max-model-len 8192是我在单卡 24GB 下的平衡点，再往上 KV Cache 会挤占太多，Agent Team 的并发就上不去；--gpu-memory-utilization 0.92留 8% 给系统和其他进程，设到 0.95 以上容易在长上下文时被系统 OOM killer 干掉；--max-num-seqs 4是并发序列上限，对应我后面要讲的 3 到 4 个 Agent 的规模；--enable-prefix-caching对 Agent Team 特别关键，因为多个 Agent 往往共享同一段系统提示词和任务背景，前缀缓存能显著减少重复计算。

这里有个容易忽略的点：--dtype float16而不是 bfloat16。在部分消费级卡上，bfloat16 的支持不如 float16 完整，混用可能触发隐式转换导致显存抖动。我踩过一次，加载时看着正常，跑长上下文时显存曲线像心电图，换成 float16 就平了。

2.3 量化后的能力校验：别跳过这一步

量化完直接上 Agent Team 是危险的。我习惯先跑一轮能力校验，重点看三件事：JSON 输出合法率、工具名拼写准确率、多步指令的完成度。做法很简单，准备 50 条覆盖你实际业务的 Agent 指令，让模型输出结构化结果，用脚本统计合法率。

我实测 Apodex-1.1-mini 的 AWQ Int4 版本，JSON 合法率在 96% 以上，工具名拼写基本没错过，多步指令完成度约 90%。这个水平足够支撑生产级的 Agent Team，但剩下那 4% 到 10% 的失败必须靠外层校验兜住——后面讲编排时会说怎么加这层保险。如果你测出来合法率低于 90%，要么换量化版本，要么检查是不是 chat template 配错了，后者是新手最常犯的错。

3. Agent Team 的编排骨架：三个角色怎么分工

3.1 角色设计：Planner、Executor、Reviewer 的最小闭环

Agent Team 不是 Agent 越多越好。我在单卡约束下最终收敛到三个角色：Planner（规划者）、Executor（执行者）、Reviewer（审查者）。这个最小闭环的好处是每个角色的上下文都相对独立，KV Cache 压力可控，同时又能覆盖"拆解—执行—校验"的完整链路。

Planner 负责把用户的高层需求拆成可执行的子任务列表，输出严格的 JSON 结构，每个子任务带工具名和参数；Executor 拿到子任务后逐个调用工具、收集结果；Reviewer 检查 Executor 的输出是否满足原始需求，不满足就打回让 Planner 重新规划。这个循环最多跑三轮，防止无限打转。

为什么不用更多角色？我试过加一个"Memory Manager"专门管上下文压缩，结果发现它自己消耗的 token 和显存，比它省下来的还多。单卡场景下，角色数量要和显存预算、任务复杂度一起权衡，三个角色是我实测下来性价比最高的配置。

3.2 上下文隔离：每个 Agent 只给它该看的

Agent Team 最容易爆显存的原因，是每个 Agent 都塞了完整的历史对话。我的做法是上下文隔离：Planner 只看用户原始需求和上一轮 Reviewer 的反馈；Executor 只看当前子任务和必要的工具说明；Reviewer 只看 Executor 的输出和原始需求。这样每个 Agent 的上下文长度都能压到 2K 到 4K token，KV Cache 压力大幅下降。

实现上，我给每个角色维护独立的 message 列表，用前缀缓存共享那段固定的系统提示词。系统提示词里放角色定义、输出格式约束、可用工具清单，这部分所有 Agent 共用，命中缓存后几乎不占额外计算。实测这套隔离下来，3 个 Agent 并行的峰值显存比"全量历史共享"方案低了约 4GB，这 4GB 就是能不能多开一个 Agent 的关键。

提示：上下文隔离的代价是信息可能不同步。我的补救办法是在 Reviewer 打回时，把关键结论显式写进 Planner 的输入，而不是让它自己去翻历史。显式传递比隐式共享更可控，也更省显存。

3.3 工具调用的格式约束与容错

Agent 能不能稳定跑，工具调用的格式约束是命门。我在系统提示词里强制要求 Executor 输出如下结构：

{ "tool": "tool_name", "arguments": {"param1": "value1"}, "reason": "why this tool" }

reason字段看着多余，但它有两个作用：一是逼模型在调用前做一次显式推理，降低乱调工具的概率；二是出问题时方便排查，你能直接看到模型"以为"自己在干什么。实测加了reason之后，无效工具调用率下降了约 15%。

容错这块，外层必须有一层校验：解析 JSON 失败就重试一次，重试还失败就降级成让 Planner 重新规划；工具名不在白名单里直接拒绝并回传错误信息给 Executor。这层校验用几十行 Python 就能写，但它是整个 Agent Team 稳定性的地基。别指望模型 100% 守规矩，把不确定性挡在编排层，而不是祈祷模型不出错。

4. 实测数据与性能调优：数字说话

4.1 单卡 24GB 下的实测指标

我把实测环境和一个典型任务的指标整理成表，方便你对照自己的场景。测试任务是"根据一段业务描述，生成包含数据查询、计算、格式化输出的完整报告"，涉及 3 个工具、约 8 个子任务。

一次通过率 78% 意味着约五分之一的任需要 Reviewer 打回重跑，这个比例在可接受范围，但重跑会拉长端到端耗时。如果你的业务对延迟敏感，得在 Planner 的拆解质量上下功夫，减少返工。

4.2 并发数与显存的平衡：我怎么做压测

并发数不是拍脑袋定的。我的压测方法是：固定任务集，从 1 个 Agent 逐步加到 6 个，记录峰值显存和端到端耗时，找拐点。实测结果很清晰：3 个 Agent 时耗时随并发近似线性下降，到 4 个时收益开始变缓，5 个以上峰值显存逼近 23.5GB，开始触发换入换出，耗时反而回升。

所以我的结论是单卡 24GB 下，3 到 4 个 Agent 并行是甜点。这个数字会随你的上下文长度、工具返回体大小变化，但方法论通用：找到显存拐点，在拐点前一个位置停下。别贪心，多开一个 Agent 带来的那点吞吐提升，抵不过一次 OOM 重跑的成本。

4.3 前缀缓存和批处理的组合收益

这两个优化叠加起来效果明显。前缀缓存让共享的系统提示词只算一次，批处理让多个 Agent 的推理请求合并成一批。我实测开启前缀缓存后，多 Agent 场景的首 token 延迟下降约 25%；再叠加连续批处理（continuous batching），整体吞吐提升约 40%。

配置上，vLLM 默认就开了连续批处理，关键是--enable-prefix-caching要手动加。另外系统提示词要放在 message 列表最前面且保持完全一致，哪怕多一个空格都会导致缓存不命中。我踩过这个坑，排查了半天才发现是某个 Agent 的系统提示词末尾多了个换行。

5. 踩坑实录：那些文档里不会写的问题

5.1 长上下文下的显存缓慢泄漏

这个问题最隐蔽。跑短任务一切正常，跑十几个长任务后显存缓慢上涨，最后 OOM。排查链路是这样的：先看nvidia-smi确认是显存涨不是内存涨；再在 vLLM 日志里看 KV Cache 的 block 分配情况，发现已分配的 block 没有及时释放；最后定位到是 Agent 编排层没有正确结束会话，导致推理框架认为序列还在活跃。

根因是我在编排代码里，某个异常分支没有调用结束接口，序列一直挂着。修复很简单，用try/finally保证每个会话无论成功失败都显式关闭。这个坑的教训是：Agent 编排层的资源管理要和推理框架的生命周期对齐，别假设框架会自动回收。

5.2 工具返回体过大导致的上下文爆炸

有一次 Executor 调了个查询接口，返回了 2 万字的原始数据，直接塞进上下文，下一轮推理显存就顶到天花板了。这个问题在 Agent 场景特别常见，因为工具返回的内容你没法完全控制。

我的解决方案是三层：第一层在工具适配器里做截断，超过阈值只保留摘要和关键字段；第二层让 Executor 在拿到大返回体时先做一次"提取要点"的中间推理，把结果压缩后再进主流程；第三层在编排层设上下文长度硬上限，超了就强制触发压缩。三层下来，工具返回体再大也不会把显存打爆。

5.3 量化模型在特定格式上的"固执"

Int4 量化后，模型在某些格式上会表现出奇怪的固执。我遇到过一次，Reviewer 要求输出带特定字段名的 JSON，模型死活不肯用那个字段名，反复输出它自己习惯的名字。换 FP16 版本就没这问题，说明是量化带来的格式偏好偏移。

应对办法不是硬刚，而是在系统提示词里给一个完整的输出示例，让模型照着抄格式。实测给示例后，格式遵循率从 85% 拉回 97%。这也印证了一个经验：量化模型对"示例"的依赖比原版更强，few-shot 在 Int4 场景下不是可选项而是必需品。

5.4 排查链路复盘：一个 OOM 的完整定位过程

把一次典型 OOM 的排查过程完整走一遍，方便你复现思路。现象是跑第 7 个任务时 OOM，前 6 个正常。第一步，看显存曲线，发现是阶梯式上涨而非突增，排除单次大请求；第二步，看 vLLM 的 block 使用率，发现已用 block 数只增不减，怀疑序列未释放；第三步，在编排层加日志，打印每个会话的创建和销毁，发现第 3 个任务的某个子会话在异常分支里没销毁；第四步，修复异常分支的资源释放；第五步，回归测试跑 20 个任务，显存曲线平稳。

这个链路的价值在于顺序：先确认现象特征，再定位到框架层，最后回到业务代码。反过来从业务代码开始翻，效率会低很多。

6. 从能跑到好用：几个提升稳定性的工程习惯

6.1 给每个 Agent 设 token 预算

不设预算的 Agent 会失控。我给每个角色设了硬性 token 预算：Planner 单轮不超过 1K，Executor 单子任务不超过 2K，Reviewer 不超过 1.5K。超预算就强制截断并触发摘要。这个习惯让上下文长度变得可预测，显存规划也就有了依据。

预算怎么定？拿你的典型任务跑一遍，统计每个角色的实际 token 消耗分布，取 90 分位数作为预算上限。我实测下来，这个上限比平均值高 40% 左右，既能覆盖大多数情况，又不会给异常情况留太多浪费空间。

6.2 输出校验要前置而不是后置

很多人把校验放在最后，等整个流程跑完再检查。我的做法是每一步输出都校验：Planner 的子任务列表校验结构，Executor 的工具调用校验格式，Reviewer 的结论校验完整性。前置校验的好处是错误早发现早重试，不会等到最后才发现前面某步就错了，白白浪费几轮推理。

实现上，每个角色的输出都过一个轻量的 schema 校验函数，不通过就带着错误信息让该角色重试一次。这层校验的代码量不大，但它是把"能跑"变成"稳定跑"的关键。

6.3 日志要能还原整个决策链

Agent Team 出问题时，最痛苦的是不知道模型为什么做了某个决策。我的日志策略是：每个角色的每次输入输出都完整记录，包括工具调用的reason字段、Reviewer 的打回理由、Planner 的重新规划依据。这些日志在排查时能还原完整的决策链。

日志量会很大，我的做法是按会话 ID 分文件，跑完一个任务归档一个。别嫌麻烦，等你遇到那种"偶尔失败一次"的诡异问题时，这些日志就是唯一的线索。我靠这套日志定位过好几次量化模型的格式偏移问题，没有日志根本无从下手。

6.4 灰度上线：先单 Agent 再多 Agent

最后说个流程上的习惯。别一上来就上完整的三 Agent 闭环，先让 Executor 单 Agent 跑通工具调用，再加 Planner，最后加 Reviewer。每加一个角色都跑一轮回归测试，确认显存和稳定性没退化。这个灰度节奏能让你在出问题时快速定位是哪个角色引入的，而不是面对一个黑盒干瞪眼。

我在实际项目里就是按这个节奏推的，单 Agent 阶段跑了两天才加 Planner，加完又观察了一天。慢是慢了点，但省下了后面大量排查时间。单卡跑 Agent Team 这件事，稳比快重要，毕竟一次 OOM 重跑的成本，够你多观察好几轮了。