用途：把 pytorch/pytorch 仓库中调用可复用工作流 _linux-build.yml / _linux-test.yml 的工作流（如 test-b200.yml、pull.yml、trunk.yml、tsan.yml、operator_microbenchmark.yml）从 EC2 运行器迁移到 OSDC（即 ARC，EKS 自托管运行器）。_linux-build.yml 与 _linux-test.yml 各含两个作业：build / test 为 EC2 路径，由 !inputs.use-arc 控制；build-osdc / test-osdc 为 OSDC 路径，由 inputs.use-arc 控制，二者靠该输入切换执行通道。此手册不覆盖以原始 ARC 标签加 container: 指令的独立 OSDC 工作流。
模式选择：dial-up 适合已广泛覆盖、希望按标签逐步扩大 OSDC 采用的工作流，参考 test-b200.yml（PR #181544）；100% opt-in 适合始终在 OSDC 上运行的工作流，参考 operator_microbenchmark.yml、attention_op_microbenchmark.yml 的 B200 作业。runner_prefix 与 use-arc 必须成对处理，一个硬编码另一个由 determinator 驱动即为缺陷。
dial-up 迁移步骤：先在调用 _runner-determinator.yml 的 get-label-type 作业中添加 check_experiments: arc,lf，否则 use-arc 恒为 false；再向 _linux-build.yml 调用传入五个输入，包括 runner_prefix、ci-docker-hash（由 determinator 计算，附加到 ghcr.io 镜像标签）、use-arc、python-version、compiler、cuda-version，后三者需与 docker-image-name 对应；接着在 _linux-test.yml 调用中为测试作业添加 needs: get-label-type 并传入 use-arc 及 setup-linux 所需输入；随后删除 OSDC 不适用的 EC2 输入（如 aws-role-to-assume）；最后用 gh workflow run 或打 ciflow/* 标签验证 build-osdc / test-osdc 是否运行。
100% opt-in 步骤：硬编码 runner_prefix 与 use-arc: true，构建作业仍需 needs: get-label-type 以取得 ci-docker-hash，构建与测试作业都要传 use-arc、python-version、compiler、cuda-version，仅构建作业需 ci-docker-hash。
限制与常见问题：缺少 check_experiments 会导致 OSDC 不激活；测试作业缺少 needs: get-label-type 会使 use-arc 为空；构建作业缺少 ci-docker-hash 会拉取未哈希标签，失败表现为容器步骤 manifest unknown；python-version / compiler / cuda-version 与 docker-image-name 不一致会导致构建失败；不应混用两种模式。资料未提供具体收费、价格、平台数量和效果数据。