硬件已经定下来的时候，先别急着挑量化档位。更稳的顺序是：先用这台机器能腾出的显存，估出权重占用的上下限，再在这个区间里选量化格式；量化格式一旦选好，权重文件往往要重新准备，来回换的代价比改上下文长度和卸载层数大得多。LFM2.5-24B-A2B 这类 MoE 结构还有个容易踩的点：A2B 说的是每个 token 走多少激活参数，但显存里常驻的仍然是接近总参数量的权重，按激活参数去估显存通常会低估。下面按“定硬件 → 定权重区间 → 单变量试配置 → 每次记录 → 写取舍清单”的顺序给出可执行的做法。

适用场景：单机端侧部署 LFM2.5-24B-A2B，显卡和内存已固定，量化档位、上下文长度、卸载层数三项拿不准先动哪个。操作动作：先用权重文件体积和空闲显存算出可行区间，再在加载配置里一次只改一个字段，逐次记录显存峰值与生成速度。验证方式：同提示词、同输出长度重复跑，看显存峰值是否越线、单位时间生成量是否明显下降。风险边界：估算是近似值，运行时激活、临时缓冲和并发会额外吃显存，实际可用的上下文长度和层数需结合环境确认，不要按理论值贴着上限配置。

把三个变量写成一张互相约束的表

量化位数、上下文长度、卸载层数不是三件独立的事，改其中任何一个都会挤压另外两个的余量。先把约束关系写清楚，再动手：

• 量化位数 → 权重占用。权重占用近似等于参数量乘以每参数字节数，再叠加分组量化的 scale/zero 等辅助张量开销。4bit 大致是每参数半个字节，8bit 大致是一个字节，实际落盘文件比理论值略大。所以最可靠的估算方式不是算，而是直接看权重文件的体积。
• 上下文长度 → 缓存占用。KV 缓存随序列长度线性增长，同时受层数、KV 头数、head_dim 和缓存精度影响。上下文翻倍，KV 缓存大致也翻倍，这部分开销和权重占用是并列占用，不是二选一。
• 卸载层数 → 生成速度。把一部分层放到 CPU 或系统内存，可以让权重塞进显存，但每个 token 都要跨设备搬运这部分计算，单位时间生成量通常随之下降。卸载层数越多，显存压力越小，速度越慢，这就是唯一直接的交换关系。

先固定硬件，再估权重占用的上下限

先看这台机器实际能腾出多少显存，而不是看标称容量。用下面这条命令取一次当前值：

nvidia-smi `--query-gpu`=name,memory.total,memory.used,memory.free `--format`=csv
# 非 NVIDIA 环境换成对应工具，如 rocm-smi

把 memory.free 当作权重占用的硬上限，再从中扣掉系统显示输出、驱动上下文、同机其他进程占用，以及运行时需要的激活和临时缓冲。这部分很难精确算，建议先按保守比例预留，剩下才是权重可用的区间。接着看权重文件实际体积：

du -sh /path/to/LFM2.5-24B-A2B-*/
ls -lh /path/to/weights/*.safetensors 2>/dev/null | head

把不同精度版本的目录分别量一次，就得到一组对应的权重占用值。用「权重占用 + 预留」去比「显存可用」，能装下的精度构成下限，装不下的就是上限。这一步只做判断，不改任何配置。需要结合环境确认的是：同一个模型不同发布方的量化产物体积差异不小，最好以你手上实际要加载的那份文件为准。

在配置里按顺序一次只改一个变量

下面的骨架是通用写法，字段名以你实际使用的加载器为准，替换成对应键名即可。三个字段的位置和取值范围先说清楚，再谈改动顺序。

model: LFM2.5-24B-A2B
weights: /path/to/weights          # 需与下面 quant.format 实际匹配

quant:
  format: int4                     # int4 / int8 / gguf 具体量化类型
                                   # 多数加载器要求权重文件本身就是该格式，
                                   # 不能只改字段；仅加载时量化的实现才可切换

context:
  max_seq_len: 4096                # 正整数，从偏小值起，逐步加

offload:
  gpu_layers: 999                  # 0 ~ 总层数；先试能全放下的最大值
  cpu_layers: auto                 # 其余层落 CPU/内存

改动顺序建议是：先定 quant.format（因为受权重文件约束，代价最大），再动 offload.gpu_layers（纯运行时参数，改完立刻看显存峰值和速度），最后才试 context.max_seq_len（它主要吃 KV 缓存，前面两项稳定后再往上加）。每一轮只改一个字段，其余保持原值，否则出问题时无法归因。

每改一项就记录一次占用与生成速度

把调整过程变成可对比的数据，每次改动后固定记录四个字段：

• 显存峰值：加载完成并跑完一轮生成后的最高占用，用 nvidia-smi 定时采样或看加载器日志。
• 加载耗时：从进程启动到可以接受请求的时间。
• 首字延迟：同一提示词下第一个 token 返回的时间。
• 单位时间生成量：稳定解码阶段的 token 数除以耗时。

对比方式要控制住变量：同一段提示词、同一最大输出长度、同一 batch、同一采样参数，每档配置至少跑几次取中位数，避开首次运行的预热影响。记录可以简单写成一行文本，例如「int4 / 4096 / 全层 GPU → 显存峰值 X、加载 Y 秒、首字 Z 秒、生成 W tok/s」，只要每行结构一致，横向就能看出是哪一项在拖后腿。

在取舍清单上写下最终组合与主动放弃的项

调到最后一定会剩下一个“不够完美”的组合，把它写下来，比记在脑子里有用。可以照下面这个模板填：

最终量化档位：____
上下文长度：____
卸载层数：____（总层数 ____）
显存峰值：____
单位时间生成量：____
主动放弃：____
放弃原因：____
重估条件：换更大显存 / 换更小上下文 / 换更激进量化

“主动放弃”这一栏往往填的是：为了保住生成速度而放弃长上下文，或为了全层驻留显存而降一档量化精度，或为了长上下文而接受部分层卸载。写清楚放弃项和重估条件，下次换机器或换权重格式时不用从头再试一遍。