在跑 DeepSeek Harness 的第三个月我遇到过一次典型的“三高”现场任务成功率 97.8%看起来不错但耗时曲线的 P95 从 60 秒一路拉高到 240 秒成本账单同步涨了快三倍。最初判断是模型端变慢结果查了半天真正原因是集群里有一条登录失败在作祟——Login Server 的鉴权服务返回了 token exchange failed上层 Runner 认为这是可恢复错误于是一遍又一遍地重试每重试一次都会完整走完调度链路并产生一次调用开销。这个项目本身说白了就是一个把海量 Prompt、模型版本、插件和批量任务粘在一起的编排层负责分发任务、管理并发、处理鉴权、打捞失败、核算成本。它在小规模实验阶段很“省心”几台机器就能跑得风生水起一旦进入规模化批量运行耗时、成本、失败三个数字会开始互相污染你会发现仪表盘上每个指标都亮着红灯却说不清最先崩掉的是哪一个。这篇文章把我这段时间的完整排查经验整理出来。适合正在用类似 Harness 编排层做批量评测、批量生成或者把模型调用封装成内部服务的团队参考。里面的方法论不挑具体工具即使你是自己写的调度脚本同样适用。1. 先把表象拆开耗时、成本、失败是同一根链条上的三个截面很多人遇到“三高”时会下意识分头排查耗时高了去看模型响应成本高了去看 Token 用量失败率高了去看报错日志。这样做不是不行但效率极低。因为在一个批量编排系统里这三个指标经常是同一个故障在三个截面上的投影。我自己总结的一个类比是失败率是事故发生频次耗时是事故影响范围成本则是事故账单。如果你只盯着账单金额永远想不明白为什么 Token 消耗对不上业务量只盯着耗时曲线也发现不了真正的问题源头是重试风暴而不是模型变慢。1.1 三个指标互相“污染”的典型链路以我遇到的那次故障为例完整链路是这样演化的某台执行节点上的登录服务因为本地文件权限异常启动后无法正常写入令牌缓存。批量任务调度到该节点后调用模型第一次鉴权就失败返回 token exchange failed。Runner 把该错误标记为“可恢复”触发自动重试并按指数退避策略排队等待。随着新任务源源不断进入队列排队积压越来越严重P95 耗时被大幅拉高。成本侧的计算逻辑又把每次失败重试的调用成本计入总账账单金额直接翻倍。这个链路里初始故障只有一个——登录服务的本地权限问题。但最终呈现在仪表盘上的是耗时飙高、成本翻倍、失败率抬头三个完全不同的表象。分开查意味着你要在三套日志系统里反复横跳查到最后可能才发现是同一个根因。1.2 Harness 层面必须建立的“统一事实入口”在规模化运行之前单人调试时可以对着一个屏幕看所有任务。但任务量到几千、上万个批次后你根本不可能靠肉眼扫日志。我建议在 Harness 的埋点设计上建立一个基本原则一个任务task_id从提交到终结的完整生命周期必须能在同一张表或同一个日志流里被完整还原。具体需要记录的核心字段如下任务维度task_id、请求来源、业务标签、调度批次号、最终状态成功/失败/取消。调用维度模型名、模型版本、Prompt 版本、上下文窗口摘要、输入 Token 数、输出 Token 数、缓存命中 Token 数。阶段维度入队时间、调度时间、每个阶段开始/结束时间、重试次数、失败阶段名。成本维度本次调用的预估成本、重试导致的额外成本、缓存节省的成本。字段落齐了后续聊耗时、成本和失败才算有共同语言。不然你排查耗时看一套日志算成本看另一套账单分析失败又去检索另一个系统三套数据对不上所有分析都等于白做。2. 耗时排查的正路从请求入口到 Token 输出逐段做时间账耗时问题在规模化阶段最常见的错误操作就是直接看“任务总时长”。总时长只有一个数字它回答不了任何问题。正确姿势是把一次任务从提交到最终结束切成多个阶段分别计时间账然后看时间最不合理的那一段。2.1 单条任务至少要拆成六个阶段无论 Harness 内部实现多复杂一次完整的模型调用任务通常可以拆成下面这些阶段阶段起点终点常见耗时异常原因入队与调度请求进入队列任务被分配给具体 Executor队列积压、调度器吞吐不足预处理与上下文构建Executor 接收任务Prompt 构建完成Tokenizer 过慢、检索器延时模型调用发起推理请求收到完整响应网络连接排队、限流退避、模型响应慢后处理与校验收到响应输出校验通过Schema 校验逻辑过重、JSON 解析异常结果落库校验通过写入存储成功数据库连接池打满、磁盘 IO 抖动回调与通知状态变更回调链完成插件回调阻塞、外部 Webhook 慢我把每个阶段的开始和结束时间都埋进结构化日志格式类似这样{ task_id: dsh_20250611_00001, stage: model.invoke, started_at: 1718092800123, ended_at: 1718092805321, duration_ms: 5198, retry: 2, model: deepseek-chat, prompt_tokens: 1240, completion_tokens: 320, status: partial_failure }有了这批数据耗时分析就变成 SQL 查询问题了按阶段聚合 sum 和 avg算 P50/P95/P99再按业务标签分组对比。不用上什么高级 APM 工具日志采集 简单聚合就能定位大部分问题。2.2 我见过最坑的“假耗时”把重试当正常耗时刚把阶段打点做完时我在统计模型调用时间时被坑了一次。某类任务在高峰期 P95 稳定在 150 秒左右乍看是模型响应太慢。翻了明细日志才发现大量任务命中限流后自动重试了 4 到 6 次每次等待退避时间 10 到 30 秒不等。这些重试等待时间被计入了阶段耗时但它反映的并不是模型真实性能而是流控策略和重试策略的叠加效果。解决方案是统计时把retry 0和retry 0的样本拆开分别算分位数。重试多次的任务单独画一条曲线重点观察它们的失败原因占比。这个动作帮我发现了不少并发控制问题——比如连接池过小导致请求排队排队到超时超时触发重试然后进一步加剧连接池压力。2.3 从“慢请求”定位到“坏链路”的排查顺序耗时异常时我的排查顺序很固定先排除环境因素再看 Harness 内部查是否有大任务占满并发槽位导致小任务排队时间飙升。查限流和重试事件是否在同一时间段集中出现若出现则先用错误日志定位触达限额的原因。查模型 Provider 侧的分位时延是否同步抬升如果 Provider 侧正常说明慢点在 Harness 内部。查 Executor 所在机器的 CPU、内存、磁盘 IO 和网络连接数排除基础设施瓶颈。最后才查单条样本的模型响应本身是否出现长尾。这套顺序本质上是在做“洋葱式剥离”从最外层能看到的现象开始逐层向内先排除容易忽略的系统性因素再深入业务逻辑。多数时候耗时异常并不是模型本身变慢而是排队、重试、上下文过长这三个编成层因素在互相叠加。3. 成本核算不是看总 Token 数建一本地账看清每一笔钱都花在哪DeepSeek Harness 这类工具的计费逻辑并不复杂但规模化后成本构成会迅速超出“Token 数量 × 单价比”这个简单的估算。你必须把成本拆成几层账本来管理否则月底账单出来后你再想定位是哪批任务烧了钱基本来不及了。3.1 成本的三层账本我实际跑批时会把成本分成三层第一层是调用成本即真实发给模型 API 的输入、输出 Token 费用这部分按单价 × 用量计算即可。第二层是无效成本包括失败重试产生的费用、中途退出但已消耗上下文窗口的费用、后处理不合格被丢弃但已经完整生成的费用。第三层是基础设施成本Harness 运行所在机器的算力、存储、网络带宽以及编排调度本身的 CPU / 内存开销。最危险的是第二层。因为它不像网络请求失败那样有显著的错误码而是“看似成功完成了一次调用结果却没进入有效结果集”属于典型的隐性成本。比如一个输出校验失败的任务模型完整生成了几百个 Token这些 Token 费用已经被计入账单但结果却被直接丢掉而且下一次重试还会再次花一遍相同的钱。每条调用日志里我建议加上cached_tokens、cost_estimate和effective三个字段。当任务的最终状态为失败或无效时把effective标记为 false这样月底汇总就能直接算出“本月无效成本占比”用来评估失败治理的优先级。3.2 不同调度拓扑下的故障、扩容与成本特点排查规模化问题时很多人会忽略一个因素Harness 内部的调度拓扑结构会直接影响故障扩散范围、扩容难度和成本曲线的形状。我整理过一张常用拓扑的对比在方案评审时非常实用拓扑结构特征故障特点扩容特点成本特点星型一个中心节点负责分发多个执行节点接收任务中心节点故障则全局不可用执行节点故障只影响局部扩容执行节点很快中心节点容易成为瓶颈控制面成本低任务增长时成本接近线性适合大多数批量评测树型多层结构上层节点汇总下层节点执行单分支故障不太扩散但根节点故障影响面很大按层级扩容灵活子节点扩缩容很自然两层以上任务可能出现重复处理同一结果的成本需要做去重总线型共享消息通道多个执行器订阅任务通道压力大单个消费者处理慢会拖累整体增加消费组数量和分区数即可相对平滑消息积压会导致任务超时并触发重试积压期成本虚高环型节点按序接力每个节点处理完传给下一节点某个节点故障时任务中断定位困难扩容需要重新规划环路麻烦链路长且串行单任务成本高实际工程中很少用于批量模型调用网状任意节点间均可直连灵活度最高故障传播路径极复杂几乎无法靠人工梳理依赖关系扩容容易但节点数增加后连接关系呈平方级膨胀同一任务可能被多个节点并发触发隐性重复成本很高对于普通批量评测场景星型和树型就足够了网状结构只在少量复杂的 Agent 链路中值得使用否则故障定位成本会远高于它能带来的灵活性收益。3.3 成本优化最重要的是缓存命中与批处理窗口实现成本显著下降的手段通常不是去压低模型单价而是调整 Harness 侧的任务组织方式。我这边两个最有效的动作一是把“重复前缀”利用好。同一业务线、同一版本模型的 Prompt 若存在大量共享前缀批量提交时缓存命中率会明显上升。缓存命中的 Token 计费远低于完整计算所以我在 Harness 里特意加了“批处理窗口”——把同一批共享系统提示词和上下文样本尽量安排在同一个时间窗口内提交而不是零散地随到随发。二是把重试次数上限死死按住。按我的经验很多成本超标案例中重试消耗的 Token 费用能占到总费用的 30% 以上。给重试设置明确的上限比如最多 3 次超限后直接进入人工处理队列成本会立刻降一个台阶。4. 失败不是单一状态错误分层、重试策略与“失败舰队”规模化任务跑起来之后每天都会产生成百上千条失败记录。如果每个失败都走同一套重试逻辑要么浪费大量时间要么直接熔断把本来可恢复的临时故障也打成不可用。所以我建了一套错误分层体系按层决定处置策略。4.1 按错误来源把失败分四层我通常把失败样本按错误来源分成四类实际处理策略差别很大错误层典型案例首次处置建议是否建议自动重试环境与服务层Login Server 启动失败、权限拒绝、Token 交换失败、Docker 服务未启动、依赖安装失败先修环境再重放任务不建议直接重试环境未修复时重试只会反复失败模型与 Provider 层限流429、连接超时、上下文长度超限按指数退避策略稍后重试可以重试但必须设置次数上限并加上抖动数据与校验层输出不符合 Schema、期望 JSON 解析失败、工具返回字段缺失收集样本进入人工复核队列不建议重试重试大概率还会得到同类结果框架与代码层插件崩溃、数据库写入失败、磁盘空间不足修复 Harness 或插件 Bug 后重放视具体原因决定代码 Bug 未修复前重试无意义登录失败这类“环境和服务层”错误在第一批跑规模化任务的人手里是最容易浪费时间的。比如登录失败报错failed to start login server或者更具体的“以一种访问权限不允许的方式做了一个访问”通常都指向 Login Server 想监听某个本地端口或写某个目录但当前进程没有足够权限或者端口被占用。遇到这类报错我的处理顺序是先查端口占用再查进程运行身份最后查日志目录和工作目录的写权限。把服务改成以管理员权限启动或者换到非系统保护目录下运行问题大概率能解决。Token exchange failed 这类错误通常是上游 Login Server 根本没起来或者令牌缓存读不到先恢复服务再谈别的。4.2 重试策略必须区分“可恢复”和“永久失败”自动重试不是越多越好。最好的做法是在 Harness 里给错误码打上“可重试性”标签限流和网络超时可以重试权限错误、Schema 校验失败、参数非法这类永久性错误不应该重试直接进入失败样本集。重试参数上我建议采用指数退避加抖动第一次等待 1 秒第二次 2 秒第三次 4 秒最大间隔不超过 30 秒并在每次退避时加上 0 到 500 毫秒的随机抖动避免所有失败请求在同一时刻集中冲击上游服务。4.3 用“失败舰队”替代无脑重试所谓失败舰队是我从测试行业借来的概念。当某一个 Prompt 样本、模型版本、输入上下文的组合连续失败达到阈值我这边设置为同一模板失败 5 次Harness 就不再把它们当普通任务反复重试而是自动把这一整组相关样本捞出来单独形成一批“疑似问题集”打上标签供人工抽检。这个机制极大减少了无效重试也帮我快速圈定模型版本回退的决策范围。比如有些输出校验失败表面上是“模型没听懂指令”实际是某个系统 Prompt 模板升级引入了格式冲突。失败舰队能让你一眼看到一个模板 ID 下的失败密度远高于其他模板从而快速定位到最近的变更。5. 把三类排查合成一套观测体系指标、日志、追踪的配合方式耗时、成本、失败分开查效率太低这件事的根本解法是在 Harness 里建立指标、日志、追踪三位一体的观测体系。很多自建平台在这块做得不够一个重要原因是三套数据来自不同系统指标取自监控面板、日志打印在文本文件、失败数据散落在任务表联查时需要人工用 task_id 在三个系统之间来回搬运。5.1 最小可用的三件套指标层负责回答“有多少”。比如失败任务数、任务耗时 P50/P95/P99、重试次数分布、Token 消耗速率、预估成本累计值。日志层负责回答“为什么”。每次任务的关键阶段都要输出带 task_id 的结构化日志并记录重试事件和错误码。追踪层负责回答“路径在哪里”。对单条任务从入队到终结的完整生命周期做链路串接每跳都记录时间戳。在具体实现上不需要追求重型 APM 系统。把结构化日志收集到中心化日志平台再用 task_id 关联查询已经能做大部分追踪工作。甚至在 Harness 自身的数据库里建两张表——一张存任务主流程一张存阶段耗时明细——就足够支持日常排障了。5.2 规模化阶段我真正盯的阈值阈值设置没有放之四海而皆准的标准但我这边跑熟后形成了以下一组基线可以作为你制定告警规则的起点指标我采用的警戒线触发后的动作总体失败率单批次超过 3%暂停自动提交新批次优先检查错误分类重试占比超过 10% 的任务发生过重试检查是否出现限流风暴或连接池瓶颈P95 耗时超过基线值 1.5 倍以上持续 10 分钟发出告警启动耗时排查流程每任务平均 Token 消耗超过基线 2 倍检查 Prompt 是否意外膨胀、是否出现上下文重复传递缓存命中率低于 40%检查批处理窗口和共享前缀比例是否下降无效成本占比超过总成本 20%立刻审查失败重试策略与失败舰队阈值这些比例值要根据自己的任务类型微调。比如纯生成类任务的缓存命中率天然偏低不要拿评测类任务的标准去卡它。5.3 性能基线要随版本持续更新观测体系建好之后还有一个容易被忽视的动作每个模型版本、每次大版本 Prompt 模板升级后跑一轮最小回归集把耗时分位数、Token 平均用量、失败率刷新成新基线。如果不做这个上一节提到的“超过基线 1.5 倍”就无从谈起。基线不是一次性的模型升级后可能整体吞吐变化了Prompt 变长后 Token 基线也会整体移动。唯一不变的是方法本身每次变更都要记录前后对照用数据判断这次改动是优化了还是劣化了。6. 完整复盘从一次登录失败到全域任务阻塞的排查链路最后用一个完整的案例把耗时、成本、失败串联起来。这次故障让我意识到前面所有的方法论不是说教而是真金白银换来的经验。6.1 事故现场某天批量任务开跑后的第三个小时监控面板突然报警。现象如下失败率从 0.8% 缓慢攀升到 5%且持续没有回落。耗时 P95 从 70 秒涨到了 240 秒接近 3.5 倍。任务成本消耗速率比平时快了接近一倍。我们第一反应是模型 Provider 侧出了性能问题因为失败和耗时是同时出现的。但打开 Provider 侧的状态页对方各项指标完全正常。6.2 从耗时数据倒推我先拉出耗时拆解注意到任务的总耗时大头并不在model.invoke阶段而是在enqueue到schedule之间。也就是说大部分时间浪费在排队上根本没有进入模型调用。再按错误码聚合失败数据发现 92% 的失败都集中在同一个错误类——token exchange failed也就是调用模型前的鉴权令牌交换失败。6.3 找到根因顺着 token exchange 失败的报错去查 Login Server 的服务日志发现它在任务启动前就打印了一条“以一种访问权限不允许的方式做了一个访问”的错误。原因是执行账号对令牌缓存目录没有写权限Login Server 根本无法正常初始化后续所有需要交换令牌的模型调用自然全军覆没。真正的修复只有两步给执行账号授予对应目录的写权限重启 Login Server 并确认监听端口恢复正常。但在此之前Harness 的重试逻辑没有识别这类环境错误的“不可恢复”属性反复重试了将近三个小时把任务队列彻底堵死也烧掉了大量 Token。6.4 修复与验证我先暂停所有新任务的调度清空积压队列。失败任务不做直接重放而是等 Login Server 恢复正常后从失败前的检查点重新拉起候选批次。验证方式是抽 100 条此前失败的任务做灰度重放全部成功后再把剩余积压任务逐步释放。整个验证过程不到两小时耗时、成本、失败率三条曲线同时回落。这次故障给我的启发是批量 Harness 里最贵重的不是每一次调用而是调度链路上的信任。一次被错误重试风暴放大的局部故障能把整个批次的耗时和成本拖垮。你给每个失败样本设置什么样的重试策略本质上是在选择这个系统面对故障时要付出多大的代价。最后补两句实在话如果让我给准备跑规模化批次的团队一条最朴素的建议我会说先打点再优化。没把阶段耗时打点、成本字段落库、失败分类标签建好之前任何调优都是盲人摸象。而在这三件事里我会优先做失败分类因为失败会同时污染耗时和成本两个指标管住失败另外两条曲线大概率自己就回归正常了。另外别迷信仪表盘本身。仪表盘的价值是帮你更快找到问题不是代替你去思考问题。每次系统出现波动都要回到最原始的结构化日志里做一遍手动核对确保自动化链路没有把关键信息吞掉。排查规模化问题没有银弹唯一的捷径是把账记细、把链打全、把失败管住。
大规模批量任务排查实战：耗时、成本、失败的三高联动分析与治理
在跑 DeepSeek Harness 的第三个月我遇到过一次典型的“三高”现场任务成功率 97.8%看起来不错但耗时曲线的 P95 从 60 秒一路拉高到 240 秒成本账单同步涨了快三倍。最初判断是模型端变慢结果查了半天真正原因是集群里有一条登录失败在作祟——Login Server 的鉴权服务返回了 token exchange failed上层 Runner 认为这是可恢复错误于是一遍又一遍地重试每重试一次都会完整走完调度链路并产生一次调用开销。这个项目本身说白了就是一个把海量 Prompt、模型版本、插件和批量任务粘在一起的编排层负责分发任务、管理并发、处理鉴权、打捞失败、核算成本。它在小规模实验阶段很“省心”几台机器就能跑得风生水起一旦进入规模化批量运行耗时、成本、失败三个数字会开始互相污染你会发现仪表盘上每个指标都亮着红灯却说不清最先崩掉的是哪一个。这篇文章把我这段时间的完整排查经验整理出来。适合正在用类似 Harness 编排层做批量评测、批量生成或者把模型调用封装成内部服务的团队参考。里面的方法论不挑具体工具即使你是自己写的调度脚本同样适用。1. 先把表象拆开耗时、成本、失败是同一根链条上的三个截面很多人遇到“三高”时会下意识分头排查耗时高了去看模型响应成本高了去看 Token 用量失败率高了去看报错日志。这样做不是不行但效率极低。因为在一个批量编排系统里这三个指标经常是同一个故障在三个截面上的投影。我自己总结的一个类比是失败率是事故发生频次耗时是事故影响范围成本则是事故账单。如果你只盯着账单金额永远想不明白为什么 Token 消耗对不上业务量只盯着耗时曲线也发现不了真正的问题源头是重试风暴而不是模型变慢。1.1 三个指标互相“污染”的典型链路以我遇到的那次故障为例完整链路是这样演化的某台执行节点上的登录服务因为本地文件权限异常启动后无法正常写入令牌缓存。批量任务调度到该节点后调用模型第一次鉴权就失败返回 token exchange failed。Runner 把该错误标记为“可恢复”触发自动重试并按指数退避策略排队等待。随着新任务源源不断进入队列排队积压越来越严重P95 耗时被大幅拉高。成本侧的计算逻辑又把每次失败重试的调用成本计入总账账单金额直接翻倍。这个链路里初始故障只有一个——登录服务的本地权限问题。但最终呈现在仪表盘上的是耗时飙高、成本翻倍、失败率抬头三个完全不同的表象。分开查意味着你要在三套日志系统里反复横跳查到最后可能才发现是同一个根因。1.2 Harness 层面必须建立的“统一事实入口”在规模化运行之前单人调试时可以对着一个屏幕看所有任务。但任务量到几千、上万个批次后你根本不可能靠肉眼扫日志。我建议在 Harness 的埋点设计上建立一个基本原则一个任务task_id从提交到终结的完整生命周期必须能在同一张表或同一个日志流里被完整还原。具体需要记录的核心字段如下任务维度task_id、请求来源、业务标签、调度批次号、最终状态成功/失败/取消。调用维度模型名、模型版本、Prompt 版本、上下文窗口摘要、输入 Token 数、输出 Token 数、缓存命中 Token 数。阶段维度入队时间、调度时间、每个阶段开始/结束时间、重试次数、失败阶段名。成本维度本次调用的预估成本、重试导致的额外成本、缓存节省的成本。字段落齐了后续聊耗时、成本和失败才算有共同语言。不然你排查耗时看一套日志算成本看另一套账单分析失败又去检索另一个系统三套数据对不上所有分析都等于白做。2. 耗时排查的正路从请求入口到 Token 输出逐段做时间账耗时问题在规模化阶段最常见的错误操作就是直接看“任务总时长”。总时长只有一个数字它回答不了任何问题。正确姿势是把一次任务从提交到最终结束切成多个阶段分别计时间账然后看时间最不合理的那一段。2.1 单条任务至少要拆成六个阶段无论 Harness 内部实现多复杂一次完整的模型调用任务通常可以拆成下面这些阶段阶段起点终点常见耗时异常原因入队与调度请求进入队列任务被分配给具体 Executor队列积压、调度器吞吐不足预处理与上下文构建Executor 接收任务Prompt 构建完成Tokenizer 过慢、检索器延时模型调用发起推理请求收到完整响应网络连接排队、限流退避、模型响应慢后处理与校验收到响应输出校验通过Schema 校验逻辑过重、JSON 解析异常结果落库校验通过写入存储成功数据库连接池打满、磁盘 IO 抖动回调与通知状态变更回调链完成插件回调阻塞、外部 Webhook 慢我把每个阶段的开始和结束时间都埋进结构化日志格式类似这样{ task_id: dsh_20250611_00001, stage: model.invoke, started_at: 1718092800123, ended_at: 1718092805321, duration_ms: 5198, retry: 2, model: deepseek-chat, prompt_tokens: 1240, completion_tokens: 320, status: partial_failure }有了这批数据耗时分析就变成 SQL 查询问题了按阶段聚合 sum 和 avg算 P50/P95/P99再按业务标签分组对比。不用上什么高级 APM 工具日志采集 简单聚合就能定位大部分问题。2.2 我见过最坑的“假耗时”把重试当正常耗时刚把阶段打点做完时我在统计模型调用时间时被坑了一次。某类任务在高峰期 P95 稳定在 150 秒左右乍看是模型响应太慢。翻了明细日志才发现大量任务命中限流后自动重试了 4 到 6 次每次等待退避时间 10 到 30 秒不等。这些重试等待时间被计入了阶段耗时但它反映的并不是模型真实性能而是流控策略和重试策略的叠加效果。解决方案是统计时把retry 0和retry 0的样本拆开分别算分位数。重试多次的任务单独画一条曲线重点观察它们的失败原因占比。这个动作帮我发现了不少并发控制问题——比如连接池过小导致请求排队排队到超时超时触发重试然后进一步加剧连接池压力。2.3 从“慢请求”定位到“坏链路”的排查顺序耗时异常时我的排查顺序很固定先排除环境因素再看 Harness 内部查是否有大任务占满并发槽位导致小任务排队时间飙升。查限流和重试事件是否在同一时间段集中出现若出现则先用错误日志定位触达限额的原因。查模型 Provider 侧的分位时延是否同步抬升如果 Provider 侧正常说明慢点在 Harness 内部。查 Executor 所在机器的 CPU、内存、磁盘 IO 和网络连接数排除基础设施瓶颈。最后才查单条样本的模型响应本身是否出现长尾。这套顺序本质上是在做“洋葱式剥离”从最外层能看到的现象开始逐层向内先排除容易忽略的系统性因素再深入业务逻辑。多数时候耗时异常并不是模型本身变慢而是排队、重试、上下文过长这三个编成层因素在互相叠加。3. 成本核算不是看总 Token 数建一本地账看清每一笔钱都花在哪DeepSeek Harness 这类工具的计费逻辑并不复杂但规模化后成本构成会迅速超出“Token 数量 × 单价比”这个简单的估算。你必须把成本拆成几层账本来管理否则月底账单出来后你再想定位是哪批任务烧了钱基本来不及了。3.1 成本的三层账本我实际跑批时会把成本分成三层第一层是调用成本即真实发给模型 API 的输入、输出 Token 费用这部分按单价 × 用量计算即可。第二层是无效成本包括失败重试产生的费用、中途退出但已消耗上下文窗口的费用、后处理不合格被丢弃但已经完整生成的费用。第三层是基础设施成本Harness 运行所在机器的算力、存储、网络带宽以及编排调度本身的 CPU / 内存开销。最危险的是第二层。因为它不像网络请求失败那样有显著的错误码而是“看似成功完成了一次调用结果却没进入有效结果集”属于典型的隐性成本。比如一个输出校验失败的任务模型完整生成了几百个 Token这些 Token 费用已经被计入账单但结果却被直接丢掉而且下一次重试还会再次花一遍相同的钱。每条调用日志里我建议加上cached_tokens、cost_estimate和effective三个字段。当任务的最终状态为失败或无效时把effective标记为 false这样月底汇总就能直接算出“本月无效成本占比”用来评估失败治理的优先级。3.2 不同调度拓扑下的故障、扩容与成本特点排查规模化问题时很多人会忽略一个因素Harness 内部的调度拓扑结构会直接影响故障扩散范围、扩容难度和成本曲线的形状。我整理过一张常用拓扑的对比在方案评审时非常实用拓扑结构特征故障特点扩容特点成本特点星型一个中心节点负责分发多个执行节点接收任务中心节点故障则全局不可用执行节点故障只影响局部扩容执行节点很快中心节点容易成为瓶颈控制面成本低任务增长时成本接近线性适合大多数批量评测树型多层结构上层节点汇总下层节点执行单分支故障不太扩散但根节点故障影响面很大按层级扩容灵活子节点扩缩容很自然两层以上任务可能出现重复处理同一结果的成本需要做去重总线型共享消息通道多个执行器订阅任务通道压力大单个消费者处理慢会拖累整体增加消费组数量和分区数即可相对平滑消息积压会导致任务超时并触发重试积压期成本虚高环型节点按序接力每个节点处理完传给下一节点某个节点故障时任务中断定位困难扩容需要重新规划环路麻烦链路长且串行单任务成本高实际工程中很少用于批量模型调用网状任意节点间均可直连灵活度最高故障传播路径极复杂几乎无法靠人工梳理依赖关系扩容容易但节点数增加后连接关系呈平方级膨胀同一任务可能被多个节点并发触发隐性重复成本很高对于普通批量评测场景星型和树型就足够了网状结构只在少量复杂的 Agent 链路中值得使用否则故障定位成本会远高于它能带来的灵活性收益。3.3 成本优化最重要的是缓存命中与批处理窗口实现成本显著下降的手段通常不是去压低模型单价而是调整 Harness 侧的任务组织方式。我这边两个最有效的动作一是把“重复前缀”利用好。同一业务线、同一版本模型的 Prompt 若存在大量共享前缀批量提交时缓存命中率会明显上升。缓存命中的 Token 计费远低于完整计算所以我在 Harness 里特意加了“批处理窗口”——把同一批共享系统提示词和上下文样本尽量安排在同一个时间窗口内提交而不是零散地随到随发。二是把重试次数上限死死按住。按我的经验很多成本超标案例中重试消耗的 Token 费用能占到总费用的 30% 以上。给重试设置明确的上限比如最多 3 次超限后直接进入人工处理队列成本会立刻降一个台阶。4. 失败不是单一状态错误分层、重试策略与“失败舰队”规模化任务跑起来之后每天都会产生成百上千条失败记录。如果每个失败都走同一套重试逻辑要么浪费大量时间要么直接熔断把本来可恢复的临时故障也打成不可用。所以我建了一套错误分层体系按层决定处置策略。4.1 按错误来源把失败分四层我通常把失败样本按错误来源分成四类实际处理策略差别很大错误层典型案例首次处置建议是否建议自动重试环境与服务层Login Server 启动失败、权限拒绝、Token 交换失败、Docker 服务未启动、依赖安装失败先修环境再重放任务不建议直接重试环境未修复时重试只会反复失败模型与 Provider 层限流429、连接超时、上下文长度超限按指数退避策略稍后重试可以重试但必须设置次数上限并加上抖动数据与校验层输出不符合 Schema、期望 JSON 解析失败、工具返回字段缺失收集样本进入人工复核队列不建议重试重试大概率还会得到同类结果框架与代码层插件崩溃、数据库写入失败、磁盘空间不足修复 Harness 或插件 Bug 后重放视具体原因决定代码 Bug 未修复前重试无意义登录失败这类“环境和服务层”错误在第一批跑规模化任务的人手里是最容易浪费时间的。比如登录失败报错failed to start login server或者更具体的“以一种访问权限不允许的方式做了一个访问”通常都指向 Login Server 想监听某个本地端口或写某个目录但当前进程没有足够权限或者端口被占用。遇到这类报错我的处理顺序是先查端口占用再查进程运行身份最后查日志目录和工作目录的写权限。把服务改成以管理员权限启动或者换到非系统保护目录下运行问题大概率能解决。Token exchange failed 这类错误通常是上游 Login Server 根本没起来或者令牌缓存读不到先恢复服务再谈别的。4.2 重试策略必须区分“可恢复”和“永久失败”自动重试不是越多越好。最好的做法是在 Harness 里给错误码打上“可重试性”标签限流和网络超时可以重试权限错误、Schema 校验失败、参数非法这类永久性错误不应该重试直接进入失败样本集。重试参数上我建议采用指数退避加抖动第一次等待 1 秒第二次 2 秒第三次 4 秒最大间隔不超过 30 秒并在每次退避时加上 0 到 500 毫秒的随机抖动避免所有失败请求在同一时刻集中冲击上游服务。4.3 用“失败舰队”替代无脑重试所谓失败舰队是我从测试行业借来的概念。当某一个 Prompt 样本、模型版本、输入上下文的组合连续失败达到阈值我这边设置为同一模板失败 5 次Harness 就不再把它们当普通任务反复重试而是自动把这一整组相关样本捞出来单独形成一批“疑似问题集”打上标签供人工抽检。这个机制极大减少了无效重试也帮我快速圈定模型版本回退的决策范围。比如有些输出校验失败表面上是“模型没听懂指令”实际是某个系统 Prompt 模板升级引入了格式冲突。失败舰队能让你一眼看到一个模板 ID 下的失败密度远高于其他模板从而快速定位到最近的变更。5. 把三类排查合成一套观测体系指标、日志、追踪的配合方式耗时、成本、失败分开查效率太低这件事的根本解法是在 Harness 里建立指标、日志、追踪三位一体的观测体系。很多自建平台在这块做得不够一个重要原因是三套数据来自不同系统指标取自监控面板、日志打印在文本文件、失败数据散落在任务表联查时需要人工用 task_id 在三个系统之间来回搬运。5.1 最小可用的三件套指标层负责回答“有多少”。比如失败任务数、任务耗时 P50/P95/P99、重试次数分布、Token 消耗速率、预估成本累计值。日志层负责回答“为什么”。每次任务的关键阶段都要输出带 task_id 的结构化日志并记录重试事件和错误码。追踪层负责回答“路径在哪里”。对单条任务从入队到终结的完整生命周期做链路串接每跳都记录时间戳。在具体实现上不需要追求重型 APM 系统。把结构化日志收集到中心化日志平台再用 task_id 关联查询已经能做大部分追踪工作。甚至在 Harness 自身的数据库里建两张表——一张存任务主流程一张存阶段耗时明细——就足够支持日常排障了。5.2 规模化阶段我真正盯的阈值阈值设置没有放之四海而皆准的标准但我这边跑熟后形成了以下一组基线可以作为你制定告警规则的起点指标我采用的警戒线触发后的动作总体失败率单批次超过 3%暂停自动提交新批次优先检查错误分类重试占比超过 10% 的任务发生过重试检查是否出现限流风暴或连接池瓶颈P95 耗时超过基线值 1.5 倍以上持续 10 分钟发出告警启动耗时排查流程每任务平均 Token 消耗超过基线 2 倍检查 Prompt 是否意外膨胀、是否出现上下文重复传递缓存命中率低于 40%检查批处理窗口和共享前缀比例是否下降无效成本占比超过总成本 20%立刻审查失败重试策略与失败舰队阈值这些比例值要根据自己的任务类型微调。比如纯生成类任务的缓存命中率天然偏低不要拿评测类任务的标准去卡它。5.3 性能基线要随版本持续更新观测体系建好之后还有一个容易被忽视的动作每个模型版本、每次大版本 Prompt 模板升级后跑一轮最小回归集把耗时分位数、Token 平均用量、失败率刷新成新基线。如果不做这个上一节提到的“超过基线 1.5 倍”就无从谈起。基线不是一次性的模型升级后可能整体吞吐变化了Prompt 变长后 Token 基线也会整体移动。唯一不变的是方法本身每次变更都要记录前后对照用数据判断这次改动是优化了还是劣化了。6. 完整复盘从一次登录失败到全域任务阻塞的排查链路最后用一个完整的案例把耗时、成本、失败串联起来。这次故障让我意识到前面所有的方法论不是说教而是真金白银换来的经验。6.1 事故现场某天批量任务开跑后的第三个小时监控面板突然报警。现象如下失败率从 0.8% 缓慢攀升到 5%且持续没有回落。耗时 P95 从 70 秒涨到了 240 秒接近 3.5 倍。任务成本消耗速率比平时快了接近一倍。我们第一反应是模型 Provider 侧出了性能问题因为失败和耗时是同时出现的。但打开 Provider 侧的状态页对方各项指标完全正常。6.2 从耗时数据倒推我先拉出耗时拆解注意到任务的总耗时大头并不在model.invoke阶段而是在enqueue到schedule之间。也就是说大部分时间浪费在排队上根本没有进入模型调用。再按错误码聚合失败数据发现 92% 的失败都集中在同一个错误类——token exchange failed也就是调用模型前的鉴权令牌交换失败。6.3 找到根因顺着 token exchange 失败的报错去查 Login Server 的服务日志发现它在任务启动前就打印了一条“以一种访问权限不允许的方式做了一个访问”的错误。原因是执行账号对令牌缓存目录没有写权限Login Server 根本无法正常初始化后续所有需要交换令牌的模型调用自然全军覆没。真正的修复只有两步给执行账号授予对应目录的写权限重启 Login Server 并确认监听端口恢复正常。但在此之前Harness 的重试逻辑没有识别这类环境错误的“不可恢复”属性反复重试了将近三个小时把任务队列彻底堵死也烧掉了大量 Token。6.4 修复与验证我先暂停所有新任务的调度清空积压队列。失败任务不做直接重放而是等 Login Server 恢复正常后从失败前的检查点重新拉起候选批次。验证方式是抽 100 条此前失败的任务做灰度重放全部成功后再把剩余积压任务逐步释放。整个验证过程不到两小时耗时、成本、失败率三条曲线同时回落。这次故障给我的启发是批量 Harness 里最贵重的不是每一次调用而是调度链路上的信任。一次被错误重试风暴放大的局部故障能把整个批次的耗时和成本拖垮。你给每个失败样本设置什么样的重试策略本质上是在选择这个系统面对故障时要付出多大的代价。最后补两句实在话如果让我给准备跑规模化批次的团队一条最朴素的建议我会说先打点再优化。没把阶段耗时打点、成本字段落库、失败分类标签建好之前任何调优都是盲人摸象。而在这三件事里我会优先做失败分类因为失败会同时污染耗时和成本两个指标管住失败另外两条曲线大概率自己就回归正常了。另外别迷信仪表盘本身。仪表盘的价值是帮你更快找到问题不是代替你去思考问题。每次系统出现波动都要回到最原始的结构化日志里做一遍手动核对确保自动化链路没有把关键信息吞掉。排查规模化问题没有银弹唯一的捷径是把账记细、把链打全、把失败管住。
