最近在一台配备双4090 GPU、近200GB内存的服务器上，使用vLLM部署70B大模型并搭配RAGFlow知识库进行实验，过程中遇到了不少坑。说实话，这次大模型部署实践远比想象中曲折。
基于此前使用Ollama的经验，本以为部署70B模型应该问题不大，结果一个接一个的难题接连出现。先分享阶段性结论：
- 部署30B模型时整体运行较为流畅，但推理表现相对较弱
- 部署70B模型时，通过不断优化参数，最大tokens可达4096（还额外部署了一个bge-m3）
- 但在RAGFlow实际应用场景中，常因超出最大tokens而触发OOM报错。后来向RAGFlow官方提交了issue，团队响应非常迅速，这点值得点赞
随着调试深入，疑问也越来越多。于是顺着这些问题系统梳理了底层知识，便有了本文。我们以RTX 3060 12GB显存为例，拆解大模型显存优化的核心门道。
DeepSeek-R1-8B的显存原理剖析
原始显存需求
先算一笔显存账：
- 权重（直接成本）：8B参数 × 2字节（FP16）= 16 GB
- KV Cache（上下文缓存）：
- 动态增长，计算公式为
2 × 层数 × 头数 × 头维度 × 序列长度 × 批次大小 × 精度 - 以2048 tokens为例：
2（K/V） × 32层 × 32头 × 128头维度 × 2048序列长度 × 2字节 = 1.07 GB - 总需求：16 + 1.07 ≈ 17.07 GB，远超RTX 3060的12GB显存上限
Ollama的“显存瘦身”技巧
那么Ollama是如何让这块12GB显卡顺利运行大模型的？
- 4-bit GPTQ量化：权重显存直接从16GB降至4GB（8B × 0.5字节）
- 动态卸载策略：将部分权重临时转存到CPU内存，实测显存占用降至6.2 GB
- 代价：CPU-GPU数据传输导致Token生成速度从45 tokens/s下降至28 tokens/s
更夸张的是，一位前同事直接用Ollama在MacBook Air 8GB内存上成功运行了70B模型——这听起来像玩笑，但确实发生了。
vLLM的“显存洁癖”设计
相比而言，vLLM走的是另一条技术路线：
- 设计原则：追求极致吞吐量，拒绝任何可能影响性能的动态卸载
- 显存硬门槛：要求权重和KV Cache完全驻留GPU，导致DeepSeek-R1-8B在12GB显卡上根本无法启动
Ollama越级部署的三大核心技术
混合精度量化（灵活度远超vLLM）
Ollama在量化方面做得相当精细：
- 层级敏感量化：对底层的
MLP层使用4-bit，而顶层的Attention保留6-bit，以减少精度损失 - 实测对比（DeepSeek-R1-8B生成任务）：
| 量化方案 | 显存占用 | PPL（困惑度） |
| Ollama混合精度 | 6.2 GB | 7.1 |
| vLLM官方INT8量化 | 10.5 GB | 6.9 |
内存-CPU分级存储（vLLM的禁区）
此策略的核心思路是“分轻重缓急”：
- 策略：将FP16的
Attention权重保留在显存，MLP权重动态加载至内存 - 技术代价：
- 每次前向传播增加5-8ms的PCIe传输延迟
- 但显存需求直降40%（从10.5GB→6.2GB）
自适应序列切片
- 长文本处理：当输入超过512 tokens时，自动拆分为多段并行处理
- 显存优化效果：2048 tokens输入时，峰值显存降低32%
vLLM为何“宁死不做越级部署”？
设计目标的根本冲突
这并非技术能力问题，而是设计哲学上的差异：
- vLLM的核心使命：服务化场景下的高吞吐、低延迟（例如同时服务数百个API请求）
- 拒绝动态卸载的原因：
- CPU-GPU数据传输会严重拖慢并发请求的处理速度
- 显存碎片化可能破坏连续内存分配机制（vLLM依赖的PagedAttention技术）
量化支持的局限性
- 仅支持静态INT8：无法像Ollama那样混合使用4/6-bit，导致显存压缩率不足
- 校准数据固化：vLLM要求离线量化，而Ollama支持运行时动态调整
硬件兼容性差异
- Ollama的“妥协艺术”：
- 为兼容消费级显卡（如RTX 3060），允许牺牲速度换取显存
- 甚至支持通过系统内存模拟显存（性能下降但能运行）
- vLLM的“精英主义”：
- 仅优化Tesla系列显卡（如A100/H100），依赖高带宽显存
- 在消费卡上性能反而不如Ollama（RTX 4090实测低15%吞吐量）
实战测试——RTX 3060上的生死对决
测试环境
- 显卡：NVIDIA RTX 3060 12GB
- 测试任务：DeepSeek-R1-8B生成512 tokens回答
结果对比
| 框架 | 显存占用 | 生成速度 | 可用性 |
| vLLM | 报错退出 | - | 完全不可用 |
| Ollama | 6.2/12 GB | 22 tokens/s | 流畅运行 |
| 原版Hugging Face | 17.1/12 GB | 报错退出 | 不可用 |
关键结论
- Ollama的生存逻辑：通过量化+动态卸载，将显存需求压缩至硬件容量的60%以下
- vLLM的哲学缺陷：为追求工业级性能，放弃了对资源受限场景的适配
开发者选型指南
选Ollama的场景
- 个人开发者/小团队：硬件有限（≤24GB显存）
- 需要快速验证模型效果，对延迟容忍度高
- 长文本生成需求（利用切片策略降低峰值显存）
选vLLM的场景
- 企业级API服务：需要支持高并发（≥100 QPS）
- 拥有A100/H800等专业显卡，追求极致吞吐量
- 需兼容现有Kubernetes集群调度系统
终极避坑建议
- 警惕“虚假越级”：部分工具声称支持低显存运行，实则大幅裁剪模型参数（如DeepSeek-8B被阉割成6B）
- 验证量化完整性：使用
llm-int8工具检查Attention层是否真的保留高精度 - 压测保平安：对Ollama需测试长时生成场景下的显存泄漏问题（部分版本存在累积占用bug）
结语：没有神话，只有取舍
Ollama的“越级”本质是技术民主化——让更多人能用上大模型，哪怕牺牲速度；vLLM的“高冷”则是商业现实的抉择。未来二者或许会走向融合（例如vLLM引入动态卸载），但在此之前，开发者仍需认清需求，选择最适合自己的工具。
相关术语
内存（RAM）与显存（VRAM）
- 系统内存（RAM）：由CPU直接管理的主内存，通常称为“内存”，物理上通过主板插槽连接，供所有系统进程共享。
- 显存（VRAM）：GPU专用内存，通过PCIe总线与CPU通信，专为高吞吐并行计算设计。
- 关键区别：
- CPU不直接拥有内存，而是通过内存控制器访问RAM；
- GPU显存是独立硬件，与CPU内存物理分离。
Ollama显存优化的本质：CPU-GPU异构内存交换
当Ollama声称“将部分权重转存至CPU内存”时，其技术本质是：
将GPU显存中暂时不用的权重数据，通过PCIe总线转移到系统内存（RAM），并在需要时动态加载回显存。
这一过程涉及以下核心技术：
（1）内存分级策略（Memory Tiering）
- 热数据：当前计算所需的权重（如正在执行的Attention层）保留在显存。
- 冷数据：后续步骤才需要的权重（如下一层的MLP参数）暂存至系统内存。
- 交换粒度：通常以层（Layer）为单位，例如将DeepSeek-R1-8B的32层分成多个组按需加载。
（2）预取与缓存（Prefetching & Caching）
- 预加载机制：在计算当前层时，异步将下一层权重从系统内存提前传输至显存。
- 缓存策略：对频繁使用的权重（如Embedding层）在显存中永久保留副本。
（3）硬件加速传输
- Pinned Memory：使用
torch.cuda.Stream配合锁页内存（Pinned Memory），减少CPU-GPU数据传输延迟。 - Direct Memory Access（DMA）：绕过CPU直接由GPU控制器管理传输，实测带宽可达PCIe 4.0 x16的32GB/s。