6天挂4个模型：自养Agent免费模型池的日志驱动运维与容灾实践

做自养Agent以来最折腾我的不是Agent本身的业务逻辑而是喂给它的模型资源池。我维护了一个免费模型池初始凑了10个模型结果6天时间挂了4个。这帖子就把整个过程复盘一遍——包括模型池怎么搭、日志怎么记、挂了之后怎么从日志里定位问题以及后续怎么做了自动切换和熔断。先说背景。我所谓的“自养Agent”不是用现成的对话平台而是自己部署的一套定时触发的智能体框架每天按计划任务去抓取信息、调用模型做摘要和结构化输出再把结果回填到自己的知识库里。这种Agent对模型的需求是量大、便宜、容忍偶尔失败所以免费模型池是绕不开的选项。也正是因为它量大日志和分析就变得特别重要——不然模型挂了你只会看到结果不对却没法定位到底哪一环出了问题。如果你也在自己喂Agent手头有一批模型资源或者准备搭一个免费池子这篇文章可以直接帮你少走弯路。我会把场景、日志结构、排查路径和自动容灾方案都拆开讲清楚。1. 先说说自养Agent的部署结构和日志规划1.1 我为什么选择“多模型冗余池”而不是单模型自养Agent的核心矛盾和普通应用不一样普通应用追求单次请求质量Agent追求的是批量任务的稳定吞吐。我跑的任务大多是“每天定时采集内容然后让模型做摘要、分类、抽取关键词”单条任务失败可以重试但整体Pipeline不能因为某一个模型限流就卡死。所以从一开始我就在架构上做了模型池。所谓池就是我把多个可用模型放在同一个路由层后面Agent只跟路由层对话路由层负责选模型。模型选择策略是简单的优先级加权质量好、速度快、免费的模型排前面备用模型排后面。这样即便前面的模型挂了请求也能自动落到下一个可用模型上。很多人会问为什么不直接用一个付费API省心又稳定答案很直接我这种每日高频调用、长期跑批的任务用付费API一个月下来费用不低。而免费模型池虽然不稳定但配合冗余和切换机制完全可以把不稳定转换成“偶尔慢一点、极少失败”代价几乎为零。1.2 日志是我后来排查“消失”的唯一线索模型池的运维和普通服务不一样你无法控制模型方的服务状态唯一的观测手段就是请求日志。所以我在搭池子第一天就做了三件事第一所有Agent调用模型的请求统一走一层封装把时间、模型名、任务ID、Prompt长度、响应码、耗时全部打点记录到结构化日志里。第二日志不进Docker stdout而是写入宿主机指定目录按天切分文件。这样出了问题我可以直接在服务器上看当天的调用记录不用翻容器日志。第三给关键任务挂了crontab定时任务任务本身和执行结果都会留痕迹方便我对照“任务执行时间”和“模型报错时间”之间的关联。现在回头看这三点恰好是后来我能在6天内快速定位4个模型失效的核心基础。如果你的Agent还没有统一的日志出口我建议先把这一步补上否则一切排查都是靠猜。2. 免费模型池是怎么凑出来的10个模型从哪来2.1 我用的四类免费模型来源这里说的免费模型不是破解或者盗用的“免费”而是各家平台公开的免费档、试用额度、开源模型本地部署这几类。我筛选下来大致分四拨第一拨是本地开源模型。我用Ollama跑了一些小尺寸的模型比如qwen2.5:7b、llama3.1:8b这类。这类模型不占外部API额度免费且完全自主可控缺点是速度和效果不如云端大模型但做摘要、分类这种中等难度任务完全够用。本地模型一共占了池子里的3个名额。第二拨是国内云厂商的免费额度。现在几家大模型平台对新用户和开发者都有免费试用资源有的是赠送token有的是限时免费调用部分规格。我把这类额度接进池子作为云端主力。这部分的坑后面细说因为很多额度不是永久性的到期或者用超就直接404或者限流——我这次挂掉4个模型有一半是倒在这上面的。第三拨是公开评测/开放接口模型。有一些社区维护的开放接口提供了基于开源模型的免费推理服务经常有模型可以白名单调用。这类适合做补充但稳定性更差。第四拨是缓存和服务端自建的模型别名。比如有些网关自带“免费版”映射把某个模型映射到较小参数量版本上。这种我也挂了1个。2.2 接入时做了统一抽象10个模型来源各不相同接口地址、API格式、鉴权方式都不一样。我没有为每个模型单独写一套调用代码而是统一把它们转成OpenAI兼容的接口格式再起了一个极简路由层。每个模型在配置里就是一个条目核心字段包括name模型别名、base_url接入地址、api_key密钥、model实际模型名、weight权重、timeout超时时间、max_retries最大重试次数。Agent调用时只需传一个逻辑模型名路由层根据权重挑一个真实模型发出请求。这一步非常关键因为各家模型API风格不一致如果没有统一抽象后面做自动切换和日志统计都会很痛苦。统一成OpenAI格式之后我只需要关心每个模型的服务质量而不需要关心它们底层是什么协议。2.3 初始10个模型的构成明细初始池子配置大概是这样的序号模型别名来源类型用途倾向1local-qwen7b本地Ollama高效摘要2local-llama8b本地Ollama备用路由3local-qwen32b本地Ollama复杂推理4cloud-a-free云厂商A免费档日常主力5cloud-b-free云厂商B免费档日常主力6cloud-c-trial云厂商C试用额度批量处理7open-v1开放接口1辅助分类8open-v2开放接口2辅助生成9gate-free1网关别名1低优先级10gate-free2网关别名2低优先级这个结构看着像模像样但之后的6天就是它给我上了一课免费池里的模型不是“可用资源”而是“动态资源”你需要接受它们的生命周期非常短这个事实。3. 6天少了4个模型完整时间线和日志证据3.1 前3天限流和响应劣化是第一批信号第1天到第3天池子表面上是稳定的但日志里已经出现了一些值得警惕的信号。最明显的是HTTP 429限流频率逐步上升。我做了一套失败计数逻辑单模型连续失败3次会被暂时标记为“inactive”并切换流量。第1天只有零星429基本是某个时间点并发上来触发的重试两次就恢复了所以我没太在意。到第2天429开始集中在某一个云厂商免费档上而且重试后仍间歇失败。我当时判断是“平台的分钟级限流”在代码里把该模型的并发和退避时间调了一下。第3天从日志里看到该模型的平均响应时长从原来的2秒左右涨到了6秒以上甚至出现了读超时。这时我意识到免费额度的服务优先级通常会被平台降低慢是常态。但我还指望它撑几天没做下线处理。3.2 第4到第6天报错集中爆发4个模型先后退出第4天开始情况就不一样了。先是cloud-b-free这个模型开始成批返回401。查了日志错误信息是invalid api key。我一度以为是密钥配置出了问题后来去对应平台看了才知道新用户赠送的试用额度到期后旧密钥直接被吊销不是限流是账户层面的资源停止。这个模型从日志角度来看就是“突然不可用”没有任何梯度过程。同一天下午open-v2也开始出问题报的是404 model not found。这个更麻烦因为接口本身是好的但平台把免费模型下线并调整了模型名称。也就是说我配置里的model字段已经失效要么改名要么换新模型。第5天cloud-a-free也开始出现限流但这次不是429而是返回一个业务错误码大意是“当前模型不在免费范围内”。这说明平台把免费档调整了原本免费的模型被我那天的高频调用触发到付费检查。总而言之免费额度缩水了。第6天我例行看统计日志时发现池子里能成功返回的模型只剩6个了——10个里挂了4个其中2个是完全401/4041个是额度到期1个是被移出免费档。本地Ollama那3个倒是稳如泰山一台破机器扛住了所有压力。3.3 从日志数据看这4个模型的“消失方式”我把这4个模型的失效类型整理成了表格方便对照你手头日志里的错误码模型失效前主要错误失效判定根因归类cloud-b-free401 invalid key密钥吊销额度到期型open-v2404 model not found模型不存在模型下线型cloud-a-free业务错误码免费范围调整范围收紧型gate-free1429 超时连续不可用限流劣化型这四种类型基本包含了免费模型池中“模型消失”的所有常见形态。它们有一个共同点外界不会给你发任何下线通知唯一能感知到的方式就是日志里的错误码和响应时间变化。所以我后来经常跟朋友说免费模型池运维的本质是“日志驱动型运维”。4. 日志排查的实战从crontab日志到模型调用日志4.1 先确保所有日志能对上时间线排查这次事故我用了三部分日志Agent任务日志、模型调用日志、系统crontab执行日志。三者缺一不可。Agent任务日志记录的是每个任务什么时候启动、什么时候结束、输出是什么。模型调用日志记录的是每一次模型请求的细节。crontab日志则用来确认定时任务本身有没有漏跑、跑了几次。对照这三者的时间戳我才敢下结论说“某个模型在某个时间点开始不可用”而不是单纯猜测。具体到文件层面我的做法是模型调用日志/var/log/agent/model_access.log按天切割每条一行包含请求时间、模型别名、HTTP状态码、耗时Agent业务日志/var/log/agent/agent.log记录任务级信息Crontab执行痕迹/var/log/agent/cron_records.log通过脚本在任务开头和结尾各打一条标记这样即使某天系统重启过我也能凭时间戳还原故障现场。4.2 查看crontab执行日志的三个技巧很多新手在排查“定时任务明明配了为什么没跑”时都会卡住。这里分享三个我实测有用的技巧。第一个crontab本身不写统一日志不同发行版位置不同。Debian/Ubuntu看/var/log/syslogCentOS看/var/log/cron。直接grep CRON /var/log/syslog | tail -50就能看到最近的执行记录。第二个把任务的输出重定向到一个独立文件。比如0 8 * * * /opt/agent/run_daily.sh /var/log/agent/cron_records.log 21这样不用翻系统日志也能看到每次任务的标准输出和报错。第三个如果是容器内跑crontab要注意容器重启后cron服务不一定自动拉起。我在服务器上加了健康检查看pgrep cron是否存在没有就自动重启它。这个细节帮我避免过一次“日志缺失”的假象。4.3 从日志片段识别模型的死亡前兆这次事故里我在日志里看到了几个规律性的信号这里挑两个典型的片段说。第一个片段同一模型在几分钟内从200变成429再变成200然后又429。这是典型的“限流抖动”。我用颜色标注了这类记录看趋势能发现某平台免费额度在下行。遇到这种情况不要只调重试参数要开始准备替补模型。12:01:02 [INFO] modelcloud-a-free status200 latency2130ms 12:01:03 [INFO] modelcloud-a-free status429 latency18ms 12:01:04 [WARN] modelcloud-a-free retry1 12:01:06 [INFO] modelcloud-a-free status200 latency4112ms 12:01:07 [INFO] modelcloud-a-free status429 latency15ms第二个片段同一个模型短时间连续报不同错误码从429变成400再变成404。这种“错误码漂移”通常意味着模型条目本身有问题不是单纯的限流。12:20:01 [ERROR] modelopen-v2 status429 coderate_limit 12:20:05 [ERROR] modelopen-v2 status400 codeinvalid_parameter 12:20:09 [ERROR] modelopen-v2 status404 codemodel_not_found遇到第二类片段基本可以直接把这个模型从池子里摘除因为它已经不是“临时不可用”而是“永久消失”了。如果继续留在池子里不仅本身浪费重试机会还可能导致任务整体超时。5. 模型池的容灾设计自动切换、熔断和健康巡检5.1 流量自动切换策略模型池的容灾核心不是把模型修好——你修不好别人的服务——而是把流量导到还活着的模型上。我的路由层实际执行三个动作动作一是失败计数。每次请求失败该模型失败数加1成功则减1按滑动窗口维护。当一个模型的失败率超过50%且样本数大于10时它被标记为“half-open”状态自动间歇降权。动作二是熔断降级。连续失败达到5次直接熔断5分钟。熔断期间所有本该发给它的流量按权重发给其他模型。动作三是优先级漂移。每个模型有一个动态得分等于“基础权重除以近期失败率”。这样即便某个模型设置的是高优先级一旦失败率飙升它也会自动排到后面去。这套逻辑不复杂但非常管用。4个模型失效的时候我基本没有手动干预所有任务都是靠剩余模型撑过来的。唯一的代价是部分任务耗时变长、输出质量略降。5.2 健康检查驱动的自动剔除光靠路由层的失败计数还不够因为某些模型在低频调用下不会暴露问题。我加了一个专门的健康检查脚本定时跑起来对池子里所有模型发一条极小的探针请求比如“返回OK”然后记录响应码和延迟。这个脚本挂在crontab里每10分钟跑一次。每次执行都会生成一条JSON结构的记录包含每个模型的可用状态。如果连续3次健康检查都失败脚本会把模型从主动路由名单中移除并发一条告警通知。这里有个细节探针请求也走生产请求的同一个路由层和密钥体系这样测出来的结果才是真实可用的。用单独的测试key测出来的“可用”不能代表线上真实状态。5.3 密钥、额度和到期时间的管理这次挂掉的4个模型里有2个和密钥、额度直接相关。做免费模型池密钥管理不能随手往配置文件里塞。我的做法是把每个模型的base_url、api_key、到期日期放在一个独立的环境变量文件里代码运行时加载不要把密钥提交到代码仓库。同时维护一个到期清单每个模型的额度到期日期都记上到期前3天自动提醒。有人会问有些平台根本没给到期日期怎么知道什么时候到期我的经验是优先看平台控制台或开发者文档里的“额度有效期”字段找不到的话就用历史调用日志自测——连续两天出现401基本可以判定密钥失效直接排查到对应平台。5.4 免费模型池的容量策略模型池的容量管理我后来定了个规矩池子里至少保留8个模型云端免费模型不少于4个本地模型至少2个。少于这个数就触发“补充模型”告警。算一笔账可以说明为什么定这个数假设单个免费模型的月可用率是70%这是真实水平单模型故障概率确实挺高。但如果池子里有8个模型路由层每次调用只随机挑一个只要有一个模型活着就能完成任务。8个里全部挂掉的概率是0.3的8次方几乎不可能。关键是保证数量冗余而不是让每个模型都100%稳定。6. 免费模型池运维的常见问题和避坑经验6.1 典型问题速查问题现象大概率原因优先排查路径突然大量401key被吊销/额度到期看平台控制台查密钥状态突然大量404模型被下线/改名看接口文档确认model字段持续429免费额度触限降并发换备用模型响应时间暴涨平台对免费档降优先级记录延迟准备切换偶发500平台内部故障重试1-2次失败熔断任务没跑cron服务没拉起检查crond进程和crontab日志6.2 几条实际操作中总结的经验第一条不要信仰任何一个免费模型。我今天觉得某某模型稳定可能在明天就没了。免费池的运维心态应该是“把每个模型当作临时工”而不是“把它当固定资产”。所以在设计上不要对任何模型做硬编码或写死逻辑一切通过配置化和路由层调度。第二条日志和告警的重要性高于模型本身。模型可以随便换但你要知道它什么时候挂的、为什么挂的靠的就是日志。我这次能把4个模型的失效原因逐一还原完全仰仗日志设计做得好。如果你的Agent还没日志请一定从今天开始补上不然等于闭着眼开车。第三条免费模型的“有效生命周期”比你想的短。从我这次的数据看10个免费模型6天内失效4个半衰期不到10天。这意味着免费池的巡检频率至少要按天来而不是按月。可以设计一个每日自动巡检报告早上看一眼报告就知道哪些模型昨晚开始不稳了。第四条本地模型是最后的避风港。6天里唯一让我踏实的是本地那3个Ollama模型。不管外部免费额度怎么变本地模型永远在线。虽然能力弱一些但是在关键任务上兜底我觉得比云端的免费额度更可靠。建议自养Agent到后期资源充裕的话务必准备一个本地模型作为“地基”模型。6.3 从这次事故里学到的调度心得过去我只把“模型池”当成一个简单的资源集合现在我会把它当成一个需要持续治理的系统。所谓治理就是三个循环第一准入循环。新模型入池前先跑一天探针确认错误率和延迟达标再放量到生产流量里。第二巡检循环。每天自动跑健康检查更新每个模型的可用状态生成可用性报表。第三淘汰循环。连续挂了或劣化超过阈值的模型自动摘除并进入“冻结”状态等平台修复后再重新评估是否入池。这三个循环看起来很机械但正是这种机械让我在模型池只剩6个可用模型时还能保证Agent业务基本不受影响。自养Agent本来就够折腾了能把模型资源的稳定性管理做到“让它在后台自动转”你就可以把精力放在Agent的业务逻辑本身。最后再说一点免费池这东西本质上是用自己的运维时间换成本。如果你没有精力做日志和巡检那我建议还是老老实实买付费API。你图免费省下的钱最后可能会在排查事故的加班里加倍还回去。我自己现在跑着的池子仍然保留着免费和本地混合的模式但每次新加模型第一件事永远是写日志配置、挂上探针。毕竟这次的6天4个只是开始模型池的维护是日常活不是一次性的。