硬件选型
硬件选型不是从“买哪张 GPU”开始，而是从任务目标反推资源需求。
同一张卡，在本地实验、SFT 微调、在线推理、RAG 服务、多模态推理和多机训练里的价值完全不同。选型时最容易犯的错误，是只看单卡算力或显存容量，却没有把上下文长度、并发、KV Cache、互联、CPU、内存、存储、网络和运维成本一起算进去。
可以先用一句话概括：
硬件选型 = 模型规模 + 精度 + 上下文长度 + 并发目标 + 延迟目标 + 成本约束 + 运维条件
1. 先明确任务类型
不同任务对硬件的压力来源不同。
| 任务 | 核心压力 | 主要关注 |
|---|---|---|
| 本地实验 | 能不能跑起来 | 显存容量、生态兼容、成本、噪音和功耗 |
| 单卡微调 | 权重、优化器、激活值 | 显存容量、BF16/FP16 支持、内存和存储 |
| 多卡训练 | 计算和通信 | GPU 互联、网络、存储吞吐、分布式框架支持 |
| 在线推理 | 延迟、吞吐和稳定性 | 显存容量、显存带宽、KV Cache、调度和监控 |
| RAG 服务 | 检索链路和模型服务叠加 | CPU、内存、向量库、重排模型、LLM 推理资源 |
| 多模态模型 | 编码器和预处理开销 | 显存、图像/视频处理、CPU、存储和带宽 |
| 边缘部署 | 功耗和体积 | 低功耗加速卡、量化、离线运行和散热 |
所以选型前要先回答：
- 是训练、微调、推理，还是本地实验？
- 模型参数量是多少，使用什么精度？
- 最大上下文长度是多少？
- 目标并发和 QPS 是多少？
- 是否要求流式输出、低首 token 延迟或固定 SLA？
- 是否有 RAG、多模态、工具调用、长文档解析等额外链路？
- 是短期验证、内部工具，还是长期生产服务？
这些问题比 GPU 型号本身更重要。
2. 先估算显存
显存决定模型能不能放下，也决定能支持多少上下文和并发。
推理场景可以先用这个粗略公式：
总显存 ≈ 权重显存 + KV Cache 显存 + 运行时开销 + 冗余空间
权重显存由模型参数量和精度决定：
| 精度 | 每参数字节数 | 7B 权重估算 | 14B 权重估算 | 32B 权重估算 |
|---|---|---|---|---|
| FP16 / BF16 | 2 bytes | 约 14 GB | 约 28 GB | 约 64 GB |
| INT8 / FP8 | 1 byte | 约 7 GB | 约 14 GB | 约 32 GB |
| INT4 / 4bit | 0.5 byte | 约 3.5 GB | 约 7 GB | 约 16 GB |
这只是权重，不包含 KV Cache 和框架开销。在线推理时，KV Cache 往往会随着并发和上下文长度快速增长。
常见判断：
- 如果只是本地跑通模型，可以接受低并发、短上下文和量化。
- 如果是生产推理，不能只按权重大小选卡，要把 KV Cache 和冗余空间算进去。
- 如果是长上下文服务，显存压力可能主要来自 KV Cache，而不是权重。
- 如果希望同一张卡上放多个模型副本，还要把每个副本的权重和运行时开销一起算。
建议先阅读：
3. 显存容量和显存带宽要一起看
显存容量解决“放不放得下”，显存带宽影响“跑得快不快”。
LLM 推理中，每生成一个 token 都会大量读取模型权重和 KV Cache。很多场景并不是理论算力打满，而是访存和调度成为瓶颈。
选 GPU 时不要只看：
- FP16 / BF16 / FP8 峰值算力。
- CUDA Core 数量。
- 单卡价格。
还要看：
- 显存容量，例如 24GB、48GB、80GB、141GB。
- 显存带宽，例如 GDDR 与 HBM 的差异。
- 支持的推理精度和 kernel。
- 当前推理框架是否对该卡优化充分。
- 多卡时 GPU 间通信能力。
粗略理解：
| 场景 | 容量更关键 | 带宽更关键 |
|---|---|---|
| 大模型刚好放不下 | 是 | 否 |
| 长上下文高并发 | 是 | 是 |
| 小 batch 低并发推理 | 一般 | 是 |
| 多模型共卡 | 是 | 一般 |
| 高吞吐批量推理 | 是 | 是 |
如果预算有限，先保证显存容量满足目标模型和并发，再比较显存带宽、生态和能效。
4. 本地实验硬件
本地实验的目标通常是学习、验证模型效果、跑 demo、做少量 LoRA 或小规模数据处理。
此时不需要按生产服务标准采购，但要避免买到“参数好看、实际不好用”的配置。
优先级通常是：
- 显存容量。
- CUDA / 驱动 / 框架兼容。
- 系统内存和 NVMe 存储。
- 功耗、噪音和散热。
- 价格和二手风险。
常见选择思路：
| 目标 | 建议 |
|---|---|
| 跑 7B 量化模型 | 8GB 到 16GB 显存可尝试，体验取决于量化和上下文长度 |
| 跑 7B FP16 或更舒服的量化推理 | 16GB 到 24GB 显存更稳妥 |
| 跑 14B 量化模型 | 16GB 到 24GB 显存常见 |
| 跑 32B 量化模型 | 24GB 显存可尝试，但上下文和速度会受限 |
| 做轻量 LoRA 微调 | 24GB 显存更常见，具体取决于模型、batch 和训练方法 |
本地实验可以接受量化、CPU offload、较低 token/s 和较短上下文。不要把本地能跑通误认为生产环境也能稳定服务。
本地机器还要关注：
- 系统内存至少要能容纳模型文件、加载开销和数据处理任务。
- NVMe SSD 比机械硬盘或普通 SATA SSD 更适合频繁加载模型。
- 消费级 GPU 的散热、供电、长时间满载稳定性要单独评估。
- Windows、WSL、Linux 原生环境的驱动和框架体验不同，生产通常更偏 Linux。
5. 单卡微调硬件
单卡微调常见于 LoRA、QLoRA、SFT 小数据集实验和领域适配验证。
训练显存比推理复杂，因为除了模型权重，还要考虑：
- 梯度。
- 优化器状态。
- 激活值。
- batch size。
- 序列长度。
- 是否使用 gradient checkpointing。
- 是否冻结大部分参数。
- 是否使用 LoRA / QLoRA。
粗略判断：
| 微调方式 | 显存压力 | 说明 |
|---|---|---|
| 全量微调 | 很高 | 需要保存梯度和优化器状态，单卡通常只适合较小模型 |
| LoRA | 中等 | 只训练少量 adapter 参数，适合单卡实验 |
| QLoRA | 较低 | 量化基座模型，进一步降低显存压力 |
| 只做 embedding / 分类头 | 较低 | 取决于任务和模型结构 |
单卡微调选型建议：
- 显存越大越好，24GB 是很多个人和工作站实验的常见起点。
- 优先选择 BF16 / FP16 生态成熟的 GPU。
- 系统内存不要太小，数据集预处理、加载和 checkpoint 保存都会占用内存。
- 存储要留足 checkpoint、日志和数据集空间。
- 如果训练时间长，要关注散热和供电稳定性。
如果目标是严肃训练或频繁迭代，不要只按“刚好能启动”选卡。训练过程中 batch、上下文、数据格式和 checkpoint 策略稍有变化，就可能触发 OOM。
6. 多卡训练硬件
多卡训练不只是把 GPU 数量加起来。
训练时会频繁发生梯度同步、参数同步、激活值传输或专家路由通信。互联越差，多卡扩展效率越低。
需要关注：
- 单机内 GPU 间是 PCIe、NVLink 还是 NVSwitch。
- 多机网络是普通 Ethernet、RoCE 还是 InfiniBand。
- NCCL、分布式训练框架和调度系统是否成熟。
- 存储能否支撑多节点同时读取数据。
- CPU、内存和 PCIe 拓扑是否会拖慢数据管线。
- 机房供电、散热和故障替换能力。
多卡训练常见瓶颈：
| 瓶颈 | 表现 |
|---|---|
| GPU 互联弱 | 卡数增加后吞吐不线性增长 |
| 网络带宽不足 | 多机训练 step time 高，通信等待明显 |
| 存储吞吐不足 | GPU 等数据，利用率周期性下降 |
| CPU 数据预处理慢 | dataloader 成为瓶颈 |
| 拓扑不均衡 | 某些卡或节点长期拖后腿 |
如果只是小规模微调，单机多卡 PCIe 服务器可能够用。如果是大模型预训练、跨节点 tensor parallel、MoE 训练或高频参数同步任务，就要认真评估 NVLink/NVSwitch、RDMA 网络和集群拓扑。
对应阅读：
7. 在线推理硬件
在线推理的目标不是“模型能启动”，而是稳定满足延迟、吞吐和成本要求。
需要先定义服务目标：
- 首 token 延迟希望控制在多少？
- 平均输出 token/s 要多少？
- 峰值 QPS 是多少？
- 单请求最大上下文是多少？
- 是否允许排队？
- 是否需要流式输出？
- 是否有多租户或多模型共用 GPU？
- 是否有 SLA 和故障切换要求？
在线推理选型的核心变量：
模型大小 + 精度 + 上下文长度 + 并发 + batch 策略 + 推理框架
推理 GPU 选择时重点看：
- 显存容量是否能容纳权重和 KV Cache。
- 显存带宽是否足够支撑目标 token/s。
- 推理框架对该 GPU 的支持是否成熟。
- 是否支持目标量化格式。
- 多卡并行时互联是否够用。
- 单卡功耗、机房密度和单位 token 成本。
生产推理常见策略：
| 策略 | 作用 | 代价 |
|---|---|---|
| 量化 | 降低权重显存，可能提升吞吐 | 可能影响质量，依赖 kernel 支持 |
| 限制上下文 | 降低 KV Cache | 影响长文档能力 |
| 动态 batching | 提升吞吐 | 可能增加排队延迟 |
| 多副本部署 | 提升并发和可用性 | 增加显存和机器成本 |
| 张量并行 | 支持更大模型 | 增加通信开销 |
| KV Cache 优化 | 支撑长上下文和高并发 | 依赖框架能力 |
如果业务是低并发内部工具，可以用更便宜的卡、更激进的量化和更宽松的延迟。
如果业务是面向用户的在线服务，要以压测结果为准，不要只按理论显存估算上线。
8. RAG 服务硬件
RAG 不只是 LLM 推理。完整链路通常包括：
请求解析 -> query 改写 -> embedding -> 向量检索 -> rerank -> prompt 拼接 -> LLM 生成 -> 引用和后处理
因此硬件选型要把这些组件一起算。
RAG 常见资源需求：
| 组件 | 主要资源 |
|---|---|
| embedding 模型 | GPU 或 CPU，取决于吞吐和模型大小 |
| 向量数据库 | CPU、内存、磁盘 IO、网络 |
| rerank 模型 | GPU 或 CPU，常影响整体延迟 |
| LLM 推理 | GPU 显存、带宽、KV Cache |
| 文档解析 | CPU、内存、存储 |
| 缓存和队列 | 内存、网络、服务稳定性 |
RAG 硬件选型建议：
- 不要把全部预算都给 LLM GPU，检索和重排也会成为瓶颈。
- 向量库规模大时，内存和 SSD 性能很关键。
- rerank 模型如果放在同一张 GPU 上，要评估它和 LLM 是否互相抢显存。
- 文档解析、OCR、表格抽取、多路召回会显著增加 CPU 压力。
- 高并发 RAG 服务要关注端到端延迟，而不是只看 LLM token/s。
如果 RAG 链路复杂，建议把 LLM、embedding、rerank、向量库和业务 API 分开压测，找出真实瓶颈后再采购或扩容。
9. 多模态模型硬件需求
多模态模型通常比纯文本模型多出图像、音频或视频处理链路。
额外开销包括：
- 图像解码和 resize。
- vision encoder 前向计算。
- 视频抽帧和编码。
- OCR 或版面分析。
- 多模态 token 增加导致的上下文压力。
- 图片、视频和中间结果的存储与传输。
多模态选型关注：
| 场景 | 关注点 |
|---|---|
| 图片问答 | 显存、vision encoder、图像预处理 CPU |
| OCR + LLM | CPU、内存、OCR 模型、LLM 上下文 |
| 视频理解 | 存储、解码、抽帧、GPU 吞吐 |
| 多图输入 | 显存和上下文 token 数 |
| 实时视觉 | 延迟、编码/解码、边缘设备功耗 |
多模态服务不要只按语言模型参数量估算。图片和视频会增加前处理延迟，也可能让输入 token 数显著变长，从而放大 KV Cache 压力。
10. 云 GPU 与自建 GPU
云 GPU 和自建 GPU 没有绝对优劣，取决于使用频率、运维能力和业务阶段。
| 维度 | 云 GPU | 自建 GPU |
|---|---|---|
| 初始成本 | 低，按需租用 | 高，需要采购机器和配套设施 |
| 弹性 | 强，适合短期峰值 | 弹性弱，扩容周期长 |
| 运维 | 云厂商承担一部分 | 需要自己处理驱动、散热、故障 |
| 长期成本 | 长期满载可能较贵 | 高利用率下单位成本可能更低 |
| 可用型号 | 受区域和库存影响 | 取决于采购渠道 |
| 数据合规 | 需要评估云上数据风险 | 更容易做内网和物理隔离 |
| 调试自由度 | 受云环境限制 | 控制权更强 |
适合云 GPU 的情况：
- 短期实验、PoC、临时训练。
- 负载有明显峰谷。
- 团队缺少机房和硬件运维能力。
- 需要快速尝试不同 GPU 型号。
适合自建 GPU 的情况：
- 长期稳定高利用率。
- 对数据隔离、网络、安全有强要求。
- 已有机房、运维和监控能力。
- 需要固定拓扑或深度调优。
一个实用判断是：如果 GPU 长期接近满载，自建可能更值得算账；如果负载不稳定或还在探索阶段，云 GPU 更灵活。
11. 成本不能只看 GPU 单价
硬件成本至少包括：
- GPU 或整机采购成本。
- CPU、内存、NVMe、网卡和交换机。
- 机柜、电力、散热和机房空间。
- 云上实例、存储、带宽和跨区流量。
- 运维人力、故障替换和备件。
- 模型压测、迁移和适配成本。
- 闲置资源成本。
推理场景更应该看单位产出成本，例如：
单位成本 = 每小时成本 / 每小时可稳定输出 token 数
或者按业务口径：
单请求成本 = 机器成本 + 存储成本 + 网络成本 + 周边服务成本
便宜 GPU 如果吞吐低、故障多、框架支持差，单位 token 成本可能并不低。昂贵 GPU 如果利用率不足，也会浪费。
12. 选型决策流程
可以按这个顺序做：
- 明确任务：训练、微调、推理、RAG、多模态还是本地实验。
- 确定模型：参数量、结构、精度、量化方式和推理框架。
- 估算显存：权重、KV Cache、运行时开销和冗余空间。
- 定义服务指标：上下文长度、并发、QPS、延迟和可用性。
- 选择候选 GPU：看容量、带宽、精度、生态和价格。
- 检查主机资源：CPU、内存、NVMe、PCIe、NUMA 和网卡。
- 检查多卡/多机：NVLink、NVSwitch、RoCE、InfiniBand 和拓扑。
- 做小规模压测：用真实 prompt、真实上下文和真实并发。
- 计算单位成本：按 token、请求或业务任务计算。
- 预留扩展空间：为模型升级、上下文变长和流量增长留余量。
不要跳过压测。硬件规格只能给出上限，真实性能取决于模型、框架、batch 策略、量化、prompt 长度分布和业务链路。
13. 场景化建议
| 场景 | 优先配置 | 避免的问题 |
|---|---|---|
| 个人学习 | 中等显存 GPU、足够内存、NVMe | 为了追求大模型买到不兼容或功耗过高的卡 |
| 内部 demo | 云 GPU 或单机 GPU | 过早自建复杂集群 |
| LoRA 微调 | 24GB 以上显存更舒适 | 只看模型权重，不看训练激活和 batch |
| 小规模在线推理 | 显存足够、推理框架成熟、监控完善 | 用本地实验配置直接上线 |
| 长上下文服务 | 大显存、KV Cache 优化、压测 | 只按权重大小估算显存 |
| 高并发服务 | 多副本、动态 batching、带宽和调度 | 只堆单卡算力，不看排队延迟 |
| 大模型多卡推理 | 高速互联、成熟并行框架 | PCIe 多卡上盲目追求线性扩展 |
| 多机训练 | NVLink/NVSwitch、RDMA 网络、高吞吐存储 | 忽略网络和存储导致 GPU 等待 |
| RAG 生产服务 | LLM、向量库、rerank、CPU/内存一起规划 | 只给 LLM 配 GPU，检索链路拖慢整体 |
| 多模态服务 | 显存、预处理、存储和编解码能力 | 只按文本模型估算资源 |
14. 选型检查清单
采购或申请资源前，可以逐项检查：
- 模型参数量、精度和量化方式是否确定？
- 最大上下文长度和平均上下文长度是否分开估算？
- 并发、QPS、首 token 延迟和输出 token/s 是否有目标？
- 是否估算了 KV Cache，而不是只看权重大小？
- 推理框架是否支持目标 GPU、精度和量化格式？
- CPU 是否足够处理 tokenizer、API、RAG 和后处理？
- 系统内存是否足够支撑模型加载、缓存和服务进程？
- NVMe 是否能支撑模型加载、checkpoint 和数据集读写？
- 多卡时 GPU 拓扑是否适合 tensor parallel 或训练通信？
- 多机时网络是否支持目标训练或推理吞吐？
- 供电、散热、机柜空间和噪音是否可接受？
- 是否有监控 GPU、显存、温度、功耗、Xid、CPU、内存和磁盘？
- 是否计算了云上带宽、存储、跨区流量和闲置成本？
- 是否用真实流量样本做过压测？
- 是否预留了模型升级和流量增长空间？
15. 总结
硬件选型的关键不是找到“最强 GPU”，而是找到和任务匹配的系统方案。
可以按这条主线判断：
任务目标
-> 模型规模和精度
-> 权重显存
-> 上下文和并发
-> KV Cache
-> GPU 容量、带宽和互联
-> CPU、内存、存储和网络
-> 压测结果
-> 单位成本和运维能力
如果只是实验，能跑、便宜、兼容就很重要。
如果是生产服务，稳定性、可观测性、压测结果和单位成本更重要。
如果是训练或大规模推理，互联、网络、存储和调度能力会和 GPU 本身一样关键。