AI 推理：自建服务和托管服务怎么选

大模型推理自建还是买托管，别从报价单开始比。先看三个数：日均请求量、能接受的响应延迟、数据能不能出内网。这三个数里有两个以上卡住，答案基本就定了。下面按成本结构、分流规则和失效边界拆开讲，每条都能直接拿去跟团队对账。

三个数决定八成结论

日均调用量要看稳定量，不看活动期的峰值。稳定量小、波动大的业务，托管按量付费天然合适；稳定量足够大，自建摊薄之后的单位成本才有讨论空间。关键在稳定两个字：峰值可以靠排队和限流扛过去，低谷时闲置的机器却要一直付电费和折旧。

延迟要拆成两段看，首字延迟和整体生成时间。流式输出下，用户感知强的是首字延迟。自建在这一点上有优势，模型可以常驻显存，省掉冷启动；托管的首字表现取决于服务方的调度策略，通常不写进对外承诺里。

数据边界是硬条件。未公开的合同、用户隐私、内部财务数据，出内网这一条就足以否掉大部分托管方案。反过来，公开资料、营销文案这类内容，托管的顾虑小得多。三个数填完，剩下的才是钱的问题。

自建的成本在人和闲置

机器只是账单的一部分。自建还要出三笔：部署与版本升级的人力、监控告警与夜间值班、故障时的定位能力。这三笔在预算表里经常被漏掉，在真实账单里占比却不低。一个能跑起来的推理服务，和一个能扛住半夜告警的服务，中间隔的是人。

另一笔容易漏的是闲置。业务有明确的日内波峰波谷，机器在低谷空转，电费照付。要压掉这部分浪费就得上弹性伸缩，而弹性伸缩本身需要调度和预热机制，缩下去的机器拉不起来，请求会直接超时。

还有迭代。模型半年一换，换一次要重新压测、重新调批处理参数、重新验证输出质量。托管把这步包了，自建要自己排期。团队只有一两个懂推理框架的人时，这项成本往往比机器贵。程序员选 AI 工具时容易只比模型能力，忽略后续维护，部署方案也一样。

托管省的是运维，省不了账单

托管的价值在接入速度，拿到密钥就能跑，扩缩容、故障转移、模型升级由服务方负责。对一个还没验证需求的项目，这条路能省掉前期几个月的建设投入，小团队尤其如此，这也是低门槛起步时更常见的选择。

代价有两块。单价随调用量线性增长，量一大，账单会比预期陡；定制空间有限，并发上限、限流策略、模型版本由服务方定，你只能在它给的参数里调。要在推理链路里插一层自己的后处理，或者改采样策略，托管常常没有入口。

还有一块常被忽略：托管服务的能力边界会变。接口参数、计费方式、模型下线时间都可能调整，依赖它的业务要预留改造成本。签合同时看清版本停服的提前通知期，比谈单价有用。

四种场景的落点

表里第三行值得单独说。离线批处理对延迟不敏感，是自建容易跑出成本优势的场景，机器可以跑满，不必为波峰预留。交互式产品相反，自建要付常驻成本，托管要看接入点位置。

混合部署的分流规则

混合不是两边都接，要定三条规则，写进网关配置，不靠人记。

按数据敏感度分流：标记为敏感的请求走内网，其余走托管。规则落在网关层，别指望业务代码自觉遵守。按任务类型分流：长上下文、批量摘要这类吃显存的任务放自建，短问答、轻改写放托管。按时间段分流：白天高峰让托管承接溢出，夜间低峰全部回落自建。

时间段这条要配溢出阈值，否则流量小幅波动就来回切，两边的冷启动都被触发。阈值按历史峰值定，留出两成余量即可，不必追求精确。

它做不到什么

自建不等于完全可控。模型权重开源，但推理框架、算子优化、显卡驱动这一层仍有坑，换个显卡型号，实际吞吐可能差一截。把自主可控理解成什么都能自己改，落地时会失望。

托管也不等于不用管。提示词版本、上下文长度、重试策略、超时设置都在你这边，配错了照样出事故。服务方只承诺接口可用，不承诺你的业务逻辑正确。

两种方案都改不了模型本身的能力边界。答案不准、长文漏读、多轮跑偏，这些是模型问题，换部署方式不会变好。想先弄清本地与网页的体验差别，可以看网页版和本地部署的对比。

三个还没说透的问题

问：自建能不能先用一两台机器试？ 可以，但先想清楚试什么。验证延迟和吞吐，小规模够用；验证成本，小规模的单位成本一定偏高，不能直接外推到生产规模。

问：托管降价了，自建的账要不要重算？ 要。自建成本里机器占大头，托管降价会直接压缩自建的优势区间。建议每半年按当时报价重算一次，别用一年前的结论做决定。

问：换成参数量更大的模型，原判断还成立吗？ 不一定。参数量上去，显存占用和单次请求成本都变，原来能塞进一张卡的现在要两张。换模型时把部署方案一起重评，比事后补救便宜。

选型速查

• 数据不能出内网，先排除托管
• 稳定量小、需求还在验证，先托管，别提前建设
• 夜间批量、延迟不敏感，自建容易跑出成本优势
• 比价时把人力、闲置、迭代三笔一起算
• 混合部署写三条规则：敏感度、任务类型、时间段