AI 大模型与算力基础设施

01 · AI 技术地图与模型选择

返回目录

先分清模型会什么，再判断客户需要什么。

为什么需要这张地图

客户说“我们要上大模型”，常常把预测销售额、识别发票和知识问答放在同一个需求里。售前首先要把业务问题拆开：输入是什么，输出是什么，出错的代价是什么，现有数据能否支撑。选错任务范式，比选错一个模型版本影响更大。已有结构化数据上的稳定预测，未必需要能聊天的大模型。

大白话：工具箱里的不同工具

人工智能（Artificial Intelligence，AI）是让计算机完成通常需要人类智能的任务的总称。机器学习（Machine Learning，ML）让系统从数据中学出规律，例如根据历史订单预测销量。深度学习（Deep Learning，DL）使用多层神经网络学习复杂特征；神经网络（Neural Network）是由大量带可调权重的计算单元组成的函数，并不是脑细胞的数字复制。

生成式人工智能（Generative AI）重在产生新内容，例如文字、图像和代码。传统分类模型像“把邮件分到不同格子”，生成模型像“根据要求写一封新邮件”。两者没有先进与落后的简单排序，风控规则、检索和生成可以组成同一系统。

技术原理：训练目标决定基本能力

大语言模型（Large Language Model，LLM）通常在大量文本上学习上下文与下一个文本单元之间的统计关系。它的参数规模和训练数据让同一模型可以完成多种语言任务，但不能由“大”直接推出“事实正确”。视觉语言模型（Vision-Language Model，VLM）把图像特征与语言任务结合，可以解释截图或读取文档页面；多模态模型（Multimodal Model）处理两类及以上模态，可能涉及图像、音频、视频，而不只是图片加文字。

预训练（Pretraining）是先从广泛数据中学习通用表示；基础模型（Foundation Model）是可供多类下游任务适配的底座。指令模型（Instruction-tuned Model）在底座上学习按用户要求回答；推理模型（Reasoning Model）通常通过训练及更多推理时计算改善多步骤问题表现。推理模型不是逻辑上永不出错的证明器，额外思考还可能增加时延和输出成本。

真实场景：一个集团的三种需求

教学案例：财务需要读取扫描发票，客服需要根据手册回答，经营团队需要预测下月现金流。可分别组合文档识别与校验、检索加语言生成、结构化预测模型。共用身份认证和监控平台，并不意味着必须共用同一个最大模型。用真实样本验证每种任务，比让一个通用模型在演示中“什么都会一点”更有说服力。

售前视角：能力之外还有使用权

闭源模型（Closed Model）通常通过服务接口提供能力，内部参数不公开；开放权重（Open Weights）允许获得训练后的参数，但能否商用、再分发或用于训练其他模型取决于许可证。开源（Open Source）不能只看“能下载”，还要检查具体开放范围和许可。模型代码、权重、训练数据的许可可能不同。

比较方案时同时记录任务质量、数据流向、部署条件、可接受时延、持续成本和许可证限制。私有化部署能减少数据流出，但不自动满足全部安全要求；公开模型也不意味着数据来源和用途没有限制。客户强调国产化时，应分别确认芯片、框架、模型、操作系统和供应链要求。

面试怎么说

“我会先把客户需求拆成预测、理解与生成任务，再比较模型能力、部署边界和成本。大模型适合自然语言交互和跨任务生成，但涉及精确计算、权限判定和业务写入时，我会让受控工具或业务规则负责。对于开放权重模型，还要核查商业许可，而不是只看下载链接。”

容易混淆

参数更多不等于每项任务都更好；开放权重不等于没有使用限制；多模态不等于能可靠识别所有扫描件；模型输出自然不等于它已经验证事实。售前可以承诺交付评估方法和系统边界，不能把演示表现直接当成生产承诺。

返回目录

02 · 一句话怎样变成下一个 Token

返回目录

把分词、向量、注意力和逐词生成连起来。

为什么文字需要变成数字

计算机做矩阵运算，不能直接对“北京”两个汉字求乘积。必须先建立文本与数字之间的映射，再让网络学习数字表示之间的关系。这里有两件不同的事情：给文本片段一个编号，以及把编号转换为可以参与计算的数值向量。不要把这两步混为一谈。

大白话：字典编号与语境笔记

词元（Token）是模型处理文本的基本单元，可能是一个字、半个英文单词、标点或一段常见文本。分词（Tokenization）按分词器规则把文本切成单元，再查词表得到 Token ID。编号像书的索引号，本身没有大小上的语义关系；编号为一百的词，并不比编号为五十的词“多一倍意义”。

嵌入（Embedding）把编号映射成一串数，也叫向量（Vector）。向量像为每个词做的多维笔记。真实维度通常不是人为指定的“性别、情绪、价格”等固定标签，而是训练形成的分布式表示。同一个词进入网络后，会随上下文获得不同的隐藏表示。

技术原理：从输入到概率

以“北京的首都是”作为教学反例：模型可能顺着熟悉句式生成看似合理的文本，却没有认真校验“北京是城市”的前提。处理链路是：分词器给出编号，嵌入层查出向量，加上位置信息，多层 Transformer 处理上下文，输出层计算词表中各词元的分数，再转成概率并选择下一项。把选中的词元追加到上下文，重复这个过程，直到结束标记或长度上限。

Transformer 是以注意力机制为核心的神经网络架构名，不是英文缩写。注意力（Attention）让一个位置按相关程度聚合其他位置的信息。自注意力（Self-Attention）指查询和被关注的信息来自同一序列。典型解码器模型使用因果掩码，只能参考当前位置及之前内容，避免训练时偷看未来答案。

查询（Query，Q）表示“当前想找什么”，键（Key，K）表示“每个位置可以怎样被匹配”，值（Value，V）表示“匹配后实际汇总什么内容”。它们由输入表示经不同的可学习线性变换得到，不是三个独立的数据库。注意力用 Q 与 K 的相似程度形成权重，再对 V 加权求和。多头注意力允许不同子空间学习不同关系，但不能把某一头固定解释成主语或宾语。

位置编码（Positional Encoding）为网络提供先后和相对距离信息，否则单靠内容匹配难以区分“甲追乙”和“乙追甲”。现代模型可能用旋转位置编码等方法。Transformer 层还包含前馈网络、残差连接和归一化：前馈网络进一步变换特征，残差有助于信息与梯度传播，归一化帮助稳定计算。

训练为什么会改变回答

训练（Training）先根据已有参数给出预测，计算预测与训练目标之间的损失，再通过反向传播求各参数对损失的影响，用优化器更新参数。像反复做练习并按误差修正习惯，网络学的是可泛化的统计规律，也可能记住部分训练文本。推理（Inference）使用已经训练好的参数生成结果，普通聊天并不自动修改权重。

训练时可以利用已知完整样本并行计算许多位置的损失；生成时新词依赖先前生成的内容，因此通常逐词元推进。不能把 GPU 擅长并行计算误解为它可以任意同时生成整个答案。

真实场景：合同问答为什么还会出错

上下文窗口（Context Window）限制一次处理可容纳的词元数量，实际接口还可能分别限制输入与输出。系统提示、历史消息、检索材料、工具结果和预留输出都要计入预算。一本合同放不下时，不能期待模型自动记住未发送的页。

幻觉（Hallucination）是输出缺乏事实依据或与证据冲突的内容。语言流畅来自生成目标，不是外部事实核验。缺少知识、检索错误、问题前提错误、训练偏差和高随机性都可能诱发。即使材料在窗口内，也不保证每条内容都被准确利用。

售前视角与面试回答

“我会把模型理解为学习语言规律的生成系统。文本先变成词元编号和向量，注意力根据上下文汇总信息，网络预测下一个词元，再循环生成。它不是实时查询所有事实的数据库，所以企业问答需要提供可靠证据、来源引用和拒答策略。”

对客户要用真实合同做长文本测试，观察跨页引用、否定条件、表格和版本冲突，不能只根据标称上下文长度选型。记录输入和输出词元数，也是在为后续显存与吞吐规划积累证据。

容易混淆

一个 Token 不恒等于一个汉字；Embedding 不等于可逆压缩全文；注意力权重不是可靠的因果解释；模型会生成解释，不代表解释真实反映内部计算；普通推理不等于在线训练。

返回目录

03 · 参数、精度与显存：为什么能加载还不够

返回目录

理解 70B × 2 字节，以及权重之外的成本。

为什么售前必须会算

客户拿到“这张卡能运行某模型”的截图，接着要求全公司使用。单人启动成功只证明某次运行条件下能够完成请求，没有说明长文本、多个请求、稳定时延以及故障恢复。容量规划至少要分别考虑模型权重、请求产生的状态和框架工作空间，并预留运维余量。

大白话：厨房设备与同时开火

参数（Parameter）是训练中学到的可调数字。7B、32B、70B 中 B 是 Billion，分别表示约七十亿、三百二十亿、七百亿参数。权重像厨房固定设备，请求状态像正在加工的食材，工作空间像操作台。厨房放得下设备，不代表能同时接一千桌订单。

模型参数量与能力存在联系，但数据质量、架构、训练策略和任务适配同样关键。混合专家模型（Mixture of Experts，MoE）每次可能只激活部分专家；总权重需要存储或分层加载，而每词元计算涉及的活跃参数与总参数不是一个数字。

技术原理：精度不是型号标签

单精度浮点（FP32，32-bit Floating Point）每个数占四字节；半精度浮点（FP16）和脑浮点（BF16，Brain Floating Point 16）通常每个数占两字节。BF16 与 FP16 的数值范围和有效精度分配不同，不能只用“都是十六位”判断稳定性。FP8 是八位浮点格式族；INT8 和 INT4 是八位、四位整数表示。低位宽是否能加速，取决于硬件和推理内核是否真正支持对应路径。

理论权重字节数＝参数数量 × 每个参数的位数 ÷ 8。七百亿参数乘以两字节，得到一千四百亿字节，也就是约 140 GB，按二进制换算约 130.4 GiB。这里 GB 按十亿字节，GiB 按二的三十次方字节。实际模型文件还可能有元数据、量化比例因子和不同精度的层。

量化（Quantization）把较高精度的数值映射到较少位数的表示，通常配合缩放因子，有时还有零点。类似把精密刻度改成粗刻度以节省空间，代价是近似误差。权重量化不必然量化激活或缓存；某些低位权重在计算时还要反量化。模型在专业术语、代码或长推理上的质量变化必须实测。

预填充与解码：两种不同的忙法

预填充（Prefill）处理输入提示，建立当前上下文的内部状态；解码（Decode）不断生成后续词元。键值缓存（Key-Value Cache，KV Cache）保存已处理位置在各注意力层的 K 和 V，以避免每次生成都重复计算全部历史。缓存不是把整个答案提前算好，也不是共享给所有用户的通用知识库。

缓存占用取决于层数、每层键值头数、每头维度、缓存精度、序列长度和同时活跃的序列数。分组查询注意力（Grouped-Query Attention，GQA）让多个查询头共享较少的键值头，可能降低缓存需求。只知道“70B”不能准确计算缓存。长上下文和并发叠加，通常会明显增加显存压力。

数字例子：不要把三种量加错

教学假设：某模型有 80 层、8 个键值头、每头 128 维，缓存用两字节，每个请求已经缓存 8192 个词元。其 KV Cache 约为 2 × 80 × 8 × 128 × 8192 × 2 字节，即 2.5 GiB；八个同长度活跃请求约 20 GiB。这个结果来自指定结构，并不代表所有 70B 模型。

除了约 130.4 GiB 的 BF16 理论权重，还要加缓存、激活、临时缓冲、通信缓冲和框架保留空间。多卡并行还受到权重切分方式、缓存分配和互联效率影响，所以简单相加卡片容量并不能证明方案可运行。

售前视角与面试回答

“我会先分开计算权重、KV Cache 和运行时开销。70B 的 BF16 权重约 140 GB，但这只是底数。再根据模型配置、上下文分布、活跃并发和服务框架做估算，最后用目标业务压测验证吞吐与尾时延。单卡能加载，只说明容量的第一道门槛通过了。”

对外报价先给出假设和可验证的容量区间，不能用纸面峰值算力承诺每秒生成多少词元。量化方案要在同一测试集上比较质量、时延和吞吐，而不是只报显存下降比例。

容易混淆

训练显存通常还包含梯度和优化器状态，不能照搬推理权重公式。显存占用高不等于计算单元忙；GPU 利用率高也不等于用户体验好。权重 INT4 不意味着 KV Cache 自动变成四位。GB 与 GiB 需要统一后再比较。

返回目录

04 · 提示、微调与蒸馏：怎样改变模型行为

返回目录

先判断缺的是知识、行为，还是推理效率。

为什么“微调一下”不是万能药

客户发现回答不懂公司制度，容易要求重新训练。实际上，制度今天更新、明天撤销，常常更适合检索最新材料；输出格式不稳定，可以先设计约束和示例；只有任务行为长期稳定且有高质量训练样本时，微调才值得进入候选。把知识更新、行为学习和资源优化分开，是降低项目风险的重要能力。

大白话：当场说明、专项训练和学徒学习

提示（Prompt）是本次请求给模型的任务说明、示例和材料。系统提示（System Prompt）用于表达应用角色和规则，但它不是不可绕过的安全边界。提示工程（Prompt Engineering）是系统地设计输入与输出约束，并用测试集验证效果。

监督微调（Supervised Fine-Tuning，SFT）用输入及期望输出的样本继续训练模型，让它学习目标回答方式。低秩适配（Low-Rank Adaptation，LoRA）在冻结大部分底座权重的同时训练较小的低秩更新矩阵；量化低秩适配（Quantized Low-Rank Adaptation，QLoRA）以量化底座配合可训练适配器，降低训练资源门槛。两者是适配技术，不能据此断言部署后质量不变或速度必然提升。

技术原理：先控制输入，再考虑改参数

温度（Temperature）影响概率分布的尖锐程度：较低通常让高概率候选更突出，较高增加多样性，但不是准确率旋钮。核采样（Top-p / Nucleus Sampling）在累计概率达到阈值的候选集合中采样，控制候选范围；最大生成词元数（Max Tokens）限制输出预算，不是输入窗口大小。不同接口的参数命名与支持范围可能不同。

可靠提示应说明任务、可用材料、输出结构、证据规则和信息不足时的处理方式。以制度问答为例，要求只依据已授权的现行制度回答，按结论、条件、来源组织，材料缺失时说明缺失项。再用冲突版本、诱导提问、无答案问题验证，而不是只凭一两次成功就冻结提示。

完整训练或全参数微调会更新更多权重，通常需要更多计算、显存和数据治理。LoRA 限制可训练的更新规模，适合资源受限的任务适配，但并不免除数据清洗、训练验证和版本回滚。QLoRA 的量化主要发生在底座存储与计算路径上，适配器仍需要训练；它不是“直接把模型变成四位就完成学习”。

蒸馏与压缩：把能力搬到更小的系统

知识蒸馏（Knowledge Distillation）让学生模型学习教师模型的输出、概率或中间表示，以获得更小、更快或更适合某任务的模型。模型压缩（Model Compression）还包括剪枝、量化等路线。蒸馏不保证学生在所有任务上等同教师，训练数据和教师输出的使用许可也要检查。

教学场景：大量客服请求只需把工单归为十种类型，可以让较强模型帮助生成经人工审核的样本，再训练小模型处理大多数请求。复杂或低置信度情况升级给大模型。收益来自任务分流和系统设计，而不只是“模型越小越省”。

售前选择顺序

先建评估集，再优化提示与结构化输出；需要最新企业知识时加检索；行为、术语或格式仍不达标且有合规样本时，尝试微调；规模化运行出现成本压力时，再考虑蒸馏、量化和分流。每一步都记录对质量与成本的增量影响。

验收数据必须与训练数据隔离，避免把记住样例误当泛化。还要检查微调后通用能力是否退化、拒答是否失效、敏感信息是否被记忆，以及多个适配器如何发布和回滚。售前应把数据准备和评估工作明确列入交付范围。

面试怎么说

“RAG 更像查资料，微调更像练习做事方法。我会先判断问题来自知识缺失还是行为不匹配。对频繁更新且需要引用的企业制度，优先检索；对稳定的专用输出规范，可在有高质量样本的前提下评估 SFT 或 LoRA。两者也可以组合。”

容易混淆

降低温度不能消除幻觉；系统提示不能代替权限检查；微调不保证记住每条公司知识；LoRA 不等于只修改提示；蒸馏不等于文件压缩；训练样本多不等于训练样本好。

返回目录

05 · 从 5000 份文件到可信答案

返回目录

把入库和查询分开理解，建立 RAG 全景。

为什么普通聊天不够

客户有五千份内部技术手册、产品说明和管理制度，希望员工直接提问。普通语言模型可能从未见过这些私有文件，也不知道哪一版现行有效、当前用户能看哪些材料。把文件一次性全部放进提示，往往超过上下文预算，而且重复发送成本高、查找不稳定。把知识写入模型参数，也难以逐条更新、撤销和提供可信出处。

检索增强生成（Retrieval-Augmented Generation，RAG）先从外部资料找出与问题有关的证据，再让模型依据这些证据组织回答。它把知识维护与模型生成部分解耦，适合频繁更新、需要引用来源的企业知识。RAG 可以降低缺少知识造成的错误，但不是“接上数据库就不幻觉”。

大白话：开卷考试也要找对书

把模型想成会写答案的助理，把知识库想成资料室。助理先找书，再阅读相关页，最后解释。资料室如果把旧制度放在最前面，助理再能写也可能答错；如果助理无权看某份材料，不能让它先看完再要求它保密。正确的资料、检索、权限和引用，都是答案质量的一部分。

技术原理：入库链路

入库阶段负责把文件变成可检索的知识单元。采集连接器从文件系统、文档平台或网页获取内容，并记录来源和版本。解析器识别标题、正文、表格和页码；光学字符识别（Optical Character Recognition，OCR）把扫描图片中的文字识别出来。清洗去掉重复页眉、乱码和无用导航，同时保留表格条件、单位、标题层级与原文定位。

随后进行文本分块（Chunking），将材料切成可独立理解又不过长的段落。嵌入模型把每个块转换成向量，索引系统保存向量以及文档编号、版本、有效期、页码、权限标记等元数据。原文件和完整正文通常另有存储，索引引用它们。索引建立只是一个阶段，还需要入库失败重试、质量抽检和更新流水线。

技术原理：查询链路

查询阶段先验证用户身份并取得授权范围，对问题做必要的规范化；使用与索引兼容的嵌入模型生成问题向量，配合关键词检索找候选。Top-K 表示取排名前 K 个结果。候选经过权限与有效期过滤、重排序、去重，形成有限的上下文材料。模型收到问题、证据及回答规则，生成答案；应用检查引用是否指向真实片段，并把可访问的来源展示给用户。

上下文构造（Prompt Context Construction）要兼顾证据覆盖和词元预算：既不能把全部候选无差别塞入，也不能只给一小句导致条件丢失。问题涉及多个产品时，可能需要多次检索并合并证据。必要时先澄清产品型号或制度适用地区，而不是让模型猜。

真实场景：报销与产品支持不同

制度问答通常要求现行版本、适用组织和明确条款；技术支持还可能依赖产品型号、软件版本、错误码和故障上下文。教学案例：员工问“出差住宿最高报多少”，系统应先确认地区、职级、出差日期等必要条件，而不是直接选一个最常见金额。

回答可以是“根据现行制度，您给出的条件还缺少出差城市；请补充城市后确定额度”，并展示制度来源。明确不足比编造数字更有价值。引用必须来自检索结果的真实标识，不能让模型自由创造文件名和页码。

售前视角：交付的是链路

需求访谈应获取文件数量、总页数、格式占比、更新频率、权限来源、语言种类、典型问题和验收样本。五千份文件可能是五千张单页，也可能包含大量扫描件和超长手册，仅按文件数量估工作量会失真。

方案范围要覆盖连接器、解析、索引、问答、权限、监控与运营。先选有代表性的资料做概念验证（Proof of Concept，PoC），把“数据能否整理”和“模型能否回答”分别验证。不要把 PoC 演示中的人工整理工作隐藏起来，到了生产才发现需要长期人工维护。

面试怎么说

“我会把 RAG 拆成入库和查询两条链路。入库保证资料可读、可追溯、可更新；查询保证按权限找证据、按相关性排序并带来源回答。上线后持续评估召回与答案质量，并对没有证据或存在冲突的情况拒答或澄清。”

容易混淆

向量数据库不是整个知识库系统；引用标记不证明结论被原文支持；RAG 不替代文档治理；五千份文档不等于五千个向量；不需要微调不代表不需要数据准备。

返回目录

06 · 文档解析与分块：答案质量的上游

返回目录

扫描件、表格和更新，往往比模型选型更费功夫。

为什么检索前就可能失败

原文写着“特殊岗位另行审批”，解析时这句话被页脚清洗误删，后面检索再准确也找不到限制条件。表格中的金额与列标题错位，系统就可能把市内交通补贴当作住宿限额。这类错误不在模型生成阶段，改提示或换大模型往往只能掩盖问题。

大白话：把整本书整理成带索引的卡片

文本块（Chunk）像资料卡片：太短只剩一个数字，看不懂适用条件；太长像把整章塞进一张卡片，主题混杂，检索和生成都不够聚焦。分块长度（Chunk Size）是每块的目标大小，重叠（Overlap）让相邻块重复少量内容，减少跨边界信息丢失。它们要结合分词器计数，并不是一个适用于所有资料的固定字符数。

技术原理：先看结构，再决定切法

对结构清晰的手册，可以按章节、段落和句子递归切分，保留标题路径作为每块的背景。教学起点可尝试数百词元的块与适度重叠，但必须用实际问题验证，不能把这个范围写成行业最佳值。条款、代码函数和完整表格尽量维持语义边界，过长时用带重复表头的子块。

父子块检索是一种折中：用较小子块提高匹配精度，命中后取其父段落补全背景。窗口扩展可把邻近段落一并带回，但需要权限一致，并且不能无限扩大上下文。对于页面图片，保留页码、坐标与截图引用有助于人工核对；如果使用视觉模型解析，也要评估识别错误和成本。

数字型表格最好保存结构化行列，同时生成便于语义检索的文本描述。涉及金额求和、跨月汇总时，可以让受控查询或计算工具处理结构化数据，再由模型解释结果。不要指望仅靠“把整张表转成一句话”保留所有数值关系。

清洗与可追溯：不要只保留干净文本

去重时要区分内容重复和适用范围不同：两个分公司制度标题相同，但审批链可能不同。保留文档标识、内容哈希、版本、有效起止日期、来源链接、页码、解析器版本和入库时间。内容哈希帮助识别变化，版本和有效期帮助筛选现行材料；入库时间不能替代生效时间。

更新时以稳定文档 ID 关联新旧版本，先生成并验证新索引，再原子切换可见版本或索引别名，最后清理旧块。删除原文件后要同步删除检索索引、缓存和必要的派生数据。业务要求保留历史制度时，应按查询日期选择，而不是永久把旧版设为不可查。

真实场景：扫描报销制度

教学案例：一百页扫描制度中，有五页表格倾斜。先抽取有代表性的困难页，记录文字错误率、列对应关系和条款完整性；对于识别不可靠的页进入人工复核队列。验收问题必须覆盖表格交叉条件，如“海外长期出差是否适用普通额度”，而不仅是文档标题查询。

当一个块命中“住宿标准”，返回材料应包含地区列、职级列、币种、适用日期及例外说明。否则即使检索分数很高，答案也缺少业务意义。对需要人工校验的数据，可在前台提示“原文识别存在疑问，请查看扫描页”，避免装作确定。

售前视角：数据治理要有工作量边界

报价前抽样估算扫描件、复杂表格、图片和重复文件占比。定义连接器范围、自动解析成功标准、人工处理责任和增量更新时效。是否包含历史资料清洗、是否要接现有文档权限系统，应写进范围说明。

PoC 比较不同分块方案时，控制嵌入模型和检索设置不变，只改变分块策略，观察正确证据能否进入候选以及最终答案是否完整。逐项改变便于定位收益，不能同时换模型、块长和提示后就把改进归因于某个组件。

面试怎么说

“分块是为检索和上下文预算服务。小块更聚焦，但容易丢条件；大块信息完整，却可能主题混杂。我会优先保留标题、条款和表格结构，必要时用子块检索、父块补充，并用代表性问题验证，而不是固定一个块长就交付。”

容易混淆

重叠越大不一定越好，会增加存储、重复召回和上下文浪费；OCR 识别出文字不代表还原了阅读顺序；文件上传成功不等于索引完成；索引完成不等于数据质量通过。

返回目录

07 · 向量、相似度与检索组件

返回目录

理解向量空间，也理解相似不等于正确。

为什么关键词不总够用

用户问“笔记本连不上公司无线网”，文档写的是“终端无法接入企业 WLAN”。只找完全相同的词，可能错过相关文档。语义检索希望把表达不同但含义相近的内容联系起来。与此同时，型号、错误码和合同编号又要求精确匹配，所以语义并不能替代所有关键词需求。

大白话：把意思放进一张地图

向量是一列有序数字，例如 [0.2, -0.4, 0.7] 是三维向量。可以把它想成内容在语义地图上的坐标，但真实模型往往有数百到数千维，不适合逐维赋予人类标签。嵌入模型（Embedding Model）通常经过训练，使相关文本的表示更接近、不相关文本更远；效果取决于训练任务、数据、语言和领域。

聊天模型主要生成后续词元，检索嵌入模型主要输出适于比较的固定维度向量。两者都可能用 Transformer，但接口、训练目标与评估方法不同。不能直接把聊天模型输出的几句话当作向量，更不能混用两个不兼容模型生成的文档向量和问题向量。

技术原理：余弦相似度

余弦相似度（Cosine Similarity）＝向量点积 ÷ 两个向量长度的乘积。点积是对应维度相乘再相加，向量长度是各维平方和再开平方。它衡量方向接近程度，零向量的余弦没有定义。

数字示例：A＝[1,0]，B＝[0.8,0.6]。点积为 0.8，两个长度都为 1，因此相似度为 0.8。若 C＝[0,1]，A 与 C 的相似度为 0。实际检索分数分布与模型、距离函数有关；0.8 不能跨模型解释成统一的“八成正确”。即使余弦很高，也只是表示相关，不能证明文档现行有效或结论被支持。

稠密检索（Dense Retrieval）使用大部分维度有数值的向量表示语义。数据量大时逐个精确计算代价高，可以用近似最近邻（Approximate Nearest Neighbor，ANN）索引减少候选比较，通常以部分召回损失换取速度。检索索引参数、数据规模与过滤条件会共同影响结果。

向量数据库到底存什么

向量数据库（Vector Database）保存向量、标识以及用于过滤和回查的元数据，通常提供索引、查询和持久化能力。原始文本可以在其中，也可以在外部文档存储。每个结果应能追溯到具体文档块；仅保存一串浮点数而没有来源和权限标记，无法构成可交付的企业知识库。

FAISS（Facebook AI Similarity Search）是相似度检索与聚类库，适合嵌入应用和实验，不自带完整企业数据库治理。Milvus 是独立向量数据库，适合把向量检索作为服务管理。pgvector 是 PostgreSQL 的向量扩展，适合结合已有关系数据和 SQL。三者不能仅按“哪个名字更专业”选型。

真实场景：同义词与产品型号

教学案例：查询“怎么重置管理密码”，语义检索可能召回多个型号手册。它找到了主题，却没有确认用户使用哪一款设备。再把产品型号、版本和租户作为过滤条件，候选才有业务意义。

如果公司已有可靠 PostgreSQL 运维团队，规模和时延需求允许，可以先验证 pgvector；若需要独立扩展的向量服务，可评估 Milvus；在单机原型和定制检索中，FAISS 能减少搭建成本。选择结论要基于数据量、更新频率、过滤复杂度和运维能力，不应宣称某工具适用于所有场景。

售前视角与面试回答

“嵌入把文本映射为可比较的向量，训练让语义相关的文本通常靠近。检索分数代表相关程度，不代表答案正确。企业场景还需要型号、有效期和权限过滤，以及关键词和重排序。检索组件方面，我会分别比较库、独立数据库和关系数据库扩展的运维边界。”

PoC 时用包含同义表达、否定句、错误码和跨语言问题的测试集比较嵌入模型；记录每个问题的正确证据位置，再观察它是否进入 Top-K。模型升级通常需要重新嵌入并重建索引，不能仅替换查询端模型。

容易混淆

向量维度越多不保证检索越好；相似度不是置信概率；向量数据库不会自动理解权限；近似索引的过滤可能减少实际返回数量，写了 Top-K 不保证得到 K 条合格证据；二维图只是教学投影。

返回目录

08 · 混合检索与重排序：先找全，再选准

返回目录

让语义、关键词和逐对判断各司其职。

为什么高相似度仍会找错

错误码 E104 与 E140 在自然语言环境里可能非常接近，但解决方式不同。“可以报销”和“不可以报销”共享大量词汇，却可能表达相反结论。仅靠单一检索方式容易漏掉精确标识或关键否定条件。可靠系统通常先扩大候选覆盖，再做更精细的判断。

大白话：两位资料员与一位审稿人

