单卡部署：权重、显存与上下文预算

本页解决容量问题：设备中需要放下什么，上下文和并发增加后会发生什么。下文带日期的候选用于说明这些约束。模型行为见编码模型选型，数值格式和速度分析分别见模型量化与推理性能。

“能在单卡上跑”可能只是权重勉强加载，也可能是借助 CPU 卸载完成短请求，或是在所需上下文长度下达到交互速度。判断配置是否实用，要看任务需要多少内存、多长的上下文，以及能接受多大的延迟。交互式编程和夜间批处理，对速度的要求并不相同。

先算显存预算

原始权重的显存占用大致为：

\text{weight bytes}\approx\frac{\text{parameter count}\times\text{bits per weight}}{8}.

以 27B 参数量的模型为例，4-bit 量化后权重本身约需 12.6 GiB。但这还没算量化元数据、高精度张量、运行时工作区以及 KV 缓存。如果已有现成的量化文件，直接看文件大小比单纯计算参数量更准确。

对于传统的 MHA 或 GQA 架构，单个序列的 KV 缓存占用约为：

2\times L\times S\times d_{kv}\times b,

其中 $L$ 是层数， $S$ 是保留的序列长度， $d_{kv}$ 是每层的键/值宽度， $b$ 是每个元素的字节数。MLA 等其他注意力机制的缓存布局不同。批量大小和多并行序列会成倍增加显存需求。

还要给输出 token、临时缓冲区、显示驱动和运行时波动留空间。如果配置在跑完一个提示词后显存几乎耗尽，那它还不是一个可靠的容量规划方案。

这些只是起点，并非兼容性保证。架构、量化格式、后端、缓存精度和 GPU 支持情况都会大幅改变边界。

Qwen3.6-27B： Apache-2.0 协议，27B 参数，含视觉编码器，原生上下文为 262K，并提供扩展到约 1M Token 的方案。链接中的模型卡推荐 vLLM ≥0.19.0 或 SGLang ≥0.5.10，给的是八卡服务示例，既不能证明存在实测可用的 16 GB 量化配置，也不代表最低需要八张卡。Qwen 建议至少保留 128K 上下文以维持思考能力；为了放进显存而缩短上下文，需要评估对质量的影响，不能当作没有代价的容量优化。
gpt-oss-20b： Apache-2.0 协议，总参数量 21B，活跃参数 3.6B。模型卡片描述了一种设计用于在 16 GB 内存中运行的 MXFP4 文件，且要求使用 Harmony 响应格式。
Mistral Small 3.1 24B： 模型卡片区分了面向消费级 GPU 的量化路径和需要更大显存的 BF16 服务需求。这提醒我们：仅看模型名称无法判断显存占用。

公布的上下文限制并不意味着整个窗口能塞进单张 GPU、运行迅速或保持足够的任务质量。

通过 CPU 或系统内存卸载可以让更大模型跑起来，但数据需经过更慢的路径，解码速度可能大幅下降。性能惩罚的大小取决于模型、卸载层数、内存带宽、互联技术、后端、提示词长度和批量大小。不存在统一的“每秒 token 数”断崖点。

对于延迟敏感的工作，全驻留 GPU 是理想状态，但这并非所有负载的硬性规则。夜间批处理任务可能容忍那些会让交互式编程循环变得卡顿的卸载方案。

在工具调用循环中，较小的驻留模型往往胜过较大的卸载模型。更大的上下文也可能让系统变慢，却未必能更好地找到关键证据。请使用本地评估协议基于任务而非参数量来做决定。

Accelerate 的模型内存估算指南演示如何不加载全部权重，就估算不同数值类型的参数内存。先与本文的权重计算对照，再单独测量完整运行时；缓存、激活和临时缓冲区仍要另外留预算。