Open weights change Stable Audio 3.0 from a provider-only service into software that can run inside a workstation, studio network, or private compute environment. That creates control over prompts, source recordings, latency, customization, and deployment schedule.
It does not make local generation a one-command production system. Model selection, dependencies, storage, licenses, evaluation, and security still determine whether the result is useful. The examples below reflect official documentation; they are not a claim that this repository has been benchmarked on Medux infrastructure.
Choose the smallest suitable model
The official repository exposes three post-trained checkpoints for local inference:
small-music: 433M parameters, CPU-capable, up to 120 seconds;small-sfx: 433M parameters, CPU-capable, up to 120 seconds;medium: 1.4B parameters, CUDA GPU, up to 380 seconds.
Small Music and Small SFX are specialized. Choose based on whether the output is a composition or a sound effect. Medium targets stronger structure, melodic coherence, phrasing, and longer work. Stable Audio 3 Large is not included in the repository; it is offered through the Stability API and enterprise arrangements.
Start with Small when privacy, portability, or iteration speed matters more than maximum musicality. Use Medium when the evaluation shows a real quality benefit that justifies a CUDA environment. Do not select the largest tier before defining an acceptance test.
Understand the local runtime choices
The standard project uses Python and uv for dependency management. The repository documents a base install, optional Gradio UI, and optional LoRA training extras. Its basic sequence is:
git clone https://github.com/Stability-AI/stable-audio-3.git
cd stable-audio-3
uv sync
uv run python run_gradio.py --model small-music
Review the repository and pin a commit before executing it in a production environment. Do not pipe remote bootstrap scripts directly into a privileged shell without inspection. Generate a software bill of materials, scan dependencies, and build a reproducible image.
Stability also publishes optimized routes:
- TFLite or LiteRT for x86 and ARM CPUs across common operating systems;
- MLX for Apple Silicon;
- TensorRT for Linux with NVIDIA GPUs.
These are different runtimes, not interchangeable flags. Output and performance can vary with quantization, decoder, device, and optimization. Validate an optimized checkpoint against the standard reference on the same prompt set.
Medium requires a deliberate CUDA setup
The default project targets a specific PyTorch and CUDA combination, and Medium requires Flash Attention 2. Official instructions discuss matching the Flash Attention wheel to CUDA, PyTorch, Python, and GPU compute capability.
Dependency mismatches can produce an import error or, more dangerously, a generated static-like glitch. Treat obviously corrupted output as a failed inference, not a creative variation.
Stability’s benchmark reports Medium peak allocated VRAM from about 5.07 GB for five seconds to 6.52 GB for 380 seconds on its measured setup. Chunked decoding can reduce part of that peak. Add model loading, Python, CUDA context, concurrent requests, LoRAs, and audio buffers when sizing a service.
Run soak tests at the maximum supported duration. Monitor GPU memory fragmentation, temperatures, load time, generation latency, output length, and failures. A one-off successful notebook is not capacity evidence.
Generate through Python or the CLI
The Python interface loads a named checkpoint and calls generate with a prompt and duration. The CLI provides the same basic workflow:
stable-audio --model small-music \
--prompt "restrained electronic underscore, 96 BPM, clean ending" \
--duration 30 \
--output underscore.wav
Flag names can change, so use the checked-out repository’s --help rather than copying a frozen article into automation. Store configuration in a versioned job record instead of an unstructured shell history.
For every output, capture checkpoint revision, runtime version, prompt, requested duration, seed when supported, LoRA identifiers, device, elapsed time, output format, and checksum. That record makes a later approval or incident reproducible.
Editing and continuation stay local too
The library supports audio-to-audio generation, inpainting, and continuation. Audio-to-audio uses an initial waveform and noise level to steer how much the source changes. Inpainting replaces one or more intervals. Continuation extends beyond the source endpoint.
These modes can keep an unfinished or confidential composition inside the controlled environment. They also increase rights obligations because the model processes source recordings. Verify ownership and contributor permission before ingesting sessions, vocals, stems, or client libraries.
Never overwrite the source. Store generated alternatives as new immutable assets and preserve the mask intervals. A reviewer should be able to hear exactly which part changed.
LoRA enables private specialization
Stable Audio 3 publishes LoRA training support. A studio can adapt a base checkpoint to a licensed sonic library or a game’s specific environments without moving the whole dataset to a hosted API.
Local fine-tuning still needs governance:
- dataset manifest, rights, and allowed purpose;
- train, validation, and holdout splits;
- removal and revocation process;
- base checkpoint and code revision;
- training configuration and random seeds;
- LoRA artifact access controls;
- similarity and memorization tests.
Keep LoRAs separate by client or license boundary. Runtime stacking is convenient, but it can mix styles and terms that were never authorized together.
“Local” must be defined technically
A process is not private merely because inference runs on a laptop. Initial weights and packages are downloaded. A Gradio share link can expose the interface. Prompts may enter logs or shell history. Crash reporting, notebooks, cloud-synced folders, and backup systems may copy assets outside the intended boundary.
For a genuinely controlled deployment:
- download and scan dependencies through an approved staging process;
- verify model-file checksums;
- disable public share features and unnecessary telemetry;
- isolate the service on the required network segment;
- store prompts and outputs with least-privilege access;
- redact sensitive paths from logs;
- define deletion and backup policies;
- monitor outbound connections.
Air-gapped operation also requires locally mirrored packages, models, documentation, and license texts. Test upgrades in staging before importing them.
Licensing still crosses the boundary
The model weights use the Stability AI Community License. Stability’s launch guidance points organizations with more than $1 million in annual revenue toward an Enterprise license. The code repository’s software license does not replace the model license.
Local generation does not grant rights to an uploaded source, training dataset, artist identity, trademark, or vocal performance. Preserve license versions and consult qualified counsel for commercial or high-risk deployment.
Evaluate the audio, not just the runtime
Create a fixed suite for music, ambience, impacts, loops, transitions, and long structure. Score prompt adherence, musical form, artifacts, clipping, stereo image, seamless looping, ending quality, and similarity concerns.
Measure performance separately: cold start, warm generation time, CPU or GPU memory, power, failure rate, and concurrency. A deployment passes only when both media quality and operating behavior meet the target.
Normalize loudness only after preserving the raw output. Keep raw, mastered, and approved assets in separate locations so later processing is auditable.
Pin the evaluation suite and rerun it after every checkpoint, runtime, driver, quantization, or decoder change. A faster local build is not an upgrade if it introduces clipping, weak endings, or prompt drift.
Include negative cases as well as polished prompts. Deliberately test empty prompts, extreme durations, unsupported formats, abrupt edits, and repeated concurrent requests. These cases expose queue, validation, and resource-release failures that a small showcase set will miss.
Crossing from local generation to cloud finishing
A locally generated track stays inside the private boundary until someone exports it. Adding that track to a cloud-hosted video workflow changes the data path and must be an explicit decision.
An authorized Claude or Codex MCP client can upload an approved audio file and video to Medux for a downstream task. Stable Audio does not natively connect to Medux. The audio-track tutorial demonstrates the signed-upload, task, polling, and download lifecycle. The pitch-adjustment tutorial provides a separate operation when a reviewed track needs that transformation.
Export only the minimum required assets. Record local audio checksum, approval, upload time, signed-upload scope, Medux task ID, retention decision, and final checksum. A failed cloud finishing step should not trigger a new local generation automatically.
Open weights give teams control over where audio is created. Maintaining that control requires treating the first external upload as a governed boundary, not as an invisible continuation of local inference.