一、项目背景

我们给一家金融机构做私有化大模型底座时，第一个被卡死的就是显存。他们采购的推理卡单卡显存有限，初版直接用朴素自研推理服务，并发一上到两位数就 OOM，长上下文（合同、研报动辄上万 token）场景更是秒崩。单卡吞吐低到业务方抱怨"比人还慢"，而加卡意味着成本翻倍。我们当时定的目标很硬：在不动硬件的前提下，把单卡有效并发和吞吐翻上去，长上下文也能稳。

二、落地场景

核心落在推理引擎的显存与调度优化上。我们引入了 PagedAttention 式的显存分页管理，把 KV 缓存按块分配而非预占整段，碎片大幅降低；连续批处理（continuous batching）替代固定 batch，让长短请求混跑时 GPU 不空转；KV 缓存做 FP8 或 INT8 量化进一步省显存；再配合动态批大小和长上下文抢占回收，把有限的显存"榨"到极致。

三、关键技术挑战与解决思路

第一个挑战是显存分页与碎片。传统实现给每个请求预占 max_seq_len 的 KV 空间，长上下文请求一来就占满。分页后按 16 或 32 token 的 block 动态分配，显存利用率从约 40% 提到 80% 以上。

案例片段（已脱敏）： 连续批处理配置（示意）： scheduler:  policy: "continuous"  max_num_seqs: 256  max_num_batched_tokens: 8192  block_size: 16  kv_cache_dtype: "fp8_e5m2"  gpu_memory_utilization: 0.90

观测：单卡并发从约 24 提升到约 110，P99 延迟 1.8s 到 2.3s 可接受

第二个挑战是连续批处理的调度公平与尾延迟。短请求别被长请求饿死，我们设了 token-budget 调度，每步累积 token 数到上限就切步，保证小请求快速返回。

第三个挑战是 KV 缓存量化精度。FP8 量化后长文本偶有 attention 漂移，我们用关键层保留 FP16 加其余 FP8 的混合策略，精度损失控制在可接受区间。

第四个挑战是长上下文抢占。显存真不够时，按优先级抢占低优请求并把其 KV 换出，腾出空间给高优，被抢占的请求稍后重建，而不是直接失败。

四、效果数据

优化后单卡有效并发从约 24 提升到 110 以上；显存利用率稳定在 85% 到 90%；P99 延迟在混合负载下约 2.3 秒（原长上下文场景常超时失败）；单位 token 推理成本下降约 58%。原来需要 8 卡扛的峰值，现 4 卡即可，年度算力开支显著下降。

五、可复用经验总结

第一，显存优化顺序是"先分页、再批处理、后量化"，每一步都建立在前面基础上，别跳步。

第二，连续批处理要配套 token-budget 调度，否则长请求拖垮短请求体验。

第三，KV 量化用混合精度比全量量化稳，关键层保 FP16 是性价比最高的保险。

第四，长上下文必须有抢占回收兜底，否则显存峰值就是稳定性天花板。

六、工程落地补充与踩坑记录

显存优化上线前后，有几处细节值得单独说。第一个是抢占回收的边界设定。我们一开始把抢占阈值设得很激进，结果长上下文请求频繁被换出重建，尾延迟反而变差。后来改成显存占用超过九成且新请求优先级高才触发，并把被抢占请求的重建做成异步，用户体验才平滑。

第二个是量化精度的回归。KV 缓存量化到 FP8 后，我们在内部评测集上跑了长文本摘要和合同抽取两类任务，发现摘要偶尔丢细节。排查是某些注意力头对量化敏感，于是把这些头保留 FP16，其余量化，精度基本无损而显存照省。这个分层量化的策略后来成了我们的默认配置。

第三是监控的可观测性。优化后我们加了显存分块利用率、批大小分布、抢占次数三个看板指标，运维一眼能看出是不是又到了调度拐点。没有这些指标，显存优化就是黑盒调参，出问题无从定位。

再说成本口径。单位 token 成本下降约六成，但财务更关心总账。我们把优化前后的峰值卡数对比做成季度报告，四卡顶八卡这件事直接写进了下一年的算力采购预算，技术优化的价值才算真正被算清。

最后是长上下文的边界治理。我们给单次请求的上下文长度设了硬性上限并配合流式分块处理，既防止个别超长请求拖垮整卡，也给业务方一个清晰的预期。稳定性不是靠祈祷，而是靠把每个异常路径都先想清楚再放出去。

七、给同行的一点提醒

回顾大模型推理显存优化这个项目，最容易被低估的是最后一公里。技术方案跑通只是开头，真正决定成败的是上线后那几周：显存看板有没有覆盖调度拐点、抢占有没有误伤长请求、量化有没有在评测集上回归。我们见过太多项目栽在上线即交付的心态上，三个月后指标悄悄回潮。所以我们的做法一直是把上线当运营起点：分块利用率看板、量化精度回归、容量压测、自动化巡检，四件套缺一不可。另一个体会是，显存优化顺序不能跳，先分页再批处理后量化，顺序错了收益会被后面的瓶颈吞掉。以上是我们的一点体会，供同样做私有化推理优化的团队参考。

八、一点收尾说明

显存优化没有终点，业务模型在持续迭代、上下文也在变长，我们的看板和回归脚本会跟着业务一起调。保持对调度拐点的敏感，比追求一次调到最优更重要。技术债务要定期还，显存水位也是一样，月初看一眼曲线，就知道这月要不要再优化一轮。