the xla path · 0/15
start the path

the xla path · Multi-controller JAX · lesson 01 of 1

The coordination handshake

Three numbers and an address turn a thousand isolated processes into one program. This lesson is what actually happens when they arrive.

the goal Say what jax.distributed.initialize exchanges and when it must run, keep local and global devices straight, and connect the handshake to the key-value callbacks the PJRT boundary already showed you.

mastery work · this chapter0/2
  1. go →
manual items are your word; auto items complete from your streaks, labs, and can-you ticks · stored in your browser only
§ 01

Three numbers and an address

The chapter above establishes that stock JAX has no coordinator handing out work; every host runs the same script. What it takes to make that safe is one call: jax.distributed.initialize(coordinator_address, num_processes, process_id). One process's address is nominated as the meeting point, every process states how many peers exist, and each names its own index. On Slurm, Kubernetes, or a Cloud TPU deployment the three arguments populate themselves and the call takes none.

The timing rule is strict and the docs state it as a must: initialize runs before jax.devices(), before jax.local_devices(), before any computation touches a device. The handshake is how a process learns the cluster exists; ask about devices earlier and you get a single-process answer that poisons everything after it.

§ 02

What the handshake exchanges

During initialization the processes discover each other and exchange device information, and afterward each one can answer a question it could not answer alone: what does the whole cluster look like? The mechanism underneath is one you have already met. The PJRT boundary lesson read PJRT_Client_Create_Args field by field and found key-value store callbacks, kv_get and kv_put, sitting in the middle of the struct. This handshake is the far side of those callbacks: the coordination service is the store, and a plugin on host three learns what host zero decided by reading keys host zero wrote.

§ 03

Local, global, and the one rule

After the handshake, two device lists coexist and confusing them is the classic multi-host bug. jax.local_devices() is the hardware attached to this process; jax.devices() is every device across every process, and jax.process_index() says which slice of the world is yours. Global operations are written against the global list even though each process only ever touches its local slice.

The rule that keeps a thousand processes from deadlocking is behavioral, not enforced: all processes run the same computation in the same order. A collective is a meeting; if one process compiles a different program or reaches the meeting in a different order, the others wait forever for a participant that is never coming. The chapter's framing holds: isolated except when a collective says otherwise, and the handshake is what makes the collectives able to say it.

before you move on

Check yourself

01 When must jax.distributed.initialize run, and what breaks if it runs late?

Before any device query or computation: jax.devices, jax.local_devices, everything. Run late, the process answers device questions as if it were alone, and the wrong world-view propagates into every placement after it.

02 How does the handshake connect to the PJRT struct you read earlier?

The kv_get and kv_put callbacks in PJRT_Client_Create_Args are wired to the coordination service: the handshake is the store those callbacks read and write, which is how one host learns what another decided.

assigned

Readings