不得不感叹AI的发展真是太快了，各行各业都在被AI影响着！
前段时间我跟了一个央企的AI项目，他们的需求很简单就是要做一个AI应用平台，目的就是要AI办公提效。这个项目的驱动也很有意思，是由上及下的。我猜测，应该是公司大领导为了响应上面，急于做出一些“成绩”。至于这个“成绩”是否真正能产生效益先不管，至少表面工作要做到位！这是态度问题！
按理说，央企的项目，我是没机会参与的，但就因为他们着急落地，所以，我也有幸参与到了这个项目中。
项目细节不说，但有一个点提一下。就是项目初期，他们用的就是Ollama部署的大模型，测试期间没任何问题，但上线后随着并发量的增加，Ollama开始吃不消了，所以后来换成了vLLM。
今天这篇文章，跟大家聊聊大模型部署的两种主流方式Ollama和vLLM有啥差异，我们到底该如何选？
一、Ollama 与 vLLM 的综合对比
| 维度 | Ollama | vLLM |
|---|---|---|
| 核心定位 | 轻量化本地部署，简化开发测试 | 高性能生产级推理，支持高并发与分布式扩展 |
| 适用场景 | 个人开发、原型验证、实时交互（低并发） | API 服务、聊天机器人、企业级应用（高并发） |
| 吞吐量 | 7B模型：~45 tokens/s（单卡RTX 4090） | 7B模型：~240 tokens/s（同硬件） |
| 部署复杂度 | 简单命令启动 | 需配置多GPU、分布式调度（如张量并行） |
| 多机集群 | 不支持 | 支持 |
结论：
- Ollama 适合 50人以下团队或PoC（概念验证）阶段，快速启动且资源占用低；
- vLLM是200人以上企业生产环境首选，尤其在金融、客服等需高并发的场景。
二、核心技术对比
1. Ollama 的轻量化设计
-
优势：
内置模型仓库（直接拉取Llama/Mistral等主流模型）
自动硬件适配（CPU/GPU无缝切换）
-
局限：
无分布式扩展能力
批处理效率低（静态分组导致显存浪费）
2. vLLM 的高性能奥秘
-
PagedAttention：
将KV Cache划分为固定大小“页”，实现按需分配显存（类似OS内存管理）
显存利用率从传统框架的60%→95%+ -
Continuous Batching：
动态合并不同长度请求（一个batch内处理
[32, 128, 64]tokens）吞吐量较HuggingFace提升24倍（Anthropic实测）
三、性能实测数据（参考网络）
测试背景：Llama2-13B, A100 80GB
| 指标 | Ollama | vLLM | 提升幅度 |
|---|---|---|---|
| 吞吐量 | 78 tokens/s | 420 tokens/s | 438% |
| 首Token延迟 | 350ms | 210ms | 40% |
| 显存占用 | 38GB | 22GB | -42% |
| 最大并发 | 32请求 | 256请求 | 8倍 |
四、总结
-
选Ollama当：
☑️ 需要10分钟内启动模型
☑️ 资源受限（消费级GPU/边缘设备）
☑️ 低并发交互场景（如个人知识库） -
选vLLM当：
☑️ 企业级生产环境（≥200 QPS）
☑️ 千亿模型部署需求
☑️ 要求显存利用率>90%原文地址：https://mp.weixin.qq.com/s/R4tt67hDhZaYbEcdsOQ2qQ
