我前阵子帮一个朋友看他们团队的模型上线方案，六个人的算法组，白板上画了半天，最后卡在一个很朴素的问题上：这套东西到底是自己买卡搭，还是直接用一站式AI云服务平台。他们手里有一个已经在内部验证过的垂类模型，想在下个季度对外提供接口，团队里没人专职做运维，预算也不宽裕。这个场景我这两年遇到过太多次了，不同行业、不同规模的团队，最后都会绕回同一个岔路口。

所谓一站式AI云服务平台，说白了就是把做AI这件事需要的东西——能跑的算力、能用的开发环境、能排队执行的任务调度、能存模型和数据集的地方、能把模型变成接口的服务、以及能看清花了多少钱的账单——打包成一个入口，让你打开浏览器就能开工。它解决的不是"有没有显卡"这种单点问题，而是"从一行实验代码到线上一个能扛住流量的接口"这条链路上，中间那几十个琐碎环节由谁来兜。这篇文章我想把这条链路拆开讲清楚，包括平台内部是怎么拼起来的、实际落地时每一步要注意什么、成本怎么算才不亏、以及我踩过的那些坑。刚接触这块的读者可以当成一份选型与上手的路线图，已经用过一阵子的同行，希望能从成本核算和故障排查那两节里拿走点能直接用的东西。

1. 一站式AI云服务平台到底解决什么问题

1.1 从"攒卡自建"到"按需取用"的账怎么算

自建这套东西的真实成本，远比采购单上的数字复杂。我见过一个典型情况：团队申请预算买了八卡机器，装进机房，配了电和网，前后折腾两个多月才跑通第一轮训练。跑起来之后问题才开始：白天八个人抢八张卡，晚上机器空转没人用，月末一看利用率曲线，平均不到两层。更麻烦的是版本管理，有人用新框架版本，有人要老版本，驱动和算子库互相打架，重装一次环境半天没了，还不一定装得回去。

一站式平台把这部分换成了按需取用。你需要八卡就跑八卡的任务，跑完释放，账单按卡时结算；环境用镜像固化下来，谁跑都是同一套依赖；机器坏了、驱动挂了由平台侧处理，你只需要重新提交任务。这个转变的本质是把"固定资产+人力运维"换成了"运营支出+平台服务费"。划算不划算，取决于你的负载曲线有多陡。负载平稳且长期满载的团队，自建或者长租反而更省钱；负载波动大、处在探索期的团队，弹性带来的价值通常能盖过溢价。

我自己总结的判断标准比较粗暴：如果你的集群平均利用率长期低于五成，或者你的团队里没有一个人愿意在半夜被叫起来处理硬件告警，那就别犹豫，上平台。反过来，如果你的任务已经排到三个月后、卡基本不闲，那自建或者包年包月的性价比会明显更好，平台更适合作为溢出算力的补充。

1.2 它和"租几台带卡的机器"差在哪

这是最容易被混淆的地方。很多团队以为自己需要一站式平台，实际只是需要几台带卡的虚拟机。这两者的差别，用房子打个比方：租GPU机器是毛坯房，水电通了，剩下墙怎么刷、家具怎么摆、物业怎么找，全是你自己的事；一站式平台是精装公寓，拎包入住，但装修风格你改不了太多。

具体差在几个层面。第一是环境一致性，纯机器给你的是操作系统，框架、驱动、算子库的兼容性你自己保证；平台给的是镜像，开发、训练、推理跑的是同一套环境，不会出现"我本地能跑线上报错"这种经典事故。第二是任务调度，纯机器是独占的，一个人占了别人就得等；平台有队列、有优先级、有配额，还支持多机多卡的任务一次性拿到所有资源。第三是模型到服务的最后一公里，纯机器上你得自己写服务框架、自己做健康检查、自己做扩缩容；平台通常提供托管的推理服务，填个模型地址和资源规格就能起一个带负载均衡的接口。

我把这个对比整理成一张表，选型的时候可以直接对着看：

看这张表的时候要留意一点：平台替你兜的部分越多，你能改的部分就越少。如果你的场景需要对内核参数、网络协议栈、特定算子做深度定制，那就得确认平台是否提供裸金属形态，或者能不能挂自定义镜像并保留足够权限。这一点在选型阶段问清楚，比上线之后返工要省事得多。

1.3 什么样的团队该上，什么样的团队可以先等等

