从算力调度到推理上线：一站式AI云服务平台实践

1. 一站式AI云服务平台到底解决了什么麻烦

先说个我亲身经历的场景。早几年带一个小团队做图像相关的模型，前期的流程大概是这样的：先找几台带显卡的机器塞进机房角落，装驱动、装容器运行时、配内网源，然后手写一堆脚本把训练任务往机器上丢，谁跑完了自己去捞日志。等到模型要上线，又得重新搭一套推理服务，做反向代理、做健康检查、做监控。整个链条里，真正花在模型本身的时间不到三成，剩下七成全在"搬砖"。后来接触一站式AI云服务平台，最大的感受不是它功能多花哨，而是它把这些重复搬砖的活收拢到了一起。

所谓一站式AI云服务平台，说白了就是把 AI 项目从开发、训练、部署到最终应用这一整条链路所需要的算力、环境、工具、流水线、监控和计费，全部打包在一个云端入口里。你打开浏览器，拿到的是一个已经装好驱动和框架的工作空间；提交训练任务时，调度器会自己去找空闲的卡；模型训完，点几下就能挂成一个带弹性伸缩的在线服务；跑起来之后，显存、延迟、错误率、花了多少钱，都摆在同一个面板上。它解决的核心问题不是"算力不够"，而是"算力和工具之间的缝隙太大"，缝隙里漏掉的都是人力和时间。这篇内容适合三类人看：正在评估要不要上平台的团队负责人、需要天天在平台上跑任务的算法同学，以及被领导安排"研究一下 AI 基础设施"的工程同学。下面我按"它是什么、怎么搭、怎么算、怎么用、怎么排错"的顺序，把这几年的经验摊开讲。

1.1 从"自己攒机器"到"按需租算力"的这笔账

很多团队最初都会算一笔很朴素的账：一张卡多少钱，一台八卡机多少钱，买下来用三年，平均到每天好像比云上便宜。这个算法漏掉了三样东西。第一是闲置率，训练任务不是匀速的，项目初期可能只有一两个人在试，卡在机房里空转，电费和折旧照付；项目冲刺期又不够用，临时采购要等货期。第二是运维隐性成本，驱动版本、CUDA 版本、容器运行时、存储挂载、内网互通，这些都要人盯，一个熟手工程师的年成本往往比几张卡贵。第三是试错成本，你想试一种新的并行策略，结果发现机器之间的互联带宽不够，得重新采购，这个周期是按月算的。

云上按需的模式把这笔账改写成了"用多少付多少"，但真正让它划算的是弹性。我见过一个很典型的用法：平时保留两台常驻机器跑在线服务和数据预处理，遇到大训练任务时临时扩到二十台，跑完立刻释放。按卡时计费的话，一个持续三天的训练任务，成本可能只有常驻方案的三分之一。当然，这里有个前提，就是你的任务必须能被"打断"和"重启"，也就是要有完善的检查点机制。如果没有，弹性对你来说就是一句空话，因为一旦被抢占，几天的训练成果就归零了。

所以判断要不要上一站式平台，第一个问题不是"它香不香"，而是"我的任务有没有做成可中断的形态"。检查点保存频率、数据读取能否随机访问、训练脚本能否从断点恢复，这三点决定了你能不能吃到弹性的红利。

1.2 平台的能力拼图：四层结构缺一不可

把一站式平台拆开看，基本都能对应到四层。资源层是底座的异构算力池，包括不同型号的训练卡、推理卡、CPU 节点，以及配套的高速存储和节点间网络。开发层是给人用的入口，通常是一个带图形界面的工作空间，预装了常见框架和依赖，能直接开终端、开编辑器、跑 Notebook。训练与推理层是干活的引擎，负责任务排队、分布式编排、镜像分发、服务发布、弹性伸缩。运营层是对内的管理面，做多租户隔离、配额、计量计费、审计日志。

