企业官网建设流程全解析

简介：面向华为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 卡或高密推理节点，因为推理任务单卡占用小，拼的是整体并发和功耗。如果连客户说的「训练」「推理」对应哪种整机形态都分不清，后面的配置估算从第一步就跑偏。

这里有三组参数是售前必须能脱口而出的：

这套参数不需要死记硬背，需要建立换算习惯。POC 前我一般会先在现场服务器上跑一遍状态查询，把卡数、显存、驱动这些底数摸清楚，再回头对方案里的数字。命令各家工具链不同，但思路是一样的：

# 查询加速卡状态与算力信息（命令名按现场设备厂商工具而定） npu-smi info # 某类AI加速卡常见查询命令，输出包含卡数、显存、算力状态

这个命令输出的卡数和显存，是后面做容量估算的起点。比如客户说「有 8 张卡，要跑 70B 参数模型的微调」，先别急着报价，先算一张卡的显存能不能装下模型权重加优化器状态。装不下，方案就该往模型并行或多卡张量并行方向写，而不是继续堆单卡算力。硬件层还有一个高频考点是功耗与机柜密度，8 卡训练服务器满负荷功耗不低，风冷机柜放几台就顶到散热上限，液冷方案不是「加分项」，而是高密度场景下的必须项。题库里凡是问「机房条件受限，如何提升算力密度」的题，答案基本都指向液冷整机柜。

2.2 软件层：驱动、AI 框架与调度栈的兼容性边界

硬件参数只是门槛，软件的坑才是题库里区分度的来源。我印象很深的一道题是：客户现有训练代码基于 PyTorch 开发，想换用新一批 AI 加速卡，问迁移工作量主要看什么。很多人选「代码重写量」，实际上首先要看算子兼容性——常用的那几个算子在新卡驱动和加速库下有没有对应实现，没有的话要么改写算子，要么加兼容层，工作量差别很大。

软件层的知识结构，售前至少要拽住三块：

• 加速卡驱动与加速库版本：框架版本、加速库版本、驱动版本三者的匹配关系，是兼容性判断的第一关；
• AI 框架适配范围：PyTorch、TensorFlow 等主流框架在目标加速卡上的支持成熟度；
• 资源调度层：容器、K8s 加 GPU/NPU 调度插件、算力切分能力，这层决定多用户共享时资源怎么分。

调度层是售前最容易忽略的。客户说要建一个供多个部门共用的 AI 平台，你光配好硬件和框架，没有算力切分和队列管理，最后一定是某个部门的训练任务把集群占满，其他部门排队到天亮。售前方案里必须包含资源池化和配额管理，这是客户现场冲突的高发点，也是方案设计的加分点。还有一种常见问法：「训练平台选裸机还是容器化平台」。我的判断口径是：单团队、单一框架、人少，裸机集群够用；多团队、多框架、要配额，容器化平台优先。你不用替客户做最终决定，但要把两种形态的运维成本和隔离能力讲清楚。

2.3 方案层：「卖算力」和「交付算力」是两回事

前面两层是基础，方案层才是售前核心能力。我见过不少新人报方案，上来就是「我们给你配 64 张卡，算力多少 PFLOPS」，然后就没有然后了。客户真正要买的是能跑起来的算力，不是纸面峰值。有效算力和理论峰值之间差三道折扣：硬件可用性、调度效率、业务适配度。

常见的交付形态有三种，对应的方案设计逻辑完全不同：

选型顺序不要反。我一般先问客户「谁在用算力、怎么用、用多久」，再决定交付形态，而不是先拿现有产品套需求。题库里凡是「客户需求很模糊，让你给建议」的题，答案第一步永远是澄清使用场景，而不是报配置。还有一个高频点是训练与推理的分池问题：训练任务有波峰波谷，推理任务要求稳定在线，搅在一起的结果通常是训练一启动，推理时延就飙高。方案里最好明确建议是否物理分池，或至少在调度策略上给推理任务保留资源下限。

2.4 商务层：报价口径、POC 范围与交付边界

商务层不是销售的事，售前如果不参与，方案很容易在签单后翻车。这里有件事，题库会以「客户问报价」「客户问工期」「客户问服务」的方式出现。第一件是报价口径，同样是 100 PFLOPS 算力，按整机报、按卡报、按资源池报、按订阅报，总价和客户感知完全不同。报价口径在客户那边经常被当成玄学，售前要把话说死：含不含存储、含不含网络、含不含软件平台授权、含不含入场实施，口径含糊的方案，最后对账时每一行都是吵架素材。

第二件事是 POC 范围。训练场景的 POC 要测吞吐和稳定性，推理场景要测时延和并发上限，教学场景要测多用户并发登录。POC 不是「把厂商演示环境开给客户看」，而是要在客户自己的数据、自己的代码上跑出结果。方案里要写明 POC 环境边界和成功标准，避免现场各说各话。第三件事是交付边界：液冷方案里冷却液加注和管路施工谁来负责，跨机房组网时交换机端口和光模块算谁的，软件平台集成的第三方组件出问题找谁响应。这些边界问题看起来是合同条款，但售前在方案阶段就该写清楚，否则交付阶段还会被拉回去背锅。

3. 三类高频售前场景拆解：高校、政企智算中心与边缘推理

知识框架是底子，客户场景才是题目的真实血肉。题库里的大题基本都套在具体行业场景里，我挑三个出现频率最高的，把从需求澄清到配置估算的拆解过程写出来。这三类场景有一个共同点：客户嘴上说的需求和实际要解决的问题，中间往往隔着一层。

