LFM2.5-24B-A2B 报内存不足时，量化档位和上下文长度都可能是原因，但通常不会同时是主因，最快能区分两者的线索是报错出现的时机。A2B 这个后缀只说明推理时每步激活的参数少，权重仍然要整份驻留内存，省的是算力而不是内存；所以看到 A2B 就判断“机器应该带得动”，往往是误判的起点。

加载阶段就失败，先看量化档位与权重文件本身；能返回首字、多轮对话后失败，先看上下文长度撑起的 KV 缓存；两种现象都出现时，只调小上下文重试一次，再只降低量化档位对照一次，每次只改一项并记录占用与复现情况。若小上下文加低量化仍失败，瓶颈更可能在设备总内存或并发设置，不在模型档位。

记下报错出现的时机与完整信息

同一个“内存不足”字样，落在不同阶段指向的是不同资源不足。加载阶段失败，指的是权重还没全部驻留就放不下，或者量化格式与运行时加载器不匹配。能连上服务，但在生成首个 token 之前失败，通常是权重已驻留、首次分配 KV 缓存和算子 workspace 时超额。多轮对话进行到中途才失败，权重早已稳定驻留，涨上去的是随上下文长度线性增长的 KV 缓存。

重试之前先把下面这些字段抄下来，后面每一步对照都要用同一套字段：

• 报错原文，以及堆栈里第一条与显存或内存分配相关的行
• 失败所处的阶段：模型加载中、首个 token 返回前、第几轮对话中
• 失败时已处理的 token 数或已完成的对话轮次
• 启动参数：上下文长度、batch、并发数、dtype、KV 缓存类型
• 权重文件或量化配置里记录的量化格式字段
• 失败瞬间的进程占用：nvidia-smi 的显存用量、free -g 的可用内存、进程 RSS
• 是否启用了 swap 或内存超分；这项只作现象记录，不当作解决手段

分别估算权重占用与缓存占用的量级

把两个候选原因放到同一把尺子上，只需要大概量级，不需要精确到 MB。权重按量化位数估算：GB 约等于参数量乘以每参比特数除以 8 再除以 10 的 9 次方。按 24B 全参数粗算，4bit 大约 12GB 起步，8bit 大约 24GB 起步，16bit 大约 48GB 起步。这是纯权重估算，实际还要叠加 embedding、输出层、框架运行时和算子 workspace，MoE 结构另有路由与共享层开销，通常要再留出余量。

缓存按上下文长度估算，通用式子为：KV 字节数约等于 2 乘层数乘 KV 头数乘 head_dim 乘上下文 token 数乘每元素字节数，再乘并发数。层数、num_key_value_heads、head_dim 都可以从模型的 config.json 里读到，每元素字节数取决于 KV 缓存的数据类型。这个估算同样只是下限，不含注意力实现里的临时张量和碎片。

两边都算完再看：如果权重估算已经接近机器可用内存，多小的上下文都救不回来；如果权重估算只占一半上下，而按目标上下文长度算出的缓存量占掉了剩下的相当一部分，那上下文就是可疑项。两项都算不清时，直接进入下一步做对照实验。

先单独调小上下文长度再重试

先动上下文，是因为它改动最小、可逆、且直接指向缓存。下面是一个通用配置骨架，字段名以你实际使用的推理框架为准，常见等价写法有 max_model_len、n_ctx、max_seq_len 之类：

model: /models/LFM2.5-24B-A2B
quantization: q4_k_m        # 保持不变
max_model_len: 8192         # 只改这一项，例如从 32768 降到 8192
max_batch_size: 1           # 保持不变
concurrency: 1              # 保持不变
kv_cache_dtype: auto        # 保持不变
dtype: auto                 # 保持不变

重试时必须锁死其他变量：同一份量化文件、同一台机器、同一个 batch 与并发、同一条提示词、同样的对话轮数。把上下文压小后能跑通，说明缓存是主要原因；仍然在加载阶段就失败，说明权重侧的问题没被这步消除，继续下一步。

再单独换更低量化档位做对照

这一步把上下文长度固定在刚刚能跑通的值上，只换量化格式：

model: /models/LFM2.5-24B-A2B
quantization: q3_k_m        # 从 q8_0 或 q4_k_m 降到更低档
max_model_len: 8192         # 与上一步保持一致，不动
max_batch_size: 1
concurrency: 1

换档之后记录三件事：权重文件本身的大小变化、启动完成后进程的常驻占用变化、以及原来那条报错是否还复现。如果换成低档位后占用明显下降且报错消失，说明权重占用是另一个独立原因；如果占用降了但多轮对话依旧中途失败，说明缓存仍在增长，只是被推迟了。同时留意输出质量，低量化档位对短事实问答影响通常较小，对长文推理和代码生成的差异更明显，这一项建议自己主观记录，不要凭感觉下结论。

把结论写成这台机器可承受的配置组合

排查完把可用的组合固定成一个文件，下次直接启动，不再重新试错：

# 本机可承受组合，数值按你的实测结果填写
model: /models/LFM2.5-24B-A2B
quantization: q4_k_m
max_model_len: 8192
max_batch_size: 1
concurrency: 1
kv_cache_dtype: auto

同时维护一份纯文本记录表，列固定为：机器标识、量化档位、上下文长度、并发数、峰值占用、是否复现报错、连续跑通的最长轮次。上限的找法是从可用组合往上加一档上下文或一档并发，直到复现，再退回到前一档，把那一档写进记录表。这份表比任何口头结论都可靠。

有两种情况必须改打法而不是继续调参数。一是已经降到较低量化档位、上下文也压到很小仍在加载阶段失败，说明余量不足以放下权重，缩短对话轮次没有任何作用，只能换显存更大的设备或换更小的模型。二是业务确实需要长上下文，而长上下文只有高量化档位才跑得动，这种冲突无法通过调参化解，要么限制单次会话的对话轮次和输入长度，要么把长上下文任务拆成多次短请求。swap 或内存超分可以让进程不立刻被杀，但会把延迟推到不可接受的水平，只适合应急，不要写进正式配置。