12GB显存跑128B大模型：分层推理与量化调度实战解析

1. 这个标题到底在说什么

先把标题拆开看。“Strata”是一个近期在开源社区里被反复讨论的推理加速方案，它的核心卖点不是训练，而是让大模型在推理阶段吃更少的显存。“12GB显存跑上128B的Qwen”这句话，翻译成大白话就是：一张消费级显卡（比如某款12GB显存的型号），原本连加载一个128B参数量的模型权重都做不到，但借助这套方案，居然能把推理跑起来。

这件事为什么值得聊？因为128B参数的模型，哪怕用FP8精度存储，光权重就要128GB左右；就算用4bit量化，也要60GB以上。12GB显存和这个数字之间差了一个数量级。所以标题里说的“跑上”，一定不是把整个模型塞进显存，而是把显存当成高速缓存，把大部分权重放在内存或存储里，按需调度。这就是这类方案的本质：用时间换空间，用调度换显存。

我写这篇东西，不是要吹某个具体工具多神，而是想把“小显存跑大模型”这件事的底层逻辑、关键参数、实操坑点讲透。适合两类人看：一类是手上有消费级显卡、想本地跑大模型但被显存卡住的开发者；另一类是想理解推理调度机制、做性能优化的工程师。看完你至少能明白，为什么有些方案能“越级”跑模型，以及自己动手时该盯哪些指标。

2. 为什么12GB能碰128B：核心思路拆解

2.1 显存不够，本质是“驻留策略”问题

很多人一上来就问：12GB怎么可能跑128B？答案是：不是所有层都需要同时驻留在显存里。Transformer类模型在推理时是逐层计算的，第1层算完，它的输出传给第2层，第1层的权重在那一刻就不再被需要。也就是说，理论上你只需要同时驻留“当前正在算的那几层”就够了。

但现实没这么简单。因为逐层调度会带来两个代价：一是权重搬运的带宽开销，二是调度本身的延迟。如果每算一层都从内存搬一次权重，PCIe带宽会成为瓶颈，推理速度会慢到无法接受。所以真正可用的方案，一定是在“驻留多少层”和“搬运多少层”之间找平衡。

Strata这类方案的核心，就是把模型权重分层管理，显存里只放热层，冷层放在内存甚至NVMe上，用预取和流水线把搬运时间藏起来。这跟CPU的缓存层级是一个道理：L1最小最快，L3大但慢，内存更大更慢。显存就是这里的L1，内存是L3，硬盘是外存。

2.2 量化是第二把刀：不量化，调度也救不了

光靠分层调度还不够。128B模型即使用4bit量化，权重也有60GB以上。如果显存只有12GB，意味着你要把80%以上的权重放在显存之外。这个比例下，搬运量会非常大。所以这类方案通常会配合低比特量化，把权重压到4bit甚至更低，同时用分组量化（group-wise quantization）来减少精度损失。

这里有个关键点：量化不只是为了省空间，它还直接影响搬运效率。同样搬1GB数据，4bit量化下能搬的“有效参数量”是FP16的4倍。所以量化和调度是乘法关系，不是加法关系。你单独用任何一个，效果都有限；两个一起用，才能把12GB这个数字变得“够用”。

2.3 为什么是Qwen：模型结构对调度友好

标题里特意点了Qwen，不是随便选的。Qwen系列（尤其是大参数量版本）在结构上有几个特点对分层调度比较友好：一是层数多但每层结构规整，方便按层切分；二是GQA（分组查询注意力）降低了KV Cache的显存占用，让显存能腾出更多空间给权重；三是词表较大，embedding层和输出层占的参数比例不低，这两层如果放在显存里，能省不少搬运。

反过来说，如果是一个结构非常不规整、或者KV Cache巨大的模型，同样的调度策略效果会打折扣。所以选模型和选方案是配套的，不能只看参数量。

3. 关键参数与实操要点

3.1 显存预算怎么算：别只看权重

