尽可能压低 AI 分诊的账单

AI 分诊一旦跑通，下一个问题就是账单。每一条送到模型的告警都要花钱，在真实告警量下这个数字会很快攀升。而这笔账单大部分是可以省掉的。

SocTalk 首先就让大多数告警根本到不了模型，靠去重、合并、关联和确定性关闭（见工作原理），所以剩下的开销都集中在真正需要判断的告警上。本指南讲的就是把这部分剩余开销压到最低，同时不牺牲超出你实测范围的质量，也不把敏感的告警内容送出你的边界。

下面的做法按最便宜、最稳妥优先排列。大多数部署都用不到最后一项。

先做批处理与缓存

前沿 API 上有两项托管功能，可以在不改变模型质量的前提下降低成本。

Batch API 以异步方式处理请求，换取一个固定折扣，而输出完全相同。SocTalk 天然契合这一点。settle 窗口本就会先把一次运行压住，让相关告警先积攒起来，而一次运行本身就是异步的，所以分诊并不是一条对延迟敏感的路径。

提示词缓存（prompt caching） 会以输入价格的一小部分对提示词中重复的部分计费。SocTalk 的 supervisor 和 verdict 提示词都带有一个很大的稳定前缀，即系统提示词和工具定义，而每个案件各不相同的内容放在末尾，所以可缓存的比例是实打实的，并且在 Anthropic 路径上已经在用。

把两者都打开，在考虑下面任何做法之前，先测一下新的单次运行成本。这两项都不影响质量，没有理由跳过。

把便宜的模型用在便宜的活上

一次分诊运行会在两个角色里用到模型：一个 supervisor 负责给调查路由，决定接下来补充什么、何时下判断；一个 verdict 负责权衡证据。路由是较轻的活。SocTalk 会把每个角色解析到各自的 tier，每个 tier 可以指向各自的 provider、模型和端点，所以路由可以跑在更小的模型上，而 verdict 保留那个更强的模型。这是配置，不是新的基础设施。

更便宜的托管模型，但有一个前提

有几家 provider 以远低于前沿的价格提供接近前沿的开源模型，具体取决于 provider、模型和负载。它们很适合那些常规、低风险、用接近前沿的开源模型就够的场景。对安全场景来说，约束在于数据治理而非价格：把客户告警发给第三方 API，尤其是位于另一司法辖区的，会把这些数据移出你的掌控之外。如果这对你的租户是绝对不行的，那么下一节会把数据留在你的边界内。

自托管模型

自托管是省得最多的一条路，也是唯一能把告警内容留在你边界内的。SocTalk 消费自托管模型的方式和消费前沿 API 一样，把一个 tier 指向一个 OpenAI 兼容端点即可。它会按交付模式对后端分类，一个温热的托管 API、一个可缩容到零的 serverless GPU、一台常开的租用 GPU，或一个本地实例，从而让成本和调度对每一种都表现正确。

在哪里跑是一个真实的权衡。

• 托管的 serverless GPU 平台（例如 Modal）把模型部署在一个 OpenAI 兼容端点后面，空闲时缩容到零，按 GPU 秒计费。你只在它运行时付费，也没有服务器要运维，代价是每小时费率高于纯租用。
• GPU 租用市场（例如 RunPod）租的是接近于一个小型自托管部署会去买的消费级 GPU，每小时费率更低。作为交换，生命周期要你自己管。一个 pod 会一直计费直到你把它停掉，冷启动要好几分钟，而且最便宜档位的可用性时有时无。
• 本地实例（例如 Ollama）跑在你已经拥有的硬件上，没有按请求计的费用，也没有任何东西离开这台机器，受限于这一台机器的吞吐。

起作用的是利用率，不是显卡

自托管服务器只有在其持续批处理被填满时才便宜。一次只发一个请求会让 GPU 利用不足，反而让自托管比它应有的更贵。SocTalk 让每个 worker 并发跑多个调查，所以同时会有多个请求在后端在途，批处理被填满。

