做 AI 模型最费时间的往往不是调参，是把环境跑通：驱动、框架版本、多机调度、实验记录，任何一环卡住都要耗掉一两天。腾讯云 TI 平台这类机器学习平台卖的就是这段时间——它把工程环节打包，让你把注意力放回数据和目标上。但它并不适合所有人，判断标准比功能列表更重要。
平台打包的是工程，不是模型
平台提供的是流程骨架：数据接入、标注、训练任务编排、实验对比、模型仓库、在线服务。它不会替你决定用什么模型、标什么数据、上线给谁用。这三件事定不下来，平台再顺也白搭。
一个常见误解是"上了平台模型效果就会好"。平台影响的是效率与可复现性，效果上限由数据和任务定义决定；同一份数据换平台，指标不会涨，换标注口径才会。
训练前必须定死的四件事
任务定义（输入什么、输出什么、怎么算对）、评估口径（用什么指标、在哪个测试集上算）、数据切分（训练验证测试怎么分，避免同源泄漏）、上线约束（延迟上限、并发量级、可接受的单次成本）。四件事写成一页纸，再开任务。
评估口径最容易含糊。"准确率九成"这句话没有意义，除非说清在什么分布上、什么阈值下、把什么算作正例。口径写进文档，三个月后回看实验记录，才知道当时比的到底是什么。
数据这一关先看分布，再看量
效果不好时，先查分布，再考虑加量。典型问题有三类：类别极不均衡，某一类占绝大多数；标注口径不一致，两个人标同一批数据结论不同；训练数据与线上数据不同源，比如训练用精修图、线上一律手机拍摄。
标注一致性可以用一个笨办法验证：抽一百条让人重标一遍，看两次一致的比例。低于预期就先改标注规范，别急着扩数据——用错的规范标更多数据，只是把错误放大。
部署选型：延迟、并发、成本
离线批处理和在线服务是两套要求。离线看吞吐，可以排队、可以夜里跑；在线看尾延迟，平均值好看没用，要看最慢的那一小部分。同一个模型，两种部署方式的机器规格和费用可能差一个量级。
还有一项常被忽略：冷启动。按量计费的服务在长时间无请求后重新拉起，首次响应明显变慢，对交互式产品是硬伤。选型时问一句"从零到首次响应要多久"，能省掉上线后的很多解释。
| 上线场景 | 部署形态 | 关键指标 | 常见误区 |
|---|---|---|---|
| 离线批量打分 | 定时任务、批量推理 | 吞吐、总耗时 | 按在线规格买机器，闲时全浪费 |
| 实时接口 | 常驻服务、弹性扩缩 | 尾延迟、错误率 | 只看平均延迟，不看长尾 |
| 高频交互 | 常驻加缓存、就近接入 | 首次响应、并发上限 | 忽略冷启动与排队 |
| 私有化交付 | 容器化打包、离线部署 | 环境一致性、升级成本 | 低估现场环境差异 |
四种形态的机器配置没有通用解，能确定的是：把场景先说清楚，再去问报价，比拿着配置单反推用途靠谱。
什么时候不该上平台
三种情况用现成工具更划算：一次性实验，跑完就丢，不需要版本管理和协作；任务简单到调现成接口就够，比如通用文本分类；团队只有一个人，且没有长期维护计划。
反过来，需要多人协作、需要复现三个月前的实验结果、需要通过审计，这三条里任意一条成立，平台的账就算得过来。先判断任务类型再选工具，这套分法在任务类型怎么判断里讲过。
成本容易被低估的三个地方
做预算时单列的三项
- 标注：常常比算力贵，而且返工率高
- 存储与流量：数据集多版本留存，费用随时间涨
- 人力：平台降的是工程门槛，不是算法门槛
把这三项单列进预算，再看机器单价，结论往往不一样。很多团队只按算力做预算，最后超支的部分出在标注和存储上。多人协作时的规范统一，可参考团队配置怎么用；实验记录与版本怎么留，见历史记录怎么管理。
它解决不了什么
平台不解决业务定义。什么算异常、什么算高质量，这些标准要业务方给；给不出来，模型只能学到一个模糊的平均值。平台也不解决长尾：常见样本上表现稳定，罕见样本上照样失效，而长尾往往才是业务真正关心的部分。
还有数据分类与出境这类问题。平台提供工具和配置项，责任仍在使用方；上云前把数据分级做完，比上线后再补要省事得多。
三个容易被问到的细节
能直接用开源模型微调吗？多数平台提供预置框架和镜像，具体支持哪个模型、哪个版本，以官方文档为准，别照着手上的旧截图操作，镜像版本对不上是最常见的报错来源。
训练任务排队很久怎么办？先看申请的规格是否过宽，再考虑把任务拆小、错峰提交，这通常比加预算有效；如果每次都排很久，说明资源规划本身有问题，不是运气问题。
上线后效果下降怎么排查？顺序是：比对线上输入与训练分布、检查预处理是否一致、看阈值有没有被改过，最后才怀疑模型本身。多数"模型退化"最后查出来是上游数据变了。
