Start Free

DYNAMIC ENDPOINT TRANSFER

The destination changes.
The file transfer runs exactly as before.

Where the system that runs the work keeps changing — GPU servers, Kubernetes workloads, Cloud compute — the file transfer does not have to be set up again every time.
Connect the endpoint your existing infrastructure selected to an INNORIX transfer. The real destination can change and the same transfer logic still delivers the files you need.

Dataset StorageObject Storage (S3), training-dataset

  • training-data1.2 TB
  • pretrained-model480 GB
  • image-dataset820 GB
  • auxiliary-data120 GB

4 datasets2.62 TB

Target ConditionThe target is named by condition.

  • GPU
  • Training
  • Ready

Endpoint Selected

GPU-07Seoul | NVIDIA H100
training-dataset.tarCompleted100%

Available EndpointsThe endpoints your infrastructure holds

  • GPU-01Seoul | NVIDIA H100Busy
  • GPU-07Seoul | NVIDIA H100Selected
  • GPU-12US West | NVIDIA A100Ready
  • GPU-24Tokyo | NVIDIA L40SOffline

Selected1Ready1Unavailable2

Same transfer logicAn external scheduler decides which GPU is selected. INNORIX does not allocate GPU resources itself.

DYNAMIC ENDPOINT SELECTION

Instead of a fixed Target,
connect the Endpoint chosen at run time to the Transfer.

Dynamic Endpoint Transfer is not simply a feature for environments with a great many servers. What matters is an environment where the real Target a file has to reach is decided at run time, or keeps changing. In AI Training the GPU Compute to be used can differ on every run, a Kubernetes Workload can run on a new Pod or Node, Cloud Compute is created when it is needed, and Edge Devices connect at different moments.

Where a traditional Transfer fixes a particular IP or Hostname as its Target, Dynamic Endpoint Transfer connects the role and the condition the work calls for — "the GPU Compute that will run this Training", "the Edge Device that is Ready right now" — to a real Endpoint. Your infrastructure decides the actual Endpoint and INNORIX applies that result to the File Transfer, so the Endpoint can change without the work's Transfer Logic being built again.

StaticFixed target

Server B192.168.10.24Fixed target

DynamicSelected at runtime

GPU Compute, ReadyGPU-07Selected

Where it is used

  • AI Training
  • Kubernetes
  • Cloud Compute
  • Edge

ENDPOINT CONDITIONS & GROUPS

Use an Endpoint's role, conditions and Group
to compose a changing infrastructure.

Instead of pinning a transfer to one server’s IP address or name, the endpoint can be named by condition: role, region, workload and status.

Your infrastructure picks the endpoint that matches, and INNORIX delivers the data to it. The machine differs from run to run; the transfer setup does not change.

Target ConditionThe conditions that name the target.

One transfer setting, many targets
  • RoleGPU Compute
  • RegionSeoul
  • WorkloadTraining
  • StatusReady

Available EndpointsSelected by your infrastructure

  • GPU-03Seoul | NVIDIA H100Available
  • GPU-07Seoul | NVIDIA H100Selected
  • GPU-12Tokyo | NVIDIA A100Available
training-dataset.tar3.6 TB, 24,820 filesCompleted100%3.6 TB / 3.6 TB

INFRASTRUCTURE INTEGRATION

Your existing infrastructure decides an Endpoint's state,
and INNORIX carries that decision out as a Transfer.

A Kubernetes scheduler, a GPU scheduler, a cloud orchestrator or an edge manager keeps deciding what runs where. File transfer is connected to it without changing any of that.

Once your system has chosen a Pod, a GPU server or an edge device, INNORIX transfers the files to the endpoint it was handed and returns the progress and the result for the next step.

Transfer integrationThe transfer goes to the endpoint your system selected.

High-Speed TransferResume & RetryVerification

Existing Infrastructure

  • Kubernetes SchedulerSelects the target Pod
  • GPU SchedulerSelects the target GPU node
  • Cloud OrchestratorSelects the compute instance
  • Edge ManagementSelects the target edge device
Transfer Request

Selected Endpoint

pod/training-7bKubernetes Cluster
Namespaceml-training
Nodegpu-node-03
StatusReady
GPUNVIDIA H100
RegionSeoul
training-dataset.tar3.6 TB, 24,820 filesCompleted100%3.6 TB / 3.6 TB
Existing infrastructureINNORIX
Creating and allocating ComputeDelivering files to the selected Endpoint
Placing the WorkloadRunning the transfer
Judging an Endpoint's state and readinessChecking transfer state and recovering
Managing the Device LifecycleReturning the transfer result

INNORIX does not provision Compute or decide Workload Placement.

WORKLOAD LIFECYCLE

In the Workload and Endpoint Lifecycle,
connect the points where Data is needed.

A Cloud VM, a GPU compute node or a Kubernetes Pod is created when the work starts and released when it ends. A transfer built on a fixed server cannot follow that.

INNORIX delivers the dataset once the endpoint is ready, and collects the result data into the storage you named when the job is done. Creating and releasing the server stays with your own infrastructure.

