自己部署大模型 vs API：成本对比与选型指南

1. 先算一笔总账：自己部署大模型到底贵在哪

很多人第一次冒出“自己部署大模型”的念头，都是被 API 账单吓出来的。按量付费，用多少扣多少，看着单价不高，可一旦把大模型接进业务流，日调用量从几百次涨到几万次，月底账单能直接翻好几倍。于是很自然地会想：我买张显卡自己跑，是不是就一劳永逸、彻底省钱了？

这个想法不能说错，但只对了一半。自己部署确实能把“按次计费”变成“按硬件折旧计费”，可它同时把一堆原本由服务商承担的隐性成本，转移到了你自己头上。这笔账要算清楚，得把显性成本和隐性成本分开看，再把它们折算到同一个维度上——也就是每百万 token 的实际成本，否则根本没法比。

我先给一个粗略的结论，方便你带着预期往下看：当你的日均调用量稳定超过某个阈值、且对延迟和数据不出本地有硬性要求时，自己部署才可能更便宜；低于这个阈值，API 几乎总是更划算。这个阈值不是固定的，它取决于你选的模型规模、量化方式、硬件采购价、电费、以及你对自己时间成本的估值。下面我把每一项都拆开算。

1.1 显性成本：硬件、电费、折旧

自己部署最直观的支出就是硬件。以目前个人和小团队最现实的方案为例，一张消费级显卡（比如 16GB 显存档位）加上配套的主机，整机落地大概在八千到一万五之间。如果跑的是 7B 到 14B 级别的模型，配合 4-bit 量化，16GB 显存基本能塞下，推理速度也能接受。

但硬件不是一次性投入就完事。显卡有折旧，通常按三年摊；电源、主板、散热这些也有寿命。更要命的是电费——一张满载功耗 200W 左右的显卡，加上 CPU 和整机其他部件，满载整机功耗轻松上 350W。按每天跑 8 小时、电价 0.6 元一度算，一天电费大约 1.7 元，一年就是 600 多块。如果 24 小时不间断跑，一年电费直接奔着 1800 元去。

把这些摊到 token 上，就需要知道你的实际吞吐。一张 16GB 显卡跑 7B 量化模型，用合适的推理引擎，输出速度大概在每秒 30 到 60 个 token 之间。假设平均每秒 40 token，每天跑 8 小时，一天能产出约 115 万个 token。三年硬件折旧按 12000 元算，每天折旧约 11 元，加上电费 1.7 元，一天总成本约 12.7 元，折算下来每百万 token 约 11 元。

这个数字看起来很美，但它是建立在“显卡每天都在满负荷跑”的前提上的。如果你一天只调用几千次、每次几百 token，那显卡大部分时间在闲置，折旧却一分不少，实际每百万 token 成本会飙升到几百甚至上千元，这时候 API 反而便宜得多。

1.2 隐性成本：时间、运维、机会成本

真正让“自己部署更便宜”这个结论翻车的，往往是隐性成本。第一块是时间成本。从选硬件、装驱动、配环境、下模型、调推理引擎，到后面处理各种报错、显存溢出、版本冲突，一个新手从头跑通，花掉两三个完整工作日是常态。这些时间如果折算成工资，可能已经够买好几个月的 API 额度了。

第二块是运维成本。自己部署意味着你要对可用性负责。显卡驱动会崩、推理服务会挂、磁盘会满、模型文件会损坏。API 服务商挂了你可以提工单，自己部署挂了只能自己半夜爬起来重启。这种持续的心力消耗，很难用钱量化，但它是真实存在的。

第三块是机会成本。你把时间花在折腾部署上，就没时间花在业务本身。对于个人开发者和小团队，这往往是最贵的一块。所以我在算这笔账时，习惯给自己的人工按小时计价，哪怕只是象征性地算，也能让决策更清醒。

1.3 一个可复用的成本对比框架

为了让你能直接套用，我整理了一个对比表。你只需要填入自己的实际数字，就能得出属于自己的结论。

看这张表你会发现，自己部署的优势集中在数据不出本地和长期满负荷下的单价，而 API 的优势集中在零启动成本和弹性。所以决策的关键就变成两个问题：你的数据能不能出本地？你的负载能不能长期跑满？

2. 什么情况下自己部署才真的省钱

上一节把成本拆开了，这一节我直接给判断标准。因为很多人算账算到一半就迷糊了，其实只需要盯住几个关键变量。

2.1 调用量阈值：日均多少 token 才值得自己跑

