oLLm 是一个开源项目，通过将权重和 KV 缓存分层下放到 CPU 内存或 NVMe SSD，实现了在消费级显卡上运行大模型长上下文推理。它利用 FlashAttention-2 和分块 MLP 技术，显著降低了显存需求，使 8GB 显存的显卡也能处理 50k-100k tokens 的上下文。oLLm 兼容 HuggingFace 接口，学习成本低，但需要安装 CUDA 和 KvikIO 库，并面临 SSD 空间和延迟成本的限制。

📚 oLLm 是一个开源项目，旨在通过将权重和 KV 缓存下放到 CPU 内存或 NVMe SSD，实现大模型长上下文推理。

🖥️ 它利用 FlashAttention-2 和分块 MLP 技术，显著降低显存需求，使 8GB 显存的显卡也能处理 50k-100k tokens 的上下文。

💻 oLLm 兼容 HuggingFace 接口，学习成本低，但需要安装 CUDA 和 KvikIO 库，并面临 SSD 空间和延迟成本的限制。

⚙️ 它更适合离线分析、长文档审阅、批量处理等任务，而不是对延迟敏感的在线服务。

🔑 oLLm 打开了“小卡跑大模型”的大门，但你要付出的代价是时间与磁盘。

原创 让你更懂AI的 2025-09-28 13:35 北京

把80B模型塞进消费级显卡

在大模型推理的世界里，有一个残酷的现实：上下文越长，钱包越痛。你想在 10 万 tokens 的文档里挖掘知识？对不起，先准备一张几十 GB 显存的高端 GPU，再外加一台服务器的预算。长上下文能力明明是刚需，却总被硬件门槛挡在门外。 

直到最近，一个小而灵的开源项目——oLLm，提出了一个看似疯狂却极其实用的思路：显存不够，SSD 来凑。结果是，普通人家里那块 8GB 的 3060 Ti，也能硬生生把 Qwen3-80B、Llama3-8B 拉到 50k–100k tokens 的上下文里运行。

项目名称：

LLM Inference for Large-Context Offline Workloads

项目地址：

https://github.com/Mega4alik/ollm

为什么是oLLm？

传统推理引擎，比如 vLLM，会通过分页管理等技巧在显存里“挤出空间”，但它们的本质依旧受制于 GPU 显存容量。上下文越长，瓶颈就越明显。

OLLm 则走了一条完全不同的路线：

权重和 KV 缓存分层下放：显卡只负责最核心的计算，其他部分被分散到 CPU 内存或 NVMe SSD。这等于给 GPU 做了“显存减负”，让小显存卡也能顶上场。
FlashAttention-2 加持：长上下文最怕注意力矩阵膨胀，FlashAttention-2 的高效实现保证了即便是百 k 级长度，也不会直接把显存压爆。
分块 MLP（Chunked MLP）：把中间层切片处理，削减峰值显存开销，进一步压低显存占用曲线。

换句话说，oLLm 用一种很“工程黑客”的方式，把大模型的资源分配逻辑彻底改写：用便宜的 SSD 和 IO，换取宝贵的显存容量。

结果就是——哪怕只有一块 8GB 的小卡，也能和百 GB 显存的怪兽 GPU，在长上下文场景里同台竞技。

▲ Baseline vs oLLm对比架构示意图

Baseline 把所有权重和缓存都压在 GPU 上，显存需求飙升；oLLm 则分层到 GPU / CPU / SSD，让 8GB 小卡也能“越级挑战”。

架构与代码：SSD插手的推理过程

oLLm 的核心结构其实不复杂，关键在于一种“插槽化”的思路：当显存不够用时，KV cache 不再死死待在 GPU，而是被下放到 SSD。

初始化与加载

from ollm import Inference# Step 1: 初始化推理器ollm = Inference("llama3-3B-chat", device="cuda:0")# Step 2: 模型准备ollm.ini_model(models_dir="./models", force_download=True)# Step 3: 可选操作——把部分层权重丢到 CPU，进一步节省显存ollm.offload_layers_to_cpu(layers_num=4)

上面这段代码展示了最典型的初始化过程：模型对象被加载，但并不会把全部权重一次性灌进显存，而是根据需要动态调度。

磁盘缓存的接入

# 把 KV cache 放到磁盘past = ollm.DiskCache(cache_dir="./kv_cache")# 输入与推理messages = [    {"role": "user", "content": "请总结这篇长达 3 万 tokens 的法律合同"}]input_ids = ollm.tokenizer.apply_chat_template(messages, return_tensors="pt").to(ollm.device)outputs = ollm.model.generate(    input_ids=input_ids,    past_key_values=past,    max_new_tokens=200)

这里的亮点是  DiskCache ：它让 GPU 显存只存放必要的计算张量，而上下文膨胀导致的 KV cache 全部落盘。对用户来说，只是多写了一行，但背后却意味着一次彻底不同的推理路径。

推理流程一图看懂

为了更直观地理解这一变化，可以看看下图：

用户输入先经过 Tokenizer，再进入 Inference 引擎；与此同时，KV 缓存被分流到 SSD 的 DiskCache。最终生成结果返回给用户。只需在代码里多写一行，推理链路就被彻底改写，显存压力转移到 SSD。

安装与使用体验：一行行命令背后的门槛

