先看现象。TensorRT-LLM 0.14 转换 llama3-8b，tp 设 8，max_batch_size 256，build 阶段报 out of memory for kv cache，单卡 40GB 按理够用。
把日志和配置对完，能解释这个现象的基本就这几处。max_batch_size 与上下文长度相乘后需求被放大。还有一种是KV 头数没有按 tp 均分，每卡都留了全量。
少数情况下是没开 paged kv cache，预分配按峰值算。
不容易想到的是，权重加载用了 fp32，先吃掉一半显存。
粗估一版 KV 需求
python -c "print(2*32*32*128*8192*256*2/2**30)"降 batch 并开分页缓存
trtllm-build --model_dir ./ckpt --max_batch_size 64 --enable_paged_kv_cache enable接着用 fp16 重新转换权重
python convert_checkpoint.py --model_dir llama3-8b --dtype float16 --tp_size 8 --output_dir ckpt等前面都确认过，再跑一次压测看峰值显存
python bench_trtllm.py --engine ./engine --concurrency 64手上没有现成的复现脚本，就照着线上请求手工拼了一个。
报错是间歇性的，我蹲守了半小时才抓到一次完整现场。
白天有业务在跑，能验证的部分都压到了晚上做。
当时还开着另一个排查窗口，两边日志对照着看才定位到。
怎么算真的好了，看的是同一批现象。build 通过，运行时 64 并发以下不 OOM，首 token 延迟与预估相差 10% 以内。
KV cache 的显存按并发乘上下文长度算，先算清楚再调 batch，比盲目减半有效。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。