中等负载（500万token/天）本地TCO约18387美元、每百万token 10.07美元，仍然高于OpenAI API的6.90美元，只有到重负载本地才在每百万token上翻盘，个人用户到底该按什么用量来算“本地划不划算”？

导语：一个被误读的对比结论

“本地部署每百万token 10.07美元，API只要6.90美元，所以本地不划算”——这个推理在中等负载区间是成立的，但它被大量讨论者错误地外推成了普遍结论。问题出在比较对象的不对等：API单价是纯边际成本，本地单价是固定成本除以当期用量的摊销值。前者不随用量变化，后者随用量单调下降。两条曲线必然相交，交点之前API占优，交点之后本地占优。把某一用量点的比较结果当作全局判断，等于忽略了摊销函数的形状。

本文的主线只有一条：把“本地划不划算”还原为一个可计算的盈亏平衡用量问题。围绕这条主线，我们先拆解TCO的构成，再复算18387美元这个数字的来源与校验方式，然后推导平衡点公式，最后落到个人用户可执行的三步决策法。所有关键参数均标注来源或明确标注为模拟/整合数据，读者可代入自己的报价重算。

核心判断：本地与API的比较不是“谁更便宜”，而是“在你的用量下，哪条成本曲线更低”。用量是自变量，不是背景信息。

一、问题定义：把“划算”还原为摊销函数

1.1 三个必须区分的成本概念

讨论成本前必须先对齐口径，否则所有比较都是无效的。工程经济学中通常区分三类成本：固定成本（不随产量变化的投入，如GPU购置、机房改造）、可变成本（随产量线性变化的投入，如按token计费的API调用、电费中的计算部分）、总拥有成本TCO（全生命周期内所有相关支出的现值之和，含运维人力、折旧、能耗、备件、机会成本）。

本地部署的每百万token成本，是把固定成本按折旧年限摊到每个月、再除以当月token量得到的平均成本；API的每百万token价格则是供应商给出的边际价格。平均成本与边际价格直接比较，只有在特定用量下才有意义。笔者认为，大量“本地贵还是API贵”的争论，根源就是这两个口径被混用了。

1.2 盈亏平衡用量的形式化定义

设本地月固定摊销为 F，本地每百万token的可变成本为 v，API单价为 p，月用量为 Q（单位：百万token）。则：

本地月成本  C_local(Q) = F + v·Q
API 月成本  C_api(Q)   = p·Q
平衡点      Q* = F / (p − v)      （要求 p > v）

这个式子说明两件事：第一，只有当API单价高于本地可变成本（p > v）时，平衡点才存在，否则本地永远不可能在单位成本上翻盘；第二，Q* 与固定成本F成正比，与价差（p−v）成反比。代入本文数据：F≈18387−v·Q，若取 v≈0.4美元/百万token（电费与运维的可变部分，模拟估计），Q=5时 F≈18387−2=18385美元，则 Q*≈18385/(6.90−0.40)≈2830百万token/月，即约94百万token/天。这个量级远超个人用户，也远超多数中小企业。

二、TCO结构拆解：固定项、半固定项与边际项

2.1 固定项：硬件与基础设施

本地推理的固定投入主要是GPU及其配套。以单机8卡主流推理配置为例，整机采购价随显存容量与互联带宽差异很大，公开渠道的整机报价区间通常在数万至十余万美元量级（具体以厂商报价为准，本文不引用单一报价作为普适数据）。按3年直线折旧、残值率10%计算，月折旧额约为采购价的2.5%。此外还有机房、UPS、网络交换等一次性投入，通常按5年摊销。

需要强调的是，折旧年限的选择对结论影响极大。GPU代际更新周期约18–24个月，若按3年折旧，账面成本低于真实技术贬值速度；若按2年折旧，月固定成本上升约50%。笔者认为，对个人和小团队，采用2年折旧更接近“技术过时风险”的真实成本，也更保守、更经得起检验。

2.2 半固定项：电力、制冷与运维人力

电力成本与负载强相关但存在基础功耗。一台8卡推理服务器整机功耗视卡型与利用率，通常在2–6kW区间波动。按工业电价0.08–0.12美元/kWh、日均有效运行20小时估算，单机月电费约在100–450美元量级（模拟估算，实际以当地电价与PUE为准）。制冷按PUE 1.3–1.5折算，需再乘系数。

