Repository navigation
[request path] Keep the frontend server in one region - #152
Merged
Merged
Conversation
This was referenced Oct 28, 2026
micahtyong
force-pushed
the
micah/perf-4b/O0-frontend-region
branch
from
October 28, 2026 21:42
91c7c63 to
229238c
Compare
micahtyong
force-pushed
the
micah/perf-4b/O0-frontend-region
branch
from
October 28, 2026 21:47
229238c to
7194e8b
Compare
micahtyong
force-pushed
the
micah/perf-4b/O0-frontend-region
branch
from
October 28, 2026 21:49
7194e8b to
4fe5c38
Compare
micahtyong
marked this pull request as ready for review
October 28, 2026 21:49
micahtyong
commented
Oct 28, 2026
| ~~~ | ||
|
|
||
| Frontend, region, environment, secret names, and volume names default in `BaseConfig.platform`. `platform.modal.region` defaults to `None`, which leaves GPU placement unpinned (Modal schedules trainers and inference pools in any region); set it only to restrict placement. Set them in the same Python config using dotted overrides: | ||
| Frontend, region, environment, secret names, and volume names default in `BaseConfig.platform`. `platform.modal.region` defaults to `None`, which leaves GPU placement unpinned (Modal schedules trainers and inference pools in any region); set it only to restrict placement. The frontend server, which runs on CPU, is placed in that region, or in `us-east` when it is unset; this never affects where GPUs are scheduled. Set them in the same Python config using dotted overrides: |
Collaborator
Author
There was a problem hiding this comment.
each training request makes about nine round trips from the frontend to Modal's key-value store and function API, and those services are nearest us-east (one round trip is ~25 ms from us-east, 75 ms from us-west, 112 ms from eu-west, 260 ms from ap-southeast). A frontend on another continent therefore adds seconds to every step; the worst case we measured was 57 s per step from ap-southeast against 31 s from us-east.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
micahtyong
force-pushed
the
micah/perf-4b/O0-frontend-region
branch
from
October 28, 2026 21:50
4fe5c38 to
b8d88e0
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Every Tinker call that reaches Spindle passes through the frontend before it reaches a trainer. Along the way the frontend talks to Modal several times. It looks up which trainer owns the model, records the request, and later stores the result where the client can poll for it. Each of those is a round trip to Modal's key-value store or function API, roughly nine per request. Those services are nearest us-east: one round trip takes about 25 ms from us-east, 75 ms from us-west, 112 ms from eu-west and 260 ms from ap-southeast.
The frontend
serveronly asked Modal for a routing region, which steers requests, not a placement region, which decides where the container runs. So Modal was free to start the frontend anywhere, and over one day of testing its containers came up in us-east, us-west, the UK and ap-southeast. A client and a trainer sitting in us-east then paid an intercontinental round trip on every call.This change places the frontend
serverinplatform.modal.regionwhen the recipe sets one, and inus-eastotherwise. Only the frontend is placed. It runs on CPU, so this has no effect on where trainers and samplers are scheduled; those stay unpinned unless the recipe sets a region, as before.E2E results
The workload is a 4B LoRA classifier on 4×H100: each step runs two
forwardcalls on a frozen adapter, oneforward_backwardon the trained adapter, thenoptim_step, one after another, as the stock Tinker SDK client does. Each call carries 128 examples of about 1,631 tokens with 5 candidate labels per position. 16 steady-state steps, client and trainer in us-east."Time outside the trainer" is the client's step time minus the time the trainer spent in forward, backward and optimizer work. It is everything the request path adds.
Before WandB / After WandB
forward/forward_backwardsubmitIn the before run Modal happened to place the frontend in us-west. The worst case we saw was a frontend in ap-southeast: a step took 57 s instead of about 31 s, each submit took 3.6 s, and some 4 MB requests from the frontend to the trainer timed out and were retried.
🤖 Generated with Claude Code