手里只有一张消费级显卡时，Xiaomi MiMo-V2.6 能不能在本机加载，取决于三个可以事先算出来的量：可用显存上限、权重按什么精度存放、推理时 KV 缓存与激活值要吃掉多少。顺序建议固定下来——先用 nvidia-smi 与权重目录确认硬件和模型的基本盘，再把显存拆成权重、KV 缓存、激活值三块相加，不够时先降量化位宽，再选能加载这种量化格式的推理框架，最后跑一次最小加载，并用一条真实输入验证输出。跳过前两步直接装框架，通常会在加载到一半时 OOM，回头排查反而更慢。
先量硬件上限，再算权重、KV 缓存、激活值三块之和，只有三块之和明显小于可用显存时才值得继续往下走。显存不够时优先降量化位宽，其次减上下文长度，然后才是换框架或换卡。参数量、层数、KV 头数以权重目录里的 config.json 为准，不要按模型名字推测。下面给的是量级算式，实际占用以加载日志和 nvidia-smi 读数为准。
用 nvidia-smi 和权重文件体积核对可用显存
先确认硬件上限，避免拿一张被桌面占掉一部分的卡，去套满血显存做后续估算。
- 显存读数：nvidia-smi 表格里的 Memory-Usage 一列是当前值，动态观察可以用
nvidia-smi `--query-gpu`=memory.total,memory.used,memory.free `--format`=csv -l 1，看 total 与 free 的差值才是真正能用的部分。 - 权重文件体积：
du -sh 权重目录，或ls -lh逐个查看 *.safetensors 分片后加总。如果目录里同时放了多种精度版本，只统计准备实际加载的那一份，否则会把上限估小。 - 余量：驱动、CUDA 上下文、桌面环境和显示输出都会占显存，通常建议在 free 的基础上再留出一部分余量；留多少需要结合桌面环境与驱动版本确认，纯命令行服务器可以比带图形界面的机器留得少。
这一步的产出是两个数：可用显存 X 和权重文件实际体积 Y。如果 Y 已经接近 X，量化位宽基本没有商量空间，直接进入下一步的量化比较。
把显存拆成权重、KV 缓存、激活值三块分别估算
把「能不能跑」变成一次加法，而不是反复试错。三项的估算式与取值来源如下表，最后一列说明哪些项只能给区间。
| 分项 | 估算式 | 取值来源 | 取值性质 |
|---|---|---|---|
| 权重 | 参数量 × 每参数字节数 + 少量额外开销 | config.json 的参数量、实际量化位宽 | 相对确定，可以算 |
| KV 缓存 | 2 × 层数 × KV 头数 × 头维度 × 序列长度 × 并发数 × 每元素字节数 | config.json 的层数与注意力配置、运行时上下文长度与并发 | 上下文和并发未定时只能给区间 |
| 激活值与临时缓冲 | 与批大小、序列长度、算子实现和框架调度有关 | 框架实现与运行日志 | 只能给区间，一般靠加载后实测反推 |
每参数字节数是唯一比较硬的部分：16 位精度约 2 字节，8 位约 1 字节，4 位约 0.5 字节，加上缩放因子、嵌入层等少量结构开销。KV 缓存那一条里，如果模型使用 GQA 或 MQA，KV 头数会小于注意力头数，必须看 num_key_value_heads 这类字段而不是直接套 num_attention_heads；头维度通常等于 hidden_size 除以注意力头数，也可能在 config 里直接给出 head_dim。激活值这一项，不同框架的预分配策略差别很大，建议先用一个偏保守的区间（比如与权重量级相当）做初判，跑通后再用实测峰值回填。
从精度损失与加载方式两头比较量化格式
显存不够时决定降到哪一档，要同时看权重大小和加载方式，两者错了框架根本读不进文件。
| 位宽 | 常见格式 | 权重大致比例 | 加载方式 |
|---|---|---|---|
| fp16 / bf16 | 原始权重 | 基准 1× | transformers、vLLM 等直接加载 |
| 8 位 | INT8、GPTQ / AWQ 8bit | 约基准的一半 | 需要框架带对应量化内核 |
| 4 位 | GPTQ / AWQ、GGUF 的 Q4 类 | 约基准的四分之一 | GGUF 走 llama.cpp 一类；GPTQ / AWQ 走 vLLM / transformers 一类 |
| 更低 | 3 位及以下变体 | 更小 | 视格式而定，通常需要专门内核 |
这些比例只作用于权重，KV 缓存和激活值并不会因为权重降位而同比缩小，除非 KV 缓存本身也量化，所以算总量时要分开判断。判断精度变化，可用同一组输入分别跑原精度和量化版本，比较输出是否出现重复、乱码、中英混杂或答非所问；有条件时就用手头的小规模任务做人工比对，不要只看单句效果就下结论。量化算法、group size、是否需要校准数据等细节，需要按所用框架与格式的文档核对。
选定推理框架并跑通最小加载命令
框架选择本质上跟着量化格式走。下面两段是通用骨架，路径、端口和上下文长度按本机情况替换。
# GGUF 权重，llama.cpp 一类
llama-server -m /path/to/model-Q4_K_M.gguf \
`--ctx-size` 4096 \
`--n-gpu-layers` 999 \
`--host` 127.0.0.1 `--port` 8080# GPTQ / AWQ 或未量化权重，vLLM 一类
python -m vllm.entrypoints.openai.api_server \
`--model` /path/to/model \
`--quantization` awq \
`--max-model-len` 4096 \
`--gpu-memory-utilization` 0.90 \
`--port` 8000-m或`--model`：权重文件或权重目录路径，指向实际要加载的那一份。`--ctx-size`/`--max-model-len`：上下文长度，直接决定 KV 缓存大小，第一次加载建议先用一个偏小的值。`--n-gpu-layers`：卸载到 GPU 的层数，给不到全部层数时部分计算会落到 CPU，速度会明显变化。`--quantization`：量化算法标识，写错或框架不支持时通常直接报错退出。`--gpu-memory-utilization`：框架允许占用的显存比例，设太接近 1 容易和系统抢占。
不同版本的框架可能改名、废弃参数或调整默认值，无法确认的参数名和默认值请按框架当前文档核对，不要照抄别人的启动脚本。
用一条真实输入验证输出并记录显存峰值
加载成功不等于能出结果，发一条短输入确认整条链路通了即可，例如「用一句话说明什么是显存碎片。」观察返回是否成句、有没有截断或乱码。日志里通常会出现类似 model loaded、load_tensors、weights loaded 一类的完成关键字，具体字样以所用框架的输出为准，看到它再判断是否进到服务就绪状态。
显存峰值可以在发请求前后用 nvidia-smi `--query-gpu`=memory.used `--format`=csv -l 1 持续采样，或 nvidia-smi dmon -s u 看时间序列，取请求处理期间的最高读数。把这次峰值、上下文长度和并发数记下来，作为下次估算的校准值。
如果加载失败或请求时报显存不足，回退顺序建议是：先降一档量化位宽，再减小上下文长度，然后减小并发或批大小，之后才考虑换推理框架，最后才是换硬件。每一步只改一个变量，改完重新记录日志和峰值，避免同时改多项后无法判断是哪一项起了作用。