运维人力是最容易被低估的一项。模型版本管理、推理框架升级、故障排查、监控告警，对个人用户意味着每周数小时到十余小时的时间投入。若按机会成本折算（例如每小时30–80美元），月人力成本可达数百至上千美元。本文在18387美元的测算中，将人力按兼职折算计入，具体见下一节。

2.3 边际项：随token量增长的部分

本地推理的边际成本主要是电费中随计算量增长的部分，以及可能的散热与带宽开销。由于GPU在低利用率下功耗下降有限，本地边际成本曲线并非严格线性，而是呈现“阶梯+平台”特征：利用率低于某阈值时，增加token几乎不增加电费；超过阈值后需扩容，成本阶跃上升。这一点与API的严格线性计费形成结构性差异，也是本地在高利用率区间单位成本快速下降的物理原因。

表1：本地TCO三类成本的结构与对平衡点的影响（结构为笔者归纳，数值为区间性模拟估计）

三、复算18387美元：参数、公式与校验

3.1 测算口径与假设

为了让读者能逐项复算，本文把18387美元的月TCO拆成可替换的参数表。需要说明：该数字来自给定测算情境，本文对其做结构还原与合理性校验，不宣称其为某一厂商的官方报价。所有区间性参数均标注为模拟/整合估计。

表2：18387美元月TCO的结构还原（分项为模拟整合数据，合计对齐给定值）

3.2 单位成本换算与校验

月用量500万token/天，按30天计为150百万token/月。18387 ÷ 150 ≈ 122.6美元/百万token？这与10.07美元不符。这里必须注意单位：若“500万token/天”指5 million tokens/day，则月用量为150 million tokens，单位成本应为122.6美元/百万token。10.07美元对应的是月用量约1826百万token，即约60.9百万token/天。

这一差异提示：原始表述中的“500万token/天”与“10.07美元/百万token”在算术上不自洽，除非“500万”指5000万（50 million）或单位口径另有约定。本文的处理方式是：保留两个给定数字作为情境锚点，同时明确指出其口径张力，并在平衡点推导中采用“单位成本10.07美元”这一锚点，因为它直接决定与API 6.90美元的相对关系。读者代入自己的Q时，应以 C_local(Q)/Q 重新计算，而非直接套用10.07。

四、盈亏平衡点推导：本地何时翻盘

4.1 以单位成本锚点反推平衡用量

已知本地在Q₀处单位成本为10.07美元，API单价6.90美元。设本地月固定摊销F、可变成本v，则 10.07 = F/Q₀ + v。若取v≈0.4，则 F/Q₀≈9.67，F≈9.67·Q₀。平衡点 Q* = F/(6.90−0.40) ≈ 9.67·Q₀/6.50 ≈ 1.488·Q₀。也就是说，平衡用量约为当前锚点用量的1.49倍。若锚点确为500万token/天，则Q*≈745万token/天；若锚点实为5000万token/天，则Q*≈7440万token/天。两种解释下，个人用户都远未达到。

4.2 平衡点的图形直觉

把两条成本曲线画在同一坐标系：API是过原点的直线，斜率6.90；本地是一条截距为F、斜率为v的直线。交点横坐标即Q*。由于v远小于p，本地直线更平缓，交点之后本地必然更低。这个几何关系告诉我们：降低F（二手硬件、共享机房、缩短折旧）或降低v（更高效的推理框架、量化、批处理）都能左移交点；而API降价则会右移交点。近两年API价格持续下行，客观上把本地的翻盘门槛推高了，这是个人用户必须纳入考量的动态因素。

4.3 操作步骤：三步算出你的Q*

1. 列固定项：把硬件采购价除以折旧月数（建议24），加上机房与网络摊销，得到F。
2. 估可变项：用实测电费增量除以同期token增量，得到v；若无实测，取0.3–0.6美元/百万token作为模拟区间。
3. 代入公式：Q* = F/(p−v)，p取你实际使用的API档位单价（注意区分输入/输出、缓存命中价）。把Q*换算成日用量，与你的真实日用量比较。

拓展阅读：Hugging Face的推理性能与成本讨论社区（discuss.huggingface.co）、vLLM官方文档中的吞吐与显存说明（docs.vllm.ai），可用于校准v与吞吐参数。

五、API侧的真实成本：单价之外的四项隐性支出

把API简化为6.90美元/百万token会高估其优势，也会低估其约束。至少四项成本未被单价覆盖：限流与配额（高并发时需申请提额或购买预留吞吐）、数据合规（敏感数据出域的法务与审计成本）、供应商锁定（模型下线、接口变更的迁移成本）、延迟抖动（跨网络调用对实时业务的体验影响）。这些成本难以精确货币化，但在决策中必须定性计入。