这是最核心的变量。我按前面算出的“自己部署约 11 元/百万 token”作为基准，再假设 API 价格是 20 元/百万 token（不同模型差异很大，这里取一个中间值）。那么自己部署要回本，你的日均 token 消耗必须达到一个门槛，让折旧和电费被摊薄。

粗略估算：如果一天只产出 10 万 token，那 12.7 元的日成本摊下来就是 127 元/百万 token，远贵于 API。如果一天产出 100 万 token，成本降到 12.7 元/百万 token，开始接近 API。如果一天产出 500 万 token，成本降到约 2.5 元/百万 token，这时候自己部署的优势就非常明显了。

所以一个经验性的门槛是：日均稳定消耗在 100 万 token 以上，自己部署才开始有经济性；达到 300 万到 500 万 token，优势才比较稳固。低于这个量，除非你有数据不出本地的硬需求，否则 API 更划算。

2.2 数据敏感度：什么时候钱不是第一考量

有些场景下，钱根本不是主要矛盾。比如你处理的是内部合同、客户隐私、医疗记录、未公开的研发资料，这些数据一旦出本地就是合规风险。这时候哪怕自己部署贵一点，也得自己跑。我见过不少团队，明明 API 更便宜，还是咬牙买了显卡，原因就是数据不能出门。

还有一种情况是离线环境。比如工厂车间、野外作业、内网隔离环境，根本没有稳定的外网，API 调不通，只能本地部署。这种场景下成本对比没有意义，能跑起来就是胜利。

2.3 延迟与稳定性：API 给不了的东西

API 的延迟受网络和服务商负载影响，高峰期可能抖动。自己部署的延迟相对可控，尤其是局域网内调用，首 token 延迟可以压得很低。对于实时交互类应用，比如语音助手、在线客服，这种延迟优势会直接影响体验。

另外，API 服务商可能限流、可能涨价、可能下线某个模型版本。自己部署虽然运维累，但版本和节奏完全自己掌控。这种“确定性”对某些业务来说，价值超过省下的那点钱。

3. 硬件与推理引擎怎么选才不踩坑

决定自己部署之后，第一个现实问题就是：买什么卡，用什么引擎。这两件事选错，后面全是坑。

3.1 显卡选型：显存比算力更重要

跑大模型，显存是第一约束，不是算力。模型权重、KV Cache、中间激活值都要占显存。一个 7B 模型用 FP16 存，光权重就 14GB；用 4-bit 量化，权重降到约 4GB，但 KV Cache 还会随上下文长度增长。所以 16GB 显存是跑 7B 到 14B 量化模型的舒适区，8GB 只能勉强跑 7B 且上下文不能太长。

消费级显卡里，显存 16GB 的型号是个人部署的甜点。再往上，24GB 显存能跑更大的模型或更长的上下文，但价格也上一个台阶。如果你预算有限，宁可选显存大、算力稍弱的卡，也不要选算力强但显存小的卡——显存不够直接跑不起来，算力弱只是慢一点。

注意：买卡前一定确认你的电源功率和机箱空间。高端卡往往又长又厚，功耗也高，老电源可能带不动。

3.2 推理引擎：别一上来就追新

推理引擎这几年更新很快，vLLM、SGLang、llama.cpp、Ollama 各有侧重。我的建议是：先求跑通，再求快。

如果你是新手，想最快看到效果，Ollama 是最省心的选择。它把模型下载、量化、服务化都封装好了，一条命令就能跑起来，适合验证和小规模使用。缺点是并发能力一般，高负载下不如专业引擎。

如果你要上生产、追求吞吐，vLLM 是当前比较主流的选择。它用 PagedAttention 管理 KV Cache，显存利用率高，并发吞吐好。但它对环境和显卡驱动有要求，配置起来比 Ollama 麻烦。

llama.cpp 则适合 CPU 或混合推理场景，量化支持非常全，在资源受限的环境下很能打。如果你用的是核显或者没有独显，llama.cpp 往往是唯一现实的选择。

3.3 量化：省显存的关键手段

量化是把模型权重从高精度（如 FP16）压到低精度（如 4-bit、8-bit）的过程。它直接决定你的模型能不能塞进显存。4-bit 量化通常能把显存占用降到 FP16 的四分之一左右，代价是精度略有损失，但对大多数对话和问答任务，损失几乎感知不到。

常见的量化格式有 GPTQ、AWQ、GGUF 等。GGUF 主要用于 llama.cpp 生态，GPTQ 和 AWQ 更多用于 GPU 推理。选量化版本时，优先选社区验证过的、和你推理引擎匹配的格式，别自己乱转，容易出问题。

