前阵子帮一位准备跳槽的AI应用架构师候选人做模拟面试他在模型训练、算法调优、工程部署这几个方向上都答得挺顺。结果面试官顺着“我们准备在公司内部署一个70B开源模型”这个话题随口问了一句“你估计大概需要多少张卡”他犹豫了几秒回答“我觉得四五十张A100够了吧”。面试官接着追问“你是按什么估的显存还是吞吐训练还是推理预算上限是多少”他一下就答不上来了。这个场景我见过太多次。在AI应用架构师的面试里算力规划类问题几乎是必考题但大多数候选人吃亏在同一个地方不是不懂模型而是没有一套完整的“算账逻辑”。今天这篇文章我就把自己这些年做算力规划、以及面试别人和被别人面试时积累的问题与答案完整梳理一遍。从基础估算公式、显存和KV Cache推导到GPU选型、降本策略、容量规划再到面试官爱追问的分布式并行和故障恢复最后给出几个值得反问的问题。内容偏实操尽量让没上过大规模集群的人也能听懂、能复现、能套用。1. 一个“拍脑袋报50卡”的面试复盘算力规划到底在考什么1.1 为什么“四五十张A100”这个答案只能拿50分先说结论那位候选人给的“四五十张A100”其实不一定错但他拿不到高分因为整个过程缺少最关键的推导链。面试官想听到的是从需求到资源的一整条逻辑模型参数量是多少、训练数据有多少token、单卡有效算力是多少、显存约束是什么、目标训练周期是多久、预算上限在哪里。同样的场景如果候选人能说出“70B模型、2T token、BF16训练、MFU按50%估、60天跑完粗算下来大概需要480张A100”这种话即使数字和面试官心里的答案不一样也会被认为是懂行的人。算力规划类问题在面试中的套路非常固定。它不是考你背参数而是考一个AI应用架构师最基本的素养把模型、数据、框架、硬件、成本这些变量放到一起做出一个可执行、可验证的决策。面试官看的是你遇到不确定问题时会不会先把假设列出来再一步步逼近结果。这也是绝大多数候选人最需要训练的地方。1.2 面试中算力规划问题的完整版图我总结这些年碰到的面试题算力规划大致分五类。第一类是估算题比如“训练一个7B模型需要多少卡”“部署70B模型需要多少显存”第二类是选型题比如“A100、H100、4090怎么选”“单机8卡还是多机多卡”第三类是优化题比如“显存不够怎么办”“算力利用率上不去怎么办”第四类是成本题比如“怎么把推理成本降一半”第五类是运维题比如“训练中断怎么处理”“线上流量翻倍怎么扩容”。这五类问题背后对应的能力层层递进估算题考工程数量级选型题考系统设计优化题考框架和硬件原理成本题考商业意识运维题考可靠性思维。面试官不会要求你对每类问题都答得完美但至少要在估算和选型这两个最基础的板块上展示出清晰的逻辑。如果这两块能答好通常已经能超过80%的候选人。接下来我把每一类的核心思路拆开讲。2. 训练侧算力账从FLOPs到“需要多少张卡”的完整推导2.1 核心公式总计算量约等于6倍参数量乘以token数训练侧算力规划第一件事是算总账。业界流传最广的预训练估算公式是总计算量FLOPs约等于 6 × 参数量 × token数。为什么是6因为前向传播计算量约是2 FLOPs每参数每token反向传播的计算量约是前向的2倍也就是4 FLOPs加起来就是6。这个公式来自对Transformer训练过程的整体建模Chinchilla等经典论文里的讨论基本都遵循这个口径。举个例子。假设要训练一个7B参数的模型用2T2万亿token的数据那么总计算量就是6 × 7×10⁹ × 2×10¹² 8.4×10²² FLOPs。这个数字是后续一切推导的基础。注意这只是预训练的计算量不包括评估、清洗数据、调试实验等额外开销真实项目中要在这上面再乘一个系数。2.2 单卡有效算力峰值乘以MFU才是真实速度有了总计算量下一步是估算单卡每秒能干多少活。很多人在这里犯的错误是直接拿GPU的理论峰值算结果出来的数字极其乐观一到实际训练就发现完全对不上。真正计算时要引入MFUModel FLOPs Utilization也就是模型算力利用率。A100 80G的BF16/FP16 Tensor Core理论算力大约是312 TFLOPS但实际训练大模型时由于通信开销、访存瓶颈、kernel启动开销等因素MFU通常只能到40%到60%。如果跨机通信严重甚至可能跌到30%以下。所以单卡有效算力 单卡峰值 × MFU。按A100、MFU取50%算单卡每秒有效算力就是312×10¹² × 0.5 1.56×10¹⁴ FLOPs。把之前的总计算量除以这个值就是单卡需要的总秒数8.4×10²² ÷ 1.56×10¹⁴ ≈ 5.38×10⁸秒换算成天大约是6230天。也就是说用一张A100训练这个7B模型要跑将近17年。2.3 从单卡天数到卡数目标周期决定总规模有了单卡天数答案就直接了。如果业务目标60天训完需要的卡数就是6230 ÷ 60 ≈ 104张A100。如果只有64张卡那就是6230 ÷ 64 ≈ 97天。这种“先把总账算出来再根据周期反推卡数”的方式是机器学习团队最常用的规划方法。不过要注意104张卡只是从计算量角度得到的结果。现实中还要考虑显存是否够用、通信拓扑是否合理、数据加载会不会成为瓶颈。所以我在面试时如果给出这个答案一定会补一句“这还只是计算侧的粗算显存和网络约束我接下来再验证”。这句话很重要它表明你不是只会背公式而是知道算力规划是多重约束下的联合决策。2.4 显存账为什么7B模型单卡A100也装不下显存估算在训练侧经常是决定方案是否成立的关键。以混合精度训练为例一份模型参数在显存里的开销不只有权重本身。标准Adam优化器加混合精度训练下每个参数大约占用16字节FP16权重2字节、FP16梯度2字节、FP32主权重副本4字节、Adam的momentum和variance各4字节。于是7B模型的模型状态就是 16 × 7×10⁹ ≈ 112GB已经超过单张A100 80G的容量。这就是为什么训练大模型必须引入ZeRO或模型并行。面试中如果被问到“7B模型单卡能不能训”正确答案不是“能”或“不能”而是“如果不开任何显存优化模型状态就要112GB单卡放不下但用8卡开ZeRO-3或张量并行把模型状态分片单机8卡A100就能跑”。能把这个逻辑讲清楚说明你理解显存账的关键不是只看参数量而是看优化器状态和并行策略。3. 推理侧算力账显存、KV Cache和并发上限怎么算3.1 训推分离推理的瓶颈在显存带宽不在算力推理侧的算力规划和训练有很大区别。训练是长时间批量计算主要看总FLOPs和MFU而在线推理服务的核心指标是延迟、吞吐和并发。更关键的是自回归生成模型在decode阶段逐个token生成时算力往往吃不满反倒是显存带宽成为硬瓶颈。原因很简单每生成一个token都需要把模型权重从头到尾读一遍权重越大、带宽越低生成速度就越慢。这也是为什么推理规划不能照搬训练公式。面试官问到“部署70B模型需要多少卡”时如果只答“140GB权重2张80G卡装下”是不够的因为没有考虑并发、上下文长度和带宽约束。接下来要算的是KV Cache和并发上限。3.2 KV Cache公式并发的真正限制条件KV Cache是推理算力规划里最容易被忽视的变量也是面试官区分“背过资料”和“真正部署过”的利器。KV Cache的字节数估算公式是2 × transformer层数 × KV头数 × 头维度 × 序列长度 × 并发数 × 精度字节数。其中2表示K和V两份缓存。以70B模型为例假设它有80层8个KV头每个头维度128FP16推理那么每生成一个token、每请求需要的KV Cache约为2 × 80 × 8 × 128 × 2 327,680字节约320KB。当上下文长度为4096时一个请求的KV Cache就是 320KB × 4096 ≈ 1.25GB。如果同时有256个请求在跑KV Cache总量就是约320GB这比模型权重本身还要大得多。所以在面试中算并发上限时我会把模型权重、KV Cache、推理引擎的额外开销三者一起列出来。70B模型FP16权重是140GB8卡A100 80G总显存640GBKV Cache每个请求1.25GB粗算下来能支撑的并发就在两三百路这个数量级。当然真实环境还要考虑张量并行后权重分片、通信开销、CUDA context等最终数字必须靠压测验证但至少这样的推导能让面试官相信你有一套可复现的估算方法。3.3 从QPS反推卡数把业务需求翻译成算力需求面试中更进阶的问题是“如果线上QPS是100需要多少卡”。这时不能直接给卡数要先反推几个变量平均请求上下文有多长、平均输出多少token、目标首token延迟和每token延迟是多少。然后用到一个小定律并发数 QPS × 平均响应时间。举个例子。假设QPS100平均每个请求输出300个token目标TPOT每个token生成时间是50毫秒那么每个请求平均响应时间大约300×0.0515秒。需要的并发就是100×151500路。再结合单卡或单实例能支撑的并发比如80G A100在70B模型下大约几十路到上百路并发卡数自然就出来了。这个推导过程比直接报一个卡数有价值得多因为它把产品指标和基础设施用量联系在了一起。4. 选型题的正确打开方式GPU、互联带宽和上云还是自建4.1 GPU选型决策矩阵选型问题是算力规划里的常青树几乎每一轮面试都会遇到。我的经验是不要背参数表而要掌握一套决策逻辑。首先让模型和数据装得下单卡显存是否满足推理所需的最小空间其次看瓶颈在哪训练任务更看重单卡算力和卡间互联推理任务更看重显存容量和显存带宽最后看投入产出新卡通常贵但长上下文和量化场景下能少买卡。举个例子。一张H100 80G和一张A100 80G单卡FP16算力从312T提升到接近1000T但显存和带宽提升也很明显。如果只是跑70B模型低并发推理可能A100也够但如果要做高并发、长上下文服务多出来的算力和带宽直接决定单卡能扛多少路并发。至于24G显存的消费级卡适合做小模型微调、原型验证但做在线生产服务通常不建议因为显存带宽和稳定性都差很多。4.2 网络拓扑决定并行策略选型不只选卡还要选互联方式。单机内8张卡通过NVLink互联带宽可以达到900GB/s级别用PCIe就掉到几十GB/s跨机器的网络再快也基本是几百Gbps的量级和NVLink差了一个数量级。这个差异直接决定了你的并行策略。以7B模型的张量并行训练为例张量并行的通信量非常大每层前向反向都需要频繁交换中间结果所以张量并行最好限制在单机8卡以内最好都在NVLink域内。如果要做跨机并行更合适的是数据并行、ZeRO分片或流水线并行因为这些策略的通信频率相对低。面试中如果被问到“8卡4090和一台8卡A100服务器怎么选”我会说训练7B模型8卡4090的显存总量可能更大但PCIe互联和散热都是坑容易变成训练一小时、通信半小时除非只做微调小模型否则生产环境我更倾向A100或更新的数据中心卡。4.3 上云还是自建没有标准答案但要会算账上云还是自建的讨论本质上是在算成本和交付周期的账。云GPU的优点是弹性好、交付快缺点是小时代价高自建或包周期集群的优点是单位成本低、性能可控缺点是交付周期长、利用率不足时浪费大。面试里最稳妥的回答方式不是站队而是给出一个判断框架如果业务负载波动大、项目周期短、预算不确定上云按需更合适如果训练任务长期跑满、推理流量稳定、团队有运维能力自建或包年更划算。还可以补充一个“利用率阈值”的经验值预估长期利用率低于30%云按需高于50%自建。真实案例中我见过一个团队为了省成本自建了几十台机器结果项目延期GPU闲置了半年那比云贵多了。4.4 选型题的加分回答结构最后分享一个面试里很好用的结构。收到选型类问题时先明确约束条件模型多大、并发多少、预算是多少、SLO是什么然后给2到3个候选方案简要对比优劣接着给一个推荐方案并解释为什么优先考虑它最后加一句“我会先用小规模压测验证单卡吞吐上限再决定最终卡数”。这个回答结构的价值在于把一道可能很开放的题目变成了一个你自己主导的决策过程面试官很难找到破绽。5. 降本类问题的隐藏考点从ZeRO到量化每一步都算钱5.1 训练降本三板斧混合精度、梯度检查点、ZeRO算力规划做到后面本质就是在算钱。训练侧的降本手段面试中最常考的是三板斧。第一板斧是混合精度训练用FP16或BF16替代FP32训练速度直接翻倍显存占用减半。BF16对大模型更稳因为它和FP32有相同的指数位不用太担心溢出问题。第二板斧是梯度检查点也叫激活重计算前向传播时不保存全部激活值只保存关键节点反向传播时再算一遍用约20%到30%的计算量换回大量显存。第三板斧是ZeRO优化器状态分片ZeRO-1只切优化器状态ZeRO-2切优化器和梯度ZeRO-3把模型参数、梯度、优化器状态全部分片。训练7B以上模型时ZeRO-3几乎是必需品。面试中想让答案有亮点一定要叠加一个“显存不够导致batch太小MFU上不去”的故事。举个例子7B模型全参微调如果不开任何优化手段模型状态已经超过单卡80G只能把batch压到1训练一整天都跑不了几个step。开启梯度检查点加ZeRO-2之后batch可以翻几倍GPU利用率一下子提上来训练时间反而比不开检查点还短。这种“用时间换显存、用显存换batch、用batch换效率”的连锁逻辑才是面试官想听到的。5.2 推理降本三板斧量化、连续批处理、投机采样推理侧的降本思路和训练不太一样。第一板斧是量化FP16转INT8可以把显存直接砍半转INT4甚至能砍到四分之一。比如70B模型FP16权重140GB转INT4后大约35GB单卡就能放得下部署门槛大幅降低。但量化不是免费午餐尤其是小模型量化后掉点可能很明显。正确做法是先拿业务验证集量化测试如果能接受质量损失再上而不是看到“量化”两个字就冲。第二板斧是连续批处理和PageAttention典型代表是vLLM这类推理框架通过把显存碎片化的KV Cache管理起来在线吞吐可以提升2到4倍相当于卡没变多但单位卡的QPS翻了。第三板斧是投机采样用一个小模型先快速生成草稿再由大模型一次性验证在部分硬件条件下能明显降低生成延迟。面试中被问“推理成本太高怎么办”时我推荐沿着“先榨干现有卡再考虑加卡”的路径答。先看显存利用率和GPU利用率如果利用率低优先上连续批处理和更好的调度策略如果模型太大导致单卡并发太低再做量化或压缩最后实在不够才谈采购。这套回答里透露的思路是算力规划不只是算怎么买卡更是算怎么把已有卡用满。5.3 一个成本对比案例卡没变多负载却翻倍了为了让降本逻辑更好理解我分享一个实际踩过的场景。有一个70B模型的在线服务最初部署在16张A100上单实例并发压得很低很多卡闲着但监控里GPU利用率却不高。后来做了三件事第一引入连续批处理框架把单实例并发拉高第二把权重从FP16切到INT8KV Cache省出来的显存再塞进更多并发第三设置路由策略把短请求和长请求分开调度避免长请求把整批请求拖慢。最终同样的负载只用8张卡就跑完了GPU利用率反而提升月成本降了接近一半代价只是首token延迟略有上升业务完全可接受。这个案例在面试中讲出来很加分因为它展示了降本不是靠压缩模型质量而是靠工程手段把算力用得更有效率。面试官清楚一个AI应用架构师如果只会说“换小模型”“加卡”那是没真正上过生产环境。6. 容量规划与弹性伸缩别背“K8sHPA”要会算并发6.1 Little定律把QPS翻译成并发数容量规划类问题经常被问成“线上服务需要预留多少实例”很多候选人脱口而出“用K8s的HPA根据CPU和内存自动扩缩容”。这种答案一听就是背过的因为GPU推理服务的瓶颈通常不在CPU和内存而在显存、显存带宽和推理队列深度。真正需要先做的是把QPS翻译成并发数。这里用到排队论里最基础的Little定律并发数 QPS × 平均响应时间。假设线上目标QPS是50平均每个请求从进入到返回需要5秒那么系统里同时存在的请求数就是250。如果单实例在满足延迟SLO的前提下能稳定处理40路并发那至少需要250÷40≈7个实例。这种计算方式在任何面试现场都能靠心算完成一旦你说出来面试官会明显感受到你做过真实的容量评估。6.2 压测指标TTFT、TPOT和那些“看着正常实际不行”的坑做容量规划不能只靠估算一定要落到压测。推理服务压测最核心的三个指标是TTFT首Token延迟、TPOT或ITL每个Token生成延迟、整机吞吐。TTFT反映的是prefill阶段和排队情况TPOT反映的是decode阶段和显存带宽情况。很多团队只看QPS和平均延迟结果高并发下一看P99吓一跳就是因为没有拆分这两个阶段。压测里还有一个容易被忽视的变量请求长度分布。8K上下文的请求和128上下文的请求对显存和KV Cache的占用天差地别。如果压测时只用短文本测得到的并发上限是虚高的一上生产全是长文档显存立刻吃紧。所以我在做容量规划时一定会先从线上日志里统计请求长度分布再按分布构造压测样本。这些经验面试时说出来很容易让面试官觉得你的规划是有生产数据支撑的而不是只靠理论。6.3 弹性伸缩的工程细节预热、缓冲池与混部弹性扩缩容在面试中不难答但很多人的回答只有“HPA加节点池”这一句缺乏工程细节。真正做过的团队都知道扩容不是即时生效的。新节点从注册、拉取模型权重到完成CUDA预热可能需要好几分钟。模型越大镜像越大冷启动越慢。所以生产环境通常要做两层设计一层是提前配置缓冲实例随时可以吸收流量尖峰另一层是根据队列深度而非单纯的CPU指标做扩容触发因为GPU推理服务的排队长度比CPU使用率更能反映真实压力。另外还有一个省钱技巧是潮汐混部。在线推理服务在夜间流量低空闲的GPU完全可以跑离线任务比如夜间批量推理、数据清洗、微调实验。这样从算力规划角度看等于用同一批硬件同时满足在线和离线需求整体资源利用率自然就上去了。6.4 回答“流量明天翻倍怎么办”的标准思路这道题几乎是AI应用架构师面试中的压轴题之一。我的回答一般分四步。第一步先反问清楚“翻倍”到底是什么是QPS翻倍还是请求的上下文和输出长度翻倍这两者对算力的需求形态完全不同。第二步用Little定律快速估算翻倍后需要的并发和实例数。第三步说明扩容预案如果是预测到的大促提前扩容并压测如果是突发的依赖缓冲池加队列削峰。第四步给出兜底策略优先级降级保证核心请求的SLO牺牲非核心任务的并发。这四步走下来面试官基本能确认你具备系统级容量规划能力。7. 面试官会追问的延伸题并行策略、故障恢复与“国产卡”7.1 四种分布式并行策略的边界感算力规划绕不开分布式训练面试官在这个环节很喜欢追问并行策略的边界。数据并行最简单每个GPU放完整模型副本只同步梯度ZeRO是数据并行的显存优化版把模型状态分片到各卡用通信换显存。张量并行是把每一层的权重矩阵切到多卡上通信量非常大适合单机内部。流水线并行按层切分每张卡只负责一部分层通信量小但有流水线气泡适合跨机环境。这里有一个面试官常挖的陷阱让你给一个7B模型设计训练方案。很多人张口就是“8卡A100张量并行加数据并行”。但7B模型用数据并行加ZeRO-2其实更常见因为单机8卡开全参数微调显存完全够用为什么还要做高通信开销的张量并行只有当模型大到单卡放不下单个层或者序列特别长时才真正需要张量并行。能按模型规模和硬件约束去选并行策略而不是无脑堆技术才是架构师该有的样子。7.2 故障与长稳训练中断、慢节点和那笔隐形成本算力规划不是只在项目启动时算一次账运行期间的稳定性成本也必须在面试里体现。训练任务跑到一半节点宕机是常态所以断点续训不是“可选项”而是“必选项”。存检查点不只是存模型权重优化器状态、学习率调度器、数据加载器的offset、随机种子状态全都得存否则恢复后训练结果可能对不上。面试中能讲出这些细节的人多半是真正跑过几十天训练任务的。另一个常见问题是慢节点。集群里有一张卡因为散热或者电压问题降频整个训练任务都会被拖慢因为同步操作要等最慢的节点。排查方式一般是盯训练日志里的step耗时波动一旦出现异常就逐卡检查有没有降频告警、显存ECC错误、网络重传。面试里我们把这类问题称为“算力规划的隐形成本”规划时假设所有卡都满速现实中总有拖后腿的节点所以要么预留冗余节点要么有快速换机流程。7.3 被问到国产算力替代时要怎么答才不翻车这几年面试越来越经常聊到算力替代话题。很多人一上来就评价某类加速卡“好用”或“不好用”这种回答其实很危险。更稳妥的思路是给出一套迁移评估框架第一步看算子兼容性FlashAttention、RMSNorm、RoPE等常用kernel是否支持不支持的话有没有替代实现第二步看多机互联稳定性跨节点通信在大规模训练时是否容易断线第三步看框架生态主流训练推理框架能否无缝接入第四步看实测数据用一个小规模基准测试对比MFU、训练吞吐、推理延迟和稳定性而不是听宣传参数。这套框架既专业又客观还体现了架构师最需要的迁移评估能力。8. 反问环节与收尾把面试变成一次技术对齐8.1 值得反问的五个算力规划问题面试是双向选择算力规划领域的反问往往能帮你看清这个团队的真实水平。我整理了几个比较推荐的问题。第一个问生产环境的GPU利用率大概多少是MFU还是在线利用率这个直接反映公司算力管理水平。第二个问线上推理服务的TTFT和TPOT目标水位从中能判断对方是真正做过性能优化还是停留在能用就行。第三个问训练任务最长跑到过多久断点续训方案是否完善这能看出他们对长稳的重视程度。第四个问容量不够时的决策倾向是加卡还是优先优化模型这决定了你入职后的工作方向。第五个问算力池的分配方式是否有配额、多租户和弹性伸缩这影响日常开发的资源体验。这些问题本身不需要标准答案但你问出来之后面试官心里对你的定位会自动往上提一个台阶因为你展示了自己对算力规划的完整思考。8.2 一点个人建议最后给准备面试的朋友一个实操建议准备一套自己的算账模板。模板不要复杂训练侧记牢“6×参数量×token数、MFU、单卡天数、目标周期反推卡数、显存模型状态16B每参数”这几个数推理侧记牢KV Cache公式、Little定律、TTFT和TPOT。面试前拿公开的7B和70B模型各练两三次能做到几分钟内口算出数量级就够了。我在实际参与面试时最深的体会是面试官通常不在意你给出的数字准不准而在意你有没有推导过程以及能不能表达出假设和不确定性。所以回答任何算力规划问题时可以先亮结论数字再给推导链最后补一句“这只是数量级估算真正上线前我会用小规模压测验证”。这句话说出来基本能让面试官觉得你是一个有工程判断力的架构师而不是一个只会背资料的候选人。