很多人算显存只算权重，这是最大的坑。实际推理时显存占用至少包括四块：权重、KV Cache、激活值、框架开销。12GB里，框架本身可能吃掉1-2GB，KV Cache在长上下文下可能吃掉好几GB，真正留给权重的可能只有8GB左右。

所以你在配置分层策略时，第一步不是算“128B模型要多少显存”，而是先算“我这张卡实际能给权重多少显存”。我一般会留20%的余量，因为推理过程中会有碎片和临时分配。12GB的卡，按9.5GB可用来规划比较稳妥。

3.2 分层策略：按层切还是按块切

分层调度有两种常见做法：按Transformer层切和按权重块切。按层切的好处是调度粒度大、开销小，坏处是粒度太粗，可能一层就超过显存预算。按块切更灵活，但调度次数多，延迟高。

我的经验是：优先按层切，层内再按块切。比如一个128B模型有80层，每层权重约0.75GB（4bit下），那12GB显存大概能驻留10层左右。剩下的70层放在内存，用预取机制在算第N层时提前把第N+1层搬进来。如果某一层特别大（比如embedding层），就单独按块切。

这里有个参数叫预取深度（prefetch depth），指的是提前搬多少层。设太小，搬运延迟藏不住；设太大，内存带宽被占满，反而拖慢。一般从2开始试，根据实际吞吐调整。

3.3 量化配置：4bit不是终点

4bit量化是当前比较平衡的选择，但具体到实现，有几个参数要盯：

• group size：分组量化的大小，常见128或64。越小精度越高，但元数据开销越大。我一般用128，精度和开销比较平衡。
• 量化类型：对称量化还是非对称量化。权重一般用对称，激活用非对称。
• 是否量化KV Cache：如果上下文很长，KV Cache量化能省不少显存，但可能影响生成质量。建议先不量化，显存不够再开。

注意：量化后的模型需要对应的推理内核支持，不是所有框架都能直接吃4bit权重。选框架时先确认它支持哪些量化格式。

3.4 内存和存储：别忽略这两个瓶颈

显存之外，内存带宽和存储速度直接决定调度效率。DDR4和DDR5的带宽差一倍，NVMe和SATA SSD的随机读差好几倍。如果你用SATA SSD做权重存储，预取延迟会高到让推理变得不可用。

我的建议是：权重优先放内存，内存不够再放NVMe。如果内存只有32GB，那128B模型4bit量化后60GB，至少一半要放NVMe。这时候NVMe的随机读性能就是关键，最好用PCIe 4.0以上的盘。

4. 实操过程：从零跑通一个分层推理

4.1 环境准备与依赖确认

先确认你的硬件底线：一张12GB显存的卡、至少32GB内存、一块NVMe SSD。软件上，需要支持分层加载的推理框架。不同框架的配置方式不一样，但核心参数就那么几个：显存预算、分层策略、量化格式、预取深度。

我一般会先跑一个小模型验证流程，比如用一个7B模型，把显存预算设成2GB，强制它走分层调度。如果能跑通，再换大模型。这样能快速定位是配置问题还是硬件瓶颈。

4.2 模型转换与量化

如果拿到的原始权重是FP16，需要先做量化转换。这一步通常在CPU上做，比较吃内存。128B模型FP16转4bit，峰值内存可能要到100GB以上。如果内存不够，可以分片转换，或者用流式转换工具。

转换时要注意：保留原始权重备份，因为量化是有损的，万一效果不好还得回退。另外，转换后的权重格式要和推理框架匹配，不同框架的4bit格式可能不兼容。

# 示例：量化转换命令（具体参数因工具而异） python convert.py \ --model /path/to/qwen-128b \ --output /path/to/qwen-128b-4bit \ --bits 4 \ --group-size 128 \ --dtype fp16

4.3 分层配置与启动

启动推理时，核心是配置显存预算和分层策略。下面是一个典型的配置片段：

model: path: /path/to/qwen-128b-4bit quantization: 4bit group_size: 128 memory: gpu_budget: 9.5GB cpu_budget: 48GB disk_path: /nvme/weights scheduler: strategy: layer_wise prefetch_depth: 2 eviction_policy: lru