这四层里，最容易做表面功夫的是开发层，最容易翻车的是资源层和运营层。我见过一些平台，工作空间做得漂漂亮亮，一点进去就能写代码，但一提交多机任务就卡在镜像拉取上，或者两个人同时用，配额没有隔离，一个人把卡占满另一个人干瞪眼。所以在评估平台时，别只看第一屏的交互，重点问三个问题：镜像分发是怎么做的、配额和隔离做到什么粒度、任务失败后的日志和现场能不能留住。

1.3 哪些团队真的需要它，哪些其实用不上

不是所有团队都该上一站式平台。如果你的项目处在验证阶段，只有一两个人、一两个模型、单卡就能跑完，那么一台按量计费的带卡实例加一份自己写的启动脚本，效率可能比学一套平台还高。平台的价值随着协作人数、任务数量、上线要求三个变量上升。当团队超过五个人、每周要跑几十个任务、模型要对外提供服务时，平台带来的秩序感就开始压过学习成本。

还有一种情况也需要它：合规和审计要求比较严的场景。比如需要记录谁在什么时间用了多少资源、模型版本和训练数据能不能对上、线上服务有没有留操作痕迹。这些在散装环境里靠自觉，在平台里是默认能力。

反过来说，如果你的核心诉求是极致的单机性能调优，比如要把某张卡的利用率压榨到某个极限值，那么通用平台反而可能带来一层抽象损耗，这时候裸金属加自建调度更合适。这不是平台的问题，是场景匹配的问题。

2. 架构拆解：一个能跑通的平台长什么样

理解了它解决什么问题，接下来拆架构。我不打算讲成教科书，而是按"一个任务从提交到上线，中间经过了哪些环节"这条线来捋，这样每个组件为什么存在就很清楚了。

2.1 资源层：异构算力池与调度策略

资源层的核心是把物理机器抽象成可分配的"卡时"。做法通常是先给每台机器装一个轻量的节点代理，定期上报健康状态、显卡型号、显存容量、驱动版本、当前占用情况，控制面汇总成一张全局资源视图。调度的时候，用户提交的任务带着资源声明，比如"需要 4 张同型号卡、64 核 CPU、256G 内存"，调度器去匹配满足条件的节点。

这里的门道在匹配策略。最朴素的是先到先得，谁先提交谁先跑，但这样容易造成大任务饿死。稍微好一点的是按优先级加队列，把在线服务、离线训练、数据处理分成不同队列，给不同权重。再进一步是拓扑感知，多机训练时尽量把任务放在同一台交换机下，减少跨层通信。我们做过一次对比，同样是八机训练，拓扑感知调度和随机调度在通信密集的模型上能差出百分之十几的吞吐。

还有一个容易被忽略的点是碎片治理。八卡机被一个两卡任务占了两张，剩下六张如果凑不成一个完整任务，就浪费了。成熟平台会有碎片整理策略，比如小任务优先填充分散节点，或者设置超时后自动迁移。我自己的经验是，团队里如果小任务特别多，一定要把"最小申请粒度"定下来，否则资源池会碎成一地。

2.2 开发层：镜像、工作空间与依赖治理

开发层看起来简单，其实是矛盾最集中的地方。算法同学想要最新版本的框架，运维同学想要稳定不变的镜像，这两个诉求天然冲突。合理的做法是分层镜像：基础层放驱动和系统依赖，由平台统一维护，不允许用户改动；中间层放框架和常用库，按版本打标签；最上层是用户自己的项目镜像，只装项目特有的依赖。这样既保证了底层稳定，又给了上层自由。

工作空间的形态一般是容器化的远程桌面或者网页版编辑器，背后挂一块持久化存储，关掉再打开，代码和数据还在。这里有个坑要提前说：持久化存储的性能差异极大。同样是挂载一块盘，有的是本地盘，读写快但换节点就没了；有的是网络盘，可靠但延迟高。如果数据集特别大、训练时随机读取频繁，网络盘的延迟会直接把数据加载变成瓶颈，显卡利用率掉到三成以下。解决办法是把数据先同步到本地高速盘，或者用平台提供的数据缓存能力。