3.1 高校 AI 教学与科研平台：一张卡其实撑不起二百人实训

高校客户问「建一个支持 200 人同时上课的 AI 平台，要多少算力」，这是题库里典型的教学场景题，也是新手最容易算错的地方。不少人的第一反应是 200 人每人一张卡，直接算出 200 张卡。这个答案在真实项目里基本会被推翻，因为「同时在线」和「同时跑训练」是两个完全不同的概念。

教学实训的真实资源模型是：200 人在线，一半人在看课件、写代码，真正同时发起训练作业的可能只有三四十个任务；而这几十个任务里，大多是图像分类、文本分类这类小模型，单任务占用的显存很小。所以正确步骤是先澄清并发训练任务数，再按单任务显存估算，而不是按人头数估算。我的计算路径分四步：

1. 澄清高峰并发：拿历史课表或常见选课人数，估出同一时间发起训练作业的任务数；
2. 定单任务规格：按课程涉及的模型类型，确定单任务需要多少显存和算力；
3. 算总量并留余量：总量乘以 1.2 到 1.5 的并发冗余系数；
4. 拆分节点类型：登录节点、CPU 数据处理节点、AI 训练节点分开配，别混在一起。

按 36 个并发训练任务、每个任务占用 16GB 显存来估算，显存总需求约 576GB；单张加速卡按 64GB 显存算，训练节点配 8 张卡就够覆盖教学需求，再加 2 台 CPU 节点做数据预处理和镜像分发。这个配置比「200 人 200 张卡」小一个数量级，但实际使用体验反而更好。这类题的区分点就在你有没有先问并发，而不是直接报卡数。

高校场景还有一个隐藏考点：教学平台要的是「环境快速就绪」。老师上课 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 方案设计题：需求澄清五问与配置估算固定步骤

方案设计题是大题，占分最多。这类题的坑在于题干条件永远不够，必须在作答前自己补齐关键假设。我固定用需求澄清五问来补条件：

1. 谁在用：用户是算法工程师、数据分析师、还是学生，决定平台形态；
2. 怎么用：训练、推理、还是两者都有，决定集群配比；
3. 数据有多少：数据集规模、增长趋势，决定存储容量和带宽；
4. 预算和工期：决定方案是分步交付还是一次到位；
5. 现有资产：有没有存量服务器、网络设备、框架代码，决定兼容策略。

五问过完，配置估算就是固定步骤：先算总算力需求，再拆训练推理配比，然后选整机形态，接着算存储与网络配套，最后写成 POC 方案。每一步都要留出明确的假设说明，比如「按 FP16 稠密算力估算」「并发冗余按 1.2 倍」，客户后续想改参数，也知道从哪里下手。

答题时还有一个容易被忽视的动作：方案要给出「最小可用配置」和「推荐配置」两档。客户预算不确定时，两档方案能让他先看到起步成本，再决定是否加码。我见过不少新人只给一档，结果客户嫌贵直接不回复。两档配置不是让步，是给客户一个决策梯度。

4.3 客户沟通题：先复述需求再问边界

沟通题一般给一段客户原话，让你判断客户真实需求。比如客户说「我们想搞个 AI 平台，能跑大模型」，这句话信息量极低——大模型可以是微调、推理、私有化训练，平台可以服务几十人也可以服务几千人。直接给方案就是中套。

我的做法是先复述需求，把客户的话翻译成技术边界。例如「您这边是想把开源大模型部署到私有环境做推理服务，还是需要在自己的数据上做微调训练？这两者所需的算力和平台功能差别比较大。」复述的目的是让客户纠正你，而不是让你猜。沟通题里，敢提问的答案分数远高于直接给配置的答案。

复述之后要问边界条件：并发用户量、数据是否出域、是否需要和现有系统打通、运维团队有没有专人。这些条件决定了安全和部署形态。最后再给一个成熟度判断，比如「这类私有化大模型推理方案落地比较多，微调训练则要评估数据准备和算法人力」，让客户对项目难度有预期。沟通题本质上考的是你能不能把模糊需求变成可以执行的项目边界。

4.4 一份能直接背的参数对照速查表

刷题到最后，真正需要记的是场景和参数的对应关系。我把三类场景的核心指标整理成一张速查表，临考前背熟，答题时对照题干先定位场景，再选参数。

这张表不能替代知识框架，但能帮你快速定位题目考什么。拿到一道题，先看它描述的场景落在哪一行，再看题目问的是哪个指标，选项里的干扰项就很容易识别。速度和准确率同时提上来，刷题效率会高很多。

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 用三句话摘要法压缩整套题库

每道题做完，压成三句话记在文档里：问题是什么、答案怎么给、坑在哪里。这个动作比反复刷题更有效，因为压缩的过程逼你提炼关键判断。时间久了，整套题库会缩成一张能随身带走的速查纸。

6.3 每月一次角色互换自测

每月找个固定时间，和同事角色互换，一个人演客户，一个人演售前。客户角色专挑边界模糊的需求来问，售前角色要在两分钟内完成复述需求和澄清边界。这套练习对沟通题特别有效，因为在真实对话里你才会意识到，自己以为说清楚了，客户其实一头雾水。

我入行时的血泪经验是：复盘不能只靠脑子记。每次客户交流结束后，把客户问过的问题和题库对照一遍，看哪些是题库里有的，哪些是题库没有但真实会出现的，再补进自己的速查表。我一开始以为刷题是为了通过考核，后来才明白题库是给售前搭骨架的，真正的血肉要在客户现场长出来。希望这些拆解能帮你在同样的方向上少走一段弯路，希望帮到你。

本文还有配套的精品资源，点击获取