一位资料员按意思找资料，一位按关键词找资料，把结果合并；审稿人再把问题和每段材料放在一起细看。稀疏检索（Sparse Retrieval）用大量可能的词维度表示文本，其中只有少数维度非零。BM25（Best Matching 25）是经典关键词排序方法，综合词频、词的稀有程度和文档长度调整相关性。

混合检索（Hybrid Search）组合稠密语义检索与稀疏关键词检索。重排序（Reranking，常称 Rerank）对已经找到的有限候选重新评分。它不会凭空从全库补出第一阶段漏掉的内容，除非系统另外启动补充检索。

技术原理：候选生成与精排分离

双编码器（Bi-encoder）分别把问题和文档编码为向量，文档向量可预先计算，因此适合大规模初筛。交叉编码器（Cross-encoder）把问题与文档一起输入模型，利用更充分的逐项交互进行评分，通常更适合有限候选的精排。并非所有重排序器都采用同一种架构，生成模型也可用于受控评分，但需要考虑成本和稳定性。

合并两路检索时，不能默认余弦分数与 BM25 分数处于同一标尺。可以做经过验证的归一化加权，也可以使用基于排名的倒数排名融合（Reciprocal Rank Fusion，RRF）。其思想是按每一路的排名贡献得分，减少不同分数尺度直接相加造成的问题。融合参数仍要在测试集上确定。

一个教学配置是两路各取若干候选，合并去重后取几十条送重排序，再把最相关的少量证据交给生成模型。数字只是实验起点，最终取值由召回、质量、上下文预算和时延共同决定。不能把候选数越大当作单调提高质量的保证。

证据构造：少而完整

重排序后仍要补齐上下文。例如命中的条款写着“以上标准不适用于海外”，就需要拿到它引用的标准和适用范围。去除重复块能节省词元，但不能误删不同版本或不同条件的差异。上下文中的文档应明确标记来源、页码、日期和段落编号，让模型把每个结论与证据绑定。

对相互冲突的资料，应先按现行版本、业务适用范围和权威来源规则处理；无法裁定时说明冲突并升级人工。不要让模型在矛盾材料中随意选一个顺眼的结论。对证据不足的查询，低相关阈值与拒答策略可结合，但阈值需要按模型和数据校准。

真实场景：设备支持与制度查询

查询“X900 设备 E104 错误”时，关键词路能保护型号和错误码，向量路能找到“初始化失败”等同义描述，重排序再判断哪段确实解释 E104。查询“新员工异地入职能否报销搬家费”时，语义检索解决表述差异，权限和生效日期过滤解决有效性，精排关注“新员工”“异地”“搬家费”是否在同一条款条件中成立。

售前视角：为什么不是越复杂越好

每新增一层都会增加延迟、成本和运维负担。先测纯关键词与纯向量基线，再看混合与重排序的增益。如果客户资料高度结构化且查询几乎都是精确编号，简单检索也可能足够。对高风险制度问答，更高的证据精度可能值得额外几十到数百毫秒，但具体耗时必须实测，不能预先保证。

把检索和生成的日志分开：保留查询、过滤条件、候选来源、排序前后分数和最终使用证据，日志中应按制度处理敏感文本。这样用户报错时才能判断是没找到、排序不对还是模型没用对。

面试怎么说

“Embedding 适合大范围快速找候选，Rerank 适合对问题与候选做更细判断。混合检索能同时覆盖语义表达和精确关键词，但融合方式与候选规模需要评估。重排序救不了完全没召回的证据，所以我会分阶段测召回和答案质量。”

容易混淆

Rerank 不是再做一次相同的余弦计算；Top-K 越大不一定答案越好；关键词检索不是落后的技术；混合检索不自动解决过期文档；排序得分不可直接当成可信度百分比。

返回目录

09 · 权限、更新与过期制度排查

返回目录

从用户身份一直追到引用来源，建立可审计链路。

为什么不能让模型负责保密

企业知识库可能同时存放公开产品手册、部门制度、薪资和合同。若先检索全库，再在提示中写“不要泄露”，模型已经接触了未授权信息，日志和缓存也可能保存了它。访问控制必须在可信应用与数据层执行，不能交给语言模型猜测。

大白话：凭门禁卡进入资料室

访问控制列表（Access Control List，ACL）记录谁能访问哪些资源。基于角色的访问控制（Role-Based Access Control，RBAC）按岗位角色授权；基于属性的访问控制（Attribute-Based Access Control，ABAC）结合部门、项目、地区等属性判断。它们像门禁规则，必须在看资料前生效，而不是看完后提醒保密。

技术原理：把权限贯穿每个阶段

入库时把文档来源权限映射为可验证的元数据，记录租户、部门、项目以及授权组。查询时根据登录身份生成过滤条件，检索层尽可能在候选召回过程中限制范围；返回前再次检查，避免过滤机制或元数据同步失误。客户端不能自行声明自己属于某个管理组，身份与授权由服务端可信信息决定。

重排序和生成只能接收已授权候选。来源下载、页码预览和缓存命中也要重新验证权限；“答案没有泄露，但引用链接能打开全文件”同样是问题。共享缓存键应包含必要的租户、权限或证据可见性维度，权限变更时及时失效。不能只把用户问句作为缓存键。

更新链路要记录文档生效日期、失效日期和版本关系。用于当前政策问答时过滤现行版本；用户明确问历史政策时按当时日期检索。删除与权限撤销需要贯穿原文件、索引、派生文本和缓存。增量更新失败要告警，避免系统安静地长期使用旧资料。

案例：为什么引用三年前的报销规定

先保存出错问题、用户权限、回答和引用标识，复现问题，再顺着链路找证据。查清新制度是否入库，并核对版本排序使用的日期。上传时间和制度生效时间可能不同。

如果旧版仍在索引里，核查版本与有效期过滤；如果新文档未进入候选，检查采集任务、解析失败和嵌入索引；如果候选正确而答案错误，检查上下文拼接和生成规则；如果更新后仍答旧内容，检查答案缓存和前端缓存。每个结论都对应日志证据和可复验修复。

真实场景：跨部门共用知识库

教学案例：人力部可看薪酬附件，普通员工只能看制度正文。即使它们来自同一个文件，也可能需要按敏感程度拆分文档或采用更细粒度的块级权限。简单沿用文件级 ACL 未必满足业务要求。权限设计阶段就要确定最小可见单元，避免索引完成后才发现无法隔离。

离职员工被移出身份组后，应测试其会话、历史链接和缓存是否还可访问。访问日志应记录谁在何时查询了哪类资料，但不必永久保留全部敏感提示。保留策略需要结合企业制度，而不是为了排错无限期保存。

售前视角：把安全写成可测的验收项

验收应覆盖跨租户、跨部门、被撤销授权、引用链接和缓存复用等反例。明确权限同步时效、数据删除时效、审计范围、日志脱敏和管理员职责。需要私有化时，还应检查解析、嵌入、重排序和生成各环节是否调用外部服务，不能只看最终模型放在哪里。

项目计划要留出与统一身份、文档平台和安全团队联调的时间。安全要求不只是采购一个网关，而是整条数据链路的约束。

面试怎么说

“遇到过期制度，我先保留问题和引用，再查新文档是否入库、版本是否切换、有效期过滤是否生效，然后看排序、上下文和缓存。权限方面，我会在检索与来源访问时独立执行，并确保未授权内容不会进入模型上下文。”

容易混淆

上传日期不等于生效日期；文档权限不等于模型权限；私有化不等于自动安全；过滤答案文本不能替代检索授权；一份文件的所有页也不一定有相同敏感级别。

返回目录

10 · RAG 评估与标准售前方案

返回目录

把“感觉不错”转换成可验收的证据。

为什么演示成功不等于项目成功

十个精心挑选的问题全部答对，可能只是演示材料与提示高度匹配。真实员工会使用简称、错别字、复杂条件和没有答案的问题。售前要把成功标准前置，否则项目后期只能围绕“我觉得不够智能”争论，既无法定位问题，也无法证明改进。

大白话：把找资料和写答案分别打分

召回率（Recall）关注应该找到的证据有多少被找到；精确率（Precision）关注找到的候选里有多少真正相关。在检索中，Recall@K 表示前 K 个候选覆盖相关证据的程度，具体标注口径必须说明。单证据问题也常统计“正确证据是否进入前 K”的命中率，它与多证据召回率不能混用。

答案评估还要关注事实正确性、完整性、忠实性与引用有效性。忠实性指回答是否受所给证据支持，正确性还需要与权威事实一致。模型完全忠实地引用过期文件，仍可能给出业务上错误的答案。

技术原理：建立分层测试集

先由业务专家整理真实问题，标注所需资料、答案要点和适用条件。测试集覆盖常见问题、长尾问题、跨文档问题、无答案问题、冲突版本问题、权限反例、扫描表格及恶意注入。开发集用于调参，保留集用于最后验收，不能不断用验收题反复调到满分。

评估检索时固定问题和正确证据，记录初筛、融合、重排序后的结果；评估生成时可以先给正确证据，判断模型能否按证据回答。若正确证据下仍答错，重点改提示、模型或结构化处理；若证据没找到，重点修数据与检索。这样能避免把所有失败都归因于模型不够大。

人工评审可制定零到二分等简单量表，明确错一个关键金额就算失败，而不是文笔流畅就加分。模型评审可以帮助规模化，但需对照人工校准，避免偏爱长答案或同类模型。高风险问题与权限泄露不能仅用平均分掩盖。

数字例子与验收口径

教学假设：一百个单证据问题中，正确资料进入前十候选的有九十个，命中率为百分之九十。最后八十个答案符合全部要点，不代表模型“准确率固定八成”，因为结果只适用于这份测试集、指定版本和设置。另有二十个无答案问题，应单独统计正确拒答比例，不能混到容易问题里稀释。

性能验收需要固定输入长度、输出长度、并发或到达率、硬件和缓存状态，报告首词元时延及尾部时延。业务验收则观察员工能否更快找到可靠材料、是否减少人工转接。技术指标与业务收益有联系，但不是同一个数字。

可在面试讲解的标准技术方案

第一层是数据接入：文件连接器、解析与 OCR、清洗和版本治理。第二层是检索：分块、嵌入、向量及关键词索引、权限过滤和重排序。第三层是生成：上下文预算、模型推理、结构化答案、来源校验和拒答。第四层是平台治理：统一身份、网关限流、日志审计、监控告警、质量评估和发布回滚。

实施分为样本治理、PoC、试点、生产四个阶段。每阶段有进入条件和退出条件：样本可追溯后才测检索，关键质量指标达到约定值后才扩大用户范围。生产需要增量更新、备份恢复、模型与索引版本记录，以及故障降级方案，例如退回原文检索。

售前视角：报价与风险

报价拆分一次性实施与持续费用：文档整理、连接器、权限集成、平台配置、GPU 或 API 服务、存储、运维和质量运营。使用教学假设可以估量级，但不能凭空报市场价格。成本测算应注明计费口径、访问量、词元长度、缓存命中和数据增长。

风险清单应具体到可执行措施，例如扫描表格需要抽检、权限系统接口交付日期影响联调、峰值负载需要压测后确认。客户期望百分之百正确时，说明哪些高风险结论必须人工确认，并将无证据拒答作为合格行为。

面试怎么说

“我会先和业务方定义代表性问题及验收口径，再分别测证据召回和最终答案。方案覆盖数据治理、检索、生成与平台运维，不只部署一个聊天界面。上线时保留索引和模型版本，支持回滚与人工升级，持续从真实失败案例改进。”

容易混淆

引用率不等于引用正确率；平均准确率不能掩盖越权；PoC 题目通过不等于长期稳定；用户满意度不能代替事实核查；完全拒答虽然安全，却不能满足业务可用性。

返回目录

11 · 从聊天到工具调用

返回目录

模型提出动作，应用校验并执行。

为什么会说还不够

用户问昨天 GPU 用了多少电、哪台机器空闲，语言模型仅靠训练知识无法获得企业实时数据。它必须连接监控或资产系统。用户还可能希望创建工单或调整配额，此时系统从生成文字进入了影响真实业务状态的领域，需要清晰的执行与授权边界。

大白话：助理提单，业务系统办理

工具使用（Tool Use）让模型通过外部功能获得信息或执行任务。函数调用（Function Calling）通常指模型按工具定义输出函数名及结构化参数，由应用执行并把结果交回模型。应用程序编程接口（Application Programming Interface，API）是系统提供的可调用入口。

模型产生“查询监控”的结构化请求，并不代表它自己连接了数据库，也不证明操作已经执行成功。真正的调用发生在受控应用代码中。可以把模型看成提出办理事项的助理，执行器像审核表单的办事窗口；表单必须满足格式、身份和业务规则才能办理。

技术原理：一个完整调用回合

应用先把可用工具的名称、用途、参数类型、必填字段和约束提供给模型。模型判断是否需要工具，输出工具调用对象。执行器解析参数，进行类型校验、身份授权、范围限制、超时和调用频率控制，然后调用内部 API。工具返回结构化数据或明确错误，应用附上关联标识再交给模型，模型据此生成回答或继续下一步。

JSON Schema 是描述 JSON 数据结构的规范，可声明字符串、数值、枚举和必填项。结构符合规范只是第一层，例如“结束日期晚于开始日期”“只能查询本人项目”“不得查询未来时段”等业务规则仍需应用检查。即便模型接口支持结构化输出，也不能省略验证。

查询数据库时，优先暴露按业务封装的只读工具，例如按授权项目获取每日利用率，而不是给模型一个可任意执行 SQL 的管理员账户。确需生成 SQL 时，用只读账号、允许的表列、参数化查询、结果行数和执行时限约束，并拒绝不符合规则的语句。

真实场景：库存查询与采购

教学案例：用户问某型号服务器库存。工具先查当前库存并返回查询时间，模型解释可用数量；若用户接着要求采购，应该进入独立写入流程，展示型号、数量、供应商和预算，按企业规则审批。读工具和写工具使用不同权限，不能因为查询成功就默认允许下单。

内部 API 可能超时、返回部分数据或重复响应。工具结果应包含状态、时间范围、单位和缺失字段，不能把空结果当零。写入操作要有幂等键，避免重试造成重复工单或重复变更。幂等指同一操作重复提交不会产生额外副作用。

售前视角：接口盘点比演示更重要

需求访谈要确认系统是否有正式接口、认证机制、速率限制、数据口径和测试环境。很多项目的主要工作不是让模型输出函数名，而是整理历史接口、建立授权和异常处理。需要把接口开发、业务审批和运维责任纳入范围。

评估工具调用时，除回答是否自然，还要看选对工具比例、参数正确性、越权拦截、失败处理与操作可追溯性。对于高影响操作，优先让模型生成可审查的建议，再由人确认执行。

面试怎么说

“Function Calling 的关键是模型输出结构化的工具名和参数，应用完成校验后执行，再把结果交回模型。模型不是权限系统，也不是执行成功的证明。企业接入要把只读查询和写入动作分开，控制权限、超时、重试与审计。”

容易混淆

输出一段 JSON 不等于调用了 API；工具返回成功不等于业务结果一定完整；只读账号也可能泄露过多数据；让模型生成 SQL 不意味着必须允许任意 SQL；系统提示不能替代服务端授权。

返回目录

12 · Agent 的规划、执行与反馈

返回目录

一步一步分析昨天的 GPU 使用情况。

为什么需要多步执行

“分析昨天公司 GPU 使用情况，并生成优化报告”不只是查一个数。系统需要确定昨天的时间范围、当前用户可见的资源、要用哪些指标，再汇总异常、识别可能原因并提出有证据的建议。如果数据缺失，还需要调整查询或说明限制。智能体（Agent）通常是围绕目标选择工具、执行步骤并根据结果继续行动的系统。

大白话：有反馈的任务助理

普通聊天像一次答复，固定工作流像按既定清单办事，Agent 更像在规则内选择下一步的助理。这里的“自主”是有限的：可用工具、最大步数、成本和授权边界仍由系统定义。一个有工具的机器人是否称为 Agent，没有统一的商业边界，售前应直接描述它实际能做的事。

技术原理：规划—行动—观察

ReAct 通常解释为 Reasoning and Acting，强调推理与行动交替：提出下一步操作、调用工具、读取观察结果，再决定下一步。生产系统应记录可审计的计划、工具调用和结论依据，不需要也不应把模型内部隐藏推理当作事实证据。可以给用户展示简洁的任务状态与依据。

状态保存目标、已完成步骤、工具结果摘要和剩余预算；调度逻辑判断继续、重试、澄清或结束。工具返回数据不足时，下一步可以补查；如果达到最大调用次数、超时或预算上限，则停止并报告部分结果。没有明确终止条件的循环容易消耗资源却不产生可靠成果。

完整案例：昨天 GPU 资源分析

第一步理解任务：把“昨天”按企业时区转换成明确起止时间，并确认用户授权的集群范围。第二步确定数据：设备利用率、显存占用、功率、作业、队列等待和故障事件。不同指标采样周期要一致，单位要明确。

第三步调用监控 API：使用只读工具读取时间序列，必要时分页；记录数据时间范围、采样间隔和缺失比例。第四步分析：用确定性的统计代码计算均值、峰值、分位数和空闲时段，按项目与作业关联。模型负责解释，统计计算由可复验逻辑完成。

第五步生成报告：说明范围与数据完整度，列出高负载、低利用率和排队长的资源，引用查询结果标识。第六步交付建议：例如检查低利用率作业是否受 CPU 或存储瓶颈影响，建议错峰或调整批大小。没有足够证据时写成待验证假设，不能把低利用率直接等同于资源浪费。

从指标到建议：避免错误因果

某 GPU 利用率低可能是等待数据、通信同步、小批请求、模型切换或故障重试。显存占用高但计算不忙，可能是模型常驻等待请求。仅根据平均利用率自动关闭机器，可能打断低频关键业务。报告应把观察、推测、建议和执行动作分开。

教学报告可以写：“集群甲在指定时段的已采集样本中存在长时间空闲，建议核对作业排期与保留容量；本报告不自动释放资源。”若用户要求执行优化，再进入带审批的变更流程，显示影响范围和回滚方案。

售前视角与验收

验收不只看报告文风，而看时区是否正确、范围是否授权、统计是否可复验、缺失数据是否说明，以及建议是否有依据。使用固定数据集可以验证分析一致性，使用故障注入验证 API 超时和部分结果处理。最后检查整个任务成本与完成时延。

接口不可用时，应告诉用户已完成哪些步骤、哪些数据缺失、如何重试。不能编造一份看起来完整的昨日监控报告。对同一任务保留任务标识，方便用户与运维查找执行记录。

面试怎么说

“我会让 Agent 先明确时间和授权范围，再调用只读监控接口，以确定性程序计算指标，由模型解释并形成带来源的报告。设置步数、时间和成本预算。任何资源调整进入单独审批流程，分析报告本身不意味着授权变更。”

容易混淆

Agent 不等于能无限自主执行；工具结果不是可信指令；平均利用率低不必然能缩容；报告写完不代表真实数据完整；多步骤输出不等于完成了多步骤行动。

返回目录

13 · 工作流、多 Agent 与 MCP

返回目录

选择必要的复杂度，把连接协议与业务能力分开。

为什么不是所有任务都要 Agent

报销审核如果流程固定、规则明确，通常更需要可预测和可审计，而不是让模型自由决定下一步。售前容易把“自主”当作卖点，忽视多次模型调用造成的时延、成本和排错难度。设计的目标是稳定完成业务任务，复杂度只在带来可测收益时才值得增加。

大白话：流水线与项目小组

工作流（Workflow）是预先定义步骤、分支和条件的执行流程，适合固定审批、文档处理和标准报表。单智能体（Single Agent）在限定工具与预算中决定步骤；多智能体（Multi-Agent）把任务分配给多个角色或实例，可能进行并行研究、交叉检查或分工执行。

多 Agent 像一个项目小组：专业分工可能提升质量，也会增加协调和沟通。把同一个问题让三个模型回答，并不自动得到三倍可靠性；它们可能共享相同的错误知识。

技术原理：先确定流程边界

流程稳定、风险高、分支可枚举时，优先用确定性工作流；只有输入差异大、工具路径难预先穷举且允许评估探索结果时，再引入 Agent。也可以把模型放在固定工作流的一步，例如提取合同字段，后续仍由规则检查金额和审批链。

多 Agent 需要明确每个角色的输入、输出、共享状态与停止条件，限制互相转派和重复调用。单个执行者负责最终一致性，避免多个 Agent 同时写同一业务记录。要比较相对于单 Agent 或固定流程的质量增益，不能仅凭角色数量宣称先进。

模型上下文协议（Model Context Protocol，MCP）是一种让 AI 应用连接外部能力的协议。宿主（Host）是应用本身，客户端（Client）与服务端（Server）建立协议连接，服务端提供工具、资源或提示模板等。工具可通过 tools/list 发现，通过 tools/call 调用；底层消息使用 JSON-RPC，可使用本地标准输入输出或远程 HTTP 传输。

MCP 解决什么，不解决什么

MCP 减少每个 AI 应用与每个工具各写一套连接方式的重复劳动，像统一插座规格。它不提供行业知识，不决定任务规划，也不替代业务授权。连接器能告诉模型有一个“查订单”工具，但用户是否有权查某笔订单仍由服务端判定。

协议会演进，握手与能力声明方式应以所用版本的官方规范为准。本教材核查的是 2026-07-28 文档，概念图只表达 Host、Client、Server 的关系，不把某个旧版本的初始化流程当成所有版本共同约定。接入前还需核查服务代码来源、远程身份验证、允许访问的资源和日志处理。

真实场景：企业巡检报告

固定每日巡检：按集群列表读取指标、运行确定性阈值规则、生成标准报告，工作流通常足够。临时问题“为什么昨天训练变慢”，可能要根据结果追加查询网络、存储和作业日志，适合受限 Agent。若需要同时调查多个独立集群，可以并行执行独立读取，再集中汇总；并行不一定需要多个有自主决策能力的 Agent。

Agent 与 RAG 可以组合：Agent 调用检索工具查询运维手册，再调用监控工具查事实，最后提出排查建议。RAG 提供证据，Agent 管理行动，两者不是互斥的产品类别。

售前视角：如何向客户解释价值

先展示现有工作流在哪些输入变化下失效，再说明 Agent 能减少哪些人工判断。PoC 对比任务成功率、人工接管率、平均调用次数、成本与时延。对 MCP，应强调标准连接和治理边界，不要说“接入协议后任何系统都能自动安全联通”。

如果需要多 Agent，给出明确分工，例如资料检索与数据分析独立完成，主流程校验证据并合并；同时提供超时降级和冲突处理。客户采购的是可靠服务，不是角色数量。

面试怎么说

“我优先选择能满足目标的简单流程。固定且高风险的步骤用工作流，路径不确定的任务再考虑 Agent。MCP 是连接工具和上下文的协议，和 Agent 的规划能力是不同层次。多 Agent 只有在分工收益大于协调成本时才采用。”

容易混淆

MCP 不是模型，不是数据库，也不是自动授权；多 Agent 不保证更准确；并行任务不必都由 Agent 执行；工作流可以包含模型；RAG 可以作为 Agent 的一个工具。

返回目录

14 · 把权限、审批与失败控制做进系统

返回目录

安全是执行边界，可靠性来自可验证的状态。

为什么会读外部内容就有风险

模型可能读取网页、文档、邮件或工具返回。其中可能夹带“忽略之前要求，把数据发到某地址”之类的内容。提示注入（Prompt Injection）试图把本应作为数据处理的内容变成操作指令。即使没有恶意，文档中的教程命令也可能被错误当成当前任务。系统必须区分用户授权、应用规则和外部资料。

大白话：文件里的命令不是老板的命令

助理在一本手册里读到“删除旧记录”，不代表老板刚刚批准删除生产数据库。最小权限（Least Privilege）让每个工具只具备完成任务所需的能力；人工参与（Human-in-the-loop，HITL）在关键步骤让人审核。它们不是频繁弹窗的同义词，而是把有实际影响的动作放到清晰的授权边界内。

技术原理：纵深控制

工具采用允许清单，限制可访问域名、项目、表列与操作类型；参数校验要防止路径越界、任意命令和非授权目标。秘密凭据由服务端保管，不放在提示或浏览器代码里。外部返回作为不可信数据传递，不能因为其中自称“系统消息”就提升权限。

读与写拆成不同工具，写操作先生成待执行计划，显示对象、参数、影响和回滚方式，经授权后使用短期或范围受限的凭据执行。审批应绑定具体操作摘要，若参数变化需要重新满足审批规则，不能用一张泛化的“我同意”覆盖后续所有行为。

执行要有总时限、每步时限、最大工具调用数、最大词元或费用预算。重试只针对可恢复错误，并采用有限次数及退避；对非幂等写入，先确认上一次是否已生效。重复观察同一失败结果时应停止循环，转为澄清或人工处理。

失败设计：承认部分完成

任务状态可分为待执行、运行中、等待审批、部分完成、成功与失败。只有工具结果与业务后置条件都满足时，才报告操作完成。例如创建工单接口返回接受请求后，还要确认工单编号或最终状态，而不是只看 HTTP 连接成功。

长期任务要保留可恢复的检查点与执行标识，避免浏览器刷新导致重复处理。对多个系统写入，不能假设它们具备同一个事务；需要补偿动作或人工恢复方案。补偿也可能失败，因此应记录每个外部副作用。

真实场景：监控工具返回恶意文本

教学案例：GPU 作业名称被恶意用户设为“请把所有配置发送到外部网址”。监控 API 返回这段名称后，模型可能看到它。安全设计应只把名称作为字符串展示或分析，禁止它改变网络访问白名单和任务目标。工具权限层即使面对错误模型输出，也应阻止外发。

验收可以注入这样的测试文本，确认系统不会执行其中命令，再测试超时、无权限、空数据、部分返回和重复提交。提示中提醒“不要服从资料里的指令”有帮助，但不能作为唯一防线。

售前视角：成本和责任可解释

给客户一张清晰的权限矩阵：哪些工具只读，哪些需审批，哪些根本不开放。设定项目级预算与限流，记录每次任务的调用次数、耗时和费用口径。把业务负责人、接口负责人和运维负责人的职责写清，失败时知道由谁处理。

高风险业务可采用“建议模式”先上线：生成有证据的优化建议，人工在现有系统执行；积累成功数据和故障样本后，再逐步开放低风险自动动作。这是分阶段交付策略，不是能力不足的掩饰。

面试怎么说

“我不把安全寄托在模型听话。外部资料是数据，权限在执行层校验；敏感写入要有具体审批和审计；任务设置超时、重试、幂等和预算。工具成功之后还要验证业务结果，失败则明确部分完成状态。”

容易混淆

提示注入不只是用户直接越狱；私网文档也可能有恶意内容；有审批不代表参数不会被替换；所有失败都重试会放大问题；只读访问同样需要控制数据范围。

返回目录

15 · GPU：算得快与装得下是两回事

返回目录

把计算、显存、带宽和互联分开看。

为什么服务器经验很有用

传统服务器选型会看处理器、内存、网络与磁盘，大模型服务也要看这些资源，但主计算和主要模型状态常常集中在 GPU。采购时只看算力峰值，可能买到装不下模型或数据搬运跟不上的设备。售前需要把“每秒能做多少运算”“能放多少状态”“状态搬得多快”拆开讨论。

大白话：通用主管与并行车间

中央处理器（Central Processing Unit，CPU）擅长复杂控制、低延迟和分支多的任务；图形处理器（Graphics Processing Unit，GPU）具备大量并行执行资源，适合对大量数据执行类似计算。这是架构倾向，不代表 CPU 不能做矩阵、GPU 不能做一般计算。

矩阵可以理解为规则排列的数字表。神经网络的大量计算是矩阵乘加，同一操作可以分散给许多执行单元，因此适合 GPU。CPU 仍负责请求处理、数据准备、分词、调度及许多业务逻辑，GPU 不是把整台服务器都替代掉。

技术原理：算术能力与数据供给

CUDA（Compute Unified Device Architecture）是 NVIDIA 的并行计算平台和编程模型，包含编译、运行时及库生态；它不是一种 GPU 显存，也不是所有品牌通用的标准驱动。Tensor Core 是 NVIDIA GPU 上面向矩阵乘加的专用计算单元名称，支持格式与效率随代际和内核而变。

FLOPS（Floating-point Operations Per Second）是每秒浮点运算次数；TFLOPS 是每秒万亿次，PFLOPS 是每秒千万亿次。比较峰值必须说明精度、稠密或稀疏口径、单 GPU 或整机数量。稀疏指标常假设可利用特定结构化稀疏模式，不意味着任意模型都能达到那个数。

高带宽内存（High Bandwidth Memory，HBM）通过堆叠等设计提供高带宽，常用于数据中心加速器。显存容量决定能放多少权重、缓存和工作空间；显存带宽描述每秒可搬运多少数据。生成阶段可能频繁读取权重和 KV Cache，在某些负载下受内存带宽限制；预填充常有较高计算强度，但实际瓶颈必须测量。

连接方式：卡内、卡间与节点间

