本地部署AI前，先想清楚需求再买GPU

1. 别急着下单显卡，先把这件事想明白

"我们要本地部署 AI，预算批了，先买几张卡？"——这是我最近半年被问得最多的一句话。每次听到，我都想先按住对方掏钱包的手。因为在我经手的项目里，真正让本地部署翻车的，从来不是算力不够，而是需求没想清楚就冲进去买硬件。GPU 是这条链路上最贵、最难反悔、折旧最快的一环，一旦买错，几十万砸下去，模型跑不动、业务接不上、运维扛不住，最后只能当昂贵的电暖器。

先把话说透：本地部署 AI 这件事，本质上是把"模型推理/微调"这套能力从云端搬回你自己的机房或办公室。它解决的是数据不出内网、调用成本可控、响应延迟稳定、以及某些场景下对模型行为有完全掌控权的问题。适合谁来参考？三类人：一是手里有敏感数据、合规上不允许外传的团队；二是调用量已经大到云端 API 账单肉疼、想算一笔长期账的公司；三是想拿开源模型做二次开发、做垂直领域微调的技术团队。如果你只是偶尔试试 AI 写文案，那本地部署纯属给自己找罪受，直接用现成服务更划算。

这篇东西我想按真实的落地顺序讲：先搞清楚你到底要跑什么、跑多大、跑多快，再决定要不要买卡、买什么卡、买几张。中间会穿插我踩过的坑、算过的账、以及那些文档里不会写的细节。核心关键词就三个：本地部署、AI、GPU，但你会发现，GPU 排在最后才该被认真讨论。

2. 第一步永远是需求拆解，不是硬件选型

2.1 先分清你是"推理"还是"训练/微调"

这两个词经常被混着说，但它们的硬件需求差了一个数量级。推理是把已经训练好的模型拿来用，输入问题、输出答案，对显存的要求主要取决于模型参数量和量化精度。训练/微调是要更新模型权重，除了模型本身，还要存梯度、优化器状态、激活值，显存占用通常是推理的好几倍。

举个具体的账：一个 7B 参数的模型，用 FP16 精度做推理，光权重就要占大约 14GB 显存（7B × 2 字节）。如果做全参数微调，加上梯度（14GB）、Adam 优化器状态（动量+方差，约 56GB），轻松突破 80GB，单卡根本放不下。而如果只是推理，一张 16GB 显存的消费级卡，配上 4-bit 量化，就能把 7B 模型跑得挺顺。

所以第一件事，拿张纸写清楚：你是要部署一个能对话/问答的服务，还是要拿自己的数据去训练/微调模型？前者对硬件友好得多，后者才是真正的吞金兽。我见过太多团队一上来就说"我们要微调"，结果聊下来发现，他们其实只需要把公司文档喂进去做检索问答（RAG），根本不用动模型权重。

2.2 模型规模决定显存下限，别拍脑袋

模型参数量和显存的关系，有个粗略但好用的估算公式：

推理显存 ≈ 参数量(B) × 精度字节数 × 1.2（预留 KV Cache 和框架开销）

按这个公式，不同精度下常见模型的显存需求大致如下：

这张表是我自己反复验证过的经验值，实际会因为上下文长度、批处理大小浮动。注意 KV Cache 这一项：上下文越长、并发越高，它涨得越凶。很多人算显存只算权重，结果一上生产、并发一上来就 OOM（显存溢出），就是漏了这块。

所以选模型规模时，别盯着"最强"的那个。70B 确实聪明，但如果你的业务只是做意图分类、信息抽取、客服问答，7B 到 13B 的模型配上好的提示词工程，效果完全够用，硬件成本却只有零头。我个人的建议是：先用小模型把流程跑通，验证业务价值，再考虑要不要上大模型。

2.3 并发量和延迟要求，才是真正决定卡数的因素

单机能跑起来，和能扛住业务量，是两码事。一个 7B 模型在单张卡上，单次请求可能只要几百毫秒，但如果同时来 50 个请求，要么排队、要么显存爆掉。这时候你要么加卡做并行，要么上推理框架做批处理调度。

这里有个常被忽略的点：吞吐量和延迟是一对矛盾。批处理（batching）能把多個请求打包一起算，提高 GPU 利用率、降低成本，但会增加单个请求的等待时间。如果你的场景是实时对话，延迟敏感，那批处理窗口就得开小；如果是离线批量处理文档，那就可以把批处理开大，用更少的卡干更多的活。