Endpoint lifecycleThe transfer follows the endpoint from creation to release.

GPU-07
  1. 1. CreatedThe endpoint is created.Created
  2. 2. ReadyThe environment for the job is ready.Ready
  3. 3. Data DeliveryThe required data is delivered.Delivered
  4. 4. Job RunThe job runs on the delivered data.Finished
  5. 5. CollectionThe result data is collected back.Collected
  6. 6. ReleasedThe endpoint is released when the job ends.Released
training-dataset.tar3.6 TB, 24,820 filesCompleted100%3.6 TB / 3.6 TB

ORCHESTRATOR & API

Call a Dynamic Transfer
from your existing Orchestrator and API.

Once an Endpoint has been decided in an existing system — Kubernetes, a GPU Scheduler, a Cloud Orchestrator — that system calls INNORIX's transfer capability.

Workflow Logic and Scheduling stay in your existing system, and only the File Transfer is connected as an independent Data Movement Layer. The Endpoint differs on every run while the call and the handling of its result stay the same, so Transfer Capability is added to a Dynamic Infrastructure without your existing Automation being defined again.

OrchestratorKubernetes, GPU Scheduler, Cloud Orchestrator
Callback
INNORIXRuns the transfer
Completed
WorkloadEndpoint Selected

API Interface

InterfaceWhat it does
Create TransferComposes the file and Endpoint relationship
Start TransferRuns the transfer
StatusChecks the current state
ResultChecks the completion result
CallbackHands the completion result to your existing Workflow

UNIFIED OPERATIONS

However much the Endpoint changes,
check every transfer result on one platform.

The GPU or the Compute that runs the work differs every time, and still the transfer jobs and their results need no separate management.

Manage connected machines and transfer Flows in INNORIX Studio, and in Runs check the Endpoint that was actually selected, the transfer's progress and its completion result.

Training Data DeliveryTarget Condition | GPU, Training, Ready

Runs18Succeeded16Resumed2Running0
Run timeSelected EndpointTarget fileSizeProgressResult
2026.10.19 14:32GPU-07Seoul | NVIDIA H100training-dataset.tar3.6 TB100%Succeeded
2026.10.19 09:14GPU-12Tokyo | NVIDIA A100training-dataset.tar3.6 TB100%Succeeded
2026.10.18 22:51GPU-03US West | NVIDIA H100training-dataset.tar3.6 TB100%Succeeded
2026.10.18 18:27GPU-24Seoul | NVIDIA L40Straining-dataset.tar3.6 TB100%Resumed

Faster than an explanation: try it yourself.

Connect the devices and build the distribution flow.

Add flowCancelSave draftSave & active

Flow canvas

Daily · 02:00HQHQ-BUILD-01TOKYO-EDGE-07EdgeTOKYO-EDGE-01OSAKA-EDGE-02NAGOYA-EDGE-03SAPPORO-EDGE-04FUKUOKA-EDGE-05TOKYO-EDGE-06

0 devices · 1 step

Configuration

Start when

NowSchedule

Every day · 02:00

Source

HQ-BUILD-01

Target

Choose target

GET STARTED

Now put it to work in your application.

TECHNICAL FAQ

Frequently asked questions

What is Dynamic Endpoint Transfer?

In an environment where the source or target of a file transfer is not a fixed server but is decided at the moment of execution, it connects the endpoint actually selected to an existing transfer job.

How is it different from ordinary server-to-server file transfer?

Ordinary server-to-server transfer usually fixes the source and the target in advance. Dynamic Endpoint Transfer can apply the endpoint selected at execution time to the same transfer logic.

Does INNORIX select the GPU or the Kubernetes pod itself?

No. Existing infrastructure such as a GPU scheduler, Kubernetes or a cloud orchestrator handles resource placement and endpoint selection. INNORIX delivers the files the selected endpoint needs.

Can it be used when an endpoint's IP address changes?

If the existing infrastructure passes the endpoint information currently valid and that endpoint can connect to INNORIX, it can be set up without naming a fixed IP in the transfer logic.

Can it be used in a Kubernetes environment?

It can be set up to connect the result of Kubernetes workload placement to the actual file transfer endpoint. How pods and nodes are connected, the conditions for running the Agent and the network requirements have to be reviewed per environment.

Can it be used with a GPU compute pool as well?

It can be set up to deliver a dataset to the GPU compute an external scheduler selected and to collect the results or checkpoints produced afterwards.

Who decides the Ready, Busy and Offline states?

The existing infrastructure decides whether a workload can run and how resources are allocated. INNORIX runs the file transfer on the endpoint information and the transfer-ready state it is given.

Every one of these capabilities,on a single platform.

The capability on this page is one of the many file transfer features INNORIX Platform provides. From file transfer to automation and unified operations, try every feature free.

Start Free

Considering transfer to changing Endpoints?

We'll help you review the Dynamic Transfer setup you need across Cloud, Kubernetes, and distributed environments.

  • Review of your Dynamic Infrastructure environment
  • Proposal for an Endpoint and Group connection method
  • Guidance on integrating with your existing Orchestrator

We use these details only to answer your inquiry. See our Privacy policy.