stroblmeandClaude Fable 5
eb2d098d7c
The engine runs where the automations are and the GPU is somewhere else, usually behind a different network — so the worker connects out and the engine answers over the socket it was given. Nothing has to expose Redis, and the same connection works through the tunnel the hosted access will use. What travels is the protocol the local pool already speaks, so a node cannot tell which kind of worker it is on. A node declares device: gpu and device_policy, the label is resolved per call (a worker attaching later needs no rebuild), and a run whose labels nothing carries waits in the queue saying what it waits for rather than failing — submit from the couch, the GPU box picks it up when it is switched on. Two things had to move with it. Compiling now happens on the machine that will run the node: a node importing torch is correct on the GPU box and a missing module on the engine, so checking it here failed nodes that were fine. And the artifact endpoint accepts a worker's own credential, because storing a checkpoint is exactly what that credential is for — and only that. Verified against the real split: the training ran on this host (its checkpoint names the machine and a numpy the engine does not have), streamed 40 metric points back mid-run, and the evaluate node read the checkpoint on the engine. Cancel kills the remote training; pulling the worker fails the run in six seconds instead of waiting out its ten-minute timeout. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AD8SfVhzXBG2nAfFcVh3iD
0 lines
0 B
Python
0 lines
0 B
Python
The file is empty.