企业官网建设流程全解析

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 exaFLOPS（1.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的多头注意力用的是MLA（Multi-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(f"total 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、机柜母线，每一层都需要按N+1或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对比。这样你才能清楚地知道每一步优化到底带来了多少收益，而不是被一堆“优化过的数字”裹挟着加码硬件。算力行业靠数字驱动，但真正的工程判断力，永远来自你亲手测过的那些真实负载。