Skip to content

docs(sc): explain generation fault tolerance, with a support matrix - #3841

Open
terrykong wants to merge 2 commits into
feat/sc-resiliency-04-restart-readmissionfrom
docs/sc-fault-tolerance
Open

docs(sc): explain generation fault tolerance, with a support matrix#3841
terrykong wants to merge 2 commits into
feat/sc-resiliency-04-restart-readmissionfrom
docs/sc-fault-tolerance

Conversation

@terrykong

Copy link
Copy Markdown
Collaborator

Adds a guide for the generation fault-tolerance feature this stack builds. Based on part 4 so it can describe the finished thing, restart and re-admission included.

It is deliberately short. Two pictures and a table do most of the work.

What is in it

  • The support matrix, first. Two weight-sync transports can recover a lost shard, one generation backend is supported, and trainer ranks are never excluded. Those limits are the first thing someone enabling this needs, and today they can only be learned by reading the code.
  • Who watches what — a mermaid diagram of the ledger: who writes it (the probe loop, failed requests) and who reads it (shard selection, the refit). Plus the two facts that surprise people: is_alive() is answered by the Ray actor so it cannot see a wedged engine, and SUSPECT still takes part in a refit.
  • A grid of shard state × refit outcome. The outcome turns on when the shard was noticed rather than on how badly it failed, which is the part that is hard to hold in your head. It also says plainly where the wedged-engine case ends the run on nccl_reshard, and why.
  • The config block, with a note on why refit_timeout_s is what makes recovery possible at all when a shard fails during a refit.

Checked against this branch rather than written from memory: every default in the config block, the two frozensets that define the serving and absent state sets, which synchronizers override reconcile_communicator, and which generation backends implement attach_fleet_health.

docs/index.md is updated in both places — the card grid and the toctree.

Happy to move it under design-docs/ if you would rather it sat there, or to cut it further.

Adds docs/guides/single-controller-fault-tolerance.md. Leads with what is and
is not supported -- two transports, one generation backend, and no trainer
recovery -- because those limits are the first thing someone enabling this
needs, and today they can only be recovered by reading the code.

The rest is two pictures and a table: who writes and reads the fleet ledger,
and what happens for each combination of shard state and refit outcome. The
grid is the part that is hard to hold in your head, because the outcome turns
on when the shard was noticed rather than on how badly it failed.

Calls out the two things that surprise people: is_alive() is answered by the
Ray actor and cannot see a wedged engine, and SUSPECT still takes part in a
refit. Both are deliberate, and both explain rows in the grid.

Signed-off-by: Terry Kong <terryk@nvidia.com>
@terrykong
terrykong requested a review from a team as a code owner August 26, 2026 07:20
@copy-pr-bot

copy-pr-bot Bot commented Aug 26, 2026

Copy link
Copy Markdown

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

@github-actions github-actions Bot added the Documentation Improvements or additions to documentation label Aug 26, 2026
Three changes from review feedback.

Moved to design-docs/, which is where the rest of the refit and generation
internals live.

Replaced the two mermaid blocks with rendered PNGs. Mermaid laid the ledger
out in a way that did not show what was actually being said -- which boxes are
states, which are callers, and which direction the arrows mean. The figures
are drawn to the same light palette the docs use, and the state list gained
RETIRED, which the mermaid version had left out along with its half of
absent_shards().

Added an outcome marker to every row of the failure table, so the shape of the
answer is visible before the reasoning is read: continues, recovers, depends
on transport, or the run ends.

Signed-off-by: Terry Kong <terryk@nvidia.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Documentation Improvements or additions to documentation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant