Skip to main content
This guide describes how to create custom BundleTemplates and Bundles to deploy models with specific configurations on SambaStack. In SambaStack, bundles are the fundamental deployment unit. Rather than deploying individual models, you deploy bundles that group one or more models together with their deployment configurations, including batch sizes and sequence lengths. This approach uses the SambaNova Reconfigurable Dataflow Unit (RDU) to support multiple models and configurations in a single deployment, enabling instant switching between configurations for improved efficiency and flexibility.
This guide covers creating custom bundles. For deploying pre-configured bundles provided by SambaNova, see Deploying Bundles.

Prerequisites

Before creating custom bundles, complete the following that applies to you:

Quickstart - Hosted

System set up for hosted SambaStack

Quickstart - On-prem

System set up for On-prem Sambastack
Additionally, review the following documentation:

Terminology

Concepts

Bundle architecture

For an overview of core bundle concepts including what bundles and bundle templates are see Deploying Model Bundles. This section covers the specific three-tier structure used when creating custom bundles:
  1. BundleTemplate - Defines how models can be run: available sequence length profiles, batch sizes, and PEF mappings. Also defines target and draft model relationships for speculative decoding pairs.
  2. Bundle - Binds a template to specific checkpoints in storage, making it ready for deployment
  3. BundleDeployment - Instantiates one or more replicas of a bundle on the cluster
This separation allows you to:
  • Reuse templates across multiple checkpoints, including custom checkpoints for fine-tuned models
  • Bundle different checkpoints of the same underlying model while sharing the same template
  • Deploy the same bundle configuration with different replica counts
  • Update checkpoints without modifying deployment configurations

BundleTemplate structure

A BundleTemplate defines the deployment capabilities for one or more models. The following example shows a multi-model template with speculative decoding configuration:
The example above includes configurations for three models:
  • gpt-oss-120b: 2 configs
  • Meta-Llama-3.3-70B-Instruct: 5 configs, 3 of which use speculative decoding with Meta-Llama-3.1-8B-Instruct as the draft model
  • Meta-Llama-3.1-8B-Instruct: 3 configs
For more details on the speculative decoding fields, see the Speculative Decoding Deployment Guidelines. BundleTemplate Top-Level Fields

Models and Experts

Each model in a BundleTemplate contains one or more experts, which represent sequence length profiles. Common profiles include:
  • 8k, 16k, 32k, 64k, 128k - Fixed sequence length configurations
  • default - Standard configuration when no specific length is required
Expert Configuration Parameters Each expert contains one or more configurations with the following parameters:
Parameters within spec_decoding (target models only):For detailed guidance, see Speculative Decoding Deployment Guidelines.

Bundle structure

A Bundle binds a BundleTemplate to specific checkpoints. The following sections explain each part of the Bundle manifest. Resource Identity Define the Bundle name and resource type:
  • metadata.name - The Bundle name used to reference this bundle in deployments
  • apiVersion and kind - Keep these values the same for all bundles
Checkpoints Define the model checkpoints to use:
Models Map model names to checkpoints and templates:
Template and Secrets Connect the Bundle to its BundleTemplate and credentials:

Complete Bundle Example

The following example shows a complete multi-model Bundle:
The paths to checkpoints hosted by SambaNova will be provided to you by your SambaNova contact. If you have hosted your own checkpoints, you can include those paths in the source fields above.

BundleDeployment structure

A BundleDeployment instantiates a bundle on the cluster. For detailed deployment information, see Quickstart - Hosted or Quickstart - On-prem.

PEF and checkpoint lifecycle status

SambaStack assigns a pef_status field to PEF CR versions and a checkpoint_status field to model CR checkpoint versions to indicate their support lifecycle. Understanding these statuses helps you make informed decisions when selecting PEF or checkpoint versions for custom bundles. PEF and checkpoint version status values Each version entry in a PEF CR includes a pef_status field. Checkpoint CR versions use checkpoint_status. Both share the same set of values: Example PEF CR versions with status
To check version statuses, run kubectl describe pef <pef-name> or kubectl describe model <model-name> and review the pef_status or checkpoint_status field in the Versions section.
The following procedures describe the step-by-step workflow for creating and deploying custom bundles using the concepts and structures described above.

Procedures

Identify available PEFs

Before creating a BundleTemplate, identify the PEF resources available for your model.
1

List available PEFs

List PEFs matching your model and sequence length requirements:
Example:
Output:
2

View PEF details

View PEF details to understand supported configurations and check for higher versions:
Example output:
Review the Spec.Metadata section for:
  • batch_size - Supported batch size
  • max_seq_length - Maximum sequence length
  • num_rdus - Required RDU count
  • rdu_arch - Required RDU architecture
  • seq_lengths - Supported sequence lengths
Check the Versions section to determine if a higher PEF version is available and to review each version’s pef_status before referencing it in a BundleTemplate.
Use version 1 in your PEF references (for example, llama-3p1-70b-ss16384-bs4-sd5:1) unless kubectl describe pef confirms a higher version is available.

Create a BundleTemplate

1

Create the YAML file

Create a YAML file for your BundleTemplate. For a single-model template:
For multi-model templates with speculative decoding, see the BundleTemplate Structure example.
2

Apply the BundleTemplate

3

Verify creation

Including multiple batch sizes for each expert allows the inference engine to select the smallest and fastest configuration based on current workload.

Create a bundle

1

Create the YAML file

Create a YAML file for your Bundle:
For multi-model bundles, see the Complete Bundle Example.
2

Apply the Bundle

3

Verify legalizer validation

The legalizer automatically runs when you apply the bundle and validates whether the bundle fits in RDU memory.
Do not proceed to deployment until the bundle shows ValidationSucceeded.

Deploy the bundle

1

Create a BundleDeployment

2

Apply the BundleDeployment

3

Monitor deployment status

Update or remove a bundle/BundleTemplate

1

Modify the YAML file

Edit the Bundle or BundleTemplate YAML file with your changes.
2

Reapply the configuration

The legalizer automatically revalidates the changes.

Troubleshooting

Legalizer validation failures

Deployment failures

Model Deployment

Bundle deployment concepts and workflows

Supported Models and Bundles

Catalogue of models and bundles available for deployment

Custom checkpoint deployment

Deploy your own custom or fine-tuned checkpoints

Checkpoint Conversion Tool

Convert Checkpoints to Compatible formats