我为什么把 DeepSeek V4 Flash 设为 Hermes Agent 的常驻模型
基于近 30 天用量、缓存命中、真实首响和一次压缩超时，我把 Flash 留在 Hermes 前台，把高推理模型留给复杂任务。
我的两个 Hermes Agent 都把 DeepSeek V4 Flash 作为常驻模型。日常交互交给 Flash，需要持续分析或多步骤执行时，再调用 GPT-5.6 Terra 的高推理档。
我同时保留了两项固定订阅，Codex Pro X5 每月 100 美元，Claude Max 每月 250 美元。在各自的工作台中，Codex 使用 GPT-5.6 Sol 的高推理档，Claude Code 使用 Opus 5 high。
已经支付两项订阅费以后，我仍然给 DeepSeek 按量付费，主要考虑 Hermes 的运行方式。常驻 Agent 需要长时间在线，接收消息后尽快响应，有时还要连续调用工具。我评估主模型时，先看首个响应时间和连续可用性，再看长期运行成本，复杂任务另行委派。
当前配置
一台 Mac mini 运行达达，保持全天在线；另一台 MacBook Air 运行芬达，随电脑的在线状态工作。两边采用相同的基本配置，主会话使用 DeepSeek V4 Flash，委派任务使用 GPT-5.6 Terra。
分工很明确。常驻层负责对话、状态查询和短任务，Flash 的响应速度直接影响使用感受；执行层负责耗时较长的工作，Terra 的高推理档通过 Codex 套餐调用。
两项订阅依然在使用，Codex 和 Claude Code 各自处理独立工作，Codex 套餐还向 Hermes 提供按需调用的高推理模型。DeepSeek 的增量支出则用于维持 Hermes 主会话的高频运行。
近 30 天的实际用量
我从 DeepSeek 平台导出了 2026 年 7 月 15 日至 8 月 13 日的计费明细，只统计达达和芬达两把 key。
这段时间，两边合计产生 8056 次调用，计费 token 约 11.91 亿，实际费用为 62.17 元。其中，DeepSeek V4 Flash 有 7776 次调用，计费 token 约 11.37 亿，费用为 54.94 元。Flash 分别占总调用量的 96.5%和总 token 的 95.5%。
缓存影响很大。Flash 的输入缓存命中率为 98.2%，平台统计的 token 包含缓存命中部分，因此 11.37 亿 token 不能理解为同等规模的新输入，54.94 元也不能用来推导适用于其他用户的单位价格。在我当前这种长会话、高缓存命中的运行方式下，Flash 的实际支出较低。
按用量报告当时采用的汇率，两项订阅每月约 2359 元，达达和芬达近 30 天的 DeepSeek 支出相当于这笔固定费用的约 2.6%。这部分增量成本在我的预算中可以接受。
8 月 12 日是一个调用较多的样本。当天达达和芬达合计调用 DeepSeek 1222 次，处理约 1.92 亿计费 token，费用为 11.37 元。同一天，Hermes 主动调用 Codex 的记录为 56 次。两边的请求口径不同，不能直接比较工作量，但可以看出当时的任务分配，大部分日常交互留在 Flash，少量复杂任务交给订阅模型。
首个响应时间
我另外从两个 Hermes 的消息数据库中提取了 8 月 9 日中午至 8 月 13 日下午的记录。统计方式是从用户消息写入，到同一会话出现第一条 assistant 记录为止。自动生成的上下文消息和异步通知已经排除。
达达
有效样本 305 条。首个响应中位数 9.3 秒，P90 为 42.9 秒。
芬达
有效样本 262 条。首个响应中位数 8.2 秒，P90 为 18.6 秒。
P90 表示九成样本在这个时间内出现首个响应。它只衡量什么时候开始处理，完整任务可能还要继续调用工具；样本中的任务难度也不一致，这组数据只反映当前配置的实际首响，不能用于模型横向排名。
从这 567 条真实消息看，两个 Agent 的首个响应中位数都在 10 秒以内。这与我的日常感受一致，也是我继续保留 Flash 的主要原因。
一次压缩超时带来的调整
异常发生在后台。8 月 9 日，达达使用 GPT-5.6 Luna 辅助压缩上下文时，请求在 300 秒后超时，随后回退到主模型，整个压缩过程最终被取消。Hermes 主进程没有停止，消息也没有丢失，但在使用端看起来已经接近失去响应。
我随后把辅助压缩模型也调整为 DeepSeek V4 Flash。配置生效后，截至 8 月 13 日，本机日志记录了 26 次由 Flash 执行的辅助压缩调用，没有再次出现同类超时。
观察期只有四天。这 26 次记录不能证明长期稳定性，也不能说明 Flash 在所有压缩任务上都更快；当前能确认的范围仅限于我的 Hermes 配置和这段运行时间，切换后没有复现原来的超时故障。
这次调整让我开始检查 Agent 的完整运行过程。即使主模型回复很快，只要辅助压缩发生长时间超时，整个会话仍然会显得不稳定。主会话与后台辅助任务需要分别检查，委派调用另做记录。
我现在采用的模型分工
日常消息、状态查询和短任务继续由 DeepSeek V4 Flash 处理。需要更长推理过程或连续执行多个步骤时，Hermes 调用 GPT-5.6 Terra 的高推理档。独立工作台中的复杂任务则继续使用 Sol 的高推理档或 Opus 5 high。
这套规则仍需数据校准。我不会为了消耗固定套餐额度，把所有请求都交给订阅模型；套餐用量长期过低时，也会调整委派条件。Hermes 现在主动判断任务规模，符合条件就调用 Terra，并通过日报和月报检查实际比例。
后续我会继续观察两个指标。一个是首个响应时间的中位数和 P90，另一个是委派任务的失败与重试情况。DeepSeek 支出持续增长，或者首个响应明显变慢时，我会缩小常驻模型承担的任务范围。Terra 调用频繁遇到容量限制时，则需要增加重试和备用模型。
在现有数据发生明显变化前，我会继续把 Flash 设为常驻模型，把 Terra 的高推理档留给复杂任务。