一、先分清接入的是资源还是服务

接入这件事，两种含义常被混着讲。第一种是资源纳管：把自己的机器、加速卡、存储登记到统一调度侧，由调度侧按需分配，资源的运行状态对调度侧可见。第二种是服务接入：不交出资源的分配权，只把能力以接口的形式对外提供，外部按约定调用，用量按次计量。两者的差别在于控制权与责任边界：前者调度侧能决定任务落在哪，后者资源方自己决定，只承诺服务能力。多数单位的起步形态是第二种，因为它改动小、风险低，不需要把内部调度交出去；等协作稳定、互信建立，再逐步把部分资源转为第一种。判断自己该走哪条，看两个问题：愿不愿意让外部调度决定自己机器上跑什么，以及能不能保证对外承诺的响应时间。这两个问题的答案往往不一致，前一个关乎管理权限，后一个关乎技术能力，任何一个答不了就先别急着交控制权。

二、存量集群的四种形态

第一种是有成熟调度系统的集群：任务已经由内部调度排队分配，节点、队列、配额都有管理。这类集群的对接重点是“接调度而不是接机器”——在调度侧开放一层对外接口，把资源容量、队列状态、任务提交与状态查询对上，防止绕过调度直接占用节点，否则内部配额就形同虚设。第二种是裸机池：一批物理机按人分配、长期占用，没有统一调度。这类要先把机器池化，装一层基础调度，再对外提供，否则资源状态说不清。第三种是容器集群：已有一套编排系统在跑，对接相对省事，只需把集群的凭证、命名空间、配额与外部调度打通，注意租户隔离要提前设计，别让外部任务进到内部业务的命名空间里。第四种是小型集群或单机：几台机器、一两个项目组在用。这类不必硬性纳管，按服务接入的方式对外提供接口更实际，等规模上去再谈资源层对接。四种形态里，第一种与第三种是主流，第二种改造量偏大，第四种则容易被高估难度。

三、接入前的三件准备

第一件是资源画像。要把自己的资源说清楚：多少张加速卡、什么档位的显存、卡间互联方式、可用存储的类型与容量、能承受的任务类型（训练、微调、推理、批处理）、以及在保证内部业务前提下的对外可让出比例。这份画像不是宣传材料，而是调度侧用来做匹配的依据，写得含糊，后续匹配就会失真——比如只写“有若干张卡”而不写显存与互联，外部把大模型训练任务派过来，跑不动还要退回，双方都白耗时间。第二件是账号与租户。要决定外部任务以什么身份进来、在哪个隔离范围内运行、能用哪些数据、能写到哪些目录。租户划分一旦定下，后续所有配额、计费、审计都挂在它上面，改起来很麻烦，宁可在准备阶段多花两天。第三件是计量口径。按什么计量：卡时、任务时长、还是有效计算步数；从什么时刻开始算、排队时间算不算、失败重跑算谁的。口径不统一，账单一定会吵架，而且是在业务已经跑起来之后吵，处理成本很高。

四、技术对接的四层

第一层是注册与发现。把资源或服务登记上去，让调度侧知道有这么一个资源池、它在哪里、能力如何、当前状态怎样。关键是状态的实时性：登记一次就不再更新，调度侧看到的是过期信息，会把任务派给已经跑满的资源。第二层是调度接口。任务提交、状态查询、取消、日志取回，这几个动作要能通过接口完成，语义与内部调度保持一致；若两侧的语义对不上，比如对“排队中”的定义不同，就会出现外部以为在跑、内部还在排的情况。第三层是监控与计量。资源使用率、任务耗时、成功与失败，这些数据要能按租户维度归集，既供调度侧做决策，也供双方对账。第四层是身份与权限。统一认证、按角色授权、操作留痕，这三件事在企业环境里是硬要求，尤其当外部多个单位共用一套体系时，谁能看谁的日志、谁能取消谁的任务，必须事先写清。四层里第一与第二层决定能不能跑起来，第三与第四层决定跑起来之后能不能管得住。

五、任务跨域的四道坎

资源接上了，任务真跑起来还会遇到四件事。第一件是数据在哪。任务被派到远端资源上，数据却在本地，要么先搬过去，要么让远端能访问本地存储。前者的成本是传输时间与费用，后者的成本是网络打通与安全策略，两条路都要提前规划，不能等任务报错再想。第二件是镜像在哪。运行环境以镜像形式交付时，远端拉取镜像的速度直接决定启动时间，常见的做法是在远端做镜像缓存，只同步差异层。第三件是网络路径。跨域访问要确认带宽、时延与是否经过受限区域，长距离链路对分布式训练的卡间同步影响很大，跨域做多机训练通常不划算，把这类任务留在同域、把单机任务外派更实际。跨域调度真正适合的，是数据量不大、能中断续跑的任务，判断标准只有一条：中断之后重来的代价高不高。第四件是结果回传。产物落在远端存储再取回，比跑完直接丢弃要可靠；还要约定保留期，防止任务结束几天后想复现时发现产物已被清理。四道坎里，第一与第三件决定能不能跑，第二与第四件决定跑得顺不顺。

六、分批接入的次序

不建议一次把全部资源接进去，按三步走风险小。第一步，选一个非关键资源池做试点：规模小、内部依赖少、出问题不影响业务。这一步的目标不是产出，而是把四层对接与四道坎全部走一遍，把发现的问题记成清单。第二步，接入一个真实业务的资源池，同时保留原有的使用方式，做一段并行运行：同一批任务既能在原路径跑，也能通过调度侧跑，比较两边的耗时、成功率与账目是否一致。并行期的价值在于有对照，出问题时能判断是新路径引入的还是原本就有。第三步，逐步扩大接入范围，每扩一批，都按同一份清单核对一遍，别因为前面顺利就跳过核对。全过程中都要留回退路径：外部调度侧出现故障时，内部业务能不能照旧运行，这是接入设计里必须回答的问题，也是很多单位事后才补的一课。

七、上线之后的运营

接入完成只是开始，之后有几件事要常态化。第一件是配额与优先级：外部任务与内部任务抢资源时谁优先，要有明确规则，并在调度配置里体现，而不是靠临时沟通。第二件是结算：按约定的计量口径出账，账单要能拆到租户与任务，双方各自有据可查；出现差异时，能定位到具体哪条任务。第三件是服务承诺：对外承诺的响应时间、可用性、故障恢复时长，要写成可核对的条目，并定期回看达成情况。第四件是异常处理：任务卡住、节点故障、网络中断，各类情形怎么发现、通知谁、多久处理，写成流程，比每次临时协调高效。第五件是定期复核资源画像：硬件增减、存储扩容、互联升级之后要更新登记信息，否则调度侧的判断会一直基于旧数据。五件事里前两件常在运行三个月后暴露问题，后三件决定了这套协作能不能长期维持下去。

结语

接入的核心是把四件事对齐：资源描述写清楚、调度入口对上、用量账目核得清、身份权限打通。先分清是资源纳管还是服务接入，再按存量集群的形态选路径：有调度系统的接调度、裸机池先池化、容器集群注意租户隔离、小集群按服务接入。技术层做注册与发现、调度接口、监控计量、身份权限四层，任务跨域时解决数据、镜像、网络、结果回传四道坎。分批接入、保留回退、上线后把配额、结算、承诺、异常、画像五件事常态化，这条路径才走得稳。