feat: Add per-service instance type support in launcher

[gabrielzpascual]

Description

Motivation

Multi-service training jobs (such as RFT/Storm RL) deploy multiple pods with different compute requirement. GPU-intensive services (training, inference) alongside CPU-only orchestration services (messaging, scheduling, reward computation). Currently, all services are scheduled on the same instance type, forcing expensive GPU instances to be used even for lightweight CPU workloads.

This change adds per-service instance type targeting, enabling deployments where a single job spans multiple instance types within the same cluster. GPU services target GPU nodes while CPU services route to cheaper CPU nodes, reducing cost and improving resource utilization.

Changes

• Added get_instance_types_map() function to build a per-service instance type mapping from config
• Added _get_instance_type_for_service() method to resolve instance type for each service with fallback to default
• Added _build_label_selector_for_instance() method to construct node affinity label selectors per instance type
• Modified _map_resource_config() to set per-service instanceType and labelSelector
• Modified _set_efa_resources() to calculate EFA counts per-service based on their target instance type
• Added per-service labelSelector: null field to RFT helm values (falls back to global when null)
• Updated RFT helm templates to read per-service label selectors
• Added instance_types: null config field to recipes_collection/config.yaml

Testing

Tested on a HyperPod RIG cluster with mixed instance groups:

• GPU IG: ml.p5.48xlarge (training + generation services)
• CPU IG: ml.r6i.32xlarge (orchestration services)

Verified:

• Per-service node affinity correctly routes pods to the intended instance type
• Label selectors include both node.kubernetes.io/instance-type and sagemaker.amazonaws.com/instance-group-type: Restricted
• Fallback behavior works. Services without explicit instance_types entry use the global instance_type default
• Cross-instance-type communication works (NATS messaging, HTTP calls between services on different node types)

Usage:

hyperpod start-job --recipe "fine-tuning/nova/.../RFT/..." \
  --override-parameters '{
    "instance_type": "ml.p5.48xlarge",
    "++instance_types.training": "ml.p5.48xlarge",
    "++instance_types.vllm_generation": "ml.p5.48xlarge",
    "++instance_types.hub": "ml.r6i.32xlarge",
    "++instance_types.prompter": "ml.r6i.32xlarge",
    "++instance_types.rbs": "ml.r6i.32xlarge",
    "++instance_types.nats_server": "ml.r6i.32xlarge",
    "++instance_types.redis": "ml.r6i.32xlarge"
  }'

Merge Checklist

Put an x in the boxes that apply. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your pull request.

General

• I have read the CONTRIBUTING doc
• I have run pre-commit run --all-files on my code. It will check for this configuration.
• I have updated any necessary documentation, including READMEs and API docs (if appropriate)
• I have verified the licenses used in the license-files artifact generated in the Python License Scan CI check. If the license workflow fails, kindly check the licenses used in the artifact.

Tests

• I have run pytest on my code and all unit tests passed.
• I have added tests that prove my fix is effective or that my feature works (if appropriate)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[AshwinS27]

lgtm