想把 IQuest-Q1 放在本机跑 Agent，先别急着调提示词，先把两个数字量清楚：一是空闲状态下的显存基线，二是长上下文时的显存峰值。这两个数字决定了你能挂多少工具、留多长的对话历史、并发能给到几路。只看“参数不大”或“显存够用”这类描述通常判断不准，因为系统桌面、其它常驻进程、KV cache 都会各吃掉一块。

IQuest-Q1 能不能本地跑 Agent，取决于两个可测的数字：空闲基线显存与长上下文峰值显存。先记录基线，再用同一提示词分别跑短、长上下文，最后按“总显存 − 基线 − 安全余量”回推模型可用预算。预算不够时，先缩上下文，其次降精度，再考虑换规格或换设备。

记录空闲状态下的显存基线占用

基线的作用是把系统和其它进程的占用从模型占用里剥离出来。建议在刚开机、还没加载 IQuest-Q1、也不跑其它显存任务的窗口期记录；机器上有浏览器、IDE 或常驻推理服务时，最好先关掉再记录，否则后面算预算会高估可用显存。

# NVIDIA 显卡
nvidia-smi
nvidia-smi `--query-gpu`=memory.total,memory.used,memory.free `--format`=csv,noheader

# 想持续观察，可以间隔采样（-d 高亮变化）
watch -n 2 -d nvidia-smi

取值时机：等桌面和常驻服务稳定后再读，不要取刚开机那一瞬的数字；间隔一段时间读三次，取比较稳定的那个值作为基线。把结果填进这张表：

如果两次读到的“已用”差异明显，说明还有别的进程在动，先找出它再往下测。AMD 平台可以换用 rocm-smi 之类的工具；统一内存架构的机器口径不同，需要单独确认。

用短上下文与长上下文各跑一次并比较峰值

这一轮只改上下文长度，其它条件尽量一致：同一个提示词开头、同一套启动参数、同样的批量大小。峰值显存的取值时间点建议定在“生成过程中轮询到的最大值”，而不是模型刚加载完那一刻——KV cache 随对话增长而涨，只看加载瞬间会低估。

# 轮询采样，输出到文件后取最大值
nvidia-smi `--query-gpu`=memory.used `--format`=csv,noheader -l 1 | tee peak.log

如果推理框架暴露了运行时的显存统计接口（常见命名类似 max_memory_allocated），也可以用它取峰值；两种方式选一种并全程保持一致，不要混用。把两次运行填进同一张表：

比较时看峰值差值和耗时差值两条线：长上下文峰值明显抬高，说明留给并发和长对话的空间被 KV cache 吃掉了；耗时同步变长，Agent 里多轮工具调用的体感会变差。

调整精度或量化配置后再测一轮

降配的入口通常是启动参数，也可能是配置文件里的字段。不同实现的参数名不一样，常见命名包括 dtype、quantization、load_in_8bit / load_in_4bit、max_model_len 之类；先确认你手上这套的启动脚本里实际写的是哪一个，再动手改。

# 骨架示意，按自己的启动方式替换路径与参数名
python serve.py `--model` /path/to/IQuest-Q1 `--dtype` float16 `--max-model-len` 8192
python serve.py `--model` /path/to/IQuest-Q1-awq `--dtype` auto `--max-model-len` 8192

对比方式是把上一张表扩成“配置 × 指标”：每换一次配置，重跑同一组短、长上下文，记录峰值显存、能开到的最大上下文和生成耗时。要关注的是省下来的显存能否换回一段可用的上下文，而不是只看显存数字变小——量化权重有时会在长上下文上更早触顶，回答稳定性也需要单独看一遍。

把实测占用与本机可用显存对齐

换算口径建议统一成一句话：模型可用预算 = 总显存 − 基线已用 − 安全余量。安全余量按机器情况留，图形桌面、显示器输出、其它进程都会临时占用，留得太紧容易在长对话中途失败。

设总显存为 T，空闲基线已用为 B，安全余量为 M
模型可用预算 P = T - B - M

再把长上下文那一次的峰值 V 代进去：
  若 V 明显小于 P，剩余部分可用于并发和更长的对话历史
  若 V 接近或超过 P，先缩上下文，不要先加并发

Agent 场景比单轮问答更吃余量，因为工具调用的输入输出会持续累积进上下文。预算不够时，最先被牺牲的通常依次是：上下文被截断（对话历史或工具返回值被裁掉）、并发降为 1、请求排队甚至加载失败；再往后才是把部分计算卸载到 CPU 或内存，代价是速度明显下降。先保功能可用，再谈速度。

决定继续本地跑还是缩配置

把上面的数字对齐后，结论通常落在几条路径上，按“先动配置、后动硬件”的顺序试：

• 缩短上下文：把 max_model_len 或等效参数调到实测能稳住的长度，配合在应用侧做历史裁剪和工具返回值摘要。代价是长任务容易丢上下文，需要自己设计记忆与摘要策略。
• 降低精度或换量化权重：省出的显存用于更长上下文或并发。代价是回答稳定性要重新看一遍，长上下文下的表现需单独测。
• 换更小规格的权重：同一套 Agent 逻辑换到小模型上，显存和速度都更好估。代价是复杂工具调用和长链推理的成功率可能下降。
• 换设备或把推理放到别处：加显存、换机器，或让本机只跑轻量部分。代价是成本与部署复杂度上升，本地数据不出机的优势也会受影响。

判断标准可以很简单：如果长上下文峰值加上基线，仍在总显存之内且留有安全余量，就可以继续本地跑 Agent；如果已经贴着上限，就先缩上下文或降精度，再决定要不要换设备。数字量清楚了，后面的取舍才有依据。