依赖治理还有个实操建议：把环境构建当成代码来管。写一份构建文件，锁死版本号，提交到版本库，每次训练任务都从这个文件构建出来的镜像启动。我见过太多"我这里能跑你那里不能跑"的扯皮，追到最后都是某个小版本差异。锁版本这个动作，花十分钟，能省十个小时。

# 一个典型的分层构建示例（仅示意结构） FROM base-runtime:driver-xxx-cuda-xxx RUN pip install --no-cache-dir \ torch==x.y.z \ torchvision==a.b.c \ numpy==p.q.r COPY ./requirements-lock.txt /tmp/ RUN pip install --no-cache-dir -r /tmp/requirements-lock.txt WORKDIR /workspace

2.3 训练与推理层：任务编排和弹性伸缩

训练层的核心是任务抽象。用户不该关心任务跑在哪台机器上，只需要描述"我要跑什么、需要多少资源、数据在哪、产物放哪"。平台负责拉镜像、挂存储、注入环境变量、起进程、收集日志、监控状态、失败重试。分布式训练还要多做一步：把各节点的地址和角色注入进去，保证通信初始化能对上。

这里的关键参数是重试策略。重试次数设太少，一次偶发的节点故障就让几天的任务白跑；设太多，一个有代码 bug 的任务会反复吃掉资源。我的经验是按任务时长分级，短任务重试三次，长任务重试一次但必须强制从最近检查点恢复，并且把重试原因记录下来，方便事后统计节点稳定性。

推理层的重点是弹性。一个在线服务通常包含几个要素：副本数、每副本资源、就绪探针、扩缩容阈值、灰度策略。副本数不是拍脑袋定的，后面第三章会给计算公式。这里先提一个常见误区：很多人只按 CPU 使用率做扩缩容，但推理服务的瓶颈往往在显存和请求队列上，CPU 可能才用了一点点，卡已经打满了。所以扩缩容指标要选对，显存占用率和排队请求数通常比 CPU 更准。

2.4 运营层：计量、配额与多租户隔离

运营层是给管理者用的，但它直接影响每个使用者的体验。配额要能分到团队甚至个人，不然就会出现一个人跑大任务把公共池占满的情况。计量要细到卡时、存储、流量，最好能按项目打标签，这样月底做成本分摊时不用手工算。隔离要保证不同租户之间不互相干扰，至少做到资源配额隔离，强一点的做法是节点级别的物理隔离。

我特别想强调标签体系。从第一天起就要求每个任务、每个服务、每份存储都带上项目标签和负责人标签，这件事的收益会在三个月后显现出来。等到账单出来发现某个项目烧了一半预算，你能立刻定位到是哪个任务、谁提交的、跑了多久，而不是对着一堆数字发呆。

3. 上平台前必须算清的几个参数

选型和用得好不好，差别往往在这几个数上。我把最常被问到的三类计算整理出来，都是可以直接套的。

3.1 显存估算：先算模型，再算卡

显存不够是最高频的报错，而大多数人对它的估算都偏乐观。训练阶段的显存大致由四部分组成：模型权重、梯度、优化器状态、激活值。用混合精度加自适应优化器时，每个参数大约要占 16 到 20 字节。举个例子，一个 70 亿参数的模型，光前三项就要 70 亿乘以 16 字节，约 112G，这还没算激活值。所以想要单卡放下是不现实的，至少要两张 80G 的卡，并且配合切分策略。

推理阶段的账要简单一些，权重按精度折算，半精度就是每参数 2 字节，70 亿参数约 14G。但真正的大头常常是键值缓存，它和序列长度、并发数成正比。粗略估算，缓存占用约等于 2 乘以层数乘以隐藏维度乘以序列长度乘以并发数乘以字节数。序列长度翻倍，缓存就翻倍，这就是为什么长上下文场景下显存消耗会突然爆炸。

