容量计算公式
模型权重占用的字节数由精度决定，每个参数对应固定的字节数：GGUF Q4_K_M 属于混合精度，平均每参数字节数约为 0.5–0.56，而非固定的 0.5，因为 K 量化为不同张量分配不同的位宽——请参阅 量化 了解如何解读这些名称。
将参数量乘以每参数字节数得到原始权重大小，然后在此基础上增加约 20%，以容纳 KV 缓存、激活值和框架开销（在适度上下文长度下）：
29 GB（bf16）、约 ~15 GB（8-bit）和约 ~9.5 GB（4-bit）——请参阅 Hugging Face LLM 优化指南。更长的上下文会在该 1.2× 基线之上增加更多 KV 缓存；请参阅 KV 缓存与上下文 了解其缩放原因。
此公式是用于权重容量规划的估算值，并非精确值。实际数值应为你计划运行的特定量化版本的实际
GGUF 文件大小，加上目标上下文长度所需的 KV 缓存。请参阅 GPU 模型适配指南 查看详细示例和交互式估算器。实际竞争内存的资源
以下三项共享同一池 VRAM（或统一内存）：- 模型权重 — 模型加载后固定不变，不受提示词长度影响。
- KV 缓存 — 随上下文长度和批处理大小增长；请参阅 KV 缓存与上下文。
- 激活值和框架开销 — 每次前向传播期间所需的工作内存较小，大致对应上述公式中的
1.2×系数。
卸载：当模型无法完全装入时
如果模型的权重无法完全装入 GPU 的 VRAM，llama.cpp 等后端允许你将模型拆分到 GPU 和 CPU 上运行，而不是直接失败。这通过 --n-gpu-layers（简写 -ngl）标志控制：它设置有多少模型层加载到 GPU 上，其余层保留在系统内存中。
- 完全卸载（
-ngl设置得足够高以覆盖所有层）：整个模型在 GPU 上以全速运行。 - 部分卸载：部分层在 GPU 上运行，其余层在 CPU 上使用系统内存运行。这使得大于 VRAM 的模型能够实际加载并运行，但需付出代价。
- 无卸载（
-ngl 0）：整个模型仅在 CPU 上运行。
llama.cpp。
统一内存如何改变局面
在具有 统一内存 的系统上——Apple Silicon 和 AMD 的 Strix Halo 平台——CPU 和 GPU 共享单个内存池，而不是 GPU 拥有自己独立且较小的 VRAM。这改变了卸载的计算逻辑：- 容量：统一内存系统可以加载比具有固定 VRAM 的独立 GPU 大得多的模型，因为“VRAM”池可以大到等于机器的总 RAM（上限为分配给图形使用的部分）。
- 带宽：同一内存池的带宽低于独立 GPU 上的专用 GDDR 内存。完全装入统一内存的模型解码速度仍慢于完全装入独立 GPU VRAM 的相同模型，因为解码速度取决于带宽，而不仅仅是容量。
深入了解更多
推理如何工作
为什么解码阶段首先受内存带宽限制。
KV 缓存与上下文
随对话增长而非仅随模型增长的内存使用部分。
量化
缩小每参数字节数以改变容量公式中最大的输入变量。
GPU 模型适配指南
VRAM 表格、交互式估算器以及常见硬件的适配情况。
模型适配并运行后
容量规划和卸载让模型在你的硬件上运行，无论是完全在 GPU 上还是与 CPU 拆分运行。一旦它在localhost 上响应请求，下一步就是从其他位置访问它。
为其提供稳定的端点
Tokios 不选择、托管或微调模型——一旦它在本地运行，Tokios 将其转换为一个稳定的、经过身份验证的端点，你可以从任何地方调用。