为什么本地代理不应在显存中保持所有模型热加载：来自代理循环的实际数据

在构建一个处理语音、屏幕观察和工具执行的自主本地代理时，天真架构是让每个模型服务器在后台运行。我在一个本地工作站上测试了这个设置，运行四个组件： - Qwen3.8-27B（规划和工具调用） - Nemotron（语音输入） - Chatterbox（语音输出） - Unlimited-OCR（屏幕和图像读取） 空闲内存消耗达到122 GB。在任何任务开始之前，GPU就已经被占满。 实际上，代理循环是基于回合和顺序的： - 在语音交互期间，OCR不需要占用GPU内存。 - 在图像解析期间，音频模型无所作为。 - 关键是，当代理决定运行Python脚本、网页抓取或bash命令时，LLM可以等待几秒或几分钟让脚本完成，而无需活跃的GPU资源。 我建立了一个基于Rust的守护进程来控制代理循环中的休眠状态。当工具或模态不活跃时，它会被置于休眠模式。 休眠前后的空闲GPU使用情况： 模型 原始空闲GPU，9月1-2日（MiB） 休眠模式后，9月5日（MiB） 差异（MiB） LLM（Qwen3.8-27B） 87,443 39,092 48,351 STT（Nemotron） 10,385 267 10,118 TTS（Chatterbox） 17,947 3,127 14,820 OCR（Unlimited-OCR） 6,592 422 6,170 总空闲内存从122.3 GB下降到42.9 GB。 关键要求是延迟：如果唤醒模型需要3到5秒，语音来回交互会感觉中断。因为守护进程丢弃暂存/KV分配，而不是从存储进行冷重启，所有四个模型的唤醒延迟都低于200毫秒。如果你在单节点硬件上构建本地代理循环，动态休眠状态使得在一个设备上运行4个以上模型完全可行。