阶段	主要显存构成	粗略系数	常见误区
训练	权重、梯度、优化器状态、激活值	每参数 16 到 20 字节起	只算权重，忽略激活值
微调	权重、部分梯度、激活值	每参数 8 到 16 字节	忘记预留临时缓冲区
推理	权重、键值缓存、运行时开销	每参数 2 到 4 字节加缓存	忽略并发带来的缓存增长

实操建议：申请资源时在估算值上再留两成余量，同时把批量大小做成可配置项，先用小批量跑通，再逐步往上加，观察显存曲线，找到拐点。这比一次性拍一个大数字靠谱得多。

3.2 存储与网络：最容易被低估的两项

存储的账要按"数据集 + 检查点 + 镜像 + 日志"四块算。数据集好算，检查点是变量：一个 70 亿参数的模型，一份检查点大约 14G 到 30G，取决于保存精度和是否包含优化器状态。如果你每小时存一次、保留最近五份，那就是上百 G 的常驻占用，再乘以任务数，很容易到几十 T。所以保留策略要提前定，比如保留最近三份加每周一份归档。

网络这块，单机训练基本无感，多机训练就是生死线。节点间通信带宽不够，梯度同步会变成瓶颈，表现是显卡利用率上不去、任务耗时远超预期。选型时要问清楚节点间互联的带宽和延迟，以及是否支持绕过 CPU 的直接内存访问。如果平台不提供这些信息，那基本可以判定它不适合大规模分布式训练。

3.3 成本模型：把闲置率算进去

成本计算不能只看单价。完整的式子大致是：总成本 = 卡时单价 × 卡数 × 时长 × 实际占用系数 + 存储费用 + 出网流量费用。其中实际占用系数是最容易被忽略的，它等于任务真实计算时间除以占用时长。如果任务排队、启动、加载数据花了两小时，实际计算只有六小时，这个系数就是 0.75，你的有效成本要除以它。

我在实际项目里做过统计，优化前的系数大概是 0.6，优化后能到 0.85。提升主要来自三件事：把数据预热到本地盘、缩短镜像拉取时间、让任务从检查点恢复而不是从头跑。这三件事都不难，但对账单的影响是实打实的。另外，闲置资源回收要设规则，比如工作空间连续两小时无操作自动停机，听起来有点烦，但一个几十人的团队，一年省下来的钱足够再买几张卡。

4. 实操：从零把一个模型跑上线

这一章按顺序走一遍完整流程，中间穿插我踩过的坑。假设的场景是一个中等规模的任务，需要四张卡做微调，然后发布成一个在线服务。

4.1 第一步：做一份能复现的环境镜像

别急着写训练代码，先把环境固化下来。推荐的顺序是：先在一个临时工作空间里把依赖装通、把脚本跑通，然后把安装过程整理成构建文件，构建出镜像，再用这个镜像起一个干净的工作空间复跑一遍。这一步的意义在于排除"我本地能跑"的幻觉。我见过太多次，临时空间里因为之前装过某个库所以能跑，换成干净镜像就报找不到符号。

构建文件里要锁三样东西：系统层的基础镜像标签、框架的精确版本、以及所有依赖的锁定清单。构建完成后打个带日期和提交号的标签，比如项目名加日期加短哈希，这样以后回溯的时候能精确对应到某一次代码状态。镜像体积也要控制，装完不必要的包记得清理缓存，镜像小一点，拉取快一点，扩容时冷启动就短一点。

注意：不要在工作空间里直接改平台提供的基础镜像，任何改动都通过构建文件固化，否则下次重建环境时改动就丢了，而且没人记得当时改了什么。

4.2 第二步：提交训练任务并接好数据

任务描述一般是一份声明式配置，说清楚用哪个镜像、要多少资源、数据挂在哪、命令是什么、产物存到哪。下面是个示意结构，字段名各家不同，但骨架基本一致。

