自建GPU算力 vs 直接调用LLM API：成本分水岭在哪

「要不要自己买卡」这个问题，几乎每个做大模型应用的团队都会在第二个月撞上。第一版 demo 用免费额度跑通了，用户开始进来，账单开始有点分量，于是有人提出来：与其每月付 API 费，不如买两张卡自己部署。

这个直觉在很多时候是错的。本文不谈玄学，只算账：把三条主流路线摆在同一张表上，给出可复算的判断口径。

一、先把三条路的账本摆出来

真实场景里只有三条路，第三条常被忽略：

1. 纯 API：调用第三方推理服务，按 token 或按请求付费
2. 租 GPU 自部署：按小时租算力，自己起推理框架（vLLM / SGLang 等）
3. 买 GPU 自建：一次性购机，机器归你，成本摊到全生命周期

下面这张表按国内 2026 年的常见市场价区间填的，你可以直接用自己的报价替换：

注意最后一行：数据合规是自建唯一无法被替代的理由。如果你的业务没有这条硬约束，那么其余所有维度，自建都比 API 更贵或更慢。

二、真正决定成本的是「有效占用率」

很多人比价方式是错的：拿「API 月账单」和「机器价格」直接比，觉得机器一买就能用三年、月均几百块。这个比法漏掉了一个关键量——这台机器有多少小时真的在干活。

把它写成一个可算的式子：

# 自建盈亏平衡点
def breakeven_requests(machine_price, gpu_kwh_watt, kwh_price,
                       idle_watts, months=36, api_price_per_req=0.002,
                       utilization=1.0):
    """
    machine_price      整机价格（元）
    gpu_kwh_watt       满载功耗（瓦）
    idle_watts         空载功耗（瓦）
    utilization        有效占用率 0-1
    api_price_per_req  对照的 API 单次请求均价（元）
    """
    bill = 0.0
    for _ in range(months):
        full = 30 * 24 * 3600 * utilization       # 满载秒数
        idle = 30 * 24 * 3600 - full              # 空载秒数
        bill += (gpu_kwh_watt * full + idle_watts * idle) / 1000 / 3600 * kwh_price
    total = machine_price + bill
    # 相同支出下，API 能买多少次请求
    return {"自建总成本": round(total, 0),
            "等价 API 请求数": int(total / api_price_per_req),
            "盈亏平衡月请求量": int(total / api_price_per_req / months)}

print(breakeven_requests(20000, 450, 0.6, 120))
# 示例输出：自建总成本约 27000 元，等价 API 请求约 1350 万次，月平衡点约 37.5 万次

按这个例子：一台 2 万元的机器，三年下来连电费约 2.7 万。只有当你的总请求量超过约 1350 万次（月均 37 万次以上）时，自建才开始占优。

三、毛利率视角：API 才是更稳的生意

换个角度看同一件事。假设你正在做一个对外收费的应用，判断标准就变成了：每赚 1 元收入，要花多少在算力上。

（表中 API 成本按每次请求 2 元/千 token、平均 1 千 token 折算，仅用于展示曲线形状；实际单价务必按你自己的模型刊例价替换。）

这张表的形状比数字更重要：API 成本随量线性增长，自建成本几乎是一条水平线。两者的交点在哪，取决于你的量级——而不是取决于谁更「先进」。

三、什么情况该选「租」

3.1 训练与微调：几乎总是租

训练任务有三个特征：占用率间断、型号迭代快、失败成本高。这三条全部指向租赁。

• 占用率间断：模型训练很少 7×24 跑满一年。真实情况是「两周密集训练 + 三个月推倒重来」。以年 1200 有效小时计，租卡支出约 2600 元，买卡仅折旧就是 2200 元，还没算占用的资金
• 型号迭代快：2022 年买 3090 的人，2024 年训 7B 全参已经吃紧；2023 年买 4090 的人，2026 年跑 LoRA 仍然舒服。同一笔钱，买的时间点决定它能用多久
• 失败成本高：训练报 OOM、数据 pipeline 卡死、CUDA 版本冲突——自购机器这些坑要自己填，租卡平台通常给你一个能跑的基础镜像

3.2 突发推理与峰值流量

做产品的人迟早会遇到这个问题：平时 5 QPS，活动日 200 QPS。自购卡按峰值配置，99% 的时间在空转；按均值配置，活动日直接崩。

这正是云与租赁存在的意义——按需扩容。另一条更省心的路是直接把推理交给 API：流量波动由服务方吸收，你只为实际 token 付费。下文会给出三条路的成本对照。

四、什么情况该选「买」

买卡不是不理性，只是它的适用条件很窄。以下三条同时满足，才值得考虑自购：

还有一类隐性成本容易被漏算：人。自购机器意味着有人要管驱动、管散热、管电源、管故障。一台机器一年至少吃掉 0.3 个人力。把这部分折算进去，很多「自购更省」的账本立刻反转。

五、第三条路：直接调用大模型 API

很多人纠结「租还是买」，其实真正的问题问错了。如果目标只是让模型在你的产品里跑起来，而不是改造模型本身，那么第三条路往往最便宜：直接调 API。

三种方式逐项对照：

结论很清楚：要做「改模型」的事，租；要做「用模型」的事，调 API。先调 API 验证业务是否成立，确认有价值后再考虑微调——顺序反过来，钱就白花了。

六、五天验证路径：花几十块得出结论

最怕的不是选错，是在没数据的情况下选。以下路径可以在 5 天内用极低成本拿到决策依据：

1. 第 1 天 · 验证可行性：用免费额度把业务流程跑通，确认模型输出质量达标。这一步成本为零
2. 第 2 天 · 量化成本：统计单次请求的平均 token 数，乘以日均请求量，得出 API 路线月成本
3. 第 3 天 · 摆出对照账本：把上一节的毛利率表格用你自己的请求量重算一遍
4. 第 4 天 · 小规模试训：如果确认需要微调，只租 1 张 4090 跑 LoRA，控制在 10 小时以内，验证效果增量
5. 第 5 天 · 决策：效果增量不明显 → 停在 API；效果增量显著且请求量大 → 再评估常驻部署

下面这段代码可以帮你算清第 2 步的账本，直接改成你的数字：

def line_breakdown(requests_per_day: int, avg_tokens: int,
                   price_per_1k_tokens: float = 0.002,
                   gpu_hourly: float = 2.2,
                   hours_per_day: float = 10,
                   days: int = 30) -> dict:
    """API 路线 vs 常驻 GPU 路线的月度成本对照"""
    # API 路线：按 token 计费，注意多数服务商 input/output 分别计价
    api_cost = requests_per_day * avg_tokens / 1000 * price_per_1k_tokens * days
    # GPU 路线：只为实际开机小时付费（常驻部署则 hours_per_day = 24）
    gpu_cost = gpu_hourly * hours_per_day * days
    return {
        "API 月成本": round(api_cost, 2),
        "GPU 月成本": round(gpu_cost, 2),
        "更优路线": "API" if api_cost <= gpu_cost else "GPU",
        "毛利率": round(api_cost / gpu_cost, 2),
    }

# 案例：日 2000 次请求，平均 800 token，单价按 2 元/百万 token
print(line_breakdown(2000, 800, price_per_1k_tokens=0.002))
# 输出示例：{'API 月成本': 96.0, 'GPU 月成本': 660.0, '更优路线': 'API', '毛利率': 0.15}

七、常见问题 FAQ