在自己的硬件上运行大语言模型

去年我花了4200美元搭建了一套本地推理设备，能以合理的速度跑动一个70B参数的模型。一位同事看了我的配置，问了个显而易见的问题：“为什么不直接用API？这些钱够买八年的API额度了吧。”他的算账没错，但他没看懂这笔账的真正逻辑。

过去，本地运行大语言模型是研究实验室的专利，需要机架式GPU集群。如今这一局面变化很快。消费级硬件、量化技术和优化过的推理引擎，让70B+的模型也走进了个人爱好者和小团队的视野。像Tinybox这样的设备则更进一步——专为离线运行120B参数模型而设计的专用硬件，无需依赖云端。

但“能跑”和“好用”是两回事。下面我们就聊聊，在本地运行大模型到底需要什么，什么时候值得这么做，什么时候还是直接付费用API更划算。

为什么还要在本地运行模型？

API模式——把数据发给云服务商，再拿回结果——对大多数场景来说完全够用。它更省事，低用量时单次成本更低，而且总能用上最新的模型。那为什么还有人折腾本地推理呢？

隐私与合规。有些数据不能离开内网。病历、法律文件、专有代码、金融数据——受监管行业通常对数据驻留有硬性要求。把患者记录发到API端点，即便是加密传输，也可能违反HIPAA。本地推理能把所有数据都留在自己的机房里。
延迟。API调用意味着网络往返、可能的排队等待以及速率限制。本地推理没有网络延迟，也不用排队。对于实时编程助手、端侧翻译、语音交互这类交互式应用，50毫秒和500毫秒之间的差距，就是“跟手”和“卡顿”的区别。
规模化后的成本。API按token计费。用量小的时候几乎可以忽略，用量大了，费用会狠狠地滚雪球。一个团队如果大量做代码审查、文档分析或批量处理，每个月的API账单轻松上千美元。本地硬件是一次性投入，买完之后，推理基本就是免费的。
可用性。云API会宕机，会被限流，价格可能说变就变，模型也会被弃用。如果你的产品依赖第三方API，那就只能听天由命，任由对方的商业决策摆布。本地推理意味着你的能力不会因为别人的服务器闹脾气而突然消失。
实验自由。API服务商有使用政策，决定你能用模型做什么、不能做什么。本地模型没有这些限制——你可以微调、修改，用于任何用途，想跑多少次就跑多少次。

硬件现实

LLM推理的根本瓶颈是内存，而不是算力。在做任何事情之前，模型参数都得先装进内存（GPU显存或系统内存）。一个70B参数的模型如果用16位浮点数存储，大约需要140 GB内存，这已经超过了任何一块消费级GPU的显存容量。

这时候量化就改变了游戏规则。把模型权重的精度从16位降到8位、4位，甚至2位，内存需求就能大幅下降：

Memory requirements for a 70B parameter model:
FP16 (full precision):  ~140 GB  → requires multiple A100s
INT8 (8-bit quant):     ~70 GB   → requires 2x RTX 4090 (48GB total)
Q4_K_M (4-bit quant):   ~40 GB   → fits on 2x RTX 3090 or 1x A6000
Q2_K (2-bit quant):     ~25 GB   → fits on 1x RTX 4090 (24GB)
For a 120B parameter model:
FP16:                   ~240 GB  → enterprise GPU territory
INT8:                   ~120 GB  → 5x RTX 4090 or purpose-built device
Q4_K_M:                 ~70 GB   → 3x RTX 4090
Q2_K:                   ~40 GB   → 2x RTX 4090

4位量化（llama.cpp生态中的Q4_K_M）目前是最佳平衡点。质量损失是可以测量的，但在实际使用中通常可以接受——在盲测中，大多数人分不清Q4和全精度的输出。2位量化对质量的影响比较明显，尤其是在推理密集型任务上，但用于文本分类、摘要这类相对简单的应用依然没问题。

消费级硬件方案

如果你打算自己搭建本地推理环境，大致有三条路线，各自的性价比差别很大。

单GPU路线

一块RTX 4090（24 GB显存，约1600美元）可以从容运行最高约30B参数的4位量化模型，或者用激进的2位量化跑70B模型。对于大多数7B–13B的模型来说，它确实有点大材小用——每秒能输出40多个token，比大多数人的阅读速度还快。这是最省心的路线：买块显卡，装上llama.cpp或Ollama，开跑就行。

多GPU路线

两块或更多GPU可以把一个模型拆分到多个设备上（张量并行）。两块RTX 3090（合计48 GB显存，二手约2200美元）就能舒服地跑4位量化的70B模型。问题在于：主板要有足够的PCIe通道，机箱里还得有放多块全尺寸显卡的物理空间。散热也是个实际问题——机箱里两块350W的显卡，发热量相当惊人。

统一内存路线

配备大容量统一内存的Apple Silicon Mac是一个出乎意料的可行选项。一台配备192 GB统一内存的M2 Ultra，可以把全精度的70B模型整个装进内存。推理速度比专用GPU慢，70B模型大概每秒10到15个token，但它的简单程度很难被超越：没有驱动问题，不用配置多GPU，也不需要操心散热。就是一台Mac Studio放在桌上，跑着70B模型。

