企业官网建设流程全解析

最近在做一套基于910B NPU的大模型服务平台，硬件是8台机器，每台满配8卡，加起来正好64张NPU。这个规模放在今天不算小，但也远没到可以随便挥霍的程度。很多人一听64卡，就觉得什么模型都能跑，实际摸底之后发现，真正能落到生产环境的顶尖模型，选择面非常窄。这篇文章把我从需求梳理、模型对比、显存估算到并行配置和压测的全过程整理出来，希望能给同样拿着小集群做大模型选型的人一些参考。下面我会把这次选型分析的核心逻辑、具体数据和踩坑记录一次说清楚。

1. 8台×8卡到底意味着什么：算力池的账面与真实约束

1.1 先给这64张卡算一笔显存总账

如果单张910B NPU按64GB显存来算，64张卡总共是4096GB，约4TB。这个总显存听起来非常可观。作为参考，一个700亿参数的稠密模型，用16位精度存储权重，大约需要140GB，也就是说光从容量看，这4TB显存能装下几千亿参数甚至上万亿参数的模型。但显存容量并不是唯一的约束。实际操作中，跑模型不只是把权重塞进去，同时还要放激活值、KV Cache、临时计算缓冲区，以及多副本冗余，每一部分都会吃掉几百GB。

举个例子，一个700亿参数的模型做推理，如果把batch size设成32，输入长度和输出长度控制在2K左右，KV Cache可能额外吃掉几十GB，看起来对4TB不算什么。但如果你把模型切到所有64卡上做张量并行，权重只需要一份，可通信开销会急剧上升；如果做成数据并行，每张卡都要一份完整权重，4TB的显存容量要除以副本数。所以，算总账不等于可用账，必须先把并行复用策略定下来，才知道真实能用的显存有多少。

1.2 单机8卡拓扑和跨机通信，决定了模型并行策略的上限

这一层很多人容易忽略。8台机器，每台8卡，听起来就是64卡互联，但实际网络拓扑是：单机内部8张卡通过高带宽总线连接，带宽通常在数百GB/s级别，而跨机器之间的带宽一般只有几十GB/s，差距可以达到一个数量级。这就像同一个办公室的人喊一嗓子就能沟通，跨楼层的人却必须打电话。所以，同一个模型切片时，优先把通信频繁的层放在单机内，换句话说，张量并行最好只限制在单机8卡范围内，跨机之间更适合用流水线并行或专家并行，这样通信频次相对低，单次数据量可控。

这个约束直接影响了选型。如果一个模型大到必须用16卡甚至32卡做张量并行才能跑起来，那意味着每次前向计算都要经过跨机通信，每层都要做all-reduce或all-gather，性能会迅速劣化。我在选型时给自己定了一个原则：优先考虑能在单机8卡内完成张量并行的模型，其次是可以通过2到4台机器做流水线并行或专家并行能跑得好的模型。超过这个范围，即便总显存放得下，实际吞吐也会很难看。这个原则帮我筛掉了很多看起来很美但工程上很难搞的模型。

1.3 把模型规模“翻译”成硬件资源需求

为了有一个可量化的判断，我习惯用一张表来做预筛选。模型参数量设为P（单位亿），精度位数为B，那么权重占用大约是 P×B/8 GB。以70B模型FP16为例，70×16/8=140GB；如果换成FP8，就是70GB。如果是MoE模型，总参数很大，但实际推理时激活的参数只是其中一部分，不过权重仍然需要全部加载，所以显存估算不能按激活参数算，必须按总参数算。这一步把很多人的认知带偏了，总觉得MoE模型能省显存，其实它省的是计算量，不是存储量。

然后再加上KV Cache估算，它大约等于 2 × batch size × 序列总长度 × 层数 × 头维度 × 精度字节。公式不复杂，但很容易漏掉层数和注意力头数。我的做法是直接用推理框架自带的内存估算接口，或者先加载模型后用监控命令看实际占用，再反推batch和长度上限。这里还要考虑微调场景，全参数微调时显存需求会激增，70B模型仅优化器状态就接近权重四倍的量级，没有几十张卡根本跑不动。所以选型前必须明确：是只做推理，还是也要微调，两者对硬件资源的需求完全不同。

2. 顶尖大模型选型的四个核心维度

2.1 参数量和架构类型：稠密模型 vs MoE模型

