Ollama到底是什么？能跑多大模型？

Hello，大家好～

如果有同学在自己电脑上跑大模型，第一个接触到的工具基本都是 Ollama。但它到底是个什么来头？和经常被拿来对比的 vLLM 又差在哪？这篇文章把Ollama的限制、能跑多大模型、以及 ollama run 后台干了什么一次说清楚。

Ollama 追求「跑起来」的极致便捷，vLLM 追求「跑得快、扛得住」的生产级性能，两者定位完全不同。

一、Ollama 是什么

Ollama 是一个开源的本地大语言模型运行框架，由Ollama 公司于 2023 年推出，核心目标是大幅降低在个人电脑上运行 LLM 的门槛，常被称为「LLM 版的 Docker」。

它的主要特点：

• 极简易用：一行命令即可运行，例如 ollama run llama3，自动下载并启动，无需手动配置 CUDA 环境。

• 跨平台友好：支持 macOS、Windows 和 Linux，并特别优化了 Apple Silicon（M 系列芯片）的 Metal 加速。

• 硬件门槛低：通过 GGUF 量化格式压缩模型，消费级显卡甚至纯 CPU 也能运行。

• 隐私与数据安全：模型和数据完全保留在本地。

所以，Ollama 和 vLLM 一样属于大模型推理引擎，只是它更偏向个人开发、快速验证和本地部署。

二、Ollama 的主要限制

它的设计目标是「开箱即用」，这也决定了它在一些方面存在明确限制。

1、并发处理能力有限

默认并发设置非常保守，以确保个人使用时的稳定性。

• 默认并发低：官方建议并发数保持在 3～4，大型模型甚至建议设为 1。

• 高并发下性能骤降：超过 10 个用户并发时就可能达到瓶颈，平均延迟超过 21 秒，吞吐量仅约 0.46 请求 / 秒。

• 请求队列限制：最多可排队 512 个请求，超出可能被拒绝。

2、上下文长度与显存强相关

Ollama 支持的上下文长度并非固定值，而是根据可用显存自动调整，默认值通常很保守。

• 默认上下文窗口仅 4096 tokens，即使模型本身支持 128K，默认也可能只使用 4K。

• 按显存自动分级：小于 24 GiB 默认 4K；24～48 GiB 默认 32K；大于等于 48 GiB 默认 256K。

• 超长上下文有风险：会急剧增加显存消耗，可能导致模型层被挤出显存，生成速度从约 18 tok/s 暴跌至 0.9 tok/s。

3、同时加载的模型数量受限

• 默认最多同时加载 2 个模型；在 macOS 上上限是 3 个，且无法通过配置更改。

• 即使在拥有 512GB 内存的顶配 Mac 上，Ollama 也会拒绝加载第 4 个模型。

4、性能瓶颈与运行时问题

• 基准测试显示，Ollama 的吞吐量比底层使用的 llama.cpp 还要低 5～10%，大模型上差距甚至达到 20～30%。

• 存在「静默提示截断」的故障模式：上下文填满时可能不报错，而是直接截断输入，这会影响基准测试的准确性。

三、Ollama 能加载多大参数的模型

理论上没有硬性参数上限，实际大小完全取决于硬件内存（RAM + VRAM）。Ollama 通过量化技术（如 4-bit）将模型压缩，以便在消费级硬件上运行。

以下是基于 4-bit 量化的大致硬件需求：

模型参数规模	4-bit 量化后大致需求	典型硬件场景
7B～8B	约 6 GB 显存起	主流消费级显卡（如 RTX 3060 12GB）
13B～14B	约 10 GB 显存起	中高端显卡（如 RTX 4070）
30B～34B	约 20 GB 显存起	高端显卡（如 RTX 3090/4090）
70B	约 40 GB 显存起	需要多卡（如 2× RTX 3090）或专业卡
100B+	约 64 GB+ 统一内存	Apple Silicon Mac 或大内存设备

实际案例：24GB 消费级显卡可以跑 32B 的 qwen2.5:32b；128GB 的 Apple Silicon Mac 可以跑 70B；128GB 统一内存的设备还能跑 122B 的 MoE 模型。