适合上的团队有几个共同特征。一是处在验证期，模型方案还没定型，今天试这个结构明天换那个数据集，算力需求忽高忽低。二是团队规模小，没有专职的平台或运维角色，谁有空谁去折腾环境。三是数据敏感，需要做权限隔离和操作审计，自建一套合规体系成本比用平台的现成能力高得多。四是有明显的周期性，比如每月月底跑一次全量训练，其余时间几乎不用卡。

可以先等等的情况也很明确。长期满载的团队，平台溢价会被放大；有成熟机房和运维班子的团队，自建的可控性更高；对底层有强定制需求的团队，比如要改通信库、要特定型号网卡做定制优化，平台的抽象层反而碍事。还有一种情况容易被忽略：如果团队连"要训什么、数据怎么清、评测怎么做"都还没想清楚，那上平台只是把一个模糊的问题变得更贵，这时候更该做的是把数据和小规模实验理清楚。

2. 平台内部是怎么拼起来的

2.1 算力层：训练卡和推理卡为什么要分开

一站式平台的算力池，通常会按用途分成两类。训练侧看重的是显存容量、显存带宽和卡间互联，因为大模型训练是典型的通信密集型负载，梯度同步的量级能到几十 GB 一轮，卡间互联带宽差一个数量级，训练速度就能差出三四成。推理侧看重的是单卡性价比和并发能力，模型加载完基本只读，通信压力小，反而对显存容量和批处理效率更敏感。

分开的理由很实际。训练任务通常会把卡占满，显存吃到九成以上，如果和线上推理混在同一批机器上，一个训练任务启动就可能把推理实例挤到 OOM，线上的请求立刻抖动。我见过一次事故，某团队为了省钱把训练和推理放在同一个资源池，只做了软配额，结果月中一次大规模训练把整个池子吃干净，线上接口响应时间从两百毫秒涨到十几秒。后来他们改成物理隔离，训练池和推理池分开，成本涨了两成，但再没出过这类问题。

训练需要多少显存，有个粗略公式可以估。混合精度加 Adam 优化器的情况下，每个参数大约要占 16 字节：权重两份（一份 FP16 一份 FP32 主权重）约 6 字节，梯度 2 字节，优化器的一阶二阶动量 8 字节。这只是模型状态，激活值、临时缓冲、显存碎片还要额外算，经验上再留 30% 到 50%。所以一个 70 亿参数的模型，光模型状态就要 112 GB 左右，加上激活开销，实际得按 150 GB 以上准备。单卡显存 80 GB 的话，至少要两张卡做分片，工程上一般四卡起步更从容，配合分片策略把优化器状态切开。

推理侧算的是另一笔账。同一个 70 亿模型，FP16 权重约 14 GB，一张大显存的推理卡能放下，剩下的显存用来装 KV 缓存。批大小设 8、上下文长度按 2K 估算，KV 缓存会再吃掉几 GB。如果要做 INT8 量化，显存能压到 7 GB 左右，单卡能塞下更大的批，吞吐能翻倍，但要先验证精度掉多少，别为了省成本把业务指标做崩了。

2.2 调度层：容器、队列和抢占怎么配合

调度是平台最不显眼但最影响体验的一层。现在主流做法是容器加编排系统，镜像负责环境一致，编排系统负责把卡分配给任务。这里有几个细节，选型时值得专门问。

第一个是整体调度。多机多卡任务必须保证所有参与副本同时拿到资源，否则先起来的副本会一直等，等到超时全部失败。有些平台的调度器不保证这一点，小任务跑得好好的，一上八卡就反复失败，排查半天发现是资源碎片导致的分配不齐。第二个是优先级和配额。生产任务、实验任务、离线批处理应该分属不同优先级，生产任务能抢占实验任务的资源，实验任务被打断后从检查点恢复。第三个是抢占的配套，可中断资源便宜不少，但前提是你的任务真的能从检查点恢复，这一条得自己验证过才算数。

还有一个容易忽略的配置是共享内存。容器的 /dev/shm 默认只有 64 MB，数据加载进程一多就会报错，报错信息还特别不直观，通常表现为进程莫名退出或者卡死。解决办法是在任务描述里显式指定共享内存大小，一般给到内存规格的三分之一到二分之一。这个坑我踩过一次，排查了整整一个下午，最后发现是共享内存不够。

2.3 平台层：从实验记录到线上接口的闭环

再往上是平台层，也是"一站式"这个词真正的落点。这一层通常包含几块：交互式开发环境、任务提交入口、实验记录、模型仓库、推理服务、监控与计费。单看每一块都不稀奇，价值在于它们之间的数据是打通的。

