NVIDIA把“AI工厂AI Factory”这个词从概念变成真实产品之后业内一直在等第一批实地数据。这次公开的信息里有三个数字足够让做推理架构的人睡不着整厂功耗100MW、推理算力2ZFLOPS、单机DeepSeek推理吞吐量“暴增”到原来的30倍。很多人看到2ZFLOPS觉得是又一轮军备竞赛但我更关心的是后面那个30倍——它真正暴露了DeepSeek这类MoE大模型在英伟达新机柜上吃到了什么红利以及过去一年里我们在显存池化、KV Cache和FP4量化上做的所有优化终于有了一个能落进数据中心机房的完整答案。这篇文章不打算复述发布会PPT我想从工程角度把这三组数据拆开2ZFLOPS怎么算出来的100MW到底喂给了哪些模块单机30倍吞吐量背后动的是哪些卡脖子环节以及对我们这些做推理部署、做模型服务、甚至只是本地跑DeepSeek的人有什么能直接抄作业的启示。1. 2ZFLOPS与100MW的工程换算一个机柜里到底发生了什么1.1 从单卡到AI工厂NVL72机柜的算力密度先说这2ZFLOPS。ZFLOPS是10的21次方次浮点运算每秒2ZFLOPS就是2×10²¹ FLOPS。这个数字放在半年前大多数人会觉得是“理论峰值”层面的乐观包装但这次英伟达给的是推理侧的可服务算力不是训练跑分意义完全不同。怎么把这么大规模的数字落到实处理解关键在机柜。DGX GB200 NVL72这类整机柜设计单个机柜里放72块Blackwell架构GPU、36颗Grace CPU通过第五代NVLink把GPU两两之间的互联带宽拉到900GB/s量级HBM总容量能达到144TB左右。这个机柜在FP4精度下推理算力大约能摸到1.4 exaFLOPS1.4×10¹⁸ FLOPS级别。那2ZFLOPS需要多少机柜简单除一下2000除以1.4大约1400到1500个NVL72机柜。再乘上单机柜功耗60到70kW总数正好落在90到105MW区间。所以“100MW、2ZFLOPS”不是两个孤立的展示参数它们互为验证——一个完整的AI工厂规模大概就是上千个高密度液冷机柜的体量。这种整机柜思路和过去堆8卡GPU服务器的逻辑完全不同。8卡A100服务器跑大模型推理瓶颈通常不在算力而在显存带宽和跨节点通信。GPU算得快但模型参数拿不过来KV Cache放不下计算单元大量空转。NVL72把72块GPU放进同一个NVLink域等于把过去一个“机房集群”的通信能力压缩进一个机柜这是后续所有吞吐量倍增故事的物理前提。1.2 2ZFLOPS是服务能力不是跑分还有一个容易被忽略的点这2ZFLOPS是推理算力。推理和训练负载特征差异极大。训练是高强度持续计算GPU利用率可以长时间顶着跑推理是间歇性、延迟敏感、并发密集的负载每个请求的输入长度、输出长度、并发用户数都在跳动。所以在推理场景下算力数字本身的价值有限真正决定用户体验的是“能在多低的延迟下支撑多大并发”。这时候显存容量和显存带宽往往比GPU峰值算力更先触顶。举个例子DeepSeek R1这类推理模型单次请求要经历大规模预填充prefill阶段和逐token生成decode阶段。预填充吃算力decode阶段吃显存带宽两者对硬件资源的需求模型完全不同。传统8卡服务器里显存被物理隔离算力和显存无法跨节点动态调配并发一高就卡在资源孤岛上。NVL72的显存池化能力等于把144TB显存变成一台“显存交换机”谁缺就给谁补。2ZFLOPS如果只看计算峰值大概相当于几万张消费级显卡的算力叠加但把它和100MW、上千机柜放在一起看它强调的其实是“可持续、低延迟、高并发”的规模化推理服务能力。这是从“能算”到“能服务”的质变。1.3 100MW功耗都去哪了100MW是什么概念一个普通城市核心区的商业用电负荷也就这个量级。这笔电费即便按0.5元一度算满负荷运行一年也接近4.4亿元。所以功耗拆分不是锦上添花是AI工厂能不能长期运转的命门。从工程经验看100MW大致按这样分配GPU和HBM本身是最大的耗电主体约占70%到75%也就是70到75MW。这一块在Blackwell架构上主要通过FP4/FP8低精度计算和更细粒度的电源门控来压低。Grace CPU负责数据搬运和通信约占5%。NVLink交换、网卡、NVMe存储和其余系统部件大约占10%到15%。最后还有制冷和供电损耗——液冷方案能把这个环节压到总功耗的8%以下如果还用风冷光风扇和精密空调就能吃掉15%以上。这也是为什么NVL72明确标配液冷。过去我们在机房部署8卡服务器风冷就够了但单机柜60kW以上的热密度风冷已经物理上无法解决。液冷板直触GPU、CDU冷量分配单元循环、室外冷却塔散热这套系统是AI工厂能稳定跑满100MW的前提。2. DeepSeek为什么是这次优化最大的受益者MoE架构的特性和英伟达的优化方向完全咬合2.1 稀疏激活推理时其实只用了小部分参数DeepSeek V3/R1采用MoE混合专家架构公开参数上说是671B总参数但每个token推理时只会激活约37B参数。这是个极其关键的特性。MoE模型的工作原理可以类比一家大型综合医院医院有几百个科室专家模块但一个病人来看病只需要对应几个科室会诊不可能全院所有医生都围着你转。DeepSeek有256个专家每次只选8个最相关的专家激活剩下的专家虽然加载在显存里但不参与计算。这对推理硬件的意义在于决定显存容量的是总参数671B决定计算量的却是激活参数37B。这个“总参数大、激活参数小”的结构天然吃显存池化和高带宽显存而不是无限追求GPU算力。英伟达在NVL72里做的FP4量化、显存池化、专家并行几乎每一项都在放大这个结构优势。2.2 KV Cache显存池化长上下文推理的胜负手MoE模型还有一个痛点KV Cache。生成每个token都要把历史的Key和Value缓存下来序列越长缓存占用越大。DeepSeek的多头注意力用的是MLAMulti-head Latent Attention结构核心目的就是压缩KV Cache——把显存占用从O(序列长度×头数×头维度)降到一个更小的潜空间。这一手对NVL72的意义特别大。单机柜144TB显存如果KV Cache被压缩到只有传统MHA架构的十分之一甚至更低那么同一份显存能同时服务的并发请求数就大幅上升。过去一个长上下文请求可能吃掉一整张卡80GB显存现在同样的空间能塞下更多请求。在NVL72的池化显存里KV Cache不再固定在某一张卡的显存里而是可以在机柜内动态调度。调度器看到哪些卡有空闲显存就把新的请求分配过去。配合DeepSeek自身的MLA低缓存占用整套系统在长上下文场景下的并发能力提升非常显著。2.3 量化余量与FP4精度牺牲换来3倍显存收益英伟达这次发布里明确强调FP4推理优化。FP4是4比特浮点相比FP8理论上显存占用再减半计算吞吐还能再上一个台阶。但FP4最大的风险是精度损失——如果模型结构对量化不友好用FP4跑推理输出质量会明显劣化甚至出现胡言乱语。DeepSeek在FP4上的优势在于训练阶段就做了大量精度冗余设计。DeepSeek在训练时就用了FP8混合精度权重分布相对规整极端离群值少这给后训练量化提供了很好的“底子”。叠加英伟达TensorRT-LLM里针对DeepSeek的FP4 kernel优化模型权重从FP8压到FP4显存占用、带宽压力、计算量三个维度同时下降这是吞吐量能大幅上涨的数学基础。我个人的实测经验是类似的量化优化在小规模模型上提升不明显但在几百B参数的MoE模型上FP4的效果是颠覆性的——因为显存带宽的瓶颈直接松绑了。3. 单机30倍吞吐量提升背后一个完整的协作系统3.1 显存池化从算力孤岛到算力池“单机30倍吞吐量”是这次新闻里最抓眼球的数据也是最容易被误读的。它不是指单张显卡变快了30倍而是指一个NVL72整机柜系统在跑DeepSeek部署时整体可服务的token吞吐量是上一代方案的30倍。其中最核心的变量是显存池化。传统8卡A100/H100服务器显存是物理隔离的每张卡上的模型分片和KV Cache无法跨卡灵活调度一张卡的显存满了另一张卡再空也帮不上忙。这就是“算力孤岛”。NVL72的NVLink域把72块GPU的显存变成统一寻址的资源池。推理引擎加载DeepSeek时专家模块可以打散放在池子各处KV Cache挂载到池子里任意空闲位置。调度器按请求动态分配资源GPU空闲算力也能更充分地被利用。这一条对MoE这种“总参数大、激活参数小”的模型尤为关键——因为671B的总参数要装得下而每一次请求又只需要快速触碰一部分。3.2 通信不再是瓶颈NVLink域和CX8网卡的关系上一代方案里跨节点通信是最大的延迟来源。DeepSeek这类MoE模型的专家并行天然需要频繁把所有节点的部分输出做全局聚合。如果走RoCE或InfiniBand网卡单次通信延迟在微秒级叠加吞吐量根本提不起来。NVLink域把这个问题压到了近乎零。机柜内72块GPU通过NVLink Switch互联形成一个带宽极高的扁平网络跨机柜再走CX8网卡800G级别和ScaleUP/ScaleOut网络。这种“大域内、小跨域”的通信架构让MoE模型最怕的All-to-All通信多了好几条车道。这也是为什么NVL72不是简单堆GPU而是重新设计了整机计算拓扑。光有一颗强心脏不够还得保证全身血管畅通。3.3 软件栈更新CUDA 13/ cu130、TensorRT-LLM与DeepSeek harness硬件之外软件栈这次的动作同样大。NVIDIA发布的CUDA 13对应cu130更新里重点优化的内容之一就是Blackwell架构下的FP4原语和MoE模型调度原语。TensorRT-LLM也针对性补了DeepSeek R1的MLA算子让Attention部分不再走通用kernel而是走专门针对MLA结构优化的高速路径。这些软件优化对部署者的影响是直接的。过去在vLLM或SGLang里跑DeepSeek很多算子还是通用实现显存带宽利用率和计算单元利用率都远没有到极限。换用适配新硬件的推理后端后同样的模型同样的硬件吞吐量可能直接翻倍甚至更多。我还注意到圈子里开始流行叫“DeepSeek harness”的工具链——它在NVIDIA的SampleFabric、TensorRT-LLM、FastAPI之间做编排生成生产级的推理工作流。虽然不是官方提供的一键工具但它的思路很值得借鉴把模型部署变成一串可复现、可观测、可回滚的流水线而不是每次都在命令行里手工敲参数。4. 从100MW到我们的服务器普通团队到底能蹭到什么4.1 不自建工厂最划算的是直接把DeepSeek当API用说句实话100MW的AI工厂和我们绝大多数团队没有任何直接关系——自建几座NVL72机柜的资本开支和运维难度不是普通创业公司能碰的。但普通团队仍然能从整条产业链里吃到两波红利。第一波是模型厂商直接把优化后的推理能力封装成API。DeepSeek官方API的输入输出价格就已经压在很低的位置现在英伟达这边的推理吞吐量上去了、单位token成本降下来API的性价比大概率还会进一步变好。很多团队的明智选择是先直接用API不碰自建基础设施。等体量真的大到API费用变成核心成本再考虑研究私有化部署。4.2 中端卡集群方案H20/H800级别上的落地方案如果有合规和私有化要求必须自行部署也不必追求NVL72。对中小团队来说H20/H800集群配TensorRT-LLM或SGLang依然能吃到相当一部分优化红利。核心是把握好这几个工程原则模型并行切分时优先保证显存池化程度高的方案把KV Cache和专家模块分散放置避免某张卡显存被打满而其他卡闲置。推理引擎优先选带FP8/INT8量化支持且对MoE调度做过适配的版本例如SGLang的DeepSeek专用分支或TensorRT-LLM新版本。首token延迟和吞吐量要分开调优。prefill阶段的并发度、decode阶段的连续批量大小很多参数是冲突的需要按自己的业务请求特点做针对性压测。还有一个实操点如果显存有限部署DeepSeek R1的蒸馏小模型如32B也是不错的选择。总参数变小之后显存池化的收益下降但对硬件门槛的要求也同时下降单卡A100/H100甚至单张4090都能跑成本模型完全不同。4.3 DeepSeek harness类工具怎么本地搭很多人在GitHub上搜到“deepseek harness”之后不知道怎么在本地验证。这里给一套相对通用的流程参考了社区里常见的做法第一步准备环境。需要一台至少24GB显存的GPU服务器32B蒸馏模型系统装好CUDA 12.4以上版本、Python 3.10、PyTorch 2.1。第二步安装vLLM或SGLang。以vLLM为例安装后加载模型pip install vllm python -m vllm.entrypoints.openai.api_server \ --model deepseek-ai/DeepSeek-R1-Distill-Qwen-32B \ --tensor-parallel-size 2 \ --max-model-len 32768 \ --gpu-memory-utilization 0.9第三步写一个并发压测脚本测吞吐量。用aiohttp发异步请求统计每秒完成的token数import asyncio, aiohttp, time async def one_call(session, prompt): async with session.post( http://localhost:8000/v1/completions, json{model: deepseek-ai/DeepSeek-R1-Distill-Qwen-32B, prompt: prompt, max_tokens: 512} ) as resp: data await resp.json() return len(data[choices][0][text].split()) async def main(): prompts [给我讲一个关于数据中心的故事] * 64 async with aiohttp.ClientSession() as session: t0 time.time() results await asyncio.gather(*[one_call(session, p) for p in prompts]) total_tokens sum(results) dt time.time() - t0 print(ftotal tokens: {total_tokens}, elapsed: {dt:.2f}s, throughput: {total_tokens/dt:.2f} token/s) asyncio.run(main())这个脚本能帮你量化对比不同后端、不同量化精度参数下的真实吞吐量比看官方吹的数字直观得多。第四步用容器封装整个推理服务。社区里的harness工具本质上是把模型加载、推理服务、监控告警打包成标准流水线。自己用Docker Compose也能拼一个简化版services: inference: image: vllm/vllm-openai:latest command: [--model, deepseek-ai/DeepSeek-R1-Distill-Qwen-32B, --port, 8000] ports: - 8000:8000 deploy: resources: reservations: devices: - driver: nvidia count: 2 capabilities: [gpu]实测下来这类容器化部署在H20集群上比裸进程更稳定重启和扩缩容都从容很多。5. 工程现实散热、供电、网络、可靠性——AI工厂的四大暗礁5.1 液冷不是可选项是必需品单机柜60kW以上的热密度风冷已经完全失效。我见过不少团队在规划部署时把液冷当成“锦上添花”结果实测GPU因为温度保护降频吞吐量比标称低了20%以上。液冷方案需要关注三个参数冷却液入口温度一般15到40摄氏度可调、CDU的换热能力、管路的冗余设计。NVL72机柜的液冷接口直接落在背板上数据中心要提前铺好管路否则“买得起机柜、供不上冷量”是真正的尴尬。5.2 供电从UPS到柴发的整个链路都要重算100MW的数据中心即使在工业园区级别也属于“巨无霸”负荷。从10kV或35kV高压进线到中压配电、UPS、PDU、机柜母线每一层都需要按N1或2N冗余设计。单机柜功耗60kW意味着普通数据中心的16A/32A插座完全派不上用场机柜母线必须支持到数百安培级别。对没有园区级供电条件的团队一个务实建议是先把供电容量按目标算力需求的1.5倍规划为未来扩展留余量。电力系统的改造周期通常以月为单位等业务起来再扩电会卡住整个项目。5.3 网络从InfiniBand到CX8网卡跨柜通信的取舍AI工厂的网络不是“能用就行”而是直接决定大模型训练和推理的成功率。英伟达方案里CX8网卡提供了800G级别的端口配合ScaleUP/ScaleOut分层设计意图很清楚让机柜内的流量尽量留在NVLink域让跨机柜流量走专门的高带宽通道。实际运营中容易踩的坑是把所有流量都丢在同一张网络上推理请求的延迟抖动会直接影响线上服务的稳定性。更合理的做法是控制面和数据面分离推理流量走专用VLAN或物理网络监控、日志、模型加载走管理网络避免相互挤占。5.4 可靠性设计单点故障不能拖垮整柜整机柜的摩尔定律级算力密度反过来意味着故障爆炸半径也变大了。一个NVLink交换芯片故障可能影响几十块GPU之间的通信。生产级部署里必须做到故障预案前置模型要能快速热迁移、请求要能优雅降级、故障检测要在秒级触发。我见过有团队在测试环境里全链路跑通结果一上线遇到单卡故障整个推理服务挂了十分钟才恢复。后来加上健康检查和请求重试机制单卡故障的影响缩小到只影响个位数比例的请求。这个经验值得所有人借鉴测试环境一定要做“故障演练”把最坏情况暴露在可控环境里。写在最后一些经验之谈做了一段时间AI基础设施相关的工作我最大的感受是英伟达这套“AI工厂”思路的真正门槛不在芯片设计而在系统工程。从芯片到机柜到数据中心到软件栈每一层都在互相咬合想单点突破非常难。对普通团队而言与其盯着100MW、2ZFLOPS这样的远距离数字焦虑不如关注两个更贴近自己的问题一是API调用成本会继续下降能更便宜地用上顶级模型二是开源推理引擎和工具链正在快速迭代我们自己部署开源模型的性价比也在持续提升。最后分享一个实操心得不管用什么硬件跑DeepSeek先别急着上优化全家桶。先用默认配置搭一套忠实服务的推理环境把业务链路跑通再逐项开量化、开显存池化、调连续批处理参数每做一步都做一次A/B对比。这样你才能清楚地知道每一步优化到底带来了多少收益而不是被一堆“优化过的数字”裹挟着加码硬件。算力行业靠数字驱动但真正的工程判断力永远来自你亲手测过的那些真实负载。 NVIDIA AI工厂：100MW、2ZFLOPS与DeepSeek30倍吞吐的工程解码
NVIDIA把“AI工厂AI Factory”这个词从概念变成真实产品之后业内一直在等第一批实地数据。这次公开的信息里有三个数字足够让做推理架构的人睡不着整厂功耗100MW、推理算力2ZFLOPS、单机DeepSeek推理吞吐量“暴增”到原来的30倍。很多人看到2ZFLOPS觉得是又一轮军备竞赛但我更关心的是后面那个30倍——它真正暴露了DeepSeek这类MoE大模型在英伟达新机柜上吃到了什么红利以及过去一年里我们在显存池化、KV Cache和FP4量化上做的所有优化终于有了一个能落进数据中心机房的完整答案。这篇文章不打算复述发布会PPT我想从工程角度把这三组数据拆开2ZFLOPS怎么算出来的100MW到底喂给了哪些模块单机30倍吞吐量背后动的是哪些卡脖子环节以及对我们这些做推理部署、做模型服务、甚至只是本地跑DeepSeek的人有什么能直接抄作业的启示。1. 2ZFLOPS与100MW的工程换算一个机柜里到底发生了什么1.1 从单卡到AI工厂NVL72机柜的算力密度先说这2ZFLOPS。ZFLOPS是10的21次方次浮点运算每秒2ZFLOPS就是2×10²¹ FLOPS。这个数字放在半年前大多数人会觉得是“理论峰值”层面的乐观包装但这次英伟达给的是推理侧的可服务算力不是训练跑分意义完全不同。怎么把这么大规模的数字落到实处理解关键在机柜。DGX GB200 NVL72这类整机柜设计单个机柜里放72块Blackwell架构GPU、36颗Grace CPU通过第五代NVLink把GPU两两之间的互联带宽拉到900GB/s量级HBM总容量能达到144TB左右。这个机柜在FP4精度下推理算力大约能摸到1.4 exaFLOPS1.4×10¹⁸ FLOPS级别。那2ZFLOPS需要多少机柜简单除一下2000除以1.4大约1400到1500个NVL72机柜。再乘上单机柜功耗60到70kW总数正好落在90到105MW区间。所以“100MW、2ZFLOPS”不是两个孤立的展示参数它们互为验证——一个完整的AI工厂规模大概就是上千个高密度液冷机柜的体量。这种整机柜思路和过去堆8卡GPU服务器的逻辑完全不同。8卡A100服务器跑大模型推理瓶颈通常不在算力而在显存带宽和跨节点通信。GPU算得快但模型参数拿不过来KV Cache放不下计算单元大量空转。NVL72把72块GPU放进同一个NVLink域等于把过去一个“机房集群”的通信能力压缩进一个机柜这是后续所有吞吐量倍增故事的物理前提。1.2 2ZFLOPS是服务能力不是跑分还有一个容易被忽略的点这2ZFLOPS是推理算力。推理和训练负载特征差异极大。训练是高强度持续计算GPU利用率可以长时间顶着跑推理是间歇性、延迟敏感、并发密集的负载每个请求的输入长度、输出长度、并发用户数都在跳动。所以在推理场景下算力数字本身的价值有限真正决定用户体验的是“能在多低的延迟下支撑多大并发”。这时候显存容量和显存带宽往往比GPU峰值算力更先触顶。举个例子DeepSeek R1这类推理模型单次请求要经历大规模预填充prefill阶段和逐token生成decode阶段。预填充吃算力decode阶段吃显存带宽两者对硬件资源的需求模型完全不同。传统8卡服务器里显存被物理隔离算力和显存无法跨节点动态调配并发一高就卡在资源孤岛上。NVL72的显存池化能力等于把144TB显存变成一台“显存交换机”谁缺就给谁补。2ZFLOPS如果只看计算峰值大概相当于几万张消费级显卡的算力叠加但把它和100MW、上千机柜放在一起看它强调的其实是“可持续、低延迟、高并发”的规模化推理服务能力。这是从“能算”到“能服务”的质变。1.3 100MW功耗都去哪了100MW是什么概念一个普通城市核心区的商业用电负荷也就这个量级。这笔电费即便按0.5元一度算满负荷运行一年也接近4.4亿元。所以功耗拆分不是锦上添花是AI工厂能不能长期运转的命门。从工程经验看100MW大致按这样分配GPU和HBM本身是最大的耗电主体约占70%到75%也就是70到75MW。这一块在Blackwell架构上主要通过FP4/FP8低精度计算和更细粒度的电源门控来压低。Grace CPU负责数据搬运和通信约占5%。NVLink交换、网卡、NVMe存储和其余系统部件大约占10%到15%。最后还有制冷和供电损耗——液冷方案能把这个环节压到总功耗的8%以下如果还用风冷光风扇和精密空调就能吃掉15%以上。这也是为什么NVL72明确标配液冷。过去我们在机房部署8卡服务器风冷就够了但单机柜60kW以上的热密度风冷已经物理上无法解决。液冷板直触GPU、CDU冷量分配单元循环、室外冷却塔散热这套系统是AI工厂能稳定跑满100MW的前提。2. DeepSeek为什么是这次优化最大的受益者MoE架构的特性和英伟达的优化方向完全咬合2.1 稀疏激活推理时其实只用了小部分参数DeepSeek V3/R1采用MoE混合专家架构公开参数上说是671B总参数但每个token推理时只会激活约37B参数。这是个极其关键的特性。MoE模型的工作原理可以类比一家大型综合医院医院有几百个科室专家模块但一个病人来看病只需要对应几个科室会诊不可能全院所有医生都围着你转。DeepSeek有256个专家每次只选8个最相关的专家激活剩下的专家虽然加载在显存里但不参与计算。这对推理硬件的意义在于决定显存容量的是总参数671B决定计算量的却是激活参数37B。这个“总参数大、激活参数小”的结构天然吃显存池化和高带宽显存而不是无限追求GPU算力。英伟达在NVL72里做的FP4量化、显存池化、专家并行几乎每一项都在放大这个结构优势。2.2 KV Cache显存池化长上下文推理的胜负手MoE模型还有一个痛点KV Cache。生成每个token都要把历史的Key和Value缓存下来序列越长缓存占用越大。DeepSeek的多头注意力用的是MLAMulti-head Latent Attention结构核心目的就是压缩KV Cache——把显存占用从O(序列长度×头数×头维度)降到一个更小的潜空间。这一手对NVL72的意义特别大。单机柜144TB显存如果KV Cache被压缩到只有传统MHA架构的十分之一甚至更低那么同一份显存能同时服务的并发请求数就大幅上升。过去一个长上下文请求可能吃掉一整张卡80GB显存现在同样的空间能塞下更多请求。在NVL72的池化显存里KV Cache不再固定在某一张卡的显存里而是可以在机柜内动态调度。调度器看到哪些卡有空闲显存就把新的请求分配过去。配合DeepSeek自身的MLA低缓存占用整套系统在长上下文场景下的并发能力提升非常显著。2.3 量化余量与FP4精度牺牲换来3倍显存收益英伟达这次发布里明确强调FP4推理优化。FP4是4比特浮点相比FP8理论上显存占用再减半计算吞吐还能再上一个台阶。但FP4最大的风险是精度损失——如果模型结构对量化不友好用FP4跑推理输出质量会明显劣化甚至出现胡言乱语。DeepSeek在FP4上的优势在于训练阶段就做了大量精度冗余设计。DeepSeek在训练时就用了FP8混合精度权重分布相对规整极端离群值少这给后训练量化提供了很好的“底子”。叠加英伟达TensorRT-LLM里针对DeepSeek的FP4 kernel优化模型权重从FP8压到FP4显存占用、带宽压力、计算量三个维度同时下降这是吞吐量能大幅上涨的数学基础。我个人的实测经验是类似的量化优化在小规模模型上提升不明显但在几百B参数的MoE模型上FP4的效果是颠覆性的——因为显存带宽的瓶颈直接松绑了。3. 单机30倍吞吐量提升背后一个完整的协作系统3.1 显存池化从算力孤岛到算力池“单机30倍吞吐量”是这次新闻里最抓眼球的数据也是最容易被误读的。它不是指单张显卡变快了30倍而是指一个NVL72整机柜系统在跑DeepSeek部署时整体可服务的token吞吐量是上一代方案的30倍。其中最核心的变量是显存池化。传统8卡A100/H100服务器显存是物理隔离的每张卡上的模型分片和KV Cache无法跨卡灵活调度一张卡的显存满了另一张卡再空也帮不上忙。这就是“算力孤岛”。NVL72的NVLink域把72块GPU的显存变成统一寻址的资源池。推理引擎加载DeepSeek时专家模块可以打散放在池子各处KV Cache挂载到池子里任意空闲位置。调度器按请求动态分配资源GPU空闲算力也能更充分地被利用。这一条对MoE这种“总参数大、激活参数小”的模型尤为关键——因为671B的总参数要装得下而每一次请求又只需要快速触碰一部分。3.2 通信不再是瓶颈NVLink域和CX8网卡的关系上一代方案里跨节点通信是最大的延迟来源。DeepSeek这类MoE模型的专家并行天然需要频繁把所有节点的部分输出做全局聚合。如果走RoCE或InfiniBand网卡单次通信延迟在微秒级叠加吞吐量根本提不起来。NVLink域把这个问题压到了近乎零。机柜内72块GPU通过NVLink Switch互联形成一个带宽极高的扁平网络跨机柜再走CX8网卡800G级别和ScaleUP/ScaleOut网络。这种“大域内、小跨域”的通信架构让MoE模型最怕的All-to-All通信多了好几条车道。这也是为什么NVL72不是简单堆GPU而是重新设计了整机计算拓扑。光有一颗强心脏不够还得保证全身血管畅通。3.3 软件栈更新CUDA 13/ cu130、TensorRT-LLM与DeepSeek harness硬件之外软件栈这次的动作同样大。NVIDIA发布的CUDA 13对应cu130更新里重点优化的内容之一就是Blackwell架构下的FP4原语和MoE模型调度原语。TensorRT-LLM也针对性补了DeepSeek R1的MLA算子让Attention部分不再走通用kernel而是走专门针对MLA结构优化的高速路径。这些软件优化对部署者的影响是直接的。过去在vLLM或SGLang里跑DeepSeek很多算子还是通用实现显存带宽利用率和计算单元利用率都远没有到极限。换用适配新硬件的推理后端后同样的模型同样的硬件吞吐量可能直接翻倍甚至更多。我还注意到圈子里开始流行叫“DeepSeek harness”的工具链——它在NVIDIA的SampleFabric、TensorRT-LLM、FastAPI之间做编排生成生产级的推理工作流。虽然不是官方提供的一键工具但它的思路很值得借鉴把模型部署变成一串可复现、可观测、可回滚的流水线而不是每次都在命令行里手工敲参数。4. 从100MW到我们的服务器普通团队到底能蹭到什么4.1 不自建工厂最划算的是直接把DeepSeek当API用说句实话100MW的AI工厂和我们绝大多数团队没有任何直接关系——自建几座NVL72机柜的资本开支和运维难度不是普通创业公司能碰的。但普通团队仍然能从整条产业链里吃到两波红利。第一波是模型厂商直接把优化后的推理能力封装成API。DeepSeek官方API的输入输出价格就已经压在很低的位置现在英伟达这边的推理吞吐量上去了、单位token成本降下来API的性价比大概率还会进一步变好。很多团队的明智选择是先直接用API不碰自建基础设施。等体量真的大到API费用变成核心成本再考虑研究私有化部署。4.2 中端卡集群方案H20/H800级别上的落地方案如果有合规和私有化要求必须自行部署也不必追求NVL72。对中小团队来说H20/H800集群配TensorRT-LLM或SGLang依然能吃到相当一部分优化红利。核心是把握好这几个工程原则模型并行切分时优先保证显存池化程度高的方案把KV Cache和专家模块分散放置避免某张卡显存被打满而其他卡闲置。推理引擎优先选带FP8/INT8量化支持且对MoE调度做过适配的版本例如SGLang的DeepSeek专用分支或TensorRT-LLM新版本。首token延迟和吞吐量要分开调优。prefill阶段的并发度、decode阶段的连续批量大小很多参数是冲突的需要按自己的业务请求特点做针对性压测。还有一个实操点如果显存有限部署DeepSeek R1的蒸馏小模型如32B也是不错的选择。总参数变小之后显存池化的收益下降但对硬件门槛的要求也同时下降单卡A100/H100甚至单张4090都能跑成本模型完全不同。4.3 DeepSeek harness类工具怎么本地搭很多人在GitHub上搜到“deepseek harness”之后不知道怎么在本地验证。这里给一套相对通用的流程参考了社区里常见的做法第一步准备环境。需要一台至少24GB显存的GPU服务器32B蒸馏模型系统装好CUDA 12.4以上版本、Python 3.10、PyTorch 2.1。第二步安装vLLM或SGLang。以vLLM为例安装后加载模型pip install vllm python -m vllm.entrypoints.openai.api_server \ --model deepseek-ai/DeepSeek-R1-Distill-Qwen-32B \ --tensor-parallel-size 2 \ --max-model-len 32768 \ --gpu-memory-utilization 0.9第三步写一个并发压测脚本测吞吐量。用aiohttp发异步请求统计每秒完成的token数import asyncio, aiohttp, time async def one_call(session, prompt): async with session.post( http://localhost:8000/v1/completions, json{model: deepseek-ai/DeepSeek-R1-Distill-Qwen-32B, prompt: prompt, max_tokens: 512} ) as resp: data await resp.json() return len(data[choices][0][text].split()) async def main(): prompts [给我讲一个关于数据中心的故事] * 64 async with aiohttp.ClientSession() as session: t0 time.time() results await asyncio.gather(*[one_call(session, p) for p in prompts]) total_tokens sum(results) dt time.time() - t0 print(ftotal tokens: {total_tokens}, elapsed: {dt:.2f}s, throughput: {total_tokens/dt:.2f} token/s) asyncio.run(main())这个脚本能帮你量化对比不同后端、不同量化精度参数下的真实吞吐量比看官方吹的数字直观得多。第四步用容器封装整个推理服务。社区里的harness工具本质上是把模型加载、推理服务、监控告警打包成标准流水线。自己用Docker Compose也能拼一个简化版services: inference: image: vllm/vllm-openai:latest command: [--model, deepseek-ai/DeepSeek-R1-Distill-Qwen-32B, --port, 8000] ports: - 8000:8000 deploy: resources: reservations: devices: - driver: nvidia count: 2 capabilities: [gpu]实测下来这类容器化部署在H20集群上比裸进程更稳定重启和扩缩容都从容很多。5. 工程现实散热、供电、网络、可靠性——AI工厂的四大暗礁5.1 液冷不是可选项是必需品单机柜60kW以上的热密度风冷已经完全失效。我见过不少团队在规划部署时把液冷当成“锦上添花”结果实测GPU因为温度保护降频吞吐量比标称低了20%以上。液冷方案需要关注三个参数冷却液入口温度一般15到40摄氏度可调、CDU的换热能力、管路的冗余设计。NVL72机柜的液冷接口直接落在背板上数据中心要提前铺好管路否则“买得起机柜、供不上冷量”是真正的尴尬。5.2 供电从UPS到柴发的整个链路都要重算100MW的数据中心即使在工业园区级别也属于“巨无霸”负荷。从10kV或35kV高压进线到中压配电、UPS、PDU、机柜母线每一层都需要按N1或2N冗余设计。单机柜功耗60kW意味着普通数据中心的16A/32A插座完全派不上用场机柜母线必须支持到数百安培级别。对没有园区级供电条件的团队一个务实建议是先把供电容量按目标算力需求的1.5倍规划为未来扩展留余量。电力系统的改造周期通常以月为单位等业务起来再扩电会卡住整个项目。5.3 网络从InfiniBand到CX8网卡跨柜通信的取舍AI工厂的网络不是“能用就行”而是直接决定大模型训练和推理的成功率。英伟达方案里CX8网卡提供了800G级别的端口配合ScaleUP/ScaleOut分层设计意图很清楚让机柜内的流量尽量留在NVLink域让跨机柜流量走专门的高带宽通道。实际运营中容易踩的坑是把所有流量都丢在同一张网络上推理请求的延迟抖动会直接影响线上服务的稳定性。更合理的做法是控制面和数据面分离推理流量走专用VLAN或物理网络监控、日志、模型加载走管理网络避免相互挤占。5.4 可靠性设计单点故障不能拖垮整柜整机柜的摩尔定律级算力密度反过来意味着故障爆炸半径也变大了。一个NVLink交换芯片故障可能影响几十块GPU之间的通信。生产级部署里必须做到故障预案前置模型要能快速热迁移、请求要能优雅降级、故障检测要在秒级触发。我见过有团队在测试环境里全链路跑通结果一上线遇到单卡故障整个推理服务挂了十分钟才恢复。后来加上健康检查和请求重试机制单卡故障的影响缩小到只影响个位数比例的请求。这个经验值得所有人借鉴测试环境一定要做“故障演练”把最坏情况暴露在可控环境里。写在最后一些经验之谈做了一段时间AI基础设施相关的工作我最大的感受是英伟达这套“AI工厂”思路的真正门槛不在芯片设计而在系统工程。从芯片到机柜到数据中心到软件栈每一层都在互相咬合想单点突破非常难。对普通团队而言与其盯着100MW、2ZFLOPS这样的远距离数字焦虑不如关注两个更贴近自己的问题一是API调用成本会继续下降能更便宜地用上顶级模型二是开源推理引擎和工具链正在快速迭代我们自己部署开源模型的性价比也在持续提升。最后分享一个实操心得不管用什么硬件跑DeepSeek先别急着上优化全家桶。先用默认配置搭一套忠实服务的推理环境把业务链路跑通再逐项开量化、开显存池化、调连续批处理参数每做一步都做一次A/B对比。这样你才能清楚地知道每一步优化到底带来了多少收益而不是被一堆“优化过的数字”裹挟着加码硬件。算力行业靠数字驱动但真正的工程判断力永远来自你亲手测过的那些真实负载。