一、核心认知：训练和推理，是两种完全不同的算力逻辑
每一条用户对话、每一段长文档问答，都会持续生成 KV 缓存，并发会话越多、上下文越长，显存占用呈线性上涨。很多项目在测试阶段流量小，看不出问题；一旦业务放量，KV Cache 瞬间占满显存，直接触发 OOM，服务中断。
大模型推理的瓶颈，从来不是算力 TFLOPS，而是显存容量与显存带宽。很多企业用高算力显卡搭建推理集群，最后被 KV Cache 卡死并发上限。
二、推理成本的隐形黑洞：流量波峰波谷带来的资源浪费
突发高并发场景，算力资源调度延迟，高峰期排队、响应延迟，直接影响用户体验；
单位 Token 定价在高并发场景单价上浮，业务放量后，账单会超出预期；
长上下文场景，KV Cache 不产生 Token 计费，但持续占用显存，这部分隐性资源消耗不会体现在账单上，很容易被低估。
适合业务稳定、需要持续对外提供服务的企业。弹性算力可以作为补充，只用来承接临时峰值流量，不做主力推理底座。
短期小流量 POC，Token 模式有优势；一旦业务进入稳定生产阶段，长期推理优先选择独占包卡作为基础算力，弹性算力只做削峰补充，混合架构才是成本最优解。
三、推理硬件选型：不要照搬训练的硬件标准
H200：超大 141GB HBM3e 显存，长上下文、70B 以上大模型高并发推理首选，足够容纳模型权重 + 海量 KV Cache；
昇腾 910C：128GB HBM3 显存，国产化私有化推理场景，适配政企合规项目；
RTX5090：仅适合测试、内部 Demo 推理。32GB 显存容量有限，并发上来极易爆显存，不建议作为线上生产推理主力。
四、落地架构建议：企业如何搭建低成本稳定推理集群
区分业务底座和峰值扩容：生产推理底座采用包月独占 GPU 集群，承载日常稳定流量；突发营销、临时活动的峰值流量，搭配弹性算力按需扩容。不要把全部业务压在弹性 Token 算力上。
模型量化优化先行：FP8、INT4 量化可以降低权重显存占用，提升单卡可承载并发，硬件选型和模型优化要同步规划，不能只靠堆卡解决并发。
预留 KV Cache 显存冗余：很多集群部署时，显存全部分配给模型权重，没有预留 KV Cache 空间，业务放量直接崩溃。推理集群规划，KV Cache 显存预留是硬性指标。
持续监控显存水位：推理集群运维核心指标不是 GPU 算力利用率，而是显存占用率，提前识别显存瓶颈，而不是等线上报错再处理。