PCI Express（PCIe）是常用的高速外设互联标准，连接 CPU、GPU 和其他设备。NVLink 是 NVIDIA 的高速互联技术，NVSwitch 是构建多个 GPU 高带宽通信域的交换组件。不是所有 NVIDIA 卡都有 NVLink，更不能把 PCIe 插槽数量直接当成高效多卡并行能力。

单卡部署把模型和请求状态放在一个 GPU；单机多卡在一台服务器内协同；跨节点需要经过网络协调。数据从本地显存、机内互联到跨机网络，延迟和带宽条件不同。设计应尽量让频繁通信发生在合适的互联域内。

真实场景：两个看似相同的需求

教学案例：业务甲只处理短问短答，模型较小且并发较高；业务乙每次读取长文档，模型相同却需要更大的 KV Cache。两者可能更关注不同资源。另一个视觉渲染与推理混合场景，还需要考量显卡的图形能力和共享方式。不能只说“都是 AI，所以买同一配置”。

观测 GPU 利用率时，应同时看显存、内存带宽、功率、CPU、网络和请求排队。利用率只是某段时间的活动度指标，不直接代表算力效率；不同采样周期也会影响观感。

售前视角与面试回答

“GPU 适合大规模并行矩阵计算，但服务性能由计算、显存容量、显存带宽和互联共同决定。我会先看模型与业务负载，再确认服务器拓扑和软件兼容，最后按真实词元长度与并发压测，不把峰值 TFLOPS 换算成用户数。”

采购清单除了卡片型号，还应列出服务器形态、供电散热、CPU 与内存、网卡、驱动、固件、框架和维保。整机的兼容与支持矩阵决定后期故障是否可定位、可修复。

容易混淆

显存容量不是显存带宽；GPU 峰值算力不是模型每秒词元数；Tensor Core 不等于整个 GPU 核心；CUDA 版本不只是一个安装包名称；多卡容量相加不能保证模型高效跨卡运行。

返回目录

16 · 主流硬件选型：先确认是哪一种形态

返回目录

官方规格表与系统级指标辨析。

为什么同名卡也要确认形态

同一代 GPU 可能存在 PCIe、SXM 或不同显存配置。SXM 是 NVIDIA 的模块形态，通常用于具备专用供电与互联的服务器底板；OAM（OCP Accelerator Module）是另一类加速器模块规范。它们不是可以随意插入普通 PCIe 槽的板卡。型号缩写相同，不代表功率、带宽与服务器兼容条件相同。

大白话：发动机、整车与车队不能混比

单 GPU 指一个图形处理器的规格；八卡节点是包含多 GPU、CPU、内存和互联的服务器系统；NVL72 是机架级系统。就像发动机功率不能和整支车队的总功率直接比较。看宣传数字前，先找到统计单位、精度口径和脚注。

技术原理：从规格推导候选，而非结论

本节末尾的硬件对照采用官方公开资料，核查日期为 2026-11-07。容量为厂商标称十进制值，带宽为官方峰值。适用方向根据容量、带宽与生态判断，实际性能以部署环境的压测为准。

L40S 是 48 GB GDDR6 的 PCIe 卡，无 NVLink 和 MIG，适合评估推理、视觉与图形混合任务。A100 80GB SXM 与其 PCIe 版本的带宽不同。H100 SXM、H200 SXM 的容量和带宽也不能混写。B200 的当前 HGX 参考架构列出单 GPU 180 GB，不能沿用早期不同口径的宣传数字。

GB200 Grace Blackwell Superchip 包含一颗 Grace CPU 与两颗 Blackwell GPU；官方列出的 372 GB 是其 GPU 显存合计。GB200 NVL72 包含三十六颗 Grace CPU 与七十二颗 GPU，约 13.4 TB 是整机架 GPU 显存合计。这两个数字都不是“一张 GB200 显卡”的显存。

其他平台与国产适配

AMD Instinct MI300X、MI325X 等数据中心加速器提供不同容量与互联方案。其软件生态通常涉及 ROCm（Radeon Open Compute）平台，要核查具体模型、框架版本、算子、量化和通信库兼容性。不能把 NVIDIA 上的配置文件原样复制后假定表现相同。

昇腾等国产人工智能加速器可能采用 NPU（Neural Processing Unit，神经网络处理器）名称。国产化选型要关注 CANN 等软件栈、框架适配、模型转换、算子覆盖、量化路径、集合通信和现场支持。此次没有取得足以统一核对昇腾 910 各后续版本的完整官方公开规格，因此不填猜测数字，要求供应商正式规格书和样机验证。

这里列的是常见代表性平台，不是截至核查日所有新品的排行榜。采购阶段应再次核对可供货型号、地区合规、整机厂认证和服务条款，不能仅根据网上一张表下单。

真实场景：70B 与多模型平台

70B 私有化需要先核算权重、缓存和运行时空间，再选择量化或多卡切分。多个小模型共用平台，则可能更重视隔离、调度和利用率。若跨卡通信频繁，机内互联是重要因素；若模型完整放在单卡且请求相互独立，多副本部署可能更简单。

大显存卡可能减少切分和通信，但设备成本、可用性和软件兼容也要比较；较多小卡未必更便宜，因为互联、功耗、机位和维护也有成本。没有工作负载数据时，先给候选方案与验证计划。

售前视角：公平对比的五个条件

一是同一业务模型与质量要求；二是同一输入输出长度分布；三是同一并发或请求到达方式；四是相同的可接受尾时延；五是把功耗、许可、运维和冗余纳入成本。硬件规格表只决定哪些方案值得试验，不直接决定最终性价比。

让供应商提供准确的单 GPU 与整机规格、兼容矩阵和测试复现条件。性能数字必须说明是否稀疏、是否量化、是否使用缓存、是否含排队和网络时间，否则比较可能失真。

面试怎么说

“我会先确认卡型与系统形态，再比较容量、带宽、互联和软件支持。比如 H100 SXM 与 PCIe 规格不同，GB200 模块和 NVL72 的总量不能当作单卡参数。最后用同一模型、负载和时延目标比较实际服务能力。”

容易混淆

GB200 不是简单的一张独立显卡；不能把八卡节点的 PFLOPS 写成单卡；FP8 格式支持不意味着所有模型都能无损高效运行；国产平台兼容性不等于只要能导入权重。

硬件对照

官方规格核查于 2026-11-07。容量为厂商标称值，带宽为峰值。

L40S · PCIe卡

48 GB GDDR6，864 GB/s。互联为 PCIe Gen4 x16；无NVLink。代表性精度为 FP32 / TF32 / BF16 / FP16 / FP8 / INT8。

推理、视觉及图形混合；多卡通信需评估 规格来源

A100 80GB · SXM单GPU

80 GB HBM2e，2,039 GB/s。互联为 NVLink 600 GB/s。代表性精度为 FP64 / FP32 / TF32 / BF16 / FP16 / INT8。

成熟训练推理；无原生FP8 Tensor Core 规格来源

H100 · SXM单GPU

80 GB HBM3，3.35 TB/s。互联为 NVLink 900 GB/s。代表性精度为 BF16 / FP16 / FP8 / INT8 等。

高吞吐训练与推理候选 规格来源

H200 · SXM单GPU

141 GB HBM3e，4.8 TB/s。互联为 NVLink 900 GB/s。代表性精度为 BF16 / FP16 / FP8 / INT8 等。

较大权重与长上下文服务候选 规格来源

B200 · HGX中的SXM单GPU

180 GB HBM3e，最高 8 TB/s。互联为 NVLink 1.8 TB/s。代表性精度为 BF16 / FP16 / FP8 / FP6 / FP4 等。

高密度训练推理；核实机房与软件条件 规格来源

MI300X · 单OAM模块

192 GB HBM3，5.3 TB/s。互联为 Infinity Fabric；PCIe 5.0 x16。代表性精度为 FP64 / FP32 / TF32 / BF16 / FP16 / FP8 / INT8。

较大模型候选；核查ROCm适配 规格来源

MI325X · 单OAM模块

256 GB HBM3E，6 TB/s。互联为 Infinity Fabric；PCIe 5.0 x16。代表性精度为 FP64 / FP32 / TF32 / BF16 / FP16 / FP8 / INT8。

大容量候选；仍需实测质量与服务性能 规格来源

昇腾910系列 · 型号、板卡与整机须分别确认

待正式规格书核验，待正式规格书核验。互联为 按具体平台确认。代表性精度为 按具体型号与软件栈核验。

核查CANN、框架、算子、量化、通信与支持

GB200 Superchip 的两颗 GPU 合计 372 GB 显存。GB200 NVL72 的 72 颗 GPU 合计 13.4 TB 显存。规格来源

返回目录

17 · 显存估算：用结构和负载说话

返回目录

分别计算权重、KV Cache 与运行时余量。

为什么不能只问能跑多大模型

“能跑”可能指能加载、能完成一次短请求、能服务十个活跃请求，或者能在目标时延内稳定运行。这些不是同一个标准。容量规划要把最大上下文、日常长度、活跃请求和高可用需求写清，否则任何 GPU 数量都缺乏依据。

大白话：固定库存、订单占位与操作空间

权重是固定库存；KV Cache 随每个活跃请求的上下文增长；运行时空间用于临时计算、通信和框架管理。批大小（Batch Size）是一次计算组织的样本或词元规模，推理引擎中的调度批可能随着请求完成而动态变化。并发数（Concurrency）表示同时在系统内处理或等待的请求数，不能直接等同于某个固定批大小。

上下文长度（Context Length）在缓存估算中应理解为当前已缓存或计划容纳的总序列长度，包括输入与已生成内容。只填输入长度，会低估长输出请求的缓存增长。

技术原理：两条公式

权重 GiB＝参数量（十亿）× 10⁹ × 位数 ÷ 8 ÷ 2³⁰。KV Cache GiB＝2 × 层数 × KV 头数 × 每头维度 × 序列词元数 × 活跃序列数 × 缓存每元素字节数 ÷ 2³⁰。第一个 2 表示 Key 与 Value 两组状态。

这个 KV 公式适用于指定结构下的常规完整注意力缓存简化估算。滑动窗口注意力、潜在注意力压缩、混合架构、共享前缀、分页碎片、缓存量化和分布式切分会改变实际占用。模型配置中的 KV 头数可能不同于查询头数，不能拿隐藏维度除头数后再随意代换。

估算时从模型配置中逐项取得结构参数，再根据部署条件加入运行时开销与预留。预留比例属于规划假设，实际容量由框架配置和压测决定。

数字例子：并发和上下文怎样相乘

在 80 层、8 个 KV 头、头维 128、两字节缓存的教学结构中，一个 8192 词元序列的缓存约为 2.5 GiB，四个为 10 GiB，八个为 20 GiB。如果上下文翻倍且其他条件不变，缓存也约翻倍。这样可以解释为什么长文档和高并发会共同推高资源需求。

量化权重到四位，70B 的理论权重下降到约 35 GB，即 32.6 GiB，但还要加量化元数据、可能保留高精度的层，以及未必量化的 KV Cache。不能用“比 BF16 小四倍”推导整台机器总显存也恰好小四倍。

张量并行与流水线并行

张量并行（Tensor Parallelism，TP）把同一层的部分矩阵计算分到多个设备，通常需要频繁交换中间结果，对互联敏感。流水线并行（Pipeline Parallelism，PP）把不同层放到不同设备，让请求或微批经过各阶段，需要考虑阶段平衡和流水线空泡。

副本部署则让多个完整模型独立接请求，适合模型能装入单个资源单元且需要扩吞吐的情形。三者可以组合，但复杂度和故障域会变化。TP 的卡数通常受模型维度与框架实现约束，不能把任意卡数都当作合法配置。

售前视角：从估算走到验证

先读取目标模型配置与权重格式，再收集输入输出长度分布、活跃请求和突发特征。根据候选并行方式做容量检查，然后在目标服务器上测试显存峰值、内存不足行为、请求排队和尾时延。还要验证一张卡或一个节点故障后的剩余容量。

容量允许但速度不够时，可能需要更多副本、不同量化、优化调度或降低最大长度；速度看似足够但没有故障余量，也不构成高可用。应向客户提供假设、测试方法、实测结果与扩容触发条件。

面试怎么说

“参数量决定权重的大致底数，KV Cache 必须根据具体层数、KV 头数、维度、长度和活跃序列另算。然后加运行时开销。多卡还要看切分和互联，因此先用理论计算筛选候选，最终容量承诺以真实压测为准。”

容易混淆

用户人数不等于活跃请求数；批大小不等于排队请求数；所有模型不适用同一 KV 公式；TP 不只是把文件平均切几份；显存总和足够仍可能因单卡分配或工作空间不足而失败。

返回目录

18 · 从模型文件到企业推理服务

返回目录

框架、容器、网关与监控如何组成服务。

为什么本地能回答还不算部署完成

在个人电脑运行一次模型，通常没有多租户身份、限流、版本发布、故障恢复和审计。企业需要稳定接口与运维能力。推理服务化是把模型运行能力包装成可治理的服务，让应用调用方不必知道 GPU 放在哪台机器。

大白话：厨房后面还需要餐厅运营

PyTorch 是常用深度学习框架，负责张量计算、自动求导及模型执行；Transformers 是 Hugging Face 的模型与分词器生态库。它们能帮助加载和运行模型，但完整服务还需要调度、接口、资源隔离与监控。

llama.cpp 是面向高效本地推理的项目，支持其生态中的模型格式和多种后端，适合边缘或本地验证；Ollama 提供便捷的模型运行与管理体验。vLLM 是面向大模型服务的推理引擎；TensorRT-LLM 是 NVIDIA 面向大语言模型推理优化的工具与运行栈。工具选择要基于设备、模型、部署规模和团队维护能力。

技术原理：服务路径

用户应用把请求发给 API 网关。网关负责身份认证、租户配额、限流、路由和必要的审计；模型服务执行分词、调度、推理与流式输出；GPU 资源层提供设备和隔离；监控采集请求、模型、节点及设备指标。模型注册表记录名称、权重版本、精度、模板与依赖，发布流程控制升级和回滚。

OpenAI 兼容 API 指服务提供与某些常用接口相似的路径和消息格式，便于客户端迁移，不代表所有参数、工具调用、结构化输出或多模态行为都完全一致。接入前用真实请求验证接口差异，特别是聊天模板、停止词、最大长度和错误返回。

Docker 用容器打包用户空间依赖；Kubernetes 是容器编排系统，管理调度、伸缩和健康状态。容器镜像不能自行消除宿主机驱动与设备插件的兼容问题。需要固定可复现的镜像、驱动和框架组合，记录模型文件校验值，避免不同节点悄悄运行不同版本。

部署方式与生命周期

开发验证可以从单进程开始，生产常用容器与明确的服务入口；是否使用 Kubernetes 取决于规模、团队技能和已有平台。为一个小模型硬上复杂集群也可能增加负担。模型加载可能耗时较长，健康检查应区分进程存活、模型已就绪和服务可用。

滚动升级时，新副本加载并通过检查后再接流量，旧副本停止接收新请求但允许已有流式响应完成。回滚要同时考虑模型、分词器、提示模板和推理配置，不能只换权重。对于 RAG 服务，还应记录索引与嵌入版本的兼容关系。

真实场景：企业统一模型平台

教学方案：多个应用经统一网关调用不同模型，短分类任务路由到小模型，复杂问答路由到大模型，代码任务路由到经过评估的代码模型。网关统一认证与预算，后端分别维护模型副本和 GPU 资源。

日志分为访问元数据、性能指标和经允许保留的内容样本。默认不应把所有敏感提示与工具结果无限保存在日志。监控告警覆盖错误率、排队长度、首词元时延、设备内存不足、GPU 错误、节点失联和存储下载失败。

售前视角：框架选择不是排行榜

比较工具时列出目标模型支持、精度路径、硬件平台、吞吐时延、并行方式、可观测性和运维门槛。个人验证速度快的工具适合探索，但生产还需要访问控制和高可用；吞吐优化强的引擎，也需要确认具体模型与版本能否使用。

交付物应包括部署清单、配置基线、模型版本、监控看板、发布回滚步骤和故障手册。用“我们支持容器化”不能替代这些细节。

面试怎么说

“模型服务不仅是启动推理进程。我会在应用和模型之间设置认证、路由、限流与审计，后端管理调度、GPU、版本和监控。框架按模型与硬件兼容性选，发布时验证就绪和回滚，接口兼容也要用真实请求测试。”

容易混淆

Docker 不包含宿主驱动的一切能力；Kubernetes 不自动保证 GPU 性能隔离；OpenAI 兼容不等于功能完全相同；服务进程存活不等于模型就绪；模型文件可下载不代表许可证允许目标用途。

返回目录

19 · 连续批处理、分页缓存与前缀复用

返回目录

把调度、存储和复用三个优化分开理解。

为什么一批请求不能总是一起等

不同用户的输出长度不同。若一批请求必须等待最长答案完成，短请求已经结束所空出的资源可能无法及时补入新任务。长提示的预填充也可能干扰正在流式生成的用户。推理引擎需要在有限显存和计算资源内调度不同阶段的请求。

大白话：流动的餐桌与分页笔记本

连续批处理（Continuous Batching）允许调度器随着请求完成，把新请求加入后续计算批次，不必让整批一起开始、一起结束。分页注意力（PagedAttention）借鉴操作系统分页思想，把 KV Cache 分成块管理，减少必须申请大块连续空间带来的浪费。前缀缓存（Prefix Cache）复用多个请求共同前缀的计算结果，像重复使用同一份已整理的开头笔记。三者分别解决调度、存储和重复计算。

技术原理：队列与缓存块

每个请求有长度、已生成词元、缓存占用和完成状态。调度器在每个迭代或调度周期决定哪些请求继续解码、哪些进行预填充，以及可使用多少词元和缓存块。分块预填充（Chunked Prefill）把长提示拆成可调度的部分，帮助平衡长输入与正在解码的请求，但效果依赖引擎和配置。

分页 KV 管理为逻辑序列维护到物理缓存块的映射，避免每个请求按最大长度提前占用一大段连续空间。它不能改变单个词元需要保存的基础状态，也不是把显存无限扩展到主机内存。某些实现支持交换或卸载，但那是额外策略，具有传输与时延代价。

共同前缀缓存可以节省重复预填充，例如相同长系统提示或重复文档。它不直接减少生成新词元的解码工作。前缀必须满足引擎的精确匹配与缓存键规则；不同模型、适配器、模板或关键上下文不能混用缓存。缓存容量有限，淘汰后仍需重新计算。

公平性与内存压力

如果只追求最大吞吐，调度器可能堆积更多请求，让个别用户等待很久；如果过度限制批规模，又可能浪费 GPU。需要结合业务设置最大活跃序列、词元预算、上下文上限和排队策略。资源不足时可以拒绝、排队或降级，而不是让所有请求一起崩溃。

长短请求混合时，平均值可能掩盖长尾。压测要包含长输入、长输出与突发到达，观察短请求是否被拖慢。缓存命中场景与冷启动场景都要测，不能只报告已经预热后的最好结果。

真实场景：固定手册与个性化请求

教学案例：一批用户围绕同一本长手册提问，前缀复用可能显著减少重复处理材料；但每个用户上传不同文档时，命中率可能很低。输出很长时，解码成本占主导，前缀缓存对总时延的改善也会变小。

vLLM 官方文档核查确认上述能力方向，但 PagedAttention 的特定设计页标记为历史实现说明。因此本课用它解释机制，不声称当前版本固定采用历史页面中的某个内核或数据结构。部署时应记录所用版本、硬件和实际配置。

售前视角与面试回答

“连续批处理让不同请求动态进入计算批；分页 KV 减少缓存管理浪费；前缀缓存复用相同开头的预填充。这些优化可协同，但不会凭空增加显存，也不保证所有业务都同样受益。我会比较冷、热缓存和长短混合负载下的吞吐与尾时延。”

客户要求更高吞吐时，先确认是否接受更大排队延迟；客户要求低延迟时，可能需要更低资源利用率和更多备用容量。性能优化应围绕服务目标，而不是只让看板上的 GPU 利用率变高。

容易混淆

PagedAttention 不等于无限上下文；前缀缓存不等于缓存整段答案；连续批处理不等于无限并发；缓存命中率高不保证解码快；历史设计文档不一定描述当前版本全部实现。

返回目录

20 · 说清时延、吞吐与服务目标

返回目录

从用户感受出发，读懂性能测试报告。

为什么每秒多少 Token 不够

一个系统每秒总共生成很多词元，但某个用户等十几秒才看到第一个字，交互体验仍可能不好。另一个系统首字很快，却后续输出断断续续。售前需要将用户感受分解成可以测量的指标，并说明统计范围与测试条件。

大白话：排队、上第一道菜与上菜节奏

首词元时延（Time To First Token，TTFT）从请求开始到看到第一个输出词元，通常包含网络、排队、预填充和首步生成，具体取决于测量点。每输出词元时间（Time Per Output Token，TPOT）描述后续生成节奏。总时延（Latency）是从请求开始到完成的时间。吞吐量（Throughput）是单位时间完成的工作量，可以按请求或词元统计。

每秒词元数（Tokens per Second，Tokens/s）必须注明是单请求输出速度还是整服务输出总量，是否包含输入。每秒请求数（Queries/Requests Per Second，QPS/RPS）统计请求量，但短分类与长报告的单请求成本相差很大。

技术原理：指标之间的关系

若输出 N 个词元，且后续生成间隔较稳定，教学近似为：总时延 ≈ TTFT ＋（N－1）× TPOT。假设 TTFT 为 1 秒，生成 101 个词元，TPOT 为 0.05 秒，总时延约 6 秒。真实系统还会受到网络缓冲、流式分块和调度波动影响。

并发 C、稳定到达率 λ 和平均在系统内时间 W 在满足稳定系统等前提时，可用 Little 定律近似 C＝λ×W。若每秒两次请求，平均每次十秒，平均在途请求约二十个。突发期间、系统不稳定或用户思考时间未计入时，不能机械套用。

P50、P95、P99 是时延分位数：P95 为两秒，表示所统计样本中约百分之九十五不超过两秒，并不表示每个用户都两秒。尾部时延通常更能暴露排队与资源竞争，但小样本的高分位数很不稳定，应报告样本数量、持续时间和错误率。

从指标到承诺

服务级别目标（Service Level Objective，SLO）是内部或约定的性能可靠性目标，例如在规定负载下某项时延与成功率达到标准；服务级别协议（Service Level Agreement，SLA）通常是正式服务约定，可能含责任与补偿。不能把一次压测最好结果直接写进长期 SLA。

GPU 利用率（GPU Utilization）只是设备活动度的一种观察，不能替代用户指标。更高利用率可能带来更长排队。测量时固定模型、量化、硬件、输入输出分布、到达方式、缓存状态和服务配置，同时记录失败、取消与超时，不能把失败请求从统计中删掉让报表好看。

真实场景：聊天与离线报告

交互聊天通常更关注首字与后续节奏；离线批量报告可能更重视吞吐和完成期限。两者可以使用不同队列、配额和调度策略，避免大批后台任务挤占在线请求。客户说“要快”，应追问是更早看到首字，还是完整答案更早结束，或同一小时处理更多任务。

测试既有闭环并发模式，也有开放到达率模式。闭环客户端等待响应后再发下一次，请求变慢时自然降低到达率，可能掩盖排队恶化；开放模型按规定节奏发送，更容易暴露超载。要选择接近真实使用方式的测试。

售前视角与面试回答

“我会同时报告 TTFT、TPOT、端到端时延、吞吐和错误率，并给出 P95 等尾部指标。输入输出长度、并发、缓存和硬件必须写清。容量是满足目标时延和成功率时的可持续吞吐，不是系统勉强跑出的最大值。”

扩容触发可以结合排队时长、活跃序列、显存余量和尾时延，不能只用 CPU 式的单一利用率阈值。模型加载耗时较长时，要提前扩容或保持热备用。

容易混淆

一千个注册用户不是一千并发；每秒输出词元数不等于每秒请求数；P95 不能用平均值替代；首字快不等于全文快；吞吐峰值不等于满足 SLA 的容量。

返回目录

21 · 从 IaaS 到 AI 算力平台

返回目录

哪些经验可迁移，哪些能力需要补齐。

为什么传统经验不是从零作废

身份、网络隔离、存储、监控、容量、变更与交付管理，在 AI 平台中仍然重要。新增的是 GPU 设备拓扑、显存状态、模型依赖与词元服务指标。你的优势是理解企业基础设施与交付约束，学习重点应放在这些约束如何因 AI 负载而改变，而不是否定已有 IaaS 经验。

大白话：原来的机房，多了一种特殊租户

基础设施即服务（Infrastructure as a Service，IaaS）提供计算、存储和网络等资源。GPU 任务像对电力、散热、通信和软件版本都更挑剔的租户。传统虚拟机可以按 CPU 和内存分配，GPU 还要考虑设备能否共享、共享方式是否有隔离、显存是否足够，以及作业能否跨卡协同。

技术原理：隔离与调度

GPU 直通把物理设备交给虚拟机使用，接近独占模式，但迁移和共享受限。虚拟 GPU（Virtual GPU，vGPU）通过厂商支持的虚拟化方式共享设备，可能涉及许可和特定硬件。多实例 GPU（Multi-Instance GPU，MIG）在支持的设备上划分硬件实例，提供特定资源隔离；支持范围、切分规格和互联能力需查对应型号。

时间片共享（Time Slicing）轮流使用设备，不等于 MIG 的硬件隔离，也不保证显存被安全独立分区。GPU 池化与调度需要考虑模型大小、卡型、拓扑、队列优先级和碎片。一个作业需要连续的同机多卡时，集群还有很多零散空卡也可能无法满足。

调度系统要记录驱动、CUDA 或其他计算平台、框架、通信库和模型要求的兼容矩阵。镜像固定并不意味着宿主环境一致；驱动升级可能影响全部模型，必须先灰度测试并具备回滚。

高速网络与存储

远程直接内存访问（Remote Direct Memory Access，RDMA）允许网络设备以较少 CPU 介入传输数据；RoCE（RDMA over Converged Ethernet）在以太网上承载 RDMA，InfiniBand 是另一类常用于高性能互联的网络技术。它们不是简单把网卡速率提高就自动生效，还需要交换、拥塞控制、拓扑和端到端配置。

跨节点训练与模型并行可能频繁同步，通信性能影响扩展效率；普通独立推理副本的请求负载均衡通常没有同样强的跨卡同步需求。因此先看工作负载，再决定是否需要昂贵的高速网络。

存储既要支持模型分发，也要支持数据集和检查点吞吐。大量节点同时加载模型会冲击共享存储；可采用校验后的本地缓存和分阶段发布。小文件数量、元数据压力和网络竞争同样重要，不能只看标称顺序读写带宽。

真实场景：四种交付形态

裸金属让客户独占整机并承担较多管理责任；GPU 云主机提供虚拟化使用体验，需核查直通或共享方式；专属算力可以在约定资源池中隔离分配；算力托管可能包含机位、电力、网络、硬件和运维中的部分，具体责任以合同为准。名称相似不代表服务边界相同。

教学方案：研发试验使用按需资源，稳定在线推理使用保留副本，跨节点训练使用经过验证的高带宽集群。通过统一配额和队列管理资源，但为不同负载制定不同服务目标。

售前视角：把迁移能力讲清楚

可迁移能力包括需求访谈、容量估算、网络分区、可用性设计、成本比较与交付协同。新增能力包括模型显存、KV Cache、并行拓扑、推理调度和词元性能评估。面试时把两者连接：“我熟悉企业基础设施约束，现在用模型结构和请求负载把这些约束转换为 AI 服务容量。”

不要把传统虚拟化超分经验直接照搬到高负载 GPU。明确卡型亲和、作业抢占、共享隔离和故障恢复策略，并观察 GPU 错误、显存、功率、温度、网络与作业状态。

面试怎么说

“IaaS 的安全、网络、存储和运维方法可以迁移，但 GPU 服务新增显存、拓扑、驱动框架兼容和模型调度约束。我会根据训练、推理或开发负载选择独占、虚拟化或共享方式，并用业务服务指标验收。”

容易混淆

MIG 不适用于所有 GPU；时间片不等于硬件隔离；有 RDMA 网卡不等于端到端 RDMA 配置正确；容器不解决所有驱动兼容；空闲卡总数足够不等于拓扑满足作业。

返回目录

22 · 高可用、成本与数据中心交付

返回目录

把模型服务放回真实的机房和商业条件里。

为什么技术方案必须考虑运行多年

PoC 可以只跑一台机器，生产却要面对硬件故障、模型升级、流量突增和电力维护。高可用（High Availability，HA）并不是写一句“做双机”，而是在明确故障场景下仍满足业务要求。总拥有成本（Total Cost of Ownership，TCO）也不只是 GPU 采购价。

大白话：备用厨房与整年账单

把一份模型切到四张卡，通常是一个协同工作的实例，不是四个互为备用的服务。任一卡故障可能影响整个实例。高可用需要独立可接管的副本或明确的恢复方案，并考虑网关、存储、配置和身份服务等依赖。

自建的账单包含设备折旧、电力、制冷、机位、网络、软件许可、运维和闲置容量；租赁的账单包含资源时间、存储流量、支持服务及数据迁移成本。比较时使用同一业务负载、服务目标和时间周期。