M系列芯片通过统一内存架构实现这一点：CPU和GPU共享同一个内存池，不用在CPU内存和GPU显存之间来回拷贝数据，因此不存在这方面的瓶颈。它的内存带宽低于专用GPU方案，这也是推理速度较慢的原因。不过，一台功耗只有60瓦的设备，能拥有192 GB可寻址内存，确实相当令人印象深刻。

专用推理设备

最新的一类是专用的本地推理硬件——专门为高效运行大模型而设计的专用设备。它们的目标是解决多GPU的麻烦：不用再把消费级显卡拼凑起来、和一堆线缆较劲，而是直接获得一台从底层就为推理而设计的一体机。

吸引力显而易见。插上电，把应用指向它，模型就跑起来了。没有驱动冲突，不用管CUDA版本，也不会因为把三块显卡塞得太近而降频。代价是成本——专用设备每单位算力的价格通常高于同等的消费级GPU。你买的是系统集成、可靠性，以及不用自己去调试PCIe通道分配。

对于需要本地推理、但内部没有硬件工程师的小公司来说，这类设备很有道理。而对于喜欢动手折腾的爱好者，DIY多GPU方案依然更便宜，也更灵活。

软件栈

硬件只是故事的一半。推理软件栈发展非常快，选对软件，在同样的硬件上吞吐量可能直接翻倍。

llama.cpp——本地推理的瑞士军刀。用C/C++编写，从树莓派到多GPU服务器都能跑。支持数十种模型架构和量化格式。不一定是最快的，但胜在可移植性强，而且维护活跃。
vLLM——针对NVIDIA GPU的吞吐量优化方案。使用PagedAttention高效管理显存，大幅提升批量推理的效率。如果你要在一台机器上为多个用户提供服务，vLLM通常是最佳选择。
Ollama——“LLM界的Docker”。它在llama.cpp外面包了一层友好的界面，并带有模型仓库。运行ollama run llama3:70b，它就会自动下载模型、配置量化并开始提供服务。非常适合入门，但可配置性不如直接使用原生llama.cpp。
MLX——苹果推出的机器学习框架，专为Apple Silicon优化。如果你用的是M系列Mac，MLX通常比llama.cpp性能更好，因为它能更充分地利用统一内存架构。

# Getting started with Ollama (the easiest path)
# Install: https://ollama.ai
# Run a 7B model (downloads automatically, ~4GB)
$ ollama run mistral
# Run a 70B model (needs ~40GB RAM/VRAM)
$ ollama run llama3:70b-instruct-q4_K_M
# Serve as an API endpoint (OpenAI-compatible)
$ ollama serve
$ curl http://localhost:11434/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{
"model": "mistral",
"messages": [{"role": "user", "content": "Explain TCP handshakes"}]
}'

诚实的成本对比

我们来算一笔真正重要的账。假设你运行的是70B模型，每天处理大约100万个token（大致相当于分析50到100份文档，或者处理几百次聊天对话）。

Cloud API (approximate pricing for 70B-class model):
Input:  $0.50 per million tokens
Output: $1.50 per million tokens
Daily cost: ~$2.00
Monthly cost: ~$60
Yearly cost: ~$720
Local inference (2x RTX 4090 build):
Hardware: $4,200 (one-time)
Electricity: ~$30/month (assuming 700W, 8h/day, $0.15/kWh)
Break-even: ~5.5 years
Local inference (Mac Studio M2 Ultra 192GB):
Hardware: $5,800 (one-time)
Electricity: ~$3/month (60W)
Break-even: ~8 years

每天100万token的用量下，云API在相当长一段时间内都更便宜。但如果用量上去，这个结论会发生明显变化。每天1000万token时，API每年要花7200美元，而本地硬件大约7个月就能回本。每天5000万token时，本地推理几周就能收回成本。

成本对比还没有考虑非经济因素：隐私、延迟、可用性和实验自由度。如果其中任何一项是硬性要求（而不仅仅是锦上添花），那么财务对比就退居次要位置了。

量化会损失什么

量化是让大模型能在本地运行的关键，但它并非没有代价。降低精度意味着部分信息会丢失，而且这种损失在不同任务上并不均匀。

在我的测试中，4位量化模型在以下任务上的表现与全精度几乎一致：文本生成、摘要、简单问答、翻译，以及常见模式的代码生成。而质量下降主要体现在：复杂的多步推理、数学计算、需要精确回忆训练数据的任务，以及细致入微的指令遵循。

实际意义在于：如果你用本地模型做代码补全、文档摘要或对话式AI，4位量化完全够用。但如果你要做复杂的分析推理，或者细微的准确性差异很关键，就需要仔细测试，并可能为了更高精度而付出更多内存的代价，或者换用更小的模型。

如何做决定

我在本地跑了一年模型之后，总结出一套判断本地推理还是云端推理的框架：

适合用云API的情况：你需要绝对最顶尖的模型质量，用量低到中等，团队没有硬件方面的专业能力，需要频繁切换模型，或者延迟不是关键因素（几百毫秒完全可以接受）。

适合本地运行的情况：你的数据不能离开内网，需要稳定的100毫秒以内的延迟，token用量高到足以覆盖硬件成本，希望无成本负担地自由实验，或者需要不依赖第三方可用性的推理服务。

这个领域变化非常快。模型越来越小、越来越高效，量化技术持续进步，硬件也在变便宜。本地推理在经济上变得划算所需的用量门槛，每年都在下降。如果现在对你来说还不划算，那么十八个月后也许就划算了，而且在此期间，软件栈只会变得越来越好用。