一、服务范围按五段拆，逐段问三层

五段的划分方式是按活干的顺序来的。资源与环境是地基，数据与模型准备是原料，训练与调优是加工，上线与推理是出货，运维与支持是贯穿始终的保障。每段都要问三层。第一层是能力提供：给你工具、给你入口，怎么用自己看文档。第二层是指导协助：有问必答、卡住时能一起看，但操作由你完成。第三层是代为实施：对方动手，你验收。三层不是包含关系，很多服务方只在部分环节做到第三层。判断自己需要哪一层，看两件事：团队里有没有人能独立完成这段活，以及这段活出问题时的代价有多大。团队里有人能做、代价可控，第一层就够；没人能做或者代价高，就该争取第三层。逐段对齐三层之后，那份服务清单才有实际意义，否则“支持训练”这四个字可以指任何程度的支持。

二、资源与环境这一段

这一段要问清四件事。第一，给的是加速卡还是整机还是集群：只给卡，网络互联与存储要自己解决；给集群，就要问清卡间互联方式、存储类型与容量、网络带宽。第二，资源是独占还是共享：共享池的优点是随取随用，缺点是峰值时可能排队；独占的资源稳定但要提前预留。第三，运行环境的形态：是提供预置镜像、还是允许自定义镜像、还是只能在其规定的环境里跑。允许自定义镜像是重要的一条，它决定了你能不能用上自己调过的依赖版本。第四，权限粒度：能不能拿到管理权限、能不能装系统级依赖、能不能改网络配置。这四条里前两条影响性能，后两条影响可做的事情范围。还有一个容易被忽略的点：算力配额如何调整、调整需要多久。项目推进中配额往往要变，调整流程长会拖慢节奏，这一条在选型阶段就该问清。

三、数据与模型准备这一段

这一段常被当成“自己的事”，实际它决定了后面顺不顺。通常包含四项。第一项是数据接入：支持哪些来源、单次能搬多大体量、有没有加速通道。第二项是数据治理：去重、清洗、格式转换、质量筛查，这些能不能由服务方提供工具或代为处理。第三项是标注支持：如果需要人工标注，是否提供标注工具与人员渠道，标注质量怎么验。第四项是模型资产的准备：预置了哪些开源模型、能不能把自己已有的权重导入、导入的格式有没有限制。四项里，第一与第四项是硬条件，不满足就卡住；第二与第三项是效率问题，做了能省时间。这一段还有一个常被忽略的环节：数据在训练环境里的可访问方式。是每次拷进去，还是挂在共享存储上直接读，两者的效率差别很大，尤其在多轮实验时会非常明显。问清这一点，比自己摸索要快得多。还有一件小事值得一问：数据版本怎么标记。多轮实验里同一份数据常有多个修订版本，若没有统一的版本标记，两周后就分不清某次结果用的是哪一版，复现时会很被动。

四、训练与调优这一段

这一段的差异在各家之间拉得开，要问清五件事。第一，训练形态覆盖哪些：从零预训练、继续预训练、全量微调、参数高效微调，四种的算力需求与实施难度差别很大，不是每家都能接。第二，分布式能力：支持单机多卡还是多机多卡，并行策略是自动还是需要自己配，扩展效率大概什么程度。第三，调优手段：除了常规微调，有没有偏好对齐、指令构造、领域适配这类方法上的支持，是提供工具还是提供方法论指导。第四，效果衡量：有没有配套的测试集构建、自动打分、人工抽检的流程，能不能给出量化的对比结论。第五，产物交付：训练完给什么，是只给权重，还是连同训练配置、数据版本、评测报告一起交付。第三与第四项颇能区分服务深度：只给算力和框架的，效果好坏要自己判断；能一起定评测口径、一起看结果的，才算真正参与。第五项关系到后续能不能复现，只有权重没有配置与数据版本，半年后很难说清当时是怎么训出来的。另外建议在合作开始前把评测集的所有权与使用方式写清：评测集由服务方一并提供，短期省事，长期容易形成依赖；自建一份不外传的评测集，才能在迭代中守住判断标准。

五、上线与推理这一段

模型训出来只是半成品，上线这一段包含四块内容。第一块是部署形态：单实例、多副本、还是按请求弹性伸缩；不同形态对应的运维复杂度差别很大。第二块是性能调优：量化压缩、批处理合并、缓存复用、推理引擎的算子优化，这些手段能显著影响单卡能服务多少并发，问清是否包含。第三块是发布与灰度：能不能按比例切流、能不能快速回滚、多个版本能否并存。第四块是监控与告警：延迟分位值、错误率、资源占用、以及内容层面的异常，这些指标谁来配、告警发给谁。四块里前两块决定单位成本，后两块决定上线后稳不稳。这一段要提前确认的是责任边界：服务方负责到“服务能正常响应”，还是负责到“业务指标达标”，两者差距很大，多数情况下服务方只能承诺前者，把这一点说清能防止后期扯皮。

六、贯穿全程的运维与支持

这一段不是某个环节，而是全部环节的背景。要问清四件事。第一，支持渠道与响应级别：只有工单，还是有对接人；工作日与节假日的差别；紧急问题怎么升级。第二，交付物里的文档与培训：有没有操作手册、有没有上手培训、有没有常见问题的整理。第三，变更通知：环境升级、接口调整、配额规则变化，是否提前告知。第四，运维分工：集群本身的维护、故障处理、版本升级由谁负责，这一条在自建与托管混合时尤其容易模糊。四件事里响应级别与运维分工要紧，也常在合同里写得笼统。可操作的做法是把它们写成可核对的条目：什么级别的问题、多久首次响应、多久给出处理方案，逐条填清楚。填不出来的条目，实际执行时往往就是“看情况”。

七、哪些事通常不在服务范围内

把边界划清，比把清单列长更省事。通常不在范围内的有五件事。第一件是业务逻辑：模型怎么嵌进业务系统、接口怎么设计、前端怎么展示，这些属于应用侧的工作。第二件是数据合规的主体责任：数据来源是否合法、是否涉及个人信息、跨境是否合规，责任在使用方，服务方通常只提供合规所需的技术手段。第三件是业务指标：模型上线后转化率、满意度这类指标的变化，受产品、运营、数据质量多重影响，服务方一般只承诺技术指标。第四件是内部系统对接：与既有账号体系、审批流程、监控体系的打通，多数要双方配合，不能全交出去。第五件是长期运营的人力：日常的数据更新、效果巡检、版本迭代，需要持续投入，服务方提供的是能力与工具，不是替你常驻。五件事提前讲明，后续合作反而顺；反过来，把边界说得含糊、事后逐项争取，双方都累。还有一个实操建议：把服务范围写成一份交付清单，每一条注明由谁做、交付物是什么、怎么算完成，作为附件跟在合同后面。日后有分歧时，照单核对比口头回忆有效得多。

结语

看服务范围，先把链路切成资源与环境、数据与模型准备、训练与调优、上线与推理、运维与支持五段，每段再问清是只给工具、给工具加指导、还是代为实施。资源与环境问独占与权限，数据段问接入与可访问方式，训练段问形态、分布式、调优手段与效果衡量，上线段问部署形态、性能优化、灰度与监控，运维段问响应级别与分工。边界上记清五件通常不做的事：业务逻辑、数据合规责任、业务指标、内部系统对接、长期运营人力。五段三层加一份边界清单，服务范围就不再是一串含糊的词。