大模型选型，首先绕不开的就是架构选择。稠密模型每个token会激活全部参数，计算强度高，但效果相对稳定，推理实现复杂度低。MoE模型总参数量大，但每次只激活一小部分专家，单位token的计算成本低，适合高并发场景。可代价是全部专家权重都要留在显存里，同时对卡间通信的冲击非常明显。如果说稠密模型是所有人都干活，MoE就是一群人开会但只有少数人发言，会议系统也就是通信网络不能太差，否则每轮发言都要等很长时间。

从硬件角度看，900B总参数的MoE模型全量权重用FP16存储需要1.8TB，4TB显存能放下，但如果你做数据并行冗余，很快就不够。而一个70B稠密模型在单机8卡上就能做到很低的推理延迟，吞吐也能通过增加并发拉起来。所以在64卡集群上，如果追求极致吞吐，MoE可能占优；如果追求单请求低延迟和工程可控，70B级稠密模型更稳妥。这次选型中，我把这两类模型都纳入候选，用实际压测数据说话，而不是凭感觉押注。

2.2 上下文长度和批处理量，决定KV Cache的吞噬速度

这个维度经常被忽略。同样是70B模型，上下文长度从4K扩展到128K，KV Cache的占用会增长30倍以上。如果你要看中长文本，比如代码仓库、论文、多轮对话，就必须把KV Cache的空间规划到权重之外的余量里。一个64GB的NPU卡，假设权重占了一半，剩下给KV Cache的一半空间，能支持的并发数和序列长度并没有想象中那么高。很多人在模型选型时只盯着参数量，根本不看上下文长度，结果部署完发现稍微喂几段长文本就OOM，非常尴尬。

所以在选型时我把上下文长度作为一个硬指标，先列出来：业务需要多长上下文？期望并发是多少？然后推算KV Cache总量，再留给权重。不同模型在同样长度下KV Cache占用并不一样，与注意力头数、层数、是否使用分组查询注意力都有关系。支持GQA的架构能显著降低KV Cache大小，这个特性在选型时优先级很高。事实证明，同一个参数量级别，有没有GQA，实际能承载的并发数可能差出一倍以上。

2.3 量化方案：FP16、BF16、FP8还是INT8

顶尖模型的原始权重大多数是BF16或FP16格式。对于推理场景，量化到FP8或INT8能把权重占用减半，对显存紧张的项目是很大的红利。但量化并不总是一拍脑袋就能做，要考察模型对低比特的耐受度，还要考虑NPU对FP8和INT8计算的支持程度。910B NPU对常见量化格式有不错的支持，但个别算子会回退到低效率实现，导致理论减半的显存没换来同比例的吞吐提升。我实测过同一模型在FP8和BF16下的表现，某些层确实有精度损失，但整体效果还在接受范围内。

我的原则是：权重尽量直接用FP8方案，如果精度敏感就退回到BF16，绝不用INT4强行压缩一个大模型。对于追求顶尖效果的模型，INT4的精度损失在复杂推理任务上会被明显放大，特别是数学、代码、逻辑推理这几类任务。这个问题在评测集上非常突出，所以选型时必须把量化后的效果评估纳入测试计划，不能只看显存开销降下来了就拍板。如果拿到的模型原本就是低比特训练过的，那是另一回事，否则还是要谨慎。

2.4 生态与框架适配：跑得动比跑得快更重要

这一点不说可能有人会忽视。一个模型就算在某个硬件上表现一流，但到了910B NPU上，如果推理框架不支持或算子没有优化，跑起来会非常难受。选型时我会先看模型结构是否为社区主流结构，是否已有对应NPU的适配案例。优先选择那些能够直接用现成推理引擎跑的模型，而不是新模型或改动很大的变体。因为后续还需要服务化、批量推理、动态shape等功能，光有模型权重，没有配套的工程生态，在落地上就是一场灾难。

尤其是“顶尖”模型，很多模型发布后只是放出了权重，没有适配主流推理框架，也没有优化过的算子库。想让它跑在NPU上，可能要自己写算子、自己改并行逻辑，这个成本已经远远超出“选型”的范畴。我的建议是：如果目标是快速上线、稳定服务，那就选工程生态最成熟的那一档模型；如果目标是挑战极限性能，愿意投入大量研发时间去适配，那可以考虑更强的模型。两者要分开对待。

3. 我实际对比过的三类候选模型画像

3.1 第一类：700亿级稠密模型，单机8卡即可部署

