很多人卡在同一个位置：先用着别人送的免费额度跑通了 demo，量一上来就不知道该继续薅、还是自己搭一套。免费站点省事但说不清边界，自建可控但时间也是成本。这篇不劝你选哪个，只给一套判断口径——按量级、按数据敏感度、按你愿不愿意长期养机器，把两条路的代价摊在同一张表上比。
很多人卡在同一个位置：先用着别人送的免费额度跑通了 demo，量一上来就不知道该继续薅、还是自己搭一套。免费站点省事，但说不清边界在哪；自建可控，但时间也是成本，你搭完还得养。这篇不劝你选哪个，只给一套判断口径——按量级、按数据敏感度、按你愿不愿意长期养机器，把两条路的代价摊在同一张表上比。
先明确一件事：这两条路解决的不是同一个问题。免费中转站帮你把「验证一件事值不值得做」的成本压到接近零，自建帮你把「这件事要长期稳定跑」的确定性握在手里。先想清楚你现在处在哪个阶段，再往下看分档和清单，能省掉一半纠结。
先把两条路各自的真实代价摆出来
| 对比项 | 免费中转站 | 自建 |
|---|---|---|
| 现金支出 | 零或接近零 | 机器、带宽、域名按月付 |
| 额度与限速 | 别人说了算，随时可能变 | 自己定，但受上游供应商约束 |
| 模型选择 | 站里上什么你用什么 | 想接谁接谁，但要自己调通 |
| 数据留存 | 你问不到对方记不记 | 自己知道日志放哪、留多久 |
| 停服风险 | 站点挂了只能换一家 | 挂了只能自己修 |
| 时间成本 | 几乎为零 | 装环境、修故障、盯更新 |
- 别只比钱，给自己算一个「每小时时间值多少」，自建每周花在装环境、修挂掉的服务上的时间要折成钱再比
- 免费额度换到的是零现金支出的试错机会，代价是额度上限、限速、模型不确定和随时可能停服
- 自建换到的是可控性，代价是持续投入，落地那一刻只是开始，后面每个月的维护才是真账单
- 什么情况下不适用：只跑一次性小脚本、只想验证某个提示词效果，两条路都不值得投入，直接用现成免费额度就够了
按调用量分档：什么量级下自建才开始划算
调用量是最容易量化的一个维度，也是最容易被高估的一个。很多人觉得自己「量很大」，实际拉出日志一看，峰值也就集中在少数几天，平均下来并不高。分档的目的不是给你一个绝对门槛，而是让你知道在这个量级下，哪条路的固定成本摊得开。
| 量级 | 典型场景 | 建议方向 |
|---|---|---|
| 轻量 | 个人试水、每天几十到几百次请求 | 免费中转优先，去 /sites 挑几家有免费额度的分别跑 |
| 中等 | 小团队在用、持续跑业务 | 开始算自建固定成本，量不够平摊就先别动 |
| 高频 | 长跑任务、批量处理 | 自建收益主要是不被限速、不被临时调额度 |
| 突发型 | 平时很低、偶尔集中爆发 | 混合，平时走中转，关键链路单独兜底 |
中等量级最纠结，因为这时候自建的固定成本还摊不开——机器是月付的，带宽是月付的，量不够就是纯亏。到 /compute 看当时的机器和带宽报价，按你自己的实际请求量折算一遍，能不能摊平当场就有答案，别靠感觉。
高频量级下，自建的主要收益其实不是省钱，而是不被人限速、不被人临时调额度。这种「确定性」对长跑任务和批量处理是刚需，对偶尔用一下的人毫无价值，所以量级这一票该不该投，取决于你的任务形态。
数据敏感度这一票，常常直接决定答案
这一节最容易被忽略，但往往一票定胜负。前面两个维度算的都是成本，成本可以权衡、可以妥协，数据能不能外传通常没法妥协。只要你的输入里带客户资料、内部代码、未公开文档，免费站点就不是「省钱」而是「转移风险」——风险没有消失，只是从你账上挪到了别人手里。
- 先看 /safety 和 /ai-dict/category/safety 里的口径，搞清楚你打算用的那家对数据留存、日志、用途是怎么说的
- 自建不代表绝对安全，但你至少知道自己把数据放哪、日志留多久、谁能碰到
- 免费站点你连它记不记、记多久、给谁看都问不到，这种不确定本身就是成本
- 什么情况下不适用：数据全是公开资料，或者只是拿公开文档做检索问答，这一票可以不投给自建
判断方法很直接：把你现在实际会发出去的请求内容抓几条出来看一遍，如果里面有任何一条是你不想让它出现在别人服务器日志里的，这一票就已经投完了，后面的成本比较只是补充说明。
自建真正容易低估的三笔开销
决定自建的人，通常只算了机器和带宽，然后发现实际花的比预算多。多出来的部分不是被坑了，而是三笔一开始就存在、只是没被摆到台面上的开销。提前知道它们存在，你在做决定时的心态会稳很多。
- 稳定性责任
- 以前站点挂了可以骂两句换个站，自建挂了只能自己爬起来修，凌晨也一样
- 上游成本
- 模型侧的钱没消失，只是换了个地方付，上游接口一样要钱、要额度
- 兜底线路
- 自建也建议留一条中转线做备用，主路挂了不至于业务全停
第二笔最容易被低估：自建只是把「谁来调模型」这件事接了过来，模型本身的钱一分没少。具体单价到 /official-api 看当时的数字，再拿 /tools/model-cost-calculator 按你的实际 token 量折算，两个数放一起才叫「自建的总成本」，只看服务器账单会严重低估。
- 先算上游账用 /tools/model-cost-calculator 按你真实的输入输出 token 量跑一遍，得到模型侧每月大概多少，这是自建也躲不掉的部分
- 再算机器账到 /compute 看当时的配置和报价，挑一个能扛住你峰值的档位，别按平均值选
- 留一条兜底线自建落地的同时配一条中转线路，主路异常时先切过去，避免半夜被叫起来
- 设一个复盘点跑一个月后回来对一次账，看实际维护时间有没有超出你的预估，超了就重新评估
一张自查清单：照着答完就有答案
前面几节是分维度拆开看的，落到你自己身上，最简单的方式是拿一张清单逐条回答。回答不用精确，大致方向对就行，因为这几条里只要有任意一条是「不能接受」，方向基本就定了，剩下的都是细节。
- 每天请求量大概多少，峰值会不会翻几倍
- 输入里有没有不能外传的内容
- 出问题时要多久恢复，这个时间你能不能自己扛
- 有没有人能帮你一起维护，还是只有你一个人
- 愿不愿意为它每月付一笔固定成本
判读规则：五条里「数据不能外传」或「不能接受停服」占任意一条，就直接偏自建；五条全是「无所谓、能等」，免费中转站继续用没问题。拿不准就别二选一，混合着来——日常探索走免费中转，关键链路自建或走更稳的付费通道，两边都留一手。
需要说明的是，这套清单不适用于「纯粹学习目的」的场景。如果你只是想搞明白某个模型对某类问题答得怎么样，既没有数据敏感问题也不在乎停服，那结论永远是先用现成的，自建留给下一个阶段。
下一步拿不准从哪家免费额度开始试，先去站内中转站目录按免费额度筛一遍，挑几家分别跑同一组请求，横向比完再决定要不要自建。→常见问题
免费中转站能长期用吗？会不会突然就没了？
免费额度本质上是一种拉新手段，站点愿不愿意一直供取决于它自己的账。稳妥做法是别把关键业务压在单一免费来源上，平时多留一两家备用，接口地址和 key 都提前存好。想判断某个站的存续信号，可以去 /sites 看它有没有在持续维护，参考 /site-lifespan-diversify 里的观察角度。
自建一套大概要投入多少？
固定开销主要是机器或云主机、带宽，加上你自己搭进去的时间，模型调用本身还是一笔按量费用。具体租金到 /compute 和 /compute/price-index 看当时的数字，token 成本用 /tools/model-cost-calculator 按你的真实用量折一遍。先算这三项加起来，再和免费站点的额度限制对比。
能不能先用免费中转站验证，跑通了再自建？
可以，而且这是最常见的路径：用免费额度把提示词、调用逻辑、错误处理都跑通，确认这个功能真的有人用、量真的涨起来了，再投入自建。迁移时注意把模型名、参数、超时重试这些抽成配置项，别写死在代码里，换通道时才不用重写。
