免费、自托管、付费 API 三条路的选择框架——先评估使用量、数据敏感度、运维能力、延迟容忍度和成本天花板,再选最适合的模型。
你上周花了一整个周末租了一台 GPU 机器,拉取了一个量化模型,然后看着它拒绝加载。到了周日晚上它终于跑起来了。到了周一你才发现模型只是最便宜的部分——真正的成本是你那个周末。
现在同一个项目需要一个编程助手,而你正盯着三扇门:免费层级、自托管模型,或者付费 API。每个人都有看法。没有人知道你的约束条件。
每周都有一个新的开源模型发布,每周也都有一个新的免费层级出现。这让选择变得更难,而不是更容易。真正的问题不是"哪个模型最好"——而是"在接下来的六个月里,我能维持哪种方案?"
这个问题取决于五个约束条件:用量规模、数据敏感度、运维能力、延迟耐受度,以及成本上限。模型质量是一个过滤器,而不是决策因素。你首先决定能在哪里运行这个东西,然后选择最适合那里运行的最好的模型。
免费一栏中有一个选择是 MonkeyCode,一个开源编程助手,提供免费模型访问和免费服务器选项。在撰写本文时,免费层级包含 1000 万 token——足够做真正的实验,而不只是玩具示例。披露:本文是 MonkeyCode 产品推广的一部分。
我不会告诉你 MonkeyCode 适合所有人,因为它确实不适合所有人。这篇文章的核心是框架,而这个框架适用于你最终选择免费层级、自托管模型还是付费 API。运行下面的评分脚本,让你自己的答案来说话。
用量规模决定了免费额度的感受。如果你每天只做一次重构,一千万 token 看起来是无限的。如果你整天跑 Agent 循环,同样的数字就变成了倒计时。
数据敏感度是最难协商的约束条件。如果你的代码可以离开你的机器,免费托管访问没问题。如果不能——有 NDA、受监管行业、专有算法——自托管就不再是一个选项,而是一个必须。
运维能力是大多数人欺骗自己的地方。自托管一个模型不是周末项目;而是订阅升级、崩溃和磁盘空间。有些人真的喜欢这种订阅。大多数人后来才发现他们并不喜欢。
延迟耐受度区分交互式工作和自动化管道。共享的免费服务器在响应时间上不会打败本地 GPU。如果你是手动敲提示词,秒级延迟没问题。如果你在构建一个在紧密循环中调用模型的 Agent,延迟会随着每一步成倍增加。
成本上限是每个人都会尊重但没有人正确加权的约束条件。零预算是合理的选择,不是性格缺陷。它迫使你优化你真正需要的东西,而那通常比营销宣传的要少。
以下是我在有人让我帮他们做决定时使用的脚本。它问五个问题,给三种方案打分——免费托管、自托管、付费 API——并打印出推荐结果。权重是透明的,所以你可以反驳它们。
#!/usr/bin/env python3
"""pick_setup.py — score free hosted, self-hosted, and paid API setups."""
DIMS = {
"usage_volume": {"q": "How much will you run it?", "low": "a few requests a week", "high": "continuous agent loops"},
"data_sensitivity": {"q": "Can your code leave your machine?", "low": "fully public", "high": "NDA'd or regulated"},
"ops_capacity": {"q": "Do you want to operate a server?", "low": "never again", "high": "I already run infra"},
"latency_tolerance": {"q": "How patient are you per request?", "low": "seconds are fine", "high": "I want fast loops"},
"cost_ceiling": {"q": "What is your monthly budget?", "low": "zero", "high": "hundreds of dollars"},
}
OPTIONS = ["free_hosted", "self_hosted", "paid_api"]
# For each option and dimension: score for answer 0, 1, 2.
SCORES = {
"free_hosted": {"usage_volume": [2, 1, 0], "data_sensitivity": [2, 1, 0],
"ops_capacity": [2, 1, 0], "latency_tolerance": [2, 1, 0],
"cost_ceiling": [2, 1, 0]},
"self_hosted": {"usage_volume": [0, 1, 2], "data_sensitivity": [2, 2, 2],
"ops_capacity": [0, 1, 2], "latency_tolerance": [1, 2, 2],
"cost_ceiling": [0, 1, 2]},
"paid_api": {"usage_volume": [1, 2, 2], "data_sensitivity": [2, 1, 0],
"ops_capacity": [1, 1, 1], "latency_tolerance": [1, 2, 2],
"cost_ceiling": [0, 1, 2]},
}
WEIGHTS = {"usage_volume": 0.25, "data_sensitivity": 0.25, "ops_capacity": 0.20,
"latency_tolerance": 0.15, "cost_ceiling": 0.15}
def ask(dim):
meta = DIMS[dim]
while True:
try:
v = int(input(f"{meta['q']} (0={meta['low']}, 1=between, 2={meta['high']}): "))
if v in (0, 1, 2):
return v
except ValueError:
pass
print("Enter 0, 1, or 2.")
def main():
answers = {dim: ask(dim) for dim in DIMS}
totals = {}
for opt in OPTIONS:
totals[opt] = sum(WEIGHTS[d] * SCORES[opt][d][answers[d]] for d in DIMS)
print("\nScores (higher is better):")
for opt in sorted(totals, key=totals.get, reverse=True):
print(f" {opt:14s} {totals[opt]:.2f}")
print(f"\nPick: {max(totals, key=totals.get)}")
if __name__ == "__main__":
main()
真正有趣的输出不是胜者——而是分差。如果免费托管以很大优势获胜,说明你有缓冲空间。如果只赢了 0.05,你离悲剧只有一步之遥——一次速率限制就够你受的。
各条路在哪里崩掉
免费路线崩在数据和用量上。当你的代码是公开的、用量很轻、预算为零时,它是正确的选择。当某一次请求包含你承受不起泄露的内容时,它是错误的选择。
自托管路线崩在时间上。当数据不能离开你的网络,或者当你已经在运行基础设施、模型只是另一个服务时,它是正确的选择。当你有正职工作并且这是一个副项目时,它是错误的选择。
付费路线崩在成本 scaling 上。当你需要 SLA、支持渠道,或者免费层级无法提供的吞吐量时,它是正确的选择。当你的用量很轻、以至于你为几乎用不到的订阅付费时,它是错误的选择。
在你运行这个脚本之前,先说几个诚实的局限性。一千万 token 的数字和免费服务器是 MonkeyCode 今天的方案;配额和可用性会变化,我不会基于任何免费层级来构建业务。免费服务器没有 SLA。
如果你的工作受监管或你的正常运行时间很重要,这本身就可以否决免费路线。脚本也是给方案打分,不是给模型打分——你仍然需要单独在你的任务上评估模型质量。
因此,如果合规性禁止第三方处理,就不要用这个方法。不要把免费层级放进会阻塞发布的 CI 流水线中。也不要误以为免费服务器就是生产环境。
测试这个框架最便宜的方式是用你真实的答案运行脚本,然后在你推荐的方案上花一个下午。如果你的答案落在免费一栏,MonkeyCode 的免费层级是一个合理的起点——仓库链接在我的个人资料中。如果不是,脚本刚刚为你省下了一个周末。