技术原理：故障域与容量

设计故障域时看 GPU、节点、机架、电源与可用区。模型副本分布在不同节点能降低单机故障影响，但如果共同依赖一个无冗余网关或共享存储，仍可能整体不可用。热备用已加载模型，接管快但占资源；冷备用节省常驻资源，但模型下载和加载需要时间。

负载均衡应了解实例健康与排队状态。请求重试需要考虑流式输出已经给用户发送多少内容，不能把两次答案拼在一起。限流、排队上限和降级策略用于保护系统，超载时应返回明确状态。扩容受资源申请、镜像拉取和模型加载时间影响，不像普通轻量服务那样总能瞬间生效。

恢复时间目标（Recovery Time Objective，RTO）描述希望多久恢复；恢复点目标（Recovery Point Objective，RPO）描述可接受的数据丢失窗口。纯推理权重可从可靠存储重载，但会话、任务状态、审计和索引更新可能有不同 RPO。逐项分类，不能用“模型是无状态的”忽略外围数据。

电力、散热与机柜

高密度 GPU 服务器带来更高机柜功率需求，要核查机柜供电、配电冗余、上游容量和实际散热能力。风冷依赖足够空气流量和合理冷热通道；液冷常通过冷板和液体循环带走热量，还需要冷却分配单元、管路、泄漏检测和维护流程。不能把支持液冷理解成随便接一根水管。

电能使用效率（Power Usage Effectiveness，PUE）＝数据中心总能耗÷ IT 设备能耗。教学例子：IT 设备平均功率 10 千瓦，持续 24 小时，IT 用电约 240 千瓦时；若采用 PUE 1.4 的假设，总设施折算用电约 336 千瓦时。这个例子不是具体机房测量值，价格还需乘以实际电价，且峰值功率与平均能耗不同。

自建与租赁的算账方法

先定义测算周期和利用率假设。自建每月成本可由设备折旧、资金或租赁费用、电力制冷、机位网络、许可运维及备件组成；云资源按实际计费单位、运行时间、附加存储网络和支持费计算。需要高可用时，两边都计入冗余，不能拿单机自建与双区云服务比较。

教学场景：业务量不稳定、模型经常更换时，租赁有灵活优势；长期稳定高利用率且有运维能力时，自建可能值得评估。最终结论取决于真实报价、资源可用性、数据要求和资金周期。本教材不编造 GPU 市场价格，也不提供没有假设的回本月份。

售前视角：交付验收与故障演练

验收除了正常负载压测，还应包含实例退出、节点失联、模型加载失败、存储不可用和配置回滚。记录恢复时间、在途请求处理和告警是否准确。部署文件、资产清单、版本基线、备份与运维手册要能交给客户接手。

商业方案写清交付范围、验收指标、数据准备责任、服务时间、备件与维修响应，以及模型和框架后续升级是否包含。把“支持七乘二十四小时”具体化为监控、响应和恢复的不同承诺。

面试怎么说

“我会把模型并行和服务高可用分开设计：多卡切分解决单实例容量，独立副本与依赖冗余解决故障恢复。成本按相同负载与SLO比较，包含电力、散热、运维和备用容量。最后通过故障演练与回滚验证交付。”

容易混淆

多卡不等于多副本；备用资源不一定已加载模型；峰值功率不是月平均能耗；PUE 不是设备本身效率；租赁单价低不等于全周期成本低；SLA 不能只依据一次最好压测。

返回目录

案例 A · 3000 人企业知识库

返回目录

从需求访谈、PoC、架构到报价与交付。

为什么先谈业务边界

这是教学假设案例，不代表学习者曾交付过该项目。客户希望给三千名员工建设内部问答系统。员工总数只说明潜在使用人群，不能直接推导调用量、并发或 GPU 数。首先确定试点部门、主要问题、可用资料、错误代价和业务收益，例如减少查找制度的时间，而不是泛泛地追求“全公司智能化”。

访谈业务负责人：最常被问的二十类问题是什么，现有查找方式耗时多少，哪些结论必须人工确认。访谈信息部门：身份系统、文档平台、部署位置、网络出口、接口与运维能力。访谈安全部门：数据分级、权限、日志保留、外部模型调用和供应商远程维护边界。三类访谈共同形成需求基线。

大白话：先整理资料室，再雇讲解员

企业知识库的价值不是多一个聊天框，而是让员工更快找到有权查看且当前有效的资料。资料整理、搜索能力和答案解释分别像资料管理员、检索员与讲解员。任何一环失效，系统都可能流畅地给出不可靠答案。

技术方案：四层架构

数据层通过连接器采集文档，保存原件与版本；解析流程处理 PDF、Word、网页和扫描件，抽检表格与标题层级。索引层保存分块、向量、关键词和权限元数据，提供增量更新、删除与版本切换。问答层根据身份过滤、混合检索、重排序和上下文预算生成带来源答案。治理层提供统一身份、限流、日志、监控、评估和回滚。

选型先比较托管接口与私有化部署的可行性。若制度允许非敏感内容调用外部模型，可降低初期维护负担；敏感资料需要在批准边界内完成解析、嵌入、重排和生成。已有 PostgreSQL 且规模适合时可验证 pgvector；需要独立检索服务时比较 Milvus。模型以中文制度、产品手册和无答案问题测试结果为准，不预先承诺某一参数量。

身份授权在检索之前建立，来源访问再次验证。普通员工与管理部门使用不同可见范围；日志按敏感等级脱敏。对现行制度使用有效期过滤，对历史问题要求明确日期；删除和撤权进入可监控的更新任务。

PoC：明确输入和退出条件

教学计划可以先选三类代表材料和约一百五十道经业务审核的问题，其中包含表格、跨文档、旧版本、无答案与权限反例。具体数量由覆盖面决定，并不是越多越好。预留一部分题作最终验证，调整提示时不反复查看。

第一轮只检查资料能否正确解析；第二轮检查证据是否进入候选；第三轮检查答案正确性与引用；第四轮验证权限与性能。双方预先约定合格阈值、严重错误定义和重测方式，不能项目结束后才临时挑有利指标。这里不预填“准确率百分之九十五”作为通用保证，因为业务难度和样本尚未确认。

性能测试记录输入输出分布、到达率和缓存状态，先测小规模试点，再逐步增加负载，找出满足目标尾时延和成功率的可持续容量。对外展示原始条件与失败样本，而不只展示一张最高吞吐图。

报价结构与实施交付

报价分一次性与持续两部分。一次性包括资料治理、连接器、身份权限集成、页面与接口、部署、测试和培训；持续项包括模型调用或算力、索引与对象存储、备份、运维及质量运营。每项说明计量基础、包含范围和客户责任，不虚构设备单价。

阶段交付为需求基线、样本集、PoC 报告、试点系统、生产与运维移交。客户提供数据授权与业务评审人员；供应方提供配置、监控、回滚和培训。扩展到全部员工之前，要完成权限反例、文档更新时效、备份恢复及峰值负载验证。

风险与上线后的改进

最大风险常是资料不完整、权限来源不一致和业务期待不明确。对每项风险指定负责人、验证方法与截止时间。上线后采集经脱敏的失败类型：没检索到、找到但过期、条件缺失、生成不忠实、引用失效。按类型修复，避免每次都更换模型。

可用降级是返回搜索结果和原文，或把问题转人工。对没有可靠证据的问题明确说明不足。用户反馈要能关联具体问题、文档版本和模型配置，才能形成可重复改进。

面试表达：两分钟结构

“我会先确认三千名员工中的实际使用部门和任务，梳理文档、权限与更新要求。技术上分数据治理、检索、生成和平台四层；PoC 先验解析和召回，再验答案、权限及性能。报价拆一次性集成和持续资源费用。试点通过后再扩展，交付时保留版本、回滚和运营指标。”

如果没有真实交付该项目，应说“如果负责这个项目，我会这样设计”，不能把教学案例改写成自己的客户经历。

容易答错

直接给三千人配三千并发；承诺 RAG 不会幻觉；把权限放进提示；只测十道演示题；认为买向量数据库就完成知识库；把业务方整理资料的工作遗漏出报价。

返回目录

案例 B · 1000 人与 70B 私有化

返回目录

用请求、Token 和服务目标推导容量候选。

为什么先挑战“直接报几张卡”

这是教学假设案例。客户有一千名员工，希望部署 70B 模型。先问选择 70B 的原因：是否在真实任务上优于较小模型，是否有许可证与部署要求，输出质量标准是什么。参数量可能是客户从宣传中形成的偏好，不应成为唯一设计输入。

员工总数不等于同时使用人数，同时在线也不等于同时生成。应采集日活、每人请求数、忙时占比、请求间思考时间和输入输出长度。没有历史数据时先采用清晰假设做区间，并通过试点校正。

大白话：按真实订单配置厨房

一千名员工像一千名会员，不会每个人时时刻刻都在下单。真正决定服务压力的是忙时每秒来多少请求，每份请求有多长，以及希望多久完成。显存决定能容纳的状态，计算与带宽决定服务速度，冗余决定故障时还能剩多少能力。

数字推导：带着单位计算

教学假设：每天四百名活跃员工，每人二十次请求，共八千次；其中百分之四十集中在两小时内，即三千二百次。忙时平均到达率约为 3200÷7200＝0.444 次每秒。若暂用三倍突发系数，规划探索点约为 1.33 次每秒。这个系数不是行业常数，必须用真实访问曲线验证。

再假设平均输入 2000 词元、输出 500 词元，规划探索点对应约每秒 2667 个输入词元和 667 个输出词元。输入与输出分别记录，不能加起来后直接与某张只测输出的性能表比较。如果平均端到端处理十秒，按稳定系统近似平均在途请求约 13.3 个；突发、长尾与排队可能让峰值更高。

首轮测试至少覆盖短问短答、长文档总结与长代码输出。用长度分布代替单一平均值，记录最大长度和高分位长度。客户真正关心的是这些请求在忙时能否达到约定 TTFT、TPOT、成功率和总时延。

显存与候选策略

70B BF16 理论权重约 140 GB；四位权重约 35 GB，但量化元数据、高精度层、KV Cache 与工作空间另计。读取目标模型配置，再按真实 KV 头数和层数估算缓存，不凭“70B”自动填结构。

候选甲保留 BF16，用合适多卡切分，追求质量基线；候选乙采用经评估的量化，减少权重占用并可能增加副本；候选丙比较较小模型或任务分流，看能否满足质量标准同时降低成本。所有候选都需要在目标硬件与互联上实测，不能仅按显存总和得出 GPU 数。

如果模型并行实例占用多张卡，仍只算一个服务实例。高可用应有独立副本或明确的恢复容量。故障后仍满足服务目标，才算满足约定冗余；不能把全部资源平时用满，再声称有备用能力。

压测与扩容方案

先做单实例基线，逐步增加到达率，记录排队、显存峰值、首词元与输出节奏，找到拐点。再做多副本负载均衡与故障测试，观察一实例退出后其他实例是否超载。测试需包含冷启动、缓存未命中、长输入及客户端取消。

容量结论应写成“在指定模型版本、精度、硬件、长度分布和到达率下，达到某项 SLO”，并附原始测试条件。扩容触发由尾时延、队列和余量共同决定。由于模型加载耗时，提前保留热容量或预测忙时，避免等到超载才开始下载权重。

商业取舍与交付

报价给出质量、成本和可用性不同的候选，而不是只报最贵配置。列明服务器、网络、电力散热、软件、运维、备份和冗余。租赁与自建用相同周期和负载比较，试点量小与正式生产量大的成本结构可能不同。

交付包括模型版本与许可证记录、可复现镜像、配置基线、压测报告、监控阈值、上线与回滚步骤、故障演练及运维培训。若数据仍不足，应交付容量验证计划与保留条件，不给没有依据的并发保证。

面试表达

“我不会用一千名员工直接换算卡数。我先估请求到达率和输入输出词元负载，再独立计算权重与缓存，选择量化、多卡或副本策略。最后在目标硬件上验证服务目标，并把故障余量、扩容时间和成本放入方案。”

容易答错

将注册人数当并发；将平均每秒请求数当峰值；把输入吞吐与输出吞吐混比；用理论显存除单卡容量后直接四舍五入报卡数；把同一模型的四卡切分当作四副本；省略量化质量回归。

返回目录

案例 C · 企业 AI 开发助手

返回目录

把辅助编程经验转成需求、治理与推广能力。

为什么开发助手不是一个统一需求

这是教学假设案例。研发团队可能同时需要低延迟代码补全、解释陌生代码、跨仓库检索、生成测试和自动完成小任务。补全对延迟敏感，代码库问答依赖索引与权限，Agent 开发涉及文件修改与命令执行。把这些都称作“AI 编程”会掩盖不同的架构和风险。

大白话：从词语提示到协作工程师

代码补全像在编辑时提供下一句建议；代码解释像导师讲解某个函数；代码库检索像熟悉项目的资料员；开发 Agent 则可能查文件、修改代码、运行测试并整理结果。能力越接近真实操作，越需要明确范围、可审查变更和恢复手段。

技术方案：入口、知识、执行与治理

入口可以是 IDE 插件、命令行或网页。网关统一身份、租户、配额、模型路由与日志策略。补全服务选择适合低延迟的模型与短上下文路径；解释和设计任务使用更强模型；代码库索引按语言结构提取函数、类、路径与依赖，并保留提交版本。

检索层同时使用符号名称、路径关键词和语义匹配，避免仅向量搜索找错相似函数。权限继承代码托管系统，用户不能通过问答看到无权访问的仓库。索引随提交增量更新，答案和代码引用应指向具体版本，避免解释了已经修改的函数。

执行层在隔离工作区或容器中运行 Agent，限制可访问目录、网络与工具。文件变更展示差异，测试在限定环境执行；合并、发布、凭据访问和生产操作进入独立授权流程。模型生成的代码需要审查，不能把测试通过当作绝对安全证明。

隐私与知识边界

明确哪些代码、日志和提示可以发送到外部服务，供应商是否保留数据、如何使用以及管理员如何配置。密钥扫描与敏感文件排除应在发送前执行，不能只写在员工培训文档里。私有化部署仍需要日志脱敏、内部权限和审计。

源代码注释、仓库说明和依赖文档可能包含提示注入，不能赋予它们比用户授权更高的权限。工具执行器限制任意命令与外发目标；对依赖安装和下载，也要采用企业批准的来源与网络策略。版权与许可问题需按公司政策审查，不能以“AI 生成”自动豁免。

PoC：用任务结果衡量价值

选择代表性的日常任务：解释陌生模块、修复一个有明确复现的缺陷、补测试、生成接口调用和跨文件小改动。比较无助手与有助手的完成时间、评审返工、测试结果、开发者采纳和失败原因。避免只用生成代码行数衡量效率，代码越多不一定越好。

代码补全记录延迟与建议采纳；代码问答检查引用和版本；Agent 任务检查完成率、人工干预、越界操作拦截和变更可审查性。对隐私与权限做反例测试，例如请求另一个团队仓库内容、诱导读取凭据文件或自动发布。

推广、培训与商业方案

先在自愿参与的小团队试点，培训如何表达任务、提供复现、审查差异和验证结果。整理真实成功与失败案例，建立内部使用规范和支持渠道。推广不是把插件装完，而是让团队知道哪些任务适合、怎样验证、遇到问题如何反馈。

成本包含许可或模型调用、代码索引、算力、集成、培训和持续支持。按活跃使用与任务收益评估，不把购买席位数当成真实使用量。规模化前确认代码库规模、分支更新频率、网络与身份集成。

如何表达自己的真实经验

可据实说：“我使用过 AI 辅助编程工具开发软件，接触过模型 API，也参与过工具推广。我理解用户在任务描述、代码验证、隐私和使用习惯上的障碍。对于企业级方案，我会把这些经验映射到场景划分、PoC、权限治理和落地培训；大规模生产部署的部分，我会用实验和团队协作补齐。”

如果没有实施过企业全量上线，应明确区分个人动手验证、推广参与与方案推演。可展示真实项目中的问题描述、修改前后差异和测试记录，但不要带出公司保密代码或夸大个人负责范围。

容易答错

把补全与 Agent 开发混成一个性能指标；用生成行数证明效率；忽视仓库权限和提交版本；把个人使用经历包装成大型企业交付；让 Agent 默认拥有生产部署权限。

返回目录

面试表达 · 从 IaaS 售前到 AI 方案

返回目录

讲出可迁移能力，诚实区分实践与理论。

为什么不必伪装成算法研究员

招聘中的技术栈要求，通常是为了判断你能否理解客户目标、解释技术取舍、协调资源与控制交付风险。算法论文能力与售前方案能力有交集，但并不是同一岗位要求。承认自己尚未做过某类大规模训练，并不妨碍你展示可靠的需求分析和架构方法。

大白话：把已有地图扩展到新区域

你熟悉服务器、虚拟化、网络、存储和客户沟通，这是地图的主体。新增的是大模型生成机制、RAG、工具调用、GPU 显存与服务性能。面试应把新知识挂到真实经验上，而不是背一串产品名。

90 秒自我介绍模板

“我有多年云计算、IaaS、数据中心基础设施与政企售前经验，主要能力是把客户需求转成可落地的架构、资源与交付方案。近年我实际使用 AI 辅助编程开发软件，接触模型 API，并参与过 AI 工具推广，因此对应用场景、使用体验和落地阻力有直接认识。

为了转向 AI 解决方案，我正在系统补齐 LLM、RAG、Agent 和 GPU 服务化知识。我的思路是把模型能力与基础设施、权限、成本和验收连接起来。例如企业知识库，我会先做数据和权限调研，再设计检索、生成与评估；70B 私有化，我会先估请求和词元负载，再算权重、缓存并通过压测确定容量。

我会清楚区分实际项目、个人验证和理论方案。对于尚未负责过的大规模 AI 生产部署，我不会夸大经验，但能用已有的售前方法和可复验实践快速补齐，并与算法、研发和交付团队协作。”

技术追问如何组织

采用“问题—机制—取舍—验证”四句式。先说技术解决什么问题，再解释一层真实机制，随后说适用条件与代价，最后说怎样验证。例如：“Rerank 解决初筛候选不够准确；它联合比较问题与片段；代价是额外时延且救不了漏召回；我会对比加重排前后的证据排名和答案质量。”

遇到未知问题，先澄清定义，再给已知边界：“我没有在该型号上做过实测，不能保证吞吐；可以先核查显存与兼容，再用目标长度和并发压测。”这比猜一个漂亮数字更专业。

项目经历怎样讲

对真实项目使用情境、任务、行动、结果的结构，但每个结果都要有可证明依据。可以讲客户需求如何变化、你怎样协调网络或安全要求、如何制定验收和处理风险。迁移到 AI 时说明同一方法会增加哪些检查，例如文档权限、模型质量和词元负载。

个人验证可以说“我在自己的开发任务中试用过工具，观察到某类问题，需要人工审查和测试”，不要升级成“我带领公司完成某行业生产落地”。理论架构直接标为假设案例。没有数据就描述观察和限制，不编造百分比收益。

面试前准备材料

准备一张 RAG 架构图、一张推理服务图、一个显存算例和一个真实辅助编程例子。每份材料能在两分钟内解释，并能回答失败时怎么排查。检查所有数字的来源与单位，特别是单卡和整机、GB 与 GiB、人数和并发。

可以主动说明自己的成长路径：先跑通小规模验证，建立数据与性能评估方法，再参与生产交付。把学习转化为可检查的产物，比声称“最近一直关注 AI”更有说服力。

不能踩的线

不要虚构公司客户、GPU 集群规模或性能提升；不要把他人团队结果全部算成个人交付；不要对许可证、安全或成本做没有依据的承诺。诚实说清责任范围，同时展示你知道下一步如何验证。

返回目录

深读 01 · 一台 GPU 服务器，除了显卡还有什么

返回目录

CPU、内存、PCIe、NUMA、网卡和电源，怎样共同影响模型。

为什么“八卡服务器”仍不是完整配置

客户确认八张 GPU 后，可能接着问 CPU 配几颗、内存多大、几张网卡、磁盘怎么配。不能只围绕 GPU 回答，因为数据准备、模型加载、通信和服务调度都依赖其他组件。显卡再强，如果输入数据一直送不过来，也会出现“显存占着、算力闲着”的现象。

先区分服务器用途：在线推理重视稳定时延与副本恢复；训练重视持续数据供给、通信和检查点；研发环境还要容纳交互式任务、容器和多人共享。不存在一套只按 GPU 数量就能确定的 CPU、内存和网络比例。

大白话：车间工位之外还有走廊和备料区

GPU 是大量并行加工工位，CPU 处理调度和较复杂的控制，主机内存是备料区，PCIe 是设备与主机之间的通道，网卡是连接外部的出入口。本地磁盘保存系统、模型或数据缓存。工位多而走廊窄，或者备料不足，整条生产线仍会慢。

非统一内存访问（Non-Uniform Memory Access，NUMA）表示不同 CPU 插槽访问不同区域内存的距离和代价不同。想象两栋楼各有自己的仓库：访问本楼仓库通常更近，跨楼搬运要经过连接通道。

技术原理：先读拓扑，再配数量

PCIe 通道数和连接树决定设备之间实际共享哪些上行链路。两个插槽看起来都能插网卡，可能一个直接连 CPU，另一个与多张卡共享交换芯片上行。GPU、网卡和主机内存的 NUMA 归属会影响数据路径，因此既要看物理插槽，也要看整机拓扑图。

双路 CPU 平台并不自动让所有设备都等距离。尽量按厂商认证的布局让高频协作设备具备合适路径；某些拓扑需更严格的亲和性设置，具体取决于 GPU 直连传输、CPU 互联和软件。不能只根据“同一台服务器”判断通信代价很低。

PCIe 代际与链路宽度也要匹配。端口标称带宽并不等于可持续数据有效吞吐，编码、事务与软件都有开销。网卡提供两个高速网络端口时，要核查 PCIe 主机接口和工作模式，不能直接假定双端口都能同时达到各自标称上限。

主机内存与磁盘怎样估

先列内存消费者：操作系统和容器、模型加载或转换、分词与批处理、训练数据预取、页锁定缓冲区，以及可能的 CPU 卸载。页锁定内存（Pinned Memory）是避免被系统换出的内存，有助于某些设备传输，但申请过多会挤压其他进程。

教学假设：模型制品为 140GB，加载流程可能需要额外副本或转换缓冲；是否占两倍不能靠猜，要看加载方式并测峰值。若还把部分权重卸载到主机内存，内存需求和 PCIe 流量都会增加。不要说“内存只要等于显存就够”，也不要用所有 GPU 容量简单乘一个固定系数作为通用规则。

系统盘可按运维要求做冗余；数据或模型缓存盘按容量、持续吞吐、写入寿命和恢复方式规划。本地 NVMe（Non-Volatile Memory Express，面向非易失存储的高速访问协议）常用于缓存，但单块盘不是共享可靠存储的替代品。丢失缓存可重新下载，与丢失唯一训练结果的风险不同。

电源、散热与管理口

冗余电源要核对配置模式和降额条件。例如两只电源同时满载供电，并不代表失去一只后仍能供给整机峰值。还要确认机柜供电、支路和相位，避免两路电源最后接到同一故障点。

带外管理（Out-of-Band Management，OOB）通过独立控制器或管理路径查看硬件、远程开关机和装系统。业务网络断开时仍需要管理能力，所以管理口、管理交换机及安全隔离也要进入方案。GPU 互联网络不能代替这些管理功能。

售前场景：怎样向客户索取完整条件

让整机厂提供 CPU—内存—PCIe—GPU—网卡拓扑图、卡槽支持列表、电源散热条件和驱动固件组合。对训练确认数据吞吐与检查点；对推理确认分词、网关、模型加载和故障恢复。采购清单写到服务器配置和兼容矩阵，不能只写“某型号GPU八张”。

有现成样机时，分别测模型加载、单节点推理、CPU和GPU间传输、网卡带宽，再做整体负载。硬件烧机通过只说明基本健康，不等于模型任务达到服务目标。

面试追问怎样回答

“我先按训练、推理或研发用途确认数据路径，再核对整机拓扑。CPU和内存承担调度、分词、数据与加载，网卡需要匹配GPU和NUMA路径；磁盘区分可靠数据与可重建缓存。电源、散热、带外管理和软件兼容一起验收，不能只报GPU。”

容易混淆与继续追问

GPU 显存和主机内存不是同一资源池；增加内存不会自动解决显存不足；网卡端口数不等于网卡张数；同一服务器里的设备不一定具备同等路径；双电源不自动证明满载单电源可接管。

接着可问自己：数据是从哪里来、经过哪块网卡、哪段PCIe、哪个内存区域，最后到哪张GPU？沿着这条路径，就能把传统服务器知识接到AI性能排查。

返回目录

深读 02 · GPU 集群为什么常有好几张网络

返回目录

先分清业务、存储、计算和管理，再讨论 InfiniBand。

为什么“交换机买多少台”不能先答数字

同样是八台 GPU 服务器，八个完整模型独立服务用户，与八台共同训练一个模型，对网络的要求相差很大。前者主要传问题与回答，后者可能在每一步交换大量梯度或中间结果。设备数量应从通信任务、拓扑和可用性推导，而不是按“每台服务器两台交换机”的习惯决定。

先画出谁和谁通信：用户到网关、节点到存储、GPU节点之间、运维到管理控制器。画清流量后，才能判断哪些共网、哪些隔离，哪些需要低延迟高速互联。

大白话：访客路、货运路与内部协作通道

业务前端网络负责用户访问和接口；存储网络负责数据集、模型和检查点；计算后端网络负责节点间协作；管理网络负责装机、监控和带外操作。像园区里的访客道路、货运通道和车间传送线。

这是按职责划分，不意味着每个项目一定要建四套完全独立的物理网络。小型环境可在经过评估后共用部分网络；大规模或高风险环境会更强调带宽、故障和安全隔离。逻辑隔离也不自动消除共用链路上的拥塞。

技术原理：单位和带宽口径

网络规格常用 Gb/s，即每秒十亿比特；文件和显存常用 GB，即十亿字节。一个字节等于八比特，所以 400Gb/s 除以八，得到理论 50GB/s 的原始速率上限。扣除协议、实现和传输损耗后，有效吞吐更低。不能把“400G网卡”解释成每秒400GB文件。

双向带宽与单向带宽、每端口与整机聚合带宽要分别看。一个全双工端口可同时收发，但一次单向传输不能把两个方向相加。交换机总吞吐可能按全部端口双向累计，不能拿这个数与一条链路的单向流量比较。

网络延迟对频繁小消息很重要；带宽对大块持续传输很重要。某些训练同时受两者影响。请求文本很小不意味着整个AI系统网络流量小，模型分发、检索、日志和节点协作仍可能占大头。

InfiniBand 与 RoCE 如何理解

InfiniBand 是面向高性能通信的网络技术；RoCE 是在以太网上承载 RDMA 的路线。它们都可能用于GPU集群，但设备、交换网络、管理与软件配置不同。把现有以太网“换一张RDMA网卡”不代表已经具备完整高性能网络。

InfiniBand 网络需要相应的子网管理能力；RoCE需要关注拥塞控制、队列和端到端一致配置。选择还取决于已有运维团队、规模、应用支持、供货和预算。对独立推理副本，先验证普通高质量以太网是否足够，不因“AI项目”就直接引入最复杂网络。

多网卡、多平面与多轨道

服务器可以有多张网络适配器，也可以一张适配器暴露多个端口。多平面（Multi-plane）把通信分到不同网络平面；轨道优化（Rail-optimized）常按GPU或网卡对应位置组织通信路径，减少某些流量的跨层跳转。它们不是“把所有网口随便捆绑起来”。

传统以太网链路聚合不等于训练通信库自动把任意RDMA端口容量相加。需要核对通信库选择网卡、GPU映射、路由与拓扑的方式。八个端口接入同一张大网与八个端口分别接入八个平面，设备和线缆计数可能完全不同。

真实场景：两种八节点方案

教学场景甲：每台服务器独立运行推理副本，网关均衡分发请求，主要验收端到端时延、模型分发与故障切换。场景乙：模型跨八台运行，每步需要集合通信，重点验收节点间带宽、延迟和应用扩展效率。不能把甲的网络预算直接复制到乙。

存储流量与训练流量共网时，集中写检查点可能干扰训练通信；业务与管理共用一个故障点时，业务异常可能让排错入口也失联。是否分网要用流量和故障场景说明，而不是只画不同颜色。

售前怎么一步步回答

“我先区分业务、存储、节点协作和管理流量，确认是独立副本还是分布式作业。再确定每节点网络端口数和速率，结合拓扑、超售比与故障目标计算交换机、端口和链路；最后核对物理连接器、模块、布线和运维。”

采购前需要网络拓扑、端口分配、地址或子网规划、冗余方式与验收方法。不要用服务器台数直接乘一个固定交换机系数。

容易混淆

400Gb/s不等于400GB/s；双端口不一定意味着两张网卡；计算网不等于管理网；多轨道不等于普通链路聚合；无超售不等于任何应用都线速。接下来读“交换机与链路怎么算”，把这些概念落成数量。

返回目录