举个例子。你在开发环境里调通了一个训练脚本，提交成任务跑完，指标曲线自动记到实验记录里；产出的模型文件注册到模型仓库，带上这次训练用的数据版本、代码提交号、超参数；上线时从模型仓库选一个版本，配置资源规格，平台自动拉起推理实例并挂上流量。半年后线上指标掉了，你能顺着这条链一路回溯到是哪次数据更新、哪次代码改动引入的。这套血缘关系在自建方案里要花不少工夫搭，而且经常是出了问题才想起来补。

我特别看重实验记录这一块。团队规模一上去，最大的浪费不是算力，是"这个参数组合上次是不是试过了"这种重复劳动。有记录和没记录，同样一批实验能差出一半的卡时。

3. 实操：把一个小模型从开发推到线上

这一节我把流程走一遍，用一个七亿参数级别的模型做例子，规模不大，但该有的环节一个不少。这些步骤在不同平台上的具体命令会不一样，思路是通用的。

3.1 镜像构建：把环境一次性钉死

第一步是准备镜像。原则很简单：所有依赖都在镜像里，运行时不装任何东西。我见过太多团队在启动脚本里写一堆安装命令，每次启动花五分钟装包，还时不时因为源不稳定导致任务起不来。更糟的是，同样的代码今天和明天跑出的结果对不上，因为装到的依赖版本变了。

镜像要分层，把变化频率低的放前面。基础镜像用平台提供的框架镜像，先装系统级依赖和固定版本的框架，再装项目依赖，最后拷代码。这样改代码只需要重建最后一层，推送和拉取都很快。镜像体积也要控制，太大的镜像会拖慢扩容速度，弹性伸缩时新实例起不来，直接影响可用性。

FROM ai-framework-base:2.4-cuda12 # 系统依赖，变更频率最低 RUN apt-get update && apt-get install -y --no-install-recommends \ libgl1 libglib2.0-0 && rm -rf /var/lib/apt/lists/* # 项目依赖，锁定版本 COPY requirements.txt /tmp/requirements.txt RUN pip install --no-cache-dir -r /tmp/requirements.txt # 代码放最后，改代码只重建这一层 COPY . /workspace/app WORKDIR /workspace/app ENV PYTHONUNBUFFERED=1

依赖清单要写死版本号，别用范围约束。这不是洁癖，是可复现性的底线。另外记得配内部软件源，公网源在拉几百个包的时候经常超时，一超时整个构建就废了。

3.2 训练任务提交：检查点策略怎么定

任务提交用声明式配置，指定镜像、启动命令、资源规格、数据挂载、检查点目录。多机多卡的任务还要指定副本数和通信端口。下面是一个简化后的配置骨架，字段名各平台不同，结构大同小异：

name: train-7b-sft-v3 image: registry.local/nlp/train:20240612 command: - torchrun - --nproc_per_node=8 - --nnodes=2 - train.py - --config=/workspace/app/config/sft_v3.yaml resources: replicas: 2 gpu_per_replica: 8 cpu: 64 memory: 512Gi shared_memory: 128Gi mounts: - name: dataset path: /data/sft-v3 read_only: true - name: checkpoint path: /ckpt/train-7b-sft-v3 env: NCCL_DEBUG: WARN OMP_NUM_THREADS: "8"

检查点频率是这里最需要算的一个参数。定得太稀，一次故障白跑几小时；定得太密，写盘开销吃掉训练时间。算法是这样的：先估故障间隔。假设单卡的日均故障率是千分之五，100 卡的集群一天期望故障 0.5 次，平均两千秒左右就会有一次中断。再看写一次检查点要多久，70 亿参数的模型存一份大约 14 GB，共享存储写入带宽按 1 GB/s 算，写一次 14 秒。如果每 10 分钟存一次，开销占比是 14/600，约 2.3%，完全可以接受；每 30 分钟存一次，开销降到 0.8%，但平均要白跑 15 分钟。折中下来，10 到 15 分钟一次是比较舒服的区间。

还有两个细节值得做。一是只保留最近若干个检查点和关键节点的检查点，不然存储费用会悄悄涨上去。二是用异步写入，训练进程把状态丢给后台线程，不阻塞下一步计算，代价是需要额外一份内存做缓冲。

3.3 模型导出与量化：先测精度再谈省钱