四、Ollama 与 vLLM 的核心区别

1、定位与设计哲学

• Ollama：定位为开发者友好型本地运行环境，由社区驱动，核心是降低部署门槛，让个人开发者快速实验。

• vLLM：定位为生产级高性能推理引擎，由研究机构主导，核心是在有限硬件下最大化模型效能，专为高并发、低延迟场景设计。

2、性能与并发能力

这是两者最显著的差异。单用户低并发时，生成速度差距不大；但高并发场景下，性能天差地别：

• 吞吐量：10 路并发下，vLLM 吞吐量可达 Ollama 的近 4 倍；50 路并发下差距可拉大到 4.5 倍以上。

• 延迟与稳定性：高负载下 Ollama 可能出现严重排队延迟，错误率可达 13%～30%，而 vLLM 能维持稳定响应。

3、易用性与硬件支持

• Ollama 开箱即用，无需 GPU 或 CUDA 环境；vLLM 通常需要 NVIDIA/AMD GPU 并提前配置 CUDA，有一定技术门槛。

• Ollama 兼容 CPU、Apple Silicon、NVIDIA/AMD GPU；vLLM 主要面向 NVIDIA GPU，且不支持 macOS。

• Ollama 使用 GGUF 官方模型库；vLLM 直接加载 Hugging Face 上的模型，覆盖更广。

4、一张快速对比表

维度	Ollama	vLLM
定位	个人本地运行环境	生产级高性能推理引擎
核心目标	降低部署门槛	最大化吞吐与硬件利用率
并发能力	弱，适合低并发	强，适合高并发
易用性	开箱即用	配置较复杂
硬件支持	CPU、Apple Silicon、N/A 卡	主要 NVIDIA GPU，不支持 macOS
模型格式	GGUF，官方模型库	Hugging Face 模型
典型场景	个人开发、原型、隐私离线	企业服务、线上 API、高并发

五、Ollama和vLLM怎么选

1、适合选择 Ollama 的情况

• 想在笔记本或台式机上快速实验、开发原型。

• 数据隐私敏感，希望完全离线或本地运行。

• 只有消费级显卡、Mac 或纯 CPU。

• 本地知识库、教育学习、个人助手等低并发场景。

2、更适合选择 vLLM 的情况

• 需要为企业应用或线上服务提供模型 API。

• 面临高并发请求，对吞吐量和延迟有严格要求。

• 拥有服务器级 GPU（如 A100/H100），追求硬件利用率。

• 需要无缝集成 Hugging Face 生态，支持张量并行等分布式推理。

六、ollama run 之后到底发生了什么

执行 ollama run 启动模型时，Ollama 后台会执行一系列内存管理操作，核心目标就是尽可能利用 GPU 加速推理。

1. 检查模型是否已加载：后台服务（监听 11434 端口）先检查模型是否已在内存中处于「热」状态，是则直接复用。

2. 从模型存储读取：未加载则从本地模型库（通常在 ~/.ollama/models）读取，文件以类似容器镜像的分层结构存储。

3. 评估显存需求：这是最关键的一步，评估模型完整加载所需显存，与当前可用显存对比。

4. 加载权重到显存或内存：能完全放入单卡就全进 VRAM；放不下就分到多卡；显存不足则一部分留 RAM 由 CPU 计算，即「部分卸载」。

5. 启动推理引擎：加载完成后基于 llama.cpp 启动推理，生成回复。

可以用 ollama ps 查看加载情况：100% GPU 表示完全在显存，48%/52% CPU/GPU 则表示混合加载。

七、写在最后

Ollama 是一个出色的大模型推理引擎，优势在于个人开发、快速验证和隐私敏感场景。它的低并发、保守上下文、有限模型并行这些限制，正是为了保证在普通硬件上开箱即用而做出的权衡。

Ollama 是个人探索的「瑞士军刀」，vLLM 是生产服务的「工业引擎」。 在个人工作站上做实验、搭本地知识库、跑个人助手，Ollama 非常合适；要为大量用户提供稳定高并发的模型服务，vLLM 才是更合适的选择。