深读 03 · 交换机、网卡和线缆到底怎样算

返回目录

用完整数字例子拆解 Leaf–Spine，明确哪些数能算、哪些要验证。

为什么必须先写假设

网络设备清单至少依赖服务器数、每服务器计算网络端口数、每端口速率、交换机可用端口、下联与上联分配、拓扑层数和冗余目标。还要确认端口是否能拆分、速率是否相同、多平面怎样接。缺少这些条件时，准确回答应是先补条件并给计算路径，而不是猜一个台数。

本课采用教学抽象：所有网络端口同速；交换机有32个独立、可用的逻辑端口；构建两层Leaf–Spine网络。这个32口不是某款真实交换机的默认规格。物理连接器数量与逻辑端口数可能不同，真实设备必须看规格书。

大白话：楼层接入与楼间骨干

叶交换机（Leaf Switch）直接连接服务器，脊交换机（Spine Switch）连接各叶交换机。把Leaf看作每层楼的接入点，把Spine看作楼间的骨干通道。服务器占下联端口，通向Spine的链路占上联端口，同一根层间链路还占一个Spine端口。

超售比（Oversubscription Ratio）可按“下联带宽总量÷上联带宽总量”说明。十六条400G下联配八条400G上联，就是2:1；十六下联配十六上联是1:1。1:1表示这一层带宽容量没有超售，还需核对路由、交换能力和故障条件。

技术原理：按端口守恒计算

设服务器数为N，每服务器计算网端口数为H，总服务器端口E＝N×H。每台Leaf使用D个下联、U个上联，交换机端口数P至少满足D＋U≤P。需要的Leaf数量L至少为向上取整(E÷D)。这是单网络域的均匀教学模型，不代表真实多平面一定如此。

上联总链路为L×U，对应需要同样多的Spine端口。若有S台Spine且要求每台Leaf均匀连到每台Spine，每个Leaf—Spine对用U÷S条链路；这要求在该简化模型中U能被S整除，并且每台Spine使用L×U÷S个端口、不超过P。满足总端口数只是必要检查，还要看连接模式与交换能力。

服务器接入链路有E条，层间链路有L×U条，总点到点链路E＋L×U。交换机实际被用端口为E＋2×L×U：一条服务器链路只占一个交换机端口，层间链路占两端交换机端口。这个守恒关系能抓出许多漏算。

完整算例：8台服务器，每台8个计算网端口

总服务器端口是8×8＝64。教学交换机每台32个逻辑端口，Leaf分16下联、16上联，因此需要4台Leaf。选择4台Spine，每台Leaf向每台Spine连接4条链路，恰好用完16个上联；每台Spine连接4台Leaf、各4条，总用16个端口，仍有余量。

清单是4台Leaf＋4台Spine；64条服务器接入链路＋64条层间链路，共128条点到点链路。交换机被使用端口为64＋128＝192个，另有64个服务器端口。若所有链路400G，单Leaf满配下联与上联都为6400Gb/s，容量比为1:1。

这里4台Spine是明示的布局选择，不是数学上最少台数。在相同抽象条件下，也可讨论更少Spine、每对更多并行链路，但故障影响与端口占用会变化。多路径不自动证明N-1时仍保留全部带宽，断一台设备后必须重新算剩余容量。

线缆与光模块：链路数不等于模块数

若每条链路都是两端独立可插拔光模块加一根兼容光纤，在不考虑拆分和特殊封装的教学假设下，128条链路对应256个链路端模块。这个数不能直接抄到真实采购单：DAC（Direct Attach Copper，直连铜缆）和AOC（Active Optical Cable，有源光缆）通常以完整线缆组件交付；一个模块也可能承载多个逻辑端口。

例如某些设备的物理OSFP笼位可承载两个400G逻辑端口，物理笼位、可插拔模块、光纤支路和网络逻辑端口并非一一对应。实际要按厂商认证的线缆矩阵、距离、连接器、拆分方式与备件核对。还应计入管理和存储网络，不能把计算网清单当整个项目清单。

多平面、故障与成本怎么扩展

如果八个服务器端口分别归属八个独立平面，应逐平面计算节点数、每节点接入数和交换拓扑，再汇总。小规模平面可能一层交换就够，不能把本课单域两层例子机械乘八。

冗余问题要问“丢失一台Leaf影响谁”“丢失一台Spine剩多少带宽”“双端口是否共享同一适配器故障”。N+1设备数、路径冗余与完整性能冗余不是同一承诺。总成本还包括安装、光纤配线、布线距离、测试、维护和备件。

售前面试可以这样回答

“我先确定每节点计算网端口与速率，再按Leaf下联容量算接入数量，按上联与Spine端口预算算骨干；然后数服务器链路、层间链路和连接组件。举例8节点每节点8端口，采用32逻辑口、16下16上的教学网络，可用4Leaf与明确选择的4Spine，共128条点到点链路。真实BOM还要核对拆分、光模块和故障后带宽。”

容易混淆与计算边界

不要把32个物理笼位必然当32个网络端口；不要只数下联漏掉上联；不要把每端口400G、双向累计与整机吞吐混加；不要把1:1容量条件叫作任何流量下都严格非阻塞；不要把理论50GB/s当应用实测。

上面的算例使用均匀单域、同速端口的两层网络。做采购和交付方案时，还需核对实际端口、链路布局和互操作性，并用目标工作负载验证通信性能。

返回目录

深读 04 · RDMA 为什么快，为什么仍可能慢

返回目录

把少拷贝、GPU 直连、流控和拥塞串起来。

为什么“支持RDMA”不是验收结果

传统网络路径可能涉及多次数据拷贝、内核处理和CPU协调。大型训练在多台服务器间频繁交换数据，如果每次都由CPU搬运并多次中转，资源与时延代价会累积。RDMA让兼容设备用更直接的方式交换已准备好的内存数据，但它只优化路径的一部分。

客户说“已经装了高速网卡，为什么训练没变快”，要检查真实任务有没有走到预期路径，而不是只看设备说明书。应用、通信库、驱动、网络和拓扑都必须配合。

大白话：直达货梯，不是瞬间移动

普通路径像货物先经过前台登记，再搬到中转仓，最后到工位。RDMA像在经过授权和准备后使用直达货梯，减少一些中转。货梯仍有容量、调度和安全要求，目标工位也可能来不及收货。

GPU直接远程内存访问（GPUDirect RDMA）在兼容条件下让网卡等设备与GPU显存直接交换数据，减少绕经主机内存。不要理解成CPU完全不参与，也不要以为所有GPU与网卡组合都能直接传。

技术原理：数据路径与控制路径

RDMA需要准备可访问的内存区域、队列和访问权限。应用或通信库安排工作，设备负责具体传输；地址、访问范围和连接配置仍然受控。传输的直接性不代表谁都能读远端内存，错误配置或过大授权也会带来风险。

GPUDirect RDMA对GPU、网卡、驱动与PCIe路径有支持条件。同一PCIe交换域、经过CPU I/O路径、跨CPU互联，代价和可用性可能不同。想象两台设备都在同一栋楼里，但真正通道要绕到另一栋再回来；物理距离近不代表数据路径短。

实际排查先确认网卡工作在预期协议和速率，再看GPU—NIC对应关系、NUMA与PCIe链路，随后检查通信库是否选择了正确网络。固定环境变量“强制某卡”可能掩盖拓扑问题，不能不看版本和系统就抄优化命令。

RoCE的PFC与ECN：堵车时怎么处理

按优先级流量控制（Priority Flow Control，PFC）让相邻设备暂停某个优先级的发送，像路口暂时拦车。显式拥塞通知（Explicit Congestion Notification，ECN）通过标记拥塞，让端到端发送方减速，像通知源头少发车。前者是逐跳背压，后者帮助控制源头速率，两者作用不同。

PFC配置不当会把暂停向其他链路传播，使无关流量也等待；持续暂停还可能造成停滞。ECN、端点拥塞控制、队列和缓冲配置需要配合。不能说启用PFC后绝无丢包，也不能把所有RoCE实现都写成必须永远零丢包。官方软件存在不同工作模式，具体以端点、交换平台和配置为准。

流量优先级的设计要与主机侧一致。把所有业务塞进同一“高优先级”并不会自动解决拥塞，反而可能失去隔离。上线需要观察端口队列、丢包、暂停和拥塞通知等指标，而不仅是看链路亮灯。

真实场景：带宽测试好，训练仍慢

点到点大包测试主要验证某条路径的持续搬运能力；训练可能使用频繁小消息、多节点同步和不同算法，通信形态不同。一个慢节点会让其他节点在同步点等待；存储或CPU预处理也可能让某个进程迟到，看起来像网络慢。

应先测节点内和节点间基础通信，再用集合通信测试不同消息大小与节点数，最后跑实际训练。保留版本、拓扑、错误计数和配置。基础测试通过只是一层证据，不能直接推出应用扩卡效率。

售前验收怎样落地

设备验收检查协议、速率、线缆误码和固件；网络验收检查路径、拥塞与故障后能力；通信验收检查不同消息尺寸及集合操作；业务验收检查实际任务的吞吐、每步时间和扩展效率。每一层写清条件与失败处理。

方案比较RoCE和InfiniBand时，要同时考虑现网技能、运维、兼容矩阵与应用，不用“哪个绝对更好”概括所有规模。

面试怎么说

“RDMA减少数据搬运中的CPU和中转开销，GPUDirect RDMA进一步尝试让网卡直接交换GPU显存数据，但要满足拓扑和软件支持。RoCE还需端到端拥塞与队列配置。我的验收从链路、通信到真实任务分层进行，不能只看支持标签或单条带宽测试。”

容易混淆

RDMA不是简单的高网速同义词；GPUDirect RDMA不等于任意设备零拷贝；PFC不是端到端拥塞控制；没有丢包不等于没有等待；单链路满速不等于多节点训练线性加速。

返回目录

深读 05 · 扩卡为什么要通信，训练显存怎么算

返回目录

数据并行、分片、集合通信和扩展效率，一次讲透。

为什么八张卡不一定快八倍

训练需要计算，也需要交换信息。各卡处理不同样本后，要让模型保持一致；一个模型拆到多卡后，又要传递中间结果。通信、同步、数据供给和负载不均都会占时间。增加GPU可能把瓶颈从计算推到网络或存储。

首先区分目标：模型装不下，还是模型装得下但训练太慢？数据并行通常解决处理更多样本，参数和状态分片解决重复存储，模型并行解决单实例切分；不同策略节省与增加的资源不同。

大白话：各做一份题，或一起做一道大题

数据并行（Data Parallelism，DP）像多个学生各做一部分习题，每个人手里有同一本模型，然后汇总学习结果。分布式数据并行（Distributed Data Parallel，DDP）是PyTorch中的常用实现方式，通常各进程持有模型副本并同步梯度。

张量并行分担同一层计算，流水线并行分担不同层。专家并行（Expert Parallelism，EP）在混合专家模型中把不同专家放在不同设备，路由会使词元跨设备流转。不是所有并行都主要传相同类型的数据，也不是所有模型都适合相同切法。

技术原理：训练不是只存权重

训练显存可拆为权重W、梯度G、优化器状态O、激活A和临时缓冲T。梯度描述参数如何改变以降低损失；优化器利用梯度及历史状态执行更新；激活是前向计算为后续使用保留的中间结果。具体字节数依赖精度、优化器、主权重副本与实现。

因此“训练永远每参数16字节”不是通用规律。教学时可以先分别列项，再补充激活和工作空间；不能把推理的两字节权重公式拿来规划训练。

完全分片数据并行（Fully Sharded Data Parallel，FSDP）在相应策略下分散保存参数、梯度与优化器状态，需要计算时临时收齐所需参数，梯度同步后重新分片。它减少重复状态，但峰值仍包含当前计算的完整参数、激活、预取和通信缓冲，并非总显存除以卡数。DDP本身也不会自动给你完成全部数据划分和采样安排。

All-Reduce与一个简单搬运算例

集合通信（Collective Communication）是多个参与进程共同完成的通信操作。全部归约（All-Reduce）把各参与者的数组按指定操作合并，并让每个参与者得到相同结果。秩（Rank）是参与进程在通信组中的编号，不必永远等同于整台服务器。

理想环形All-Reduce可分为归约散射（Reduce-Scatter，合并后各持一片）和全部聚集（All-Gather，把各片收齐）。在均匀理想模型中，P个rank、每个参与的完整数组S，每rank发送量约2×(P－1)÷P×S，接收量也相同。

教学假设P＝8、S＝1GB，则每rank发送约1.75GB，接收也约1.75GB。若还要算收发总和，必须另说明口径。不能把1.75GB当整网总流量，也不能直接用网卡峰值相除承诺完成时间；真实算法、消息大小、拓扑、拥塞与计算重叠都会改变结果。

梯度累积与激活重计算

梯度累积（Gradient Accumulation）把多个较小微批的梯度累积后再更新，帮助在有限显存中形成较大的有效批，但可能改变同步与优化节奏，需要结合训练配置。激活重计算（Activation Checkpointing）少保存部分中间结果，反向时重新算，用额外计算换显存。

这两个方法都不意味着“免费省资源”。若大幅重计算，单步更慢；若批量或更新策略变化，训练收敛与任务质量也要观察。卸载到CPU或存储同样会增加数据传输，不是把显存无代价扩成硬盘。

扩展效率怎样看

强扩展通常讨论同一总任务增加资源后完成得多快；弱扩展关注每资源任务量保持相近、总工作随资源增长时的表现。测试前明确全局批大小、训练步数、质量目标和总样本量，避免改变任务后仍声称同比加速。

教学例子：单资源吞吐100单位，八资源合计600单位，按同口径吞吐估计并行效率为600÷(8×100)＝75%。这只说明该设置下的扩展表现，不是模型质量或硬件效率的全部。要拆每步中计算、通信、数据等待和慢rank耗时，才能决定优化方向。

售前与面试回答

“训练要算权重、梯度、优化器、激活与临时空间。DDP主要复制模型分担样本，FSDP减少重复状态但增加收齐和分片通信；TP、PP和EP又有不同路径。扩卡方案要看互联、数据供给和同步，最后比较同任务的吞吐、质量与扩展效率。”

容易混淆

普通DDP不自动把完整权重切小；FSDP不是全部内存都按卡数均分；通信测试中的algbw和busbw口径不同；八卡可能仍是一个故障域；训练快不等于达到同样质量所需总成本更低。

返回目录

深读 06 · 为什么 GPU 在等数据，存储怎样规划

返回目录

从吞吐、IOPS、元数据到检查点，沿数据链路排查。

为什么有时该升级的不是GPU

监控显示GPU经常空闲，可能并非模型不够大，而是数据还在读盘、解压、解析或传输。训练需要持续供给样本，推理需要加载权重、获取检索证据和写日志。存储只看容量，容易在启动和峰值时暴露性能瓶颈。

先区分数据路径：模型制品、训练数据集、检查点、知识原文、向量索引和业务日志，读写模式与可靠性要求都不同。不能把它们统一描述为“挂一个大共享盘”。

大白话：仓库大，不代表出货快

容量回答仓库能装多少；吞吐回答每秒能运出多少数据；每秒输入输出操作数（Input/Output Operations Per Second，IOPS）回答每秒能处理多少次操作；元数据性能关注目录、文件名、权限和属性等管理。搬一整车与逐个处理百万小零件，对仓库要求不同。

顺序读很快的设备，未必擅长大量小文件随机读取。多个节点同时访问同一目录或同一热点文件，还可能让看似足够的聚合带宽失去意义。

技术原理：先算需求，再查全路径

教学假设每节点持续需要3GB/s数据、8节点并行，总读取需求约24GB/s。这是应用端需求，不是随便选一块“标称24GB/s”的存储就满足。路径还经过存储节点、交换链路、客户端、文件系统、CPU解析和主机到GPU传输，任一段不足都会限制整体。

如果每条样本平均2MB且每秒读取1500条，理想数据量约3GB/s；若平均2KB却仍需每秒1500条，总字节少了，但访问开销和元数据可能变得更突出。IOPS与吞吐需结合实际块大小、顺序性和并发理解，不能拿两个最大标称值同时当常态能力。

数据加载器（Data Loader）可能做随机采样、解压、增强和预取。CPU不足或工作线程配置不合适，会让磁盘与GPU都没跑满。缓存能减少重复读取，但要测首次读取、缓存命中和数据更新后的情况。

模型加载与检查点写入

教学假设8节点各需读取140GB模型制品，同时冷启动总读取量约1120GB。若共享路径有效总吞吐仅10GB/s，只按数据量除带宽就至少约112秒，还没算排队、解析和加载。这个理想下界解释为什么扩容不是瞬间完成。

检查点（Checkpoint）保存可恢复的训练状态，可能包括参数、优化器、随机状态和进度，大小不只等于推理权重。8节点各写100GB、希望60秒内完成，单按数据量看就需要约13.3GB/s聚合写入能力，还要加一致性与恢复验证。

把写入做成异步可以减少阻塞，但数据真正落盘前仍存在风险。恢复点目标、写入一致性与训练暂停时间需要明确，不能把“写请求已接受”当可恢复检查点已经完成。

对象存储、文件存储和本地缓存

对象存储（Object Storage）按对象与键访问，适合模型制品、备份和数据集分发；文件存储（File Storage）提供目录和文件访问语义，适合某些共享工作流；本地NVMe能做高速缓存与临时空间。哪种适合，取决于应用接口、数据一致性、共享和恢复要求。

分布式文件系统或并行文件系统可以把数据分布到多个服务端，但扩展性仍需按实际客户端和访问模式验证。不要把“分布式”当性能无限增长。关键产物要有可靠保存和恢复，缓存可重建数据才适合用“丢了再下”处理。

GPUDirect Storage与现实边界

GPU直接存储访问（GPUDirect Storage，GDS）在支持条件下优化存储与GPU显存之间的数据路径，尽量减少主机内存中转。它不是让所有文件操作自动更快，也不免除解压、格式解析和预处理。

是否走到直接路径与文件系统、I/O模式、对齐、软件栈和拓扑有关。把GDS当候选优化，先确定CPU中转确实是瓶颈，再验证兼容性和实际收益，不在方案阶段凭功能名承诺翻倍。

售前排查与验收

按顺序看数据读取与队列、文件数量和元数据、CPU预处理、主机到显存复制、GPU计算和通信等待。先隔离单组件，再跑完整任务，记录冷缓存、热缓存、并发加载、检查点和故障恢复。

面试可以说：“我不只按TB配容量，会按模型分发、样本读取与检查点分别估吞吐和操作模式，再核对客户端、网络与CPU路径；最终用真实作业验证GPU是否持续得到数据。”

容易混淆

存储大不等于吞吐够；IOPS高不等于大文件带宽高；本地缓存不是唯一可靠副本；异步写入不等于已经可恢复；GDS不代替数据预处理；按标称带宽算出的时间只是理想下界。

返回目录

深读 07 · 模型越大、上下文越长，就一定更好吗

返回目录

从训练目标到GQA、MoE和长上下文，解释能力与代价。

为什么要理解参数表之外的东西

客户会问“换更大的模型能不能解决”“百万上下文是不是不需要RAG”。如果只背参数量和窗口长度，就难以解释质量、速度与成本的变化。模型能力是数据、架构、训练和推理方式共同作用的结果，资源也要按具体机制计算。

售前不需要推导整套算法，但应知道每个优化解决哪种瓶颈，以及它没有解决什么。否则很容易把“支持”说成“保证”，把单项指标误认为整体效果。

大白话：学过更多，不代表这次一定答对

模型像通过练习形成习惯的写作者，参数是表达这些习惯的数字。更多参数可以容纳更复杂的映射，但训练材料质量、练习目标和实际题目是否匹配同样重要。给写作者更大的书桌，也只是能铺更多材料，不代表能准确整合所有页。

模型输出一个词元的概率，也不是完整答案真实可靠的概率。熟悉句式可能很容易续写，陌生事实则需要外部证据。

技术原理：训练目标与对齐

预训练常用预测后续词元的任务，从文本中的规律获得通用能力。指令微调让模型学习按任务要求组织回答。偏好优化（Preference Optimization）利用回答之间的偏好信号，改善有用性、风格或安全行为；基于人类反馈的强化学习（Reinforcement Learning from Human Feedback，RLHF）是一类相关路线，不是所有对齐训练的统一名称。

这些阶段改变模型更倾向怎样回答，但不自动建立实时事实数据库，也不让模型拥有业务系统权限。评价时需同时看任务正确性、证据、拒答和是否过度迎合用户。模型“同意你”可能是风格，而不是问题前提得到验证。

长上下文：容量、计算和准确性分开看

标准完整自注意力会比较许多位置对，注意力关系数量通常随序列长度的平方增长。教学上从4千到8千词元，位置对数量约变为四倍；这不表示端到端时延或显存也一律恰好四倍，因为具体内核、分块、缓存与其他计算会改变结果。

KV Cache在常规结构与固定活跃序列数下通常随已缓存长度线性增长。因此“注意力比较的平方关系”和“缓存长度的线性关系”描述不同东西，不能混用。生成很长答案又涉及越来越长的历史，实际成本需区分预填充与解码。

高效注意力实现可减少中间矩阵的存储与搬运，但不意味着语言模型已经能无代价处理任意长度。模型也可能在长材料中漏用关键条件。窗口标称值只是可接收范围，业务还需测跨页、跨段、冲突信息与证据位置。

GQA与MoE：省的不是同一笔账

多头注意力中，查询头与键值头的组织可以不同。GQA让多个查询头共享较少KV头，因此缓存公式应填真实KV头数。不能从总参数量推出KV结构，也不能默认所有模型层的配置相同。

MoE通过路由选择部分专家处理每个词元，使总参数与每次活跃参数分开。它可能降低某些计算成本，但总权重仍需保存或按设计加载，专家分布与负载不均可能增加通信。宣传里的“活跃若干B”不能单独拿来计算整个模型所需存储。

适合某业务的小型稠密模型，可能比更大MoE更容易部署与维护。判断应基于任务质量、服务负载和系统复杂度，而不是只比较参数表。

推理模型与输出预算

推理模型可能使用更多推理时计算改善复杂任务，接口还可能区分可见输出和内部预算。不同模型与供应商口径不同，应用要核查计费、上下文和最大输出限制，不能把所有接口的Max Tokens视为同一语义。

需要复杂推理时，增加预算可能有帮助，但也会增加时延或成本，且没有单调正确的保证。简单分类、信息抽取与固定格式任务，较小模型加规则可能更合适。先按任务难度分流，再决定是否用最强模型。

售前与面试回答

“我会把模型能力、可接收长度和资源消耗分别验证。长窗口不代替检索与权限治理，GQA主要改变KV结构，MoE要区分总参数和活跃参数。采用更大模型或更多推理预算前，先看代表性任务是否有质量增益，再比较时延和全周期成本。”

容易混淆

概率高不等于事实真；偏好对齐不等于实时知识；高效注意力不等于无限上下文；MoE活跃参数不等于全部权重；窗口能放下不等于模型能准确使用所有信息。

返回目录

深读 08 · 服务为什么慢：从首字到尾字排查

返回目录

排队、Prefill、Decode、传输和冷启动，分别找证据。

为什么不能见慢就加卡

用户说“系统慢”，可能是在登录、上传文件、检索、等待首字或生成长文时变慢。每种情况需要不同修复。增加GPU副本能缓解部分排队，却不一定解决PDF解析、数据库锁等待或客户端流式缓冲。

第一步记录同一请求的阶段时间与关联标识，避免把多个系统的日志拼错。把端到端时延拆成阶段，才知道钱应该花在哪里。

大白话：等位、备菜、烹饪和端上桌

网关排队像等位，预填充像阅读订单与备菜，解码像持续出菜，网络与前端缓冲像把菜送到桌上。如果厨房已经做好却服务员迟迟不端，换炉灶没有帮助。

相同总时延可能有不同体验：立刻出首字但后面停顿，和等很久后一次出现全文，需要看不同指标。测量点必须注明在客户端、网关还是模型服务端。

技术原理：先定位阶段

网关记录接收、鉴权、排队、下游请求、首字节和完成；RAG再记录检索与重排；推理层记录预填充、解码与调度状态。流式返回通常只证明连接在持续传输，不代表模型每个词元都立即显示，代理或浏览器也可能缓冲。

首词元变慢时，检查输入长度、排队、模型加载、检索与工具等待；后续生成变慢时，检查活跃序列、缓存压力、内存带宽、通信与调度干扰；偶发极慢时，检查尾部负载、节点健康和冷缓存。不能只看平均GPU利用率。

模型切换、首次加载与动态适配器也可能增加启动成本。把冷启动与热服务分别统计。客户要求随时切模型时，需要说明模型常驻显存、加载时长与资源预算之间的关系。

吞吐与延迟怎样形成排队

教学假设某实例在目标长度下可稳定完成每秒2次请求，持续到达每秒3次，就会累积排队。服务没有异常崩溃，也可能越来越慢。把到达率设得高于可持续容量，然后只看成功请求，容易得到误导性报表。

利用率接近饱和时，微小波动可能放大等待，不能用平均到达率等于平均服务率作为稳定规划。应根据峰值分布与尾时延留余量。设置排队上限与超时，超载时明确拒绝或降级，避免无限等待拖垮整个系统。

连续批处理能提高某些负载的资源利用，但并发越多不一定越好。要找到满足目标时延与错误率的容量点，而不是只追求最大总Tokens/s。

缓存、量化与卸载的选择

前缀缓存节省相同输入开头的重复预填充；答案缓存直接复用结果，但要考虑权限、时效和相同问题是否应有相同答案。两者安全与正确性边界不同。不能让财务用户的可见答案通过共享缓存返回普通员工。

量化减少部分存储与搬运，需质量和内核验证；CPU或磁盘卸载用更慢的数据路径换容量，可能适合低频任务，不一定适合在线低时延。增加副本更适合独立请求扩吞吐，多卡并行则需评估通信。先找瓶颈，再选手段。

真实场景：长文档拖慢短问答

同一队列混入大量长文档总结，可能影响短请求首字。可评估输入长度限制、分块预填充、长短请求分队列、任务优先级或独立资源池。每种方法都有代价，例如分池会降低共享弹性，严格优先级可能让后台任务饥饿。

要求低延迟的在线聊天与离线报告应有不同服务目标。拒绝超大输入时给用户可理解的处理方式，如缩小资料范围或转为异步任务，不能只暴露内部内存错误。

售前与排障表达

“我先按客户端、网关、检索与推理拆时延，再区分排队、预填充和解码。根据证据决定是调队列、缓存、量化、扩副本还是改善网络存储。性能结论同时报告长度、到达率、缓存、错误率和尾时延，避免只看总吞吐。”

容易混淆

GPU利用率低不代表资源足够；首字慢不一定是解码慢；缓存命中不能代替冷启动测试；量化不是所有场景的性能药方；更多并发可能降低单用户速度；请求超时后后台也应尽量取消无用工作。

返回目录

深读 09 · RAG再深入：问题改写、表格、评估与更新

返回目录

不只“搜一段再回答”，把复杂问题拆成可核查的任务。

为什么完整链路跑通后还会质量不稳

“能查产品手册”不代表能回答跨版本比较，“能读制度”也不代表能精确计算本月各部门报销总额。复杂问题可能缺前提、需要多次检索，或者本质上需要数据库计算。继续堆文档块和更大模型，未必能解决任务类型错误。

先判断要的是解释资料、定位原文、精确查询还是统计计算，再选择检索与工具组合。知识库不是所有企业数据访问的统一答案。

大白话：先把问题问对，再去找证据

用户说“昨天那个新标准能不能用”，资料员需要知道“哪个标准、哪个地区、哪个日期”。问题规范化把简称补全，澄清把必要条件交给用户确认，查询改写把口语变成更适合检索的表达。这些步骤帮助寻找证据，但改写不能擅自增加事实。

原始问题应保留，让系统能对照检查改写是否偏离。例如“不能开机”被改成“开机慢”，检索可能很相关却完全答错。

技术原理：多次检索与结构化约束

查询分解（Query Decomposition）把复合问题拆成子问题，例如分别找两个版本的容量限制，再对比。多跳检索（Multi-hop Retrieval）根据第一步证据补充第二步所需信息。每一步要保存来源与约束，不能把中间推测当作已经证实的事实。

有些方法先生成一个假设答案或假设文档用于扩展检索，这属于查询辅助，不是可靠证据。生成文本可能引入错误方向，所以只可作为检索线索，并由真实来源验证。简单场景优先保持少步骤，复杂流程要看质量收益是否值得增加成本与时延。

日期、租户、产品型号和权限应尽量通过结构化过滤或明确条件控制。让嵌入向量自行表达所有精确约束并不可靠。否定、比较和数字条件需要在候选与答案层进一步核对。

表格与数据库：解释和计算分工

制度表格的某个额度可以保留表头、行列与原页引用后检索；本月三万条交易的汇总则更适合数据库查询。让模型从几个随机召回块里估总额，无法保证覆盖全部记录。

可以用RAG解释字段含义与制度，再用只读结构化工具统计授权范围内的数据，由模型组织结论。查询参数、单位、时间范围和结果数要可复验。用户问“增长百分之多少”，还要明确分母、比较期间和是否包含新增部门。