反过来，本地也有API没有的成本：能力上限（本地模型规模受显存限制，复杂推理任务质量可能低于旗舰API）、迭代滞后（新模型权重开放通常晚于API上线）、故障自担（无SLA兜底）。笔者认为，正确的比较不是“单价对单价”，而是“全成本对全成本、全能力对全能力”。对个人用户，API在能力与省心度上的优势往往被低估；对数据敏感型团队，本地的合规价值又常被单价比较掩盖。

决策提示：先问“数据能不能出域”，再问“用量够不够大”。前者是0/1约束，后者是连续变量。顺序错了，算得再精也无意义。

六、个人用户决策路径：三步定量法

6.1 第一步：量化你的真实日用量

个人用户的典型用量远低于讨论中的“中等负载”。以编程助手为例，一次对话往返含系统提示、上下文与输出，通常消耗数千至数万token；若每天进行50次此类交互，日用量约在0.1–1百万token量级。写作、翻译类任务单次消耗更低。把日用量如实记录下来（多数API控制台提供用量面板），是全部决策的起点。

6.2 第二步：按你的Q重算两条曲线

不要套用别人的10.07或6.90。用你的F、v、p和Q代入第一节公式，得到两个具体数字。若你的Q仅为个位数百万token/月，本地单位成本会高得离谱（固定成本被极小分母摊薄），此时API几乎必然占优；若Q达到数百百万token/月且数据不可出域，本地才进入候选区。

6.3 第三步：加入非货币权重做最终判断

把合规、能力、延迟、运维负担各按高/中/低打分，与成本差额一起看。一个可操作的规则是：若成本差额在总预算中占比低于10%，优先按非货币因素决策；若高于30%，成本应占主导。这条规则是笔者基于工程决策实践的归纳，非文献结论，读者可自行调整阈值。

表3：按日用量分档的决策建议（阈值为本文模拟归纳，非普适标准）

七、敏感性分析：哪些参数最致命

对Q*做一阶敏感性分析可知，其弹性主要来自三个参数：折旧年限、API单价、以及实际利用率。折旧从3年缩短到2年，F上升50%，Q*同比例上升；API单价下降20%，价差（p−v）缩小，Q*上升幅度可能超过25%（因分母变小）。利用率的影响更隐蔽：若本地设备日均有效利用率仅20%，相当于F被摊到更少的有效token上，单位成本成倍放大。

笔者认为，利用率是个人用户最容易被忽视的杀手。个人场景的用量天然呈脉冲式，设备大量时间闲置，而固定成本照摊。这也是为什么“个人本地部署”在经济上通常不成立——不是硬件太贵，而是分母太小且不稳定。相比之下，团队共享能把利用率拉高，平衡点才可能进入可达区间。

八、边界条件与常见误判

第一类误判是静态比较：用今天的API价格对比今天的硬件价格，忽略API持续降价与硬件贬值。第二类是忽略质量差异：本地小模型单位token更便宜，但完成同一任务可能需要更多token或更多轮次，有效成本未必低。第三类是把沉没成本当固定成本：已经买了的设备，其购置价不应再影响“未来是否继续本地”的边际决策，正确的比较是“继续本地的增量成本”对“API的增量成本”。

边界条件同样重要：当任务涉及强实时性、超长上下文、多模态理解时，本地与API的能力差距可能压倒成本考量；当数据完全可公开、任务高度标准化时，API的规模经济优势最明显。本文的定量框架适用于“能力大致可比、数据可自主选择”的中间地带，超出该地带应优先按能力与合规约束决策。

九、结论与展望

回到最初的问题：个人用户该按什么用量来算“本地划不划算”？答案是——按你自己的、可持续的、剔除脉冲峰值的日均有效用量来算，并用 Q* = F/(p−v) 求出平衡点，再与你的Q比较。在给定情境下，中等负载的本地单位成本仍高于API，翻盘需要约1.5倍于锚点的用量（按本文口径），个人用户通常达不到；但这不构成对本地部署的否定，只说明它服务于不同的用量与合规区间。

展望未来，三个趋势会改变平衡点位置：推理框架的效率提升会压低v，模型量化与蒸馏会降低硬件门槛从而压低F，而API价格战会压低p、右移交点。三者赛跑的结果因场景而异，唯一不变的方法论是：把用量作为自变量，把全成本作为因变量，动态复算，而非记住一个静态结论。