job: name: finetune-demo-v3 image: registry.local/demo:20240115-a1b2c3 resources: gpu: 4 gpu_type: same-model cpu: 32 memory: 128Gi mounts: - source: dataset-bucket/demo/train target: /data/train mode: readonly - source: output-bucket/demo/ckpt target: /output mode: readwrite command: > python train.py --data /data/train --out /output --batch-size 8 --save-every 500 restart: max_retries: 2 resume_from_checkpoint: true

几个细节值得展开。数据挂载用只读模式，防止训练脚本误写把原始数据搞坏。产物目录单独挂，方便训练结束后直接做版本归档。保存频率要和任务时长匹配，一小时存一次太密，浪费时间；十小时存一次太疏，一旦中断损失太大。我的经验是按"单次保存耗时不超过总时长的百分之二"来定，比如一次保存要两分钟，那总时长就该在百分钟以上。

提交之后别马上关页面，盯前十分钟。重点看三件事：镜像拉取有没有卡住、数据能不能读到、显卡有没有真正被占上。很多任务失败在这三个环节，越早发现越省事。

4.3 第三步：模型打包与推理服务部署

训练产物一般是一堆权重文件加配置文件，部署前要做两件事：把加载逻辑固化成一个启动脚本，把依赖收敛到一个精简的运行镜像。运行镜像和训练镜像要分开，训练镜像里那些只在训练时用的包没必要带进线上，镜像越小，扩容越快。

服务配置的核心是副本数和资源规格。副本数的估算可以用一个简单式子：副本数 = 峰值每秒请求数 × 平均单请求耗时 ÷ 单副本可承载并发，再向上取整并留一点余量。举例来说，峰值每秒 50 个请求，平均耗时 200 毫秒，那么并发量约等于 10，如果单副本能稳定承载 8 个并发，就需要两个副本。这个算法很粗，但比拍脑袋强，压测之后再修正。

配置项	建议值	说明
就绪探针初始延迟	大于模型加载耗时	设小了会导致服务反复重启
单副本最大并发	压测峰值的七成	留出突发余量
最小副本数	至少 2	避免单点，也方便滚动更新
扩容触发指标	排队请求数或显存占用率	比 CPU 使用率更贴近真实瓶颈

上线顺序建议是先小流量灰度，观察错误率和延迟，再逐步放大。灰度期间重点盯长尾延迟，也就是最慢那百分之一的请求，平均值好看但长尾飙高，说明有请求在排队或者触发了频繁的显存回收，这种情况扩副本比调参有效。

4.4 第四步：压测、灰度与监控

压测要在接近真实的流量形态下做，别只用固定并发打。真实流量有突发、有长请求、有短请求混在一起。我的做法是先用逐步加压找到拐点，也就是延迟开始非线性上升的那个点，然后把线上最大副本数按拐点的七成配置。压测过程中同步记录显存曲线和显卡利用率，如果显存一路涨不回落，多半是有缓存没释放或者请求对象没回收，这种问题上线后会在几小时内暴露成内存溢出。

监控指标我一般固定看这几个：请求量、错误率、延迟分位数、排队长度、单副本显存占用、显卡利用率、重启次数。这七个够用了，再多就是噪音。告警阈值设在压测拐点的八成，并且区分等级，延迟轻微上升发通知，错误率超过阈值直接呼叫。

提示：把每次发布的服务配置和镜像标签记进变更记录，出问题时第一时间能回滚到上一个稳定版本。回滚能力比排查能力更重要，因为线上问题首先要求止血。

5. 常见问题与排查速查

这一章是我这些年攒下来的问题清单，按阶段分类，都是实际遇到过的。

5.1 训练阶段的高频故障

显存溢出排第一。报错信息通常很直白，但原因有五种：批量太大、序列太长、模型比预估大、激活值没释放、多进程各占一份。排查顺序是先降批量确认能不能跑通，再看单步显存峰值，最后检查是否有梯度累积配置错误。有个隐蔽情况是数据里混进了异常长的样本，导致某一步突然爆显存，这种情况要在数据加载环节加长度过滤。

