我见过太多人在“本地部署大模型”和“付费买 Token”之间做选择时只用一句话下结论本地部署一次性买张显卡以后就不花钱了肯定比按量付费的 API 便宜。这个结论在大多数情况下是错的而且错得离谱。原因很简单大家把一笔账算漏了而且不是漏一项两项是漏掉了电力、隐性维护、数据标注、上下文适配、团队时间成本还有最容易被忽略的“闲置率”。正好最近不少朋友在问用 Ollama 本地部署 DeepSeek和直接买商用大模型 API到底哪个划算我自己做过几年企业 AI 应用的落地也在自己机器上折腾过本地部署今天就把这笔账从头算一遍。先说结论本地部署和付费 Token 根本不是同一个赛道的产品。有人买了 32G 显存的机器结果每天只跑几次测试算下来单次成本贵得上天也有人每天跑几千次 RAG 检索用了半年 API 才发现费用暴涨早知道就该自己部署。这两种情况我都见过所以这篇不是劝你选哪边而是把真正的成本结构摊开讲清楚。1. 我们到底在对比什么——两种成本模型的天生差异1.1 买 Token 买的是“用完即走”本地部署买的是“持续持有”商用 API 的定价模型是典型的运营支出模式按 Token 计费用多少付多少。今天业务增长多付钱明天业务停滞少付钱。账面上非常灵活没有前期投入。本地部署则是资本支出加运营支出的双重模型。显卡、内存、主板、电源这是一次性硬件成本但还有电费、机柜空间、散热、系统维护、模型更新、故障处理等长期成本。很多人只算了硬件成本把后面这一串“持久战”全忘了。我有个朋友花一万多买了一块二手大显存显卡准备搞本地部署。他算的账很简单市面上好的大模型 API一个月跑业务可能花几千块买显卡一个多月就回本。结果用起来才发现机器只要开着一天至少多花几度电显卡满负荷跑的时候整机功耗能到五六百瓦机箱风扇声音像飞机起飞。最难受的是模型更新开源社区隔几个月就发新版本重拉权重、重新量化、重新测试一次折腾几个晚上。这些时间成本从来不会出现在电商下单页面里。1.2 大多数人对这笔账的算法错在哪常见的错误算法是这样的拿 API 一年费用对比一张显卡的购入价然后直接下判断。比如 API 一年要花两万显卡一万五那就买显卡。这个思路至少漏了四项成本。第一项是折旧和设备寿命。显卡不是永动机高负载跑三年性能和稳定性都会下降而且代际更新快。三年后大概率要升级或更换。你应该把硬件成本除以 36 个月而不是当成一次性支出。第二项是电力与配套。大功率显卡满负荷运行的功耗乘以整机其他部件的耗电再乘以运行时长一年下来不是小数目尤其商业机房电费更贵。第三项是人的时间。本地部署不是装个软件就结束从选模型、量化、调显存、配置上下文长度到处理各种依赖冲突每一步都在烧人力。如果按工程师时薪算可能比 API 费用还贵。第四项是机会成本。把研发时间花在维护本地推理服务上意味着做产品迭代的时间变少了。还有一个经常被忽略的点API 的费用是浮动的本地部署的模型性能是“锁定”的。商用大模型厂商不断迭代同样的价格能买到更好的模型你自己部署的模型一旦更新整个部署流程要重来一遍。算账的时候不能只算今天要把未来六到十二个月的变量都放进去。2. 真正决定钱包厚度的四个关键指标2.1 Token 不是“字数”而是吞吐量、延迟和并发很多人把 Token 理解成“字数”然后对比 API 单价和本地部署的电费这是最表面的算法。Token 的背后其实是三件事你每秒能处理多少 Token每一个请求要等多久以及同一时间能扛住多少个并发请求。API 的优势在于集群化部署算力池很大并发能力通常远高于单机。你调 API只要限流允许几十个请求并发没压力。本地部署是单卡或双卡一旦并发上来显存带宽就成为瓶颈每个请求都在排队实际体验会明显变慢。如果业务对响应时间有硬要求比如客服机器人和在线助手本地部署很可能扛不住高并发这时候“省下”的 Token 钱会变成流失的用户和下降的转化率。本地部署强在低延迟和可控性。API 调用有网络往返一次请求有几十上百毫秒的网络开销反复调用工具或者做多轮 Agent 时累计延迟很明显。本地推理只要模型加载好了同一个机房内延迟可以做到很低。这也是为什么很多做实时语音交互、聊天机器人私有化部署的团队宁愿忍受硬件成本也要本地部署。2.2 显存决定了你能跑多大的模型而模型大小决定能力下限本地部署有一个逃不掉的物理定律模型放不进显存性能再强也白搭。当前跑大模型主流方案是量化后加载到显存里。一个 14B 参数的模型量化到 int4 之后占显存大概在 8G 到 10G32B 模型量化到 int4大概需要 20G 到 24G70B 模型就算量化到 int4也需要 40G 以上显存。再加上 KV Cache、上下文窗口、并发请求占用的额外显存实际需求更高。你买一张 24GB 显存的卡理论上能放 32B 的 4bit 模型但如果上下文长度开到 32K并发五个请求很快就会爆显存。强行塞进去的结果是推理速度骤降甚至直接 OOM 退出。所以很多人买完卡才发现能跑不等于能流畅用能流畅用不等于能满足需求。算账时如果不把模型能力和显存配置对应起来很容易出现硬件买了但根本没法满足应用场景的情况。2.3 上下文长度和并发决定了 Token 的实际消耗效率上下文长度是个容易被忽视的“价格放大器”。API 按 Token 计费时每一轮对话都会把历史消息拼进去上下文越长单次调用的 Token 越多成本上升得越快。如果做 RAG每次检索到的文档片段都会塞入上下文几百页文档累积下来一次请求可能吃掉几千甚至上万 Token。这时候如果还频繁调用费用立刻失控。本地部署没有按 Token 计费的问题但上下文越长推理时的显存占用和计算量越大。长上下文会显著降低生成速度而且本地硬件处理长上下文的效率通常不如大厂集群。也就是说上下文需求越高本地部署的硬件门槛就越高API 的灵活优势反而更凸显。到底谁便宜完全取决于你的平均上下文是多长。2.4 闲置率才是最大的隐性成本我曾经接过一个企业的咨询他们的系统只有白天有人用晚上和周末基本闲置。这本应该是本地部署的绝佳场景但仔细一算不是那么回事。为了支撑白天的峰值他们需要一块较大显存的卡这块卡 80% 的时间是空闲的。显卡空转耗电虽然不高但整机服务器是不能关的系统更新、监控、备份都在跑。API 的优势在于峰值和闲置都按实际用量付费。业务没流量费用就是零。本地部署即使没人用只要机器不关机折旧、电费、维护都在持续产生成本。如果按“有效 Token 量”来分摊这些成本单 Token 价格会高得吓人。这也是为什么很多看起来“该本地部署”的场景最后算下来反而买 API 更划算。3. 用真实场景算一次收支平衡点3.1 先建立自己的计算模型别用感觉要具体算。设定几个变量你的日均请求量、平均每次请求的输入 Token 数、平均输出 Token 数、按年运行天数、API 的每百万 Token 价格、本地硬件总投入显卡加整机按三年折旧、年均电费、年均维护人力成本。把这些代进去就能得出一个“日均调用量临界值”。举个例子假设商用 API 每百万 Token 的总费用是 20 元你日均消耗 200 万 Token一年就是 200×365×20 除以 1000单位是万元的话要换算清楚这里大约是一年 14600 元。本地部署一套能稳定跑 32B 模型的设备显卡加其他硬件按 2.5 万元算三年折旧每年约 8300 元电费一年按 1800 元算维护人力一年按 5000 元算合计每年约 1.5 万元。这样一比本地部署和 API 基本打平。如果日均 Token 量只有 50 万API 一年约 3650 元本地部署每年却要 1.5 万元明显买 API 更划算。如果日均 Token 量达到 500 万API 一年 3.6 万元本地部署只要 1.5 万元这时候才轮到本地部署显优势。3.2 不同业务场景的分场景对比拿写作助手举例。一个人用 AI 写文章每天调用次数可能就几十次每次输入加上输出大概两三千 Token日均消耗不到 10 万 Token。这种情况下买 API 一年也就花几百块本地部署完全不划算你还要花时间做环境配置。再拿客服问答机器人举例。如果日均对话量是五千次每次平均消耗两千 Token日均就是一千万 Token。商用 API 一年费用会非常可观而本地部署只要前期把硬件配好后续增量成本很低明显该选择私有化部署。而且客服系统往往有数据合规要求消息不能出内网这时候本地部署就不是成本问题而是能不能用的问题。代码补全场景就复杂多了。代码补全的 Token 消耗量高但商用 API 的响应速度和准确性往往经过大规模优化本地小模型的补全质量容易不够。如果团队已经有本地代码库可以结合 RAG 做私有化代码助手这时候本地部署的收益不只是省钱还有代码安全。不过也要评估本地小模型在复杂代码理解上的能力是否够用省下的钱可能变成人工重写代码的时间。3.3 混合架构往往才是正解我见过不少团队在 A 和 B 之间二选一最后都吃了亏。更合理的做法是把任务拆开高并发、简单、固定格式的任务优先走本地部署比如信息抽取、分类、摘要需要强推理、生成复杂文档、理解长文本的任务调用 API比如写代码、做复杂分析。这个思路类似数据库的读写分离。一部分流量打到本地推理服务上一部分流量按需走 API同时在后端加一个开关本地服务过载或故障时自动切到 API。这样既能控制成本又能兜底稳定性和质量。混合架构还有一个好处可以用商用 API 的输出作为本地小模型的训练素材逐步提升自建模型的效果降低长期 API 依赖。4. 本地部署实操中的关键细节4.1 硬件选型的常见误区显存不是越大越好很多人以为显存越大越好直接上 24GB 甚至 48GB 的卡。显存大确实能跑更大模型但也要看显存带宽和算力。同一张卡跑 7B 模型可能能有很高的吞吐量跑 32B 模型就会慢一半以上因为每次生成 Token 都要对整个模型做前向计算。如果业务实时性要求高与其上大显存跑大模型不如选一张带宽高、算力强的卡跑小模型换来更快的响应。功耗和散热也要考虑。大显存显卡满载功耗通常超过 300W整机功耗更高。家用环境最多塞两张卡机箱散热一旦压不住高温降频会让性能缩水。企业机房则要考虑电力容量和制冷成本。之前不是没有见过为了省 API 费买机器结果每个月机房托管费加电费比 API 费用还贵的案例。4.2 一套零基础可复制的部署流程本地部署大模型最稳妥的入门方式是用 Ollama它能自动做模型量化、依赖管理和模型服务暴露比自己手动编译部署框架省事太多。所以下面以一个典型流程为例。第一步检查硬件驱动和显存。Linux 环境下输入nvidia-smi确认驱动正常并查看总显存和剩余显存。如果你用的是 AMD 卡需要确认 ROCm 版本支持情况。第二步安装 Ollama。官方脚本一键安装装好后先拉一个参数规模适中的模型比如 7B 或 14B 的模型拉取命令是ollama pull 某个你需要的模型。第三步启动服务。Ollama 默认监听 11434 端口可以通过环境变量修改并发和显存预留参数。第四步用最简单的 Python 代码调本地接口验证服务状态。再配合一个轻量的前端框架比如 Open WebUI 或 FastGPT就能搭出带对话界面的本地助手。如果企业内部要统一管理可以在同一台机器上通过 Docker 方式部署服务便于版本控制、资源限制和日志收集。很多开源部署项目提供 Docker Compose 一键拉起比手动配置省心得多适合直接进入验证阶段。4.3 配置上下文和并发时的取舍本地部署只调通接口远远不够关键在上下文长度和并发参数的配合。先看当前机器的显存占用再决定 KV Cache 能留多大。Ollama 里可以通过设置环境变量控制并发数比如OLLAMA_NUM_PARALLEL控制同时处理的请求数OLLAMA_MAX_LOADED_MODELS控制同时保留在显存里的模型数量。数值不是越大越好。并发高每个请求分到的显存和算力就少生成变慢模型加载多个显存占用飙升容易被系统杀掉。我自己的经验是从小处调起。先设并发为 1跑一轮请求记录每个请求的首次响应时间和每秒生成 Token 数。再把并发调到 4对比吞吐量。理想情况是 4 路并发时每秒总 Token 数比单路时提升但单路响应速度略有下降。如果并发一加上去就报显存不足就要降低上下文长度或者改用更小的量化模型。不要一上来追求大并发宁可单个请求快也不要所有请求一起卡。4.4 量化质量与模型能力的关系量化是本地部署绕不开的环节。把模型从 FP16 压到 int4显存占用直接砍半推理速度更快但也会带来能力损失。对于复杂推理、长文本生成、代码生成量化后的模型在准确率上可能下降几个点。不同量化格式之间差别也很大有的在中文场景下损失更明显。所以不能只看显存放得下还要拿实际业务数据做评测。评测方法很简单准备一批包含标准答案的请求分别用 FP16 和 int4 版本跑一遍对比输出和标准答案的差异。如果差异不大int4 完全可接受如果错误率明显上升宁可换小一号的模型保持 FP16也不要硬上大模型 int4。我见过有人为了跑 70B 模型把量化压到 int3结果生成的回答驴唇不对马嘴最后还是要靠人工修反而更费钱。5. 常见问题与排查技巧实录5.1 本地部署的典型翻车现场本地部署最常见的错误是显存溢出。现象是前几轮对话正常上下文累积变长后突然报错或者生成中断。排查思路很简单观察显存占用曲线如果发现显存使用量持续上升直到打满说明 KV Cache 溢出。解法是限制上下文长度或者清理历史消息把部分内容移入向量数据库而不是一股脑全塞进模型上下文。第二个常见问题是推理速度越来越慢。排除模型本身大小因素后大概率是任务堆积导致排队。这时看服务的请求日志如果请求数多而每请求平均耗时也高那就是负载过高。可以在服务入口加限流或者增加并发设置、换更高带宽的显卡。千万别一慢就不断重试重试会让负载雪上加霜。第三个问题是量化模型输出质量差。很多人换了 int4 模型后觉得模型变笨了第一反应是换大模型。其实可以先确认是否用了合适的量化方式有些模型在特定量化格式下质量下降特别明显。另外采样参数比如温度和 top_p 调得不好也会让输出显得混乱这种不是模型能力问题是参数设置问题。5.2 商业 API 调用的常见报错与处理API 调用的坑和本地部署完全不一样。最常见的是限流报错信息通常是请求频率超过限制。解法是做好退避重试把请求做并发控制甚至本地加一层缓存重复问题不反复查询。第二个是 Token 超额输入太长超过模型上下文限制。第三方平台通常会报上下文长度错误此时需要做文本截断或摘要把关键信息放进新的请求里。第三个是认证问题Token 过期、刷新失败或者权限不足都会导致请求失败。检查服务商文档里的 Token 刷新机制不要把 Token 硬编码在代码里设置自动续期更稳妥。还有些项目会遇到因服务区域和 IP 策略导致的访问失败这种问题通常是服务商的可用性限制需要检查服务提供方的支持列表并从兼容方面考虑。5.3 一个我踩过的真实坑重试风暴有次我给一个系统接开源模型的本地服务服务偶尔响应慢下游代码没有设置超时一直等。等不到就重试重试又把新请求塞进队列最后服务直接雪崩。这个教训说明不论用本地部署还是 API必须在调用层设置合理的超时、重试上限和熔断机制。本地服务再稳定也会遇到模型加载、磁盘 IO 波动等问题没有兜底策略省下来的 Token 钱都会变成事故处理成本。另一个真实教训是监控缺失。用 API 时服务商后台能看到 Token 用量和费用趋势自建服务只能自己埋点。刚开始我什么都没配结果某天发现显存被打满日志刷了几千行错误才知道自己连最基本的请求数、平均耗时、错误率都没有统计。后来补了简单的 Prometheus 和 Grafana 监控终于能直观看到服务健康度也敢做容量规划了。6. 我自己的决策习惯和最终建议6.1 三张表格帮你快速判断我把自己的判断准则整理成几张表供参考。对比维度付费买 Token本地部署大模型初始投入几乎为零高硬件加部署变动成本按量付费上不封顶电费和人力为主并发能力高弹性好受显存和带宽限制延迟有网络开销内网低延迟数据隐私依赖服务商政策数据不出本地模型更新厂商自动迭代自行维护升级维护成本极低持续投入有门槛日均 Token 消耗量推荐方案理由低于 10 万付费 API成本极低省心10 万到 100 万混合或 API本地收益不明显100 万到 500 万混合为主核心流量本地化高于 500 万本地部署为主API 费用压力大应用场景建议方案关键考虑个人写作、学习API无需硬件投入客服问答、信息抽取本地部署高并发、数据合规代码补全、复杂推理API 或混合模型能力要求更高RAG 知识库本地部署长文本隐私保护6.2 给你的落地建议我个人的看法是绝大多数人一开始不必直接买硬件。先用 API 把业务逻辑跑通把 Token 用量和响应要求摸清楚再根据实测数据做决策。如果业务量确实大到 API 费用影响整体成本再考虑本地部署而且优先从开源小模型加量化开始而不是直接追求超大参数模型。本地部署从来不是“省钱”的万能解它更像是一种对基础设施和工程能力的投资。如果你有明确的业务场景、稳定的调用量、愿意投入时间去维护它会成为长期回报率很高的选择。如果你的业务还停留在探索阶段API 的低门槛和零维护优势会帮你省下真正宝贵的注意力。说到底算这笔账的标准不该是“哪个单价便宜”而应该是“哪个方案能让你把精力花在产品和业务上”。硬件的账可以用计算器算清楚团队注意力和时间成本这笔账还得靠自己做判断。