我重点看了几款700亿参数级别的稠密开源模型，用Model-A代表表现最强的那款。它的特点是底座非常扎实，在知识问答、代码、数学等任务上都有很强能力，综合效果可以算作第一梯队。用8张卡做张量并行，FP16权重140GB摊到每卡17.5GB，加上KV Cache和激活值，每卡占用约40GB，剩下20多GB余量。这个模型可以做到单机部署，不需要跨机通信，服务稳定，压测时吞吐和延迟表现都可控。最终我把这类模型作为默认首选。

同时我也对比了另一款同级别的Model-A-Plus，上下文能力更强，但权重生效后每卡占用增加了5GB左右，相同并发下KV Cache的余量变小。这个细微差别在长文本场景下被放大了，所以最终没有选它。这种在表格里很难看出来的差异，只有跑真实压力测试才能发现。

3.2 第二类：千亿级MoE模型，需要跨机并行才能发挥优势

第二类是总参数在600B到1000B之间的MoE模型，比如Model-B。它的优势是每个token只激活少量专家，推理时计算量低，理论推理吞吐可以做得比同等总参数的稠密模型高很多。但在64卡环境下，它需要把所有专家权重分布在多台机器上，模型并行复杂度明显上升。以总参数700B、FP8权重约350GB为例，4台机器32卡刚好能放下，再配合专家并行和张量并行，实测吞吐确实比单机70B模型高出不少，但代价是单请求延迟明显变高，通信开销在负载高的时候波动很大。

如果业务对延迟不敏感，以离线批处理为主，比如批量文档分析、离线数据标注，这类MoE模型值得选。但如果是面向在线交互的应用，用户问一句话要等更久才能看到第一个token，这种体验很难接受。所以在线上服务这个场景，我一开始就把它排除了。

3.3 第三类：更大规模的“顶配”模型，看得见但用不起

第三类，也是很多人口中的顶尖大模型，总参数动辄上万亿，FP8权重就需要2TB以上。4TB总显存放得下，但这时几乎没有余量给KV Cache和并发，而且所有数据都要跨机传输，训练和推理都会卡在网络瓶颈上。我尝试过用大部分卡做张量并行，结果单卡利用率惨不忍睹，整体吞吐还不如前面两类。原因很好理解：跨机通信的带宽只有卡间带宽的十分之一左右，每层都做全量通信，等数据的时间比计算时间还长，算力自然被浪费。

所以即使理论上它能跑，我最终也把它排除在实用选型之外。结论很明确：顶尖模型不等于最大模型，在有限算力下，能发挥出硬件性能的模型才是真正的好模型。这个判断虽然听起来有点反直觉，但做完一轮压测之后，你会发现这恰恰是工程上最正确的选择。

4. 从选型到落地的关键实操路径

4.1 用一张表完成显存与并行方案估算

我建了一个共享表格，列出候选模型、总参数量、激活参数量、精度、权重占用、估算KV Cache、总占用、单机8卡可部署性、需要跨机卡数、推荐并行策略，每填一行就做一次筛选。比如一个模型权重占用超过3TB，直接标红；单机8卡权重占用加KV Cache超过每卡80%，标黄。这个表格在项目沟通里非常有用，能让所有参与决策的人快速看到权衡，而不是争来争去拍脑袋。

表格之外，我还会补充一列“可支撑的最大并发”，这是结合目标上下文长度和KV Cache占用算出来的。因为业务方最关心的是“这个模型能撑多少并发”，这个数字比参数量更有说服力。算完之后，我们就能很清楚地分出优先级：单机8卡能稳定运行的模型排第一，跨机并行能跑但延迟高的排第二，勉强塞进去的排第三。

4.2 并行切分配置：张量并行、专家并行、流水线并行怎么组合

实际配置时，我的经验是：张量并行尽量不超过单机8卡，跨机只放流水线或专家并行。如果使用MoE模型，专家并行会让每个专家分布在不同卡上，路由通信压力很大，必须把网络拓扑和卡间通信考虑进去。通常先用框架默认配置跑通，再逐步调整并行度，比如从纯数据并行切到张量并行加专家并行，每一步都记录吞吐和延迟，不要一开始就上最复杂的组合。

我踩过的一个坑是，一开始为了让Model-B跑起来，直接用了32卡张量并行，结果卡间通信时间占比接近四成，算力利用率不到一半。后来把并行配置改成4台机器流水线并行加专家并行，单卡利用率提升到60%以上，整体吞吐提升非常明显。有时候做减法比做加法更重要，并行度不是越高越好。

4.3 在线服务参数调优：batch、并发、max-length的平衡

