Required files

Dataset manifest

[{
  "id": "chunk-001",
  "fileName": "training-001.bin",
  "bytes": 4096,
  "sha256": "REPLACE_WITH_REAL_64_CHARACTER_SHA256",
  "format": "MODEL_SUPPORTED_FORMAT",
  "exampleCount": 128
}]

Replace the sample values with the actual file metadata. File names, byte sizes, and SHA-256 checksums must match. Obtain example counts and format identifiers from your model's data preparation tools.

Preparation

1. Obtain a compatible model and its data preparation instructions.
2. For dataset jobs, prepare self-contained chunks and a matching manifest. For RL, use the experience model package described below.
3. Reserve separate validation examples if the model supports evaluation.
4. Select all files in the workspace, configure settings, and create the job.
5. Start with a small dataset before committing to a longer run.

Devices and participants

The site origin must be registered with Weei and training must be available to the user. Keep the coordinator's browser open for distributing data, collecting results, and saving checkpoints. Other participants must accept invitations before receiving model and data files.

Training chunks are processed on participant devices. Share data only with appropriate participants. Save important checkpoints outside browser storage.

CPU and GPU files

WASM is required for every job. Add the model package’s WGSL shader archive to allow GPU training. Without WGSL, training uses CPU. WGSL cannot replace the WASM model. The optional archive is passed as executionFiles for both new jobs and checkpoint continuation.

Reinforcement learning: required package

The model supplies the environment, policy and learning algorithm. Weei distributes experience assignments and aggregates updated weights. Select model.wasm and its manifest.json in weei-model-package format. A plain chunk list is not sufficient for an experience model. The package must declare workSource and any auxiliaryWeights.

Configure an experience job

1. Select the package manifest. The form changes to Training rounds and the model’s units per assignment, such as episodes.
2. Choose units within the package’s minimum and maximum. Batch size, learning rate and local epochs have model-defined meanings.
3. For generated evaluation, the model needs capabilities.evaluation and a positive workSource.evaluationUnits. Enable Schedule validation with a round interval. Models with inputs: none do not take a validation dataset.
4. Create the job, connect participants, invite them and start. Review training and evaluation metrics by checkpoint round.

When continuing a checkpoint, Training rounds is the final round number: round 397 with a target of 500 trains 103 more rounds. Resume restores the experience sequence; New starts a new sequence while keeping the weights. File-based auxiliary weights must match the checkpoint.

Execution limits

CPU experience assignments without input data can use multiple local Workers when the model declares maxWorkers above one. GPU experience training is hybrid: WASM plays episodes and the GPU runs policy updates. It requires a package-declared GPU backend and the matching shader archive in GPU shaders. Experience training over dataset inputs currently has no GPU support. The model and device determine the actual mode.

Validation files are optional for dataset training. If supplied with a package, the file must match its declared name, size and SHA-256. A model must declare evaluation support.

RL package and model contract ↗

Verify execution

1. Check that the connection reports Training API ready.
2. Create the job. Resolve any validation errors before starting.
3. Start training and inspect the job status and progress returned by the API.
4. Check the full API state for reported errors and completed results.
5. Download a checkpoint after a completed training stage.

Verify model quality

For dataset jobs, supply validation data when creating the job. Experience models use generated evaluation when supported. Run validation on the latest checkpoint or an explicit round. Compare metrics on the same held-out dataset. Lower training loss alone does not establish quality on unseen examples.

Training and validation values appear in the checkpoint table and metric chart. The chart uses checkpoint rounds on the horizontal axis; metric direction comes from the model. Test the downloaded checkpoint in your model’s compatible inference tool.

Errors and recovery

Continue training

Choose a checkpoint, compatible model, manifest, and data files. “New dataset” keeps the weights with a fresh queue. “Same dataset” restores the previous queue. Continuing creates a new job; invite participants again as needed.

Verify reinforcement learning