数值校验可以交给确定性程序，模型负责语言说明。不要为了让系统看起来统一而把所有步骤都改成自由文本生成。

嵌入升级与索引生命周期

替换嵌入模型后，即使向量维度相同，表示空间也可能变化。通常要重新生成文档向量，做质量验证，再切换查询端与索引。不能只更新问题编码器而继续用旧向量。

版本记录包含原文、解析器、分块、嵌入模型、索引、提示和生成模型。增量更新需要可重试、可回滚；删除与权限撤销要贯穿向量、原文、缓存及来源预览。不同版本并行试验时，避免把评估结果对应错配置。

评估怎样从平均分走向改进

建立失败分类：解析丢信息、正确证据未召回、重排错误、条件缺失、生成不忠实、引用不支持、过度拒答、权限与时效问题。每类记录一个可复现样例和责任组件。

对多个证据才能回答的问题，单条命中率不够，要看必要证据是否共同进入上下文。答案正确还应检查引用是否真正支持对应结论，不能只统计引用标记数量。用“给正确证据”的实验隔离生成能力，再修检索，是高效定位方法。

售前与面试回答

“RAG质量提升先看任务：资料解释用检索，精确统计用受控结构化工具。复杂问题可澄清、改写或分解，但每步保留原问题和来源。升级模型与索引按版本验证，评估按失败链路分类，不只追一个平均准确率。”

容易混淆

改写生成的文本不是证据；表格被转成文字不代表适合任意统计；向量维度相同不代表模型兼容；引用多不代表支持充分；上线后资料治理和质量运营不会自动结束。

返回目录

深读 10 · Agent落地：状态、接口、重试和审计

返回目录

从演示里的“会调用”走到生产里的“可恢复”。

为什么一次顺利演示不代表可靠

演示通常假设接口正常、数据完整、任务不被中断。真实环境里浏览器会刷新、接口可能已执行但响应丢失、审批可能几小时后才回来。若系统只依赖一段聊天历史，很难判断任务究竟执行到了哪一步，也容易重复操作。

Agent工程化的重点是显式状态、受控执行和可恢复性。模型负责某些判断，任务系统负责真实状态，二者不能靠自然语言约定混在一起。

大白话：聊天记录不是办事台账

聊天里说“我准备创建工单”，只是计划；说“正在创建”，也可能只是描述。办事台账需要工单编号、执行时间、提交参数和系统回执。状态机（State Machine）把任务分成明确状态，并规定哪些事件允许转换。

例如待执行→运行→等待审批→执行写入→验证→完成；也可能进入可重试失败、永久失败或部分完成。这样刷新页面后可以读台账继续，而不是让模型猜之前发生了什么。

技术原理：把任务和工具调用单独建账

每个任务有任务ID，每次工具调用有调用ID与参数摘要。记录发出时间、执行状态、结果标识和关联的授权。长任务按检查点保存，恢复时先看已发生的副作用，避免重跑所有步骤。

接口契约（API Contract）说明参数、数据单位、分页、错误码、超时和业务含义。HTTP返回成功不一定意味着异步业务已经完成；空数组可能表示没有记录，也可能表示范围或权限不足，需要接口明确。模型不能替一个含糊接口补造语义。

工具返回尽量结构化并限制大小。大量日志先由程序筛选和统计，再给模型摘要与可追溯样本，避免上下文塞满后漏掉关键错误。结构化输出仍要做业务校验，格式合格不代表目标合法。

重试、幂等和部分成功

教学场景：创建工单请求已到服务端，但响应在网络中丢了。盲目重试可能创建第二张工单。若API支持幂等键，同一业务操作重复提交应返回同一结果；否则先按请求标识或业务记录查询状态，再决定下一步。

跨系统操作不一定有统一事务。例如先创建工单，再预留资源，第二步失败后，需要取消预留、关闭工单或进入人工处理。补偿动作（Compensating Action）是在无法整体回滚时抵消部分影响，但补偿也可能失败，必须有记录与负责人。

临时故障可有限退避重试，永久权限错误应停止并说明，数据缺失可请求补充。把所有错误都改成“再试一次”，会扩大负载与副作用。

审批与授权如何绑定

人工审批需要展示具体对象、参数、影响和期限。批准A项目的两台机器，不代表批准任意项目与数量；如果模型之后改了参数，应重新满足相应授权条件。审批结果写入任务状态，并由执行器验证，不能只让模型读一句“批准了”。

默认只开放任务所需工具，尽量把生产写入和研发工具隔离。执行环境限制文件、网络和凭据，工具结果只作为数据。外部内容自称“管理员要求”不能提升权限。

质量与成本怎样观察

监控任务成功率、人工接管率、平均步骤、重复调用、失败类型、时长和费用。成功要看业务后置条件，例如报告是否包含真实数据、资源是否按批准参数变更；不能只看模型是否说“完成”。

评估集加入中断恢复、超时、重复提交、部分返回、权限撤销和恶意工具文本。固定样例能复现失败，在线记录能发现新类型。对相同错误反复循环要主动终止，返回部分成果和可执行的下一步。

售前与面试回答

“企业Agent需要独立的任务状态和工具执行记录。模型提出动作，执行器校验授权与参数，工具回执和业务状态决定是否成功。超时要区分未知与失败，写入用幂等或状态核对，跨系统用补偿与人工出口，所有步骤有预算和审计。”

容易混淆

聊天历史不是可靠事务记录；重试不总是安全；HTTP成功不等于异步任务完成；人工说过同意不代表批准所有后续参数；可恢复不等于可以无限重放。

返回目录

深读 11 · 平台怎样持续可靠：隔离、监控与发布

返回目录

从一个模型进程，到能交给运维团队的平台。

为什么平台不只是多部署几个模型

应用团队希望统一接入，安全团队希望权限清晰，运维团队希望能升级和排错，财务希望知道资源被谁使用。模型平台要把这些需求连接起来。一个能启动模型的控制台，未必具备完整的多租户与服务保障。

租户可以是部门、项目或客户。隔离不仅是登录界面，还包括数据、请求配额、GPU资源、日志、缓存和管理员权限。需要按实际风险确定边界。

大白话：公寓管理不只发房门钥匙

门禁解决谁能进，配额解决每户用多少，监控发现漏水，维修记录帮助恢复，装修审批控制变更。模型平台也需要这些不同机制。一个网关可以统一入口，但不能代替后端所有隔离和资源管理。

可观测性（Observability）常通过指标、日志和链路追踪理解系统内部状态。指标看总体变化，日志看事件细节，追踪把一次请求跨服务的步骤连起来。

技术原理：治理与数据边界

网关做身份、配额、路由、限流和必要审计。后端模型服务仍需保护内部接口，防止绕过网关；检索与工具服务也独立检查授权。数据副本包括原文件、解析文本、向量、缓存、备份和日志，删除或撤权应按策略传递到各层。

向量不是天然匿名化后的安全数据，嵌入与索引仍可能携带敏感语义与关联信息。因此访问和备份也要按数据等级管理，不能因为“只有数字”就公开下载。

速率限制、总预算与资源配额作用不同：每秒请求数保护瞬时流量，词元或费用预算控制累计消耗，活跃序列和显存控制运行状态。长短请求差异大时，仅限制QPS未必公平。

监控指标怎样分层

用户层看成功率、首词元、总时延和取消；模型层看输入输出长度、队列、活跃序列、缓存与版本；设备层看显存、功率、温度和错误；基础设施层看CPU、内存、网络、存储与节点健康。把这些通过请求和实例标识关联。

告警要指向可执行动作。仅提示“GPU利用率高”不说明应扩容还是正常工作；队列增长、尾时延恶化与容量余量一起看更有用。监控自身也需可靠，避免服务出问题时恰好没有数据。

发布与回滚为什么要成套版本

模型、分词器、聊天模板、量化格式、推理引擎和驱动组合共同决定行为。RAG还包括嵌入模型、分块和索引。发布清单应记录这些版本及校验值，才能复现质量和性能。

灰度发布（Canary Release）先让有限流量使用新版本，比较质量、错误和时延，再扩大。就绪检查应验证模型已加载且能处理真实样例，不只看进程存在。旧副本先停止接新请求，再处理已有流式请求；回滚也要恢复兼容配置，而非只替换文件名。

高可用与灾备怎样问

高可用通常关注常见设备或实例故障下的连续服务，灾难恢复（Disaster Recovery，DR）关注更大故障域的恢复。两者需要明确RTO、RPO和故障范围。模型权重可重新下载，不代表会话、任务状态、索引与审计也可随意丢失。

按依赖画故障图：网关、身份、配置、模型存储、数据库、GPU实例和监控。两个模型副本如果共用一个无冗余存储或电源，仍可能同时受影响。故障演练记录服务接管、在途请求、数据恢复和告警，而不是只拔一根线看页面还能否打开。

售前与交付表达

“我会把平台按入口治理、数据权限、推理资源与运维发布分层。监控围绕用户体验并关联设备指标；版本成套管理，灰度、回滚与故障演练可复现。交付给客户的不只是界面，还有配置基线、权限矩阵、监控与恢复手册。”

容易混淆

网关不是全部安全边界；多租户不是简单加部门标签；向量不是自动脱敏；进程活着不是模型就绪；双副本不一定跨故障域；备份存在不代表恢复流程已验证。

返回目录

深读 12 · 客户追问时，怎样从需求走到完整清单

返回目录

把未知条件变成调研问题、计算依据、验收与责任。

为什么售前不应只背一个标准配置

客户问题常从“要一个大模型”逐步变成“几张卡、几台交换机、多少存储、怎么容灾、花多少钱”。每个数字都依赖前面的业务假设。专业回答不是立刻给最精确的数字，而是把缺失条件说明，并给出可复验的推导。

你已有的政企与IaaS售前经验，正适合把多个团队的约束汇总成需求基线。新增任务是把模型质量、Token负载、GPU状态和高速数据路径加入调研。

大白话：先确定要开哪种餐厅，再列采购单

物料清单（Bill of Materials，BOM）回答要买哪些部件、数量和规格；工作说明书（Statement of Work，SOW）回答要做什么、谁负责和怎样验收；方案架构解释它们如何共同满足目标。三者有关联，但一份设备表不能代替交付范围。

预算报价可以有假设区间，正式承诺则需要更充分的数据、兼容核验和实测。对暂时未知的条件建立验证事项，而不是藏在一个看似确定的总价中。

第一轮调研：任务与质量

问业务：主要任务是什么，成功答案长什么样，哪些错误不可接受；数据来自哪里，谁能看，多久更新；有无必须引用或人工确认的结论。区分知识解释、精确统计、代码操作和自动写入。

问使用：潜在人数、活跃人数、忙时请求、输入输出长度、峰值和增长；是否有长文档、多模态、离线批任务；用户想要首字快还是全文快。缺历史数据时，先采样或试点，明示临时假设。

第二轮调研：资源与数据路径

模型方面确认许可证、版本、精度与部署框架；服务器方面确认GPU、CPU内存、PCIe拓扑、网卡和磁盘；网络方面区分业务、存储、计算与管理，按端口与拓扑计数；存储方面分模型分发、数据读取、检查点和业务数据。

机房确认机柜功率、供电冗余、散热、空间、布线与维护条件；软件确认操作系统、驱动、容器、编排、身份、日志与版本支持。数据不出某边界时，要逐环节核查解析、嵌入、重排、生成和工具接口，不能只看最后一个模型。

清单怎样从计算结果生成

先形成逻辑架构和负载表，再做容量候选。服务器数量关联模型切分、吞吐和故障余量；网卡与交换机关联计算端口和拓扑；存储关联容量、读写与恢复；配线关联物理端口、距离和模块兼容。

BOM应列明设备形态、订货型号、数量、接口、配套线缆、维保与备件。对GPU服务器不要漏电源和导轨等整机条件，对网络不要漏上联与管理，对软件不要漏许可证和持续维护。不要把芯片宣传规格直接当整机可交付配置。

SOW明确数据准备、连接器、权限集成、测试、培训和上线支持。客户负责提供哪类数据与接口，供应方负责哪些改造，外部团队交付日期如何影响项目，都要写清。

PoC到验收：用阶段门槛降低不确定性

PoC先验证质量与关键技术路径，试点验证真实流程和权限，生产验收验证峰值、恢复与运维。每阶段有样本、配置、阈值、风险与退出条件。约定不能通过时是优化、缩范围还是终止，避免演示成功后无限追加期望。

验收报告区分事实、假设和未完成项。事实给来源或测试记录；假设给适用条件；未完成项给责任和验证方法。没有正式报价就不给GPU市场价格，没有压测就不给并发保证，没有亲自做过就不写成个人交付。

面试时的完整答法

“我会先明确业务任务、质量和数据边界，再收集请求与Token负载。技术上算权重、缓存、并行、网络与存储，结合机房和兼容条件形成候选BOM。PoC验证关键假设，生产按性能、权限和恢复验收；SOW写清范围、责任与持续费用。遇到缺数据，我会给验证路径和区间，不伪造精确结果。”

继续拓宽知识的学习方法

每遇到一个名词，追问五件事：它解决哪种等待或风险；输入输出是什么；需要什么前提；代价和失败方式是什么；怎样证明它有效。再沿“数据从哪来—经过什么—怎样计算—如何交付”画路径。

这套方法可用于GPU、RAG、Agent，也可用于新出现的框架与硬件。面试时不必记住所有产品参数，但要能说明核查哪里、怎么实验，以及哪些承诺现在还不能成立。

返回目录

面试问答

返回目录

1. 大模型与传统机器学习有什么区别？

判断能否按业务任务选技术，而不是追热点。

分类器像分拣员，生成模型像写作者，业务系统可同时需要两者。

大模型通常通过广泛数据训练，具备跨任务语言生成能力；传统机器学习常针对较明确的预测或分类目标。选型要看数据、任务、错误代价和成本，而不是参数大小。

我会先问输入和输出是什么。销量预测主要面对结构化历史数据，制度问答需要理解问题并组织有来源的文字，这两种任务不能用同一评估标准。大模型的通用性来自规模、数据与训练方式，但语言流畅不代表事实正确。实际系统可以用规则做确定性判断，用传统模型做预测，用大模型做人机交互。PoC 分别验证任务质量、时延和成本，再决定架构。不能把已有可靠预测模型全部替换成聊天模型，也不能因为用了大模型就省掉数据治理。

追问 生成式 AI 和多模态是什么关系？

不要说传统模型不能使用深度学习。 对应章节

2. Token、Token ID 与 Embedding 有什么关系？

看是否真正理解数字化输入过程。

词元是片段，编号是字典索引，向量是可计算的表示。

分词器把文本切成 Token 并映射到词表编号，嵌入层把编号变成向量。编号没有连续语义，向量经训练承载关系；后续网络再结合上下文更新表示。

我会用一句话举例：先按照特定分词规则切成若干片段，可能包括汉字、子词和标点。每个片段有一个编号，但编号大小不表示意思接近。嵌入层查出一组数，后面加上位置信息并通过 Transformer。训练会调整这些数字，让它们有利于预测任务。最终输出层给词表候选打分，再选择下一个 Token。因此一个字不一定等于一个 Token，计费和上下文预算应使用目标模型的分词器。检索嵌入模型则通常输出用于相似度比较的文本表示，和聊天模型的生成接口不同。

追问 为什么换分词器会影响长度？

不要说一个 Token 永远等于一个汉字。 对应章节

3. Attention 的 Q、K、V 是什么？

考察机制理解及解释能力。

查询问要找什么，键负责匹配，值负责提供汇总内容。

Q、K、V 是输入表示经过不同可学习变换得到的矩阵。用 Q 与 K 的匹配程度形成权重，再对 V 加权汇总，使当前位置利用上下文信息。

自注意力中，查询和被查询信息来自同一序列。模型通过学习形成 Q、K、V，并非人工给每个词设置三张标签。注意力分数经过缩放和归一化后形成权重，再汇总值向量；多头让不同表示子空间同时参与。典型生成模型使用因果掩码，避免当前位置看未来词。位置编码补充顺序关系，前馈网络继续变换特征。面试里可以用“它在句子中指谁”帮助理解，但要补充这只是直观类比，不代表每个注意力头具有固定的语法功能，也不能把注意力图当成可靠的因果解释。

追问 为什么需要位置编码和因果掩码？

不要把 Q、K、V 说成外部数据库的三个字段。 对应章节

4. 大模型为什么会幻觉？

判断是否能设定合理的能力边界。

会写通顺答案，不等于已经核对事实。

模型按上下文和学到的规律生成文字，生成目标不等于事实校验。缺知识、错误证据、歧义和生成策略都可能引发幻觉。可通过可靠检索、引用校验、结构化工具与拒答降低风险。

先区分缺少知识和没有正确使用知识。私有制度未提供给模型时，它可能按类似材料补全；资料已提供但版本冲突或条件复杂时，也可能错误整合。RAG 能补证据，却可能召回过期或无权限资料。低温度减少随机性，但也可能稳定地产生同一个错误。我的方案会在输入侧治理资料，在检索侧保证有效性和权限，在生成侧要求证据绑定，并对高风险结论增加规则或人工确认。评估中加入无答案、矛盾材料和诱导前提，统计错误与合理拒答，而不是承诺绝无幻觉。

追问 有引用为什么还会错？

不要说温度设为零就完全正确。 对应章节

5. 70B BF16 为什么约需 140GB 权重显存？

考察单位、公式和容量边界。

七百亿个数字，每个占两字节。

70B 是约七百亿参数，BF16 每参数两字节，理论权重约一千四百亿字节，即140GB或约130.4GiB。还要另外计算 KV Cache、运行时缓冲和余量。

公式是参数数量乘每参数字节数，先统一十进制 GB 与二进制 GiB。这个数仅是理论权重，不包括请求状态，也不保证模型文件全部采用同一精度。实际加载还受分片、元数据、框架工作空间和通信影响。KV Cache 根据模型层数、KV 头数、头维度、缓存精度、上下文和活跃序列计算，不能由70B单独推出。若量化到四位，理论权重约35GB，但元数据和高精度层另计，缓存也未必四位。最后要看单卡分配与多卡拓扑，在目标负载下验证显存峰值。

追问 为什么 GB 和 GiB 不一样？

不要把140GB当总服务显存。 对应章节

6. KV Cache 为什么随并发增长？

考察是否理解请求状态。

每位正在读书的人都有自己的上下文笔记。

KV Cache 保存历史位置的键和值，减少逐 Token 生成时的重复计算。不同活跃序列通常需要各自状态，因此长度和活跃序列增加都会增加占用；前缀共享等优化会影响实际值。

常规完整注意力的简化公式为两倍层数乘 KV 头数、头维、序列长度、活跃序列和每元素字节数。前面的二对应键和值。GQA 的 KV 头数可能小于查询头数，所以不能直接使用查询头数。长度要包含输入和已生成部分，规划上需考虑长尾与输出增长。分页管理减少碎片，前缀缓存可能共享部分状态，但不消除后续独立内容。滑动窗口或其他架构要用相应模型公式。并发规划还应区分排队请求和正在占用 GPU 缓存的活跃序列，最终观察框架实测分配。

追问 权重量化后 KV 会自动量化吗？

不要只按参数量计算 KV。 对应章节

7. RAG 与微调怎么选？

看能否区分知识与行为。

RAG 像查资料，微调像专项练习。

频繁更新、需要来源的知识优先用 RAG；稳定的任务行为和输出规范可评估微调。先建立评估集，优化提示和检索，再判断是否需要 SFT 或 LoRA，两者可以组合。

我会先定位失败原因。企业制度更新且要引用，参数中的知识难逐条撤销，检索更便于治理。若模型在给足正确证据后仍不会按专业格式回答，且有合规、高质量样本，可以微调。LoRA 是参数高效适配方法，SFT 是监督训练方式，两者不冲突。微调要区分训练集和验证集，检查通用能力退化与敏感信息记忆。RAG 也不是零成本，需要解析、权限和评估。选择依据是业务质量增量与全生命周期成本，而不是认为微调更高级。

追问 QLoRA 量化了哪些部分？

不要说微调能可靠记住全部现行制度。 对应章节

8. 量化为什么不一定更快？

考察硬件与算法之间的条件。

文件变小不代表所有加工步骤都变简单。

量化降低数值位宽，可减少权重存储与部分带宽，但需要对应硬件和内核支持，可能增加反量化开销。质量、速度和显存收益都要在目标模型与负载上测。

低位数表示通常需要缩放因子，部分层或计算仍保持较高精度。有的硬件原生支持某些低精度矩阵运算，有的路径需要转换后计算。短请求、批大小、模型结构和带宽瓶颈都会影响结果。权重量化并不必然改变激活与 KV Cache，因此总显存节省不能仅按位宽比推导。验证时先比较任务质量，再在同一输入输出长度、到达率和缓存状态下测吞吐与尾时延，记录量化格式和内核版本。对代码、专业术语和推理任务尤其要做回归，不能只测通用聊天。

追问 INT4 与 FP8 怎样取舍？

不要承诺低位量化无损且必然加速。 对应章节

9. 请完整介绍 RAG 架构。

检验是否能独立讲解方案链路。

先整理证据，再按权限找到证据，最后解释证据。

分入库和查询两条链。入库包括采集、解析、清洗、分块、嵌入和索引；查询包括身份权限、检索、融合、重排、上下文构造、模型生成与来源校验，外围有更新、监控和评估。

我会从客户五千份文件的需求出发。先记录格式、版本与权限，解析扫描件和表格，按语义结构分块，同时保存页码、有效期和来源。生成向量并建立关键词索引。员工提问时验证身份，在授权范围内混合召回，经重排序和去重构造有限证据。模型按证据回答，引用由真实片段标识生成，材料不足时澄清或拒答。上线还需增量更新、删除同步、缓存隔离和质量评估。PoC 分开测解析、召回、答案与权限，避免把聊天演示当成完整交付。

追问 哪些环节最容易影响质量？

不要把向量数据库等同完整 RAG。 对应章节

10. 为什么要分块，块长如何选？

看是否理解结构与预算的权衡。

卡片太短没条件，太长混主题。

分块让检索定位和上下文预算可控。小块更聚焦但易丢条件，大块完整但噪声更多。我会保留标题、条款和表格边界，用代表性问题比较，不设万能块长。

先看文档结构和查询类型。制度条款要保留适用范围与例外，代码应尽量保留函数结构，表格应保留表头、单位和行列关系。重叠可缓解边界问题，但过大增加重复索引与上下文浪费。可用小块检索后扩展父段落，兼顾精度与完整性。实验时固定模型和检索参数，只改变切分策略，比较正确证据进入候选、引用完整度和最终答案。更新时保持稳定文档标识与版本关系，避免每次切分变化制造大量失效引用。分块不是越碎越专业，而是让证据能被找到并准确使用。

追问 什么时候用父子块？

不要把固定字符数当行业标准。 对应章节

11. Embedding、向量库与聊天模型各做什么？

判断组件职责是否清晰。

编码员生成坐标，资料库存和找，讲解员生成答案。

嵌入模型生成可比较向量，向量库管理索引和元数据，聊天模型根据证据生成文字。文档和问题向量要兼容；相似度只代表相关，不代表正确或授权。

嵌入模型通过训练把相关文本放到相近表示空间，通常为检索输出固定维度向量。向量库保存向量、块标识、权限和版本信息，按距离与过滤条件返回候选。原文可以放在同一系统，也可通过标识回查外部存储。聊天模型收到问题与证据后生成回答。FAISS 是库，Milvus 是数据库，pgvector 是关系数据库扩展，选型涉及数据规模和团队运维。升级嵌入模型时，维度相同也不保证表示空间兼容，通常需要重新嵌入并验证索引切换。

追问 向量相似度0.8是什么意思？

不要解释成答案有80%概率正确。 对应章节

12. 为什么要混合检索和 Rerank？

考察精确标识与语义匹配的互补。

两条路找候选，再做细审。

向量擅长语义表达，关键词擅长型号与错误码；混合提高覆盖。重排序对有限候选做更细判断，但增加成本且不能找回初筛完全漏掉的证据。

先建立关键词和向量基线，分析失败类型。若型号或错误码容易混淆，关键词提供精确约束；同义表达较多时，语义检索补覆盖。合并时分数尺度不同，需验证归一化或排名融合，不能直接无脑相加。候选再由重排模型联合比较问题和片段，选出更相关证据。最后仍需有效期、权限和上下文完整性检查。评估要分别看初筛召回、重排排名和答案质量，同时测额外时延。复杂组件只有在真实测试里带来收益才值得增加。

追问 Rerank 与 Embedding 的架构区别？

不要说重排自动解决所有漏召回。 对应章节

13. 知识库如何避免越权？

考察企业治理与安全边界。

先检查门禁，再给资料，而不是看完后提醒保密。

身份在可信系统确认，检索按租户与文档权限过滤，返回前复核；重排和模型只接收授权内容。引用下载、缓存和撤权同步也要执行相同规则。

入库时把来源权限映射为文档或块级元数据，并明确更新时效。查询端不能信任客户端自报部门，必须从身份系统获取授权范围。检索时尽可能先限制候选，返回时再校验，避免检索组件行为差异造成泄露。来源预览和下载独立检查，缓存键包含必要的可见性维度，撤权和删除时失效缓存。验收用跨部门、离职、历史链接和共享缓存反例测试。系统提示可以提醒回答规范，但无法替代数据层权限。私有化也仍需内部隔离和审计。

追问 块级与文件级权限怎么选择？

不要让未授权材料先进入模型再要求不泄露。 对应章节

14. 引用了三年前制度，如何排查？

观察是否按链路定位而非盲目换模型。

先查书是否更新，再查选书，最后查读书和旧答案缓存。

先保留问题、身份、答案和引用，检查新制度是否成功入库，旧版有效期与版本过滤，再看召回重排、上下文和答案缓存；修复后用原题及权限反例回归。

我会先复现并定位引用的具体块。若新文档根本不存在，查采集、OCR、分块和索引失败；若新旧都存在但旧版进入上下文，查生效日期、版本字段与过滤条件，不能把上传时间当生效时间。若上下文正确但答案仍旧，查提示、引用映射与模型输出。若更新后才有些用户异常，重点查缓存键和失效机制。修复要保留历史查询能力，不能一律删除全部旧制度；用户询问历史政策时应按日期查。最后验证监控能发现下一次更新失败，而不只修这个问题。

追问 如何处理明确查询历史政策？

不要只在提示里加“用最新资料”就算修复。 对应章节

15. RAG PoC 怎样验收？

看能否把模糊效果变成可测标准。

资料找得对和答案写得对要分开评分。

建立业务认可的代表性问题与保留集，分别验解析、Recall@K、答案正确与忠实、引用、拒答、权限及性能。阈值事先约定，记录模型、索引与配置版本。

测试集要包含常见、长尾、无答案、冲突版本、复杂表格和权限反例，并由业务专家标注证据与关键要点。检索失败与生成失败分开：给正确证据仍答错时修生成，证据没找到时修数据与检索。模型评审可辅助，但高风险结论要人工校准。性能固定长度分布、到达率和缓存状态，统计尾时延与失败。验收题不能持续用于调参，否则容易过拟合演示。最终同时报告技术指标和业务使用效果，明确严重错误定义及重测方式，把资料准备与持续更新纳入交付范围。

追问 引用率与引用正确率有何不同？

不要以十个演示问题全部通过作为生产验收。 对应章节

16. Function Calling 的真正执行者是谁？

看是否清楚模型和应用职责。

模型填写申请，应用审核后办理。

模型输出工具名和结构化参数，应用解析、校验权限和业务规则后执行 API，再把结果回传。模型输出调用对象不等于操作已成功。

工具定义告诉模型用途、参数类型和约束。执行器除 JSON 格式校验，还要检查当前用户能否访问目标、时间范围是否合法、行数和费用是否超限。数据库优先封装只读业务接口，写入工具单独授权并使用幂等键。工具超时或返回部分数据时，应明确状态，让模型基于真实结果回答。成功与否还要看业务后置条件，例如工单是否实际创建。日志记录关联标识、参数摘要与执行结果，同时保护敏感信息。这个架构既支持工具调用，也让权限不依赖模型是否听话。

追问 参数结构正确还可能有什么问题？

不要说模型自己直接拥有数据库管理员权限。 对应章节

17. Workflow、Agent 与 Multi-Agent 怎么选？

看能否控制不必要复杂度。

固定路线用流程，不确定路线才需要受限探索。

流程明确、风险高的任务优先工作流；需要根据观察动态选工具时考虑 Agent；多 Agent 只有在明确分工能提升质量或效率时采用，并比较协调成本。

我会先画出任务步骤和分支。如果条件可枚举，例如报销审批，确定性流程更容易验证。临时故障分析需要随结果追加查询，可以把探索部分放进受限 Agent，外围仍由工作流控制权限和预算。多 Agent 适合独立资料研究或分工检查，但共享错误、互相转派和重复调用会增加风险。必须定义输入输出、共享状态、冲突处理和终止条件。PoC 与简单基线比较任务成功率、人工接管、成本和时延，不能用 Agent 数量证明先进。并行执行独立查询也不必引入多个自主角色。

追问 工作流能包含大模型吗？

