TrainerConfig
Training-client launch settings: which training shape to use, the optional reference trainer, region, and run-level knobs. Recipes take it asConfig.trainer:
training_shape_id for explicit shape selection — this is the primary shape-specific value you set. Pass the full shared path accounts/fireworks/trainingShapes/<shape> (the fireworks account is the public shared shape catalog). If you leave it unset, supported recipes auto-select a validated shape from the control plane based on base_model, lora_rank, and max_seq_len.
To request replicated HSDP for a run:
On the shape path (
training_shape_id set or auto-selected), accelerator_type, accelerator_count, node_count, and custom_image_tag are derived from the training shape. TrainerConfig still exposes those fields for the advanced manual path (training_shape_id=None), where they are sent directly and shape validation is skipped.DeployConfig
Deployment settings for sampling and weight sync. WrapsDeploymentConfig fields:
deployment_shape is set (the recommended path), the shape owns deployment hardware and serving configuration.
When
deployment_shape is set, the deployment shape owns GPU type and serving configuration. Use deployment_accelerator_type only for advanced manual deployments without a deployment shape.ConcurrencyConfig
Rollout sampling concurrency settings used by RL-family recipes:Checkpoint & weight-sync fields
Weight-sync and checkpoint cadence are top-level fields on the recipeConfig (no nested config object). rl_loop and igpo_loop expose the full weight-sync cadence knobs; async_rl_loop pins sampler sync to every optimizer step and exposes only pre-training sync and timeout. Every recipe exposes dcp_save_interval:
The old nested
WeightSyncConfig recipe field is gone. Recipe Config objects set the fields above directly, and the SDK-managed service owns the underlying save and weight-sync state.WandBConfig
Weights & Biases logging settings:ReconnectableClient
Blocking convenience wrapper aroundFiretitanTrainingClient. All cookbook recipes use this as their training client — it dispatches each call and blocks until the result is ready or the timeout expires. Failures propagate to the caller so the training loop can crash cleanly and resume from the last DCP checkpoint.
This is a recipe-internal wrapper. User code should not construct it with trainer managers. Recipes build it from the
FiretitanTrainingClient returned by the SDK-managed service client.
Properties:
Methods:
Checkpoint utilities
For checkpointing, resume, and promote — see the dedicated Checkpoints and Resume page.Skills reference
Agent-facing operational guidance for gradient accumulation normalization lives in the cookbook skill reference.Deprecated managed infra (InfraConfig)
Earlier cookbook releases provisioned trainers and deployments from the recipe layer usingInfraConfig, WeightSyncConfig, and the standalone helpers setup_infra / ResourceCleanup / make_reference_client / create_base_reference. Provisioning now lives entirely behind the SDK-managed service client (build_service_client(...) → service.create_*), and recipes take trainer=TrainerConfig(...) plus deployment=DeployConfig(...).
What to change
The
InfraConfig dataclass is still importable for backward compatibility and now emits a DeprecationWarning when constructed; it is no longer accepted by recipe Config objects.
Get help migrating
The cookbook ships a debug-and-migrate skill atskills/dev/ that walks an agent through porting old InfraConfig / setup_infra scripts to the new TrainerConfig + build_service_client surface (in addition to its day-to-day debugging guidance for weight sync and checkpoint promotion). Point your coding agent at that skill to automate the migration.