训练完的模型不能直接上线，通常要做格式转换。训练框架的检查点包含优化器状态，体积是推理需要的三倍左右，先导出成纯权重的格式，体积立刻降下来。再往下如果要做量化，INT8 能把显存和带宽需求砍掉一半，吞吐提升明显，但一定要先跑精度评测。

我的做法是准备一个小规模的评测集，覆盖业务里最典型的几百条输入，量化前后各跑一遍，对比关键指标。如果指标掉在可接受范围内，再上量化；如果掉得厉害，试试只量化部分层，或者换更温和的方案。这里有个经验：分类和检索类任务对量化比较宽容，生成类任务对数值精度更敏感，尤其是长文本生成，量化后的退化往往在几百个 token 之后才显现，短样本评测是测不出来的。

3.4 灰度发布与压测：别让上线变成赌博

推理服务上线，我的习惯是先起一个小规格的实例组，挂百分之一的流量跑一天，看延迟分布和错误率，没问题再逐步放量到百分之五、百分之二十、全量。每一步之间至少观察几个小时，覆盖业务的高峰时段。

压测要单独做，别指望灰度期间的线上流量能压出问题。方法是阶梯加压，从每秒十个请求开始，每两分钟翻一倍，一直压到延迟明显劣化或者错误率上升，那个拐点就是这套配置的容量上限。压测时重点看三个数：P99 延迟、每秒处理的请求数、显存占用曲线。如果显存随请求量线性上涨且不回落，多半是有缓存没释放，跑久了会 OOM。

import time, statistics, concurrent.futures as cf def one_call(client, payload): t0 = time.perf_counter() resp = client.invoke(payload) return time.perf_counter() - t0, resp def ladder(client, base_qps=10, steps=5, duration=120): for i in range(steps): qps = base_qps * (2 ** i) interval = 1.0 / qps latencies, errors = [], 0 end = time.time() + duration with cf.ThreadPoolExecutor(max_workers=64) as pool: futures = [] while time.time() < end: futures.append(pool.submit(one_call, client, sample_payload())) time.sleep(interval) for f in cf.as_completed(futures): try: lat, _ = f.result() latencies.append(lat) except Exception: errors += 1 latencies.sort() p99 = latencies[int(len(latencies) * 0.99)] if latencies else 0 print(f"qps={qps} p99={p99:.3f}s errors={errors}/{len(futures)}")

健康检查的配置也有讲究。就绪探针必须在模型加载完成后才返回成功，否则流量会打到还没准备好的实例上，表现就是发布期间零星超时。存活探针的阈值要放宽，模型加载动辄几十秒，探针设得太激进会导致实例被反复重启，永远起不来。这两个参数看着不起眼，我见过至少三个团队在这里栽跟头。

4. 算力成本怎么算才不亏

4.1 卡时之外，还有哪些账要算

很多人算成本只算卡时单价，实际账单里卡时通常只占六七成。剩下的部分包括存储、网络出口流量、镜像仓库、日志和监控的留存，以及可能的服务费。这些项目单项看着不多，加起来能把预算顶穿。

存储是大头。训练用的数据集、检查点、模型文件、日志，全都占空间。一个中等规模的团队，数据集几个 TB，检查点如果保留策略没做好，一个月能滚出几十 TB。分层存储能省不少：正在用的数据集放高性能存储，检查点放对象存储，历史版本转归档。三者的单价能差三到五倍，同一份数据放错地方，一年的费用能差出几万块。

网络出口流量容易被完全忽略。模型权重动辄几个 GB，如果每次都从公网拉，流量费会很吓人。正确的做法是把模型和数据集放在平台内部，服务和训练任务通过内网访问，只有对外提供的接口响应走公网。跨区域的数据传输也要留意，尽量让计算和存储待在同一个区域。

4.2 利用率才是决定单价的那个变量

名义单价没有意义，有效单价才有。算法是：月度总费用除以有效卡时。有效卡时的定义要严格一点，只算真正在跑计算的时间，排队、启动、加载数据、空转都不算。

我拿一个具体场景算过。八卡机器按每月 5760 卡时计，假设单卡每小时二十元量级，满负荷跑是一个数。但如果平均利用率只有三成，有效单价立刻变成三倍多，这时候平台上按需的价格优势就完全消失了。反过来，如果你的任务能填满空隙，比如白天跑推理、夜里跑训练，或者用可中断资源跑离线批处理，有效单价能压得很低。