这里gpu_budget是给权重的显存，不是总显存。prefetch_depth从2开始，跑起来后用监控工具看显存和带宽占用，再决定加还是减。

4.4 性能观测与调优

跑起来之后，重点看三个指标：首token延迟、每token延迟、显存峰值。首token延迟反映预取和加载效率，每token延迟反映稳态吞吐，显存峰值反映调度是否稳定。

如果首token延迟很高，说明预取没藏住搬运时间，可以加大预取深度或换更快的存储。如果每token延迟波动大，可能是显存碎片或调度抖动，可以试试固定层驻留策略。如果显存峰值接近上限，说明预算设太紧，要留更多余量。

我实测下来，12GB卡跑128B 4bit模型，稳态吞吐大概在每秒几个token的量级，首token延迟可能到十几秒。这个速度不适合交互式对话，但适合离线批处理或对延迟不敏感的场景。

5. 常见问题与排查技巧

5.1 启动就OOM：先查框架开销

很多人配置里写了9.5GB权重预算，结果一启动就OOM。原因通常是框架本身的开销没算进去。不同框架的运行时占用差异很大，有的吃1GB，有的吃3GB。排查方法是：先不加载模型，只启动框架，看显存占用多少，再把这个数字从总显存里扣掉。

另一个常见原因是KV Cache预分配。有些框架会按最大上下文长度预分配KV Cache，哪怕你实际只用短上下文。这时候要把预分配关掉，改成动态增长。

5.2 速度慢到不可用：定位瓶颈在搬运还是计算

如果推理速度慢，先分清是搬运瓶颈还是计算瓶颈。方法很简单：看GPU利用率。如果GPU利用率很低（比如20%以下），说明大部分时间在等数据，瓶颈在搬运。如果GPU利用率很高但速度还是慢，说明计算本身慢，可能是量化内核效率低。

搬运瓶颈的解法：换更快的存储、加大预取深度、减少量化分组开销。计算瓶颈的解法：换更高效的推理内核、调整batch size、检查是否用了不支持的算子。

5.3 生成质量下降：量化参数背锅

4bit量化后如果发现生成质量明显下降，先检查group size是不是太大。group size从128降到64，精度会好一些，但显存和带宽开销增加。另一个可能是某些层不适合量化，比如输出层和embedding层，可以对这些层保留FP16。

5.4 独家避坑：别在机械硬盘上跑分层

我踩过最大的坑，就是试图用机械硬盘做权重存储。结果首token延迟直接飙到几分钟，完全不可用。分层推理对随机读非常敏感，机械硬盘的寻道时间会让预取机制彻底失效。如果你手头只有机械硬盘，建议先升级到NVMe，这是最低门槛。

另一个坑是内存不足时用swap。swap的延迟比NVMe还高一个数量级，一旦触发swap，推理基本就卡死了。所以内存预算要留足，宁可少驻留几层，也不要让系统开始swap。

6. 这套方案适合谁，不适合谁

分层推理不是万能药。它适合显存有限但内存和存储充裕的场景，比如个人开发者用消费级卡跑大模型做实验、做离线批处理、做模型评估。它不适合对延迟极度敏感的场景，比如实时对话、在线服务。因为搬运开销决定了它的延迟下限，这个下限很难通过调优突破。

另外，这套方案对模型结构有要求。层数多、结构规整、KV Cache小的模型更适合。如果模型本身KV Cache就很大，显存被KV Cache吃掉，留给权重的空间就更少，调度效果会打折扣。

我在实际使用中的体会是：先算清楚你的瓶颈在哪，再决定要不要上分层。如果显存只差一点点，量化就够了；如果差一个数量级，分层才有意义。别为了用而用，工具是解决问题的，不是制造问题的。

最后分享一个小技巧：跑分层推理时，把日志级别调到debug，能看到每层的加载和驱逐记录。这些日志对调优非常有用，能帮你判断预取深度是否合理、哪些层被频繁换入换出。调优的本质就是让热层稳定驻留，冷层少搬动，日志会告诉你真相。