# vLLM 的局限：Ollama 如何用黑科技实现越级部署？

场景下概述：

使用ragflow知识库来谈谈ollama的黑科技！

--部署30b，还是很流畅的，但是推理能力确实比较弱

-- 部署70b，通过不断地优化参数，最大tokens,4096 tokens没问题（还部署了一个bge-m3）

--但是在ragflow中使用的时候，由于超出最大tokens,经常报内存溢出，因此给ragflow的官方提交了一个issue。官方很快就修复了，这块还是很赞的

示例演示：

原始显存需求：

 权重（直接成本）：8B参数 × 2字节（FP16）= 16 G

•  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的“瘦身魔法

--4-bit GGUF量化：权重显存降至8B × 0.5字节 = 4 GB

--动态卸载策略：将部分权重临时转存至CPU内存，显存占用降至6.2 GB（实测数据）

--代价：CPU-GPU数据传输使Token生成速度从45 tokens/s降至28 tokens/s。

 vLLM的“显存洁癖"

•  设计原则：vllm追求极致吞吐量，拒绝任何可能影响性能的动态卸载

• 显存硬门槛：要求权重+KV Cache完全驻留GPU，导致DeepSeek-R1-8B在12GB显卡上无法启动

Ollama越级部署的三大核心技术 

混合精度量化（灵活度碾压vLLM）

 --层级敏感量化：对底层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）

自适应序列切片

显存优化效果：2048 tokens输入时，峰值显存降低32%

长文本处理：当输入超过512 tokens时，自动拆分为多段并行处理

开发者选型指南

选Ollama的场景

• • 个人开发者/小团队：硬件有限（≤24GB显存）

• • 需要快速验证模型效果，对延迟容忍度高

• • 长文本生成需求（利用切片策略降低峰值显存）

选vLLM的场景

• • 企业级API服务：需要支持高并发（≥100 QPS）

• • 拥有A100/H800等专业显卡，追求极致吞吐量

• • 需兼容现有Kubernetes集群调度系统

终极避坑建议

• • 警惕“虚假越级”：部分工具声称支持低显存运行，实则大幅裁剪模型参数（如DeepSeek-8B被阉割成6B）

• • 验证量化完整性：使用llm-int8工具检查Attention层是否真的保留高精度

• • 压测保平安：对Ollama需测试长时生成的显存泄漏问题（部分版本存在累积占用bug）

关键结论

Ollama的生存逻辑：通过量化+动态卸载，将显存需求压缩至硬件的60%以下

 vLLM的哲学缺陷：为追求工业级性能，放弃对资源受限场景的适配、