简介面向华为H19-381智能计算售前认证备考者的题库资料内容覆盖服务器、存储、安全、网络与计算等核心知识域包含Taishan服务器、iBMC管理接口、RAID技术、SSD分类、TPM可信平台模块、鲲鹏自研芯片等关键考点适合备考华为售前认证或需要系统搭建智能计算产品知识体系的工程师参考。资料包为1个PDF文件整体约183KB体积小巧便于手机端阅读和打印根据页内预览题目多以单选、多选和判断题形式呈现并附参考答案可直接用于刷题自测与考前速记。目前已有1171人学习下载。这份题库将分散在华为培训材料中的产品参数、安全规范、网卡形态和CPU平台选型等细节浓缩为问答形式帮助读者快速定位易错点与高频考点提升对智能计算售前方案的理解和应答准确率。1. 智能计算售前题库到底在考什么先看懂题面背后的岗位诉求干 HCS Pre-sales 智能计算售前的第一年我花在题库上的时间不少拿到编号 h19-381 的智能计算售前题库时本以为刷完就能应对客户结果第一次模拟就被一道「高校 200 人同时在线要配多少卡」的题问住了。光背答案是没用的客户换一个问法或者把“训练”换成“推理”同一道题就变成另一道题。这套题覆盖 AI 服务器选型、智算中心方案、高校 AI 平台设计、POC 组织这些高频场景本质上考的是「客户抛出一个模糊需求时你脑子里有没有一套稳定的拆解动作」。新手靠它搭骨架熟手靠它查漏补缺这篇就按这个思路往后拆。2. 智能计算售前的四层知识底图从芯片参数到可交付算力我翻过不少售前新人做错的题发现九成不是死在难题上而是死在「不知道这题考的是哪一层」。智能计算售前要同时拽住硬件、软件、方案、商务四根线缺一根方案就是空中楼阁。下面按这四层把题库里反复出现的知识点过一遍。2.1 硬件层AI 加速卡、整机形态与三组必懂参数题库里的选型题无论题干怎么包装最终落到加速卡和整机形态上。训练场景通常看 8 卡训练服务器卡间互联带宽直接决定大模型并行效率推理场景更偏爱 4 卡或高密推理节点因为推理任务单卡占用小拼的是整体并发和功耗。如果连客户说的「训练」「推理」对应哪种整机形态都分不清后面的配置估算从第一步就跑偏。这里有三组参数是售前必须能脱口而出的参数组核心指标方案里翻车的样子单卡算力FP16/BF16 浮点算力、是否支持稀疏计算把 FP16 标称值当 FP32 用集群算力直接虚高两倍显存单卡显存容量、显存带宽模型权重加梯度放不进单卡被迫改模型并行训练吞吐骤降卡间互联互联带宽与拓扑8 卡服务器内部互联不足多卡训练吃掉三成以上并行效率这套参数不需要死记硬背需要建立换算习惯。POC 前我一般会先在现场服务器上跑一遍状态查询把卡数、显存、驱动这些底数摸清楚再回头对方案里的数字。命令各家工具链不同但思路是一样的# 查询加速卡状态与算力信息命令名按现场设备厂商工具而定 npu-smi info # 某类AI加速卡常见查询命令输出包含卡数、显存、算力状态这个命令输出的卡数和显存是后面做容量估算的起点。比如客户说「有 8 张卡要跑 70B 参数模型的微调」先别急着报价先算一张卡的显存能不能装下模型权重加优化器状态。装不下方案就该往模型并行或多卡张量并行方向写而不是继续堆单卡算力。硬件层还有一个高频考点是功耗与机柜密度8 卡训练服务器满负荷功耗不低风冷机柜放几台就顶到散热上限液冷方案不是「加分项」而是高密度场景下的必须项。题库里凡是问「机房条件受限如何提升算力密度」的题答案基本都指向液冷整机柜。2.2 软件层驱动、AI 框架与调度栈的兼容性边界硬件参数只是门槛软件的坑才是题库里区分度的来源。我印象很深的一道题是客户现有训练代码基于 PyTorch 开发想换用新一批 AI 加速卡问迁移工作量主要看什么。很多人选「代码重写量」实际上首先要看算子兼容性——常用的那几个算子在新卡驱动和加速库下有没有对应实现没有的话要么改写算子要么加兼容层工作量差别很大。软件层的知识结构售前至少要拽住三块加速卡驱动与加速库版本框架版本、加速库版本、驱动版本三者的匹配关系是兼容性判断的第一关AI 框架适配范围PyTorch、TensorFlow 等主流框架在目标加速卡上的支持成熟度资源调度层容器、K8s 加 GPU/NPU 调度插件、算力切分能力这层决定多用户共享时资源怎么分。调度层是售前最容易忽略的。客户说要建一个供多个部门共用的 AI 平台你光配好硬件和框架没有算力切分和队列管理最后一定是某个部门的训练任务把集群占满其他部门排队到天亮。售前方案里必须包含资源池化和配额管理这是客户现场冲突的高发点也是方案设计的加分点。还有一种常见问法「训练平台选裸机还是容器化平台」。我的判断口径是单团队、单一框架、人少裸机集群够用多团队、多框架、要配额容器化平台优先。你不用替客户做最终决定但要把两种形态的运维成本和隔离能力讲清楚。2.3 方案层「卖算力」和「交付算力」是两回事前面两层是基础方案层才是售前核心能力。我见过不少新人报方案上来就是「我们给你配 64 张卡算力多少 PFLOPS」然后就没有然后了。客户真正要买的是能跑起来的算力不是纸面峰值。有效算力和理论峰值之间差三道折扣硬件可用性、调度效率、业务适配度。常见的交付形态有三种对应的方案设计逻辑完全不同交付形态适用对象售前主要回答的问题裸金属训练集群单一团队、框架固定卡间互联、存储带宽、作业调度怎么打通容器化调度平台多团队共享、多框架并存资源配额、隔离性、队列优先级怎么设一站式 AI 开发平台高校教学、行业新手数据管理、开发环境、训练作业怎么串成闭环选型顺序不要反。我一般先问客户「谁在用算力、怎么用、用多久」再决定交付形态而不是先拿现有产品套需求。题库里凡是「客户需求很模糊让你给建议」的题答案第一步永远是澄清使用场景而不是报配置。还有一个高频点是训练与推理的分池问题训练任务有波峰波谷推理任务要求稳定在线搅在一起的结果通常是训练一启动推理时延就飙高。方案里最好明确建议是否物理分池或至少在调度策略上给推理任务保留资源下限。2.4 商务层报价口径、POC 范围与交付边界商务层不是销售的事售前如果不参与方案很容易在签单后翻车。这里有件事题库会以「客户问报价」「客户问工期」「客户问服务」的方式出现。第一件是报价口径同样是 100 PFLOPS 算力按整机报、按卡报、按资源池报、按订阅报总价和客户感知完全不同。报价口径在客户那边经常被当成玄学售前要把话说死含不含存储、含不含网络、含不含软件平台授权、含不含入场实施口径含糊的方案最后对账时每一行都是吵架素材。第二件事是 POC 范围。训练场景的 POC 要测吞吐和稳定性推理场景要测时延和并发上限教学场景要测多用户并发登录。POC 不是「把厂商演示环境开给客户看」而是要在客户自己的数据、自己的代码上跑出结果。方案里要写明 POC 环境边界和成功标准避免现场各说各话。第三件事是交付边界液冷方案里冷却液加注和管路施工谁来负责跨机房组网时交换机端口和光模块算谁的软件平台集成的第三方组件出问题找谁响应。这些边界问题看起来是合同条款但售前在方案阶段就该写清楚否则交付阶段还会被拉回去背锅。3. 三类高频售前场景拆解高校、政企智算中心与边缘推理知识框架是底子客户场景才是题目的真实血肉。题库里的大题基本都套在具体行业场景里我挑三个出现频率最高的把从需求澄清到配置估算的拆解过程写出来。这三类场景有一个共同点客户嘴上说的需求和实际要解决的问题中间往往隔着一层。3.1 高校 AI 教学与科研平台一张卡其实撑不起二百人实训高校客户问「建一个支持 200 人同时上课的 AI 平台要多少算力」这是题库里典型的教学场景题也是新手最容易算错的地方。不少人的第一反应是 200 人每人一张卡直接算出 200 张卡。这个答案在真实项目里基本会被推翻因为「同时在线」和「同时跑训练」是两个完全不同的概念。教学实训的真实资源模型是200 人在线一半人在看课件、写代码真正同时发起训练作业的可能只有三四十个任务而这几十个任务里大多是图像分类、文本分类这类小模型单任务占用的显存很小。所以正确步骤是先澄清并发训练任务数再按单任务显存估算而不是按人头数估算。我的计算路径分四步澄清高峰并发拿历史课表或常见选课人数估出同一时间发起训练作业的任务数定单任务规格按课程涉及的模型类型确定单任务需要多少显存和算力算总量并留余量总量乘以 1.2 到 1.5 的并发冗余系数拆分节点类型登录节点、CPU 数据处理节点、AI 训练节点分开配别混在一起。按 36 个并发训练任务、每个任务占用 16GB 显存来估算显存总需求约 576GB单张加速卡按 64GB 显存算训练节点配 8 张卡就够覆盖教学需求再加 2 台 CPU 节点做数据预处理和镜像分发。这个配置比「200 人 200 张卡」小一个数量级但实际使用体验反而更好。这类题的区分点就在你有没有先问并发而不是直接报卡数。估算维度示例取值说明在线人数200 人不是估算起点只是规模上限高峰并发任务数36 个由课程类型和课表决定单任务显存16GB以课程常用模型为参照训练节点配置8 卡 x 64GB含 1.2 倍并发冗余配套节点2 台 CPU 节点负责登录、数据处理、镜像分发高校场景还有一个隐藏考点教学平台要的是「环境快速就绪」。老师上课 45 分钟学生环境初始化花 20 分钟课程就废了。方案里要带容器镜像或预置环境让学生一点开就能用。这一点不写进配置单但决定了客户听完方案后的真实感受。3.2 政企智算中心从总算力到有效算力的应答链路政企客户问得最多的一句话是「我要建一个 500P 的智算中心你们能不能做」。这道题表面是问能力实际在考你有没有先厘清「500P」的定义。不同口径下的 500P成本可能差出两倍。FP16 算力数值通常是 FP32 的两倍稀疏算力又可能是稠密算力的两倍客户报的 500P 到底是稠密 FP16、稀疏 FP16、还是 FP32必须先确认否则后面所有估算都是空中楼阁。我在这类场景里的应对链路固定是三段先定口径再拆配比最后补配套。定口径是确认算力计算标准拆配比是把总算力分成训练集群和推理集群训练集群追求大算力和高互联推理集群追求高并发和低时延补配套是算存储容量、存储带宽和网络架构这三个配套在智算中心里往往比算力本身更能决定交付体验。有效算力的概念在这个场景里特别重要。同样标称 500P 的集群不同调度效率下能实际用于业务的有效算力差别很大有效算力 理论峰值 x 资源可用性系数 x 调度效率系数资源可用性系数要扣掉故障维护窗口、预留资源、备份资源调度效率系数要扣掉任务排队、显存碎片、网络通信开销。两个系数合起来实际有效算力常常只有理论峰值的六到七成。方案里敢把这两个系数写出来的售前客户信任度会明显不一样因为大多数厂商只报峰值。政企场景的配套估算里存储带宽是高频翻车点。训练作业读取数据集时如果存储带宽跟不上加速卡的消费速度加速卡就只能空转等数据。判断口径很简单取「集群并发读带宽」和「单卡数据吞吐 x 卡数」两者中的较小值作为设计目标存储方案按这个目标配带宽而不是按容量堆硬盘。很多智算中心建成后性能不达标查到最后都是存储 IO 成了瓶颈这个坑在方案阶段就能避免。3.3 制造视觉质检的推理场景时延与并发才是真需求制造业的智能计算需求大多是视觉质检一类的推理场景和前面的大规模训练完全是另一套算法。客户说「产线每天拍 50 万张图想上 AI 质检」这时候算训练集群是答非所问真正要做的是推理节点数估算。推理场景的估算逻辑是先算单张图片的推理时延再算产线并发要求最后换算成节点数。我一般用这样的简单模型import math daily_images 500_000 # 每日图片量来自产线实际节拍 single_latency 0.02 # 单张推理时延秒以测试脚本为准 work_hours 8 # 每日有效检测时长小时 peak_multiplier 3 # 峰值倍率产线集中出货时段 redundancy 1.2 # 冗余系数留故障和升级余量 # 平均每秒需处理图片数乘峰值倍率得到高峰期每秒并发需求 avg_rps daily_images / (work_hours * 3600) peak_rps avg_rps * peak_multiplier # 单节点每秒钟能处理的图片数 throughput_per_node 1 / single_latency # 节点数 峰值并发需求 / 单节点吞吐 x 冗余 nodes math.ceil(peak_rps / throughput_per_node * redundancy) print(f建议推理节点数: {nodes})这个模型里最容易被忽略的是峰值倍率。日均图片量除以全天时长得到的是平均值但产线不会匀速生产集中出货时段的需求可能是平均值的几倍。如果按平均值配节点高峰时段时延会飙高质检直接堵线。还有一点推理节点估算的重点是显存容量而不是浮点算力。一张高算力卡如果显存只够放两路推理流再多并发也只能排队所以推理节点选型看显存和显存带宽而不是只盯算力。方向搞反了推理场景的配置单会贵得离谱还不好用。提示上面的代码按单卡单节点计算如果推理节点插了多张卡throughput_per_node记得乘卡数。4. 智能计算售前题目的应答结构选择、方案与沟通题的通用拆法题库刷多了会发现题目是有限的但出题人会换场景、换数字、换角色。与其背题不如建立一套稳定的拆题结构。我把常见题分成三类技术选择题、方案设计题、客户沟通题每一类都有自己的应对顺序。这里面有大量的血泪经验最核心的一条是先判断考什么再决定怎么答。4.1 技术选择题先排绝对项再按可交付性排序技术选择题通常是四选一选项里混着正确但没用的陈述、看似专业但跑偏的陈述、还有绝对化的表述。我的处理分三步先定性再排错最后排序。先定性是判断这道题考的是选型、兼容性还是排错。选型题看需求匹配兼容性题看版本和接口排错题看故障链路。第一步方向定错了后面再纠结选项都是白费。排错这一步优先排除带「所有」「一定」「全部」这类绝对化词的选项技术方案里几乎没有绝对。最后排序时按「满足需求 - 兼容性 - 成熟度 - 成本」的顺序选前两项不满足后面再便宜都不选。举个例子一道题问「训练集群扩容时最优先确认什么」选项里有「存储剩余容量」「卡间互联拓扑」「机房功耗余量」「新卡与现有驱动版本兼容性」。按顺序排答案很明确是兼容性因为硬件和驱动不兼容扩容就是事故。这类题的干扰项不是错误而是「重要但不够优先」比的是优先级判断。4.2 方案设计题需求澄清五问与配置估算固定步骤方案设计题是大题占分最多。这类题的坑在于题干条件永远不够必须在作答前自己补齐关键假设。我固定用需求澄清五问来补条件谁在用用户是算法工程师、数据分析师、还是学生决定平台形态怎么用训练、推理、还是两者都有决定集群配比数据有多少数据集规模、增长趋势决定存储容量和带宽预算和工期决定方案是分步交付还是一次到位现有资产有没有存量服务器、网络设备、框架代码决定兼容策略。五问过完配置估算就是固定步骤先算总算力需求再拆训练推理配比然后选整机形态接着算存储与网络配套最后写成 POC 方案。每一步都要留出明确的假设说明比如「按 FP16 稠密算力估算」「并发冗余按 1.2 倍」客户后续想改参数也知道从哪里下手。答题时还有一个容易被忽视的动作方案要给出「最小可用配置」和「推荐配置」两档。客户预算不确定时两档方案能让他先看到起步成本再决定是否加码。我见过不少新人只给一档结果客户嫌贵直接不回复。两档配置不是让步是给客户一个决策梯度。4.3 客户沟通题先复述需求再问边界沟通题一般给一段客户原话让你判断客户真实需求。比如客户说「我们想搞个 AI 平台能跑大模型」这句话信息量极低——大模型可以是微调、推理、私有化训练平台可以服务几十人也可以服务几千人。直接给方案就是中套。我的做法是先复述需求把客户的话翻译成技术边界。例如「您这边是想把开源大模型部署到私有环境做推理服务还是需要在自己的数据上做微调训练这两者所需的算力和平台功能差别比较大。」复述的目的是让客户纠正你而不是让你猜。沟通题里敢提问的答案分数远高于直接给配置的答案。复述之后要问边界条件并发用户量、数据是否出域、是否需要和现有系统打通、运维团队有没有专人。这些条件决定了安全和部署形态。最后再给一个成熟度判断比如「这类私有化大模型推理方案落地比较多微调训练则要评估数据准备和算法人力」让客户对项目难度有预期。沟通题本质上考的是你能不能把模糊需求变成可以执行的项目边界。4.4 一份能直接背的参数对照速查表刷题到最后真正需要记的是场景和参数的对应关系。我把三类场景的核心指标整理成一张速查表临考前背熟答题时对照题干先定位场景再选参数。场景核心指标常见翻车点大规模训练单卡 FP16 算力、显存带宽、卡间互联只算总算力忽略互联拓扑在线推理单路时延、并发路数、显存容量拿浮点算力衡量推理能力教学实训并发任务数、环境就绪时间、配额管理按在线人数估算显存多团队共享算力切分、队列优先级、隔离性没有配额机制大任务挤死小任务智算中心整体有效算力、存储带宽、配套网络只报理论峰值不报折扣系数这张表不能替代知识框架但能帮你快速定位题目考什么。拿到一道题先看它描述的场景落在哪一行再看题目问的是哪个指标选项里的干扰项就很容易识别。速度和准确率同时提上来刷题效率会高很多。5. 智能计算售前题库里的五个高频坑现象、原因与解法刷题和真实项目最大的共同点就是把同一个坑反复踩。下面五个坑是我从题目和项目对照里筛出来的高频问题每条按「现象 - 原因 - 解决」写你可以直接拿来做自查清单。坑不踩一遍永远不觉得是坑但有些坑在方案阶段就能绕开。5.1 算力单位混用FP16 被当成 FP32 报给客户现象方案里写「集群总算力 400 TFLOPS」客户拿着竞品报告来问为什么别人是 800数字差一倍。两边看起来都在说同一件事但对比毫无意义。原因FP16 算力数值约等于 FP32 的两倍报告里没标注精度口径数值对比就没意义。更多时候是售前自己把 FP16 标称值直接当 FP32 写进了 PPT客户只要跨品牌一问就会露馅。解决所有算力数字必须带精度前缀FP16 就写「FP16 稠密算力」FP32 就写「FP32 算力」。对外对比时先确认对方用什么精度再换算成同一个口径。这个习惯越早养成越好数字一旦被写进标书后面再改就是走流程的麻烦。注意凡是方案里出现 TFLOPS、PFLOPS 这类数值旁边必须同时标注精度和稀疏性缺一个都不算完整口径。5.2 只报理论峰值不报有效算力现象配置单漂亮总算力很高客户上线后跑业务发现速度远不及预期回过头来找售前对质。原因理论峰值是芯片标称值实际集群要考虑调度排队、资源预留、故障冗余、通信开销有效算力通常只剩六到七成。只报峰值等于把不可能达到的数字当成承诺给了客户。解决方案里主动写两组数——理论峰值和预估有效算力并给出系数来源。比如「可用性系数 0.9调度效率系数 0.75预估有效算力为理论峰值 67%」。客户觉得你诚实交付后也不容易产生预期差。这个习惯同时能筛掉那些不看系数的客户他们往往也会在后续环节制造更多麻烦。5.3 训练推理同池推理被训练任务挤死现象训练任务一启动在线推理服务时延飙升前端业务直接超时。客户第一反应是算力不够急着要扩容。原因训练任务会占满整卡算力和显存推理任务和它共享同一批资源时没有优先级保护只能排队。表面看是算力不足实际是资源池缺少隔离和抢占保护机制。解决资源池上做配额和优先级配置给推理服务保留资源下限预算允许时直接物理分池。方案设计阶段就建议客户在调度层加入资源预留而不是等上线后再调整。题库里凡是出现「训练推理混合负载」字样的题考点基本都在这里。5.4 存储带宽没算数据加载变成新瓶颈现象集群算力跑不满加速卡利用率长期偏低训练一步等数据一步。监控上看加速卡没满存储队列倒是堆满了。原因存储方案只配了容量没配带宽。训练作业并发读取数据时存储出口带宽成了瓶颈。容量再大带宽不够数据也只能排队慢慢出。解决按「并发读带宽 单位时间内所有训练任务的数据消费量」来配存储再留 30% 冗余。售前阶段把存储带宽写入配置单而不是留给交付阶段再补。判断口径很简单取「集群并发读带宽」和「单卡数据吞吐 x 卡数」两者较小值为设计目标存储方案的容量和性能分开列。5.5 POC 周期被压缩到只剩压测的那一天现象POC 排期三天客户要求「第一天到货第二天出结果」最后交出来的测试数据里全是环境问题谁也不敢按这个结果做决策。原因POC 不只是压测本身环境准备、驱动和框架安装、客户数据导入、基线测试都要时间。周期被压缩后这些时间只能从压测里挤环境没调好就开跑结果自然没法看。解决POC 计划按三段排期环境准备、兼容性验证、业务压测每段都要有明确完成标准。如果客户坚持压缩就把风险写进确认单让客户知道压缩的是哪部分时间。售前的价值不是答应一切而是把代价摆到台面上宁可多要三天准备时间也不要交一份不能用的压测报告。6. 把题库变成售前弹药库错题打标签与三句话摘要法题库刷完不是终点把它内化成自己的应答习惯才是目的。我现在的习惯是题刷完以后做三道加工错题打场景标签、压缩成三句话、每月一次角色互换自测。这套做法不强求速度但对长期做售前有实打实的帮助。6.1 给错题打上「场景标签」而不是题型标签错题本不要按「选择题」「简答题」分类要按场景分类。同样一道硬伤题在高校客户和政企客户身上表现完全不同。我的标签维度有三个行业场景、技术阶段、客户角色。比如「高校-配置估算-并发算错」刷第二遍时一眼就知道自己在哪个环节容易错比「错题集-第 12 题」有用得多。6.2 用三句话摘要法压缩整套题库每道题做完压成三句话记在文档里问题是什么、答案怎么给、坑在哪里。这个动作比反复刷题更有效因为压缩的过程逼你提炼关键判断。时间久了整套题库会缩成一张能随身带走的速查纸。题目摘要示例三句话高校教学平台配置估算问题200 人同时在线要多少算力答案按并发任务数 36 估算不按人头坑并发和环境就绪时间比总算力更关键智算中心总算力判断问题客户报 500P 是否可信答案先确认 FP16 还是 FP32、稠密还是稀疏坑不确认口径就报价成本可能差两倍6.3 每月一次角色互换自测每月找个固定时间和同事角色互换一个人演客户一个人演售前。客户角色专挑边界模糊的需求来问售前角色要在两分钟内完成复述需求和澄清边界。这套练习对沟通题特别有效因为在真实对话里你才会意识到自己以为说清楚了客户其实一头雾水。我入行时的血泪经验是复盘不能只靠脑子记。每次客户交流结束后把客户问过的问题和题库对照一遍看哪些是题库里有的哪些是题库没有但真实会出现的再补进自己的速查表。我一开始以为刷题是为了通过考核后来才明白题库是给售前搭骨架的真正的血肉要在客户现场长出来。希望这些拆解能帮你在同样的方向上少走一段弯路希望帮到你。本文还有配套的精品资源点击获取