多机通信超时排第二。表现是任务卡住不动，日志停在初始化那一步。常见原因包括节点间网络不通、端口被占、各节点看到的网卡不一致。排查方法是先在节点之间做基础的连通性测试，再确认启动参数里指定的网卡名是否正确。有些环境有多个网卡，默认选中的那个可能不是高速的那个，这个坑非常常见。

数据加载成瓶颈排第三。表现是显卡利用率在三到五成之间反复波动，像锯齿。原因是数据预处理太重或者存储读取太慢。解决办法是把预处理结果缓存成紧凑格式、增加加载进程数、或者把数据预热到本地盘。

现象	可能原因	处理方向
启动即显存溢出	批量或序列过大、模型比预估大	降批量、查模型结构
训练中途显存突增	异常长样本、缓存累积	数据长度过滤、检查缓存释放
卡在初始化	网卡选错、端口冲突、网络不通	核对网卡名、做连通性测试
显卡利用率锯齿	数据加载慢、预处理重	数据缓存、增加加载进程
任务无故中断	节点故障、被抢占、超时	查事件日志、加检查点、调重试

5.2 部署与线上服务的高频故障

冷启动太慢是最影响体验的问题。模型加载要几十秒甚至几分钟，扩容时新副本还没就绪，流量已经压过来了。缓解办法有三个：精简运行镜像、把模型文件放在本地高速盘、预热时先跑一次假请求把缓存建起来。另外把最小副本数设高一点，别等到流量来了才扩。

服务反复重启通常是就绪探针配置不当。探针的初始延迟必须大于模型加载耗时，否则平台认为服务没起来，直接杀掉重启，形成循环。这个错误很低级但特别常见，看日志会发现服务其实加载成功了，只是没来得及响应探针。

延迟长尾飙高一般和排队有关。单副本并发设得太高，请求在进程内排队，平均值还行但尾部很难看。解决办法是降低单副本并发、增加副本数，让排队发生在负载均衡层而不是进程内。还有一个原因是显存回收触发频繁，可以调小单次处理的批量。

5.3 账单与配额相关的坑

忘记关工作空间是头号浪费源。一个带卡的开发环境开着不用，一天下来也是一笔钱。建议设自动停机策略，或者在每天固定时间提醒。检查点保留过多是第二号，几十 T 的存储常年躺着没人看。出网流量容易被忽略，把大文件往外拉的时候注意一下计费规则。

配额方面，最常见的问题是配额申请粒度和实际需求不匹配。申请了十张卡，实际只用两张，别人又申请不到。建议按项目周期动态调整，而不是一次性申请一大笔长期占着。

6. 用了几年之后，我个人的几点体会

第一点，平台是放大器，不是救火队。如果代码本身没有检查点、没有日志规范、没有数据版本管理，上了平台只会把这些混乱放大，因为任务跑得更快、更多，问题暴露得也更密集。所以上平台之前，先把工程习惯补齐，收益会大得多。

第二点，别追求一次配置到位。资源规格、副本数、保存频率这些参数，第一次都是猜的，重要的是有一套观察和修正的机制。我习惯在项目启动时记录一组基线数字，跑一周后对比，把偏差大的项调掉。这个过程比任何选型文档都有用。

第三点，把成本当成一个技术指标来盯。很多人觉得成本是财务的事，其实它和技术决策强相关。同一个任务，数据放对位置、镜像做小一点、检查点策略合理一点，成本能差出三成。技术同学如果能在方案里带上成本估算，说服力会强很多。

最后分享一个很实用的小习惯：给每个任务和每个服务写一行备注，说明它是什么、谁负责、什么时候可以下线。这件事花不了几秒钟，但三个月后你回头看那一屏任务列表时，会感谢当时的自己。平台给的是秩序的基础，真正的秩序还是靠人一点点维护出来的。