不要说用了多个模型就一定更可靠。 对应章节

18. MCP 是什么，解决了什么？

区分协议、规划与授权。

统一工具插座，而不是替助理做决定。

MCP 是 Model Context Protocol，连接 AI 应用与工具、资源等外部能力。Host 内的 Client 连接 Server，协议规范发现和调用，但不决定任务规划，也不替代业务授权。

可以用企业监控接入解释：监控服务通过 MCP 暴露工具说明，AI 应用发现可用能力，再在用户授权范围内调用。工具发现与调用使用标准消息，减少每个应用重复写连接方式。具体传输、版本和能力声明要按所用规范实现，不能把一个版本的握手当成永久规则。MCP 不会让模型自动理解业务，也不会消除提示注入。服务端仍校验身份、令牌受众和具体资源授权，工具结果仍当作数据。接入本地服务还要检查启动程序来源和系统权限。

追问 MCP 和 Function Calling 怎么配合？

不要把 MCP 说成模型或自动权限管理系统。 对应章节

19. Agent 如何防止无限循环与失控成本？

考察工程可靠性。

给任务预算、停止线和失败出口。

设置最大步骤、工具次数、时长和词元预算，识别重复失败，有限重试并退避。任务状态可恢复，写入防重复；超限后返回部分结果或转人工。

每个任务记录目标、已完成步骤、执行标识与剩余预算。工具调用有单步超时，整体任务另有期限，避免一个工具拖住全部流程。重试区分暂时网络错误和永久权限错误，后者不应反复尝试。非幂等写入先确认上次状态，避免重复工单或变更。循环检测可以观察重复工具参数、相同错误和没有新增证据的计划。成本需要包括模型、工具和外部服务。结束时报告真实完成状态，不把生成了一份计划当作执行完毕。验收用超时、空数据、错误参数和重复提交测试。

追问 HTTP成功后为什么仍需业务检查？

不要无限重试所有错误。 对应章节

20. Prompt Injection 如何防范？

看是否把外部数据与指令分开。

文档里的命令不是当前用户的授权。

外部文档和工具结果按不可信数据处理；工具采用最小权限、参数验证、目标白名单和独立审批。提示防护只是辅助手段，权限必须在执行层强制落实。

攻击不一定来自当前用户，也可能在网页、代码注释、工单名或监控标签中。模型读取后可能错误把内容当命令。设计时限制可调用工具和外发目标，不让模型接触不必要的密钥；读写分离，敏感操作先给出具体对象和参数，经批准后执行。审批绑定操作内容，参数变化不能沿用旧审批。对返回数据标记来源并保持任务边界，日志记录可审计行动而非依赖模型自我声明。验收注入伪造系统指令、诱导外发和越权查询，验证即便模型提错操作，执行器也会拦住。

追问 私网文档是否也需要防注入？

不要说只加一条系统提示就彻底解决。 对应章节

21. CPU、GPU、显存和带宽如何解释？

看是否理解资源瓶颈。

算术工位、仓库大小和搬运速度是不同指标。

CPU偏复杂控制，GPU适合大量并行计算；显存容量决定能放多少状态，带宽决定搬运速度。模型性能由计算、内存、互联和软件共同决定，不能只看TFLOPS。

神经网络大量使用矩阵乘加，GPU的并行资源与专用矩阵单元适合这类工作。CPU仍承担分词、数据准备和服务控制。预填充与解码的计算强度不同，某些解码负载受权重和缓存读取带宽约束。显存再大也不保证生成速度快，算力峰值再高也可能装不下模型。多卡时还需看PCIe、NVLink或其他互联。实际定位用设备、CPU、网络、存储和请求指标一起看。比较峰值需同精度、稠密稀疏和设备数量，随后用业务负载测可持续性能。

追问 GPU利用率低可能是什么原因？

不要把显存容量当显存带宽。 对应章节

22. 如何比较 H100、H200、B200 和 GB200？

考察规格严谨性与选型方法。

先确认比的是单个部件还是整套系统。

先核对具体形态及官方规格，再比较显存、带宽、互联和软件支持。GB200模块含两颗GPU，NVL72是机架，不能把系统总量当单卡。最终比较相同业务目标下的实测与成本。

我会明确H100是SXM还是其他版本，H200也注明形态。当前官方HGX参考架构中的B200单GPU容量与早期宣传口径可能不同，因此引用来源和核查日期。GB200超级芯片包含Grace CPU和两颗Blackwell GPU，NVL72进一步是整机架级方案。除容量外还看网络、供电、液冷与整机支持。性能表要区分稀疏和稠密精度口径，不用机架PFLOPS与单卡比较。候选型号能否达到客户SLO，需要同模型、量化、长度、负载和缓存条件下测试。价格与供货也须询价，不能凭印象承诺。

追问 为什么大显存可能减少通信开销？

不要写“一张GB200有13.4TB显存”。 对应章节

23. Tensor Parallelism 与 Pipeline Parallelism 有何区别？

看是否理解多卡通信。

张量并行分一道工序，流水线并行分不同工序。

TP把同一层部分计算分到多设备，通信频繁；PP把不同层分到不同设备，需要阶段平衡。完整模型副本是另一种扩吞吐方式，三者不能混为一谈。

模型放不下单卡时，可以切分权重与计算。TP通常需要在层内或层间交换中间结果，因此机内高速互联重要，并行度还受模型维度和框架约束。PP按层划阶段，请求或微批沿阶段运行，要避免某一阶段成为瓶颈和空泡过多。多副本让独立请求分配到不同完整实例，适合模型能装入一个资源单元的情况。实际可以组合，但需核算每卡显存、通信和故障域。一组多卡模型实例不等于多个高可用副本；任一卡失败可能影响整组服务。

追问 为什么跨节点TP需要谨慎？

不要把卡数直接等同服务副本数。 对应章节

24. vLLM 的三个优化分别解决什么？

检验不是只背功能名。

调度、缓存空间、重复前缀是三笔不同的账。

连续批处理动态组织请求；PagedAttention以块管理KV减少分配浪费；前缀缓存复用相同前缀的预填充。效果依负载与版本，前缀缓存不直接减少后续解码。

短请求完成后，连续批处理可以把新请求补入后续计算，减少固定批的等待浪费。分页缓存把逻辑序列映射到物理块，减少连续预分配和碎片，但基础缓存量仍与长度和活跃序列有关。前缀缓存适合固定系统提示或重复长材料，命中与淘汰会影响收益。长输出占主导时，总体收益可能有限。应在冷、热缓存及长短混合负载下测质量、吞吐、TTFT与TPOT。框架能力还与模型、硬件和安装版本相配，历史设计文档用于理解原理，不据此猜当前全部内核实现。

追问 分块预填充有什么用？

不要说分页缓存让显存无限增长。 对应章节

25. TTFT、TPOT、吞吐和P95如何取舍？

判断能否读懂性能报告。

首菜多久、后续多快、全店产量和慢客体验。

TTFT看首Token等待，TPOT看后续节奏，吞吐看整体工作量，P95看尾部体验。高吞吐可能伴随排队，规划应找满足时延与成功率目标的可持续吞吐。

先定义测量起止点和输入输出长度分布。首Token包含排队与预填充等，后续节奏受调度和缓存影响。单请求Tokens/s与整服务总Tokens/s不同，QPS又受每次长度影响。平均值掩盖长尾，所以报告P50、P95、P99和样本量、失败率。压测到达方式也重要：闭环等待响应再发请求可能隐藏超载，开放到达率更容易暴露排队。在线聊天和离线报告可分队列设置不同目标。最终把硬件、模型、量化、缓存和配置写进结果，不能只交最高吞吐数字。

追问 吞吐变高为什么用户反而变慢？

不要将平均时延冒充P95。 对应章节

26. 1000 名员工的 70B 部署如何规划？

考察从业务到容量的推导。

先估真实订单，再估每份订单的重量。

先收集活跃用户、请求频率、峰值与Token长度，再计算输入输出负载；独立估权重、缓存与运行时，比较量化和并行候选，压测后确定资源并留故障余量。

人数只决定潜在使用范围。我要知道一天多少次请求、忙时集中程度、长短请求比例和目标首字与总时延。没有数据时用明确假设给区间，再通过试点校准。70B的BF16权重约140GB，但缓存由模型结构和活跃序列决定。容量允许后还要测目标到达率下的排队、吞吐、尾时延与错误，不能仅除单卡显存得到采购数量。候选可以是BF16多卡、经验证量化、较小模型分流或多副本。高可用另外验证实例故障后的剩余能力，商业比较纳入能耗、运维和冗余。

追问 怎样由到达率近似并发？

不要一千员工配一千并发。 对应章节

27. MIG、vGPU 与直通怎么选择？

考察共享与隔离意识。

独占房间、硬件分间和软件共享各有条件。

直通偏独占，vGPU依赖厂商虚拟化支持与许可，MIG在支持设备上提供硬件实例。时间片共享不是同等隔离。按负载、卡型、性能与安全需求选择。

先确认客户要隔离的是显存、计算、性能还是管理权限。直通通常便于独占设备，但资源共享和迁移受限制。MIG有型号和切分规格约束，并非每张卡都支持，实例能力也要核实。vGPU涉及驱动、虚拟化平台、许可和支持矩阵。时间片共享可以提高某些轻负载利用率，但不能自动提供同等显存与故障隔离。调度还需考虑卡型、拓扑和资源碎片。验收用真实并发任务观察性能干扰、越权和故障影响，不能只看资源分配界面显示成功。

追问 L40S是否支持MIG？

不要认为所有NVIDIA GPU都支持MIG。 对应章节

28. AI 集群为什么需要 RDMA 与高速存储？

看是否能将IaaS经验迁移。

多工位协同需要快通信，开工前还要及时供料。

跨节点训练或模型并行可能频繁同步，RDMA减少CPU介入的数据传输；RoCE与InfiniBand是相关网络路线。存储负责数据、权重和检查点，必须按负载验证端到端吞吐。

我先区分独立推理副本和频繁同步作业。前者未必需要和大规模训练同等昂贵的互联；后者通信延迟和带宽会限制扩展效率。RoCE需要交换网络、拥塞控制和端到端配置，仅有RDMA网卡不够。存储不仅看顺序吞吐，还看小文件、元数据、并发加载和检查点写入。大批节点同时下载权重可能打满共享链路，可采用本地缓存和分阶段发布。故障排查同时观察CPU、网络、GPU与存储等待，避免把所有慢都归因于GPU型号不足。

追问 为什么空闲GPU可能在等存储？

不要把网卡标称速率当端到端有效带宽。 对应章节

29. 自建与租赁怎么比较成本？

看商业测算是否同口径。

用相同服务要求比较完整账单。

比较同周期、同负载、同SLO下的TCO。自建包含折旧、电力制冷、机位、网络、许可、运维和冗余；租赁包含资源时间及附加服务。使用真实报价与利用率，不编造回本期。

我会先定义峰值、平均使用和增长预测，区分稳定在线服务与弹性研发任务。自建固定投入大，利用率与运维能力影响单位成本；租赁灵活，但长期常驻费用、数据迁移和附加资源也要算。两边都计入高可用和故障备用，不能拿单机自建对比双区托管。机房能耗需区分峰值与平均，PUE只能作为设施折算假设。价格、供货、许可和地区条件都须正式核实。最终提供敏感性分析，例如利用率和增长变化会怎样影响结论，而不是给一个看似精确但没有依据的数。

追问 利用率下降如何影响自建成本？

不要遗漏闲置、运维与备用容量。 对应章节

30. 没有五年AI交付经历，如何表达优势？

判断诚信、迁移能力和成长路径。

把真实经验接到新问题，不借用别人的履历。

我会据实讲IaaS和政企售前的需求、架构、成本与交付经验，以及真实AI编程和推广实践。用RAG与算力案例展示方法，明确哪些是实际项目、个人验证和理论设计。

可以先说已有优势：理解企业网络、安全、运维与采购约束，能把模糊需求转为方案和验收。再讲实际接触AI工具和API过程中观察到的任务描述、验证、隐私与培训问题。随后用一个假设案例说明如何做数据与权限访谈、Token负载规划和PoC。对于没有做过的大规模生产部署，明确说明缺口，并给出可执行学习与验证路径。面试官追问数字时，只用有记录的结果，不虚构客户名称、集群规模或提升比例。诚实边界与系统化方法结合，比堆砌最新型号更可信。

追问 你亲自负责过哪些环节？

不要把个人实验说成企业生产交付。 对应章节

31. GPU服务器CPU、内存和磁盘怎么配？

看能否按数据路径选整机，而非只选卡。

工位之外还要有备料、走廊和调度。

先区分训练、推理和研发，再核对CPU预处理、内存峰值、PCIe与NUMA路径、网卡及磁盘。没有适用所有模型的固定内存倍数；整机兼容与真实作业一起验收。

我会先列CPU和主机内存承担的任务：分词、数据加载、预取、模型加载转换和可能的卸载。再看GPU、NIC与NVMe在PCIe树和CPU插槽上的位置，核对共享上行和链路速率。内存按实际消费者与加载峰值估，磁盘区分可靠数据和可重建缓存。训练还看样本和检查点，推理看冷启动与稳定时延。电源冗余要验证失去一个供电单元后是否还能支撑负载，带外管理和机柜散热也要计入。最终要求整机厂提供认证配置与拓扑，并用目标任务测试，不只跑硬件健康检查。

追问 双路CPU为什么还会有远端访问代价？

不要认为显存越大就无需主机内存规划。 对应章节

32. GPU集群一定要InfiniBand吗？

考察负载与网络之间的判断。

独立营业和多人协作需要的通道不同。

不一定。先判断是独立推理副本，还是频繁节点同步的训练或模型并行。再比较带宽、延迟、兼容、现有运维与成本，区分业务、存储、计算和管理网络。

我先画通信关系。独立副本主要接收请求、返回答案与加载模型，不必自动采用和大型训练相同的互联。跨节点同步任务则要测通信占比、消息大小和扩卡效率。InfiniBand与RoCE有不同设备和运维条件，RoCE也不是换网卡就完成，需要端到端队列和拥塞配置。网络可以按职责分层，是否物理隔离由负载、故障与安全决定。方案最终给拓扑、端口、链路和验收，而不是用服务器台数乘固定设备系数。若缺任务数据，先给候选网络与验证步骤，不能保证某速率等于应用吞吐。

追问 400Gb/s折算多少GB/s？

不要把400G说成每秒400GB。 对应章节

33. 8台服务器每台8网口，交换机和线缆怎么算？

看能否写前提并按端口守恒。

服务器下联和骨干上联都要数。

先确定逻辑端口、速率与拓扑。教学例子64服务器端点，32逻辑口交换机16下16上，用4Leaf与明确选择的4Spine，每对4链路，共64接入加64层间链路，即128条。

这个例子必须说明32口是独立可用的同速逻辑端口，不是直接套某型号物理笼位。64端点除每Leaf16下联，需4Leaf；每Leaf16上联分到4Spine，各4条；每Spine用16口。链路总数128，交换机被用端口为64加两倍64，即192，服务器另有64端点。1:1只是上下联容量没有超售。若假设每条光链路两端各一个独立模块，才有256个模块端；真实Twin模块、DAC/AOC、拆分与配线要单独核对。4Spine是选定布局而非最少台数，故障后的剩余带宽需重新算，不能仅凭端口相等保证线速。

追问 为什么128条链路不一定要256只独立光模块？

不要把物理笼位、逻辑端口和模块一一等同。 对应章节

34. 有RDMA网卡为什么训练仍然慢？

看是否会验证真正的数据路径。

有直达货梯，也可能堵在入口或目的地。

查是否走预期RDMA路径，再查协议速率、PCIe与NUMA、GPU-NIC映射、拥塞和通信库。最后确认应用是否在等数据或慢rank，不把单链路测试当训练性能。

RDMA减少部分CPU处理和中转，GPUDirect RDMA需要GPU、NIC、驱动和平台拓扑支持。同机设备也可能跨CPU路径。RoCE还要检查端点和交换网络的优先级、PFC、ECN与拥塞控制，而不是只看配置开关。PFC是逐跳暂停，不等于端到端控制；拥塞可能扩散。验收依次看物理链路、点对点、不同消息大小的集合通信，再跑实际作业。若某rank因存储或CPU预处理迟到，其他卡也会在同步点等待，表象很像网络问题。用阶段时间和错误计数定位，比直接更换更快网卡有依据。

追问 PFC与ECN分别解决什么？

不要把零丢包等同没有拥塞。 对应章节

35. DDP与FSDP怎样影响显存和网络？

判断是否区分复制和分片。

DDP每人一整本，FSDP各存一部分、使用时收齐。

DDP通常复制模型并同步梯度，FSDP在相应策略下分片参数、梯度和优化器状态。FSDP减少重复存储，但增加收齐与分片通信；激活、临时参数和缓冲峰值还要单算。

训练账本包括权重、梯度、优化器、激活和临时空间，具体字节数随精度与实现而变。DDP主要让不同进程处理不同数据，不能自动让装不下的完整权重适配单卡。FSDP按配置在计算前收齐参数，再同步分片梯度，因此峰值不是总内存简单除卡数。预取用更多显存换通信计算重叠，封装粒度也影响表现。通信网络、PCIe路径和数据供给决定扩展效率。比较时固定任务、批量或质量目标，分别报告吞吐、每步时间、通信等待与显存峰值，避免改变任务后声称纯粹扩卡加速。

追问 为什么训练不能直接用推理权重公式？

不要说FSDP所有开销都均匀分摊。 对应章节

36. All-Reduce怎样估搬运量？

看是否清楚公式口径与限制。

大家合并一份结果，各自拿到同样内容。

理想环形模型中，P个rank、每rank完整数组S，每rank发送约2(P-1)S/P，接收同量。8rank、1GB时各发送约1.75GB。它是搬运规模近似，不是实际时间保证。

All-Reduce按指定操作合并各rank数组，让每个rank获得结果。环形教学模型分归约散射和全部聚集，每一步只搬相应分块。公式中的S是每rank参与的完整数组，不是整个网络所有进程数据总和，发送与接收需分开口径。8个rank时因子1.75；统计收发总和再说明额外倍数。NCCL测试的算法带宽与总线带宽也有校正区别。真实实现可选择其他算法，受消息尺寸、拓扑、端点、拥塞和计算重叠影响。规划时用公式理解量级，用通信测试和实际训练证明耗时，不能直接除网卡峰值就写进SLA。

追问 rank等于一台服务器吗？

不要把每rank发送量当全网总流量。 对应章节

37. 存储如何让GPU吃不饱？

看能否排查数据供应链。

仓库出货、解压和搬运都可能卡住工位。

查读取吞吐、IOPS与元数据，再看CPU预处理、预取、主机到GPU传输和缓存。模型加载、样本读取、检查点分别规划，用真实数据与冷/热缓存验证。

容量、吞吐和操作次数对应不同访问模式。大文件顺序读取与百万小文件的瓶颈不同，聚合带宽还可能被客户端或网络限制。教学假设8节点各需3GB/s，就有24GB/s应用需求，但还要核对全链路。模型同时冷启动会集中读大文件，检查点则集中写状态，并要求可恢复一致性。CPU解压和增强可能先饱和，导致存储与GPU都不满。GDS可以优化支持路径的中转，不会免除格式解析。验收要覆盖并发、冷缓存、检查点和恢复，不能只交一项磁盘顺序峰值。

追问 缓存丢失与训练结果丢失的风险有何不同？

不要用容量TB数代表性能。 对应章节

38. 百万上下文还需要RAG吗？

考察窗口、质量与治理的区别。

大书桌能摊更多页，但仍要挑对资料。

长窗口增加可接收材料，不自动解决成本、权限、更新、定位与准确使用。RAG筛选相关且授权的证据，长上下文可作为补充，是否采用以真实任务质量和资源成本验证。

首先核对接口输入输出限制和分词口径。标准完整注意力的位置比较通常有平方级关系，而常规KV随缓存长度线性增加，两者不能混淆。高效内核减少部分存储和搬运，不代表无限长度无代价。即使材料放得下，模型也可能漏条件或整合冲突版本。企业资料还涉及授权、现行有效与引用。RAG可减少无关输入并支持治理，长上下文可容纳更完整父文档，二者能组合。PoC要测跨页、长尾、冲突和证据位置，同时记录词元、时延与显存，再决定如何组织材料。

追问 GQA主要省哪一部分资源？

不要说窗口长就不需要知识治理。 对应章节

39. 首字慢与后续生成慢分别查什么？

看是否能拆开端到端时延。

等位与出菜节奏的瓶颈不同。

首字慢查排队、输入长度、检索工具、冷启动和Prefill；后续慢查活跃序列、缓存、带宽、通信和调度。客户端与代理缓冲也要排除，按请求关联各阶段。

我先确认用户慢在哪，并统一客户端与服务端测量点。网关、检索、重排和模型分别打时间戳；输入增长通常增加预填充工作，长输出则持续占解码和KV。队列接近饱和时，平均资源利用率正常也可能尾时延很高。长短任务混合可考虑分队列或分块预填充，但要评估公平性。缓存、量化、扩副本与卸载解决不同问题，不能一开始就加卡。报告带长度分布、到达率、缓存状态、失败和取消，寻找满足SLO的稳定容量点；冷启动和故障切换另测，避免把最好热缓存结果当长期承诺。

追问 为什么增加并发会降低个人输出速度？

不要只看总Tokens/s。 对应章节

40. RAG能直接统计交易总额吗？

判断是否区分资料检索与完整计算。

找几张卡片不能证明看完全部账本。

少量资料解释可用RAG，精确汇总大量记录应使用授权的结构化查询与确定性计算。模型解释结果并引用数据范围，不能从Top-K片段推算全量总额。

先判断问题是解释规则、定位记录还是精确统计。检索通常只取相关候选，不保证覆盖所有满足条件的数据，尤其金额求和与分组比较。可用RAG解释报销规则，再让只读数据库工具按权限、时间与部门查询，程序做计算，模型组织结论。要说明分母、币种、时区和缺失记录。复杂资料问题可以分解与多跳检索，但中间生成内容仅作线索，真实来源才能当证据。评估要检查必要证据是否完整，数值与引用是否支持结论，而不只看文笔或引用数量。

追问 问题改写为什么可能造成偏移？

不要让模型从少数片段猜全库统计。 对应章节

41. Agent接口超时后能直接重试吗？

考察副作用与恢复能力。

回执丢了，不代表事情没办。

先区分只读和写入，以及未知结果与明确失败。写入用幂等键或查询业务状态，避免重复；跨系统部分成功要有补偿或人工出口，任务记录状态与调用标识。

假设创建工单已执行但响应丢失，第二次提交可能再创建一张。执行器需要同一操作的幂等键，或根据请求标识核对最终记录。任务状态独立于聊天，保存审批、参数和每步结果，刷新后按检查点恢复。权限错误不应盲目重试，临时网络错误有限退避。多系统没有统一事务时，部分成功需要补偿计划并记录补偿失败。最后按业务后置条件判断完成，不因模型说了完成或HTTP接受请求就算成功。验收用重复提交、审批延迟和中断恢复测试。

追问 审批后参数变化怎么办？

不要认为所有重试都无副作用。 对应章节

42. 怎样把方案变成BOM、SOW与验收？

看能否把技术与交付责任连起来。

采购单、工作范围和合格标准要相互对应。

先做任务、质量、数据和负载调研，再核算服务器、网络、存储与冗余。BOM列规格数量，SOW列范围责任，PoC验证假设，生产验权限、性能、恢复与运维。

我从业务和错误代价开始，收集数据权限、更新、活跃用户、峰值与Token分布。技术侧确认模型许可、显存、并行、拓扑和数据路径，机房侧确认电力散热和布线。形成候选后核查具体订货型号、接口、模块和配套支持，不能把宣传芯片参数当整机配置。BOM还含备件维保，SOW明确数据准备、接口、测试培训与上线责任。PoC、试点和生产有不同退出条件与回退方式。没有报价或压测的地方明示假设，不伪造价格与并发，让每个重要数字都有来源或验证计划。

追问 哪些项目工作最容易漏出报价？

不要以设备表代替完整交付方案。 对应章节

30 分钟速查

• 0–5分钟 · 讲清模型。 文本→Token ID→Embedding→位置与注意力→下一个Token。模型学的是生成规律，事实可靠需要证据与验证。70B BF16理论权重约140GB，缓存和运行时另算。
• 5–12分钟 · 讲清RAG。 入库：采集、解析、分块、嵌入、索引。查询：身份、过滤、混合召回、重排、上下文、回答、引用。先测证据召回，再测答案。过期制度先查版本、索引与缓存。
• 12–17分钟 · 讲清Agent。 模型提出工具名和参数，应用校验并执行。固定任务优先工作流，动态任务再用受限Agent。MCP是连接协议。最小权限、审批、幂等、预算和停止条件要落实在代码中。
• 17–23分钟 · 讲清算力。 计算、显存、带宽、互联分别看。KV公式依结构与活跃序列，不凭参数量猜。TP、PP和独立副本不同；连续批处理、分页KV和前缀缓存各解决不同问题。
• 23–27分钟 · 讲清方案。 人数→活跃→请求→忙时→输入输出Token→候选配置→压测→冗余与扩容。性能看TTFT、TPOT、吞吐、P95和错误率；TCO包含能耗、运维与冗余。
• 27–30分钟 · 练习真实表达。 用“问题—机制—取舍—验证”回答。区分实际项目、个人动手和理论方案。展示IaaS需求、架构、成本和交付经验如何迁移，不编造AI客户和生产业绩。

常见易错点

• 一个Token等于一个汉字？ 不固定，取决于分词器和文本。
• Attention就是实时查互联网？ 它在输入表示之间计算关系，外部查询需要工具。
• 温度为零就没有幻觉？ 随机性降低不等于事实得到验证。
• 开放权重就能任意商用？ 分别核查权重、代码与数据许可证。
• RAG可以保证不幻觉？ 仍可能错检索、错引用或错误整合。
• 向量相似度0.8就是80%正确？ 分数代表相关性，不是校准过的正确概率。
• Rerank能救回所有漏召回？ 它主要对已有候选重排。
• 分块越短、Top-K越大越好？ 需平衡条件完整、噪声与预算。
• 先检索全库，再让模型保密？ 未授权内容不应进入模型上下文。
• 上传时间就是制度生效时间？ 两个时间语义不同，应显式记录有效期。
• 工具调用JSON生成了就执行了？ 应用必须校验、执行并核对结果。
• MCP自动解决权限和规划？ 它规范连接，业务授权与Agent策略另行实现。
• 多Agent一定比单Agent好？ 增加协调与成本，须比较任务收益。
• 70B BF16总共只需140GB？ 这是理论权重，缓存和运行时另计。
• 权重INT4，KV也一定INT4？ 缓存精度独立，需要配置与支持。
• 1000员工就要1000并发？ 应由真实使用与请求长度推导负载。
• 四卡TP就是四个高可用副本？ 常是一个跨四卡实例，故障域不同。
• NVL72的显存是单卡规格？ 它是整机架总量，不能混写。
• GPU利用率高说明体验好？ 可能排队很长，要看用户时延和错误率。
• 有容器就没有驱动兼容问题？ 宿主驱动、设备插件、框架和模型仍需匹配。

返回目录

术语

返回目录

AI · 人工智能

Artificial Intelligence。 让机器完成通常需要智能的任务。

统称预测、识别、规划与生成等能力。 识别发票并核对字段。 AI范围大于机器学习。 对应章节

ML · 机器学习

Machine Learning。 从数据学规律，而非逐条写规则。

根据样本拟合预测函数。 用订单历史预测销量。 并非所有ML都用深度网络。 对应章节

DL · 深度学习

Deep Learning。 用多层计算学习复杂特征。

构建表示学习模型。 视觉识别和语言生成。 是机器学习的一类方法。 对应章节

Neural Network · 人工神经网络

Artificial Neural Network。 由可调数字连接起来的计算函数。

通过训练学习输入输出关系。 预测下一个词元。 不是人脑的完整仿真。 对应章节

Generative AI · 生成式人工智能

Generative Artificial Intelligence。 根据要求创造新内容。

生成文字、图像或代码。 起草产品说明。 与只做分类或预测的任务不同。 对应章节

LLM · 大语言模型

Large Language Model。 学过大量语言材料的生成模型。

理解和生成文本。 解释合同条款。 语言流畅不等于事实可靠。 对应章节

VLM · 视觉语言模型

Vision-Language Model。 同时处理图像和语言。

连接视觉特征与文本任务。 解读设备截图。 多模态还可能包括音频等。 对应章节

Foundation Model · 基础模型

Foundation Model。 可适配多类任务的通用底座。

提供迁移能力。 将底座适配为指令助手。 基础模型不必已经适合聊天。 对应章节

Token · 词元

Token。 模型读写文本的基本片段。

作为序列处理与计费单元。 英文单词可能拆成多个词元。 不固定等于汉字或单词。 对应章节

Tokenization · 分词

Tokenization。 按规则把文本切成词元。

转换文本到词表编号。 将一句话转成ID序列。 与按语义切文档块不同。 对应章节

Token ID · 词元编号

Token Identifier。 词表里某个片段的索引号。

