一、十几个入口，其实只有四个变量

书上列了 16 种使用途径，看着很散。但把它们拆开，回答的其实是四个问题： 谁在调（人还是程序）、跑在哪（厂商机房／自己机器／公司内网）、 按什么付费（订阅／按量／一次性买硬件）、数据出不出内网。 这四个问题一回答，16 种自动归成四类，每一类的成本和约束都很清楚：

二、按量的本质：成本跟着用量走

API 的账单只有一个公式：输入 token 数 × 输入单价 ＋ 输出 token 数 × 输出单价。问得多就付得多， 没有下限也没有上限。 订阅反过来：价格固定，但有一个你没被明说的次数天花板。个人用撞不到，团队用会撞到。 本地部署的成本结构又是另一种：硬件是一次性的、电费是固定的， 用量再大也不涨（前提是并发扛得住）。 Demo 里那个交叉点就是这么算出来的：把「固定成本」和「随用量涨的成本」分开列，再找两条线的交点。 约 1208 次/天——低于这个数走 API，高于它走订阅。

三、最便宜的那个不一定能选

钱的账算完，还有三条红线，任何一条不过，便宜就跟你没关系。 数据能不能出内网。 API 和订阅都要把内容发到厂商的服务器。 合同、病历、施工图纸这类没过审的材料，一步都不能发。这一条不过，只剩本地部署。 延迟能不能接受。 本地跑一个 7B 模型，出字速度可能比 API 慢，而且你一个人用的时候它在满载， 三个人同时用就开始排队。 出了问题谁负责。 订阅有 SLA，服务挂了有人赔；本地挂了，只能自己修。 所以真实的选型顺序不是「先算钱」，是先划红线（数据）→ 再算钱 → 最后看体验。 顺序反了，算出来的最优解往往是用不了的。

四、从订阅换到 API 的时机

量小的时候订阅更省心：145 元固定，不用写一行代码。 API 便宜，但你得自己写调用、做重试、管密钥、处理限流——这些都是人力。 所以真正的拐点往往不是那张交叉点，是「有没有人维护」这条线。 一个人偶尔用，交叉点算出来再便宜也不值得他搭一套脚本。 反过来说，只要这套东西已经嵌进业务流程（比如每天自动生成日报），那 API 就是明显更优的：用量可控、 成本可测、还能按需切换模型。 最后提醒一句：单价是会变的。 Demo 里的 1 元／2 元每百万 token 是我给的假设， 各家各时期都不一样。要记的不是数字，是这张表的算法。

五、动手 Demo：每天 200 次：API 24.0、订阅 145、本地 600.9；拐点在 1208 次

设定一个典型用户：每天问 200 次，每次输入约 3000 个 token（两千字左右的材料）、输出 500 个 token。 算三笔账——网页版订阅、API 按量付费、本地买一张两万块的卡自己跑。 然后扫四个用量档，看排名什么时候翻转。

calls = 200.0                 # 每天问答次数
tok_in, tok_out = 3000.0, 500.0
sub = 145.0                   # 订阅月费
p_in, p_out = 1.0, 2.0        # API 每百万 token 单价
card, life, watt = 20000.0, 3.0, 350.0

m_in = calls * 30 * tok_in / 1e6
m_out = calls * 30 * tok_out / 1e6
api = m_in * p_in + m_out * p_out
local_hw = card / (12.0 * life)        # 硬件摊到每月
local_pow = watt / 1000 * 24 * 30 * 0.6 * 0.3

unit = (tok_in * p_in + tok_out * p_out) / 1e6 * 30
cross = sub / unit                     # 打平点的每天次数

实跑输出：

--------------------------------------------------------------------
用法决定成本：同样每天 200 次问答，三条路差出一个数量级
--------------------------------------------------------------------
  方式         每月成本（元）   成本结构         主要约束
  ----------------------------------------------------------
  网页版订阅              145   固定             有次数上限
  API 按量               24.0   随用量线性涨     无上限
  本地部署              600.9   硬件摊销＋电费   一次性投入大

  每月输入 token           18.0 百万
  每月输出 token           3.0 百万

  这个量级下 API 最便宜，订阅次之，本地最贵——因为本地那两万块的显卡摊到 36 个月，每月就是 556 元。
  但**这个结论只在「每天 200 次」这个用量下成立**。用量一变，排名就变：

  每天次数   API 月费   订阅月费   本地月成本   最便宜
  ---------------------------------------------------
        20        2.4        145        600.9   API
       200       24.0        145        600.9   API
      2000      240.0        145        600.9   订阅
     20000     2400.0        145        600.9   订阅

  API 与订阅打平的每天次数 约 1208 次
  **低于这个数走 API，高于这个数走订阅**——这是纯按钱算的分界线。
  真实决策还要看三件钱算不出来的事：数据能不能出内网（决定能不能用 API）、响应延迟能不能接受（本地可能更慢）、出了问题谁负责（订阅有 SLA）。

  单价这里是我显式给的假设（输入 1 元／百万 token、输出 2 元、显卡 2 万），各家各时期都不一样，**别记数字，记这张表的算法**：把「固定成本」和「随用量涨的成本」分开列，再找交叉点。

三行结果：订阅 145、API 24.0、本地 600.9。本地最贵，因为那两万块的卡摊到 36 个月， 每月就是 556 元——还没开始用，已经比订阅贵了四倍。 API 之所以只有 24 元，是因为这个用量太小：每月输入 18 百万 token、输出 3 百万， 按 1 元／2 元算就是 18 ＋ 6 ＝ 24 元。 但结论只在「每天 200 次」成立。扫四档就翻转了：每天 2000 次时 API 涨到 240 元，订阅还是 145 元； 本地那条线一动不动 600.9 元。 交叉点在 1208 次/天：145 ÷ 0.12（每次问答的 API 单价）＝ 1208。 低于它走 API，高于它走订阅。 注意本地这条线永远不参与这个比较—— 它只有在「数据不能出内网」这个前提被触发时才上桌。 这套算法最值钱的地方不是算出来的数，是把固定成本和变动成本分开列这个动作。 任何「到底该买还是该租」的问题（服务器、车、打印机），用的都是同一张表。

30 秒实验

1. 把每次输入从 3000 token 改成 300，重算交叉点。 它会从 1208 次涨到几千次——说明「长材料用户」和「短问答用户」的最优解完全不同。
2. 把显卡价格从 2 万改成 5 万，算本地月成本涨到多少、需要多少用量才能比订阅便宜。 你会发现它可能永远比不过——这就是「本地一定省钱」的反例。
3. 把使用年限从 3 年改成 5 年，硬件摊销从 556 降到 333，本地月成本降到 378。 摊销年限是这张表里最容易被随便填、又最影响结论的一个参数。

常见误区

1. 「本地部署一定最便宜」。每天 200 次时它是最贵的那个，差 4 倍。 本地的优势是数据不出门和长期无上限，不是单价。
2. 「API 便宜所以都该用 API」。数据出不了内网就没得选；而且 API 要人维护，人力的钱不进这张表。
3. 「订阅有次数上限，所以不划算」。绝大多数个人用户撞不到那个上限，145 元固定反而最省心。 别拿团队场景的结论套个人场景。

途径选完，接下来看它到底能干什么。下一节看推理——DeepSeek 最出圈的那项能力，也是被误解最多的一项。

• ☐ （本节完，下一节 1.3.3 DeepSeek的逻辑推理能力）

相关笔记

• 🧠 AI训练师手册2 · 索引