Skip to main content
A ModelBundle combines one or more model and profile pairs into a single named, deployable unit. Each entry in spec.modelConfigs references a Model and a ModelProfile by name and can specify per-model batching and model settings. ModelBundle resources use apiVersion: sambanova.ai/v1alpha1.
A bundle is optional. To serve a single model, pair it with a profile and deploy it directly. Create a bundle when you want to serve several models as one unit, configure speculative decoding, or validate and share a named configuration.

Structure

The following example shows a multi-model bundle:
The example above includes three models, with Meta-Llama-3.1-8B-Instruct serving as the non-routable draft model for Meta-Llama-3.3-70B-Instruct. ModelBundle Top-Level Fields

Model configurations

Each entry in spec.modelConfigs pairs one model with one profile: Batching is resolved in the following order of precedence: the model configuration’s batchingConfig, then the profile’s recommended configuration, then its all configuration, then a configuration generated from the PEF grouping. See Resolution order.

Swappable models

The swappable setting controls whether a model can be evicted from HBM in favor of another model on the same endpoint. When swappable is set to true, the entire model is removed from HBM if a different model needs to run on that endpoint. This includes the model’s checkpoint weights, its profile metadata, and its PEFs. Set this field to true for models that can be evicted in order to free capacity for another model, and leave it unset or set it to false for models that must remain resident.

Speculative decoding

In speculative decoding, a smaller draft model proposes tokens and a larger target model verifies them. The pairing is declared at the bundle level in spec.specDecodingPairs, and the draft model is included as its own non-routable entry in spec.modelConfigs. For the field reference, requirements, and the full workflow including custom draft checkpoints, see Deploying with speculative decoding.

Legalizer results

The legalizer validates a configuration’s resource requirements before deployment. It runs automatically when you apply a ModelBundle, and its results are published under status.legalizerInfo. The bundle status also reports the effective batching configuration that was resolved for each model.
Example status for a bundle that passed with warnings:
A bundle can pass the legalizer with warnings present, as in the example above, and still report ValidationSucceeded. Review warnings before deploying, but they do not prevent deployment.
The utilization fields show N/A when skip_legalizer: true is set on a bundle that has been legalized at least once. If the bundle has never been legalized, for example because skip_legalizer: true was set from initial deployment, legalizerInfo is absent entirely. The utilization field may also be absent if the legalizer output could not be parsed.

Create a custom bundle

Author, apply, and validate a bundle of your own

ModelDeployment

Serves a bundle on the cluster