最近在做一套基于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/8140GB如果换成FP8就是70GB。如果是MoE模型总参数很大但实际推理时激活的参数只是其中一部分不过权重仍然需要全部加载所以显存估算不能按激活参数算必须按总参数算。这一步把很多人的认知带偏了总觉得MoE模型能省显存其实它省的是计算量不是存储量。然后再加上KV Cache估算它大约等于 2 × batch size × 序列总长度 × 层数 × 头维度 × 精度字节。公式不复杂但很容易漏掉层数和注意力头数。我的做法是直接用推理框架自带的内存估算接口或者先加载模型后用监控命令看实际占用再反推batch和长度上限。这里还要考虑微调场景全参数微调时显存需求会激增70B模型仅优化器状态就接近权重四倍的量级没有几十张卡根本跑不动。所以选型前必须明确是只做推理还是也要微调两者对硬件资源的需求完全不同。2. 顶尖大模型选型的四个核心维度2.1 参数量和架构类型稠密模型 vs MoE模型大模型选型首先绕不开的就是架构选择。稠密模型每个token会激活全部参数计算强度高但效果相对稳定推理实现复杂度低。MoE模型总参数量大但每次只激活一小部分专家单位token的计算成本低适合高并发场景。可代价是全部专家权重都要留在显存里同时对卡间通信的冲击非常明显。如果说稠密模型是所有人都干活MoE就是一群人开会但只有少数人发言会议系统也就是通信网络不能太差否则每轮发言都要等很长时间。从硬件角度看900B总参数的MoE模型全量权重用FP16存储需要1.8TB4TB显存能放下但如果你做数据并行冗余很快就不够。而一个70B稠密模型在单机8卡上就能做到很低的推理延迟吞吐也能通过增加并发拉起来。所以在64卡集群上如果追求极致吞吐MoE可能占优如果追求单请求低延迟和工程可控70B级稠密模型更稳妥。这次选型中我把这两类模型都纳入候选用实际压测数据说话而不是凭感觉押注。2.2 上下文长度和批处理量决定KV Cache的吞噬速度这个维度经常被忽略。同样是70B模型上下文长度从4K扩展到128KKV 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模型也值得试。但无论如何建议先从能跑通的配置开始用数据说话再下结论。希望这篇文章能帮你少走一些弯路。