笙亿网络策划

Mistral Large 4 本地跑，先看显存和量化格式

约 6 分钟读完 16 阅
文章导读
想在本地跑 Mistral Large 4，卡住的通常不是安装步骤，而是显存。下载几十 GB 权重之前，先做两件事：从模型卡确认参数量和可用的量化格式，再用公式估一遍“权重 + 上下文缓存”要占多少显存。估出来塞得下，再挑量化档位；塞不下就换更低位宽或缩短上下文，而不是下完再发现加载失败。
📋 目录
  1. Ⅰ 查官方模型卡确认参数规模和量化支持
  2. Ⅱ 用公式估算不同量化下的显存占用
  3. Ⅲ 在本地用 llama.cpp 加载量化模型
  4. Ⅳ 观察日志确认显存是否溢出及推理速度
  5. Ⅴ 根据硬件调整上下文长度和批大小
A A

想在本地跑 Mistral Large 4，卡住的通常不是安装步骤，而是显存。下载几十 GB 权重之前，先做两件事：从模型卡确认参数量和可用的量化格式，再用公式估一遍“权重 + 上下文缓存”要占多少显存。估出来塞得下，再挑量化档位；塞不下就换更低位宽或缩短上下文，而不是下完再发现加载失败。

先查模型卡的参数量和量化格式列表，再按“参数量 × 每参数字节数 + KV 缓存”估算显存，选一个能塞进显存的量化档位，用 llama.cpp 加载，靠 nvidia-smi 和日志确认有没有溢出。显存紧张时优先下调上下文长度和批大小，或换更低位宽的量化。能不能跑起来取决于显卡显存、上下文设置和量化档位，需要在本机日志里确认，不能只看别人的配置照抄。

查官方模型卡确认参数规模和量化支持

第一步不是搜别人的教程，而是打开模型对应的模型卡页面，找两个字段：参数量（parameter count，可能写作总参数或激活参数）和量化/精度支持列表。参数量决定权重的基线大小，量化支持列表决定你能选哪些低位宽格式。

  • 参数量：模型卡通常在开头或 “Model Details” 一段给出，注意区分总参数量和专家激活参数量，MoE 结构两者差别很大。
  • 量化格式：常见写法包括 GGUF、AWQ、GPTQ、FP8、INT8、INT4 等，以及 GGUF 内部的 Q4_K_M、Q5_K_M、Q8_0 这类档位。以模型卡实际列出的为准，没列出的不要假定存在。
  • 上下文长度：模型卡一般会写训练上下文或支持的最大上下文，这个值直接决定 KV 缓存的上限。

把参数量、量化格式清单、最大上下文长度这三项抄下来，后面两步都靠它们。如果模型卡只给了 PyTorch 权重、没有 GGUF，就需要确认是否有社区转换版本，或自己走转换流程，这一步属于额外工作量。

用公式估算不同量化下的显存占用

显存占用可以粗略拆成权重和运行缓存两部分，用变量表示：

Mistral Large 4 本地跑，先看显存和量化格式
权重显存 ≈ P × B_weights
KV 缓存 ≈ 2 × L × H_kv × D_head × S × B_kv × N_seq
总显存 ≈ 权重显存 + KV 缓存 + 运行时开销（CUDA context、临时 buffer）
  • P：参数量，来自模型卡。
  • B_weights：每个参数占用的字节数。FP16 通常按 2 字节、INT8 按 1 字节、4 bit 量化按约 0.5 字节估算，再留一点量化元数据余量。
  • L：层数；H_kv：KV 头数；D_head：每头维度；S：上下文长度；B_kv：KV 缓存精度字节数；N_seq：并发序列数。

把不同量化档位的 B_weights 代进去，就能看出同一张卡上哪些档位有余量、哪些刚好卡线。运行时开销没有固定比例，建议在估算结果上留出余量，尤其是显存和模型大小接近的时候。上下文长度翻倍，KV 缓存大致同倍增长，这一点比换量化档位更容易被忽略。

在本地用 llama.cpp 加载量化模型

llama.cpp 直接吃 GGUF 文件，命令骨架如下，路径和层数按自己的环境替换：

llama-cli \
  -m /path/to/your-model.gguf \
  -ngl <卸载到 GPU 的层数> \
  -c <上下文长度> \
  -b <批大小> \
  -p "你的测试提示词"

需要常驻服务时换成 server 模式：

Mistral Large 4 本地跑，先看显存和量化格式
llama-server \
  -m /path/to/your-model.gguf \
  -ngl <层数> -c <上下文长度> -b <批大小> \
  `--host` 127.0.0.1 `--port` 8080

-ngl 决定多少层放到 GPU，其余留在内存或 CPU；-c 是上下文窗口，-b 是批大小。加载时看终端输出里的模型元信息，确认加载的量化档位和上下文配置符合预期，再判断是显存问题还是配置问题。

观察日志确认显存是否溢出及推理速度

另开一个终端持续看显存：

nvidia-smi -l 1
nvidia-smi `--query-gpu`=memory.used,memory.total `--format`=csv

日志侧重点看两类信息：一是显存分配失败，例如 out of memory、cudaMalloc failed、failed to allocate 这类关键字；二是 llama.cpp 自身提示层卸载失败或 buffer 分配不足。出现这些提示，说明 -ngl、上下文或批大小超过了当前显卡能承受的范围，先降参数再重试。

Mistral Large 4 本地跑，先看显存和量化格式

速度看的是每次生成 token 的时间或 tokens/s 输出。GPU 卸载层数越多通常越快，但如果显存吃紧触发换页或部分回退到 CPU，速度会明显掉下来，这时要结合 nvidia-smi 的显存曲线一起判断，而不是只看单次输出。

根据硬件调整上下文长度和批大小

显存不够时，优先级建议是：先降批大小，再降上下文长度，最后考虑换更低位宽的量化档位。批大小主要影响并发和部分中间 buffer，降到 1 或较小值能立刻释放一部分显存；上下文长度直接线性影响 KV 缓存，从几万降到几千通常省得最多，代价是可处理的输入变短。

  • 只想做短对话或单轮问答：把上下文压到够用即可，不必按模型最大上下文配置。
  • 需要长文档处理：先确认 KV 缓存估算是否还能塞下，再决定是否接受更低位宽量化带来的质量取舍。
  • 多用户并发：并发数乘进 KV 缓存估算，必要时用较小的上下文加多次请求来换稳定运行。

每改一次参数，都回到日志和 nvidia-smi 复查一遍，确认没有 OOM、显存有余量、输出质量可接受，再固定这组配置。这样调整比盲目下载最全的权重更省时间。