4. 从零跑通本地部署的完整实操

这一节我按真实操作顺序走一遍，你可以直接照着做。我以 Linux 环境加一张 16GB 显卡为例，这是最典型的个人部署配置。

4.1 环境准备：驱动、CUDA、Python

第一步是显卡驱动。装驱动最稳的方式是用系统包管理器，别去官网下 runfile 手动装，容易和内核版本打架。装完之后用nvidia-smi确认能看到显卡和驱动版本。

第二步是 CUDA 工具链。注意，你不需要单独装完整 CUDA，很多推理引擎会自带运行时。但如果你要自己编译某些组件，就需要装对应版本的 CUDA Toolkit。版本匹配很关键，引擎要求 CUDA 12.x，你就别装 11.x。

第三步是 Python 环境。强烈建议用 conda 或 venv 隔离，别在系统 Python 里乱装。创建一个独立环境，Python 版本选 3.10 或 3.11，这两个版本兼容性最好。

conda create -n llm python=3.11 conda activate llm

4.2 用 Ollama 快速验证

环境好了之后，先用 Ollama 跑通，建立信心。安装 Ollama 后，直接拉一个量化模型：

ollama pull qwen2.5:7b ollama run qwen2.5:7b

如果能看到模型正常对话，说明驱动、显存、推理链路都通了。这一步的意义是排除硬件和驱动问题，把变量降到最少。很多人一上来就折腾 vLLM，结果报错一堆，分不清是驱动问题还是引擎问题，白白浪费时间。

4.3 用 vLLM 上生产

验证通过后，如果要做服务化，换 vLLM。先装：

pip install vllm

然后启动服务：

python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --dtype auto \ --max-model-len 8192 \ --gpu-memory-utilization 0.9

这里几个参数很关键。--dtype auto让引擎自动选精度；--max-model-len控制最大上下文，设太大显存会爆；--gpu-memory-utilization 0.9表示用 90% 显存，留一点给系统。启动后它会暴露一个兼容 OpenAI 接口的端点，你原来的 API 调用代码几乎不用改，把 base_url 换成本地地址就行。

4.4 压测与调优：找到你的真实吞吐

服务跑起来不代表能用。你得压测，知道在并发多少的情况下延迟还能接受。可以用简单的脚本发并发请求，观察首 token 延迟和每秒输出 token 数。

调优的方向主要是两个：一是调--max-num-seqs控制并发批大小，二是调--gpu-memory-utilization在显存和吞吐之间找平衡。显存利用率调高，能缓存更多 KV，吞吐上去，但留给系统的余量变小，容易 OOM。这个平衡点只能实测，没有万能参数。

提示：压测时盯着nvidia-smi的显存占用，一旦接近 100% 就要警惕，生产环境建议留 10% 余量。

5. 常见问题与排查速查

自己部署最耗人的就是排错。我把高频问题整理成表，遇到时直接对照。

除了表里的，还有几个我踩过的坑值得单独说。第一，别用系统自带的 Python，依赖冲突能让你怀疑人生。第二，模型文件下载要校验，下到一半损坏的模型会报各种莫名其妙的错。第三，日志一定要留，出问题时日志是唯一线索，别把输出重定向到 /dev/null。

还有一个容易被忽略的点：散热。消费级显卡长时间满载，机箱风道不好会降频，吞吐直接掉。我见过有人跑分正常，一上持续负载就慢，最后发现是机箱闷罐。花几十块加个机箱风扇，比调半天参数都管用。

6. 我的实际选择与一点经验

折腾了这么多轮，我现在的做法是混合：日常轻量调用走 API，省心；高频、敏感、需要定制的任务走本地。这样既不用为了偶尔的峰值去买昂贵硬件，又能在关键场景保住数据和成本优势。

如果你还在犹豫，我的建议是先别急着买卡。拿 API 跑一个月，统计真实调用量和 token 消耗，再套前面的框架算一遍。很多时候你会发现，自己部署省下的钱，还不够覆盖你折腾的时间。但如果你确实有数据不出本地的需求，或者调用量已经稳定在高位，那本地部署就是值得的，而且越早跑通越早受益。

最后分享一个小技巧：本地部署的模型，不一定要用最大的。7B 量化模型在大多数问答和摘要任务上已经够用，跑得快、显存省、成本低。盲目追大模型，只会让你的显卡和电费一起遭殃。先用小模型跑通业务，等真的不够用了再升级，这条路稳得多。