在我们的基准里，把批处理填到八路并发，相比一次一个把聚合吞吐提高了大约六到八倍，并把单请求成本压到串行情形的约 13% 到 17%，在所测的 L40S、A10G、L4、RTX 3090 和 RTX 4090 上都是如此。大部分节省来自利用率。是并发而非显卡，把自托管从低效推到了比串行基线更便宜，在这些运行里如此。

实测成本

下面的数字来自我们自己的基准运行，用一个 7B 开源模型在一组固定的分诊案件上、八路并发跑出来的。它们是参考，不是保证。你的模型、硬件和告警构成都会让它们变化。

按每次完整分诊算，在一台租用的消费级 GPU 上自托管，比一次未优化的前沿 API 调用便宜大约两到三个数量级，也比同一模型跑在托管 serverless 平台上便宜数倍，因为所测的租用卡既每小时更便宜，在这些运行里也更快。托管平台更高的费率买到的是缩容到零和免运维。前沿 API 更高的价格买到的是一个可能更适合更难案件的托管模型档位，而且没有基础设施要运维。

延迟仍然可用。这组 12 个案件在一台 Modal A10G 上大约一分钟跑完，在一台 RunPod 4090 上是 11 到 14 秒，都是八路并发，而不是单流估算暗示的好几分钟，因为并发让这些调用相互重叠，而真实的 verdict 落在 token 预算之内。

小模型是否够用

只有当便宜的模型确实顶得住，成本才有意义。在我们的运行里，一个 7B 开源模型守住了 SocTalk 的结构化分诊契约：产出合法的 router 和 verdict 输出、没有 schema 错误，并且在一个小的基准样本上，其 verdict 有大约 58% 到 75% 与一个更大的推理模型一致。它在路由上更弱，而在与授权相关的案件上，它有时会关闭那些档案里没有任何授权、本应升级的活动。

因此，小的自托管模型是常规中段一个可行的便宜档位，背后再放一个更强的模型兜住难的案件。它对你的环境是否够用，是要去测的，而不是假定的，而且在把任何关闭决定交给小模型之前，应该拿一个有代表性的基准去测。无论如何，安全下限（safety floor）依然成立。无论用什么服务方式，任何模型都不能在一个已知恶意信号或一个仍在活动的相关案件之上做关闭。

需要预先规划的限制

• 冷启动。 一个缩容到零或刚租下来的后端不会立刻就绪。模型下载和加载要好几分钟，所以一波冷着到来的告警要等。对常规分诊没问题，对任何紧急的事就是问题，这也是为什么一个温热的兜底 tier 有它的价值。
• 租用的运维负担。 一台租用 GPU 会一直计费直到你停掉，也没有缩容到零，所以空闲时间就是白花的钱，而拆除要你自己记得做。最便宜档位的可用性时有时无。
• 成本核算。 按 token 计的预算对前沿 API 是对的单位，对一个按 GPU 秒计的后端就是错的单位。自托管时要按后端自己的计费单位来核算。
• 数据治理是一条光谱。 脱敏会在任何东西离开之前去掉密钥，但运营上下文，主机、账户、日志内容，仍然会送到外部 API。只有在边界内自托管才能把这些上下文留在你的边界里。

选择在哪里跑

三个问题就能定下来。利用率。 稳定、高利用的负载偏向一张租用卡；零散、突发的负载偏向一个缩容到零的平台，或一个空闲成本为零的托管 API。运维意愿。 租用最便宜，但要你自己跑；serverless 平台更贵，但自己会跑；API 最贵，但没有东西要跑。数据敏感度。 如果告警内容不能离开你的边界，自托管就是唯一答案，而上面的功课就是你把它做到负担得起的办法。

对大多数团队来说，顺序和本指南一样。先批处理与缓存，接着把路由放到更便宜的模型上，只有当量级和数据驻留需求值得去运维时，才上一个自托管 tier。

免责声明。 SocTalk 与任何 LLM 或 GPU 服务提供商都不存在从属、背书或赞助关系。本指南中提到的 Modal、RunPod、Anthropic、OpenAI、Ollama 以及任何其他服务，都只是作为模型可以在哪里运行的示例。文中的成本与性能数字是我们自己的基准观测，而非提供商公布的数字，所有产品名称与商标归各自所有者所有。