Mistral Large 4 本地跑要算显存、量化格式决定能不能跑

本地跑 Mistral Large 4 能不能跑起来，卡点通常不在模型本身，而在两件事：显卡显存够不够放下权重和上下文缓存，以及选哪种量化格式。显存决定上限，量化格式决定下限——同一张卡，用 FP16 可能加载即 OOM，换成 INT4 就能跑起来，代价是效果和速度要自己验证。稳妥顺序是：先从模型卡确认参数量和可用量化类型，再按公式估一遍显存，然后选 llama.cpp 或 vLLM 加载，最后用 nvidia-smi 看真实占用，不满意再回头调参数。

查模型卡拿到参数量和量化类型，按「参数量 × 每参数字节数 + 上下文缓存」估最低显存，通常还要给运行时留出余量。显存不够时优先降量化精度或缩短上下文，而不是靠系统交换空间硬扛。量化到 INT4 这类低位后，指令跟随和长上下文表现需要用固定用例自己对比，不能只看单条回复是否通顺。加载完成后用 nvidia-smi 确认实际占用，再根据推理日志和报错回调参数。

查模型卡确认参数量和可用量化格式

先打开 Hugging Face 模型页或官方仓库的模型卡，找这几项：总参数量（如果是 MoE，还要看激活参数量）、上下文长度上限、官方或社区提供的量化格式、对话模板。不要用别人截图里的数字，自己打开页面确认。量化类型常见的有 GGUF 的 Q4_K_M / Q5_K_M / Q8_0、AWQ、GPTQ、FP8 等，能选哪些直接决定了后面显存怎么估。

如果模型卡只给了架构描述，可以下载 config.json 看结构：

huggingface-cli download <repo_id> config.json `--local-dir` ./ml4
python -c "import json;c=json.load(open('./ml4/config.json'));print({k:c.get(k) for k in ['num_hidden_layers','hidden_size','num_attention_heads','num_key_value_heads','max_position_embeddings']})"

这些字段不直接等于参数量，但能帮你判断 KV cache 的量级，以及模型是否支持你要用的长上下文。参数量以模型卡标注为准，不假设具体数值。另外确认量化文件是否分片：GGUF 常见 -00001-of-0000X 命名，加载时要给第一片路径或整个目录。

按量化精度估算显存占用

估算公式：

显存 ≈ 参数量 × 每参数字节数 + KV cache + 运行时开销

每参数字节数按量化精度取：FP16/BF16 约 2 字节，FP8/INT8 约 1 字节，INT4（含 AWQ-4bit、Q4 系列）约 0.5 字节，实际会因为量化元数据和未量化层略高于这个值。设模型参数量为 N（单位十亿），权重部分的量级就是：

FP16/BF16：约 2N GB
FP8 / INT8：约 N GB
INT4：约 0.5N GB

KV cache 单独算，粗略形式：

KV cache ≈ 2 × 层数 × KV 头数 × 头维度 × 序列长度 × 并发数 × 每元素字节数

序列长度（上下文）和并发数是你能直接调的变量，也是显存最容易失控的地方。举例：设 N 为模型参数量，按 INT4 估权重约 0.5N GB，如果你的卡在放完权重后只剩很小一块余量，那 KV cache 加上运行时开销大概率不够；把 -c（llama.cpp）或 `--max-model-len`（vLLM）从 32768 降到 8192，KV cache 会大致按比例下降，这就是「能不能跑」的取舍点。

用 llama.cpp 加载 GGUF 量化模型

llama.cpp 适合单机单卡或少量卡，直接吃 GGUF 量化文件。先确认文件路径，再加载：

./llama-cli \
  -m /models/mistral-large-4-Q4_K_M.gguf \
  -c 8192 \
  -ngl 99 \
  -t 8 \
  `--temp` 0.7 \
  -p "用一句话解释量化"

要起兼容接口的服务用 llama-server：

./llama-server \
  -m /models/mistral-large-4-Q4_K_M.gguf \
  -c 8192 \
  -ngl 99 \
  `--host` 0.0.0.0 `--port` 8080

参数含义：-m 是模型文件（分片给第一片），-c 是上下文长度，-ngl 是放到 GPU 的层数，显存不够就往下调，-t 是 CPU 线程数。如果 -ngl 调小后大量层留在 CPU，速度会明显下降，属于能加载但不好用的状态，需要自己权衡。量化类型写在文件名里，Q4_K_M、Q5_K_M、Q8_0 对应不同的每参数字节数，换文件就是换显存占用。

用 vLLM 加载 AWQ 量化模型

vLLM 更适合需要并发和 OpenAI 兼容接口的场景，AWQ 权重需要显卡支持对应的 kernel：

python -m vllm.entrypoints.openai.api_server \
  `--model` /models/mistral-large-4-awq \
  `--quantization` awq \
  `--dtype` float16 \
  `--max-model-len` 8192 \
  `--gpu-memory-utilization` 0.9 \
  `--tensor-parallel-size` 1 \
  `--port` 8000

关键参数：`--quantization` awq 告诉 vLLM 按 AWQ 方式加载，模型目录里通常带有对应的量化配置；`--gpu-memory-utilization` 控制显存总占用比例，权重和 KV cache 都算在里面；`--max-model-len` 决定 KV cache 上限；`--tensor-parallel-size` 大于 1 时把模型切到多卡。如果启动时报 KV cache 不足，先降 `--max-model-len` 或 `--gpu-memory-utilization`，再考虑换更低位的量化。

用 nvidia-smi 观察显存占用与推理延迟

加载前先看基线，加载后再看稳定值：

nvidia-smi
nvidia-smi `--query-gpu`=memory.used,memory.total,utilization.gpu `--format`=csv -l 1
nvidia-smi dmon -s mu -d 1

memory.used 接近 memory.total 时，任何更长上下文或更高并发都可能触发 OOM。模型加载完成后先空跑一次推理，看显存是否稳定；如果持续上涨，多半是上下文或缓存没释放。延迟看推理日志：llama-server 和 vLLM 默认都会打印 prompt 处理 token 数和生成速度，客户端侧可以用 time curl 做端到端对照。

根据输出调整的方向：

显存紧张：降量化精度（Q5_K_M 换 Q4_K_M）、缩短 -c 或 `--max-model-len`、减少并发或 batch。
显存有余但速度慢：确认 -ngl 是否够大，是否有不必要的 CPU 卸载。
加载即 OOM：先算权重是否已经超过显存总量，这种情况只能换卡、换量化或分片多卡，调参数无用。

量化到 INT4 之后的输出质量，建议用几组固定问题做前后对比，重点看指令跟随、长上下文里的信息召回和格式遵守。这些对比要在你自己的用例上做，别人给的结论只能当参考。