我一般会问客户三个问题来定并发：峰值 QPS 是多少？可接受的 P99 延迟是多少？请求是均匀分布还是突发？这三个答案出来，卡的数量基本就有谱了。先有并发模型，再有硬件配置，顺序不能反。

3. 硬件选型：GPU 只是其中一环

3.1 显存容量比算力更值得优先看

新手选卡最容易犯的错，是盯着 TFLOPS（浮点算力）比大小，忽略了显存。对本地部署 AI 来说，显存容量是硬门槛，算力是软指标。显存不够，模型直接加载不进去，算力再高也是废铁；显存够了，算力差一点，无非是慢一些，但至少能跑。

所以选卡的第一原则：先满足显存下限，再在预算内挑算力。消费级的 4090 有 24GB 显存，专业级的 A100 有 40GB/80GB 版本，H100 有 80GB。如果预算有限又要大显存，多张消费级卡拼起来也是一种思路，但要考虑卡间通信（NVLink 或 PCIe）带来的效率损耗。

3.2 消费级卡、专业卡、国产卡怎么选

这三类卡我都有实际接触，各有各的适用场景：

• 消费级卡（如 4090、3090）：性价比高，24GB 显存能覆盖大部分 7B-13B 场景，适合中小团队起步、做原型验证。缺点是散热和供电要自己搞定，长时间高负载稳定性不如专业卡，而且部分型号有驱动和虚拟化限制。
• 专业卡（如 A100、H100、L40S）：显存大、稳定性好、支持多卡高速互联，适合生产环境和大模型。缺点是贵，一张卡顶一套房的首付，而且采购周期长。
• 国产加速卡：在特定合规场景下有优势，生态和工具链这两年进步很快，但迁移适配成本要提前评估，不是所有框架和模型都开箱即用。

我的经验是：原型阶段用消费级卡快速验证，生产阶段再根据实际负载上专业卡。别一上来就 all in 专业卡，万一需求变了，沉没成本太高。

3.3 别忽略 CPU、内存、存储和网络

GPU 是主角，但配角掉链子照样演不下去。我列几个容易被忽视的点：

• 系统内存：模型加载时要先从磁盘读进内存再进显存，内存不够会频繁 swap，慢到怀疑人生。经验值是显存的 1.5 到 2 倍。
• 存储：模型文件动辄几十 GB，用机械盘加载一个 70B 模型能等十几分钟。NVMe SSD 是标配，读写速度直接影响冷启动时间。
• CPU：数据预处理、tokenization、请求调度都靠 CPU，核数太少会成为瓶颈，尤其在多并发场景下。
• 网络：多机多卡部署时，网络带宽和延迟直接决定扩展效率，万兆起步，能上 InfiniBand 更好。

这些加起来，一套像样的本地部署环境，GPU 往往只占总成本的一半左右。做预算时千万别只算卡钱。

4. 软件栈：让硬件真正跑起来的那些事

4.1 推理框架怎么挑

硬件到位后，得有个框架把模型跑起来。目前主流的几类：

• Ollama：上手最快，一条命令拉模型、跑推理，适合个人和小团队快速验证。缺点是生产级的并发调度和监控能力偏弱。
• vLLM：主打高吞吐，PagedAttention 技术对显存利用很高效，适合生产环境的批量推理。配置稍复杂，但值得。
• TensorRT-LLM：NVIDIA 官方出品，针对自家卡优化到极致，性能最好，但编译和适配成本高，模型支持有门槛。
• Transformers + 自建服务：最灵活，什么模型都能跑，但性能和并发要自己调优，适合有工程能力的团队。

选哪个，取决于你的团队能力和业务阶段。验证阶段用 Ollama，生产阶段用 vLLM，这是我比较推荐的路径。

4.2 量化：用精度换显存的关键手段

量化是把模型权重从高精度（如 FP16）压到低精度（如 INT8、INT4），显存占用能降一半甚至更多，代价是精度略有损失。常见的量化方案有 GPTQ、AWQ、GGUF 等。

实操中我的建议是：优先试 4-bit 量化，如果效果掉得厉害再退回 8-bit。大部分业务场景下，4-bit 量化的效果损失在可接受范围内，但显存省下来的钱是实打实的。不过要注意，量化不是万能的，某些对数值精度敏感的任务（如复杂数学推理）可能会明显退化，得实测。

