模型部署如何做容量规划
在做模型部署时，除了看模型精度，还需要重点关注哪些容量相关指标，才能避免上线后资源不够或成本过高？
容量规划要先看业务与性能指标
容量规划通常要结合请求量、峰值并发、单次推理时延、吞吐量、模型大小、显存占用、CPU占用和存储需求一起评估。业务侧要明确日均请求量、峰值流量、可接受响应时间，以及是否存在批量推理场景。技术侧要测出模型在不同硬件上的QPS、延迟和资源消耗，再据此估算单实例可承载的请求量，进而推导需要多少实例、多少GPU或CPU资源。
如果我已经知道模型服务的大致访问量，怎样把访问量换算成机器数量，避免机器买少了影响服务，买多了又浪费预算？
用峰值流量和单机承载能力反推资源
可以先统计平均QPS、峰值QPS和流量波动区间，再在压测环境中测出单台机器或单个Pod的稳定承载上限。计算时要预留冗余，通常按峰值流量乘以安全系数，再除以单机可承载QPS，得到基础机器数。还要考虑扩缩容耗时、故障切换、节假日高峰等情况，避免资源只够理论值，实际遇到波动就出现排队或超时。
文本生成、分类、检索和多模态模型在部署时，容量规划思路会不会不一样？如果不一样，差别主要体现在哪些地方？
模型类型不同，资源瓶颈也不同
不同模型的容量规划重点差异很大。分类模型通常更关注高并发和低延迟，资源压力多在CPU或轻量GPU上；文本生成模型往往更吃显存和推理时延，长上下文会显著增加资源消耗；检索模型更关注向量库、存储和索引更新能力；多模态模型则需要同时评估图像预处理、显存占用和端到端时延。规划时应针对实际推理链路做压测，而不是只按模型参数量估算。
如果模型服务已经上线，发现高峰期资源紧张或响应变慢，扩容应该怎么做，才能尽量不影响线上用户体验？
通过弹性扩容和限流机制平滑过载
上线后出现容量紧张时，可以结合自动扩缩容、灰度扩容和流量调度来缓解压力。可以优先扩充副本数，必要时提升单实例规格，或者把部分低优先级请求转入异步队列。为了防止扩容期间服务被打满，还可以配置限流、超时、降级和缓存策略。扩容方案要提前在压测环境验证，确认扩容速度、冷启动时间和实例稳定性，避免高峰来临时资源还没到位。