所以我的建议是两件事。一是把任务按重要性分层，生产任务用常规资源，实验和批处理用可中断资源，后者通常能便宜一半以上。二是给每个项目设配额和告警，超了要么申请要么停，别让一个跑飞的实验悄悄吃掉整个月的预算。我见过一次，某个脚本里的循环参数写错，一晚上起了两百个任务，第二天账单出来大家都沉默了。

4.3 弹性策略：什么时候该缩，什么时候不能缩

弹性伸缩听起来很美，用不好会反噬。扩容慢是常见问题，新实例从调度到能接流量，要经历拉镜像、加载模型、预热，快的几十秒，慢的几分钟。如果业务流量爬升很快，等自动扩容反应过来，请求已经超时一片了。这种情况要配预留的最小副本数，让基础容量常驻。

缩容更要谨慎。缩得太快，刚释放的容量马上又不够用，来回震荡；缩得太慢，白花冤枉钱。我的经验是给缩容加一个冷却窗口，比如连续十分钟负载低于阈值才缩，并且一次只缩一个实例。业务有明确日周期的，用定时伸缩比指标伸缩更靠谱，早上八点扩、晚上十点缩，比根据 CPU 利用率猜要准得多。

5. 常见问题与排查技巧实录

5.1 训练侧的高频故障速查

训练任务出问题，排查顺序建议从显存往下走。下面这张表是我这些年攒下来的，覆盖了绝大多数情况：

数据加载这块值得单独说。很多人看到卡利用率只有三成，第一反应是模型或框架有问题，实际上十有八九是数据管道堵了。判断方法很简单，临时把输入换成随机生成的张量，如果速度立刻上去了，那就是数据侧的问题。常见的解法包括把图片或音频预先解码成二进制数组存起来、增加加载进程数、开启预取、把数据集放到本地高速盘。我做过一次优化，把在线解码改成离线预处理加顺序读取，训练速度直接翻了一倍多。

5.2 推理侧的问题往往更隐蔽

推理的问题不像训练那样一报错就停，它常常是慢慢劣化，等你发现时用户已经在抱怨了。几种典型情况。

首请求特别慢。这是冷启动导致的，实例刚起来，模型还没进显存，第一个请求要等加载完。解决办法是配就绪探针，加载完才接流量，同时保留最小副本数，别让它缩到零。

P99 延迟抖动大。通常是批处理策略的问题，动态批处理为了凑大批会等一小段时间，短请求被长请求拖累。可以给等待时间设上限，或者按请求特征分队列。

显存缓慢上涨。多半是缓存没设上限，或者长上下文请求把 KV 缓存撑爆了。给缓存设一个容量上限，超了走淘汰策略，同时限制单请求的最大长度。

实例反复重启。先看是不是被 OOM 杀了，再看存活探针是不是设得太严。我遇到过一次，探针超时设成两秒，模型加载要四十秒，结果实例刚起就被判死，无限循环。把初始延迟调大就好了。

5.3 选型与验收阶段该问清楚的几件事

最后这部分是我自己踩坑总结出来的清单，签合同之前逐条问一遍，能省掉后面很多麻烦。

算力真实性要确认。问清楚是整卡还是切分卡，切分比例是多少，有没有超卖。有些方案宣传的卡数很好看，实际单卡的算力只有标称的一小部分，跑起来才发现不对。

网络规格要确认。多机训练对网络要求高，问清楚机间带宽、是否支持高速互联、跨机柜的延迟情况。这一条直接决定你的多机扩展效率。

存储要确认是不是共享的、带宽多少。训练时几十个进程同时读数据集，存储带宽不够就会拖死整个任务。

数据和模型的迁移成本要确认。你的数据能不能导出去，模型能不能拿走，导出有没有额外费用。这一条关系到长期锁定风险，容易被忽略。

服务的可用性口径要确认。是按分钟算还是按请求数算，故障赔偿怎么触发，有没有免责条款。不同平台的统计口径差别很大，同样的数字实际含义可能差好几倍。

我自己在实际操作中的一个体会是，上线前一定要做一次至少二十四小时的长稳测试。短时间的压测看不出内存泄漏、连接泄漏、日志打满磁盘这类问题，而这些恰恰是线上事故的高发区。还有一条，别在周五下午发布，这是我用两次周末加班换来的教训。真要发布，选周一或周二上午，出问题还有一整个工作日可以处理。

如果你想在现有基础上再往前走一步，我建议把评测环节做成常态化的自动化流程：每次模型更新自动跑一遍固定评测集，指标不达标就阻断发布。这件事前期投入大概两三天，但能把"这次改动到底有没有变差"这种争论彻底消灭掉，长期看非常值。