问高并发短请求和长序列生成混跑时，推理服务的 KV Cache 与调度器该怎么设计才能互不拖后腿？

我们内部一个 LLM 网关同时接两类请求：

• 代码补全：7B 模型，峰值 500 QPS，p99 要压在 300ms 以内；
• 代码解释/生成：70B 模型，约 30 QPS，单次经常生成上千 token，对吞吐敏感。

两个模型都跑在 vLLM 的 continuous batching 上，遇到几个问题：

1. 补全请求短、条数多，生成请求序列长、token 多，混在一个调度队列里，短请求会不会被长序列的 decode 拖住，导致 p99 保不住？
2. 7B 和 70B 的 KV Cache 显存占用、max_seq_len 差异很大，共用显存池时，长序列会不会把短请求的 KV 挤爆？
3. 各业务线的 system prompt 高度相似，理论上 prefix cache 能省 KV，但跨模型的 prefix 不通用，值不值得专门设计？

我目前纠结三个方向：A 是两个模型各起独立实例按模型路由；B 是统一集群靠调度器做优先级 + 抢占；C 是小模型水平扩展、大模型单独部署，中间加队列削峰。

想请教下这种“高并发短请求 + 低并发长序列”混合场景，调度器和 KV Cache 管理更推荐哪种设计？优先级抢占会不会把生成请求饿死？prefix cache 跨模型场景实际收益大概多少？