本地部署LLM的真实成本：别只盯着电费

一位物流公司的工程总监Sarah，在云推理账单单月冲到8000美元后，果断买了一块本地GPU。硬件周二到货，周五跑通CUDA，第三周第一条流水线投产。第一个完整月结束后，她盯着电费单看了很久——一块24小时不间断跑推理的GPU，每天至少处理十万token，电费却只是云API同等用量的一小部分。

于是"本地推理几乎免费"的说法开始流行。但这篇来自ayraix.com的实战复盘给出了一个更冷静的结论：电费根本不是真实成本，连边都算不上。

三个月的真实TCO账本

作者把前三个月的开销摊开算了一遍。硬件侧，一块中端显卡加上主机内存升级套件，按24个月摊销；电力侧，GPU加整机24小时运行，功耗在几百瓦的量级。三项加总，每月运行成本约58到73美元。

对照云API，在估算约每天50万token的用量下，前沿模型的月账单约180到240美元。净节省每月107到180美元，大约第4个月回本。

账算得通，但有一个严格的前提：高频、重复性任务，比如工单分类、信息抽取、结构化输出，且数据敏感不愿外发，同时能接受"很好"而不是"最强"的模型能力。作者明确指出，如果每天调用低于100次，把时间成本诚实计入后，API反而更便宜。

TCO（Total Cost of Ownership，总拥有成本）是评估IT基础设施投资时常用的财务框架，它要求把一项资产从采购到退役期间的所有直接与间接支出都纳入考量，而不只是看初始购买价格。典型的TCO构成包括：硬件采购成本按折旧年限摊销、电力与散热、机房空间、软件许可、运维人力、故障停机损失以及升级替换成本。在本地LLM推理场景中，TCO的意义尤为突出，因为GPU的账面价格只是冰山一角，驱动维护、系统排障、模型版本管理等隐性人力往往占据更大比重。若只比较电费与云API单价，就会得出"本地几乎免费"的错觉；而按TCO口径把24个月摊销和运维时间折算进去，结论才会回归真实。作者用三个月账本正是这一框架的简化应用。

没人写进表格的隐藏成本

真正让"免费本地推理"站不住脚的，是前三个月里那40个小时——和构建AI系统毫无关系的时间。

作者列了一份让人肉疼的清单：主机系统内核更新后CUDA驱动冲突，4小时；Docker网络变更导致Ollama主机名解析失效，6小时；模型悄悄输出损坏的JSON、最后查出是GPU显存分配bug，8小时；批处理任务中GPU利用率莫名卡在60%，3小时性能剖析仍未完全解释清楚；剩下的时间耗在配置漂移、模型重下载和Ollama版本锁定上。

这40小时换来的是对推理引擎在并发负载下如何分配显存、Docker网络与GPU直通如何交互、上下文窗口大小如何影响系统内存（而非仅显存）的真实理解。作者对此的定性很精准：这不是税，是学费——但买GPU之前，你该清楚自己付的是哪一种。

云API调用一发生就产生账单，本地推理调用产生的是时间成本，隐性地摊在几个月的持有期里。两者都真实，只是只有一个会出现在账单上。

文中反复出现的Ollama是一个开源的本地大模型运行工具，它把模型下载、量化格式加载、推理服务暴露为本地HTTP接口等步骤封装成简单命令，大幅降低了本地部署门槛，常被视为"本地跑LLM"的默认入口。Ollama底层依赖llama.cpp推理后端，支持GPU直通与CPU回退，并通过Modelfile管理提示模板与参数。但它的便利也带来文中提到的运维问题：版本升级可能改变API行为或模型缓存路径，容器化部署时需正确配置主机名解析与端口映射，多版本共存时需锁定版本以保证可复现。理解Ollama在技术栈中的位置——它是推理服务层而非模型本身——有助于判断哪些故障属于工具链问题、哪些属于硬件或驱动问题。

被忽视的瓶颈：系统内存