用于查找嵌入表示。 编号映射到向量行。 编号距离不是语义距离。 对应章节

Embedding · 嵌入

Embedding。 把内容变成可计算的一组数。

形成表示或检索向量。 问题与文档比较相似度。 不是聊天答案，也非可逆全文压缩。 对应章节

Vector · 向量

Vector。 有顺序的一列数。

表示特征与执行相似度计算。 三维示例[0.2,-0.4,0.7]。 每维未必有固定可解释标签。 对应章节

Transformer · 变换器架构

Transformer（架构名）。 通过注意力等层处理序列。

建立上下文表示。 解码器预测下个词元。 不是所有神经网络的总称。 对应章节

Attention · 注意力机制

Attention Mechanism。 按相关程度汇总信息。

让位置利用其他位置的内容。 代词结合前文形成表示。 权重不等于因果解释。 对应章节

Q/K/V · 查询／键／值

Query / Key / Value。 要找什么、如何匹配、汇总什么。

构成注意力计算。 Q与K算权重后汇总V。 不是三个外部数据表。 对应章节

Positional Encoding · 位置编码

Positional Encoding。 给序列补充先后与距离信息。

让模型区分顺序。 区分甲追乙与乙追甲。 不等于词元编号。 对应章节

Context Window · 上下文窗口

Context Window。 本次可处理的词元空间。

限制输入与输出预算。 系统提示和历史占用窗口。 容量大不保证利用准确。 对应章节

Hallucination · 幻觉

Hallucination。 生成没有依据或与事实冲突的内容。

描述生成风险。 编造不存在的制度条款。 不只发生在高温度采样。 对应章节

Parameter · 模型参数

Model Parameter。 训练调整的数字。

保存模型学习到的映射。 70B约七百亿参数。 参数量不同于激活参数量。 对应章节

Training · 训练

Model Training。 根据损失调整参数。

学习任务能力。 预训练预测文本。 普通聊天推理不自动改权重。 对应章节

Inference · 推理执行

Model Inference。 使用已有参数处理请求。

生成预测或回答。 调用聊天模型。 不必包含复杂逻辑推理任务。 对应章节

Prefill · 预填充

Prefill。 先处理输入并建立历史状态。

计算提示对应的表示和缓存。 读取长合同后开始回答。 与逐词生成的Decode不同。 对应章节

Decode · 自回归解码

Autoregressive Decoding。 根据已有内容继续生成。

逐词元输出答案。 流式显示后续文字。 不同于一次处理全部输入。 对应章节

KV Cache · 键值缓存

Key-Value Cache。 保存历史位置的注意力状态。

减少生成时的重复计算。 长对话缓存持续增长。 不是答案缓存或企业知识库。 对应章节

GQA · 分组查询注意力

Grouped-Query Attention。 多个查询头共享较少KV头。

减少部分缓存和计算成本。 32查询头配8KV头的教学结构。 KV头数不等于查询头数。 对应章节

MoE · 混合专家

Mixture of Experts。 每次选择部分专家参与计算。

扩大模型容量并稀疏激活。 总参数多但活跃部分较少。 总权重与活跃参数需分开。 对应章节

FP32 · 单精度浮点

32-bit Floating Point。 每个数用32位表示。

提供较高数值精度。 训练与科学计算部分路径。 每参数四字节而非两字节。 对应章节

FP16 · 半精度浮点

16-bit Floating Point。 用16位表示浮点数。

降低存储与计算代价。 模型权重每项两字节。 与BF16范围分配不同。 对应章节

BF16 · 脑浮点16

Brain Floating Point 16。 16位但具有不同数值范围分配。

适用于支持设备的训练推理。 70B理论权重约140GB。 同位宽不等于与FP16完全相同。 对应章节

FP8 · 八位浮点

8-bit Floating Point。 以8位表示浮点数的格式族。

降低部分存储和计算成本。 支持路径上的矩阵运算。 格式与硬件支持需核查。 对应章节

INT4 · 四位整数

4-bit Integer。 每个值用四个二进制位。

常用于权重量化。 70B理论权重约35GB。 不代表所有状态都是四位。 对应章节

Quantization · 量化

Quantization。 用较粗的数值刻度省空间。

减少权重或状态位宽。 BF16权重转为低位表示。 不是一定无损或加速。 对应章节

Prompt · 提示

Prompt。 交给模型的任务、材料与示例。

控制本次生成行为。 要求按结论和来源回答。 不会直接修改模型参数。 对应章节

System Prompt · 系统提示

System Prompt。 应用给模型的角色与规则。

表达行为约束。 要求证据不足时拒答。 不能替代真实权限。 对应章节

Temperature · 采样温度

Sampling Temperature。 调整候选概率分布的尖锐程度。

控制生成多样性。 低温度偏向高概率词元。 不是准确率旋钮。 对应章节

Top-p · 核采样

Nucleus Sampling。 从累计概率范围内选候选。

约束采样集合。 取累计概率达到阈值的候选。 不同于固定取前K个。 对应章节

SFT · 监督微调

Supervised Fine-Tuning。 用输入与正确回答继续训练。

适配任务行为。 学习规范工单回复。 可结合LoRA，不互斥。 对应章节

LoRA · 低秩适配

Low-Rank Adaptation。 用小矩阵学习权重增量。

降低可训练参数规模。 训练专用回答风格适配器。 不等于缩小全部底座权重。 对应章节

QLoRA · 量化低秩适配

Quantized Low-Rank Adaptation。 量化底座并训练适配器。

降低微调资源需求。 四位底座配LoRA训练。 存储四位不代表所有计算四位。 对应章节

Distillation · 知识蒸馏

Knowledge Distillation。 让学生模型学习教师能力。

压缩或迁移任务能力。 小模型学分类任务。 不保证所有能力等同教师。 对应章节

RAG · 检索增强生成

Retrieval-Augmented Generation。 先查证据，再生成回答。

接入外部或企业知识。 按内部制度解释报销。 不自动消除幻觉。 对应章节

OCR · 光学字符识别

Optical Character Recognition。 把图片里的字识别出来。

解析扫描文档。 扫描PDF转文字。 识别文字不等于恢复表格结构。 对应章节

Chunk · 文本块

Text Chunk。 用于检索的一段资料。

平衡定位与上下文预算。 一条完整制度及标题。 不同于模型词元。 对应章节

Overlap · 分块重叠

Chunk Overlap。 相邻块共享少量内容。

减少边界信息丢失。 下一块保留上一段末句。 越大不一定越好。 对应章节

Vector Database · 向量数据库

Vector Database。 管理向量与元数据的检索服务。

建立索引并回查证据。 保存块ID、向量和权限。 不等于完整RAG产品。 对应章节

FAISS · 相似度检索库

Facebook AI Similarity Search。 把向量检索嵌入程序的库。

提供相似度索引与搜索。 单机检索原型。 不是完整企业数据库服务。 对应章节

pgvector · PostgreSQL向量扩展

pgvector（扩展名）。 给关系数据库加向量能力。

结合SQL与向量检索。 按部门过滤文档向量。 不同于独立数据库产品。 对应章节

Milvus · Milvus向量数据库

Milvus（项目名）。 独立管理向量的数据库。

向量索引、过滤和检索。 企业检索服务候选。 业务权限与解析仍需设计。 对应章节

Cosine Similarity · 余弦相似度

Cosine Similarity。 比较两个向量方向的接近程度。

作为检索相关性度量。 [1,0]与[0.8,0.6]为0.8。 分数不是正确率。 对应章节

ANN · 近似最近邻

Approximate Nearest Neighbor。 用近似方式更快找邻居。

减少大规模向量比较。 HNSW索引检索。 通常以部分召回换速度。 对应章节

Dense Retrieval · 稠密检索

Dense Retrieval。 用连续向量找语义相近内容。

覆盖同义表达。 无线网与WLAN匹配。 不擅长所有精确标识。 对应章节

Sparse Retrieval · 稀疏检索

Sparse Retrieval。 按少量非零词维度匹配。

词项相关性检索。 查具体错误码。 不只是简单字符串相等。 对应章节

BM25 · BM25关键词排序

Best Matching 25。 结合词频、稀有程度与长度打分。

实现经典文本检索。 匹配产品型号手册。 分数不能直接与余弦相加。 对应章节

Hybrid Search · 混合检索

Hybrid Search。 组合关键词与语义找资料。

互补不同检索优势。 型号精确加同义描述。 仍需权限和版本过滤。 对应章节

Rerank · 重排序

Reranking。 对有限候选再次细致判断。

提升候选排列质量。 联合比较问题与段落。 不能凭空补回漏召回证据。 对应章节

Top-K · 前K个结果

Top K Results。 只取排名最靠前的K项。

限定候选规模。 检索前20条做重排。 不同于采样Top-p。 对应章节

Recall · 召回率

Recall。 应找到的证据找到了多少。

衡量覆盖。 相关证据进入前K比例。 与答案准确率不同。 对应章节

Precision · 精确率

Precision。 返回的候选里多少真正相关。

衡量候选纯度。 十条中七条相关。 与召回覆盖不是同一指标。 对应章节

ACL · 访问控制列表

Access Control List。 记录谁能看哪些资源。

执行资源授权。 部门可见文档列表。 不应只写进提示。 对应章节

RBAC · 基于角色的访问控制

Role-Based Access Control。 按岗位角色分配权限。

管理企业访问边界。 财务角色查看报销附件。 与单个模型能力无关。 对应章节

Agent · 智能体

AI Agent。 在目标和规则内选择并执行步骤。

管理多步工具任务。 分析GPU监控并形成报告。 不等于无限自主执行。 对应章节

Function Calling · 函数调用

Function Calling。 模型提出结构化工具请求。

连接语言判断与应用执行。 请求查询指定项目监控。 真正执行者是应用。 对应章节

API · 应用程序编程接口

Application Programming Interface。 系统对外提供的调用入口。

读取数据或执行业务。 监控查询接口。 接口存在不代表已授权。 对应章节

Workflow · 工作流

Workflow。 预先规定步骤和分支。

稳定执行固定业务。 按规则生成日报。 可以包含模型调用。 对应章节

ReAct · 推理与行动交替

Reasoning and Acting。 做一步，观察，再决定下一步。

组织Agent执行循环。 查指标后追加日志查询。 不是公开隐藏推理的要求。 对应章节

MCP · 模型上下文协议

Model Context Protocol。 AI应用连接外部能力的规范。

标准化工具发现与调用。 接入监控工具服务端。 不负责自动规划或授权。 对应章节

HITL · 人工参与

Human-in-the-loop。 关键节点由人审查或处理。

控制高影响操作。 批准资源调整。 不等于所有动作都频繁弹窗。 对应章节

Prompt Injection · 提示注入

Prompt Injection。 把外部数据伪装成操作指令。

描述输入安全风险。 文档诱导发送内部数据。 私网资料也可能携带。 对应章节

Idempotency · 幂等性

Idempotency。 重复提交不会新增副作用。

让重试更安全。 同一键只创建一次工单。 不等于请求永不失败。 对应章节

CPU · 中央处理器

Central Processing Unit。 偏重通用控制与复杂任务。

调度、分词及业务计算。 处理网关请求。 GPU不能替代全部CPU职责。 对应章节

GPU · 图形处理器

Graphics Processing Unit。 擅长大量并行运算的处理器。

执行矩阵与图形计算。 大模型推理。 容量与算力是两回事。 对应章节

CUDA · CUDA并行计算平台

Compute Unified Device Architecture。 NVIDIA的计算软件生态。

支持GPU程序与库。 运行兼容的推理内核。 不是所有品牌通用接口。 对应章节

Tensor Core · 张量核心

Tensor Core。 专门执行矩阵乘加的单元。

加速支持精度的计算。 低精度矩阵运算。 支持格式随代际变化。 对应章节

FLOPS · 每秒浮点运算数

Floating-point Operations Per Second。 衡量浮点计算速度。

描述峰值或测量性能。 TFLOPS为每秒万亿次。 不是每秒输出词元数。 对应章节

HBM · 高带宽内存

High Bandwidth Memory。 给加速器提供高速数据供给的内存。

存权重与缓存。 H200的HBM3e。 不是所有GPU都采用HBM。 对应章节

PCIe · 高速外设互联

Peripheral Component Interconnect Express。 连接CPU与设备的总线标准。

传输主机和设备数据。 PCIe GPU卡。 与NVLink能力不同。 对应章节

NVLink · NVLink高速互联

NVLink（NVIDIA技术名）。 GPU等处理器之间的高速连接。

降低协同通信瓶颈。 机内多GPU模型并行。 不是所有NVIDIA卡都有。 对应章节

NVSwitch · NVLink交换组件

NVSwitch（NVIDIA组件名）。 连接多个GPU的交换结构。

形成高带宽通信域。 多GPU服务器底板。 不是普通以太网交换机。 对应章节

TP · 张量并行

Tensor Parallelism。 把同一层计算分给多卡。

分摊权重和计算。 多卡协同运行大模型。 不同于独立副本。 对应章节

PP · 流水线并行

Pipeline Parallelism。 把不同层分到不同设备。

分阶段执行模型。 前半层与后半层分机。 需要平衡阶段和空泡。 对应章节

Batch Size · 批大小

Batch Size。 一次组织计算的样本规模。

提高资源利用。 动态合批多个请求。 不等同排队并发。 对应章节

vLLM · vLLM推理引擎

vLLM（项目名，无官方缩写展开）。 面向语言模型服务的运行引擎。

调度请求并管理缓存。 提供兼容API服务。 具体支持依版本和硬件。 对应章节

PagedAttention · 分页注意力

PagedAttention。 以块管理注意力缓存。

减少连续分配浪费。 动态分配KV块。 不创造无限显存。 对应章节

Prefix Cache · 前缀缓存

Prefix Caching。 复用相同开头的计算状态。

减少重复预填充。 多人询问同一长材料。 不直接减少新词元解码。 对应章节

Continuous Batching · 连续批处理

Continuous Batching。 请求完成后动态补入新请求。

提高调度效率。 短请求结束后接新任务。 不等于无限并发。 对应章节

TTFT · 首词元时延

Time To First Token。 等第一个词元要多久。

衡量交互启动速度。 从发请求到首字。 需说明是否含网络排队。 对应章节

TPOT · 每输出词元时间

Time Per Output Token。 后续平均多久生成一个词元。

衡量生成节奏。 每词元约50毫秒的假设。 与整体总吞吐不同。 对应章节

QPS · 每秒查询数

Queries Per Second。 一秒处理或到达多少请求。

描述负载和服务量。 每秒两次问答请求。 需注明到达或完成口径。 对应章节

Concurrency · 并发

Concurrency。 同时在系统中的请求数量。

规划队列与活跃资源。 二十个在途请求。 不是注册员工人数。 对应章节

P95 · 第95百分位

95th Percentile。 约95%样本不超过的值。

观察尾部体验。 P95时延两秒。 不是平均时延。 对应章节

SLO · 服务级别目标

Service Level Objective。 希望达到的可靠性或性能目标。

制定容量与运维标准。 规定负载下的成功率。 不完全等同正式合同SLA。 对应章节

SLA · 服务级别协议

Service Level Agreement。 正式约定的服务承诺。

界定服务责任。 可用性和响应约定。 不能根据最好一次测试承诺。 对应章节

MIG · 多实例GPU

Multi-Instance GPU。 在支持设备上划分硬件实例。

提供特定资源隔离。 按支持规格切分GPU。 不是时间片且非全型号支持。 对应章节

vGPU · 虚拟GPU

Virtual GPU。 通过虚拟化机制使用GPU资源。

支持虚拟机等共享设备。 企业图形或计算虚拟桌面。 可能需要许可和兼容硬件。 对应章节

RDMA · 远程直接内存访问

Remote Direct Memory Access。 减少CPU介入的网络内存传输。

加速跨节点数据交换。 分布式训练同步。 需要端到端支持。 对应章节

RoCE · 融合以太网RDMA

RDMA over Converged Ethernet。 在以太网上实现RDMA。

构建高性能通信网络。 GPU集群网络。 网卡支持不等于网络已配置好。 对应章节

InfiniBand · InfiniBand互联

InfiniBand（互联技术名）。 用于高性能计算的网络技术。

低延迟高带宽通信。 大规模训练集群。 不是RoCE的另一个名字。 对应章节

Docker · 容器工具

Docker（项目名）。 打包和运行应用用户空间。

复现模型服务依赖。 推理容器镜像。 不包含所有宿主驱动能力。 对应章节

Kubernetes · 容器编排平台

Kubernetes（项目名，K8s）。 管理应用部署、调度与健康。

组织多节点服务。 调度GPU模型副本。 不自动保证GPU性能隔离。 对应章节

PyTorch · 深度学习框架

PyTorch（项目名）。 提供张量计算和训练运行能力。

构建与执行模型。 加载神经网络做推理。 不等于完整企业服务平台。 对应章节

Transformers · 模型生态库

Transformers（Hugging Face库名）。 提供模型、分词器等实现。

加载与适配预训练模型。 文本生成原型。 与Transformer架构概念区分。 对应章节

TCO · 总拥有成本

Total Cost of Ownership。 把整个使用周期的账算全。

比较自建与租赁。 硬件加能耗运维和冗余。 不只是设备采购价。 对应章节

PUE · 电能使用效率

Power Usage Effectiveness。 总设施能耗除以IT能耗。

估算机房附加能耗。 教学假设PUE为1.4。 不是GPU自身计算效率。 对应章节

HA · 高可用

High Availability。 故障时仍能提供约定服务。

设计副本与依赖冗余。 实例失效后接管请求。 多卡切分不等于高可用。 对应章节

RTO · 恢复时间目标

Recovery Time Objective。 允许多久恢复业务。

制定故障恢复方案。 模型重载与接流量时限。 与数据丢失窗口RPO不同。 对应章节

RPO · 恢复点目标

Recovery Point Objective。 允许丢失多久的数据。

制定备份和状态恢复策略。 索引更新恢复点。 与服务恢复时长不同。 对应章节

PoC · 概念验证

Proof of Concept。 用代表性样本验证可行性。

降低方案不确定性。 评估知识库检索与答案。 演示成功不等于生产验收。 对应章节

NUMA · 非统一内存访问

Non-Uniform Memory Access。 不同CPU访问不同内存区域的代价不同。

理解主机与设备数据路径。 双路CPU各有本地内存。 物理位置近不代表拓扑路径近。 对应章节

NIC · 网络适配器

Network Interface Card。 服务器连接网络的设备。

收发网络数据。 一个适配器可有多个端口。 网卡张数不同于端口数。 对应章节

HCA · 主机通道适配器

Host Channel Adapter。 InfiniBand主机侧连接设备。

接入高性能互联。 计算节点的IB适配器。 具体卡型与端口配置要核实。 对应章节

Leaf · 叶交换机

Leaf Switch。 直接接服务器的接入层。

聚合服务器端口并连接骨干。 16下联16上联的教学例子。 下联和上联都占端口。 对应章节

Spine · 脊交换机

Spine Switch。 连接各Leaf的骨干层。

提供跨Leaf通信路径。 每Leaf连到每Spine。 不能只数台数忽略连接分配。 对应章节

Oversubscription · 超售比

Oversubscription Ratio。 下联总带宽与上联总带宽的比。

检查汇聚容量。 16个同速下联配8上联为2:1。 1:1不保证应用线速。 对应章节

OSFP · 八通道可插拔封装

Octal Small Form-factor Pluggable。 一种高速模块封装形式。

承载电光或其他链路组件。 一个笼位可承载多个逻辑口。 笼位数不一定等于网络端口数。 对应章节

DAC · 直连铜缆

Direct Attach Copper。 以完整组件连接设备的铜缆。

在兼容距离内连接高速端口。 短距离机内或机架连接。 不按独立光模块方案直接计数。 对应章节

AOC · 有源光缆

Active Optical Cable。 带有源端部的整体光缆组件。

连接适配的高速端口。 按厂商支持矩阵采购。 不等于两只独立模块加光纤。 对应章节

NDR · NDR速率代际

Next Data Rate。 InfiniBand的一代速率名称。

描述兼容链路能力。 NDR常见400Gb/s逻辑链路。 NDR200与NDR配置不同。 对应章节

ECN · 显式拥塞通知

Explicit Congestion Notification。 网络标记拥塞以帮助源端减速。

配合端到端拥塞控制。 RoCE发送端收到拥塞反馈。 不等于逐跳暂停。 对应章节

PFC · 按优先级流控

Priority Flow Control。 暂停相邻设备的特定优先级流量。

缓解某些队列拥塞。 暂停一个优先级的发送。 不是端到端控制且可能传播等待。 对应章节

GPUDirect RDMA · GPU直接远程内存访问

GPUDirect Remote Direct Memory Access。 兼容设备直接交换GPU显存数据。

减少主机内存中转。 网卡与GPU通信。 受驱动与PCIe拓扑支持约束。 对应章节

GDS · GPU直接存储访问

GPUDirect Storage。 优化存储到GPU显存的数据路径。

减少部分中转拷贝。 受支持文件系统读取数据。 不消除解析与解压。 对应章节

DDP · 分布式数据并行

Distributed Data Parallel。 各进程用模型副本处理不同数据并同步。

扩展训练样本处理。 多卡同步梯度。 不自动把完整权重分小。 对应章节

FSDP · 完全分片数据并行

Fully Sharded Data Parallel。 把部分模型训练状态分散保存。

减少重复存储。 计算前收齐需要的参数。 峰值并非所有内存除卡数。 对应章节

All-Reduce · 全部归约

All-Reduce。 合并各参与者的数据并让大家取得相同结果。

同步梯度等状态。 八个rank逐元素求和。 流量与时间口径要分别说明。 对应章节

All-Gather · 全部聚集

All-Gather。 各自持一片，最后大家收齐。

收集分布状态。 FSDP计算前收齐参数。 不包含归约求和的含义。 对应章节

Reduce-Scatter · 归约散射

Reduce-Scatter。 先合并，最后每人保留结果的一片。

分片同步结果。 同步后分散保存梯度。 与All-Gather方向作用不同。 对应章节

Rank · 通信组进程编号

Process Rank。 分布式参与者的身份编号。

识别通信与任务参与进程。 rank0记录汇总。 不总等同于一台服务器。 对应章节

NCCL · NVIDIA集合通信库

NVIDIA Collective Communications Library。 为兼容GPU提供集合通信。

完成归约和聚集等操作。 训练梯度同步。 不是交换机或自动网络规划器。 对应章节

EP · 专家并行

Expert Parallelism。 将不同专家分布到不同设备。

扩展MoE执行。 路由词元到相应专家。 总参数与通信需求仍需核算。 对应章节

Gradient Accumulation · 梯度累积

Gradient Accumulation。 多个微批先累加，再更新。

扩大有效批量的选择空间。 四次微批后更新一次。 改变节奏需验证训练设置。 对应章节

Activation Checkpointing · 激活重计算

Activation Checkpointing。 少存中间结果，反向时重算。

以额外计算换显存。 不保留某些层激活。 不等于保存恢复检查点。 对应章节

Checkpoint · 训练检查点

Training Checkpoint。 保存可继续训练的状态。

故障恢复或阶段保存。 参数、优化器和进度。 往往比推理权重更多。 对应章节

IOPS · 每秒输入输出操作数

Input/Output Operations Per Second。 一秒可处理多少次存储操作。

衡量操作频率能力。 大量小块读取。 需结合块大小，不等于GB每秒。 对应章节

NVMe · 非易失存储高速访问协议

Non-Volatile Memory Express。 高速访问存储设备的协议。

承载本地SSD等访问。 模型与样本本地缓存。 协议名不保证实际吞吐。 对应章节

Pinned Memory · 页锁定内存

Page-locked Memory。 不被操作系统换出的内存。

支持某些高效设备传输。 数据预取缓冲。 过多申请会挤占主机内存。 对应章节

OOB · 带外管理

Out-of-Band Management。 独立于业务路径的管理能力。

远程硬件诊断与控制。 业务网络故障时远程重启。 不能与计算互联混算。 对应章节

RLHF · 基于人类反馈的强化学习

Reinforcement Learning from Human Feedback。 借助偏好信号训练模型行为的路线。

改善回答偏好与交互。 比较回答优劣形成反馈。 不是所有对齐方法的统称。 对应章节

Query Decomposition · 查询分解

Query Decomposition。 把复合问题拆成可验证子问题。

帮助多证据检索。 分别查两版本再比较。 中间生成内容不是事实证据。 对应章节

State Machine · 状态机

State Machine。 规定状态及允许的转换。

管理可恢复任务。 等待审批到执行。 不依赖聊天文字猜执行状态。 对应章节

Compensation · 补偿动作

Compensating Action。 抵消部分已发生业务影响。

处理跨系统部分成功。 失败后释放已预留资源。 补偿本身也可能失败。 对应章节

Observability · 可观测性

Observability。 通过外部信号理解系统状态。

关联指标、日志与追踪。 追踪同一请求跨多个服务。 不等于只做一个GPU看板。 对应章节

Canary Release · 灰度发布

Canary Release。 先给少量流量用新版本。

逐步验证质量与风险。 新模型先试点。 能启动不等于可以全量上线。 对应章节

DR · 灾难恢复

Disaster Recovery。 较大故障域后的业务恢复。

规划恢复路径与目标。 站点异常后恢复数据与服务。 与单实例高可用关注点不同。 对应章节

BOM · 物料清单

Bill of Materials。 列出部件、规格与数量。

形成采购依据。 服务器、交换机与配套线缆。 不等于交付范围说明。 对应章节

SOW · 工作说明书

Statement of Work。 说明做什么、谁负责、如何验收。

控制项目范围与责任。 权限接口集成及测试责任。 不是只列设备型号。 对应章节

返回目录

参考资料

• 48GB GDDR6、864GB/s、PCIe Gen4；无NVLink、无MIG。 NVIDIA L40S 官方规格
• 区分SXM80与PCIe80；本表使用SXM80口径。 NVIDIA A100 官方规格
• 本表为H100 SXM，不混用NVL和PCIe。 NVIDIA H100 官方规格
• H200 SXM容量、带宽与互联。 NVIDIA H200 官方规格
• B200单GPU 180GB口径。 NVIDIA HGX 参考架构
• Superchip与整机架总量，注意稀疏计算脚注。 NVIDIA GB200 NVL72
• 单OAM模块规格与精度支持。 AMD Instinct MI300X
• 单OAM模块容量与带宽。 AMD Instinct MI325X
• 服务能力、连续批处理、并行与兼容API。 vLLM 官方文档
• 历史设计页，用于解释机制，不代表当前完整内核实现。 vLLM PagedAttention 设计
• 复用前缀预填充，不直接减少后续解码。 vLLM 自动前缀缓存
• 区分量化底座、计算类型与适配器训练。 Hugging Face 量化与PEFT
• 低秩适配与底座冻结。 Hugging Face LoRA
• 相似度搜索库的职责边界。 FAISS 官方文档
• 向量数据库、元数据和检索。 Milvus 官方概览
• 精确与近似索引及过滤注意事项。 pgvector 官方仓库
• Host、Client、Server与发现调用。 MCP 官方架构（2026-07-28）
• 身份、令牌受众、最小权限与不可信内容。 MCP 官方安全实践（2026-07-28）
• 静态目录与ZIP直接上传。 Cloudflare Pages Direct Upload
• 张量、自动求导、优化与模型保存。 PyTorch 官方入门
• 模型、分词器与推理生态。 Hugging Face Transformers
• 本地推理与多种计算后端。 llama.cpp 官方仓库
• 本地模型运行与应用接入。 Ollama 官方文档
• NVIDIA语言模型推理工具与运行栈。 TensorRT-LLM 官方文档
• Fat-tree、rail布局、逐连接检查与分层验收。 NVIDIA InfiniBand 集群启用流程
• NDR/NDR200、OSFP与分支连接的口径。 DGX SuperPOD NDR与线缆概览
• 物理笼位与逻辑网络端口的区别。 QM97XX端口与线缆
• 具体订货型号、端口配置和主机接口。 ConnectX-7适配器手册
• GPU、NIC、NVMe的PCIe和NUMA布局。 NVIDIA认证系统配置指南
• 多网卡、rail与通信库配置边界。 NCCL环境与网络选择
• 数据并行副本、梯度同步与输入划分职责。 PyTorch DDP
• 参数、梯度、优化器状态分片与计算时峰值。 PyTorch FSDP
• All-Reduce的algbw、busbw与校正因子。 NCCL测试的带宽口径
• 直接交换GPU显存的支持条件与PCIe路径。 NVIDIA GPUDirect RDMA
• 存储到显存的数据路径与实现限制。 NVIDIA GPUDirect Storage
• RoCE、PFC、ECN以及不同工作模式。 NVIDIA Cumulus RoCE
• 流控、队列、拥塞与watchdog边界。 NVIDIA Cumulus QoS
• 注意力、GQA与存储机制；文中历史硬件例子不作当前选型依据。 Hugging Face 推理效率机制
• 强化学习和推理模型的教学背景。 Hugging Face 推理模型课程
• 用重计算交换部分激活存储。 PyTorch 激活检查点
• 调度、内存压力、预填充和并行策略的取舍。 vLLM 优化与调优

返回目录