1 推理服务平台要交付什么
在公开的银行客户流失数据上训练好分类器，只完成了模型工作的部分。运营人员提交客户资料后，还需要稳定拿到流失概率；图像分类应用需要接收图片并返回类别；短文本分类应用需要判断留言属于咨询、投诉还是其他。把这些模型接到真实请求上，并持续满足速度、质量、资源和权限约束，才是推理服务平台的任务。推理是使用已经训练好的模型计算结果，训练则是从样本中学习参数，两者的资源需求和更新节奏可能不同。
平台交付的对象不是孤立的模型文件，而是可以说明责任的服务。例如，客户流失模型输入账户年限、余额、产品数量和近期活跃情况，输出流失概率、模型版本及请求标识。接口要约定缺失值怎样处理、金额使用什么单位、哪些字段允许省略。若训练时余额以元表示，服务端却收到以分表示的数值，即使程序正常返回，结果也可能失真。因此，输入约定、预处理代码和模型版本需要共同发布。
用公开数据建立基线时，可以先把数据按 70%、15%、15% 划分为训练集、验证集和测试集。训练集拟合模型，验证集选择阈值和参数，测试集只用于最终评估。若同 1 位客户有多条记录，应按客户分组划分；预测未来流失时，还应按时间划分，避免未来信息进入过去的训练样本。标准化、缺失值填补等步骤只能在训练集上拟合，再应用到其余数据。平台保存这些约定，才能追溯线上结果来自什么数据处理过程。
交付标准同时包含服务指标与模型指标。服务指标可以是每秒成功请求数、错误率和第 95 百分位延迟，即 95% 的请求在这个时间内完成。模型指标则关注预测是否有用：精确率表示预测为流失的客户中真正流失的比例，召回率表示实际流失客户中被找出的比例，F1 综合这 2 个比例，AUC 衡量模型对正负样本的排序能力。它们不能互相替代，AUC 较高也不保证某个业务阈值下的精确率满足要求。
本课使用 3 类教学工作负载：表格流失预测、CIFAR-10 图像分类和 AG News 短文本分类。它们分别展示小输入、图片预处理和文本长度变化的影响。示例中的容量与延迟是演练设定，需要在实际设备上测量。平台应把请求成功、预测正确和资源使用合在同 1 份交付说明中，让使用者知道哪些结果已被验证，哪些条件变化后需要重新评估。
2 多模型路由与弹性池
多模型路由解决“这个请求应该交给谁”。请求进入后，平台先确认租户身份，再根据任务类型、模型名称、版本规则和输入约束选择服务。客户流失请求不能被送到文本分类模型；同为流失模型，也可能同时存在稳定版本与候选版本。路由表应记录明确的版本标识，避免把含义会变化的“最新版”当作可追溯证据。请求日志还要保留实际命中的版本，而不是只保留客户端想调用的名称。
弹性池是由若干工作实例组成、可以调整容量的资源集合。工作实例负责加载模型并执行计算。表格模型可能适合使用 CPU，图像模型可能需要加速设备，文本模型的耗时还可能随输入长度增长。平台可以为不同任务建立资源池，再在池内复用空闲容量。共享并不意味着所有模型都塞进同 1 个进程；进程、内存和设备如何分配，需要根据稳定性与测量结果决定。
看 1 个简化例子：图像池有 2 个实例，每个实例在指定图片尺寸和批量设置下，每秒可稳定完成 20 个请求。当前到达率为每秒 25 个请求，尚有余量；到达率持续升到每秒 45 个时，等待队列就可能增长。这里不能只用“2 乘 20”等式决定容量，因为输入大小、预处理、并发数和共享干扰都会影响实际吞吐。容量报告必须写明测量条件，不能只报设备的理论计算能力。
扩容也有等待过程：申请资源、启动进程、读取模型、初始化运行环境、执行预热，最后通过就绪检查，实例才可以接收流量。若仅在处理器使用率达到高位时扩容，队列可能已经积压。较稳妥的入门策略是同时观察队列长度、排队时间和实例负载，保留少量已预热容量。缩容则需要先停止向实例派发新请求，等待已有请求结束，再释放资源，防止扩缩容本身制造失败。
批处理可以把若干请求合并计算，提高某些模型的吞吐，但等待凑批会增加延迟。交互式文本分类与离线图片整理可以使用不同的批量和等待上限。缓存也需要明确边界：相同输入只有在模型、预处理和相关配置一致时才可能安全复用结果。涉及客户资料的缓存还必须带租户边界，不能因为输入摘要相同就跨租户返回数据。先把这些条件说清，再讨论更复杂的调度算法。
3 配额、隔离与可观测
配额回答“允许使用多少”，隔离回答“别人使用资源时，我受到多大影响”。租户可以是不同团队、项目或使用服务的组织。每个租户都应有可识别身份，并设置请求速率、同时处理请求数、队列长度和单请求大小等限制。只限制每秒请求数还不够：每秒 5 个超大图片请求，可能比每秒 50 个小表格请求占用更多资源。配额需要接近真实消耗，同时保持规则容易理解。
入口应先检查请求大小、字段和身份，再决定是否进入队列。队列满时，明确返回可重试的限流结果，比无限等待更可控。客户端重试应有次数限制和逐步增加的间隔，否则限流会引发更多请求，形成重试风暴。超时还要区分入口等待、排队和执行阶段。客户端断开连接后，平台应尽可能取消尚未执行的任务，避免无人等待的任务继续占据容量。
隔离有不同强度。逻辑队列便于区分租户，但底层计算资源仍可能共享；独立进程能限制部分故障传播，却不能自动消除共享设备上的竞争；保留独立资源通常更可预测，但空闲时利用率可能偏低。选择时先写出服务承诺，例如重要在线任务需要有最低容量保障，实验任务允许排队。隔离不是开关，必须说明保护的是内存、计算时间、队列位置，还是数据访问。
可观测需要把指标、日志和请求追踪关联起来。指标告诉我们排队时间是否整体升高；日志记录某个请求的租户、版本、输入规模、状态和错误类别；追踪把入口、预处理、等待和执行各阶段串起来。日志不应默认保存完整客户资料或原始文本，可以保存经授权的摘要、长度和字段完整性信息。否则，排查便利会变成额外的数据暴露面。
模型质量也需要观测，但真实标签常常延迟到来。预测流失的客户是否真的流失，可能要过 30 天才能确认。因此，线上先观察输入缺失率、特征分布和预测比例，标签到齐后再计算分组精确率、召回率、F1 和 AUC。输入分布变化只是预警，不能直接证明模型质量下降；模型输出稳定也不能证明质量稳定。对于类别不平衡的数据，还要记录正例占比，避免准确率被大量负例掩盖。
4 动手：设计一次模型灰度发布
现在为客户流失模型设计灰度发布。稳定版本记为 v1，候选版本记为 v2。使用公开银行客户流失数据时，先检查客户标识是否重复，删除只在流失发生后才能知道的字段，并固定训练、验证和测试划分。客户标识通常不作为预测特征，但可以用于分组和实验分流。若公开数据缺少可靠时间字段，就明确这只是静态评估，不能据此声称已经验证未来月份的表现。
在验证集上为 v2 选择决策阈值，例如将概率达到 0.35 的客户列为需要进一步评估的对象。这个数值只是演练选择，不能把降低阈值理解为无条件提升质量：召回率通常会上升，精确率可能下降，后续处理量也会增加。假设冻结后的测试结果为精确率 0.61、召回率 0.70、F1 约 0.65、AUC 0.84，还必须给出样本数、正例数和 v1 的同口径结果，才能判断改善是否有依据。
发布包应包含模型文件、预处理配置、输入与输出约定、依赖版本、评估报告和回退目标。部署 v2 后先做就绪检查与预热，使用包含缺失字段、边界数值和非法输入的少量样例确认行为。非法输入应被明确拒绝，而不是被静默改成看似合理的数值。再用固定请求集合检查实际返回的模型版本，防止流量规则已经改动、实例却仍加载旧文件。
灰度可以从 5% 流量开始。按客户标识的稳定摘要分组，让同 1 位客户在发布阶段持续命中同 1 版本，减少结果来回变化。若没有可用标识，就应说明分流只能按请求进行。影子流量是另 1 种准备方式：复制经过授权的请求给 v2，仅记录比较结果，业务仍采用 v1 的输出。影子运行会增加资源消耗，也不能验证使用 v2 结果后产生的全部业务影响。
为演练设定观察门槛：有效请求错误率低于 1%，第 95 百分位延迟不超过 150 毫秒，队列持续增长时暂停放量。阶段可以安排为 5%、20%、50%、100%，但每阶段必须达到预定的最小请求数并覆盖代表性时段，不能只看固定经过了 10 分钟。服务门槛可以较快判断，质量门槛需要等待标签。标签不足时只允许有限放量，并在发布记录中写出仍未验证的部分。
回退预案要能实际执行：保留 v1 的可用实例与对应预处理，将新请求切回 v1，处理好正在执行的 v2 请求，并记录切换时间。触发回退后检查错误是否停止、队列是否回落、版本比例是否符合预期。回退不会撤销已经被外部流程采用的预测，因此预测结果应带版本和时间，便于后续识别受影响记录。这份演练的成果是可执行的发布单，而不是只有流量百分比的示意图。
5 利用率与租户隔离取舍
资源利用率高，说明资源较少闲置；服务稳定，说明请求在承诺范围内得到处理。两者有关，但不等价。某个图像池持续满负载可能具有很高吞吐，同时让新请求排队数秒。若只奖励平均利用率，平台就可能把所有任务都压进共享池，最终牺牲交互式请求的尾部延迟。第 95 百分位延迟尤其值得关注，因为平均值容易掩盖少量等待很久的请求。
可以把容量分成保障部分与可借用部分。设教学资源池具有 100 个抽象容量单位，重要短文本任务预留 30，图像在线任务预留 30，其余 40 用于共享。容量单位只用于理解预算，落地时应换成经过基准测试的实例数或资源份额。空闲预留容量可以有条件借给离线任务，但要规定收回方式。若借用任务无法及时停止或让出资源，所谓保障仍然可能落空。
划分资源之前，应先按工作负载测量。CIFAR-10 的原始图片尺寸固定，输入服务前若允许任意大小图片，还会增加解码、缩放和内存开销；AG News 文本也要约定最大长度，不能把超长文档当作普通短文本无限接收。限制输入大小既帮助容量规划，也让服务承诺具有明确适用范围。超过约定的请求可以拒绝，或者转入单独的异步任务流程。
共享比例升高，通常有机会减少闲置，但干扰风险取决于任务差异、队列策略和实际设备，不能从比例直接算出真实延迟。下面的滑块只演示在固定教学假设下，预留容量与共享容量如何变化，以及保障是否足够。它不会预测某块加速设备上的毫秒数。理解这种模型边界很重要：用简化模型讨论预算，再用真实流量回放验证性能，结论才有可信的适用条件。
决策时可以准备 2 份报告。成本报告说明使用资源时长、成功处理量和每 1000 个成功请求的分摊成本；稳定性报告说明各租户的限流比例、排队时间和尾部延迟。共享之后若成本下降，但重要租户经常违反延迟目标，就应降低共享程度或调整准入规则。低利用率也不必然意味着浪费，必要的预热与故障余量本来就是服务承诺的成本。
6 常见坑：共享池无噪声隔离
“共享池无噪声隔离”指共享资源池没有有效约束吵闹邻居的机制。它不表示环境安静，而是某个租户的突发负载能够明显干扰其他租户。常见迹象是：平台总体吞吐变化不大，个别租户的延迟却突然升高；模型执行耗时看似正常，排队时间却持续增长；入口错误率不高，客户端已经大量超时。只看全平台平均值，很容易把这类问题漏掉。
第 1 个坑是把队列分开就宣称完成隔离。假设租户甲和租户乙拥有不同队列，但调度器持续从甲取出长任务，乙仍可能等不到计算机会。第 2 个坑是仅限制请求数，不限制输入规模、执行时间和并发数。第 3 个坑是允许队列无限增长，把拒绝请求的问题变成超时问题。队列能缓冲短暂突发，不能创造计算能力，持续过载必须通过扩容、限流或降低接收量解决。
还要警惕把质量问题误判为资源问题。客户流失模型上线后召回率降低，可能是某个特征的含义改变，也可能是新客户群体与训练样本不同。若团队只扩容，延迟会改善，预测依然错误。反过来，客户端超时造成部分请求缺失，也可能让质量统计只覆盖较容易处理的样本。排查时应先确认统计样本是否完整，再分别核对服务阶段耗时、输入约定与延迟标签。
数据泄漏会制造另一种错觉。例如，把客户关闭账户后的状态当作预测特征，离线 AUC 可能很高，线上却没有这个字段。按请求随机划分重复客户，也可能让测试集过于容易。这些问题不能靠灰度流量自动消除。发布前必须核对每个特征在预测时是否已经可得，以及训练与测试是否共享了不该共享的实体。测试集被反复用于选版本时，也失去了独立评估的意义。
修复顺序应从证据出发：先按租户、版本和输入规模拆开观察，确认慢在排队还是执行；再收紧异常负载的大小、并发和队列上限；随后验证短请求的保障容量是否真正生效。更改后既看受保护租户，也看被限制租户，防止把故障转移到另 1 处。处理器底层调度、复杂抢占和设备切分可以后续深入，本课先掌握可解释的队列边界与服务验证方法。
7 案例：大请求饿死短请求
某教学平台同时承载 AG News 短文本分类和图片分类。短文本业务要求用户提交后尽快看到类别，图片业务允许较长等待。最初平台使用共享入口和按到达顺序处理的公共队列。基准测试中，短文本请求每次占用约 10 毫秒，较大的图片任务每次占用约 800 毫秒。这些数值是为了展示排队现象，实际耗时还取决于设备、模型和预处理实现。
某次批量图片提交使 20 个大请求先进入队列，随后到达 100 个短文本请求。用仅有 1 个工作槽的简化模型看，前面的图片任务合计需要约 16 秒，后来的短文本即使执行很快，也必须先等候。若图片请求持续到达，短文本就可能长期得不到及时处理，形成“饿死”的现象。这里没有任何模型计算错误，故障来自请求之间的资源竞争与排队规则。
监控显示，短文本第 95 百分位延迟从演练基线的 80 毫秒升至数秒，但其执行阶段仍约为 10 毫秒；图片租户的并发和输入字节数明显上升。按请求标识抽查追踪，可以看到大部分时间消耗在公共队列。这个证据支持排队干扰，而不是立即断言文本模型变慢。接着检查模型版本和缺失字段比例，排除发布与输入异常同时发生的可能。
团队先给图片请求设置大小与并发上限，再把长短任务分到独立队列，并为短文本保留可用工作容量。单纯将短文本排到前面并不完整，因为图片任务也需要获得有界等待或明确的接收承诺。对于无法在在线时限内完成的图片批量任务，入口返回任务标识，交由异步池处理。业务由此知道应该轮询任务结果，而不是不断重试同步接口。
修复验证采用同 1 组混合负载回放，比较修改前后的短文本尾部延迟、图片完成时间、限流比例和成功吞吐。再测试图片突发、短文本突发与实例暂时不可用的情况，确认保护并非只在理想负载下有效。如果短文本达标但图片持续被拒绝，应公开调整图片服务容量或接收规则，不能只把受保护租户的图表做漂亮。案例的关键是给不同工作负载明确边界，并用分组数据证明边界生效。
8 把推理平台写进运营方案
运营方案首先说明服务对象和决策用途。客户流失概率可以辅助确定人工复核顺序，但不能直接等同于客户一定会离开；新闻分类标签可以辅助整理内容，也应保留低置信度样本的人工处理入口。写清输出会影响什么动作，才能确定精确率与召回率的取舍。若误报带来较高处理成本，就需要关注精确率；若漏报损失更大，则需要同时评估召回率和处理能力。
接着列出模型清单、数据约定与服务等级。每项服务记录负责人、模型与预处理版本、最大输入、同步或异步方式、延迟目标和容量测试条件。还要说明租户能获得多少保障容量、共享容量如何借用、超过配额时返回什么结果。这些内容应能被使用团队读懂，而不是只出现“高可用”“智能调度”等无法验收的词。服务承诺必须能够转换成可检查的指标与操作。
发布治理要区分可以立即判断的服务健康与需要等待的模型质量。灰度阶段可以根据错误率和延迟暂停流量，但流失标签未到齐时，不能宣布召回率已经达标。方案应指定标签来源、回收周期、样本匹配方式与质量统计负责人。若标签仅来自被人工联系的客户，就可能产生选择偏差，不能直接代表所有客户。对缺失标签和延迟标签，应在报告中公开覆盖率。
日常运营还需要可执行的处置规则。例如，排队时间连续超过目标时先检查租户突发和就绪实例，再决定限流或扩容；输入分布发生明显变化时先核对数据管道与特征含义，再评估是否需要重训。每个动作都应有负责人、触发证据和结束条件。报警过多而没有对应动作，只会让团队逐渐忽略告警。常规报告可以同时展示服务稳定性、模型质量、容量与成本，避免只优化单个数字。
最后设计退出与恢复路径。模型下线前确认调用方已迁移，保留必要的版本记录与授权范围内的评估证据；实例故障后明确由哪个资源池承接，容量不足时按什么顺序限流。重要预测应能根据请求标识追溯到版本与输入约定，但无需无限保存原始个人信息。这样写出的方案可以交接、演练和复盘，平台才从“模型能调用”走向“服务能持续负责”。
9 从推理服务平台走向存储系统硬件（H48）
推理服务看起来主要消耗计算资源，但模型启动和结果追溯都依赖存储。工作实例需要读取模型文件和预处理配置，发布系统需要保存版本包，观测系统需要写入指标与日志。若模型加载很慢，即使计算资源已经申请完成，新实例仍不能接收请求。于是扩容时间不仅包含模型计算环境的准备，也包含文件读取、校验与加载，这会影响应该保留多少预热实例。
存储需求至少可以从容量、吞吐和延迟观察。容量说明可以保存多少模型、日志与评估数据；吞吐说明单位时间能传输多少数据；延迟说明某次读写需要等待多久。大型文件顺序读取与大量小记录写入对系统的要求不同，不能只拿 1 个标称速度判断全部业务。发布演练应记录模型文件大小、读取耗时和实例就绪时间，检查同时启动多个实例时是否出现共享读取瓶颈。
缓存可以减少重复加载，但缓存存在不等于版本正确。实例必须确认读取的是指定版本，并校验内容完整性；旧缓存也需要合理回收。日志写入还要考虑故障时的行为：若远端存储短暂不可用，请求是否等待、日志是否暂存、暂存空间满后怎样处理，都应明确。无上限地缓冲日志会挤占服务内存，而静默丢失关键记录又会破坏追溯能力。
存储可靠性同样需要连接到恢复目标。保存了模型文件并不代表能够及时恢复服务，还需要配置、依赖、权限以及实际恢复演练。训练样本、模型包与请求日志的保存周期可以不同，依据用途和数据要求分别制定。对已经结束的灰度发布，应留下足以解释版本选择的指标与配置，避免为了追溯而无差别长期保留全部原始请求。
下一课存储系统硬件（H48）将进一步讨论数据怎样被设备保存、读取，以及性能与可靠性的基本取舍。本课先建立连接：计算池决定模型在哪里执行，存储决定模型与证据如何到达、保留和恢复。遇到扩容缓慢时，要把“申请资源完成”和“服务真正就绪”分开测量。只有知道等待发生在哪个环节，后续学习硬件指标时才有明确的问题可回答。
放进方案里
本项目以公开银行客户流失数据建立表格分类服务，输入包括账户年限、余额、产品数量与活跃状态，输出流失概率、模型版本和请求标识。数据按 70%、15%、15% 划分为训练集、验证集和测试集，重复客户按实体分组；如缺少可靠时间字段，评估结论限于静态样本。预处理仅在训练集拟合，禁止使用预测时不可得的账户关闭信息，并记录正例占比与标签覆盖率。
平台分别设置在线表格池、图像池和短文本池，为重要在线任务保留容量，共享部分允许受限借用。入口校验租户、字段与输入大小，设置请求速率、并发数及队列上限，超限返回明确状态。初始服务目标为有效请求错误率低于 1%、第 95 百分位延迟不超过 150 毫秒，最终容量以约定输入与混合负载实测确定。监控按租户和版本拆分排队、执行、错误与限流指标。
候选模型先完成预热和固定样例检查，再按客户稳定分流，以 5%、20%、50%、100% 分阶段发布。每阶段要求满足最小样本量并覆盖代表性时段，违反服务门槛立即暂停或回退。质量评估报告精确率、召回率、F1 与 AUC，待真实标签到齐后同口径比较；标签不足时限制放量，不提前宣布质量达标。
平台负责人维护发布单、配额与回退操作，模型负责人核查特征、阈值和分组质量，使用团队确认误报与漏报成本。每周联合检查尾部延迟、分布变化、标签覆盖率及每 1000 个成功请求成本。模型包和必要配置按版本保存，恢复演练覆盖模型加载与资源不足情形；日志遵守访问权限和保存周期，以请求标识追溯结果并减少原始个人信息留存。
10 小结：下一步存储系统硬件（H48）
推理平台把模型、输入约定、路由、容量和观测组合成可交付的服务。多模型需要明确版本路由，弹性需要计入预热时间，共享需要配额与隔离，发布需要可执行的停止与回退条件。服务性能和模型质量必须分别测量，再联系起来解释真实体验。
自测时可以回答 3 个问题：为什么每秒请求数相同，租户造成的干扰仍可能不同？为什么 AUC 达标后，灰度发布还需要观察延迟和标签覆盖率？为什么新实例已经启动，却仍不能接收流量？若能用输入规模、排队、阈值、版本与加载过程解释，就已经掌握本课的基本判断方法。接下来进入存储系统硬件（H48），把模型读取、日志保存与故障恢复所依赖的设备基础补齐。