模型服务化之后，最重要的参数是max batch size和max sequence length。很多人喜欢把batch拉到最大，结果延迟飙升，整体吞吐反而下降。我一般先固定max-length，然后从小到大增加并发，找到延迟和吞吐的平衡点。实际曲线通常是一个倒U形：并发太低，显存闲置，吞吐上不去；并发太高，排队和显存争抢导致单请求耗时飙升，整体吞吐也掉下来。

KV Cache优化策略也必须开启，现在很多推理框架都支持分页式KV Cache管理，类似操作系统的内存分页，能大幅减少显存碎片和浪费。对于910B NPU，需要看框架版本是否支持这些优化，不支持的话就要限制最大并发，避免放到一半爆显存。在线服务不像离线跑batch，一旦OOM就是线上事故，所以参数设置一定要保守再逐步放开。

4.4 跑通一次真实压测，拿到第一手吞吐数据

选定模型后，要用真实业务数据做压测，不能只跑几个标准样例。我会用脚本并发发送请求，记录首token延迟、每token延迟、吞吐量和显存峰值。压测时故意设置多种length分布，模拟实际请求长短不均的情况，因为线上请求不会是清一色的2048 token，长短混合对KV Cache和调度策略的考验完全不同。

压测结果经常和理论估算偏差很大。有一次我估算一个MoE模型应该轻松跑到高吞吐，结果因为路由不均衡，某几张卡负载明显偏高，整体性能下降了三成。后来启用负载均衡策略才稳定下来。这个环节不能省，只看理论估算在真实场景里往往会翻车，尤其是NPU环境下的脑力工作，很多优化特性需要实际验证。

5. 常见问题与排查技巧实录

5.1 显存明明够，加载却OOM的隐形原因

最常见的问题是显存碎片和框架内存预留。模型权重估算没问题，但加载时会因为内存对齐、临时缓冲、KV Cache预分配导致超出预期。解决办法是先加载最小配置，观察显存占用曲线，再逐步调batch。另外，不同模型的分词器词表长度不一致，实际序列长度可能比预期大，也会让KV Cache超量。我踩过这个坑，最终靠限制max-length、开启KV Cache复用才解决。

还有一个容易忽略的点：如果同时加载多个模型副本用于负载均衡，显存占用不是简单乘副本数，因为每个副本都有独立的内存管理和临时缓冲，会有额外开销。所以我在配置多副本时，通常会留出至少一个卡的全部余量做缓冲，防止某段时间请求突发导致整体OOM。

5.2 跨机训练/推理速度远低于预期的排查思路

如果发现跨机时卡间通信长时间占用，首先要检查网络拓扑是否匹配并行策略。比如用了16卡张量并行但跨机带宽只有单机内带宽的十分之一，那性能必然崩。排查步骤：先分别测试单机内和跨机的通信带宽，看是否达到预期；然后看计算和通信重叠是否开启；最后再看并行度设置是不是过度。很多时候换成流水线并行后，速度反而提升明显，因为流水线通信频率比张量并行低很多。

另外，网卡中断绑定、内存页大小、网络协议缓冲区设置也会影响跨机通信。这些问题在单机测试时完全看不出来，只有真正跑到8台机器时才会暴露。最好在一开始就搭建一个最小的跨机环境做带宽测试，别等到模型加载完才发现网络瓶颈，那时候排查成本非常高。

5.3 选型后效果达不到“顶尖”的几个隐藏限制

还有一个现实问题：你选了顶尖模型，但效果不一定顶尖。原因可能是量化精度损失、推理框架对某些算子的实现不够优化、prompt策略不匹配等。建议在小规模测试集上同时跑原版权重、量化权重和不同推理框架，消除工程因素后再评价模型本身能力。如果最终效果还是不够，就要考虑换模型或增加微调。选型不是一个静态决策，要留出回退空间。

我在实测Model-A时发现，同一个模型在BF16下数学推理准确率明显高于FP8版本，但代码生成任务两者差距较小。这说明不同能力维度对量化敏感度不同，不能只看平均分数。如果业务核心是数学逻辑，那量化方案就要更保守，或者换一个对量化更友好的模型。这些都是选型时很难提前想到，但实测后必须纳入决策的因素。

我个人在实际操作中的体会是，选型这件事，技术参数只是基础，真正的分水岭在于你对自己的场景有没有清晰的边界。在64卡910B NPU集群上，我认为最优解往往不是最大的模型，而是那个能在单机8卡内稳定跑起来的70B级稠密模型。如果追求吞吐且能接受复杂部署，MoE模型也值得试。但无论如何，建议先从能跑通的配置开始，用数据说话再下结论。希望这篇文章能帮你少走一些弯路。