Check the model’s declared reward or return metric and its direction; metric names are model-defined. Compare generated evaluation on fixed episodes across checkpoint rounds. Training metrics alone do not establish policy quality. Progress uses the model’s declared work units, and a checkpoint marks an aggregated round. Episodes and trajectories stay on participants; only weights, metrics and counts are exchanged.

Recorded answers

Open Help and choose a question. The site calls Recording Demos play(id); the built-in widget repeats actions in the live application. Start from the same page state as the original recording. A missing element stops playback with an error. Stop walkthrough ends playback.

Use Open Recording Demos to create a recording, using its name as the FAQ question and its description as supporting text. Refresh answers to load the shared library. Only saved recordings of kind demo are listed; captured issues are excluded. Libraries are scoped to the exact origin, so recordings on localhost do not automatically appear in production.

Public reference

Distributed Neural Training API ↗ · Get Started ↗

Connection

The training API is retrieved after loadWeei() resolves. The built-in window is not opened. If the API is unavailable, the application shows an error. The documented contract makes it available after loadWeei() when enabled for the site and user. The interface is explicitly hidden with setVisibility(false); this does not disable training.

Execution diagnostics

Compare actual backend, browser, Workers, assignment size, batch settings, and computation-only speed per participant. Expand each peer for model hashes, GPU availability, fallback reasons, assignment IDs, and stage durations. Unknown values are shown as missing; the GPU budget is not a measurement of memory usage. Snapshots are sent every 2 seconds and on stage changes. They are stale after 10 seconds or on disconnection.

Data displayed

Job state, dataset passes, participant states, pending invitations, live progress, transfer status, and checkpoint training/validation metrics use the published State interfaces. Metric labels and direction come from the selected model. Missing values are shown as unavailable, never as zero.

Model export and aggregation

Open in Playground uses exportModule() and exportCheckpoint(round). The module is available only when job.hasModuleFile is true. An empty checkpoint round selects the latest saved checkpoint. Dataset passes are sent as settings.epochs; rounds is the legacy name. FedAvg, FedAvgM and FedAdam use the documented aggregation settings and defaults.

Remaining documentation limits

The API does not document export of GPU execution files, external tokenizers or validation files. Playground includes currently selected local GPU/validation files; missing auxiliary files must be selected manually. Checkpoint versions 1 and 2 are supported. Playground validates weight and optimizer-state sizes, finite values and SHA-256 hashes, and loads only the weights for inference.

The optional WGSL archive is provided through the documented executionFiles field. Saved-job summaries and storage inventory are displayed as returned because their schemas are not specified. Commands validate the participant’s role and current state; API errors are displayed. Commands returning does not mean training has completed.

Verification limits

Connecting to the API does not prove model training. A complete run needs a compatible WASM model, its required dataset or experience package, and an enabled site origin. Check saved checkpoints and independent validation results before using trained weights.

Execution settings and experience jobs

Backend preference, local worker limit and GPU memory budget use setBackendPreference(), setMaxLocalWorkers() and setGpuMemoryBudgetMiB(). Actual execution comes from state.execution and job.localWorkers. The GPU budget is a limit, not memory usage. Experience setup reads workSource and auxiliaryWeights from the package manifest and sends settings.experience.unitsPerAssignment. settings.epochs counts rounds for these jobs.

Recording Demos integration

The FAQ reads listDemos(), refreshDemos() and subscribe() from widgetsApi.get('recording-demos'). A question calls play(id); Stop walkthrough calls stopPlayback(). Only the management button calls widgetsApi.enable('recording-demos') to open the built-in interface. This site does not implement its own recording format or player. The widget must be enabled for this site and user independently of Distributed Training.

Weei UI is hidden with setVisibility(false). Opening a widget can replace its API instance, so the FAQ retrieves the API again for each action and renews its subscription after opening management.

RL shader archive

For inputs: none, the dataset manifest is empty and no validation file is selected. An optional WGSL file must match the package’s shaderArchive. Pass it through executionFiles for GPU training; without it the package trains on the CPU. Weei validates the selected archive.

Recording Demos API ↗ · Client API ↗