几乎所有本地LLM教程都盯着显存，作者却在显存触顶之前先撞上了系统内存的墙。大上下文窗口让主机操作系统频繁换页，推理速度慢到抵消了GPU的全部优势。

解决方案不是换更好的显卡，而是升级系统内存——这套升级对实际吞吐的提升，超过了作者尝试过的任何模型优化。结论很直接：跑14B以上模型加长上下文，系统内存要按"它真的很重要"来配置。

上下文窗口（context window）指模型一次推理能够读入的token总数，包括提示词、历史对话与待生成内容。扩大上下文窗口会显著增加内存占用：除了KV Cache（键值缓存，随序列长度线性增长并通常驻留显存）之外，推理框架在加载模型权重、处理长输入的分块与中间张量时也会消耗大量主机内存。当显存不足以容纳KV Cache时，部分实现会把权重或缓存卸载到系统内存，导致CPU与GPU之间频繁数据搬运，表现为换页和吞吐骤降。这正是作者遇到的现象：显存尚未报错，系统内存先被换页拖垮。因此长上下文场景下，系统内存容量与带宽和显存同样关键，配置时应按模型参数量、并发数与最大上下文长度共同估算。

隐私才是真正的决策驱动力

用量是表格上的算术题，隐私是另一种性质的论证，也是作者真正的决策动因。

他的流水线处理什么？文档摄取工作流里的结构化记录与每一版生成输出的修订历史；表单自动化里的联系方式、偏好数据、个人陈述；每日反思系统里他担心什么、在为什么努力、对同事的看法；基础设施健康监控里各服务的运行状态与整个系统的形态。

这些数据一个token都不外流。不发给OpenAI、Anthropic、Google或任何云厂商。模型跑在三英尺外的GPU上，没有网络访问，没有第三方服务器日志，没有服务条款把职业数据的权利让渡给公司。作者把这称为架构决策，而非偏执——一旦系统性地审计哪些工作流在处理个人数据，你会意识到自己曾随意地把多少东西发给了第三方基础设施。

云API仍然赢的场景

作者并不讳言自己仍在用前沿云API和Claude，而且理由充分：前沿级推理任务，如架构决策、复杂多步调试、需要真正写得好的文字；一次性任务，本地环境搭建开销超过直接调用的成本；错误答案有真实后果、14B能力不够用的场景；以及涉及公开数据、隐私不是变量而质量最重要的任务。

14B模型的能力天花板是真实存在的。本地模型在分类、抽取、结构化输出和模式化代码补全上表现出色，在细微判断和复杂推理链上不可靠。知道天花板在哪，按此路由——混合架构不是妥协，是正确的架构。

混合架构（hybrid architecture）指在同一套AI系统中按任务特征把请求路由到不同推理后端：敏感、高频、模式化的任务走本地小模型，复杂推理、高质量写作或低频率任务走前沿云API。实现上通常需要一个路由层，依据数据敏感级别、任务类型、置信度阈值或成本预算决定去向，并对本地模型输出做校验与回退。这种设计的价值在于同时获得隐私边界、成本控制与能力上限：本地模型承担80%的常规流量，云模型只处理真正需要强推理的尾部请求。路由策略应可配置、可观测，记录每类请求的命中后端与失败回退情况，避免把"混合"做成两套系统各自为政的拼凑。

买GPU之前只需回答一个问题

我会不会在未来12个月里，每天100次以上，对不愿发给云API的数据运行这个模型？

答案是会：买。经济和隐私两本账都成立。答案是不会：API更便宜、上手更快、零维护负担，这个答案并不丢人。真正的错误是为偶发使用买硬件，然后假装那40小时的基础设施工作不算成本。

作者最后的建议很实操：翻出过去三个月的云API账单，统计总token、汇总费用、除以30。如果月度数字高于中端GPU的摊销成本（24个月约每月25到30美元），这本账值得拉个表格细算；如果低于，继续付API账单，你的时间比省下的钱更值钱。无论哪种情况，都建议先把一条流水线跑在本地推理上——不是为了省钱，而是为了知道自己还不知道什么。