4.3 容器化与环境隔离

本地部署最烦的就是环境依赖冲突。今天装个框架把 CUDA 版本搞乱了，明天另一个服务又跑不起来。用 Docker 把每个服务隔离，是我强烈建议的做法。镜像里锁定好 CUDA、驱动、框架版本，换机器也能一键复现。

驱动版本这块要特别小心：CUDA 版本、显卡驱动、框架版本三者必须匹配，否则就是各种莫名其妙的报错。我一般会在项目文档里明确记录这套版本组合，避免后人踩坑。

5. 实操落地：从零到跑通的一条完整路径

5.1 环境准备与依赖安装

假设你已经有一台带 GPU 的机器，从裸机到跑通推理，大致这么走：

# 1. 确认显卡和驱动 nvidia-smi # 2. 安装 CUDA Toolkit（版本要和驱动、框架匹配） # 以 CUDA 12.1 为例，按官方文档配置源后安装 # 3. 用 Docker 拉起推理环境（以 vLLM 为例） docker run --gpus all -p 8000:8000 \ -v /models:/models \ vllm/vllm-openai:latest \ --model /models/your-model --quantization awq

这里--gpus all是把 GPU 透传给容器，-v是把模型目录挂载进去。跑起来后，服务会暴露一个兼容 OpenAI 接口的端点，业务代码几乎不用改就能接。

5.2 模型加载与显存监控

模型加载时，用nvidia-smi -l 1实时盯着显存变化。如果加载到一半就 OOM，说明显存估算错了，要么换更小的量化版本，要么减上下文长度。加载成功后，记录下稳定态的显存占用，这是后续扩容的依据。

我习惯在服务启动后跑一轮压测，用工具模拟不同并发，观察显存、GPU 利用率、延迟的变化曲线。这条曲线比任何理论计算都靠谱，它能告诉你这套配置的真实上限在哪。

5.3 接口封装与业务对接

推理服务跑通后，通常还要包一层业务接口：加鉴权、加限流、加日志、做请求预处理和后处理。这层用 FastAPI 之类的框架写就行，重点是别把业务逻辑和推理逻辑耦合在一起，方便后续换模型、换框架。

对接时有个细节：流式输出（streaming）。对话类应用如果等模型全部生成完再返回，用户会觉得卡顿。用流式接口边生成边返回，体验好很多，vLLM 和 Ollama 都支持。

6. 常见问题与排查实录

6.1 显存溢出（OOM）怎么办

这是最高频的问题。排查顺序：先看是不是上下文太长，缩短 max_tokens 试试；再看并发是不是太高，降低批处理大小；还不行就换更低精度的量化版本；最后才考虑加卡。别一 OOM 就想着买卡，很多时候调参就能解决。

6.2 推理速度慢的排查思路

速度慢可能出在好几个环节：GPU 利用率低（可能是批处理没开好）、CPU 瓶颈（数据预处理拖后腿）、显存带宽不足（模型太大）、或者磁盘 IO 慢（模型没加载进显存）。用 profiling 工具定位到具体环节，再针对性优化。

6.3 模型效果不达预期

本地部署的开源模型，效果往往不如宣传的那么好。这时候先别怀疑硬件，检查提示词、检查量化精度、检查是不是用了不匹配的对话模板。很多"效果差"其实是工程问题，不是模型问题。

6.4 几个我踩过的坑

第一，别用最新版驱动。新驱动不一定兼容你的框架，稳定版才是王道。第二，模型文件校验别偷懒，下载中断导致文件损坏，加载时报的错千奇百怪，浪费半天。第三，多卡不等于线性加速，卡间通信开销可能让两张卡的效率还不如一张半，扩展前先测。

7. 成本这笔账，得算长期

买卡是一次性投入，但电费、运维、折旧是持续的。一张 4090 满载功耗 450W 左右，加上整机，一天 24 小时跑下来电费不便宜。专业卡虽然贵，但能效比往往更好。做决策时，把三年总拥有成本（TCO）算出来，再和云端 API 的账单对比，答案往往比拍脑袋清晰得多。

我个人的体会是：本地部署不是省钱的手段，而是掌控力的投资。如果你的核心诉求是数据可控、响应稳定、深度定制，那这笔投入值；如果只是图便宜，大概率会失望。想清楚这一点，再决定要不要迈出第一步，比什么都重要。