免费模型端点 ≠ 免费服务器：四层对比选型框架

上周，我看到一位平台负责人描述了一场糟糕的试点。他的团队注册了一个免费的 AI 服务器，因为这样就不需要提基础设施工单了。三天后，他们开始重写应用，因为这个免费的运行时不允许他们期望的持久卷来存放镜像。这个团队把免费的模型端点和免费的服务器当作同一件事来对待了。它们不是一回事。

我打算用这个区分来评估 MonkeyCode。这家运营商提供了两个可用性声明，我将把它们作为输入：免费模型访问和免费服务器选项，并声明了 3000 万 token 的额度。披露：本文是作为 MonkeyCode 产品推广的一部分准备的。我没有运行过这个服务，所以请把这些数字当作待验证的变量而不是基准。

本文不是对 MonkeyCode 的裁决。而是一个四关比较法，你可以在有人给你提供免费 token 加免费运行时复用它。

在比较之前先把两个 offer 分开

模型访问：一个接受 prompt、消耗 token、返回补全的端点。你关心的是模型质量、上下文窗口、速率限制、延迟、工具调用、JSON 模式，以及 token 额度是否同时计算输入和输出。

服务器选项：一个运行你自己的代码、镜像或工作流的地方。你关心的是运行时限制、持久化存储、出站网络访问、出口流量、定时任务，以及部署机制。

为什么要分开？因为一个可能通过而另一个失败。一个检索应用可能很喜欢免费 token 配额，但无法在免费服务器上运行，因为它需要一个带持久卷的向量数据库。一个简单的 prompt 运行器可能在免费服务器上没问题，但免费端点暴露的模型可能不满足需求。

Gate 1：原型是否适配宣传的运行时约束

问自己原型是否无状态，以及能否在宣传的运行时约束内运行。

应用需要超过 1GB 的持久磁盘吗？如果是，验证免费服务器是否允许。

需要出站连接到数据库、队列或私有 API 吗？如果是，验证出口流量和 IP 白名单。

运行的语言或依赖是否在提供的基础镜像中不支持？如果是，估算镜像重建时间。

延迟是面向用户的还是批处理的？免费服务器的冷启动对批处理可能可以接受，但对聊天机器人不行。

并发量低吗？免费运行时通常有小的并发请求限制；50 人的演示可能很快就会超出。

如果任何答案是未知的，不要继续。在这个关卡中，未知就是失败，因为最便宜的修复方案通常是你已经了解的自托管服务器。

Gate 2：模型的能力匹配

模型端有自己的测试。不要用演示对话作为证明。用一个小输出策略契约：定义六个带有预期响应字段、拒绝行为、格式和工具调用结构的案例。用免费的模型端点运行它们。

结构化输出：返回带有必需字段的有效 JSON。

工具调用：返回预期的函数名和参数。

拒绝：安全地拒绝有害请求，且不泄露 prompt 文本。

上下文：在添加 20 轮历史记录的同时保持 4000 token 的指令稳定。

延迟：在正常补全的声明 p95 预算内保持。

Token 记账：确认输入和输出 token 是否都计入 3000 万额度。

3000 万 token 的声明只有在你知道计量规则之后才有意义。如果输入和输出都计入，一条发送 2000 token 返回 800 token 的往返调用消耗 2800 token，而不是 800 token。这在许多工作流中会让你的有效额度减半。在做预算之前先验证这一点。

Gate 3：相对自托管的成本盈亏平衡点

免费并不等于零成本，因为它可能消耗迁移时间。用变量而不是厂商幻灯片来建模比较。

tokens_m = 每月消耗的 token 百万数
price_per_m = 每百万 token 的付费模型成本
server_hours = 你在自己的服务器上需要的每月小时数
server_price = 你的每小时计算价格，租赁或摊销
eng_hours = 每月维护或迁移的工程时间
eng_rate = 每小时的全额工程师成本

用这个小型 Python 模型来找盈亏平衡点：

def monthly_cost(tokens_m, price_per_m, server_hours, server_price, eng_hours, eng_rate):
    return (tokens_m * price_per_m) + (server_hours * server_price) + (eng_hours * eng_rate)

# 免费选项：你仍然需要支付迁移、集成和未来退出的成本。
free_option = monthly_cost(0, 0, 0, 0, eng_hours=6, eng_rate=120)

# 同等工作负载下的付费模型加自托管服务器。
paid_self_hosted = monthly_cost(tokens_m=120, price_per_m=3,
                                server_hours=730, server_price=1.8,
                                eng_hours=2, eng_rate=120)

print(f'Free option: {free_option}')
print(f'Paid self-hosted: {paid_self_hosted}')

盈亏平衡的问题不是免费层是否免费。而是 free_option + migration_risk + switching_cost 在预期的试点周期内是否保持在 paid_self_hosted 之下。如果试点持续两周，两天的迁移就能抹掉节省下来的成本。

Gate 4：退出路径和退出标准

每个免费选项都需要一条归档规则。在构建之前写下硬性关卡：

Owner：一名负责评估的有名字的人。

Expiry：14 天或固定数量的测试用例，以先到者为准。

Data rule：免费服务器上不放生产客户数据或凭证。

Exit trigger：任意两个能力案例失败，或服务器限制 3 天未解决。

Archive rule：保留测试脚本和记分卡；如果试点结束，删除免费服务器实例。

硬性关卡不是分数。如果安全或数据要求失败，它会覆盖分数。

记分卡作为对话工具

下面的表格不是客观真理。它迫使团队对数字而不是感觉达成一致。

总分：82/100。两周试点的门槛是 75。团队继续进行，但只在确认 token 计量规则和服务器存储之后才能第一次提交。

改变一个变量，决策就会翻转。如果迁移时间从六小时工程时间上升到二十小时，免费选项的成本就会超过这个工作负载的付费自托管估算。这是需要进行对话的地方，而不是演示感觉有多快。

谁不应该使用这种方法

受监管的数据：健康、支付或密钥放在免费服务器上会产生清理问题，可能超过任何节省。

硬性延迟要求：如果服务没有 SLA，不要把它放在面向用户的路径上。

自定义硬件或私有模型：如果你的镜像需要 GPU、驱动程序或特定网络，自托管通常是唯一现实的选择。

没有 Owner 的团队：没有到期日的免费试用会变成无人拥有的依赖。

本分析的局限性

我没有验证 MonkeyCode 的模型列表、token 计量、速率限制、服务器运行时、存储、出口流量或正常运行时间。本文是一个提案，而不是已执行的测试。上面的代码是一个估算工具，而不是你应该针对该服务运行的命令。

如果你评估 MonkeyCode，向运营商询问这个模型需要的数字：token 计数规则、速率限制、持久存储大小、出口策略、基础镜像支持、冷启动行为和最近的正常运行时间窗口。把这些代入四个关卡并公布记分卡。

哪个变量会逆转你的决策：迁移时间、token 计数还是存储限制？这是值得首先测试的。