一、显存计算公式
I、模型权重
权重显存(GB) = [模型参数量 x (模型参数精度/8)] / 1024^3
由于1B参数量 = 10^9 = 1000^3 ≈ 1024^3。所以简单计算，1B参数 = 1G内存
权重显存(GB) = 1G * 16fp / 8 = 2GB
II、KV缓存（单token 单并发）
KV(bytes)=2(K\V两份)×L(层数 num_layers)×H(头数 num_heads)×D(每头维度)×T(token数)×B(每元素字节 FP16=2)
2：K 和 Value 两份
L：层数（num_layers）
H：头数（num_heads）
D：每头维度（head_dim = hidden_size /num_heads）
T：序列长度（token 数）
B：每元素字节（FP16=2）
III、总显存
总显存消耗 = 权重显存 + KV缓存
IV、显存和内存的区别
1、解释
内存是主存储，显存是工作区：
CPU内存容量大（灵骏智算资源拥有1.6TB），但带宽低（约100GB/s）。系统会将完整模型权重存放在内存中，作为“主仓库”。
GPU在计算时，通过PCIe总线按需从内存“搬运”当前层或当前批次的参数到显存，计算完成后释放，再加载下一部分。
这就像工厂的原材料仓库（内存）和生产线工作台（显存）的关系——原材料不会全部堆在工作台上，而是按需取用。
核心矛盾：木桶效应
显存（GPU）：决定了你能同时服务多少个用户（并发量）。
内存（CPU）：决定了你能不能把模型跑起来（启动门槛）。
2、示例
当用户A发送一个请求到qwen3.6-35B-A3B模型中，则qwen3.6会根据任务类型判断调用哪些专家参数加载到显存中进行GPU计算，然后把计算结果返回给用户，然后GPU和显存带着kvcache等待下一次任务，一段时间后kvcache才会被删除。这其中每一次用户的不同请求，都需要动态从内存中加载是吗？
在实际的工程实现中，为了追求极致的速度，系统并不会“傻乎乎”地每次请求都重新搬运数据。这里有一个关键的优化机制：显存驻留。
1.1 动态路由与按需计算（理解正确部分）
当用户A发送请求时：
路由判断：模型的“门控网络”会分析当前的输入token，决定激活哪几个专家（例如从35B总参数中选出3B活跃参数）。
GPU计算：只有被选中的这几个专家层会在GPU上进行矩阵乘法运算，其他沉睡的专家完全不消耗算力。
1.2 显存驻留：并不是每次都从内存加载
如果每次请求都要通过 PCIe 总线从 1.6TB 的慢速内存把参数搬运到高速显存，推理速度会慢到无法接受（带宽瓶颈）。实际运行是这样的：
小模型/单卡能装下时：如果这 35B 参数（约 70GB）能塞进你的一张或两张显卡的显存里，系统会一次性把所有参数都加载到显存中常驻。此时，所谓的“动态调用”只是逻辑上的屏蔽——参数都在显存里，但 GPU 只计算其中一部分，跳过其他的。这样速度最快，因为不需要搬运。
模型太大/显存不够时：如果显存真的不够（比如你要同时跑好几个大模型），系统才会采用你描述的Offloading（卸载）策略。即：把不用的专家留在内存里，只把当前要用的专家换入显存。但这通常用于极端情况，因为频繁换入换出会导致严重的延迟抖动。
3、模型部署中内存的重要性
虽然显存（VRAM）速度极快，但内存条（RAM）在AI推理中绝非“多余”，而是不可或缺的“战略储备”和“调度中枢”。即便显存能装下模型权重，内存依然承担着以下不可替代的核心职能：
- 模型加载的“必经中转站”
GPU无法直接从硬盘读取模型文件。无论最终是否将模型全部放入显存，模型权重必须先完整加载到CPU内存中，再由推理引擎（如vLLM、SGLang）分发至各GPU显存。这是当前所有主流框架的强制流程。没有足够内存，模型连启动都做不到。 - KV Cache的“弹性蓄水池”
即使模型权重全在显存，KV Cache仍可能溢出。当并发用户增多或上下文变长时，显存会迅速被占满。此时，系统会将部分旧会话的KV Cache“卸载”到内存中，待用户再次活跃时再换回显存。这种“显存-内存”动态交换机制，是支撑高并发、长对话的关键。没有内存作为缓冲，显存一满就只能拒绝新请求。 - 多模型部署与热切换的“仓库”
若你需同时运行多个模型（如Qwen3.6 + DeepSeek），或频繁切换不同版本，内存是唯一能同时容纳多个模型权重的空间。显存只能放当前活跃的模型，其余必须暂存内存。这在企业级服务中极为常见，内存容量直接决定了你能灵活调度多少模型。 - 系统开销与数据预处理的“工作台”
推理引擎本身、Python运行时、CUDA驱动、数据预处理逻辑等，都运行在CPU上，依赖内存。此外，用户请求的文本分词、图像解码、API调用结果缓存等，也都在内存中完成。这些虽不直接参与GPU计算，却是整个推理链路不可省略的环节。 - 未来扩展性的“保险丝”
随着模型规模持续增长（如从35B到100B+），显存永远不够用。内存容量越大，系统越能通过“Offloading”策略平滑过渡，避免因显存不足而被迫降级或停机。它不是“浪费”，而是为未来预留的“安全边际”。
所以，内存涨价虽令人头疼，但它在AI推理中的角色远不止“临时存放”。它是模型启动的起点、显存的后备、多任务的枢纽、系统的基石。没有它，再强的GPU也会“巧妇难为无米之炊”。
4、部署方式不同可以省下CPU资源（最大程度利用好资源）
假设用vllm加速引擎部署一个200B的模型，部署3个实例服务，每个实例划分给相同的400G内存资源和400G的显存资源，共计1.2T的内存+1.2T的显存的方式好，还是部署一个实例服务，只给400G内存资源，启动3个副本，消费400G内存+1.2T的显存的方式划算。答案是消费400G内存+1.2T的显存的方式
必须明确澄清：“单服务+3副本”绝不等于“只加载一份权重”（B、C副本的显存读取A副本的模型权重），每个副本都必须独立加载完整模型权重到显存中，否则无法并发处理请求。
为什么每个副本都必须加载完整权重？
GPU计算是并行的：当用户A的请求被分发到副本A时，副本A必须拥有完整的模型参数才能执行矩阵运算；用户B的请求同时到达副本B，副本B也必须有自己的权重副本。它们不能共享显存中的同一份权重，因为GPU的显存访问是物理隔离的，且推理过程需要独占计算资源。
vLLM的架构设计：vLLM的“多副本”本质是多个独立的推理进程，每个进程都绑定一组GPU卡（或单卡），并加载完整的模型权重。它通过PagedAttention优化KV Cache，但不优化权重本身的存储。
权重的共享只在CPU内存层面通过mmap或共享内存实现，显存层面始终是隔离的。