Kimi K3 完整权重开源后，一个比“模型有多强”更现实的问题迅速浮出水面：3T 参数、MXFP4 原生精度的模型，究竟需要多少硬件才能运行？最直观的计算是每个参数占 4 bit，因此仅权重就需要约 1.5TB。问题在于，推理系统装进去的不只是权重。
先把 1.5TB 算清楚
对于一个 3 万亿参数的模型，如果每个参数严格按 4 bit 存储，理论权重大小为：
3,000,000,000,000 × 4 bit ÷ 8 = 1,500,000,000,000 bytes
按十进制单位计算，这是 1.5TB；按操作系统常见的二进制单位计算，约为 1.36TiB。
这只是理论下限。实际模型文件还可能包含量化比例因子、分组元数据、张量对齐填充，以及未采用 4 bit 保存的嵌入层或输出层。框架加载模型时也可能生成额外缓冲区，甚至把部分权重临时转换为更高精度。
因此，“8 块 B200 的总显存刚好超过权重大小”只能说明容量账面上接近，并不等于模型可以稳定启动。只要权重分片不均、通信库预留显存，或者推理引擎需要工作区，部署就可能在加载阶段触发 OOM。把设备数量增加到 16 块，本质上是在为运行时状态、请求流量和工程余量买空间。
推理时还有哪些显存开销
大模型推理的显存占用通常可以粗略拆成四部分：
总显存 ≈ 权重 + KV Cache + 激活值与临时张量 + 运行时预留
KV Cache 与上下文长度、并发请求数、层数以及注意力结构有关。长上下文和高并发会持续放大这一项。即使模型使用混合专家结构，每个 token 只激活部分参数，完整权重通常仍要分布在设备内存中；“每次只用一部分参数”不代表其他专家可以免费消失。
激活值、量化解码缓冲区、矩阵乘工作区和跨卡通信缓冲区也需要空间。不同推理引擎的内存管理策略不同，所以不能只根据模型文件大小确定机器配置。
容量之外还要检查通信拓扑。3T 模型必然跨多张卡切分，张量并行、流水线并行和专家并行都会引入设备间传输。如果 GPU 之间缺少足够快的互联，系统即使能加载模型，也可能把大量时间耗在等待权重或中间结果上。
用脚本做第一轮容量估算
下面的 Python 脚本可以直接运行，用来计算理论权重大小和加入工程余量后的最低 GPU 数量。运行前可以修改参数规模、每参数位数、单卡显存和预留比例。
#!/usr/bin/env python3
import math
PARAMETERS = 3_000_000_000_000
BITS_PER_PARAMETER = 4
GPU_MEMORY_GB = 192
HEADROOM = 0.25 # 为 KV Cache、工作区、对齐和运行时预留 25%
weight_bytes = PARAMETERS * BITS_PER_PARAMETER / 8
weight_tb = weight_bytes / 1_000_000_000_000
weight_tib = weight_bytes / (1024 ** 4)
raw_gpu_count = math.ceil(weight_bytes / (GPU_MEMORY_GB * 1_000_000_000))
planned_bytes = weight_bytes * (1 + HEADROOM)
planned_gpu_count = math.ceil(
planned_bytes / (GPU_MEMORY_GB * 1_000_000_000)
)
print(f"理论权重大小: {weight_tb:.2f} TB / {weight_tib:.2f} TiB")
print(f"只装权重至少需要: {raw_gpu_count} 张 GPU")
print(f"预留 {HEADROOM:.0%} 后至少需要: {planned_gpu_count} 张 GPU")
print("注意：该结果未精确计算 KV Cache，也未验证并行切分约束。")
执行方式：
python3 estimate_memory.py
这个结果适合做采购前的第一轮筛选，却不能代替真实部署测试。生产规划还应分别计算目标上下文长度和并发量下的 KV Cache，并确认设备数量满足模型分片和并行度要求。理论结果是 10 张卡时，实际拓扑也未必允许随意配置 10 张，最终可能需要按 8、16 或其他完整节点规格扩展。
3TB 系统内存能不能跑
一台装有 3TB DDR5 的多路 CPU 服务器，从容量上看可能放得下 1.5TB 权重以及部分运行时数据。但“放得下”和“跑得动”是两项完全不同的指标。
CPU 内存方案面临的核心问题是带宽。自回归生成每个 token 时，需要读取大量权重。即使采用专家路由，只读取部分活跃参数，内存带宽仍会直接限制 token 生成速度。多路 NUMA 系统还会增加跨插槽访问成本；如果权重分配和线程绑定不合理，远端内存访问会进一步拖慢推理。
此外，MXFP4 能否在目标 CPU 上由推理框架原生、高效执行也很关键。如果框架需要先解包或转换成 BF16、FP16，内存占用和计算量都会增加。一个二手 CPU 服务器可能适合做权重检查、低频实验、离线批处理或验证模型能否加载，但不能仅凭内存容量推断它可以提供可接受的交互式速度。
如果考虑 CPU 或 CPU/GPU 混合卸载，可以先验证四个指标：
- 模型是否能在不转换成更高精度副本的情况下加载。
- 单请求、短上下文时的首 token 延迟和每秒 token 数。
- NUMA 绑定后，本地与跨插槽内存流量的差异。
- 增加上下文和并发后，KV Cache 是否挤占权重空间或触发交换。
采购之前，先定义“跑”的含义
对 3T 模型来说，硬件估算必须从服务目标倒推。只要求成功加载并生成一个 token，CPU 大内存服务器或激进卸载方案可能有实验价值；要求多人交互、长上下文和稳定延迟，则需要更大的 GPU 余量、更快的互联和经过验证的推理引擎。
实际落地时，可以按以下顺序推进：先读取模型配置与权重索引，确认真实文件大小和数据类型；再用目标引擎在小规模或单节点环境验证量化内核；随后测量不同上下文和并发下的峰值显存；最后依据节点拓扑决定并行策略和机器数量。
1.5TB 是计算的起点，不是采购答案。真正决定成本的，是模型实际存储格式、运行时额外内存、KV Cache 目标、设备互联，以及团队能够接受的生成速度。