要跑通 oLLm，你并不需要特别复杂的环境，但有几个小坑需要注意。

环境准备

# 创建虚拟环境python3 -m venv ollm_envsource ollm_env/bin/activate# 安装 ollmpip install ollm# 安装与 CUDA 匹配的 kvikIO（用于加速文件 I/O；若环境支持 GDS 可实现 SSD→GPU 直通）pip install kvikio-cu12

这一步看似常规，但 kvikio-cu12 是关键，它决定了 SSD 与 GPU 之间的数据搬运是否高效（有 GDS 时能走直通，无 GDS 时也能显著提速）。

模型下载（Python调用）

# HuggingFace Hub 上下载模型ollm.ini_model(models_dir="./models", force_download=True)

由于 oLLm 兼容 HuggingFace，你可以像使用常规 Transformers 一样准备模型权重。但要注意，像 Qwen3-next-80B 这种超大模型，还需要 Transformers 4.57.0.dev。

启动推理

PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True \python run_example.bash

这里的环境变量设置同样重要，它能避免内存碎片化，让长上下文推理更稳。 

从上手体验来看，oLLm 的 API 与 HuggingFace 高度一致，学习成本低。但部署难度主要体现在：CUDA 与 KvikIO 的版本匹配，以及模型体积带来的下载与存储开销。

显存的“常数化”，代价与启示

真正让 oLLm 脱颖而出的，是它在消费级硬件上的表现。官方在一块 RTX 3060Ti（8GB） 上测试了多种大模型，结果颇为震撼。

▲ Baseline vs oLLm显存占用对比

在 baseline 下，Qwen3-next-80B (50k) 需要近 190GB 显存，几乎不可能在普通 GPU 上运行。而 oLLm 仅需 7.5GB，硬生生把百 GB 级的显存需求压进了小卡的容量里。Llama3-8B-chat 在 100k 上下文下的显存需求也从 71GB 降到 6.6GB，显存消耗近乎“常数化”。

▲ SSD空间开销

不过，显存的节省是以磁盘为代价换来的。Qwen3-next-80B 在 oLLm 下需要约 180GB SSD，Llama3-8B-chat 也要 69GB。这意味着 oLLm 更适合离线批处理、文档审阅等场景，而不是对延迟敏感的在线服务。

大多数模型显存节省率超过 80%，其中 Qwen3-next-80B 接近 96%。这不仅意味着“能跑”，更意味着上下文扩展的边际成本转移到了 SSD——一个更廉价、可扩展的资源。

▲ 上下文长度与显存占用趋势（示意）

baseline 的显存需求几乎随上下文线性飙升，而 oLLm 的显存曲线接近平坦。增长的主要是 SSD 占用与 I/O 延迟。这种架构决定了 oLLm 在超长文本分析、合规审查、科研实验等场景有独特优势，但并不适合要求低延迟的实时交互。

注：本图为趋势示意图，基于官方 README 披露的离散数据点与推理规律绘制，并非逐点实测曲线。

小卡的春天，延迟的阴影

优势一：硬件门槛骤降过去，百 k 上下文的推理意味着百 GB 显存的服务器级显卡。oLLm 的“SSD 换显存”方案，把这道门槛压缩到一块 8GB 的消费级显卡。这不仅让更多研究者和开发者有机会参与实验，也让长上下文的探索从“大厂特权”变成了“社区共享”。

优势二：生态兼容无痛oLLm 与 HuggingFace 的接口几乎一致，API 调用方式保持原样。对开发者而言，几乎没有额外学习成本——只需要在推理链路里多写一行 DiskCache。这种低门槛的体验，是它能迅速引起社区关注的原因之一。

优势三：节省显存成效显著显存占用被压到 5–8GB 档，大多数模型节省率超过 80%，其中 Qwen3-80B 接近 96%。这意味着“长上下文”从一个硬件奢侈品，转变成可以随手尝试的实验选项。

局限一：磁盘开销与延迟成本代价同样明显：SSD 空间需求巨大，Qwen3-80B 需要约 180GB SSD，且推理速度受限于磁盘 I/O。对于交互式问答、低延迟对话等场景，oLLm 并不适合。它更偏向离线分析、长文档审阅、批量处理等任务。

局限二：环境兼容性挑战KvikIO 的 CUDA 版本需要与本地环境严格匹配，Transformers 版本也有限制。如果开发者对 CUDA、驱动或库的依赖关系处理不熟，很容易在安装阶段踩坑。

一句话总结：oLLm 打开了“小卡跑大模型”的大门，但你要付出的代价是时间与磁盘。它是一把钥匙，却不是万能钥匙。

8GB显卡的逆袭，才刚刚开始

在大模型推理的硬件门槛面前，oLLm 提供了一种充满巧思的解法：显存不够，就让 SSD 来补位。它没有解决所有问题，却把“百 k 长上下文”从实验室和数据中心拉进了个人电脑。

对于研究者，它意味着更低成本的实验可能；对于社区，它意味着更多样的探索路径。未来，当磁盘 I/O 优化、跨平台支持逐步补齐，oLLm 这样的设计或许能真正把“长上下文”变成人人可用的能力。

换句话说，oLLm 不仅是一种工程黑客的技巧，更像是一种信号：大模型的未来，不止在云端，也可能在你身边的小卡里。

更多阅读