单卡启动 Agents-A1 报显存不足时，先不要急着更换量化版本或去改并行度。更稳妥的顺序是：先用启动日志确认显存峰值出现在权重加载、预热还是推理阶段，再判断显存压力来自总参数量还是稀疏激活带来的动态占用，最后才决定先调量化位宽还是并行度。Agents-A1 这类混合专家模型，权重常驻部分和每 token 实际激活的参数路径不是一回事，混淆这两者，容易把问题归因到量化，结果调了配置也没落到真正吃紧的那一段。

显存吃紧时先定位阶段，再判断参数路径，最后才改量化与并行。权重加载阶段占满，多半是总参数量和加载精度的问题；预热或推理阶段才涨，则更可能是激活专家、KV 缓存与并发共同挤占。先把量化位宽调低并确认进程真正重载，再看张量并行；流水并行改动代价更大，放在后面。每一步都要用日志行和显存查询输出对照，不能只看进程有没有起来。

在启动日志里分清权重加载与推理两段显存峰值

启动日志里要盯两类标志行：一类是权重加载完成或分片加载完成的提示，另一类是缓存分配开始或 KV cache 初始化的提示。这两行之间通常对应权重常驻显存基本到位，之后显存继续上涨，就属于缓存与运行时占用，而不是权重本身。不同启动脚本措辞不一样，可以用关键字粗筛：

python -m agents_a1.serve \
  `--model` /models/agents-a1 \
  `--quant` int4 \
  `--tp` 2 \
  `--pp` 1 \
  2>&1 | tee /tmp/agents_a1_boot.log

grep -nE "load|weight|shard|cache|kv|oom|out of memory" /tmp/agents_a1_boot.log

启动过程中另开一个终端，按固定间隔采样显存，和日志时间轴对齐：

while true; do
  date +%H:%M:%S
  nvidia-smi `--query-gpu`=index,memory.used,memory.total \
    `--format`=csv,noheader
  sleep 3
done

对照写法是：如果日志停在权重加载完成那一行之后，显存就接近上限，说明问题在总参数量和加载精度；如果日志已经进入缓存分配、服务监听端口，而显存在随后的请求里才涨到上限，说明问题在激活路径与缓存。这两种情况的处理顺序完全不同，先分清再动手。

按稀疏激活估算每 token 实际走过的参数路径

混合专家模型的显存压力要拆成两部分看：一是权重常驻，取决于总参数量和量化位宽；二是运行时的激活动态，取决于每 token 命中的专家数、层数、序列长度和并发请求数。配置里通常能读到专家总数、每 token 激活专家数、层数和隐藏维度，可以直接代入一个粗算公式，用来判断量级，不追求精确值：

常驻权重显存 ≈ 总参数量 × 每参数字节数（受量化位宽影响）

单 token 激活参数 ≈ 非专家参数 + 层数 × 每层激活专家数
                     × 单专家参数量

运行时额外占用 ≈ 单 token 激活参数 × 并发 token 数
                 + KV 缓存（随序列长度和并发增长）

把配置里的专家总数和激活专家数代入第二行，看激活参数相对总参数量的比例。如果激活占比很小，但显存仍在推理阶段吃紧，通常要先把注意力放到并发数、序列长度上限和 KV 缓存上，而不是继续压量化。反过来，如果权重加载阶段就已经贴近上限，激活参数再怎么估也没用，应该直接处理加载精度与模型切分。

量化配置与并行度谁先调

三者的改动代价不一样。量化位宽一般只改启动参数或加载配置，不改变服务对外形态，回退也快；张量并行要改切分方式和卡数，涉及通信与显存分布，代价中等；流水并行会改变层在设备间的划分，启动与调优成本最高，放到最后。建议按下面的对照顺序改，每改一项只看一行关键日志。

执行顺序建议是：先确认量化位宽确实生效，再看权重加载阶段是否还贴近上限；如果单卡放不下，再加张量并行，观察各卡显存是否均衡；流水并行留到前两项都不足以解决时再动。每改一项，都要保证进程完全退出并重新加载，不能只改配置热重启。

用最小请求验证配置真的生效

配置改了但进程没重新加载，是这类问题里很常见的误判。服务起来后先用一条极短请求走通，把输出长度上限设小，减少无关变量：

curl -s http://127.0.0.1:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "agents-a1",
    "messages": [{"role": "user", "content": "你好"}],
    "max_tokens": 16,
    "temperature": 0
  }'

确认生效的检查点有三个：启动日志里打印的量化位宽和张量并行度是否与新配置一致；服务启动时是否有加载权重分片的记录，而不是直接复用旧进程；请求返回后显存采样是否出现一次小幅上升。三个都对上，才能认为这次调整真的作用到了运行中的进程。

拉长多轮请求观察显存回落

只测一轮短请求很容易得出乐观结论。建议用同一个会话逐步加长输入和输出，每轮之间记录一次显存，形成可对比的序列：

轮次  输入长度  输出上限  请求后显存  空闲后显存
1     短        16        ...        ...
2     中        64        ...        ...
3     长        128       ...        ...

判断依据是：请求结束后，显存能否回落到接近本轮的基线水平。如果每轮都在基线之上叠加一小段且不释放，需要检查是否有请求上下文未清理、缓存池配置过大或并发残留；如果显存能回落但峰值随长度明显抬升，属于正常现象，此时应关注峰值是否接近上限，而不是只看空闲值。多轮记录做完，再决定是否回头调整量化或并行配置。