# Flux Dev API
Source: https://docs.simplismart.ai/api-reference/inference/flux-dev
openapi-specs/playground/flux-dev.yaml POST /model/infer/flux
Generate high-quality images using the Flux model
# Gemma 3 27B API
Source: https://docs.simplismart.ai/api-reference/inference/gemma3-27B
openapi-specs/playground/gemma3-27b.yaml POST /chat/completions
Create a chat completion for given messages with streaming support
# Gemma 3 4B API
Source: https://docs.simplismart.ai/api-reference/inference/gemma3-4B
openapi-specs/playground/gemma3-4B.yaml POST /chat/completions
Create a chat completion for given messages with streaming support
# Llama 3.3 70B API
Source: https://docs.simplismart.ai/api-reference/inference/llama-3.3-70b-instruct
openapi-specs/playground/llama-3p3-70b-instruct.yaml POST /chat/completions
Create a chat completion for given messages with streaming support
# Llama 4 Maverick 17B API
Source: https://docs.simplismart.ai/api-reference/inference/llama-4-maverick-17b
openapi-specs/playground/llama-4-maverick-17b.yaml POST /chat/completions
Create a chat completion for given messages with streaming support
# Llama 3.1 8B API
Source: https://docs.simplismart.ai/api-reference/inference/llama3.1-8B
openapi-specs/playground/llama-8b.yaml POST /chat/completions
Create a chat completion for given messages with streaming support
# LLM Metric API
Source: https://docs.simplismart.ai/api-reference/inference/llm-metric
openapi-specs/playground/llm-metrics.yaml GET /get/metrics/{request_id}
Retrieve detailed metrics about token counts, processing time, and performance statistics
# Qwen 14B API
Source: https://docs.simplismart.ai/api-reference/inference/qwen-14b
openapi-specs/playground/qwen-14b.yaml POST /chat/completions
Create a chat completion for given messages with streaming support
# Qwen 32B API
Source: https://docs.simplismart.ai/api-reference/inference/qwen-32b
openapi-specs/playground/qwen-32b.yaml POST /chat/completions
Create a chat completion for given messages with streaming support
# Whisper V2 API
Source: https://docs.simplismart.ai/api-reference/inference/whisper-v2
openapi-specs/playground/whisper-v2.yaml POST /model/v2/infer/whisper
Process audio files for transcription or translation with advanced options
# Whisper V3 API
Source: https://docs.simplismart.ai/api-reference/inference/whisper-v3
openapi-specs/playground/whisper-v3.yaml POST /model/infer/whisper
Process audio files for transcription or translation with enhanced language support.
Supports multiple audio formats and provides detailed word-level timestamps and speaker diarization.
# Simplismart APIs
Source: https://docs.simplismart.ai/api-reference/introduction
Get started with the Simplismart API, including authentication, endpoints, and workflows for model training and inference.
Simplismart offers two powerful sets of APIs to streamline your workflow:
* **Inference APIs**: Effortlessly leverage pre-trained GenAI models for a wide range of tasks, including ASR transcription, image generation, and LLM-based applications. These APIs allow you to directly run inference and get task-specific outputs with minimal configuration.
* **Training APIs**: Fine-tune and customize GenAI models to fit your unique requirements. With these APIs, you can train models on top of existing base models, optimizing them for your specific tasks, data, and desired outputs.
## API Key Generation
Navigate to the **Settings** page, then select the **API Key** section and generate a new API key.
## Authentication
All API endpoints are authenticated using Bearer tokens and picked up from the specification file.
```json theme={null}
"auth": {
"method": "bearer",
"name": "Authorization"
},
```
# Retrieve Flux Job Details By Request ID and Job ID
Source: https://docs.simplismart.ai/api-reference/training/flux/retrieve-flux-job-details-by-request-id-and-job-id
openapi-specs/playground/flux-training.yaml GET /api/flux/training_job/get/
Fetch metadata and configuration details of a Flux training job by job_id the and org_id.
# Retrieve List of Flux Jobs By Org ID
Source: https://docs.simplismart.ai/api-reference/training/flux/retrieve-list-of-flux-jobs-by-org-id
openapi-specs/playground/flux-training.yaml GET /api/flux/training_job/list/
Overview of Flux training capabilities and endpoints.
# Start a new Flux Training Job
Source: https://docs.simplismart.ai/api-reference/training/flux/start-a-new-flux-training-job
openapi-specs/playground/flux-training.yaml POST /api/flux/train/
Submit a new Flux training job with the specified configuration, training data, and metadata.
# Retrieve List of LLM/VLM Jobs By Org ID
Source: https://docs.simplismart.ai/api-reference/training/llm/get-job
openapi-specs/playground/llm-training.yaml GET /job/get/
Fetches a list of all LLM or VLM training jobs associated with the specified organization.
# Retrieve LLM/VLM Job Details By Request ID
Source: https://docs.simplismart.ai/api-reference/training/llm/get-job-by-req
openapi-specs/playground/llm-training.yaml GET /job/get/
Fetch metadata and configuration details of a training job identified by the provided request_id and org_id.
# Start a new LLM/VLM training job
Source: https://docs.simplismart.ai/api-reference/training/llm/start-a-new-llm-vlm-training-job
openapi-specs/playground/llm-training.yaml POST /job/
Submit a new training job with the specified configuration, training data, and metadata.
# Advanced Benchmarking
Source: https://docs.simplismart.ai/benchmarking/advanced-benchmarking
Perform in-depth, customizable evaluations of LLM outputs using custom datasets and a range of evaluator types including programmatic, human, and AI-based.
# Creating an Advanced Evaluation LLM Benchmark
## Start a New Benchmark
1. Go to **Benchmarking → Create**.
2. Choose **Advanced** as the benchmark type.
3. Select **LLM** as the model type.
## General Information
* **Benchmark Name** — Give the run a clear, unique name.
* **Select Deployments** — Pick **one** deployment to benchmark.
> Only one LLM deployment can be chosen at once.
## Dataset Configuration
* **Presigned Dataset Link** — Provide a presigned URL path to your dataset file.
* Only **JSON** files are supported.
* If the dataset has more than **1000 rows**, only the **first 1000 datapoints** will be used.
* You can use the provided \[[sample dataset format](https://simplismart-public-assets.s3.ap-south-1.amazonaws.com/benchmarking/eval.json)] as a reference.
## LLM Configuration
* **Max Tokens** — Defines the maximum number of tokens the model can generate in a response.\
Example: `1024` means the response will be capped at 1024 tokens.
> A higher value allows longer outputs but also increases resource usage.
* **Temperature** — Controls the randomness/creativity of the model’s output.\
Range: `0` to `1`
* Lower values (e.g., `0.2`) → More deterministic and focused responses
* Higher values (e.g., `0.8`) → More diverse and creative responses
* Example: `0.7` balances creativity and consistency
## Evaluation Configuration
We provide a collection of **pre-built evaluators** that you can use immediately for your AI evaluation needs. Choose **up to 3 evaluators** for assessing model outputs.
Evaluators can be selected from the following categories:
* **Programmatic**\
Uses custom JavaScript or Python code to programmatically evaluate quality.\
Useful for deterministic checks (e.g., regex validation, schema conformance, rule-based scoring).
* **Human**\
Relies on human reviewers to assess outputs based on subjective or nuanced criteria like:
* Readability
* Tone
* Clarity
* Relevance
* Factual correctness
* **Statistical**\
Uses traditional ML metrics for text comparison. Helpful for benchmarking against reference outputs.
* **AI-based**\
Uses LLMs as judges with carefully designed prompts.\
Provides **automated, scalable evaluation** with high alignment to human judgment.
# Introduction
Source: https://docs.simplismart.ai/benchmarking/introduction
Discover Simplismart’s benchmarking suite to evaluate model performance & quality
Simplismart’s benchmarking suite lets you evaluate any deployment for **Performance** (speed & throughput), **Quality** (accuracy & relevance), or **Advanced evaluation** (predefined evaluator-based assessment). Follow these steps to create, configure, and run benchmarks end-to-end.
Measures **Throughput**, **TTFT** (time‑to‑first‑token), and **TPOT** (time‑per‑output‑token).
##
Evaluates model responses for **accuracy, relevance, and output quality** on selected datasets.
Measures quality using a suite of advanced predefined evaluators for deeper assessment.
## Model Types
| Model | Type | Status |
| ----------- | -------------------- | ------------- |
| **LLM** | Text generation | ✅ Available |
| **Whisper** | Speech-to-Text (STT) | ⏳ Coming soon |
| **Flux** | Image generation | ⏳ Coming soon |
## **Prerequisites**
You have at least one **Deployment** in an active **Cluster**.
# Performance Benchmarking
Source: https://docs.simplismart.ai/benchmarking/performance-benchmarking
Set up and run load tests to evaluate LLM deployment speed, throughput, and scalability using chat datasets.
# Creating a Performance Benchmark
## Start a New Benchmark
1. Go to **Benchmarking → Create**.
2. Choose **Performance** as the benchmark type.
3. Select **LLM** as the model type.
## General Information
* **Benchmark Name** — Give the run a clear, unique name.
* **Select Deployments** — Pick one or more deployments to benchmark.
* **Region** — (Shown in Available Regions) choose where the run executes.
## Supported Inputs (Chat Dataset Input)
* **Dataset Name** — Choose a dataset (currently we support only *Ultrachat* dataset).
* **Num Samples** — Limit how many rows/samples from the dataset to use.
* **Sampling Temperature** — Set generation randomness between 0 and 1.
* **Maximum tokens to generate** — Sets the upper limit on response length in tokens.
* **Whether to stream responses** — Toggle on/off to stream model outputs during the run.
## Execution Configuration
* **Users** — Number of virtual users to simulate during the benchmark.
* **Duration** — How long the benchmark should run (e.g., 30s).
* **Load Type** — Pattern for load generation (e.g., Constant).
* **Metrics** — Select the metrics to capture (e.g., *throughput*, *ttft*, *tpot*).
## Search Space (Hyperparameter Sweep)
**Search Space** allows you to run the same benchmark multiple times with different parameter values, so you can compare how deployments behave under varied conditions.
Instead of running separate benchmarks manually, you can provide multiple values and the suite will automatically generate runs for each combination.
* `inputs[name=messages].preprocess.input_tokens` — Vary the input size (number of tokens in the prompt).\
**Example**: `1000`, `2000`, `3000`.
* `inputs[name=max_tokens].value` — Vary the maximum output length.\
**Example**: `100`, `200`, `300`.
* `execution.profile.users` — Vary the number of concurrent users.\
**Example**: `1`, `2`, `3`.
**Example**:\
If you specify `input_tokens: [1000,2000]` and `users: [1,2]`, the suite will generate 4 runs:
* `1000×1`, `1000×2`, `2000×1`, `2000×2`.
> Type a value and press `Enter` or `Add` — values appear as tags. Leave blank to skip.
## Run the Benchmark
Click **Create Benchmark**.
The run is queued and executed in the selected **Region** with the chosen **metrics** and **sweep settings**.
# Quality Benchmarking
Source: https://docs.simplismart.ai/benchmarking/quality-benchmarking
Measure the accuracy and quality of LLM outputs using curated datasets and standardized evaluation metrics.
# Creating a Quality Benchmark
## Start a New Benchmark
1. Go to **Benchmarking → Create**.
2. Choose **Quality** as the benchmark type.
3. Select **LLM** as the model type.
## General Information
* **Evaluation Name** — Name for this evaluation.
* **Select Deployments** — Choose one or more deployments to evaluate.
## Dataset Configuration
* **Select Datasets** — Pick one or more datasets (e.g., *gsm8k*).
## Generation Configuration
* **Max Tokens** — Maximum tokens the model can generate per response.
* **Temperature** — Controls randomness; lower = more focused, higher = more creative.
* **Top P** — Nucleus sampling; limits token choices to the top probability mass (e.g., `0.9` = top 90%).
## Execution Configuration
* **Batch Size** — Requests processed together.
* **Evaluation Limit** — Limit number of dataset samples to evaluate (e.g., `10`).
## Run the Evaluation
* Click **Create Benchmark** to start.
# Compilation Configurations
Source: https://docs.simplismart.ai/configurations/compilation-configurations
Reference guide for model compilation configurations, including Optimization settings and Quantization options for different hardware environments.
## **Optimization Configuration**
```json theme={null}
{
"warmups": {
"enabled": true,
"iterations": 5,
"sample_input_data": []
},
"backend": {
"name": "auto",
"version": "latest",
"extra_params": {}
},
"optimisations": {
"speculative_decoding": {
"enabled": false,
"type": "auto",
"extra_params": {}
},
"attention_caching": {
"enabled": false,
"type": "auto",
"extra_params": {}
}
},
"tensor_parallel_size": 1,
"quantization": "float16"
}
```
***
## **Quantization Types**
1. **Float 32 (FP32)**
* Full precision.
* Highest accuracy.
* Maximum memory usage.
2. **Float 16 (FP16)**
* Reduced precision.
* Minimal accuracy loss.
* Recommended for most use cases.
* Balances performance and accuracy.
3. **Float 8 (FP8)**
* Advanced reduced precision.
* **Hardware Limitations**
* Not supported on **A100 GPU** architecture.
* Only available on **H100 GPUs**.
4. **INT4 Quantization**
* Extreme compression.
* Substantial memory reduction.
* Noticeable accuracy degradation.
5. **AWQ (Activation-aware Weight Quantization)**
* Advanced compression technique.
* Maintains model performance.
* Minimal accuracy loss.
***
## Model Configuration
```json theme={null}
{
"type": "llm",
"loras": [],
"lora_repo": {
"type": "",
"path": "",
"ownership": "",
"secret": {
"type": ""
}
},
"quantized_model_path": {
"type": "",
"path": "",
"ownership": "",
"secret": {
"type": ""
}
}
}
```
# LLM Training Configuration
Source: https://docs.simplismart.ai/configurations/llm-training-configuration
Detailed guide for configuring LLM training parameters, including input/output features, quantization settings, and prompt templating for combining multiple data columns.
## Advanced Configuration
```json theme={null}
{
"input_features": [
{
"name": "question",
"type": "text",
"preprocessing": {
"max_sequence_length": 4096
}
}
],
"output_features": [
{
"name": "answer",
"type": "text",
"preprocessing": {
"max_sequence_length": 4096
}
}
],
"quantization": {
"bits": 4,
"llm_int8_threshold": 6,
"llm_int8_has_fp16_weight": false,
"bnb_4bit_compute_dtype": "float16",
"bnb_4bit_use_double_quant": true,
"bnb_4bit_quant_type": "nf4"
},
"trainer": {
"type": "finetune",
"learning_rate_scheduler": {
"warmup_fraction": 0.01,
"decay": "linear"
}
},
"preprocessing": {
"sample_ratio": 1
},
"backend": {
"type": "local"
}
}
```
The training configuration provides a flexible way to define the inputs, outputs, and other advanced settings for your model.
* Max Sequence Length (input and output features) : The ‘max\_sequence\_length’ parameter in the config refers to the maximum tokens in the prompt and response respectively.
* If Quantisation of the model is not required (for smaller models like 3B, 2B etc) we can remove the quantization key from the advanced configuration, so that all the parameters are used in full precision which yields better accuracy (however training time would increase).
## **Quantization Config**
```json theme={null}
{
"bits": 4,
"llm_int8_threshold": 6,
"llm_int8_has_fp16_weight": false,
"bnb_4bit_compute_dtype": "float16",
"bnb_4bit_use_double_quant": true,
"bnb_4bit_quant_type": "nf4"
}
```
* Ensure that the names in the input and output features match exactly with the corresponding columns in the dataset. (e.g., "question" for input and "answer" for output)
## Prompt Template
In cases where you want to form a prompt using multiple columns you can use a prompt template to combine them.
**config with Prompt Template:**
```json theme={null}
{
"prompt": {
"template": "{system_prompt}\n\n {question}\n\n Response:\n"
},
"input_features": [
{
"name": "prompt",
"type": "text",
"preprocessing": {
"max_sequence_length": 4096
}
}
],
"output_features": [
{
"name": "response",
"type": "text",
"preprocessing": {
"max_sequence_length": 4096
}
}
],
"quantization": {
"bits": 4,
"llm_int8_threshold": 6,
"llm_int8_has_fp16_weight": false,
"bnb_4bit_compute_dtype": "float16",
"bnb_4bit_use_double_quant": true,
"bnb_4bit_quant_type": "nf4"
},
"trainer": {
"type": "finetune",
"learning_rate_scheduler": {
"warmup_fraction": 0.01,
"decay": "linear"
}
},
"preprocessing": {
"sample_ratio": 1
},
"backend": {
"type": "local"
}
}
```
# Image Generation Models
Source: https://docs.simplismart.ai/get-started/playground/image-generation-models
Generate fast, high-quality AI images using an intuitive playground
The image generation playground is focused on image generation and customization. You can:
* **Create Images from Text**: Generate images based on text descriptions or prompts.
* **Set Generation Parameters**: Configure steps, image size, seed, and other parameters to refine the image generation process.
* **Apply Custom Models**: Optionally use LoRA weights from the Simplismart Training Suite to customize outputs.
* **Review and Download Results**: View the generated images, assess their quality, and export them as needed.
###
## Settings Explained
**prompt**: The text description guiding the image generation, crucial for defining the desired outcome.
**height & width**: Dimensions of the generated image, available in various aspect ratios:
| **Image Dimensions** | **Aspect Ratio** | **Resolution** |
| :------------------: | :--------------: | :------------: |
| Square | 1:1 | 1024x1024 |
| Portrait | 2:3 | 768x1152 |
| Landscape | 4:3 | 1152x768 |
| Widescreen | 16:9 | 1024x576 |
| Vertical Widescreen | 9:16 | 576x1024 |
| Cinematic | 2:1 | 1024x512 |
| Vertical Cinematic | 1:2 | 1024x512 |
| Portrait | 4:5 | 816x1024 |
**seed**: Initial input for the random generator, ensuring reproducibility of generated images.
**num\_inference\_steps**: Number of iterations the model performs during generation; more steps improve quality at the cost of processing time. (recommended: 28)
**num\_images\_per\_prompt**: Number of images to be generated for a single prompt.
**guidance\_scale**: Controls how closely the model follows the input prompt. Higher values increase adherence to the prompt while lower values allow more creative freedom. (recommended: 3)
**lora\_weights** (optional): URL pointing to custom LoRA weights from the Simplismart Training Suite.
**lora\_scale** (optional): Determines the impact of LoRA weights on the generation process. (default: 1)
***
Access the Flux model API documentation [**here**](/api-reference/inference/flux-dev) for endpoints, parameters, and code examples.
# Large Language Models
Source: https://docs.simplismart.ai/get-started/playground/large-language-models
Generate and evaluate text across multiple powerful LLMs using a fast, interactive interface
The LLM (Large Language Model) playground offers a versatile space for text generation and conversational AI. Users can:
* **Chat**: Engage in interactive conversations with the model, simulating real-world dialogue.
* **Configure Output**: Adjust settings like output length, temperature and top-P to customize the responses generated by the model.
* **Experiment with Prompts**: Input different prompts and scenarios to see how the model responds, allowing for creative and practical applications.
* **Evaluate Interactions**: Analyze the generated text for coherence, creativity, and relevance to ensure it meets the required standards.
***
### Settings explained
`output tokens:` The maximum length of the generated response, important for controlling the verbosity of the output.
`temperature:` Controls randomness in the output; higher values produce more creative results, while lower values yield more deterministic responses.
`top-P:` Uses nucleus sampling to choose tokens from the top P cumulative probability mass, balancing creativity and coherence.
`stop sequence:` Specific sequences that, when generated, will halt further output.
`system prompt:` The initial instruction or context setting the behaviour of the model.
# Transcription Models
Source: https://docs.simplismart.ai/get-started/playground/transcription-models
Get real-time, high-quality speech-to-text output for any audio with fast STT processing, live results, and support for various audio formats.
The Whisper playground is designed for audio processing and transcription. You can:
* **Upload Audio Files**: Test the model by uploading audio files and receiving transcriptions.
* **Set Advanced Parameters**: Configure settings such as initial prompts, the number of speakers, beam size, audio sample rate, and more to fine-tune transcription accuracy.
* **Process Audio Real-Time**: Experience real-time audio processing and transcription to evaluate performance in various scenarios.
* **Evaluate Results**: Review and analyze transcriptions to ensure they meet the desired accuracy and quality.
###
***
### **Settings explained**
`language`: Language spoken in the audio, specify None to perform language detection.
`task`: Determines if the Whisper model should perform translation or transcription.
`initial prompt`: Optional starting text prompt for the model, useful for guiding the initial context. e.g. custom vocabularies or proper nouns to make it more likely to predict those word correctly.
`best of`: Specifies how many decoding paths to consider and choose the best from, higher values can improve quality.
`no of speakers`: The number of speakers in the audio, important for separating dialogues.
`diarization`: Assignment of speakers to different parts of the text.
`word timestamps`: Indicates if word-level timestamps should be in the output.
`without timestamps`: Option to exclude timestamps in the output.
`beam size`: Controls the breadth of search in beam search decoding, larger values improve accuracy but increase computation.
`length penalty`: A factor that penalizes longer predictions, helps control output length.
`batch size`: The number of audio samples processed together in one batch.
`patience`: The duration to wait before making a prediction, useful for adjusting responsiveness.
`minimum duration on`: Minimum duration of speech to consider it as an active segment.
`minimum duration off`: Minimum duration of silence to consider it as a break.
`maximum duration`: The longest duration of speech to process in one go, prevents excessive processing time.
`maximum speakers`: The maximum number of speakers expected in the audio.
`minimum speakers`: The minimum number of speakers expected in the audio.
`vad onset`: Sensitivity for detecting the start of speech.
`vad offset`: Sensitivity for detecting the end of speech.
`pad onset`: Additional padding time added to the start of detected speech.
`pad offset`: Additional padding time added to the end of detected speech.
***
Access the Whisper model API documentation [here](/api-reference/inference/whisper-v3) for endpoints, parameters, and code examples.
Need help with VAD parameter tuning or Whisper troubleshooting? Check our detailed guides on [VAD tuning](/troubleshooting-faq/vad-parameter-tuning) and [Whisper troubleshooting](/troubleshooting-faq/whisper-troubleshooting).
***
### Supported Languages with their Codes
```json theme={null}
LANGUAGES = {
"en": "english",
"zh": "chinese",
"de": "german",
"es": "spanish",
"ru": "russian",
"ko": "korean",
"fr": "french",
"ja": "japanese",
"pt": "portuguese",
"tr": "turkish",
"pl": "polish",
"ca": "catalan",
"nl": "dutch",
"ar": "arabic",
"sv": "swedish",
"it": "italian",
"id": "indonesian",
"hi": "hindi",
"fi": "finnish",
"vi": "vietnamese",
"he": "hebrew",
"uk": "ukrainian",
"el": "greek",
"ms": "malay",
"cs": "czech",
"ro": "romanian",
"da": "danish",
"hu": "hungarian",
"ta": "tamil",
"no": "norwegian",
"th": "thai",
"ur": "urdu",
"hr": "croatian",
"bg": "bulgarian",
"lt": "lithuanian",
"la": "latin",
"mi": "maori",
"ml": "malayalam",
"cy": "welsh",
"sk": "slovak",
"te": "telugu",
"fa": "persian",
"lv": "latvian",
"bn": "bengali",
"sr": "serbian",
"az": "azerbaijani",
"sl": "slovenian",
"kn": "kannada",
"et": "estonian",
"mk": "macedonian",
"br": "breton",
"eu": "basque",
"is": "icelandic",
"hy": "armenian",
"ne": "nepali",
"mn": "mongolian",
"bs": "bosnian",
"kk": "kazakh",
"sq": "albanian",
"sw": "swahili",
"gl": "galician",
"mr": "marathi",
"pa": "punjabi",
"si": "sinhala",
"km": "khmer",
"sn": "shona",
"yo": "yoruba",
"so": "somali",
"af": "afrikaans",
"oc": "occitan",
"ka": "georgian",
"be": "belarusian",
"tg": "tajik",
"sd": "sindhi",
"gu": "gujarati",
"am": "amharic",
"yi": "yiddish",
"lo": "lao",
"uz": "uzbek",
"fo": "faroese",
"ht": "haitian creole",
"ps": "pashto",
"tk": "turkmen",
"nn": "nynorsk",
"mt": "maltese",
"sa": "sanskrit",
"lb": "luxembourgish",
"my": "myanmar",
"bo": "tibetan",
"tl": "tagalog",
"mg": "malagasy",
"as": "assamese",
"tt": "tatar",
"haw": "hawaiian",
"ln": "lingala",
"ha": "hausa",
"ba": "bashkir",
"jw": "javanese",
"su": "sundanese",
"yue": "cantonese",
}
```
# Model Deployment Guide
Source: https://docs.simplismart.ai/guides/deployment-guides
A guide to deploying models with best practices/ checks for reliable model serving
Before deploying any machine learning model, it is critical to perform a series of infrastructure checks to ensure optimal performance and cost-efficiency. Below are the key considerations to evaluate:
## 1. Model Specifications
* **Model Size**: Determine the model's parameter size (e.g., 8B, 13B, etc.).
* **Precision Format**: Know the floating-point format (e.g., FP16, INT8), as this impacts memory requirements.
* **Tensor Parallelism:** Distribute model layers across **multiple GPUs** to handle models too large for single GPU memory.
## 2. GPU Memory Requirements
* For large models (e.g., an 8B model using FP16), ensure a minimum of **16 GB GPU memory** to avoid Out-of-Memory (OOM) errors.
* In such cases, opt for higher-spec GPUs:
* **NVIDIA L4**: 24 GB VRAM
* **NVIDIA L40s**: 48 GB VRAM
## 3. GPU vs. CPU RAM Clarification
* It's important to distinguish between **CPU RAM** (displayed as system memory) and **GPU VRAM**.
* For example, instances like `g4dn.xlarge` and `g4dn.2xlarge` offer:
* `g4dn.xlarge`: 4 vCPUs, 16 GB CPU RAM
* `g4dn.2xlarge`: 8 vCPUs, 32 GB CPU RAM
* **Note**: Across a given instance family, the **GPU VRAM typically remains constant**, even though CPU resources scale up.
## 4. Resource Allocation Best Practices
* To ensure system stability and allow room for background processes:
* Allocate **only 80%** of the available CPU and RAM to the model or service.
* Example: On a `g4dn.2xlarge` (8 vCPUs, 32 GB RAM), limit allocation to:
* **6–7 vCPUs**
* **\~26 GB RAM**
## 5. Deployment Considerations
* Identify the **deployment region** and **preferred instance family**.
* Define **scaling ranges and metrics** (e.g., CPU/GPU utilization, request latency) to enable autoscaling effectively.
# Dynamic Lora Compilation
Source: https://docs.simplismart.ai/guides/dynamic-lora-compilation
Use dynamic LoRA compilation on Simplismart to run multiple task-specific LoRAs in a single deployment, improving efficiency and simplifying workflows.
## Introduction
### What's New?
This feature enables users to dynamically load multiple **LoRAs (Low-Rank Adaptations)** into a single model deployment. With this enhancement, you can tailor your models to diverse tasks and domains without creating multiple separate deployments. By leveraging multiple LoRAs simultaneously, you can optimize model performance, reduce inference time, and streamline your model management workflows.
## Available Flags & Options
| Flag Name | Type | Default | Description |
| ------------------- | ------- | ------- | -------------------------------------------------------------------------------------------- |
| `loras` | list | `[]` | List of LoRA configurations to load. See **Example Configuration** for the schema. |
| `lora_repo` | dict | `null` | Cloud storage path (e.g. S3, GCP) containing multiple LoRAs to load dynamically. |
| `load_lora_dynamic` | boolean | `false` | Enables dynamic loading of LoRAs into the base model. `false` will merge all provided LoRAs. |
***
## Example Pipeline Configuration
### Using `loras` list:
When specifying LoRAs manually:
```json theme={null}
{
"type": "llm",
"loras": [
{
"id": "lora_id_0",
"source": {
"path": "s3://simplismart-model-repository/dobby-test-loras/Llama-3.1-8B-Instruct-GRPO-gsm8k-ft-lora",
"type": "s3",
"secret": { "type": "aws" }
}
},
{
"id": "lora_id_1",
"source": {
"path": "s3://simplismart-model-repository/dobby-test-loras/llama3.1_text2sql_instruct_tuned",
"type": "s3",
"secret": { "type": "aws" }
}
},
{
"id": "lora_id_2",
"source": {
"path": "raaec/llama3.1-8b-instruct-lora-model",
"type": "hf",
"secret": { "type": "hf" }
}
}
],
"lora_repo": {
"type": "",
"path": "",
"ownership": "",
"secret": { "type": "" }
},
"quantized_model_path": {
"type": "",
"path": "",
"ownership": "",
"secret": { "type": "" }
},
"load_lora_dynamic": false
}
```
### Using `lora_repo`:
When pulling LoRAs dynamically from a cloud directory:
```json theme={null}
"pipeline_config": {
"type": "llm",
"loras": [],
"lora_repo": {
"type": "s3",
"path": "s3://simplismart-model-repository/dobby-test-loras",
"ownership": "",
"secret": { "type": "aws" }
},
"quantized_model_path": {
"type": "",
"path": "",
"ownership": "",
"secret": { "type": "" }
},
"load_lora_dynamic": false
}
```
***
## Important Notes
✅ If `load_lora_dynamic` is `false` but the `loras` list contains more than one LoRA, then `load_lora_dynamic` will automatically be set to `true`.\
✅ The `id` specified in each LoRA will be the model's name during inferencing.\
✅ When using a `lora_repo`, each subfolder inside the specified path will become a separate model.\
✅ LoRAs will be dynamically merged or loaded at inference time depending on the `load_lora_dynamic` flag.\
✅ To understand how to structure secrets, refer to the [Secret Management](/model-suite/integrations/secrets) documentation. Here are some sample secrets for LoRAs.
```json AWS theme={null}
{
"type": "aws",
"access_key_id": "",
"secret_access_key": ""
}
```
```json Azure theme={null}
{
"type": "azure",
"auth_json": {
"client_id": "",
"client_secret": "",
"subscription_id": "",
"tenant_id": ""
}
}
```
```json GCP theme={null}
{
"type": "gcp",
"auth_json": {
"auth_provider_x509_cert_url": "",
"auth_uri": "",
"client_email": "",
"client_id": "",
"client_x509_cert_url": "",
"private_key": "",
"private_key_id": "",
"project_id": "",
"token_uri": "",
"type": "",
"universe_domain": ""
}
}
```
## LoRA Repository Structure
\
When using the **LoRA Config → LoRA Repository** option, the S3 bucket should contain the LoRA adapter files in the parent directory.
At a minimum, the parent folder **must** contain the following files:
```text theme={null}
/
├── adapter_config.json
└── adapter_model.safetensors
```
### Required Files
| File | Description |
| :-------------------------- | :-------------------------------------------------------------------- |
| `adapter_config.json` | Contains the LoRA adapter configuration required to load the adapter. |
| `adapter_model.safetensors` | Contains the trained LoRA adapter weights. |
> **Note:** Both `adapter_config.json` and `adapter_model.safetensors` must be present in the **parent folder** of the LoRA repository. These are the minimum required files for loading a LoRA adapter. Additional files (such as tokenizer files, training metadata, metrics, etc.) may be present but are not required for compilation.
### Example S3 Structure
## Recommendations
* **Performance:** Use `load_lora_dynamic = true` if you want the system to load LoRAs on-demand and minimize startup time.
* **Organizational Structure:** When using a `lora_repo`, name the directories intuitively, as those names will serve as model identifiers.
* **Security:** Configure the appropriate `secret` for S3, GCP, HF, or any supported cloud source to ensure proper authentication and authorization.
# Overview
Source: https://docs.simplismart.ai/guides/flux-compilation-guide
Comprehensive guide for compiling Flux models
This page serves as a guide for Flux Pipeline Compilation and Inference using Simplismart. Below are the links to the specific types of pipelines covered in detail.
* [Multi-Pipeline](/guides/multi-pipeline)
* [Multi-ControlNet](/guides/multi-control-net)
* [Multi-Mode ControlNet](https://docs.simplismart.ai/guides/multi-mode-control-net)
# LiveKit Integration with Simplismart
Source: https://docs.simplismart.ai/guides/livekit
Learn how to build real-time voice AI agents using LiveKit with Simplismart's high-performance inference APIs
## What is LiveKit?
LiveKit is an open-source platform that enables scalable, multi-user conferencing with WebRTC. It provides the tools you need to add real-time video, audio, and data capabilities to your applications. By combining LiveKit with Simplismart's optimized inference, you can build responsive voice AI agents that handle conversations with minimal latency. Learn more at [LiveKit.io](https://livekit.io).
## Prerequisites
Before you begin, ensure you have:
* **Simplismart API Key** - Get your API key from [Settings > API Keys](/model-suite/settings/api-keys)
* **LiveKit Account** - Visit [LiveKit Cloud](https://cloud.livekit.io/) and create an account to get your API credentials
* **Python 3.11 - 3.13** - LiveKit agents require Python \< 3.14. Verify your version with `python --version`
Simplismart provides comprehensive AI model serving including STT (Speech-to-Text), LLM (Language Models), and TTS (Text-to-Speech) - all optimized for ultra-low latency in real-time applications.
## Configure LiveKit with Simplismart
Set up an isolated Python environment for your project. This keeps dependencies organized and prevents conflicts with other projects.
```bash theme={null}
python -m venv .venv
source .venv/bin/activate # On Windows: .venv\Scripts\activate
```
Install the LiveKit agents framework with the Simplismart plugin. This includes voice activity detection (VAD) and all necessary components.
```bash theme={null}
pip install livekit-plugins-simplismart 'livekit-agents[silero]' python-dotenv
```
The `simplismart` plugin provides native support for Simplismart's STT and TTS services, while the `openai` plugin (included by default) allows you to use any OpenAI-compatible LLM API.
Create a `.env` file in your project directory with your API credentials. These credentials authenticate your application with Simplismart and LiveKit services.
```bash theme={null}
SIMPLISMART_API_KEY=your-simplismart-api-key-here
LIVEKIT_URL=your-livekit-url-here
LIVEKIT_API_KEY=your-livekit-api-key-here
LIVEKIT_API_SECRET=your-livekit-api-secret-here
```
Get your LiveKit credentials from the [LiveKit Cloud dashboard](https://cloud.livekit.io/):
Fetch following credentials these in Settings → API Keys → Create key → Copy `Environment Variables` and paste it in the `.env` file.
* **LIVEKIT\_URL**: Your project URL (starts with `wss://`)
* **LIVEKIT\_API\_KEY**
* **LIVEKIT\_API\_SECRET**
Build a complete voice AI agent that uses Simplismart for speech-to-text, language processing, and text-to-speech.
Create a file named `voice_agent.py`:
```python theme={null}
import logging
import os
from dotenv import load_dotenv
from livekit import agents, api
from livekit.agents import AgentSession, Agent
from livekit.plugins import openai, silero, simplismart
load_dotenv()
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger("voice-agent")
# Load Simplismart credentials
SIMPLISMART_API_KEY = os.getenv("SIMPLISMART_API_KEY")
SIMPLISMART_BASE_URL = "https://api.simplismart.live"
# Load LiveKit credentials
LIVEKIT_API_KEY = os.getenv("LIVEKIT_API_KEY")
LIVEKIT_API_SECRET = os.getenv("LIVEKIT_API_SECRET")
LIVEKIT_URL = os.getenv("LIVEKIT_URL")
class Assistant(Agent):
def __init__(self) -> None:
super().__init__(instructions="You are a helpful voice AI assistant.")
# Initialize Simplismart STT (Speech-to-Text) model
stt = simplismart.STT(
base_url=f"{SIMPLISMART_BASE_URL}/predict",
api_key=SIMPLISMART_API_KEY,
model="openai/whisper-large-v3-turbo"
)
# Initialize Simplismart LLM
llm = openai.LLM(
model="google/gemma-3-4b-it",
api_key=SIMPLISMART_API_KEY,
base_url=SIMPLISMART_BASE_URL,
)
# Initialize Simplismart TTS (Text-to-Speech) model
tts = simplismart.TTS(
base_url=f"{SIMPLISMART_BASE_URL}/tts",
api_key=SIMPLISMART_API_KEY,
model="canopylabs/orpheus-3b-0.1-ft"
)
async def entrypoint(ctx: agents.JobContext):
logger.info(f"Starting agent in room {ctx.room.name}")
session = AgentSession(
stt=stt,
llm=llm,
tts=tts,
vad=silero.VAD.load(),
)
await session.start(
room=ctx.room,
agent=Assistant(),
)
await session.generate_reply(
instructions="Greet the user and offer your assistance."
)
if __name__ == "__main__":
# Generate and display token
if not LIVEKIT_API_KEY or not LIVEKIT_API_SECRET:
print("Missing LIVEKIT_API_KEY or LIVEKIT_API_SECRET in .env file")
print("Get these from your LiveKit Cloud dashboard: https://cloud.livekit.io/")
else:
token = api.AccessToken(LIVEKIT_API_KEY, LIVEKIT_API_SECRET) \
.with_identity("test_user") \
.with_grants(api.VideoGrants(
room_join=True,
room="test_room",
))
jwt_token = token.to_jwt()
print("\n\nLiveKit Agent Ready to Connect!\033[0m\n\033[94m" + "="*50 + "\033[0m")
print(f"\033[94mConnect at: https://agents-playground.livekit.io/\033[0m\n\033[94m")
print(f"\033[94mURL: {LIVEKIT_URL}\033[0m")
print(f"\033[94mToken: {jwt_token}\033[0m\n" + "="*50 + "\033[0m")
agents.cli.run_app(agents.WorkerOptions(entrypoint_fnc=entrypoint))
```
This example uses Simplismart's Whisper for speech-to-text, Gemma 3 4B for language understanding, and Orpheus TTS for natural-sounding speech synthesis - all optimized for real-time performance.
Start your voice agent with the LiveKit CLI. The agent will connect to your LiveKit room and wait for a user to join.
```bash theme={null}
python voice_agent.py dev
```
To test your agent:
1. Go to the [LiveKit Agents Playground](https://agents-playground.livekit.io/)
2. **If authenticated**: You'll see available rooms and can join directly. **Otherwise**: Use manual connection by entering the URL and token from your terminal (displayed in blue when you run the agent)
3. Click **Connect**
4. **Approve microphone access** when your browser prompts you (required for voice interaction)
5. Speak into your microphone - the agent should respond!
Ensure your browser has microphone permissions enabled for the playground to function properly.
## Using Different Simplismart Models
**OpenAI Compatibility**: Simplismart's LLM API is fully OpenAI-compatible. This means you can use LiveKit's built-in `openai` plugin to connect to any Simplismart LLM endpoint, no custom plugin needed. Just point `base_url` at `https://api.simplismart.live` and set your `SIMPLISMART_API_KEY`, then pick any model from the [Simplismart Marketplace](https://app.simplismart.ai/model-marketplace).
```python theme={null}
from livekit.plugins import openai
llm = openai.LLM(
model="",
api_key=SIMPLISMART_API_KEY,
base_url="https://api.simplismart.live",
)
```
You can easily swap models based on your needs. Choose faster models for lower latency or more capable models for complex reasoning tasks.
For ultra-fast responses with a compact model, use Gemma 3 1B:
```python theme={null}
from livekit.plugins import openai
# For faster responses with smaller model
llm = openai.LLM(
model="google/gemma-3-1b-it",
api_key=SIMPLISMART_API_KEY,
base_url="https://api.simplismart.live"
)
```
For a balance between speed and capability, use Gemma 3 4B (recommended):
```python theme={null}
from livekit.plugins import openai
# Balanced performance
llm = openai.LLM(
model="google/gemma-3-4b-it",
api_key=SIMPLISMART_API_KEY,
base_url="https://api.simplismart.live"
)
```
For complex reasoning and longer context, use Llama 3.3 70B:
```python theme={null}
from livekit.plugins import openai
# For maximum capability and complex reasoning
llm = openai.LLM(
model="meta-llama/llama-3.3-70b-instruct",
api_key=SIMPLISMART_API_KEY,
base_url="https://api.simplismart.live"
)
```
Try different Whisper models for various accuracy/speed tradeoffs:
```python theme={null}
from livekit.plugins import simplismart
# Ultra-fast transcription with Whisper v3 Turbo
stt = simplismart.STT(
base_url="https://api.simplismart.live/predict",
api_key=SIMPLISMART_API_KEY,
model="openai/whisper-large-v3-turbo"
)
# Or use standard Whisper v3 for maximum accuracy
stt = simplismart.STT(
base_url="https://api.simplismart.live/predict",
api_key=SIMPLISMART_API_KEY,
model="openai/whisper-large-v3"
)
```
## Advanced Configuration
### Custom Agent Instructions
Customize your agent's behavior by modifying the system instructions:
```python theme={null}
class CustomAssistant(Agent):
def __init__(self) -> None:
super().__init__(
instructions="""You are a professional customer support agent for TechCorp.
You help customers with product inquiries, troubleshooting, and order tracking.
Always be polite, concise, and solution-oriented."""
)
```
### Adding Function Tools
Enable your agent to perform actions using function tools:
```python theme={null}
from livekit.agents import function_tool, RunContext
@function_tool
async def check_order_status(
context: RunContext,
order_id: str,
):
"""Check the status of a customer order."""
# Your order lookup logic here
return {"status": "shipped", "tracking": "ABC123"}
# Add to your agent session
session = AgentSession(
stt=stt,
llm=llm,
tts=tts,
vad=silero.VAD.load(),
tools=[check_order_status], # Add your tools here
)
```
## Troubleshooting
**Check your microphone permissions** - Ensure your browser or application has access to your microphone.
**Verify VAD settings** - The Silero VAD may need tuning for your audio environment. Try adjusting `min_speech_duration` and `min_silence_duration` parameters.
**Test STT independently** - Make a direct API call to Simplismart's Whisper endpoint to verify your audio is being transcribed correctly.
**Use a smaller model** - Try `google/gemma-3-1b-it` instead of larger models for faster responses. The 1B model typically responds 2-3x faster.
**Check network connectivity** - Ensure stable connections to both LiveKit and Simplismart endpoints. Use `ping` and `traceroute` to diagnose network issues.
**Optimize instructions** - Shorter, more focused system instructions lead to faster generation. Aim for instructions under 200 words.
**Monitor token usage** - Longer conversations accumulate context. Consider implementing context window management to keep prompts concise.
**Verify API keys** - Double-check that your `SIMPLISMART_API_KEY` and LiveKit credentials are correct and not expired.
**Check base URLs** - Ensure you're using the correct Simplismart endpoints:
* STT: `https://api.simplismart.live/predict`
* LLM: `https://api.simplismart.live`
* TTS: `https://api.simplismart.live/tts`
**Review firewall settings** - LiveKit requires WebRTC connections which may be blocked by some firewalls. Ensure UDP ports 50000-60000 are open.
**Enable noise cancellation** - Configure noise cancellation in your audio input settings if working in noisy environments.
**Check sample rates** - Ensure your audio input matches the expected sample rate for Whisper (16kHz). Mismatched sample rates can cause quality degradation.
**Monitor bandwidth** - Poor audio quality can result from insufficient bandwidth. LiveKit automatically adjusts quality, but ensure you have at least 1 Mbps available.
**Try different TTS voices** - Simplismart offers multiple TTS models. Experiment to find the best quality for your use case.
**Verify Python version** - LiveKit agents require Python 3.11 or later (but \< 3.14). Check your version:
```bash theme={null}
python --version
```
**Use pyenv for version management** - If you need multiple Python versions:
```bash theme={null}
pyenv install 3.11.5
pyenv local 3.11.5
```
**Check async compatibility** - Ensure you're using `async`/`await` syntax correctly. LiveKit agents are fully asynchronous.
## Additional Resources
* [LiveKit Documentation](https://docs.livekit.io/) - Complete guide to LiveKit features and APIs
* [LiveKit Agents Repo](https://github.com/livekit/agents) - Source code and examples
* [Simplismart TTS Plugin for LiveKit](https://docs.livekit.io/agents/models/tts/simplismart/) - Livekit Text-to-Speech Plugin integration documentation
* [Simplismart TTS Plugin for LiveKit](https://docs.livekit.io/agents/models/tts/simplismart/) - Livekit Speech-to-Text Plugin integration documentation
* [LiveKit Community](https://community.livekit.io/) - Get help from the LiveKit community
* [Simplismart Support](https://support.simplismart.ai/) - Contact our team for deployment assistance
# Multi Control Net
Source: https://docs.simplismart.ai/guides/multi-control-net
Guide to combining ControlNets with FluxPipeline across different image generation pipelines for more guided and flexible outputs.
FluxPipeline provides support for multiple image generation pipelines with and without controlnets, including text-to-image (txt2img), image-to-image (img2img), and inpainting.
Ensure that a volume mount is added to the deployment, as all images generated are dumped inside `/data/outputs` directory in the container.
## Model Optimization Configuration
### Optimization Settings
For optimization, under the optimization config, use:
```json theme={null}
"optimisations": {
"attention_caching": {
"type": "auto",
"enabled": true,
"extra_params": {
"threshold": 0.1
}
}
}
```
* Higher threshold values result in greater speed gains but may degrade image generation accuracy.
* We recommend a threshold of 0.1, which can provide up to a 40% speed improvement during inference while maintaining reasonable quality.
## Pipeline Settings
For optimization, under the optimization config, use:
* Multiple ControlNet models can be added under the controlnets section.
* Each ControlNet model requires a name, source, and authentication details if needed.
```json theme={null}
{
"type": "flux",
"loras": [],
"lora_repo": {
"path": "",
"type": "",
"secret": {
"type": ""
},
"ownership": ""
},
"pipelines": [
"txt2img"
],
"controlnets": [
{
"name": "canny",
"source": {
"path": "InstantX/FLUX.1-dev-Controlnet-Canny",
"type": "hf",
"secret": {
"type": "hf",
"token": ""
}
}
},
{
"name": "depth",
"source": {
"path": "InstantX/FLUX.1-dev-Controlnet-Depth",
"type": "hf",
"secret": {
"type": "hf",
"token": ""
}
}
}
],
"model_choice": {
"flux_type": "flux"
},
"custom_pipeline_config": [],
"custom_pipeline_resources": ""
}
```
Here are some key pointers for understanding and structuring controlnet requests:
## Understanding ControlNet Parameters
### **ControlNet Name Convention:**
* The parameters follow a structured pattern:
```
__control_image
_weightage
```
* Example for Canny:
```
"canny_control_image" - The input image processed with the **Canny edge detection** model.
"canny_weightage" - Defines the influence of the **Canny edge map** on the final image generation.
```
* Example for Depth:
```
"depth_control_image" → The input image processed with the `Depth estimation` model.
"depth_weightage" → Determines how strongly the depth control image impacts the generation.
```
### **Extensibility for Multiple ControlNets:**
* This pattern allows easy extension to additional ControlNet models in a structured way.
* If you add a new ControlNet (e.g., OpenPose), you'd include:
```json theme={null}
"openpose_control_image": "URL_to_openpose_image",
"openpose_weightage": 0.5
```
### **How Weightage Works::**
* Each weightage parameter (canny\_weightage, depth\_weightage, etc.) determines the degree of influence that specific ControlNet has on the final image.
* Higher values make the model adhere more strictly to the control image, potentially sacrificing flexibility.
* Lower values allow more artistic freedom but reduce adherence to structured inputs.
### **Combining Multiple ControlNets:**
* You can combine multiple ControlNets in a single request to layer different structural constraints.
* In this example:
* `Canny edge detection` helps maintain sharp edges in the image.
* `Depth estimation` preserves 3D structural information.
* By adjusting the weightages, you can balance between these two influences.
### **Generalized Pattern for Other ControlNets:**
```json theme={null}
"_control_image": "",
"_weightage":
```
* Example with Pose and Normal Map:
```json theme={null}
"pose_control_image": "URL_to_pose_estimation_image",
"pose_weightage": 0.5,
"normal_control_image": "URL_to_normal_map_image",
"normal_weightage": 0.3
```
## Supported Pipelines
1. txt2img - Generates an image from text input.
2. txt2img\_controlnet - Generates an image from text input with controlnet support.
3. img2img - Generates an image based on an input image and a given prompt.
4. img2img\_controlnet - Generates an image based on an input image and a given prompt with controlnet support.
5. inpaint - Modifies specific regions of an image based on a mask and a given prompt.
6. inpaint\_controlnet - Modifies specific regions of an image based on a mask and a given prompt with controlnet support.
## Example Requests
## txt2img
```json theme={null}
{
"prompt": "A girl in city, 25 years old, cool, futuristic ",
"negative_prompt": "canvas frame, (high contrast:1.2), (over saturated:1.2), (glossy:1.1), cartoon, 3d, ((disfigured)), ((bad art)), ((b&w)), blurry, ((bad anatomy)), (((bad proportions))), ((extra limbs)), cloned face, (((disfigured))), extra limbs, (bad anatomy), gross proportions, (malformed limbs), ((missing arms)), ((missing legs)), (((extra arms))), (((extra legs))), mutated hands, (fused fingers), (too many fingers), (((long neck))), Photoshop, video game, ugly, tiling, poorly drawn hands, 3d render",
"height": 1024,
"width": 1024,
"num_images_per_prompt": 4,
"num_inference_steps": 20,
"seed": 2064977189,
"guidance_scale": 4.5,
"strength": 0.8,
"scheduler": "EULER-A",
"model_type": "txt2img"
}
```
## txt2img\_controlnet
```json theme={null}
{
"prompt": "A girl in city, 25 years old, cool, futuristic ",
"negative_prompt": "canvas frame, (high contrast:1.2), (over saturated:1.2), (glossy:1.1), cartoon, 3d, ((disfigured)), ((bad art)), ((b&w)), blurry, ((bad anatomy)), (((bad proportions))), ((extra limbs)), cloned face, (((disfigured))), extra limbs, (bad anatomy), gross proportions, (malformed limbs), ((missing arms)), ((missing legs)), (((extra arms))), (((extra legs))), mutated hands, (fused fingers), (too many fingers), (((long neck))), Photoshop, video game, ugly, tiling, poorly drawn hands, 3d render",
"height": 1024,
"width": 1024,
"num_images_per_prompt": 4,
"num_inference_steps": 20,
"seed": 2064977189,
"guidance_scale": 4.5,
"canny_control_image": "https://huggingface.co/InstantX/FLUX.1-dev-Controlnet-Canny/resolve/main/canny.jpg",
"canny_weightage": 0.4,
"depth_control_image": "https://huggingface.co/InstantX/FLUX.1-dev-Controlnet-Depth/resolve/main/depth.jpg",
"depth_weightage": 0.4,
"strength": 0.8,
"scheduler": "EULER-A",
"model_type": "txt2img_controlnet"
}
```
## img2img
```json theme={null}
{
"prompt": "cat wizard, gandalf, lord of the rings, detailed, fantasy, cute, adorable, Pixar, Disney, 8k ",
"negative_prompt": "canvas frame, (high contrast:1.2), (over saturated:1.2), (glossy:1.1), cartoon, 3d, ((disfigured)), ((bad art)), ((b&w)), blurry, ((bad anatomy)), (((bad proportions))), ((extra limbs)), cloned face, (((disfigured))), extra limbs, (bad anatomy), gross proportions, (malformed limbs), ((missing arms)), ((missing legs)), (((extra arms))), (((extra legs))), mutated hands, (fused fingers), (too many fingers), (((long neck))), Photoshop, video game, ugly, tiling, poorly drawn hands, 3d render",
"height": 1024,
"width": 1024,
"num_images_per_prompt": 4,
"num_inference_steps": 20,
"image": "https://raw.githubusercontent.com/CompVis/stable-diffusion/main/assets/stable-samples/img2img/sketch-mountains-input.jpg",
"seed": 89395930,
"guidance_scale": 7.0,
"strength": 0.5,
"scheduler": "EULER-A",
"model_type": "img2img"
}
```
## img2img\_controlnet
```json theme={null}
{
"prompt": "cat wizard, gandalf, lord of the rings, detailed, fantasy, cute, adorable, Pixar, Disney, 8k ",
"negative_prompt": "canvas frame, (high contrast:1.2), (over saturated:1.2), (glossy:1.1), cartoon, 3d, ((disfigured)), ((bad art)), ((b&w)), blurry, ((bad anatomy)), (((bad proportions))), ((extra limbs)), cloned face, (((disfigured))), extra limbs, (bad anatomy), gross proportions, (malformed limbs), ((missing arms)), ((missing legs)), (((extra arms))), (((extra legs))), mutated hands, (fused fingers), (too many fingers), (((long neck))), Photoshop, video game, ugly, tiling, poorly drawn hands, 3d render",
"height": 1024,
"width": 1024,
"num_images_per_prompt": 4,
"num_inference_steps": 20,
"image": "https://raw.githubusercontent.com/CompVis/stable-diffusion/main/assets/stable-samples/img2img/sketch-mountains-input.jpg",
"canny_control_image": "https://huggingface.co/InstantX/FLUX.1-dev-Controlnet-Canny/resolve/main/canny.jpg",
"canny_weightage": 0.4,
"depth_control_image": "https://huggingface.co/InstantX/FLUX.1-dev-Controlnet-Depth/resolve/main/depth.jpg",
"depth_weightage": 0.4,
"seed": 89395930,
"guidance_scale": 7.0,
"strength": 0.5,
"scheduler": "EULER-A",
"model_type": "img2img_controlnet"
}
```
## inpaint
```json theme={null}
{
"prompt": "Face of a yellow cat, high resolution, sitting on a park bench ",
"height": 1024,
"width": 1024,
"num_images_per_prompt": 4,
"num_inference_steps": 20,
"image": "https://raw.githubusercontent.com/CompVis/latent-diffusion/main/data/inpainting_examples/overture-creations-5sI6fQgYIuo.png",
"mask_image": "https://raw.githubusercontent.com/CompVis/latent-diffusion/main/data/inpainting_examples/overture-creations-5sI6fQgYIuo_mask.png",
"seed": 89395930,
"guidance_scale": 7.0,
"strength": 0.5,
"scheduler": "EULER-A",
"clip_skip": 0,
"use_foocus": true,
"model_type": "inpaint"
}
```
## inpaint\_controlnet
```json theme={null}
{
"prompt": "Face of a yellow cat, high resolution, sitting on a park bench ",
"height": 1024,
"width": 1024,
"num_images_per_prompt": 4,
"num_inference_steps": 20,
"image": "https://raw.githubusercontent.com/CompVis/latent-diffusion/main/data/inpainting_examples/overture-creations-5sI6fQgYIuo.png",
"mask_image": "https://raw.githubusercontent.com/CompVis/latent-diffusion/main/data/inpainting_examples/overture-creations-5sI6fQgYIuo_mask.png",
"canny_control_image": "https://huggingface.co/InstantX/FLUX.1-dev-Controlnet-Canny/resolve/main/canny.jpg",
"canny_weightage": 0.4,
"depth_control_image": "https://huggingface.co/InstantX/FLUX.1-dev-Controlnet-Depth/resolve/main/depth.jpg",
"depth_weightage": 0.4,
"seed": 89395930,
"guidance_scale": 7.0,
"strength": 0.5,
"scheduler": "EULER-A",
"clip_skip": 0,
"use_foocus": true,
"model_type": "inpaint_controlnet"
}
```
## Example Response
```json theme={null}
{
"response_id": "afbc439946a44d98bb8062c8b36ec16d",
"inference_time_taken": 6.336474418640137,
"lora_time": 1.8092551231384277,
"total_time_taken": 7.176232099533081,
"request_id": "6b060ab415d84117b7b6403d622414f5",
"error": null
}
```
## Key Notes
* Ensure volume mounting in deployment for image storage.
* ControlNet models are `not loaded by default`.
* Supports `multiple pipelines` for text-to-image, image-to-image, and inpainting.
# Multi Mode Control Net
Source: https://docs.simplismart.ai/guides/multi-mode-control-net
FluxPipeline provides support for multiple image generation pipelines with and without control nets including text-to-image (txt2img), image-to-image (img2img), and inpainting.
Ensure that a `volume mount` is added to the deployment, as all images generated are dumped inside the `/data/outputs` directory in the container.
## Optimization Settings
For optimization, under the optimization config, use:
```json theme={null}
"optimisations": {
"attention_caching": {
"type": "auto",
"enabled": true,
"extra_params": {
"threshold": 0.1
}
}
}
```
* Higher threshold values result in greater speed gains but may degrade image generation accuracy.
* We recommend a threshold of 0.1, which can provide up to a 40% speed improvement during inference while maintaining reasonable quality.
## Pipeline Settings
### For optimization, under the optimization config, use:
* Multi-mode ControlNet model can be added under the controlnets section.
* Each ControlNet model requires a name, source, and authentication details if needed.
* Instead of using multiple single-mode ControlNets, all conditioning sources are unified within a single model.
### Current Limitations
* Supports only one multi-mode ControlNet model.
* Does not support multi-mode ControlNet with additional single-mode ControlNets.
* This means if using a multi-mode model (FLUX.1-dev-ControlNet-Union-Pro), you cannot combine it with other standalone ControlNets.
```json theme={null}
{
"type": "flux",
"loras": [],
"lora_repo": {
"path": "",
"type": "",
"secret": {
"type": ""
},
"ownership": ""
},
"pipelines": [
"txt2img"
],
"controlnets": [
{
"name": "canny",
"source": {
"path": "Shakker-Labs/FLUX.1-dev-ControlNet-Union-Pro",
"type": "hf",
"secret": {
"type": "hf",
"token": ""
}
}
}
],
"model_choice": {
"flux_type": "flux"
},
"custom_pipeline_config": [],
"custom_pipeline_resources": ""
}
```
## Understanding ControlNet Parameters
### When using MultiMode Controlnet, these parameters define the multi-mode behavior:
| Parameter | Description |
| ------------------------------- | ------------------------------------------------------------------- |
| `control_image` | List of images used as conditioning (e.g., depth map, canny edges). |
| `controlnet_conditioning_scale` | List of `scaling factors` for each conditioning image. |
| `control_mode` | Defines the `influence level` for each control image. |
## Supported Pipelines
1. **txt2img** - Generates an image from text input.
2. **txt2img\_controlnet** - Generates an image based on an input image and a given prompt.
3. **img2img** - Modifies specific regions of an image based on a mask and a given prompt.
4. **img2img\_controlnet** - Generates an image based on an input image and a given prompt with controlnet support.
5. **inpaint** - Modifies specific regions of an image based on a mask and a given prompt.
6. **inpaint\_controlnet** - Modifies specific regions of an image based on a mask and a given prompt with controlnet support.
## Example Requests
### txt2img
```json theme={null}
{
"prompt": "A girl in city, 25 years old, cool, futuristic ",
"negative_prompt": "canvas frame, (high contrast:1.2), (over saturated:1.2), (glossy:1.1), cartoon, 3d, ((disfigured)), ((bad art)), ((b&w)), blurry, ((bad anatomy)), (((bad proportions))), ((extra limbs)), cloned face, (((disfigured))), extra limbs, (bad anatomy), gross proportions, (malformed limbs), ((missing arms)), ((missing legs)), (((extra arms))), (((extra legs))), mutated hands, (fused fingers), (too many fingers), (((long neck))), Photoshop, video game, ugly, tiling, poorly drawn hands, 3d render",
"height": 1024,
"width": 1024,
"num_images_per_prompt": 4,
"num_inference_steps": 20,
"seed": 2064977189,
"guidance_scale": 4.5,
"strength": 0.8,
"scheduler": "EULER-A",
"model_type": "txt2img"
}
```
### txt2img\_controlnet
```json theme={null}
{
"prompt": "A girl in city, 25 years old, cool, futuristic ",
"negative_prompt": "canvas frame, (high contrast:1.2), (over saturated:1.2), (glossy:1.1), cartoon, 3d, ((disfigured)), ((bad art)), ((b&w)), blurry, ((bad anatomy)), (((bad proportions))), ((extra limbs)), cloned face, (((disfigured))), extra limbs, (bad anatomy), gross proportions, (malformed limbs), ((missing arms)), ((missing legs)), (((extra arms))), (((extra legs))), mutated hands, (fused fingers), (too many fingers), (((long neck))), Photoshop, video game, ugly, tiling, poorly drawn hands, 3d render",
"height": 1024,
"width": 1024,
"num_images_per_prompt": 4,
"num_inference_steps": 20,
"seed": 2064977189,
"guidance_scale": 4.5,
"control_images": [
"https://huggingface.co/Shakker-Labs/FLUX.1-dev-ControlNet-Union-Pro/resolve/main/assets/depth.jpg",
"https://huggingface.co/Shakker-Labs/FLUX.1-dev-ControlNet-Union-Pro/resolve/main/assets/canny.jpg"
],
"control_weightages": [0.2, 0.4],
"control_modes": [2, 0],
"strength": 0.8,
"scheduler": "EULER-A",
"model_type": "txt2img_controlnet"
}
```
### img2img
```json theme={null}
{
"prompt": "cat wizard, gandalf, lord of the rings, detailed, fantasy, cute, adorable, Pixar, Disney, 8k ",
"negative_prompt": "canvas frame, (high contrast:1.2), (over saturated:1.2), (glossy:1.1), cartoon, 3d, ((disfigured)), ((bad art)), ((b&w)), blurry, ((bad anatomy)), (((bad proportions))), ((extra limbs)), cloned face, (((disfigured))), extra limbs, (bad anatomy), gross proportions, (malformed limbs), ((missing arms)), ((missing legs)), (((extra arms))), (((extra legs))), mutated hands, (fused fingers), (too many fingers), (((long neck))), Photoshop, video game, ugly, tiling, poorly drawn hands, 3d render",
"height": 1024,
"width": 1024,
"num_images_per_prompt": 4,
"num_inference_steps": 20,
"image": "https://raw.githubusercontent.com/CompVis/stable-diffusion/main/assets/stable-samples/img2img/sketch-mountains-input.jpg",
"seed": 89395930,
"guidance_scale": 7.0,
"strength": 0.5,
"scheduler": "EULER-A",
"model_type": "img2img"
}
```
### img2img\_controlnet
**Note** : Currently `num_images_per_prompt = 1` is supported.
```json theme={null}
{
"prompt": "cat wizard, gandalf, lord of the rings, detailed, fantasy, cute, adorable, Pixar, Disney, 8k ",
"negative_prompt": "canvas frame, (high contrast:1.2), (over saturated:1.2), (glossy:1.1), cartoon, 3d, ((disfigured)), ((bad art)), ((b&w)), blurry, ((bad anatomy)), (((bad proportions))), ((extra limbs)), cloned face, (((disfigured))), extra limbs, (bad anatomy), gross proportions, (malformed limbs), ((missing arms)), ((missing legs)), (((extra arms))), (((extra legs))), mutated hands, (fused fingers), (too many fingers), (((long neck))), Photoshop, video game, ugly, tiling, poorly drawn hands, 3d render",
"height": 1024,
"width": 1024,
"num_images_per_prompt": 1,
"num_inference_steps": 20,
"image": "https://raw.githubusercontent.com/CompVis/stable-diffusion/main/assets/stable-samples/img2img/sketch-mountains-input.jpg",
"control_images": [
"https://huggingface.co/Shakker-Labs/FLUX.1-dev-ControlNet-Union-Pro/resolve/main/assets/depth.jpg",
"https://huggingface.co/Shakker-Labs/FLUX.1-dev-ControlNet-Union-Pro/resolve/main/assets/canny.jpg"
],
"control_weightages": [0.2, 0.4],
"control_modes": [2, 0],
"seed": 89395930,
"guidance_scale": 7.0,
"strength": 0.5,
"scheduler": "EULER-A",
"model_type": "img2img_controlnet"
}
```
### inpaint
```json theme={null}
{
"prompt": "Face of a yellow cat, high resolution, sitting on a park bench ",
"height": 1024,
"width": 1024,
"num_images_per_prompt": 4,
"num_inference_steps": 20,
"image": "https://raw.githubusercontent.com/CompVis/latent-diffusion/main/data/inpainting_examples/overture-creations-5sI6fQgYIuo.png",
"mask_image": "https://raw.githubusercontent.com/CompVis/latent-diffusion/main/data/inpainting_examples/overture-creations-5sI6fQgYIuo_mask.png",
"seed": 89395930,
"guidance_scale": 7.0,
"strength": 0.5,
"scheduler": "EULER-A",
"clip_skip": 0,
"use_foocus": true,
"model_type": "inpaint"
}
```
### inpaint\_controlnet
**Note** : `Currently num_images_per_prompt = 1` is supported.
```json theme={null}
{
"prompt": "Face of a yellow cat, high resolution, sitting on a park bench ",
"height": 1024,
"width": 1024,
"num_images_per_prompt": 1,
"num_inference_steps": 20,
"image": "https://raw.githubusercontent.com/CompVis/latent-diffusion/main/data/inpainting_examples/overture-creations-5sI6fQgYIuo.png",
"mask_image": "https://raw.githubusercontent.com/CompVis/latent-diffusion/main/data/inpainting_examples/overture-creations-5sI6fQgYIuo_mask.png",
"control_images": [
"https://huggingface.co/Shakker-Labs/FLUX.1-dev-ControlNet-Union-Pro/resolve/main/assets/depth.jpg",
"https://huggingface.co/Shakker-Labs/FLUX.1-dev-ControlNet-Union-Pro/resolve/main/assets/canny.jpg"
],
"control_weightages": [0.2, 0.4],
"control_modes": [2, 0],
"seed": 89395930,
"guidance_scale": 7.0,
"strength": 0.5,
"scheduler": "EULER-A",
"clip_skip": 0,
"use_foocus": true,
"model_type": "inpaint_controlnet"
}
```
## Example Response
```json theme={null}
{
"response_id": "afbc439946a44d98bb8062c8b36ec16d",
"inference_time_taken": 6.336474418640137,
"lora_time": 1.8092551231384277,
"total_time_taken": 7.176232099533081,
"request_id": "6b060ab415d84117b7b6403d622414f5",
"error": null
}
```
## Key Notes
* Ensure volume mounting in deployment for image storage.
* ControlNet models are `not loaded by default`.
* Ensure all 3 `control_` params are sent out in request.
* Supports `multiple pipelines` for text-to-image, image-to-image, and inpainting.
# Multi Pipeline
Source: https://docs.simplismart.ai/guides/multi-pipeline
Guide to using multiple image generation pipelines with FluxPipeline on Simplismart.
FluxPipeline provides support for multiple image generation pipelines, including text-to-image (txt2img), image-to-image (img2img), and inpainting.
Ensure that a volume mount is added to the deployment, as all images generated are dumped inside `/data/outputs` directory in the container.
## Model Optimization Configuration
* The standard base configuration presented in the UI is sufficient for optimal performance.
* ControlNet models will not be loaded by default.
## Optimization Settings
For optimization, under the optimization config, use:
```json theme={null}
"optimisations": {
"attention_caching": {
"type": "auto",
"enabled": true,
"extra_params": {
"threshold": 0.1
}
}
}
```
* Higher threshold values result in greater speed gains but may degrade image generation accuracy.
* We recommend a threshold of `0.1`, which can provide up to a `40%` speed improvement during inference while maintaining reasonable quality.
## Supported Pipelines
1. **txt2img** - Generates an image from text input.
2. **img2img** - Generates an image based on an input image and a given prompt.
3. **inpaint** - Modifies specific regions of an image based on a mask and a given prompt.
## Example Requests
## txt2img
```json theme={null}
{
"prompt": "A girl in city, 25 years old, cool, futuristic ",
"negative_prompt": "canvas frame, (high contrast:1.2), (over saturated:1.2), (glossy:1.1), cartoon, 3d, ((disfigured)), ((bad art)), ((b&w)), blurry, ((bad anatomy)), (((bad proportions))), ((extra limbs)), cloned face, (((disfigured))), extra limbs, (bad anatomy), gross proportions, (malformed limbs), ((missing arms)), ((missing legs)), (((extra arms))), (((extra legs))), mutated hands, (fused fingers), (too many fingers), (((long neck))), Photoshop, video game, ugly, tiling, poorly drawn hands, 3d render",
"height": 1024,
"width": 1024,
"num_images_per_prompt": 4,
"num_inference_steps": 20,
"seed": 2064977189,
"guidance_scale": 4.5,
"strength": 0.8,
"scheduler": "EULER-A",
"model_type": "txt2img"
}
```
## Img2Img
```json theme={null}
{
"prompt": "cat wizard, gandalf, lord of the rings, detailed, fantasy, cute, adorable, Pixar, Disney, 8k ",
"negative_prompt": "canvas frame, (high contrast:1.2), (over saturated:1.2), (glossy:1.1), cartoon, 3d, ((disfigured)), ((bad art)), ((b&w)), blurry, ((bad anatomy)), (((bad proportions))), ((extra limbs)), cloned face, (((disfigured))), extra limbs, (bad anatomy), gross proportions, (malformed limbs), ((missing arms)), ((missing legs)), (((extra arms))), (((extra legs))), mutated hands, (fused fingers), (too many fingers), (((long neck))), Photoshop, video game, ugly, tiling, poorly drawn hands, 3d render",
"height": 1024,
"width": 1024,
"num_images_per_prompt": 4,
"num_inference_steps": 20,
"image": "https://raw.githubusercontent.com/CompVis/stable-diffusion/main/assets/stable-samples/img2img/sketch-mountains-input.jpg",
"seed": 89395930,
"guidance_scale": 7.0,
"strength": 0.5,
"scheduler": "EULER-A",
"model_type": "img2img"
}
```
## Inpaint
```json theme={null}
{
"prompt": "Face of a yellow cat, high resolution, sitting on a park bench ",
"height": 1024,
"width": 1024,
"num_images_per_prompt": 4,
"num_inference_steps": 20,
"image": "https://raw.githubusercontent.com/CompVis/latent-diffusion/main/data/inpainting_examples/overture-creations-5sI6fQgYIuo.png",
"mask_image": "https://raw.githubusercontent.com/CompVis/latent-diffusion/main/data/inpainting_examples/overture-creations-5sI6fQgYIuo_mask.png",
"seed": 89395930,
"guidance_scale": 7.0,
"strength": 0.5,
"scheduler": "EULER-A",
"clip_skip": 0,
"use_foocus": true,
"model_type": "inpaint"
}
```
## Example Response
```json theme={null}
{
"response_id": "afbc439946a44d98bb8062c8b36ec16d",
"inference_time_taken": 6.336474418640137,
"lora_time": 1.8092551231384277,
"total_time_taken": 7.176232099533081,
"request_id": "6b060ab415d84117b7b6403d622414f5",
"error": null
}
```
## Key Notes
* Ensure volume mounting in deployment for image storage.
* ControlNet models are not loaded by default.
* The default configuration in the UI should work optimally for most use cases.
* Supports multiple pipelines for text-to-image, image-to-image, and inpainting.
# Optimization Guide
Source: https://docs.simplismart.ai/guides/optimization-guide
## Overview
This document details all configuration parameters available for the backend server, a high-performance framework designed for serving **Large Language Models**. It covers optimization and pipeline settings, including backend selection, quantization, parallelism, and advanced features such as speculative decoding and LoRA integration, supporting over 140 configurable options for flexible and efficient model deployment.
## Table of Contents
* [Quick Start](#quick-start)
* [Optimization Configuration](#optimization-configuration)
* [Backend Settings](#backend-settings)
* [Name](#name)
* [Extra Parameters](#extra-parameters)
* [V4 Backend](#v4-backend)
* [V3 Backend](#v3-backend)
* [Model Settings](#model-settings)
* [Quantization](#quantization)
* [Optimisations](#optimisations)
* [Speculative Decoding](#speculative-decoding)
* [Parallelism](#parallelism)
* [Tensor Parallel Size](#tensor-parallel-size)
* [Pipeline Configuration](#pipeline-configuration)
## Quick Start
### Default Optimization Configuration
```json theme={null}
{
"backend": {
"name": "auto",
"version": "latest",
"extra_params": {
"enable_torch_compile": true
}
},
"warmups": {
"enabled": true,
"iterations": 5,
"sample_input_data": []
},
"model_type": "llm",
"quantization": "float16",
"optimisations": {
"model_type": "llm",
"attention_caching": {
"type": "auto",
"enabled": false,
"extra_params": {}
},
"speculative_decoding": {
"type": "auto",
"enabled": false,
"extra_params": {}
}
},
"tensor_parallel_size": 1
}
```
### Default Pipeline Configuration
```json theme={null}
{
"mode": "chat",
"type": "llm",
"loras": [],
"lora_repo": {
"path": "",
"type": "",
"secret": {
"type": ""
},
"ownership": ""
},
"load_lora_dynamic": false,
}
```
## Optimization Configuration
### Backend Settings
### Name
* **default**: "auto"
* **description**: This takes backend name to compile your model with, with value `auto`, it chooses best backend based on configuration provided.
* **values**: "auto", "v3", "v4"
### Extra Parameters
This takes dicitonary as params, and these params are the configuration for server started with backend v3 and v4
### V4 Backend
| Parameter | Type | Default | Description |
| ------------------------ | ------- | ------- | ------------------------------------------- |
| `context_length` | integer | `null` | Maximum context length for the model |
| `gpu_memory_utilization` | float | `null` | Fraction of GPU memory to reserve (0.0-1.0) |
| `max_running_requests` | integer | `null` | Maximum concurrent requests |
| `max_total_tokens` | integer | `null` | Maximum total tokens across all requests |
| `chunked_prefill_size` | integer | `null` | Chunk size for prefill processing |
| `max_prefill_tokens` | integer | `16384` | Maximum tokens processed in prefill phase |
| `reasoning_parser` | string | `null` | Parser for reasoning task outputs |
| `enable_torch_compile` | bool | `false` | Enable PyTorch 2.0 compilation |
| `torch_compile_max_bs` | integer | `32` | Max batch size for compilation |
| `cuda_graph_max_bs` | integer | `32` | Max batch size for CUDA graphs |
| `tool_call_parser` | string | `null` | Parser for function call parsing |
### Notes
* Possible Values for Reasoning Parser: `deepseek-r1`, `qwen3`
* Possible values for tool\_call\_parser: `mistral`, `llama4`, `llama3`, `qwen25`
### V3 Backend
| Parameter | Type | Default | Description |
| ------------------------ | ------- | ------- | ------------------------------------------- |
| `context_length` | integer | `null` | Maximum context length for the model |
| `gpu_memory_utilization` | float | `null` | Fraction of GPU memory to reserve (0.0-1.0) |
| `reasoning_parser` | string | `null` | Parser for reasoning task outputs |
| `tool_call_parser` | string | `null` | Parser for function call parsing |
### Notes
* Possible Values for Reasoning Parser: `deepseek_r1`, `qwen3`
* Possible values for tool\_call\_parser: `mistral`, `llama3_json`, `llama4_json`, `hermes`
## Model Settings
### Quantization
* **default**: `float16`, for no quantization
* **values**: `float16`, `float8`, `w4`
* **description**: Data type or quantization format to use for model weights. Use `float16` for standard precision, or select a quantized format for reduced memory usage.
## Optimisations
### Speculative Decoding
* **type**: "auto"
* **enabled**: true
* **extra\_params**:
* **algorithm**:
* **type**: string
* **default**: `"draft"`
* **values**: `"draft"`, `"n-gram"`, `"eagle"`, `"eagle3"`, `"nextn"`
* **description**: Decoding algorithm to use for speculative decoding.
* **draft\_model\_path**:
* **type**: string or null
* **default**: `null`
* **description**: Path to the draft model used in speculative decoding. If not set, uses the main model.
* **num\_draft\_tokens**:
* **type**: integer
* **default**: `64`
* **description**: Number of tokens to generate in each speculative draft step.
* **num\_steps**:
* **type**: integer
* **default**: `5`
* **description**: Number of speculative decoding steps to perform.
* **topk**:
* **type**: integer
* **default**: `4`
* **description**: Top-k sampling parameter for candidate selection during decoding.
* **tp\_size**:
* **type**: integer
* **default**: `1`
* **description**: Tensor parallel size for distributed speculative decoding.
## Parallelism
### Tensor Parallel Size
* **Parameter**: `tensor_parallel_size`
* **Type**: integer
* **Default**: `1`
* **Description**:\
Specifies the number of tensor parallel processes to use for model inference. Increasing this value enables the model to split its computations across multiple GPUs or nodes, which can accelerate inference and allow for larger models to be served.
* Set to `1` for no tensor parallelism (single process).
* Set to a higher integer (e.g., `2`, `4`, `8`) to enable tensor parallelism across that many devices.
* Ensure your hardware setup matches the specified `tensor_parallel_size` (e.g., you have at least as many GPUs as the value you set).
## Pipeline Configuration
* **mode**:
* **type**: string
* **default**: `"chat"`
* **values**: `"chat"`, `"completion"`, `"embedding"`
* **description**: Specifies the pipeline mode.
* `"chat"`: For conversational/chat-based interactions.
* `"completion"`: For standard text completion tasks.
* `"embedding"`: For generating vector embeddings from input text.
* **loras**:
* **type**: list of objects
* **default**: `[]`
* **description**: List of LoRA (Low-Rank Adaptation) adapters to load with the model. Each object should specify the LoRA's unique ID and its source location. See the [documentation](https://docs.simplismart.ai/guides/dynamic-lora-compilation) for more details.
* **Note**: If only 1 lora is provided then it will be merged with base model, else they will loaded dynamically.
# Whisper Deployment Guide
Source: https://docs.simplismart.ai/guides/whisper-deployment-guide
Learn how to deploy Whisper V3 for transcription and translation, featuring VAD, diarization, and advanced hallucination-reduction capabilities
## **Overview**
This API provides speech-to-text transcription and translation services using OpenAI's **Whisper V3** model with advanced features like voice activity detection (VAD), speaker diarization, and hallucination reduction.
***
## **Endpoint**
```python theme={null}
POST "/predict"
```
***
## **Authentication**
Include Bearer token in headers:
```json theme={null}
headers = {"Authorization": "Bearer YOUR_JWT_TOKEN"}
```
***
## **Request Parameters**
### **Required Parameters**
* `audio_file` (string): Audio input - either Base64-encoded audio file data or publicly accessible audio URL.
### **Core Processing Parameters**
* `language` (string): Source language code. (e.g., "hi" for Hindi, "en" for English, `None` for auto-detection)
* `task` (string): Processing task - **transcribe** (speech-to-text in same language) or **translate** (translate to English)
Here is the list of [Supported Language](https://docs.simplismart.ai/get-started/playground/transcription-models#supported-languages-with-their-codes) in the Whisper Model.
**Voice Activity Detection (VAD) Parameters**
* `vad_model` (string): VAD model to use - "`silero`" (recommended for accuracy and speed)
* `vad_onset` (float): Threshold for speech start detection (0.0-1.0, default: 0.5)
* `vad_offset` (float): Threshold for speech end detection (0.0-1.0, default: 0.3)
Need help with VAD parameter tuning or Whisper troubleshooting? \
\
Check our detailed guides on [VAD tuning](/troubleshooting-faq/vad-parameter-tuning) and [Whisper troubleshooting](/troubleshooting-faq/whisper-troubleshooting).
### **Timestamp Parameters**
* `word_timestamps` (boolean): Enable word-level timestamps in output (`true`/`false`).
* `without_timestamps` (boolean): Exclude timestamps from transcription text. Only sample text tokens from whisper model. (`true`/`false`).
### **Speaker Identification**
* `diarization` (boolean): Enable speaker Diarization to identify different speakers (true/false)
### **Hallucination Reduction**
* `strict_hallucination_reduction` (boolean): Apply post-processing filters to remove repeated phrases in the transcription (true/false)
***
## **Audio Format Support**
* **MP3**, **WAV**, **M4A**, **AAC**
* URLs must be publicly accessible or a pre-signed URL.
***
## **Example Request**
### **Option 1: Base64-encoded audio file**
```python theme={null}
import requests
import base64
import json
# Read and encode audio file
with open("audio_file.mp3", "rb") as f:
audio_data = f.read()
audio_base64 = base64.b64encode(audio_data).decode("utf-8")
# API request with base64
headers = {"Authorization": "Bearer YOUR_JWT_TOKEN"}
payload = {
"audio_file": audio_base64, # Base64-encoded audio data
"language": "hi", # Hindi audio
"task": "translate", # Translate to English
"vad_model": "silero", # Use Silero VAD
"word_timestamps": True, # Include word timestamps
"without_timestamps": False, # Keep timestamps in text
"diarization": True, # Identify speakers
"vad_onset": 0.5, # Speech detection threshold
"vad_offset": 0.3, # Speech end threshold
"strict_hallucination_reduction": True # Reduce false content
}
response = requests.post(
"/predict",
json=payload,
headers=headers
)
```
***
### **Option 2: Audio URL**
```python theme={null}
import requests
import json
# API request with URL
headers = {"Authorization": "Bearer YOUR_JWT_TOKEN"}
payload = {
"audio_file": "https://example.com/audio.mp3", # Publicly accessible audio URL
"language": "en", # English audio
"task": "transcribe", # Transcribe in same language
"vad_model": "silero", # Use Silero VAD
"word_timestamps": True, # Include word timestamps
"without_timestamps": False, # Keep timestamps in text
"diarization": False, # Single speaker
"vad_onset": 0.5, # Speech detection threshold
"vad_offset": 0.3, # Speech end threshold
"strict_hallucination_reduction": True # Reduce false content
}
response = requests.post(
"/predict",
json=payload,
headers=headers
)
```
***
## **Response Format**
### **Successful Response (200)**
```json theme={null}
{
"duration": [
3.02
],
"transcription": [
{
"text": "Hello World",
"start": 0.0,
"end": 3.02
}
],
"word_timestamps": [
{
"word": " Hello",
"start": 0.0,
"end": 0.34,
"probability": 0.92
},
{
"word": " World",
"start": 0.34,
"end": 0.6,
"probability": 0.92
}
],
"diarization": [
{
"start": 0.0,
"end": 0.34,
"text": "Hello World",
"speaker": 1
}
],
"info": {
"language": "en",
"probability": 1
},
"metrics": {
"audio_loading_preprocessing": 0.009385824203491211,
"audio_chunk": 0.014404058456420898,
"audio_prediction": 0.08741092681884766,
"audio_word_processing": 0.07052230834960938,
"audio_diarization": 0.07052850723266602,
"hallucination_reduction": 0.0004951953887939453
}
}
```
***
### **Error Response (4xx)**
```json theme={null}
{
"error": "Invalid or expired authentication token",
"code": "401"
}
```
***
### **Error Response (5xx)**
```json theme={null}
{
"error": "Internal server error",
"code": "500"
}
```
***
## **Error Codes**
* **400**: Invalid request format or parameters
* **401**: Authentication failed
* **413**: File too large
* **422**: Unsupported audio format
* **500**: Internal server error
# Overview
Source: https://docs.simplismart.ai/inference/bring-your-own-compute
Deploy and run models on your own cloud infrastructure.
Bring-your-own-compute (BYOC) allows you to use your own compute solution for deploying and running your ML models.
***
## **Benefits of BYOC**
* **Control over infrastructure**: Utilize your existing resources and configurations.
* **Cost savings**: Avoid additional costs associated with using our infrastructure.
* **Scalability**: Scale deployments according to your own infrastructure capabilities.
***
## **Deploying a model using your own compute**
To deploy your model using your own compute resources, complete the necessary prerequisite integrations and set up your workflow seamlessly on the model suite using the processes outlined below:
1. **Integrating your accounts** You can add your cloud accounts, hosted zones and create secrets for your secure information, within the [integrations](/model-suite/integrations/secrets) page.
2. **Adding your cluster** Add your compute cluster by navigating to the [Clusters](/model-suite/clusters) page and providing the necessary details.
3. **Model Optimisation**
* To optimise a model, you can either choose an available model from our [model marketplace](https://app.simplismart.ai/model-marketplace), or add your own.
* Optimise your model for deployment by visiting the [Models](/model-suite/optimise-a-model) page and using our optimisation tools.
4. **Model Deployment** Deploy your optimised model through the steps mentioned in the [Deployments](/model-suite/deployments/creating-a-deployment) page.
5. **Monitoring your deployment** Keep track of your deployment using the [monitoring tools](/model-suite/deployments/inference-and-monitoring) available on the deployments page.
6. **Running a benchmarking job** Additionally, you can perform [benchmark](/model-suite/deployments/benchmarking) your deployed model for specific scenarios.
7. **Inferencing** You can invoke your deployed models from the **API tab** of the model deployment.
For **BYOC (Bring Your Own Cloud)** deployments, pricing may vary based on your setup and resource usage. Please contact our [support team](https://support.simplismart.ai/support/tickets/new?ticket_form=ask_a_question) for pricing information.
# Dedicated Endpoint
Source: https://docs.simplismart.ai/inference/dedicated-endpoint
Deploy models on exclusive, isolated infrastructure with stable performance and full customization
Dedicated endpoints provide exclusive infrastructure for your model deployments, ensuring stable performance, reliability, and isolation from shared workloads. They also enable the deployment of **proprietary or custom models**, allowing greater flexibility in configuration, scaling, and security.
## **Benefits of using a Dedicated endpoint**
* **Dedicated resources**: No sharing of compute resources with other users.
* **Bring your own models**: Deploy your own custom or finetuned models.
* **Enhanced performance**: Improved response times and throughput.
* **Higher reliability**: Reduced risk of downtime and performance degradation.
***
## Deploying your model on a Dedicated Endpoint
To deploy your model on a dedicated endpoint, follow these outlined processes. Each step includes a link for detailed instructions, ensuring a smooth launch and use of your deployed model.
***
1. Optimise your model for deployment by visiting the [Models](/model-suite/optimise-a-model) page and using our optimisation tools.
2. You can either choose a pre-optimized model from our [Model Marketplace](https://app.simplismart.ai/model-marketplace), or add your own.
**Pre-optimized models** are faster to deploy and support one-click deployment for quick setup and usage.
You can deploy your optimised model on a dedicated endpoint by selecting your cloud provider as `Simplismart Cloud`, click here for detailed [Deployment](/model-suite/deployments/creating-a-deployment) steps.
You can invoke your deployed models from the
API tab
of the model deployment.
Want the deployment to run in your own cluster? Here's [how](/inference/bring-your-own-compute).
For dedicated endpoints, pricing depends on GPU usage, with different GPUs priced separately. For detailed pricing information, refer to the [Pricing](https://www.simplismart.ai/pricing) section on our website.
# Shared Endpoint
Source: https://docs.simplismart.ai/inference/shared-endpoint
Access models through Simplismart’s shared playground endpoints.
Shared endpoints allow you to invoke ML models using our shared infrastructure. This is a cost-effective solution for users who do not require dedicated resources.
***
## **Using a shared endpoint**
Inferencing any model on a shared endpoint is straightforward. You can directly use our [Playground](/get-started/playground/large-language-models) or perform an [API](/api-reference/introduction) call.
Want a dedicated deployment for better SLAs? Check out [**Dedicated Endpoints**](/inference/dedicated-endpoint.mdx).
For shared endpoints, pricing is determined by the number of API calls and actual usage, For detailed pricing information, refer to the [Pricing](https://www.simplismart.ai/pricing) section on our website.
# Add Container
Source: https://docs.simplismart.ai/model-suite/add-container
Add a container image from Docker Hub, Depot, Nvidia NGC, Quay, or Amazon ECR to Simplismart
Simplismart supports containers from five registries: **Docker Hub**, **Depot**, **Nvidia NGC** (for NIM containers), **Quay**, and **Amazon ECR**. This page covers setting up credentials and adding your image. Once added, see [Deploy Your Container](/model-suite/deployments/deploy-container) to configure and launch the deployment.
## Prerequisites
* A container image hosted on Docker Hub, Depot, Nvidia NGC, Quay, or Amazon ECR.
* For **private images**: credentials configured in Simplismart (see [Setting Up Registry Credentials](#setting-up-registry-credentials)).
Public Docker Hub and Quay images do not require any credentials. You can skip the credentials section and go straight to [Adding Your Image](#adding-your-image).
## Setting Up Registry Credentials
Skip this section if you are using a public image.
Navigate to **Integrations** → [**Secrets**](https://app.simplismart.ai/integrations/secrets) in your Simplismart dashboard.
Click **Create Secret** and fill in the following fields:
* **Secret Name**: A descriptive name for this secret.
* **Secret Type**: Select **Docker Hub** from the dropdown.
* **Username**: Your Docker Hub username.
* **Access Token**: Your Docker Hub access token.
Click **Save**. The secret appears in your secrets list and can be selected when adding a private image.
Navigate to **Integrations** → [**Secrets**](https://app.simplismart.ai/integrations/secrets) in your Simplismart dashboard.
Click **Create Secret** and fill in the following fields:
* **Secret Name**: A descriptive name for this secret.
* **Secret Type**: Select **Depot** from the dropdown.
* **Username**: Enter `x-token` (this is always the username for Depot).
* **Access Token**: Your Depot access token.
Click **Save**. The secret appears in your secrets list.
Navigate to **Integrations** → [**Secrets**](https://app.simplismart.ai/integrations/secrets) in your Simplismart dashboard.
Click **Create Secret** and fill in the following fields:
* **Secret Name**: A descriptive name for this secret.
* **Secret Type**: Select **Nvidia Secret Docker** from the dropdown.
* **API Key**: Your NVIDIA NGC API key.
Click **Save**. The secret appears in your secrets list and can be selected when adding an NGC image.
Only **public** Quay images are currently supported. No credentials are required. You can skip to [Adding Your Image](#adding-your-image).
Navigate to **Integrations** → [**Secrets**](https://app.simplismart.ai/integrations/secrets) in your Simplismart dashboard.
Click **Create Secret** and fill in the following fields:
* **Secret Name**: A descriptive name for this secret.
* **Secret Type**: Select **ECR** from the dropdown.
* **Secret Data**: Paste your AWS credentials in the following JSON format:
```json theme={null}
{
"region": "us-west-2",
"accessKey": "",
"secretKey": ""
}
```
Click **Create**. The secret appears in your secrets list and can be selected when adding an ECR image.
## Adding Your Image
Go to the **My Models** page and click **Bring Your Own Container**.
Fill in the fields for your registry. The **Model Name** and **GPU Per Container** fields are the same for all registries.
* **Model Name**: A descriptive name for your application.
* **Platform Type**: Select **DockerHub** from the dropdown.
* **Registry Path**: Your Docker Hub registry path (e.g. `myorg/myimage`).
* **Container Image Tag**: The image version or tag (e.g. `latest`).
* **GPU Per Container**: Number of GPUs per container. Default is `1`; maximum is `8`.
* **Registry Credentials**: Select the Docker Hub secret configured earlier. Leave blank for public images.
First, locate your registry path in Depot:
1. Go to your **Depot** dashboard and navigate to **Registry**.
2. Find your image in the **Image Reference** column. It will look like:
```
registry.depot.dev/YOUR-ORG-ID:CONTAINER-IMAGE-TAG
```
Split this into two parts:
* **Registry Path**: `registry.depot.dev/YOUR-ORG-ID` (everything before the `:`)
* **Container Image Tag**: `CONTAINER-IMAGE-TAG` (everything after the `:`)
Then fill in the model fields:
* **Model Name**: A descriptive name for your application.
* **Platform Type**: Select **Depot** from the dropdown.
* **Registry Path**: The path copied from Depot (e.g. `registry.depot.dev/YOUR-ORG-ID`).
* **Container Image Tag**: The tag copied from Depot.
* **GPU Per Container**: Number of GPUs per container. Default is `1`; maximum is `8`.
* **Registry Credentials**: Select the Depot secret configured earlier.
* **Model Name**: A descriptive name for your application.
* **Platform Type**: Select **NGC** from the dropdown.
* **Registry Path**: The NGC image path (e.g. `nvcr.io/nvidia/nim/meta/llama-3.1-8b-instruct`).
* **Container Image Tag**: The image tag (e.g. `latest`).
* **GPU Per Container**: Number of GPUs per container. Default is `1`; maximum is `8`.
* **Registry Credentials**: Select the Nvidia NGC secret configured earlier.
* **Model Name**: A descriptive name for your application.
* **Platform Type**: Select **Quay** from the dropdown.
* **Registry Path**: The Quay image path (e.g. `quay.io/myorg/myimage`).
* **Container Image Tag**: The image tag (e.g. `latest`).
* **GPU Per Container**: Number of GPUs per container. Default is `1`; maximum is `8`.
* **Registry Credentials**: Leave blank, only public Quay images are supported.
* **Model Name**: A descriptive name for your application.
* **Platform Type**: Select **Amazon ECR** from the dropdown.
* **Registry Path**: The full ECR image URI without the tag (e.g. `123456789012.dkr.ecr.us-west-2.amazonaws.com/my-repo`).
* **Container Image Tag**: The image tag (e.g. `latest`).
* **GPU Per Container**: Number of GPUs per container. Default is `1`; maximum is `8`.
* **Registry Credentials**: Select the Amazon ECR secret configured earlier.
Expand **Container Configuration** to define how the platform interacts with your container. These settings carry over to the deployment step and can be overridden there.
Click **Add HTTP**, **Add gRPC**, or **Add Monitoring** to enable the respective services.
* **HTTP Service** (Required): The port your server listens on (e.g. `8000`).
* **Public Access**: Enable to make the endpoint reachable externally. When disabled, the service is accessible only within the cluster.
* **gRPC Service**: Enable if your application uses gRPC (must use a different port than HTTP).
* **Monitoring Service**: Enable for enhanced monitoring and observability.
* **Health Check Configuration**: If any field is filled, all fields are required.
* **Health Check Path**: e.g. `/health`
* **Port**: Must match your HTTP service port.
* **Initial Delay**: Time in seconds before the first check.
* **Period**: Interval in seconds between checks.
* **Timeout**: Maximum seconds to wait for a response.
* **Environment Variables**: Runtime key-value pairs for your container.
* **Command Override**: (Optional) Custom command to replace the container's default startup command.
* **Model Endpoint**: (Optional) Inference path for observability (e.g. `/v1/chat/completions`).
Click **Add Model**. For Docker Hub, the image path is verified immediately. For other registries, the image is confirmed when the deployment starts.
Once your image is added, continue to [Deploy Your Container](/model-suite/deployments/deploy-container) to configure and launch the deployment.
# Adding a Custom Model
Source: https://docs.simplismart.ai/model-suite/adding-a-custom-model
Prepare and add a custom model or custom pipeline to the Simplismart platform.
For **custom models or custom pipelines**, you must **prepare the model configuration before adding the model to the platform**. This includes defining the model logic, dependencies, and runtime environment. The platform expects all required files to be packaged together and provided as a single artifact (a ZIP file).
This page describes how to implement the model interface, define runtime configuration, package your model, and add it through the Simplismart platform.
## Model interface (`model.py`)
Your custom model must implement a standard interface so the platform can load and run it correctly.
**Method requirements:**
* **`load()`**: Handles model initialization and weight loading
* **`preprocess()`**: Optional input preprocessing
* **`predict()`**: Core inference logic
* **`postprocess()`**: Optional output formatting
Example:
```python theme={null}
class Model:
def __init__(self):
self.model = None
def load(self):
# Initialize or load model weights
self.model = "Model Initialization"
def preprocess(self, request):
"""
Preprocess the incoming request.
Input can be a Pydantic BaseModel, dict, or string.
"""
return request
def predict(self, request):
# Run inference
output = self.model.predict()
return output
def postprocess(self, request):
# Postprocess the model output
return request
```
## Runtime configuration (`config.yaml`)
The `config.yaml` file defines the execution environment for the custom model.
| Section | Purpose |
| ----------------------- | ------------------------------------------- |
| `python_version` | Python runtime version |
| `environment_variables` | Custom environment variables (if any) |
| `requirements` | Python dependencies |
| `system_packages` | OS-level packages |
| `custom_setup_script` | Optional setup script executed during build |
Example:
```yaml theme={null}
python_version: "3.10"
environment_variables: {}
requirements:
- accelerate==0.20.3
- bitsandbytes==0.39.1
- peft==0.3.0
- protobuf==4.23.3
- sentencepiece==0.1.99
- torch==2.0.1
- transformers==4.30.2
system_packages:
- wget
- curl
custom_setup_script: "script.sh"
```
## Packaging the custom model
Before adding the model to the platform, package all required files into a single ZIP file.
Place the following in one folder:
* `model.py`
* `config.yaml`
* Any additional scripts or assets (e.g. `script.sh`)
Create a **ZIP file** containing the directory contents.
Upload the ZIP to one of the supported model sources:
* **AWS S3**
* **GCP GCS**
* **Public URL**
Upload your trained model to **AWS S3** or **GCP GCS**, share the [access credentials](model-suite/integrations/secrets), and the platform will compile and prepare it for deployment. Models built to your specifications are integrated into the platform.
## Adding the custom model to the platform
In the UI, point the platform to your ZIP, choose **Custom Pipeline** as the model type, and add the model. The platform then unpacks the archive and loads your model.
On the Simplismart platform, provide your ZIP file, choose **Custom Pipeline** as the model type, and add the model. The platform then unpacks the archive and loads your model.
Go to [**My Models**](https://app.simplismart.ai/my-models) and click **Add a Model** (top-right).
* **Model name**: A name for your model.
* **Model source**: Hugging Face, AWS S3, GCP GCS, or Public URL (use the source where you uploaded the ZIP).
* **Model path**: Path to the ZIP file (e.g. S3 URI, GCS URI, or public URL).
* If using AWS or GCP, select the linked [**Cloud credentials**](/model-suite/integrations/secrets).
Under **Model Class**, choose **Custom Pipeline** (or **Custom Model**).
Choose **Simplismart Cloud** or **Bring Your Own Cloud**. Select **Accelerator type** and machine type based on your model size and compute requirements.
Use the **Pipeline Config Editor** or **Extra Params** to tune deployment. For custom models, set `type` to `"custom"`. See the table and example below.
Click **Add Model** to start compilation. The platform unpacks the archive, sets up the environment, and loads the model.
### Extra parameters (optional)
Based on your model pipeline, you can add extra parameters in JSON format under **Extra Params**.
| Field | Type | Default | Description |
| -------------------- | ------ | ---------- | ----------------------------------------------------------------------------- |
| `workers_per_device` | Int | `1` | Parallel workers per device (higher can improve inference speed). |
| `device` | string | `cpu` | `"cpu"` or `"cuda"`. |
| `endpoint` | string | `/predict` | URL path for inference requests. |
| `type` | string | (required) | Use `"custom"` for custom models; other values: `"whisper"`, `"llm"`, `"sd"`. |
For custom models, set `type` to `"custom"` in the pipeline configuration.
Example:
```json theme={null}
{
"type": "custom",
"extra_params": {
"workers_per_device": 2,
"device": "cuda",
"endpoint": "/predict"
}
}
```
***
## Next steps
Once the model is compiled, see [Deploy a custom model](/model-suite/deployments/deploy-a-custom-model) to deploy your custom model.
# Create a Cluster
Source: https://docs.simplismart.ai/model-suite/clusters
Learn how to create a cluster on your own cloud using Simplismart, configure compute resources, and prepare for model deployments.
Through the [**Clusters**](https://app.simplismart.ai/clusters) section, you can efficiently manage your compute resources, allowing for optimal allocation and monitoring of your computational power.
## **Enter Basic Details**
* **Name**: Provide a name for your cluster. This name will become your cluster slug.
* **Cloud Account**: Select the cloud account where the cluster will be created.
* **Region**: Choose the region for your cluster.
* **Hosted Zone**: Select the appropriate hosted zone.
After entering all the necessary details, click on the **Create Cluster** button to create the cluster.
***
## Node Group Addition
* When you see the **Success** status, it means your cluster including the **Auxiliary node pool** is fully provisioned, allowing you to move forward with creating a **Node Group**.
* Click on the **Add Node Group** button on the top-right.
* **Name**: Provide a descriptive name for your node group.
* **Accelerator**: Select the appropriate accelerator for your workloads.
* **Capacity Type:** You can choose the node to be a **On Demand** instance or a **Spot instance**.
* **Machine Type**: Choose the machine size that meets your performance requirements.
* **Scaling Configuration**: Define the minimum and maximum number of nodes.
***
## **Viewing Cluster Details**
* The status will show `success` once the node group is successfully created and the cluster is now ready for use.
* Once the **Node Group** is created, you can view its information by clicking on the **Overview** tab.
* Click on the **Deploy** button to deploy the model to the node. You can find the deployment page [here](/model-suite/deployments/creating-a-deployment).
***
## **Monitoring your cluster**
You can track the overall usage and performance of your cluster to ensure optimal operation, by clicking on the **Monitor** tab.
* **Date Range**: Select the date range for which you want to view monitoring metrics.
* **Pod Info**: View detailed information about the pods in your cluster.
* **GPU and GRAM Utilization**: Monitor the usage and performance of GPUs and GRAM.
# Create AWS EKS Cluster on AWS Console
Source: https://docs.simplismart.ai/model-suite/clusters/import-cluster/create-aws-eks-cluster
Step-by-step guide to create an AWS EKS cluster and configure node groups on the AWS platform
## Overview
This guide walks you through the process of creating an AWS EKS (Elastic Kubernetes Service) cluster and setting up node groups. Follow these steps if you need to create a new cluster before importing it into the Simplismart platform.
## Prerequisites
Before starting, ensure:
* You have access to the AWS Management Console and EKS service
## Create an AWS EKS Cluster
Go to **Amazon Elastic Kubernetes Service** > **Clusters** > **Create cluster**
Go to **AWS Management Console** → **EKS**.
Click **Add Cluster** → **Create Cluster**.
* Enter a **Cluster Name** (e.g., `test-cluster`)
* Choose **Kubernetes version** (e.g., `1.33`)
* Select an existing **IAM Role** or create a new one with EKS permissions
* Click **Next**
* Choose an existing VPC or create a new one
* Select public and private subnets across different Availability Zones
* Ensure proper routing and internet access for nodes
Enable control plane logging for audit and debugging.
Click **Next**, review, and click **Create**.
⏳ Cluster creation typically takes 15–20 minutes.
For more details, check out the AWS documentation: [AWS EKS Cluster Creation Guide](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html)
***
## Create Node Groups
Once your cluster is active, you'll need to create node groups to run your workloads.
### Create a Standard Node Group
Once the cluster is active:
* In the EKS cluster view, go to **Compute** → **Add Node Group**
* Enter a **Node Group Name** (e.g., `worker-nodes`)
* Select an **IAM Role** for nodes
* Choose an **Instance Type** (e.g., `t3.large` or minimum `m6a.xlarge`) and **Node Count**
* Label nodes with:
```bash theme={null}
simplismart.ai/node-group-name: worker-nodes
```
* Click **Create**
For Simplismart platform integration, minimum machine size is `m6a.xlarge` for auxiliary node groups where cluster tools will be installed.
Create a new node group with GPU-enabled instances (e.g., `g5.xlarge`) following the same steps above, but:
* Select a GPU-enabled instance type
* Ensure NVIDIA GPU drivers are installed via DaemonSet after creation
***
## Next Steps
After creating your cluster and node groups:
Import your newly created AWS EKS cluster into the Simplismart platform
Set up Kubernetes credentials to authenticate with your cluster
## Troubleshooting
If you encounter issues during cluster creation, please refer to:
* [AWS EKS Troubleshooting Guide](https://docs.aws.amazon.com/eks/latest/userguide/troubleshooting.html)
* Contact Simplismart support at [support@simplismart.ai](mailto:support@simplismart.ai)
# E2E Cluster Import Prerequisites
Source: https://docs.simplismart.ai/model-suite/clusters/import-cluster/e2e-cloud-prerquisites
## Importing a Kubernetes Cluster from E2E Cloud
This page outlines the steps and requirements to create and import a Kubernetes cluster from the E2E cloud onto the Simplismart platform. Follow these steps to ensure your cluster is set up correctly and all necessary tooling is deployed.
## Basic Cluster Set-up & Requirements
Before importing your cluster, please ensure that it meets the following prerequisites:
## Steps to Create a Kubernetes Cluster
### 1. Navigate to the Compute Dashboard
* Go to the E2E Cloud dashboard.
* Select the Kubernetes section.
***
### 2. Create a New Kubernetes Cluster
* Click on **Get Started**.
* Enter a cluster name (e.g., `test-cluster`).
* Select an existing **VPC** or create a new one if necessary.
***
### 3. Add a Node Pool
* Click on **Add Node Pool**.
* Choose a node configuration (e.g., 3.32 GB, 1516, 32 RAM).
* **Node Labels:** Label every node in the cluster to indicate its node group. Use the following format for each node’s label:
```yaml theme={null}
simplismart.ai/node-group-name:
```
* Replace `` with the appropriate group name for the node.
* Specify the worker count (number of nodes required).
* (Optional) Add a GPU pool if required (e.g., GDC A100).
For clusters that include **GPU nodes**, verify that the *NVIDIA daemon set* is deployed. This ensures proper management and scheduling of GPU resources.
***
### **4. Create the Cluster**
* Click on **Create Cluster**.
* The cluster creation process generally takes approximately **15-20 minutes**.
The cluster should include **at least one node pool** with a minimum of **one CPU**.
### Configuring Storage (Optional)
If volume mount is needed, please follow the below steps:
* While the cluster is being created, navigate to the **Storage** section.
* Go to **Scalable File System (SFS)**.
* Click **Create**.
* Select the same **VPC** as the cluster.
* Specify the required **storage size**.
* Click **Create SFS**.
* Grant `[all]` access permissions.
* Retrieve the **IP address** of the volume and keep it handy.
***
### Post-Creation Steps
Once the cluster is created, add **Load Balancer IP (LBIP)** and **Persistent Volume Claim (PVC)**.
* Create a Persistent Volume Claim (PVC) in your cluster:
* Update the storage class to Default by adding this annotation to the storage class manifest:
```yaml theme={null}
storageclass.kubernetes.io/is-default-class":"true"
```
* Or alternatively, run this command to update the storage class:
```bash theme={null}
kubectl patch storageclass -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
```
* Allocate a Load Balancer (LB) IP pool to manage inbound traffic:
Once you have completed the above steps and your cluster has been successfully created, please follow these steps to [import your cluster](/model-suite/clusters/import-cluster/import-kubernetes-cluster).
# Import AWS EKS Cluster to Simplismart Platform
Source: https://docs.simplismart.ai/model-suite/clusters/import-cluster/import-aws-cluster
Learn how to import an existing AWS EKS cluster into the Simplismart platform and configure its settings
## Overview
This guide walks you through the process of importing an existing AWS EKS cluster into the Simplismart platform. By importing your cluster, you can leverage Simplismart's deployment, monitoring, and scaling capabilities with your existing infrastructure.
**Coming Soon**: Warmpool functionality and automatic node group creation are currently only available for clusters created directly on the Simplismart platform.
In an upcoming release, these features will be extended to imported clusters. You'll be able to provide limited IAM access, and Simplismart will manage warmpool and node group creation automatically, just like it does for Simplismart-created clusters.
## Prerequisites
Before importing your cluster, ensure you have the following:
### EKS Cluster
You need an AWS EKS cluster. If you don't already have one, follow the [Create AWS EKS Cluster](/model-suite/clusters/import-cluster/create-aws-eks-cluster) guide.
### Node Group
Your cluster must have at least one node group with minimum 1 vCPU and the required label (see below). For auxiliary node groups where Simplismart cluster tools will be installed, use a minimum machine size of `m6a.xlarge`.
#### Node Group Label
All nodes in your cluster must have the required label.
To add a label, navigate to `Amazon Elastic Kubernetes Service` > `Clusters` > `` > `` > `edit` and add a label in the format given below:
```bash theme={null}
simplismart.ai/node-group-name:
```
This label is essential for the Simplismart platform to identify and manage your nodes correctly.
If you are importing a cluster, you need to create a node group yourself on AWS. Only then you can register it on the Simplismart platform. See the [Create AWS EKS Cluster guide](/model-suite/clusters/import-cluster/create-aws-eks-cluster#create-node-groups) for detailed instructions on creating node groups with the required label.
### Kubernetes Credentials
Configure your Kubernetes credentials as a secret in Simplismart to authenticate with your AWS EKS Cluster. AWS supports both token-based and certificate-based authentication. This guide covers token-based authentication using three different approaches.
**Important Timing Constraint**: AWS EKS tokens have a 15-minute validity period. Since cluster import on Simplismart takes approximately 10 minutes, you must generate the kubeconfig credentials and start the import process within 5 minutes. If the token expires during import, the cluster import will fail with an authentication error. If this happens, simply regenerate the credentials and retry the import.
This method uses the AWS CLI to generate kubeconfig credentials programmatically.
Ensure you have AWS CLI installed and configured with appropriate credentials:
```bash theme={null}
aws configure
```
Enter your AWS Access Key ID, Secret Access Key, default region, and output format when prompted.
Update your local kubeconfig file to include the EKS cluster credentials:
```bash theme={null}
aws eks update-kubeconfig --region --name
```
Replace `` with your AWS region (e.g., `us-east-1`) and `` with your EKS cluster name.
This command will add the cluster context to your `~/.kube/config` file.
Test the connection to your cluster:
```bash theme={null}
kubectl get nodes
```
If successful, you should see a list of nodes in your cluster.
Extract the kubeconfig content to add as a secret in Simplismart:
```bash theme={null}
cat ~/.kube/config
```
Copy the entire output. You'll use this in the next step.
Go to the [Secrets](/model-suite/integrations/secrets#json-format-for-adding-secrets) section in Simplismart and:
* Click on the **Kubernetes** tab
* Add a new secret with the kubeconfig content you copied
* Follow the detailed configuration instructions in the Secrets documentation
This method uses the AWS Management Console to retrieve cluster connection information and build the kubeconfig manually.
* Open the **AWS Management Console**
* Go to **Amazon EKS** service
* Select your cluster from the list
In the cluster details page, note down the following:
* **API server endpoint**: Found in the **Configuration** tab
* **Certificate authority data**: Found in the **Configuration** tab (click "Show" to reveal)
Copy both values—you'll need them to construct the kubeconfig.
Create a kubeconfig file with the following structure:
```yaml theme={null}
apiVersion: v1
kind: Config
clusters:
- cluster:
certificate-authority-data:
server:
name:
contexts:
- context:
cluster:
user:
name:
current-context:
users:
- name:
user:
exec:
apiVersion: client.authentication.k8s.io/v1beta1
command: aws
args:
- eks
- get-token
- --cluster-name
-
- --region
-
```
Replace the placeholders:
* ``: Certificate authority data from Step 2
* ``: API server endpoint from Step 2
* ``: Your EKS cluster name
* ``: Your AWS region (e.g., `us-east-1`)
Save the kubeconfig file and test the connection:
```bash theme={null}
export KUBECONFIG=/path/to/your/kubeconfig
kubectl get nodes
```
If successful, you should see a list of nodes in your cluster.
Go to the [Secrets](/model-suite/integrations/secrets#json-format-for-adding-secrets) section in Simplismart and:
* Click on the **Kubernetes** tab
* Add a new secret with the kubeconfig content you created
* Follow the detailed configuration instructions in the Secrets documentation
This method uses eksctl, a simple CLI tool for creating and managing EKS clusters.
If you haven't installed eksctl yet, follow the [eksctl installation guide](https://eksctl.io/installation/).
For macOS:
```bash theme={null}
brew tap weaveworks/tap
brew install weaveworks/tap/eksctl
```
For Linux:
```bash theme={null}
curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp
sudo mv /tmp/eksctl /usr/local/bin
```
Use eksctl to write the cluster credentials to your kubeconfig:
```bash theme={null}
eksctl utils write-kubeconfig --cluster --region
```
Replace `` with your EKS cluster name and `` with your AWS region.
This will automatically update your `~/.kube/config` file.
Test the connection to your cluster:
```bash theme={null}
kubectl get nodes
```
If successful, you should see a list of nodes in your cluster.
Extract the kubeconfig content:
```bash theme={null}
cat ~/.kube/config
```
Copy the entire output.
Go to the [Secrets](/model-suite/integrations/secrets#json-format-for-adding-secrets) section in Simplismart and:
* Click on the **Kubernetes** tab
* Add a new secret with the kubeconfig content you copied
* Follow the detailed configuration instructions in the Secrets documentation
For production environments, it's recommended to create a dedicated IAM role with minimal required permissions for Simplismart access, rather than using admin credentials.
***
## Import Cluster
Provide the following information about your cluster:
| Field | Description |
| ---------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| **Cluster Name** | A unique name to identify your cluster in the Simplismart platform |
| **Cloud Provider** | Select AWS as your cloud provider |
| **Secret** | Select a secret to authenticate with AWS. See the [Secrets](/model-suite/integrations/secrets) section for configuration details |
| **Region** | The AWS region where your EKS cluster is deployed |
| **Hosted Zone** | The DNS hosted zone for your cluster. See [Hosted Zone](/model-suite/integrations/hosted-zone) documentation |
| **Environment** | Select your environment type: Production, Development, Demo, or Custom |
| **Custom Environment Description** | Provide a description if you selected "Custom" environment |
Select the tools to install on your cluster during the import process. All tools shown below are mandatory for core cluster functionality.
### Scaling Tools
Collects basic pod and node resource usage (CPU/memory) to enable Kubernetes Horizontal Pod Autoscaling and efficient resource management.
Automatically adds or removes nodes in your cluster based on workload demand, optimizing costs by scaling infrastructure dynamically.
The [Prometheus Adapter](https://github.com/kubernetes-sigs/prometheus-adapter) is a fallback in case we want to switch to use HPA and scale based on number of requests or custom metrics.
Our main event-driven autoscaler that scales applications based on workload activity (e.g., queue length, message count), improving performance and reducing costs during idle periods. It is required for scale to 0.
### Observability Tools
Long-term metrics storage system that provides reliable, scalable storage for time-series data, enabling historical analysis and trend monitoring.
Centralized log aggregation system that collects and stores logs from all applications, making it easy to search, filter, and debug issues across your cluster.
Log shipping agent that collects logs from your applications and forwards them to Loki, making all logs searchable in the Simplismart platform.
Complete monitoring solution providing dashboards, metrics collection, and alerting capabilities to monitor workload health and system performance.
GPU monitoring tool that tracks NVIDIA GPU utilization, temperature, and health metrics, essential for optimizing AI/ML workloads.
Simplismart's internal monitoring agent that collects operational metrics and system health data like disk pressure, node readiness, degraded pod, etc for platform integration.
Configure your node groups to be managed by the Simplismart platform. Node group configuration allows you to manage your cluster resources based on workload types, hardware requirements, and scaling policies.
Using the given configuration, Simplismart is able to intelligently manage the nodes and effectively distribute the resources.
### Node Group Label
Provide the node group label you configured earlier in the [Prerequisites](#node-group-label) section. This label allows Simplismart to identify and manage your node group.
You can register multiple node groups with different configurations to use your cluster resources effectively on the Simplismart platform.
### Node Group Configuration
Enable **Use Node Group Configuration** to have Simplismart automatically allocates the resource during the deployment. If not selected, you need to provide node configuration every time you deploy.
| Field | Description |
| --------------------- | -------------------------------------------------------------------- |
| **Accelerator Type** | Select either **CPU** or **GPU** based on your workload requirements |
| **Accelerator Count** | Number of accelerators (GPUs) per node |
| **Min Node Count** | Minimum number of nodes to maintain in this node group |
| **Max Node Count** | Maximum number of nodes allowed in this node group for autoscaling |
| **CPU** | Number of CPU cores per node |
| **Memory** | Memory allocation in GB per node |
When this option is enabled, Simplismart will manage the specified node group in your EKS cluster based on the resource configuration provided. The node group must already exist in your cluster.
### Auxiliary Node Group
Enable **Mark as Auxiliary** if this node group should be reserved for supporting workloads rather than primary AI/ML operations.
**Common use cases for auxiliary node groups:**
* Monitoring and logging services (refer to Step 2 for details)
* Internal tooling and platform services
Add custom tags to manage and identify your cluster for billing, cost allocation, and resource management. Tags will be auto-populated in the [billing](/model-suite/settings/billing) section as well as the event center for better tracking and visualization. Moreover, you can create environment tags for Testing, Staging or Production based on your requirements. Environment specific tags will help you in billing and how much each environment is generating the bills.
Click **Add Tag** and provide key-value pairs as needed.
***
## Post-Import Steps
After successfully importing your cluster, follow these steps to get started:
Check that the cluster status shows as "Success" in the Simplismart dashboard. Verify all cluster tools are running correctly.
Start deploying AI/ML models to your imported cluster using the Simplismart platform.
Use the observability tools (Grafana, Prometheus, Loki) to monitor cluster health and performance metrics.
Deploy custom Docker containers to your cluster for custom models.
***
## Deployment Capabilities
### Current Support
Imported clusters currently support **container-based deployments**. You can deploy Docker/Depot containers with full integration into the Simplismart platform, including:
* Monitoring via the observability stack (Grafana, Prometheus, Loki)
* Auto-scaling via the scalability stack (Metrics Server, Cluster Autoscaler, KEDA)
* Resource management and optimization
### Coming Soon
In future releases, imported clusters will support:
Full support for custom Helm chart deployments with complete lifecycle management. Your Helm deployments will be:
* **Fully monitored** via the Simplismart observability stack
* **Fully scalable** via the Simplismart scalability stack
Once warmpool support is enabled for imported clusters, you'll benefit from:
* **Rapid auto-scaling** for faster response to workload demands
* **Reduced cold-start times** through pre-warmed resources
* **Same capabilities** as clusters created directly on the Simplismart platform
This will enable the same rapid scaling performance you get with Simplismart-created clusters.
***
## Troubleshooting
If you encounter issues during the cluster import process, please feel free to reach out to our support team at [support@simplismart.ai](mailto:support@simplismart.ai).
# Import a Kubernetes Cluster
Source: https://docs.simplismart.ai/model-suite/clusters/import-cluster/import-kubernetes-cluster
Learn how to import your existing Kubernetes cluster into the Simplismart platform
This guide walks you through the process of importing your existing Kubernetes cluster into Simplismart. Before proceeding, ensure your cluster meets the [cloud-specific prerequisites](/model-suite/clusters/import-cluster/e2e-cloud-prerquisites).
## Prerequisites
Before importing your cluster, make sure you have:
* A Kubernetes cluster that meets the cloud-specific requirements
* Administrative access to create secrets and configure node groups
* Your cluster credentials and configuration details
## Step 1: Create a Kubernetes Secret
To securely connect Simplismart to your cluster, you'll need to create a Kubernetes secret:
1. Navigate to the [Secrets](/model-suite/integrations/secrets) tab in the sidebar
2. Click **Create Secret** and select the type as Kubernetes.
3. Enter your cluster credentials and configuration
Ensure your secrets are formatted correctly. Refer to the [Cloud specific format guide](/model-suite/integrations/secrets#json-format-for-adding-secrets) for proper structure.
## Step 2: Import the Cluster
Now you're ready to import your cluster into Simplismart:
1. Navigate to the **Clusters** tab
2. Click **Import Cluster**
3. Fill in the required information:
### Basic Configuration
* **Cluster Name**: Provide a descriptive name for your cluster
* **Cloud Provider**: Select your cloud provider (AWS, GCP, Azure, OCI, etc.)
* **Region**: Specify the region where your cluster is hosted
* **Secret**: Choose the Kubernetes secret you created in Step 1
* **Environment**: Select your deployment environment:
* `Development`
* `Production`
* `Demo Environment`
* `Others`
## Step 3: Configure Cluster Tools
Select the appropriate tools based on your use case:
* **Training Tools**: For model training jobs
* **Observability Tools**: For monitoring and logging
* **Async Tools**: For asynchronous task management
* **Scaling Tools**: For auto-scaling capabilities
## Step 4: Register Node Groups
Configure your node groups to define the compute resources available for deployments.
### Node Group Labels
Provide the labels that identify your node groups:
* Use the format: `simplismart.ai/node-group:`
* These labels must match the labels applied to your nodes in the existing cluster
* Labels help Simplismart understand how to organize and schedule workloads
### Node Configuration
Specify the following details for each node group:
**GPU Configuration**
* **GPU Type**: Select the GPU model available on your node group (e.g., A100, V100, T4)
* **GPU Count**: Number of GPUs attached to each node
**Scaling Configuration**
* **Minimum Nodes**: Minimum number of nodes in the group
* **Maximum Nodes**: Maximum number of nodes for auto-scaling
**Resource Allocation**
* **vCPU**: Number of virtual CPUs available per node
* **Memory**: Amount of RAM available per node (in GB)
The vCPU and memory values are critical as they determine the maximum resources that can be allocated during deployments on your cluster. Ensure these values accurately reflect your node specifications.
## Step 5: Automated Dependency Deployment
Once you complete the import process, Simplismart automatically deploys essential infrastructure components to your cluster:
* **Deployment Controller**: Manages model deployment lifecycle
* **Cert Manager**: Handles TLS certificates
* **NGINX Ingress Controller**: Routes external traffic to your deployments
* **Additional Dependencies**: Other tooling required for platform operations
## Frequently Asked Questions
The cluster import will fail if your secret is improperly formatted. Follow the [cloud-specific format guide](/model-suite/integrations/secrets#json-format-for-adding-secrets) and ensure all required fields (tokens, certificates, keys) match the expected structure for your cloud provider.
To delete a cluster, contact [support@simplismart.ai](mailto:support@simplismart.ai). During deletion:
* All tools installed by Simplismart will be removed from your cluster
* Your cluster will continue running on your original cloud platform
* Only the Simplismart integration components are removed
Simplismart will not be able to detect your node groups. Each node must have the label in the following format:
```
simplismart.ai/node-group:
```
Apply these labels to your nodes before importing the cluster to ensure proper node group detection.
No, node group configurations cannot be modified after import. The following settings are locked during the import process:
* GPU type
* GPU count per node
* vCPU allocation
* Memory allocation
* Scaling limits (min/max nodes)
If you need to change these settings, you'll need to reimport the cluster.
Mismatched configurations can cause serious issues:
* Deployment scheduling failures
* Incorrect resource allocation
* Under or over-provisioning of resources
Always enter the exact specifications of your cluster nodes to ensure accurate resource management and scheduling.
Simplismart automatically deploys the following essential components to your cluster:
* **Deployment Controller**: Manages model deployment lifecycle
* **Cert Manager**: Handles TLS certificate management
* **NGINX Ingress Controller**: Routes external traffic to deployments
* **Additional infrastructure components**: Required for platform operations
These tools are mandatory and cannot be skipped during the import process.
The automated deployment process typically takes 5-10 minutes. Monitor the progress in the Clusters dashboard.
Simplismart installs its own versions of these tools. If your cluster has conflicting versions, you may experience issues with:
* Traffic routing
* TLS certificate management
* Deployment orchestration
**Best Practice**: Isolate Simplismart's tools in separate namespaces to prevent conflicts with your existing infrastructure.
For each node group, you must specify:
* **GPU Type**: The GPU model installed (e.g., A100, V100, T4, A10, H100)
* **GPU Count**: Number of GPUs attached to each node
This information determines which models can be scheduled on your cluster and ensures optimal resource allocation.
Yes, you can import a CPU-only cluster. However:
* GPU-accelerated model deployments will not be possible
* You can only deploy CPU-based models
* GPU node groups can only be added during the initial import, not afterward
If you plan to deploy GPU models in the future, ensure you include GPU node groups during the import process.
Common mistakes to avoid:
* **Mixed authentication methods**: Don't combine token and certificate-based authentication in secrets
* **Incorrect node specifications**: Ensure vCPU, memory, and GPU counts match your actual nodes
* **Missing node labels**: All nodes must have the required `simplismart.ai/node-group` labels
* **Expired credentials**: Verify your cluster credentials are current and valid
* **Mismatched regions**: Ensure the region specified matches your cluster's actual location
Once the import is successful, your cluster becomes fully operational in Simplismart. You can:
* [Deploy models](/model-suite/deployments/deploy-on-an-imported-cluster) to your imported cluster
* Monitor cluster health and resource utilization
* View deployment logs and metrics
* Scale your deployments based on configured node groups
Note that node group configurations are locked after import and cannot be modified later.
## Next Steps
After successfully importing your cluster, you can:
* [Deploy models](/model-suite/deployments/deploy-on-an-imported-cluster) on your imported cluster
* Configure additional node groups as needed
* Set up monitoring and observability tools
* Manage cluster resources and scaling policies
# Autoscaling
Source: https://docs.simplismart.ai/model-suite/deployments/autoscaling
How Simplismart automatically grows and shrinks your deployment's pods to match demand
Every deployment runs on a number of pods. Each pod is a running copy of your model, ready to serve requests. Too few pods, and requests queue up while response times climb. Too many, and you're paying for GPU capacity that sits idle. Autoscaling keeps this balanced automatically — Simplismart monitors your traffic and adds or removes pods accordingly.
**If you're just getting started:** you don't need to read this whole page to configure autoscaling. Choose a metric and a threshold on the deployment form and leave the rest at their defaults — see [Picking a starting point](#picking-a-starting-point) for sensible defaults by workload type. The rest of this page explains the reasoning behind that behavior, for when you need finer control.
This page walks through how autoscaling decides to add or remove pods. For the step-by-step form fields, see [Creating a Deployment](/model-suite/deployments/creating-a-deployment).
Pick the metric, threshold, and min/max range that drive scaling.
Guarantee capacity for traffic patterns you already know about.
Control how fast pods are added or removed once a threshold is crossed.
Drop idle deployments to 0 pods and stop paying for them.
## How it decides
At regular intervals, Simplismart checks one number — your chosen metric — against a target you've set, called the **threshold**. If the number is above the threshold, it adds pods. If it's below, it removes pods. At the threshold, it leaves things as they are.
Two settings bound this decision on either side:
* **Min pods** — the floor. Your deployment never drops below this, even at zero traffic, unless Scale to Zero is enabled (covered below).
* **Max pods** — the ceiling, capped by your account quota. Your deployment never grows past this, regardless of demand.
The metric determines the direction; min and max determine how far it's allowed to go.
```mermaid theme={null}
flowchart LR
A["Measure metric\n(Memory · Latency · Throughput · Concurrency)"] --> B{"Above or below\nthreshold?"}
B -- "Above" --> C["Candidate: scale up"]
B -- "Below" --> D["Candidate: scale down"]
C --> E["Autoscaling Policy\nhow fast, how much"]
D --> E
E --> F["Min / Max pods\nhard limits"]
F --> G["Pod count applied"]
```
### Choosing a metric
The metric is simply the number autoscaling watches. It falls into one of two categories:
* **Resource metrics** describe the pod itself — how hard the CPU or GPU is working, how much memory it's using.
* **Request-shape metrics** describe your traffic — how many requests are arriving, how quickly they're answered.
If you're unsure where to start, use **Concurrency** as your primary metric with **GPU Utilization** as a backup. This combination works well for most model deployments.
**Resource metrics**
| Metric | What it measures | Good fit for... |
| -------------------- | ----------------------------------------------- | ------------------------------------------------------------------------------------- |
| **CPU Utilization** | Average CPU usage across all pods | Workloads that lean on CPU, like pre/post-processing or tokenization |
| **GPU Utilization** | Average GPU compute usage across all pods | Inference that's GPU-bound, where compute (not memory) is the bottleneck |
| **Memory Usage** | Average system memory across all pods | Catching memory leaks or workloads whose memory use keeps growing |
| **GPU Memory Usage** | Average GPU memory (VRAM) usage across all pods | Getting an early warning before pods run out of VRAM (big batches, long-context LLMs) |
**Request-shape metrics**
| Metric | What it measures | Good fit for... |
| --------------- | --------------------------------------------- | ----------------------------------------------------------------------------- |
| **Concurrency** | How many requests are being handled right now | Bursty traffic made of many short requests |
| **Latency** | How long each response takes | Chat or voice, where you'd rather add pods early than let responses slow down |
| **Throughput** | Requests handled per second | Steadier traffic, where total volume matters more than any one request |
Some model runtimes expose a few extra specialized metrics too (like queue depth for async workers). Available metrics can vary by model and container type — see [Scaling Parameters](/model-suite/deployments/creating-a-deployment#scaling-parameters) for the exact list on your deployment.
Whichever metric you choose, the **threshold** is the value that determines the direction: above it, pods are added; below it, pods are removed.
## Try it: the autoscale console
Scaling up and scaling down are deliberately asymmetric. Simplismart adds pods quickly when demand rises, so requests don't queue. It removes pods more cautiously, so a brief lull doesn't remove a pod you need again moments later.
The console below runs a live simulation rather than a static illustration. Choose a traffic pattern, adjust the sliders, and watch the pod count respond in real time — no deployment required.
Two things worth exploring once it's loaded:
* The **Scaling ledger** logs every scale event as it happens. Select the **Flapping** pattern with a short scale-down period, and the ledger will flag (in rose) a scale-down that occurs sooner than expected. This is a real effect, explained in the next section.
* Under **Advanced settings**, enable **Schedule window**. It guarantees a minimum pod count during a time window you define, regardless of what the traffic metric shows — you'll see it hold that floor (shaded on the chart) and return control to standard scaling once the window ends.
Notice the shape of the two lines: traffic snaps up and pods follow within a step or two, but on the way down the pod line descends in a staircase, spread out well after traffic has already dropped. That staircase is controlled by the **Autoscaling Policy**, covered next.
## Controlling the speed: Autoscaling Policy
By default, Simplismart scales between your min and max pods with no additional rate-limiting — most deployments don't need to change this. **Autoscaling Policy** is an optional, advanced layer for controlling *how fast* pods are added or removed:
* **Stabilization window** — how long the autoscaler observes the metric before acting, so a brief spike or dip doesn't trigger a decision it would otherwise reverse moments later. Scale-up defaults to a short `60s` window (react quickly); scale-down defaults to a longer `180s` window (avoid overreacting to a blip).
* **Policies** — the size of each step: a fixed number of **Pods**, or a **Percent** of the current count, taken over a **Period** of time (1–1800s).
For most deployments, this is all you need to know — see [Autoscaling Policy](/model-suite/deployments/creating-a-deployment#autoscaling-policy) for the full field reference. The remainder of this section covers one setting that's easy to misread: the scale-down **Period**.
### A subtlety in the scale-down period
A policy such as *"remove 1 pod every 1200 seconds"* reads like a strict rate limit — one pod removed per 20-minute window, no exceptions. In practice, a second pod can be removed well before that window is up, if your traffic has been fluctuating.
**Why:** the autoscaler doesn't simply track time since the last scale-down. It looks at every scaling event — both additions and removals — within the trailing period, and a recent addition effectively offsets an earlier removal in that calculation. So if your metric has been crossing the threshold repeatedly, a scale-down can become eligible again well before the period would suggest.
You can observe this directly in the [console above](#try-it-the-autoscale-console): select **Flapping**, set a short scale-down period, and watch the ledger flag it in real time.
Here's what actually happens with a `1 pod / 1200s` (20 min) scale-down policy:
| Time | Event |
| ----- | ------------------------------- |
| 16:53 | Scale down |
| 16:54 | Scale up |
| 16:55 | Scale up |
| 17:05 | Check: can we scale down again? |
| 17:07 | Check: can we scale down again? |
**At 17:05** — currently at 4 pods. The trailing 1200s window holds 1 down and 2 ups.
`periodStartReplicas = 4 − 2 + 1 = 3`, so the floor is `3 − 1 = 2`. Scaling to 3 keeps us at 3 ≥ 2 → **allowed**. Pods go 4 → 3.
**At 17:07** — currently at 3 pods. The window now holds 2 downs and 2 ups.
`periodStartReplicas = 3 − 2 + 2 = 3`, so the floor is still `3 − 1 = 2`. Scaling to 2 keeps us at 2 ≥ 2 → **allowed**. Pods go 3 → 2 — just **2 minutes** after the previous scale-down, inside a policy meant to allow one pod removed every 20 minutes.
**How to mitigate it:**
* Give your threshold some headroom rather than tuning it to the exact edge, so ordinary noise doesn't flip the decision repeatedly.
* If your traffic is naturally variable, a smoother metric (such as Throughput) will trigger this less often than a spikier one (such as instantaneous Latency).
* Treat the period as a lookback window the autoscaler uses for its calculation, not as a timer that resets cleanly after each scale-down.
## Scale to Zero
Well suited to deployments that sit idle for extended periods — development and test environments, low-traffic endpoints. When there's no incoming traffic, **Scale to Zero** reduces your pod count to 0, so you stop paying for GPU capacity entirely. When a request arrives, a pod starts automatically, with a brief cold-start delay while it comes up. A **cooldown period** controls how long the deployment waits after traffic stops before scaling to zero, so a short pause doesn't trigger an unnecessary cold start.
Scale to Zero and Schedule-Based Autoscaling's "scale to 0 outside windows" option are mutually exclusive — use whichever fits how predictable your traffic is.
## Rapid Autoscaling
For sudden traffic bursts, **Rapid Autoscaling** reacts faster than the standard evaluation windows allow, reducing the latency spike that would otherwise occur while new pods are still starting up.
Rapid Autoscaling is available on Simplismart Cloud (Dedicated) deployments only. Contact [support@simplismart.tech](mailto:support@simplismart.tech) to enable it.
## Schedule-Based Autoscaling
If you already know your traffic pattern in advance — busy during office hours, quiet overnight, a recurring batch job — you don't need to rely on metrics for those periods. Define a time window with a guaranteed minimum pod count, and the deployment falls back to standard scaling (or zero) outside it. If a window and the regular metric-based scaling disagree, **whichever calls for more pods wins** — a window sets a floor, never a ceiling.
To see this in the [console above](#try-it-the-autoscale-console), open **Advanced settings** and enable **Schedule window**. The window appears shaded on the chart, and the pod count moves to the guaranteed minimum the instant the window opens, with none of the usual wait.
See [Schedule-Based Autoscaling](/model-suite/deployments/creating-a-deployment#schedule-based-autoscaling) for how to configure this, with both a guided picker and cron expressions.
## Picking a starting point
| Workload | Metric | Min pods | Scale to Zero | Notes |
| ---------------------------------- | --------------------------- | ---------------------- | ------------- | ------------------------------------------------------------- |
| Interactive chat / voice | Latency or Concurrency | ≥ 1 | Off | Avoid cold starts on the user-facing path |
| Bursty, cost-sensitive dev/test | Concurrency | 0 | On | Let it drop to zero between tests |
| Steady high-volume batch inference | Throughput or Memory | Sized to baseline load | Off | Default Autoscaling Policy is usually fine |
| Predictable business-hours traffic | Schedule-Based + any metric | Set per window | Depends | Use windows for the known pattern, metrics for the unexpected |
These are starting points, not rules — tune each setting against your own traffic once the deployment is live.
## Configuring autoscaling
* [Creating a Deployment](/model-suite/deployments/creating-a-deployment) walks through every field on the deployment form, including Scaling Parameters, Schedule-Based Autoscaling, and Autoscaling Policy.
* [Editing a Deployment](/model-suite/deployments/edit-deployment) covers adjusting any of these settings after the deployment is already live, applied as a rolling update.
# Creating a Deployment
Source: https://docs.simplismart.ai/model-suite/deployments/creating-a-deployment
Steps to guide you through the process of creating a Deployment
Deployments are scoped to the active workspace. If your organisation has more than one workspace, use the workspace toggle in the breadcrumb navigation to switch to the target workspace before continuing. If you only have the **Default** workspace, you can skip this step. New deployments will be created under the `Default` workspace only. See [Workspaces](/model-suite/settings/workspaces) for details.
From the main menu, select the [**Deployments**](https://app.simplismart.ai/deployments) tab and click **Create** to start a new deployment.
Fill in the following fields:
* **Deployment Name**: Provide a unique name for your deployment.
* **Model**: Choose the model you want to deploy from the dropdown.
* **Cloud**: Select **Simplismart Cloud** to deploy as a [Dedicated Endpoint](/inference/dedicated-endpoint), or **BYOC** to deploy on your own [cluster](/model-suite/integrations/cloud-account).
You can browse and select from available models in the [My Models](/model-suite/optimise-a-model).
New to autoscaling? [Autoscaling](/model-suite/deployments/autoscaling) covers how the scaling metric, threshold, and Autoscaling Policy fields below interact, before you configure them here.
**For dedicated deployments** please ensure you have enough [quota](/model-suite/settings/quotas) of the desired resources.
Choose the desired accelerator type based on your model size and SLA requirements.
To deploy on a GPU type not listed or for CPU-only deployments, email [support@simplismart.tech](mailto:support@simplismart.tech).
SSH access lets you connect directly to a running container in your deployment, which is useful for debugging, inspecting logs, or running ad-hoc commands without rebuilding and redeploying.
Toggle **SSH Access** on during deployment creation to configure it. You can add up to 5 users per deployment, choose the SSH runtime (sidecar or main container), and assign an SSH key secret to each user.
For runtime options, bringing your own image, generating a key pair, and connecting to a running deployment, see the [SSH Access guide](/model-suite/deployments/ssh-access).
Define how your deployment scales based on demand:
* **Range**: Minimum and maximum number of instances. The limits are governed by your account quota.
* **Scaling Metric**: The metric used to trigger scaling. Choose from:
* **Memory Usage**: Average memory usage across all pods.
* **Latency**: Response time per request.
* **Throughput**: Number of requests processed per second.
* **Concurrency**: Number of concurrent requests being processed.
Available scaling metrics may vary depending on the model type.
* **Threshold**: The metric value that triggers a scaling event for both scale-out and scale-in (e.g. scale out at 80% memory, scale in when it drops back below the threshold).
**Advanced Options**
* **Enable Scale to Zero**: Scales the deployment down to zero instances when there is no incoming traffic, reducing idle costs. When traffic resumes, the deployment scales back up automatically.
* **Cooldown Period**: The amount of time (in seconds) to wait after traffic stops before scaling down to zero. A longer cooldown avoids premature scale-downs during brief traffic lulls.
**Enable Rapid Autoscaling**
Rapid Autoscaling allows your deployment to scale out significantly faster during sudden traffic bursts.
Rapid Autoscaling is available on Simplismart Cloud (Dedicated) deployments only. To enable it, contact [support@simplismart.tech](mailto:support@simplismart.tech).
Enable **Schedule Based Scaling** when you know your traffic pattern in advance. For example, if most of your load arrives on weekdays during office hours, you can define time windows for those periods and let the deployment scale to zero, or fall back to a lower replica count, outside them.
**Schedule Based Scaling** and **Enable Scale to Zero** (in the Advanced Options of Scaling Parameters) are mutually exclusive. Use the **Scale to 0 outside windows** option below if you want pods to scale to zero on a schedule.
**Scale to 0 outside windows**
Choose what happens outside your configured windows:
| Setting | Outside windows | Endpoint behaviour |
| ------------ | ------------------------------------------------------------------------ | ----------------------------------------------------------------- |
| **Enabled** | Deployment runs **0 pods**. It wakes up at the start of the next window. | Returns **503 Service Unavailable** until the next window starts. |
| **Disabled** | Deployment falls back to your standard min/max replicas. | Continues to serve traffic. |
Pick **Disabled** if the endpoint must accept requests outside windows.
**Configuring windows**
Each window defines a time range during which a guaranteed minimum number of pods is maintained. Click **+ Add Window** to add more windows. When multiple rules are active (schedule windows, overlapping windows, standard scaling), whichever produces the **higher pod count** wins at any given time. The cool-down period is fixed at **5 minutes** and cannot be modified.
Each window can be configured using either the **Guided** visual picker or **Custom** cron expressions:
Use the visual picker to configure your schedule:
* **Timezone**: the timezone for interpreting wake-up and cool-down times.
* **Days**: select one or more days of the week (Mon–Sun).
* **Wake up at**: the time at which pods scale up to the configured minimum.
* **Cool down at**: the time at which pods begin scaling down.
* **Minimum Pods during window**: number of pods guaranteed during the window (1–8).
Enter cron expressions directly for more flexibility:
* **Timezone**: the timezone for interpreting the cron schedule.
* **Start**: cron expression for when pods scale up (e.g. `0 9 * * 1,2,3,4,5` for 09:00 AM on weekdays).
* **End**: cron expression for when pods scale down (e.g. `0 18 * * 1,2,3,4,5` for 06:00 PM on weekdays).
* **Minimum Pods during window**: number of pods guaranteed during the window (1–8).
A human-readable summary of each cron expression is shown below the input field.
Fine-tune how aggressively your deployment scales up and down by configuring policies and stabilization windows for each direction. This controls the *rate* of pod changes once the scaling metrics cross their configured thresholds.
**Scale Up**
Controls how quickly new pods are added when demand rises above the scaling threshold.
* **Stabilization Window**: the look-back period (in seconds) used to smooth out scaling decisions. Default: `60` s. Range: 0–3600 s.
* **Select Policy**: when multiple policies are configured, determines which one wins:
* **Max** (default): picks the policy that allows the most pods to be added.
* **Min**: picks the policy that allows the fewest pods to be added.
* **Disabled**: disables scale-up entirely.
* **Policies**: one or more rate-limiting rules. Click **Add Policy** to configure:
* **Type**: `Pods` (fixed number per period) or `Percent` (percentage of current count, max 100).
* **Value**: the number of pods or percentage to add per period.
* **Period Seconds**: the duration of each evaluation window (1–1800 s).
When multiple policies are active, **Select Policy = Max** picks the policy that allows the largest increase.
**Scale Down**
Controls how gradually pods are removed when demand drops below the threshold.
* **Stabilization Window**: the look-back period (in seconds) before pods are removed. Default: `180` s. Range: 0–3600 s.
* **Select Policy**: when multiple policies are configured, determines which one wins:
* **Min** (default): picks the policy that removes the fewest pods.
* **Max**: picks the policy that removes the most pods.
* **Disabled**: disables scale-down entirely.
* **Policies**: same fields as Scale Up.
When multiple policies are active, **Select Policy = Min** picks the policy that removes the fewest pods. This ensures scale-down is gradual even if metrics drop sharply.
Autoscaling Policy is an advanced configuration. If left unconfigured, standard min/max replica scaling based on the configured scaling metrics applies without rate limiting.
Add key-value tags to organize and filter your deployments. Tags are useful for tracking environment, team, or cost-center metadata.
* Click **+ Add Tag** to add a new key-value pair.
* Tags can be used to filter deployments on the Deployments page.
Click **Deploy Model** to initiate the deployment process.
* Check the right side of the screen to see the creation status of your deployment.
* Monitor the deployment status to know when the model is ready for use.
* The status will show `deployed` once done. Your model is now ready for use.
**For BYOC deployments** it is mandatory to have a linked cloud account and an active cluster with the required resources.
Select the cluster and the required node group based on the model.
* **Cluster**: Select the target [cluster](/model-suite/clusters).
* **Node Group**: Select the node group based on the GPU type and compute specs required by your model (e.g., A100, H100, T4).
This ensures compatibility and optimal resource allocation during deployment.
**Resource Details**
Choose the appropriate CPU and memory resources based on the selected node group.
* **CPU Request**: Minimum guaranteed CPU for the container.
* **CPU Limit**: Maximum CPU the container can use. Throttled if exceeded.
* **Memory Request**: Minimum guaranteed memory.
* **Memory Limit**: Maximum memory allowed. Exceeding it results in termination (OOM error).
Define how your deployment scales based on demand:
* **Range**: Minimum and maximum number of instances. The limits are governed by your account quota.
* **Scaling Metric**: The metric used to trigger scaling. Choose from:
* **Memory Usage**: Average memory usage across all pods.
* **Latency**: Response time per request.
* **Throughput**: Number of requests processed per second.
* **Concurrency**: Number of concurrent requests being processed.
Available scaling metrics may vary depending on the model type.
* **Threshold**: The metric value that triggers a scaling event for both scale-out and scale-in (e.g. scale out at 80% memory, scale in when it drops back below the threshold).
**Advanced Options**
* **Enable Scale to Zero**: Scales the deployment down to zero instances when there is no incoming traffic, reducing idle costs. When traffic resumes, the deployment scales back up automatically.
* **Cooldown Period**: The amount of time (in seconds) to wait after traffic stops before scaling down to zero. A longer cooldown avoids premature scale-downs during brief traffic lulls.
**Enable Rapid Autoscaling**
Rapid Autoscaling allows your deployment to scale out significantly faster during sudden traffic bursts.
Rapid Autoscaling is available on Simplismart Cloud (Dedicated) deployments only. To enable it, contact [support@simplismart.tech](mailto:support@simplismart.tech).
Enable **Schedule Based Scaling** when you know your traffic pattern in advance. For example, if most of your load arrives on weekdays during office hours, you can define time windows for those periods and let the deployment scale to zero, or fall back to a lower replica count, outside them.
**Schedule Based Scaling** and **Enable Scale to Zero** (in the Advanced Options of Scaling Parameters) are mutually exclusive. Use the **Scale to 0 outside windows** option below if you want pods to scale to zero on a schedule.
**Scale to 0 outside windows**
Choose what happens outside your configured windows:
| Setting | Outside windows | Endpoint behaviour |
| ------------ | ------------------------------------------------------------------------ | ----------------------------------------------------------------- |
| **Enabled** | Deployment runs **0 pods**. It wakes up at the start of the next window. | Returns **503 Service Unavailable** until the next window starts. |
| **Disabled** | Deployment falls back to your standard min/max replicas. | Continues to serve traffic. |
Pick **Disabled** if the endpoint must accept requests outside windows.
**Configuring windows**
Each window defines a time range during which a guaranteed minimum number of pods is maintained. Click **+ Add Window** to add more windows. When multiple rules are active (schedule windows, overlapping windows, standard scaling), whichever produces the **higher pod count** wins at any given time. The cool-down period is fixed at **5 minutes** and cannot be modified.
Each window can be configured using either the **Guided** visual picker or **Custom** cron expressions:
Use the visual picker to configure your schedule:
* **Timezone**: the timezone for interpreting wake-up and cool-down times.
* **Days**: select one or more days of the week (Mon–Sun).
* **Wake up at**: the time at which pods scale up to the configured minimum.
* **Cool down at**: the time at which pods begin scaling down.
* **Minimum Pods during window**: number of pods guaranteed during the window (1–8).
Enter cron expressions directly for more flexibility:
* **Timezone**: the timezone for interpreting the cron schedule.
* **Start**: cron expression for when pods scale up (e.g. `0 9 * * 1,2,3,4,5` for 09:00 AM on weekdays).
* **End**: cron expression for when pods scale down (e.g. `0 18 * * 1,2,3,4,5` for 06:00 PM on weekdays).
* **Minimum Pods during window**: number of pods guaranteed during the window (1–8).
A human-readable summary of each cron expression is shown below the input field.
Fine-tune how aggressively your deployment scales up and down by configuring policies and stabilization windows for each direction. This controls the *rate* of pod changes once the scaling metrics cross their configured thresholds.
**Scale Up**
Controls how quickly new pods are added when demand rises above the scaling threshold.
* **Stabilization Window**: the look-back period (in seconds) used to smooth out scaling decisions. Default: `60` s. Range: 0–3600 s.
* **Select Policy**: when multiple policies are configured, determines which one wins:
* **Max** (default): picks the policy that allows the most pods to be added.
* **Min**: picks the policy that allows the fewest pods to be added.
* **Disabled**: disables scale-up entirely.
* **Policies**: one or more rate-limiting rules. Click **Add Policy** to configure:
* **Type**: `Pods` (fixed number per period) or `Percent` (percentage of current count, max 100).
* **Value**: the number of pods or percentage to add per period.
* **Period Seconds**: the duration of each evaluation window (1–1800 s).
When multiple policies are active, **Select Policy = Max** picks the policy that allows the largest increase.
**Scale Down**
Controls how gradually pods are removed when demand drops below the threshold.
* **Stabilization Window**: the look-back period (in seconds) before pods are removed. Default: `180` s. Range: 0–3600 s.
* **Select Policy**: when multiple policies are configured, determines which one wins:
* **Min** (default): picks the policy that removes the fewest pods.
* **Max**: picks the policy that removes the most pods.
* **Disabled**: disables scale-down entirely.
* **Policies**: same fields as Scale Up.
When multiple policies are active, **Select Policy = Min** picks the policy that removes the fewest pods. This ensures scale-down is gradual even if metrics drop sharply.
Autoscaling Policy is an advanced configuration. If left unconfigured, standard min/max replica scaling based on the configured scaling metrics applies without rate limiting.
Add key-value tags to organize and filter your deployments. Tags are useful for tracking environment, team, or cost-center metadata.
* Click **+ Add Tag** to add a new key-value pair.
* Tags can be used to filter deployments on the Deployments page.
Click **Deploy Model** to initiate the deployment process.
* Check the right side of the screen to see the creation status of your deployment.
* Monitor the deployment status to know when the model is ready for use.
* The status will show `deployed` once done. Your model is now ready for use.
## Monitoring and Access
After the deployment is created, Simplismart continuously monitors the model server, waiting for the model weights to load and the server to begin responding. The deployment is marked **Healthy** once the model is fully loaded and ready to serve requests. Until then, the endpoint does not accept traffic.
Health monitoring keeps running for the lifetime of the deployment. If a pod stops responding, Simplismart stops routing traffic to it and may replace it.
### Health states
The status shown on the deployment page reflects the current health of your deployment:
| State | What it means |
| ---------------------------- | -------------------------------------------------------------------------------------------------------- |
| **Progressing** | Pods are coming up. The deployment is not yet ready to serve traffic. |
| **Healthy** | The deployment is live and accepting inference requests. |
| **Progressing with timeout** | The deployment has not become ready within the expected window. Check the **Events** tab to investigate. |
| **Not present** | The deployment has been stopped or deleted. |
| **Unknown** | Status could not be determined. Usually transient; if it persists, contact support. |
When the deployment is **Healthy**, it is ready to accept inference requests:
* **Health Status**: Shows **Healthy** on the deployment page.
* **Deployment URL**: Direct link to your running deployment. Use the **API** tab to find the endpoint URL and a pre-generated inference script. See [Inference & Monitoring](/model-suite/deployments/inference-and-monitoring) for a full walkthrough.
* **Events Tab**: Tracks lifecycle events such as health transitions, scale-out, scale-in, and instance restarts. Start here when debugging unexpected behaviour.
### Managing Your Deployment
Once your deployment is live, you can manage it from the **Deployments** page:
1. Open the **Deployments** tab from the main menu.
2. Select the deployment you want to modify.
3. Click the kebab menu (`⋮`) in the top-right of the deployment card and choose **Pause**, **Edit**, **Clone**, or **Delete**.
Adjust scaling, model, or tags without redeploying. Changes are applied as rolling updates.
Halts all running instances. The deployment configuration is preserved and can be resumed at any time.
Duplicates the current deployment's configuration as a starting point for a new deployment.
Permanently removes the deployment and all its instances. This action cannot be undone.
# Deploying a Custom Model
Source: https://docs.simplismart.ai/model-suite/deployments/deploy-a-custom-model
Steps to guide you through the process of creating a custom model deployment
Deployments are scoped to the active workspace. If your organisation has more than one workspace, use the workspace toggle in the breadcrumb navigation to switch to the target workspace before continuing. If you only have the **Default** workspace, you can skip this step. New deployments will be created under the `Default` workspace only. See [Workspaces](/model-suite/settings/workspaces) for details.
From the main menu, select the [**Deployments**](https://app.simplismart.ai/deployments) tab and click **Create** to start a new deployment.
Fill in the following fields:
* **Deployment Name**: Provide a unique name for your deployment.
* **Model**: Choose the model you want to deploy from the dropdown.
* **Cloud**: Select **Simplismart Cloud** to deploy as a [Dedicated Endpoint](/inference/dedicated-endpoint), or **BYOC** to deploy on your own [cluster](/model-suite/integrations/cloud-account).
If you haven't added your custom model yet, go to [Models](/model-suite/adding-a-custom-model) to add one before proceeding.
**Processing Type**: Choose how you want requests to be handled:
* `Sync`: instantly processes requests with results in the same call, suitable for realtime workloads.
* `Async`: queues requests and delivers results later via polling or webhook.
For `Async` modes, an additional scaling parameter becomes available:
* **Parallel Requests Per Pod**: Set the number of messages (requests) per pod. This scales based on the request queue per pod, depending on how many concurrent requests your model can handle.
**For dedicated deployments** please ensure you have enough [quota](/model-suite/settings/quotas) of the desired resources.
Choose the desired accelerator type based on your model size and SLA requirements.
To deploy on a GPU type not listed or for CPU-only deployments, email [support@simplismart.tech](mailto:support@simplismart.tech).
SSH access lets you connect directly to a running container in your deployment, which is useful for debugging, inspecting logs, or running ad-hoc commands without rebuilding and redeploying.
Toggle **SSH Access** on during deployment creation to configure it. You can add up to 5 users per deployment, choose the SSH runtime (sidecar or main container), and assign an SSH key secret to each user.
For runtime options, bringing your own image, generating a key pair, and connecting to a running deployment, see the [SSH Access guide](/model-suite/deployments/ssh-access).
Define how your deployment scales based on demand:
* **Range**: Minimum and maximum number of instances. The limits are governed by your account quota.
* **Scaling Metric**: The metric used to trigger scaling. Choose from:
* **Memory Usage**: Average memory usage across all pods.
* **Latency**: Response time per request.
* **Throughput**: Number of requests processed per second.
* **Concurrency**: Number of concurrent requests being processed.
Available scaling metrics may vary depending on the model type.
* **Threshold**: The metric value that triggers a scaling event for both scale-out and scale-in (e.g. scale out at 80% memory, scale in when it drops back below the threshold).
**Advanced Options**
* **Enable Scale to Zero**: Scales the deployment down to zero instances when there is no incoming traffic, reducing idle costs. When traffic resumes, the deployment scales back up automatically.
* **Cooldown Period**: The amount of time (in seconds) to wait after traffic stops before scaling down to zero. A longer cooldown avoids premature scale-downs during brief traffic lulls.
**Enable Rapid Autoscaling**
Rapid Autoscaling allows your deployment to scale out significantly faster during sudden traffic bursts.
Rapid Autoscaling is available on Simplismart Cloud (Dedicated) deployments only. To enable it, contact [support@simplismart.tech](mailto:support@simplismart.tech).
Enable **Schedule Based Scaling** when you know your traffic pattern in advance. For example, if most of your load arrives on weekdays during office hours, you can define time windows for those periods and let the deployment scale to zero, or fall back to a lower replica count, outside them.
**Schedule Based Scaling** and **Enable Scale to Zero** (in the Advanced Options of Scaling Parameters) are mutually exclusive. Use the **Scale to 0 outside windows** option below if you want pods to scale to zero on a schedule.
**Scale to 0 outside windows**
Choose what happens outside your configured windows:
| Setting | Outside windows | Endpoint behaviour |
| ------------ | ------------------------------------------------------------------------ | ----------------------------------------------------------------- |
| **Enabled** | Deployment runs **0 pods**. It wakes up at the start of the next window. | Returns **503 Service Unavailable** until the next window starts. |
| **Disabled** | Deployment falls back to your standard min/max replicas. | Continues to serve traffic. |
Pick **Disabled** if the endpoint must accept requests outside windows.
**Configuring windows**
Each window defines a time range during which a guaranteed minimum number of pods is maintained. Click **+ Add Window** to add more windows. When multiple rules are active (schedule windows, overlapping windows, standard scaling), whichever produces the **higher pod count** wins at any given time. The cool-down period is fixed at **5 minutes** and cannot be modified.
Each window can be configured using either the **Guided** visual picker or **Custom** cron expressions:
Use the visual picker to configure your schedule:
* **Timezone**: the timezone for interpreting wake-up and cool-down times.
* **Days**: select one or more days of the week (Mon–Sun).
* **Wake up at**: the time at which pods scale up to the configured minimum.
* **Cool down at**: the time at which pods begin scaling down.
* **Minimum Pods during window**: number of pods guaranteed during the window (1–8).
Enter cron expressions directly for more flexibility:
* **Timezone**: the timezone for interpreting the cron schedule.
* **Start**: cron expression for when pods scale up (e.g. `0 9 * * 1,2,3,4,5` for 09:00 AM on weekdays).
* **End**: cron expression for when pods scale down (e.g. `0 18 * * 1,2,3,4,5` for 06:00 PM on weekdays).
* **Minimum Pods during window**: number of pods guaranteed during the window (1–8).
A human-readable summary of each cron expression is shown below the input field.
Fine-tune how aggressively your deployment scales up and down by configuring policies and stabilization windows for each direction. This controls the *rate* of pod changes once the scaling metrics cross their configured thresholds.
**Scale Up**
Controls how quickly new pods are added when demand rises above the scaling threshold.
* **Stabilization Window**: the look-back period (in seconds) used to smooth out scaling decisions. Default: `60` s. Range: 0–3600 s.
* **Select Policy**: when multiple policies are configured, determines which one wins:
* **Max** (default): picks the policy that allows the most pods to be added.
* **Min**: picks the policy that allows the fewest pods to be added.
* **Disabled**: disables scale-up entirely.
* **Policies**: one or more rate-limiting rules. Click **Add Policy** to configure:
* **Type**: `Pods` (fixed number per period) or `Percent` (percentage of current count, max 100).
* **Value**: the number of pods or percentage to add per period.
* **Period Seconds**: the duration of each evaluation window (1–1800 s).
When multiple policies are active, **Select Policy = Max** picks the policy that allows the largest increase.
**Scale Down**
Controls how gradually pods are removed when demand drops below the threshold.
* **Stabilization Window**: the look-back period (in seconds) before pods are removed. Default: `180` s. Range: 0–3600 s.
* **Select Policy**: when multiple policies are configured, determines which one wins:
* **Min** (default): picks the policy that removes the fewest pods.
* **Max**: picks the policy that removes the most pods.
* **Disabled**: disables scale-down entirely.
* **Policies**: same fields as Scale Up.
When multiple policies are active, **Select Policy = Min** picks the policy that removes the fewest pods. This ensures scale-down is gradual even if metrics drop sharply.
Autoscaling Policy is an advanced configuration. If left unconfigured, standard min/max replica scaling based on the configured scaling metrics applies without rate limiting.
Mount a persistent volume into your deployment to provide model weights or data files that the container reads at runtime.
* **Mount Path**: The path inside the container where the volume is mounted (e.g. `/mnt/models`).
* **Size (Gi)**: The size of the volume in gibibytes.
Storage volumes are provisioned at deployment creation time. Changing the mount path or size requires redeploying.
Add key-value tags to organize and filter your deployments. Tags are useful for tracking environment, team, or cost-center metadata.
* Click **+ Add Tag** to add a new key-value pair.
* Tags can be used to filter deployments on the Deployments page.
Click **Deploy Model** to initiate the deployment process.
* Check the right side of the screen to see the creation status of your deployment.
* Monitor the deployment status to know when the model is ready for use.
* The status will show `deployed` once done. Your model is now ready for use.
**For BYOC deployments** it is mandatory to have a linked cloud account and an active cluster with the required resources.
Select the cluster and the required node group based on the model.
* **Cluster**: Select the target [cluster](/model-suite/clusters).
* **Node Group**: Select the node group based on the GPU type and compute specs required by your model (e.g., A100, H100, T4).
This ensures compatibility and optimal resource allocation during deployment.
**Resource Details**
Choose the appropriate CPU and memory resources based on the selected node group.
* **CPU Request**: Minimum guaranteed CPU for the container.
* **CPU Limit**: Maximum CPU the container can use. Throttled if exceeded.
* **Memory Request**: Minimum guaranteed memory.
* **Memory Limit**: Maximum memory allowed. Exceeding it results in termination (OOM error).
Define how your deployment scales based on demand:
* **Range**: Minimum and maximum number of instances. The limits are governed by your account quota.
* **Scaling Metric**: The metric used to trigger scaling. Choose from:
* **Memory Usage**: Average memory usage across all pods.
* **Latency**: Response time per request.
* **Throughput**: Number of requests processed per second.
* **Concurrency**: Number of concurrent requests being processed.
Available scaling metrics may vary depending on the model type.
* **Threshold**: The metric value that triggers a scaling event for both scale-out and scale-in (e.g. scale out at 80% memory, scale in when it drops back below the threshold).
**Advanced Options**
* **Enable Scale to Zero**: Scales the deployment down to zero instances when there is no incoming traffic, reducing idle costs. When traffic resumes, the deployment scales back up automatically.
* **Cooldown Period**: The amount of time (in seconds) to wait after traffic stops before scaling down to zero. A longer cooldown avoids premature scale-downs during brief traffic lulls.
**Enable Rapid Autoscaling**
Rapid Autoscaling allows your deployment to scale out significantly faster during sudden traffic bursts.
Rapid Autoscaling is available on Simplismart Cloud (Dedicated) deployments only. To enable it, contact [support@simplismart.tech](mailto:support@simplismart.tech).
Enable **Schedule Based Scaling** when you know your traffic pattern in advance. For example, if most of your load arrives on weekdays during office hours, you can define time windows for those periods and let the deployment scale to zero, or fall back to a lower replica count, outside them.
**Schedule Based Scaling** and **Enable Scale to Zero** (in the Advanced Options of Scaling Parameters) are mutually exclusive. Use the **Scale to 0 outside windows** option below if you want pods to scale to zero on a schedule.
**Scale to 0 outside windows**
Choose what happens outside your configured windows:
| Setting | Outside windows | Endpoint behaviour |
| ------------ | ------------------------------------------------------------------------ | ----------------------------------------------------------------- |
| **Enabled** | Deployment runs **0 pods**. It wakes up at the start of the next window. | Returns **503 Service Unavailable** until the next window starts. |
| **Disabled** | Deployment falls back to your standard min/max replicas. | Continues to serve traffic. |
Pick **Disabled** if the endpoint must accept requests outside windows.
**Configuring windows**
Each window defines a time range during which a guaranteed minimum number of pods is maintained. Click **+ Add Window** to add more windows. When multiple rules are active (schedule windows, overlapping windows, standard scaling), whichever produces the **higher pod count** wins at any given time. The cool-down period is fixed at **5 minutes** and cannot be modified.
Each window can be configured using either the **Guided** visual picker or **Custom** cron expressions:
Use the visual picker to configure your schedule:
* **Timezone**: the timezone for interpreting wake-up and cool-down times.
* **Days**: select one or more days of the week (Mon–Sun).
* **Wake up at**: the time at which pods scale up to the configured minimum.
* **Cool down at**: the time at which pods begin scaling down.
* **Minimum Pods during window**: number of pods guaranteed during the window (1–8).
Enter cron expressions directly for more flexibility:
* **Timezone**: the timezone for interpreting the cron schedule.
* **Start**: cron expression for when pods scale up (e.g. `0 9 * * 1,2,3,4,5` for 09:00 AM on weekdays).
* **End**: cron expression for when pods scale down (e.g. `0 18 * * 1,2,3,4,5` for 06:00 PM on weekdays).
* **Minimum Pods during window**: number of pods guaranteed during the window (1–8).
A human-readable summary of each cron expression is shown below the input field.
Fine-tune how aggressively your deployment scales up and down by configuring policies and stabilization windows for each direction. This controls the *rate* of pod changes once the scaling metrics cross their configured thresholds.
**Scale Up**
Controls how quickly new pods are added when demand rises above the scaling threshold.
* **Stabilization Window**: the look-back period (in seconds) used to smooth out scaling decisions. Default: `60` s. Range: 0–3600 s.
* **Select Policy**: when multiple policies are configured, determines which one wins:
* **Max** (default): picks the policy that allows the most pods to be added.
* **Min**: picks the policy that allows the fewest pods to be added.
* **Disabled**: disables scale-up entirely.
* **Policies**: one or more rate-limiting rules. Click **Add Policy** to configure:
* **Type**: `Pods` (fixed number per period) or `Percent` (percentage of current count, max 100).
* **Value**: the number of pods or percentage to add per period.
* **Period Seconds**: the duration of each evaluation window (1–1800 s).
When multiple policies are active, **Select Policy = Max** picks the policy that allows the largest increase.
**Scale Down**
Controls how gradually pods are removed when demand drops below the threshold.
* **Stabilization Window**: the look-back period (in seconds) before pods are removed. Default: `180` s. Range: 0–3600 s.
* **Select Policy**: when multiple policies are configured, determines which one wins:
* **Min** (default): picks the policy that removes the fewest pods.
* **Max**: picks the policy that removes the most pods.
* **Disabled**: disables scale-down entirely.
* **Policies**: same fields as Scale Up.
When multiple policies are active, **Select Policy = Min** picks the policy that removes the fewest pods. This ensures scale-down is gradual even if metrics drop sharply.
Autoscaling Policy is an advanced configuration. If left unconfigured, standard min/max replica scaling based on the configured scaling metrics applies without rate limiting.
Add key-value tags to organize and filter your deployments. Tags are useful for tracking environment, team, or cost-center metadata.
* Click **+ Add Tag** to add a new key-value pair.
* Tags can be used to filter deployments on the Deployments page.
Click **Deploy Model** to initiate the deployment process.
* Check the right side of the screen to see the creation status of your deployment.
* Monitor the deployment status to know when the model is ready for use.
* The status will show `deployed` once done. Your model is now ready for use.
## Monitoring and Access
After the deployment is created, Simplismart continuously monitors the model server, waiting for the model weights to load and the server to begin responding. The deployment is marked **Healthy** once the model is fully loaded and ready to serve requests. Until then, the endpoint does not accept traffic.
Health monitoring keeps running for the lifetime of the deployment. If a pod stops responding, Simplismart stops routing traffic to it and may replace it.
### Health states
The status shown on the deployment page reflects the current health of your deployment:
| State | What it means |
| ---------------------------- | -------------------------------------------------------------------------------------------------------- |
| **Progressing** | Pods are coming up. The deployment is not yet ready to serve traffic. |
| **Healthy** | The deployment is live and accepting inference requests. |
| **Progressing with timeout** | The deployment has not become ready within the expected window. Check the **Events** tab to investigate. |
| **Not present** | The deployment has been stopped or deleted. |
| **Unknown** | Status could not be determined. Usually transient; if it persists, contact support. |
When the deployment is **Healthy**, it is ready to accept inference requests:
* **Health Status**: Shows **Healthy** on the deployment page.
* **Deployment URL**: Direct link to your running deployment. Use the **API** tab to find the endpoint URL and a pre-generated inference script. See [Inference & Monitoring](/model-suite/deployments/inference-and-monitoring) for a full walkthrough.
* **Events Tab**: Tracks lifecycle events such as health transitions, scale-out, scale-in, and instance restarts. Start here when debugging unexpected behaviour.
### Managing Your Deployment
Once your deployment is live, you can manage it from the **Deployments** page:
1. Open the **Deployments** tab from the main menu.
2. Select the deployment you want to modify.
3. Click the kebab menu (`⋮`) in the top-right of the deployment card and choose **Pause**, **Edit**, **Clone**, or **Delete**.
Adjust scaling, model, or tags without redeploying. Changes are applied as rolling updates.
Halts all running instances. The deployment configuration is preserved and can be resumed at any time.
Duplicates the current deployment's configuration as a starting point for a new deployment.
Permanently removes the deployment and all its instances. This action cannot be undone.
# Deploy Container
Source: https://docs.simplismart.ai/model-suite/deployments/deploy-container
Configure and launch a container deployment on Simplismart
Deployments are scoped to the active workspace. If your organisation has more than one workspace, use the workspace toggle in the breadcrumb navigation to switch to the target workspace before continuing. If you only have the **Default** workspace, you can skip this step. New deployments will be created under the `Default` workspace only. See [Workspaces](/model-suite/settings/workspaces) for details.
From the main menu, select the [**Deployments**](https://app.simplismart.ai/deployments) tab and click **Create** to start a new deployment.
Fill in the following fields:
* **Deployment Name**: Provide a unique name for your deployment.
* **Model**: Choose the model you want to deploy from the dropdown.
* **Cloud**: Select **Simplismart Cloud** to deploy as a [Dedicated Endpoint](/inference/dedicated-endpoint), or **BYOC** to deploy on your own [cluster](/model-suite/integrations/cloud-account).
If you haven't added your container yet, start with [Add Your Container](/model-suite/add-container) before proceeding.
**For dedicated deployments** please ensure you have enough [quota](/model-suite/settings/quotas) of the desired resources.
Choose the desired accelerator type based on your model size and SLA requirements.
To deploy on a GPU type not listed or for CPU-only deployments, email [support@simplismart.tech](mailto:support@simplismart.tech).
If you already configured ports, health checks, environment variables, or a command override in the **[Add Model](/model-suite/add-container)** step, those values are pre-filled here and can be overridden. The fields exclusive to this step are **Enable Auth** and **File Mount**.
**Service Configuration**
Configure service types and ports for your container. You can add multiple service types, but only one of each type. HTTP service is added by default. At least one of **HTTP**, **gRPC**, or **WebSocket** is required.
Each service has a **Public Access** toggle. When enabled, the service is exposed externally and accessible via public endpoints. When disabled, it is accessible only within the cluster.
* **HTTP Service**: Exposes your application over HTTP. Set the port your server listens on (e.g. `8000`). Added by default; can be removed if you use gRPC or WebSocket instead.
* **gRPC Service** (Optional): Enable for high-performance RPC workloads. It requires a port distinct from the HTTP service port (e.g. `9000`) and can be combined with HTTP and Monitoring services.
* **Monitoring Service** (Optional): Exposes a metrics endpoint for monitoring tools such as Prometheus. Requires a **Port** (e.g. `9090`) and a **Path** (e.g. `/metrics`). Can be combined with HTTP or gRPC services.
* **WebSocket Service** (Optional): Enable for WebSocket-based model serving (e.g. real-time streaming). Set the port (e.g. `8001`).
WebSocket is exclusive and no other service types can be configured when WebSocket is selected.
**Health Check Configuration**
Configure health check settings for your container deployment.
* **Health Check Path**: Endpoint your app exposes for health probes (e.g. `/health`).
* **Port**: Must match your HTTP/gRPC service port (e.g. `8000`).
* **Initial Delay**: Wait time before the first health check (e.g. `30s`).
* **Period**: How frequently health checks run (e.g. `10s`).
* **Timeout**: Maximum time to wait for a health check response (e.g. `5s`).
**Environment Variables (Optional)**
Set runtime environment variables. Add key-value pairs using the `+` button.
**Command Override (Optional)**
Override the container's default startup command. Type or paste the full command and press **Enter** or click outside the field to parse it automatically (e.g. `python -m uvicorn main:app`).
**Model Endpoint**
Set the path your model server exposes for inference requests (e.g. `/v1/completions`). This field is **required** when using a WebSocket service (e.g. `/v1/audio/speech`).
**Enable Auth**
Toggle **Enable Auth** to require a [Simplismart API token](/model-suite/settings/api-keys) on every request to this deployment's endpoint. Unauthenticated requests will be rejected.
**File Mount**
Mount configuration files or secrets inside your container at runtime. Click **+ Add File**, specify the **Mount Path**, then upload your file.
* **Supported formats**: `.toml`, `.yaml`, `.yml`, `.json`, `.conf`, `.ini`, `.properties`, `.env`, `.cfg`, `.jsonl`, `.sh`, `.txt`
* **Total size limit**: 500 KB across all mounted files
* Each mounted file can be **edited inline** or **re-uploaded** using the Actions column.
The following system directories cannot be used as mount paths: `/sys`, `/proc`, `/dev`, `/root`, `/boot`, `/bin`, `/sbin`, `/lib`, `/lib64`.
Use a path under `/home`, `/tmp`, `/var/tmp`, `/opt`, `/srv`, or a subdirectory of `/etc` (e.g. `/etc/myapp/config.txt`).
SSH access lets you connect directly to a running container in your deployment, which is useful for debugging, inspecting logs, or running ad-hoc commands without rebuilding and redeploying.
Toggle **SSH Access** on during deployment creation to configure it. You can add up to 5 users per deployment, choose the SSH runtime (sidecar or main container), and assign an SSH key secret to each user.
For runtime options, bringing your own image, generating a key pair, and connecting to a running deployment, see the [SSH Access guide](/model-suite/deployments/ssh-access).
Define how your deployment scales based on demand:
* **Range**: Minimum and maximum number of instances. The limits are governed by your account quota.
* **Scaling Metric**: The metric used to trigger scaling. Choose from:
* **Memory Usage**: Average memory usage across all pods.
* **Latency**: Response time per request.
* **Throughput**: Number of requests processed per second.
* **Concurrency**: Number of concurrent requests being processed.
Available scaling metrics may vary depending on the model type.
* **Threshold**: The metric value that triggers a scaling event for both scale-out and scale-in (e.g. scale out at 80% memory, scale in when it drops back below the threshold).
**Advanced Options**
* **Enable Scale to Zero**: Scales the deployment down to zero instances when there is no incoming traffic, reducing idle costs. When traffic resumes, the deployment scales back up automatically.
* **Cooldown Period**: The amount of time (in seconds) to wait after traffic stops before scaling down to zero. A longer cooldown avoids premature scale-downs during brief traffic lulls.
**Enable Rapid Autoscaling**
Rapid Autoscaling allows your deployment to scale out significantly faster during sudden traffic bursts.
Rapid Autoscaling is available on Simplismart Cloud (Dedicated) deployments only. To enable it, contact [support@simplismart.tech](mailto:support@simplismart.tech).
Enable **Schedule Based Scaling** when you know your traffic pattern in advance. For example, if most of your load arrives on weekdays during office hours, you can define time windows for those periods and let the deployment scale to zero, or fall back to a lower replica count, outside them.
**Schedule Based Scaling** and **Enable Scale to Zero** (in the Advanced Options of Scaling Parameters) are mutually exclusive. Use the **Scale to 0 outside windows** option below if you want pods to scale to zero on a schedule.
**Scale to 0 outside windows**
Choose what happens outside your configured windows:
| Setting | Outside windows | Endpoint behaviour |
| ------------ | ------------------------------------------------------------------------ | ----------------------------------------------------------------- |
| **Enabled** | Deployment runs **0 pods**. It wakes up at the start of the next window. | Returns **503 Service Unavailable** until the next window starts. |
| **Disabled** | Deployment falls back to your standard min/max replicas. | Continues to serve traffic. |
Pick **Disabled** if the endpoint must accept requests outside windows.
**Configuring windows**
Each window defines a time range during which a guaranteed minimum number of pods is maintained. Click **+ Add Window** to add more windows. When multiple rules are active (schedule windows, overlapping windows, standard scaling), whichever produces the **higher pod count** wins at any given time. The cool-down period is fixed at **5 minutes** and cannot be modified.
Each window can be configured using either the **Guided** visual picker or **Custom** cron expressions:
Use the visual picker to configure your schedule:
* **Timezone**: the timezone for interpreting wake-up and cool-down times.
* **Days**: select one or more days of the week (Mon–Sun).
* **Wake up at**: the time at which pods scale up to the configured minimum.
* **Cool down at**: the time at which pods begin scaling down.
* **Minimum Pods during window**: number of pods guaranteed during the window (1–8).
Enter cron expressions directly for more flexibility:
* **Timezone**: the timezone for interpreting the cron schedule.
* **Start**: cron expression for when pods scale up (e.g. `0 9 * * 1,2,3,4,5` for 09:00 AM on weekdays).
* **End**: cron expression for when pods scale down (e.g. `0 18 * * 1,2,3,4,5` for 06:00 PM on weekdays).
* **Minimum Pods during window**: number of pods guaranteed during the window (1–8).
A human-readable summary of each cron expression is shown below the input field.
Fine-tune how aggressively your deployment scales up and down by configuring policies and stabilization windows for each direction. This controls the *rate* of pod changes once the scaling metrics cross their configured thresholds.
**Scale Up**
Controls how quickly new pods are added when demand rises above the scaling threshold.
* **Stabilization Window**: the look-back period (in seconds) used to smooth out scaling decisions. Default: `60` s. Range: 0–3600 s.
* **Select Policy**: when multiple policies are configured, determines which one wins:
* **Max** (default): picks the policy that allows the most pods to be added.
* **Min**: picks the policy that allows the fewest pods to be added.
* **Disabled**: disables scale-up entirely.
* **Policies**: one or more rate-limiting rules. Click **Add Policy** to configure:
* **Type**: `Pods` (fixed number per period) or `Percent` (percentage of current count, max 100).
* **Value**: the number of pods or percentage to add per period.
* **Period Seconds**: the duration of each evaluation window (1–1800 s).
When multiple policies are active, **Select Policy = Max** picks the policy that allows the largest increase.
**Scale Down**
Controls how gradually pods are removed when demand drops below the threshold.
* **Stabilization Window**: the look-back period (in seconds) before pods are removed. Default: `180` s. Range: 0–3600 s.
* **Select Policy**: when multiple policies are configured, determines which one wins:
* **Min** (default): picks the policy that removes the fewest pods.
* **Max**: picks the policy that removes the most pods.
* **Disabled**: disables scale-down entirely.
* **Policies**: same fields as Scale Up.
When multiple policies are active, **Select Policy = Min** picks the policy that removes the fewest pods. This ensures scale-down is gradual even if metrics drop sharply.
Autoscaling Policy is an advanced configuration. If left unconfigured, standard min/max replica scaling based on the configured scaling metrics applies without rate limiting.
Mount a persistent volume into your deployment to provide model weights or data files that the container reads at runtime.
* **Mount Path**: The path inside the container where the volume is mounted (e.g. `/mnt/models`).
* **Size (Gi)**: The size of the volume in gibibytes.
Storage volumes are provisioned at deployment creation time. Changing the mount path or size requires redeploying.
Add key-value tags to organize and filter your deployments. Tags are useful for tracking environment, team, or cost-center metadata.
* Click **+ Add Tag** to add a new key-value pair.
* Tags can be used to filter deployments on the Deployments page.
Click **Deploy Model** to initiate the deployment process.
* Check the right side of the screen to see the creation status of your deployment.
* Monitor the deployment status to know when the model is ready for use.
* The status will show `deployed` once done. Your model is now ready for use.
**For BYOC deployments** it is mandatory to have a linked cloud account and an active cluster with the required resources.
Select the cluster and the required node group based on the model.
* **Cluster**: Select the target [cluster](/model-suite/clusters).
* **Node Group**: Select the node group based on the GPU type and compute specs required by your model (e.g., A100, H100, T4).
This ensures compatibility and optimal resource allocation during deployment.
If you already configured ports, health checks, environment variables, or a command override in the **[Add Model](/model-suite/add-container)** step, those values are pre-filled here and can be overridden. The fields exclusive to this step are **Enable Auth** and **File Mount**.
**Service Configuration**
Configure service types and ports for your container. You can add multiple service types, but only one of each type. HTTP service is added by default. At least one of **HTTP**, **gRPC**, or **WebSocket** is required.
Each service has a **Public Access** toggle. When enabled, the service is exposed externally and accessible via public endpoints. When disabled, it is accessible only within the cluster.
* **HTTP Service**: Exposes your application over HTTP. Set the port your server listens on (e.g. `8000`). Added by default; can be removed if you use gRPC or WebSocket instead.
* **gRPC Service** (Optional): Enable for high-performance RPC workloads. It requires a port distinct from the HTTP service port (e.g. `9000`) and can be combined with HTTP and Monitoring services.
* **Monitoring Service** (Optional): Exposes a metrics endpoint for monitoring tools such as Prometheus. Requires a **Port** (e.g. `9090`) and a **Path** (e.g. `/metrics`). Can be combined with HTTP or gRPC services.
* **WebSocket Service** (Optional): Enable for WebSocket-based model serving (e.g. real-time streaming). Set the port (e.g. `8001`).
WebSocket is exclusive and no other service types can be configured when WebSocket is selected.
**Health Check Configuration**
Configure health check settings for your container deployment.
* **Health Check Path**: Endpoint your app exposes for health probes (e.g. `/health`).
* **Port**: Must match your HTTP/gRPC service port (e.g. `8000`).
* **Initial Delay**: Wait time before the first health check (e.g. `30s`).
* **Period**: How frequently health checks run (e.g. `10s`).
* **Timeout**: Maximum time to wait for a health check response (e.g. `5s`).
**Environment Variables (Optional)**
Set runtime environment variables. Add key-value pairs using the `+` button.
**Command Override (Optional)**
Override the container's default startup command. Type or paste the full command and press **Enter** or click outside the field to parse it automatically (e.g. `python -m uvicorn main:app`).
**Model Endpoint**
Set the path your model server exposes for inference requests (e.g. `/v1/completions`). This field is **required** when using a WebSocket service (e.g. `/v1/audio/speech`).
**Enable Auth**
Toggle **Enable Auth** to require a [Simplismart API token](/model-suite/settings/api-keys) on every request to this deployment's endpoint. Unauthenticated requests will be rejected.
**File Mount**
Mount configuration files or secrets inside your container at runtime. Click **+ Add File**, specify the **Mount Path**, then upload your file.
* **Supported formats**: `.toml`, `.yaml`, `.yml`, `.json`, `.conf`, `.ini`, `.properties`, `.env`, `.cfg`, `.jsonl`, `.sh`, `.txt`
* **Total size limit**: 500 KB across all mounted files
* Each mounted file can be **edited inline** or **re-uploaded** using the Actions column.
The following system directories cannot be used as mount paths: `/sys`, `/proc`, `/dev`, `/root`, `/boot`, `/bin`, `/sbin`, `/lib`, `/lib64`.
Use a path under `/home`, `/tmp`, `/var/tmp`, `/opt`, `/srv`, or a subdirectory of `/etc` (e.g. `/etc/myapp/config.txt`).
Choose the appropriate CPU and memory resources based on the selected node group.
* **CPU Request**: Minimum guaranteed CPU for the container.
* **CPU Limit**: Maximum CPU the container can use. Throttled if exceeded.
* **Memory Request**: Minimum guaranteed memory.
* **Memory Limit**: Maximum memory allowed. Exceeding it results in termination (OOM error).
Define how your deployment scales based on demand:
* **Range**: Minimum and maximum number of instances. The limits are governed by your account quota.
* **Scaling Metric**: The metric used to trigger scaling. Choose from:
* **Memory Usage**: Average memory usage across all pods.
* **Latency**: Response time per request.
* **Throughput**: Number of requests processed per second.
* **Concurrency**: Number of concurrent requests being processed.
Available scaling metrics may vary depending on the model type.
* **Threshold**: The metric value that triggers a scaling event for both scale-out and scale-in (e.g. scale out at 80% memory, scale in when it drops back below the threshold).
**Advanced Options**
* **Enable Scale to Zero**: Scales the deployment down to zero instances when there is no incoming traffic, reducing idle costs. When traffic resumes, the deployment scales back up automatically.
* **Cooldown Period**: The amount of time (in seconds) to wait after traffic stops before scaling down to zero. A longer cooldown avoids premature scale-downs during brief traffic lulls.
Enable **Schedule Based Scaling** when you know your traffic pattern in advance. For example, if most of your load arrives on weekdays during office hours, you can define time windows for those periods and let the deployment scale to zero, or fall back to a lower replica count, outside them.
**Schedule Based Scaling** and **Enable Scale to Zero** (in the Advanced Options of Scaling Parameters) are mutually exclusive. Use the **Scale to 0 outside windows** option below if you want pods to scale to zero on a schedule.
**Scale to 0 outside windows**
Choose what happens outside your configured windows:
| Setting | Outside windows | Endpoint behaviour |
| ------------ | ------------------------------------------------------------------------ | ----------------------------------------------------------------- |
| **Enabled** | Deployment runs **0 pods**. It wakes up at the start of the next window. | Returns **503 Service Unavailable** until the next window starts. |
| **Disabled** | Deployment falls back to your standard min/max replicas. | Continues to serve traffic. |
Pick **Disabled** if the endpoint must accept requests outside windows.
**Configuring windows**
Each window defines a time range during which a guaranteed minimum number of pods is maintained. Click **+ Add Window** to add more windows. When multiple rules are active (schedule windows, overlapping windows, standard scaling), whichever produces the **higher pod count** wins at any given time. The cool-down period is fixed at **5 minutes** and cannot be modified.
Each window can be configured using either the **Guided** visual picker or **Custom** cron expressions:
Use the visual picker to configure your schedule:
* **Timezone**: the timezone for interpreting wake-up and cool-down times.
* **Days**: select one or more days of the week (Mon–Sun).
* **Wake up at**: the time at which pods scale up to the configured minimum.
* **Cool down at**: the time at which pods begin scaling down.
* **Minimum Pods during window**: number of pods guaranteed during the window (1–8).
Enter cron expressions directly for more flexibility:
* **Timezone**: the timezone for interpreting the cron schedule.
* **Start**: cron expression for when pods scale up (e.g. `0 9 * * 1,2,3,4,5` for 09:00 AM on weekdays).
* **End**: cron expression for when pods scale down (e.g. `0 18 * * 1,2,3,4,5` for 06:00 PM on weekdays).
* **Minimum Pods during window**: number of pods guaranteed during the window (1–8).
A human-readable summary of each cron expression is shown below the input field.
Fine-tune how aggressively your deployment scales up and down by configuring policies and stabilization windows for each direction. This controls the *rate* of pod changes once the scaling metrics cross their configured thresholds.
**Scale Up**
Controls how quickly new pods are added when demand rises above the scaling threshold.
* **Stabilization Window**: the look-back period (in seconds) used to smooth out scaling decisions. Default: `60` s. Range: 0–3600 s.
* **Select Policy**: when multiple policies are configured, determines which one wins:
* **Max** (default): picks the policy that allows the most pods to be added.
* **Min**: picks the policy that allows the fewest pods to be added.
* **Disabled**: disables scale-up entirely.
* **Policies**: one or more rate-limiting rules. Click **Add Policy** to configure:
* **Type**: `Pods` (fixed number per period) or `Percent` (percentage of current count, max 100).
* **Value**: the number of pods or percentage to add per period.
* **Period Seconds**: the duration of each evaluation window (1–1800 s).
When multiple policies are active, **Select Policy = Max** picks the policy that allows the largest increase.
**Scale Down**
Controls how gradually pods are removed when demand drops below the threshold.
* **Stabilization Window**: the look-back period (in seconds) before pods are removed. Default: `180` s. Range: 0–3600 s.
* **Select Policy**: when multiple policies are configured, determines which one wins:
* **Min** (default): picks the policy that removes the fewest pods.
* **Max**: picks the policy that removes the most pods.
* **Disabled**: disables scale-down entirely.
* **Policies**: same fields as Scale Up.
When multiple policies are active, **Select Policy = Min** picks the policy that removes the fewest pods. This ensures scale-down is gradual even if metrics drop sharply.
Autoscaling Policy is an advanced configuration. If left unconfigured, standard min/max replica scaling based on the configured scaling metrics applies without rate limiting.
Add key-value tags to organize and filter your deployments. Tags are useful for tracking environment, team, or cost-center metadata.
* Click **+ Add Tag** to add a new key-value pair.
* Tags can be used to filter deployments on the Deployments page.
Click **Deploy Model** to initiate the deployment process.
* Check the right side of the screen to see the creation status of your deployment.
* Monitor the deployment status to know when the model is ready for use.
* The status will show `deployed` once done. Your model is now ready for use.
## Monitoring and Access
After the deployment is created, Simplismart continuously probes your container using the **Health Check Path**, **Port**, **Period**, and **Timeout** you configured in [Container Configuration](#container-configuration). The deployment is marked **Healthy** once those probes succeed consistently. Until then, the endpoint does not accept traffic.
Health checks keep running for the lifetime of the deployment. If a pod stops responding, Simplismart stops routing traffic to it and may replace it.
### Health states
The status shown on the deployment page reflects the current health of your deployment:
| State | What it means |
| ---------------------------- | -------------------------------------------------------------------------------------------------------- |
| **Progressing** | Pods are coming up. The deployment is not yet ready to serve traffic. |
| **Healthy** | The deployment is live and accepting inference requests. |
| **Progressing with timeout** | The deployment has not become ready within the expected window. Check the **Events** tab to investigate. |
| **Not present** | The deployment has been stopped or deleted. |
| **Unknown** | Status could not be determined. Usually transient; if it persists, contact support. |
When the deployment is **Healthy**, it is ready to accept inference requests:
* **Health Status**: Shows **Healthy** on the deployment page.
* **Deployment URL**: Direct link to your running deployment. Use the **API** tab to find the endpoint URL and a pre-generated inference script. See [Inference & Monitoring](/model-suite/deployments/inference-and-monitoring) for a full walkthrough.
* **Events Tab**: Tracks lifecycle events such as health transitions, scale-out, scale-in, and instance restarts. Start here when debugging unexpected behaviour.
### Managing Your Deployment
Once your deployment is live, you can manage it from the **Deployments** page:
1. Open the **Deployments** tab from the main menu.
2. Select the deployment you want to modify.
3. Click the kebab menu (`⋮`) in the top-right of the deployment card and choose **Pause**, **Edit**, **Clone**, or **Delete**.
Adjust scaling, model, or tags without redeploying. Changes are applied as rolling updates.
Halts all running instances. The deployment configuration is preserved and can be resumed at any time.
Duplicates the current deployment's configuration as a starting point for a new deployment.
Permanently removes the deployment and all its instances. This action cannot be undone.
### Troubleshooting
* Verify your application implements the health check endpoint and responds within the configured timeout.
* For private images, ensure the registry secret has read access to the repository.
* Confirm the HTTP service port matches the port your application listens on.
# Editing a Deployment
Source: https://docs.simplismart.ai/model-suite/deployments/edit-deployment
Guide to editing existing deployments on Simplismart
The Edit Deployment feature allows you to adjust parameters such as scaling, models, or tags without needing to redeploy from scratch.
Deployment edits are applied as **rolling updates** to minimize downtime while changes are being applied.
## Accessing the Edit Feature
Any successfully deployed model can be edited:
1. Go to **Deployments** from the left sidebar
2. Select the deployment you want to modify
3. You'll be taken to the deployment details view
Click the **Edit** button located in the top-right corner of the deployment details page.
Update the parameters and click on `Apply Changes` to implement the changes.\\
## What Can Be Edited
Understanding which parameters are editable helps you plan deployment updates effectively.
### Editable Parameters
The following parameters can be modified after deployment:
All scaling configurations can be updated:
* **Scaling Range**: Adjust minimum and maximum instance counts
* **Scaling Metrics**: Add, remove, or modify scaling triggers
* **Threshold Values**: Change the values that trigger auto-scaling
Update scaling parameters based on observed traffic patterns to optimize performance and costs.
You can swap the deployed model with important constraints:
* ✅ **Can change**: Different models of the **same type**
* ❌ **Cannot change**: Model type (e.g., LLM to STT)
**Example:**
* ✅ Swap Llama 3.1 8B with Llama 3.1 70B (both LLMs)
* ❌ Swap Llama 3.1 8B with Whisper V3 (different types)
Changing models may require adjustments to your application code if input/output formats differ.
Tags can be freely added, modified, or removed:
* Add new key-value pairs for organization
* Update existing tag values
* Remove obsolete tags
**Common tag use cases:**
* Environment identification (`env: production`)
* Version tracking (`version: v2.1`)
* Cost allocation (`team: ml-engineering`)
### Non-Editable Parameters
The following parameters are **locked** after deployment creation and cannot be changed:
* **Deployment Name**: The unique identifier for your deployment
* **Cloud / Cluster**: The infrastructure where the deployment runs
* **Processing Type**: Sync or Async processing mode
If you need to change non-editable parameters, you'll need to create a new deployment with the desired configuration.
**Warmpool Deployment Limitations:**
* Warmpool deployments cannot be edited at all
* Regular deployments cannot be converted into warmpool deployments
* To modify a warmpool deployment, create a new one with the desired configuration
## Update Process
Deployment edits are applied using a rolling update strategy to minimize downtime:
The system validates your changes before applying them
New configuration is deployed incrementally across instances
Each updated instance is health-checked before proceeding
Once all instances are updated, the deployment is complete
**Expected Behavior During Updates:**
* A small number of requests may be dropped during the rolling update
* Avoid making major updates (such as changing the model or GPU configuration) during high-traffic hours to prevent disruption.
### Automatic Rollback
The platform includes built-in safety mechanisms:
* ✅ **Automatic rollback**: If an edit fails, the system automatically reverts to the previous working version
* ❌ **Manual rollback**: Not currently supported after successful edits
* 🔍 **Health monitoring**: Continuous checks ensure deployment stability
Monitor your deployment's health metrics during and after edits to quickly identify any issues.
## Troubleshooting
Common issues and solutions when editing deployments:
| Issue | Cause | Solution |
| --------------------------------------------------- | ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **`Edit Failed due to Validation Error`** | Invalid configuration or incompatible parameters | • Review error message for specific issues
• Verify model compatibility
• Check scaling parameter ranges |
| **`Edit Failed due to Resource Unavailable Error`** | Requested resources (GPUs) not available | • Choose a different accelerator type
• Reduce instance count
• Try again during off-peak hours
• Contact [support](https://support.simplismart.ai/support/tickets/new) for resource availability |
| **Deployment Unstable After Edit** | New configuration causing issues | • System should auto-rollback if health checks fail
• If not, create a new deployment with previous configuration
• Review deployment logs for error details
• Contact [support](https://support.simplismart.ai/support/tickets/new) if issues persist |
# Inference & Monitoring
Source: https://docs.simplismart.ai/model-suite/deployments/inference-and-monitoring
### Steps for Using the Deployed Model and Monitoring it's Performance
Once the model is successfully deployed, you can follow these steps to begin inference:
* Go to the **API** tab of your model
* Find the **Endpoint URL** and the pre-generated inference script
* Copy the script, replace placeholder values, and execute it to call the model
**How to access your API Key?**
Go to **Account Settings** and select **API Key**
***
The Monitor tab provides an overview of your deployment's performance.
1. **Monitor Real-Time Status:**
* **Pod Info:** Status and count of active pods
* **Throughput & Latency:** Requests per second and processing time
* **Success & Failure Rates:** Percentage of successful and failed inferences
**2. Resource Monitoring**: Various system level metrics can be tracked along with system load information; such as CPU/ GPU usage & request metrics.
# SSH Access
Source: https://docs.simplismart.ai/model-suite/deployments/ssh-access
Configure SSH access to connect directly to a running deployment container
SSH access lets you connect directly to a running container in your deployment, which is useful for debugging, inspecting logs, or running ad-hoc commands without rebuilding and redeploying.
Toggle **SSH Access** on during deployment creation to configure it. Up to 5 users per deployment are supported.
## SSH Runtime
The **SSH Runtime** dropdown controls how SSH is served:
* **Sidecar**: Simplismart injects a sidecar container that handles SSH. Use this if your image does not already include an SSH server. No changes to your Dockerfile are required.
* **Main Container**: SSH runs inside your primary container. Use this when you are bringing your own image that already has `openssh-server` installed and configured.
## Users
**Primary User** is created automatically. The username is derived from your deployment slug (e.g. `-`) and gets **Root** access by default.
**Additional Users** follow the format `--` and are granted **Limited** access. You can add up to 4 additional users alongside the primary user.
Each user is associated with an **SSH Secret**, a Kubernetes secret holding the authorized public key for that user.
## Bringing Your Own Image with SSH
If you select **Main Container** as the runtime, your image must have `openssh-server` installed and `sshd` configured to start on launch. Below is a reference Dockerfile:
```dockerfile theme={null}
FROM nvidia/cuda:13.0.0-runtime-ubuntu24.04
RUN apt-get update && \
apt-get install -y --no-install-recommends \
bash \
openssh-server \
openssh-client \
libnss-wrapper && \
rm -rf /var/lib/apt/lists/*
COPY entrypoint.sh /usr/local/bin/entrypoint.sh
RUN chmod +x /usr/local/bin/entrypoint.sh
RUN set -eux; \
if ! getent group 1000 >/dev/null; then groupadd -g 1000 appuser; fi; \
if ! id -u 1000 >/dev/null 2>&1; then useradd -u 1000 -g 1000 -s /bin/bash -M appuser; fi
EXPOSE 2222
USER 1000:1000
ENTRYPOINT ["/usr/local/bin/entrypoint.sh"]
```
If your environment requires CUDA 12.x, replace the base image in the Dockerfile above with:
```dockerfile theme={null}
FROM nvidia/cuda:12.9.1-runtime-ubuntu24.04
```
The rest of the Dockerfile remains unchanged.
Create an `entrypoint.sh` file in the same directory as your Dockerfile. This script initializes the SSH environment and starts the SSH daemon:
```bash entrypoint.sh theme={null}
#!/bin/bash
set -euo pipefail
# When not the designated ssh sidecar, skip sshd and idle as the main container.
if [ "${SSH_CONTAINER_ROLE:-}" != "sidecar" ]; then
exec /bin/sleep infinity
fi
RUNTIME="${SSH_RUNTIME_DIR:-/ssh-runtime}"
SSH_UID="${PUID:-1000}"
SSH_GID="${PGID:-1000}"
if [ ! -d "${RUNTIME}" ]; then
echo "ERROR: SSH runtime dir ${RUNTIME} is missing; ensure the ssh-runtime volume is mounted here" >&2
exit 1
fi
# SSH_USERNAMES: comma-separated list of all usernames that SSHPiper may forward.
# Each gets a passwd entry so sshd can resolve them (all map to uid/gid 1000).
IFS=',' read -ra USERS <<< "${SSH_USERNAMES:-${SSH_USERNAME:-deployment-user}}"
: > "${RUNTIME}/nss-passwd"
: > "${RUNTIME}/nss-group"
for USER in "${USERS[@]}"; do
USER="${USER// /}" # trim spaces
[ -n "${USER}" ] || continue
echo "${USER}:x:${SSH_UID}:${SSH_GID}:SSH User:${RUNTIME}/home:/bin/bash" >> "${RUNTIME}/nss-passwd"
done
echo "${USERS[0]}:x:${SSH_GID}:" >> "${RUNTIME}/nss-group"
NSS_WRAPPER_LIB=$(find /usr/lib -name "libnss_wrapper.so*" -type f 2>/dev/null | head -1)
if [ -z "${NSS_WRAPPER_LIB}" ]; then
echo "ERROR: libnss_wrapper.so not found — cannot resolve SSH username" >&2
exit 1
fi
export NSS_WRAPPER_PASSWD="${RUNTIME}/nss-passwd"
export NSS_WRAPPER_GROUP="${RUNTIME}/nss-group"
export LD_PRELOAD="${NSS_WRAPPER_LIB}"
if [ ! -f "${RUNTIME}/sshd_config" ]; then
if [ -x /ssh-init/05-ssh-init.sh ]; then
/bin/bash /ssh-init/05-ssh-init.sh
else
# main_container mode: no init container pre-runs; self-initialise.
ssh-keygen -t ed25519 -f "${RUNTIME}/ssh_host_ed25519_key" -N "" -q
ssh-keygen -t rsa -b 4096 -f "${RUNTIME}/ssh_host_rsa_key" -N "" -q
chmod 600 "${RUNTIME}/ssh_host_"*
AUTH_KEYS="${SSH_AUTHORIZED_KEYS_FILE:-${RUNTIME}/home/.ssh/authorized_keys}"
mkdir -p "$(dirname "${AUTH_KEYS}")"
[ -f "${AUTH_KEYS}" ] || touch "${AUTH_KEYS}"
chmod 600 "${AUTH_KEYS}"
if [ "${SSH_AUDIT_LOGGING:-true}" = "true" ]; then
cat > "${RUNTIME}/ssh-audit-shell" << 'AUDIT_EOF'
#!/bin/bash
SESSION_ID=$(tr -dc 'a-f0-9' < /dev/urandom 2>/dev/null | head -c8 || printf '%x' "$(date +%s)")
SRC_IP="${SSH_CLIENT%% *}"
TS="$(date -u +%Y-%m-%dT%H:%M:%SZ)"
printf '%s SSH_AUDIT connect user=%s src=%s session=%s\n' "$TS" "$USER" "$SRC_IP" "$SESSION_ID" >&2
if [ -n "${SSH_ORIGINAL_COMMAND:-}" ]; then
printf '%s SSH_AUDIT exec user=%s src=%s session=%s cmd=%s\n' "$TS" "$USER" "$SRC_IP" "$SESSION_ID" "$(printf '%q' "$SSH_ORIGINAL_COMMAND")" >&2
exec /bin/bash -c "$SSH_ORIGINAL_COMMAND"
else
exec /bin/bash -l
fi
AUDIT_EOF
chmod +x "${RUNTIME}/ssh-audit-shell"
fi
SSH_PORT_VAL="${SSH_PORT:-2222}"
cat > "${RUNTIME}/sshd_config" << EOF
Port ${SSH_PORT_VAL}
HostKey ${RUNTIME}/ssh_host_ed25519_key
HostKey ${RUNTIME}/ssh_host_rsa_key
PidFile ${RUNTIME}/sshd.pid
AuthorizedKeysFile ${AUTH_KEYS}
UsePAM no
PasswordAuthentication no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
AllowTcpForwarding no
AllowAgentForwarding no
GatewayPorts no
X11Forwarding no
MaxAuthTries 3
MaxSessions 2
LoginGraceTime 30
ClientAliveInterval 120
ClientAliveCountMax 2
PermitEmptyPasswords no
PermitUserEnvironment no
PermitUserRC no
PermitTunnel no
PrintLastLog yes
EOF
if [ "${SSH_AUDIT_LOGGING:-true}" = "true" ]; then
echo "ForceCommand ${RUNTIME}/ssh-audit-shell" >> "${RUNTIME}/sshd_config"
fi
fi
fi
exec /usr/sbin/sshd -D -e -f "${RUNTIME}/sshd_config"
```
Key requirements:
* `openssh-server` must be installed, SSH will not work without it.
* Password authentication is disabled; only public key auth is accepted.
* Port `2222` must be exposed.
* `ssh-keygen -A` generates the host keys at build time.
* The `CMD` optionally runs a bootstrap script (passed via `$SSH_BOOTSTRAP_SCRIPT`) before starting `sshd` in the foreground.
The SSH Secret you configure in the Secrets tab must contain the public key that corresponds to the private key you will use when connecting.
## Generate an SSH Key Pair
Before creating your deployment, generate a key pair:
```bash theme={null}
ssh-keygen -t ed25519 -f simplismart_key
cp simplismart_key simplismart_key.pem
```
This produces two files:
* `simplismart_key.pem`: your private key. Keep this locally; never share it.
* `simplismart_key.pub`: your public key. Add this to Simplismart as an **SSH Public Key** secret under [Integrations → Secrets](/model-suite/integrations/secrets).
When configuring SSH Access in the deployment form, select that secret from the **SSH Secret** dropdown for each user.
## Connecting to a Running Deployment
Once the deployment status shows `deployed`, open the deployment detail page. The **SSH Access** section shows the ready-to-use command pre-filled with your username and host:
Copy the command and point `-i` to your `.pem` private key file:
```bash theme={null}
ssh -i simplismart_key.pem -p 2222 -@
```
The panel also displays:
* **SSH User**: Auto generated primary username tied to your deployment slug
* **Access Level**: `root` for the primary user, `limited` for additional users
* **SSH Runtime**: `sidecar` or `main_container`, as configured at creation
# Cloud Accounts
Source: https://docs.simplismart.ai/model-suite/integrations/cloud-account
Steps to guide you through the process of adding your Cloud Accounts.
* Navigate to the Integrations tab in the main menu and click on [Cloud Accounts](https://app.simplismart.ai/integrations/cloud-accounts).
* On the Cloud Accounts page, click on the **Add Cloud Account** button.
***
## **Enter Cloud Account Details**
* Choose your cloud provider from the list & select the default region for your cloud account.
* Provide a name for your cloud account.
* Select the linked cloud credentials from the dropdown menu. (previously added in the [Secrets](/model-suite/integrations/secrets) tab)
* After entering all the necessary details, click the **Add Cloud Account** button to save.
* Your organization’s cloud accounts will now be displayed on the main [**Cloud Accounts**](https://app.simplismart.ai/integrations/cloud-accounts) page.
# Hosted Zone
Source: https://docs.simplismart.ai/model-suite/integrations/hosted-zone
Step-by-step guide for creating and managing Hosted Zones.
* Navigate to the **Integrations** tab in the main menu and click on [**Hosted Zones**](https://app.simplismart.ai/integrations/hosted-zones)**.**
* On the Hosted Zones page, click the **Add Hosted Zone** button.
* Provide a name for your hosted zone, and enter details of the domain, subdomain and the zone id of the same.
* Select the linked cloud credentials from the dropdown menu. (previously added in the [Cloud Accounts](/model-suite/integrations/cloud-account) tab)
* After entering all the necessary details, click the **Add Hosted Zone** button to save.
* Your organization’s hosted zones will now be displayed on the main [Hosted Zones](https://app.simplismart.ai/integrations/hosted-zones) page.
# Secrets
Source: https://docs.simplismart.ai/model-suite/integrations/secrets
Store and manage credentials used by integrations, clusters, registries, and deployments.
Secrets are secure credentials stored within Simplismart platform that allow the platform to access external systems such as cloud accounts, container registries, model sources, or Kubernetes clusters.
Secrets typically include:
* Access keys
* API tokens
* Service account credentials
* Cluster authentication details
All secrets are stored securely and are only used for the specific integrations or deployments where they are referenced.
Token-based and certificate-based authentication cannot be used together. Choose only one method.
## Why secrets are used
Secrets are required to:
* Access cloud infrastructure for cluster creation or import
* Pull containers from private registries
* Download models from external sources
* Authenticate with Kubernetes clusters
Using secrets ensures:
* Credentials are not exposed in plain text
* Access can be centrally managed
* Integrations can be reused across deployments
## Add a Secret
Go to **Integrations → Secrets** in the Simplismart UI.
Click the **Create Secret** button to open the secret creation form.
Enter a descriptive **secret name** and choose the appropriate **secret type** from the dropdown menu (e.g., `AWS`, `GCP`, `Docker Hub`, `Hugging Face`, `Kubernetes`, `Generic`).
Paste the credentials in the specified JSON format into the provided text area. Refer to the sections below for examples of required structures for each secret type.
Click **Create** to securely store the secret.
Once created, the secret is securely stored and available for use across your organization's integrations and deployments.
## Using Secrets
Secrets can be used in:
* Cloud account integrations
* Cluster creation or import
* Container registry access
* Model source authentication
When configuring an integration or deployment, select the relevant secret from the dropdown.
## Edit Secrets
To modify an existing secret:
Go to **Integrations → Secrets**.
Locate the secret you wish to modify from the list, then click the **Edit** button on the top right corner of the screen.
Adjust the credentials in the JSON format as needed. Ensure the new credentials are valid for the secret type.
Click **Save Changes** to update the secret.
## Cloud Credentials
Cloud credentials (often referred to as cloud secrets) enable Simplismart to interact with your cloud infrastructure for tasks such as:
* Creating or importing Kubernetes clusters
* Managing storage resources for model artifacts and training data
* Deploying workloads to your cloud environment
**Best Practices for Cloud Credentials**
When configuring cloud credentials, follow these best practices to maintain a secure and efficient environment:
Allocate a dedicated cloud account, project, or subscription specifically for Simplismart operations to isolate resources and permissions.
Grant only the minimum necessary permissions required for Simplismart to perform its functions. Avoid overly broad access.
Implement a policy for periodic rotation of access keys and API tokens to reduce the risk of compromise.
Never use personal or root account credentials. Always use service accounts or roles with specific, limited permissions.
The specific permissions required depend on the actions Simplismart will perform (e.g., cluster creation vs. ongoing maintenance). For initial setup, broader access might simplify configuration, which can then be refined to a more restrictive policy.
### Required Permissions for Cloud Providers
Below are the recommended initial roles for integrating with major cloud providers. These roles provide sufficient permissions for Simplismart to manage resources effectively. You can refine these permissions after the initial setup.
AWS secrets allow Simplismart to create or manage EKS clusters and access storage resources.
#### Required Credentials
Provide the following fields in the JSON format:
* `access_key_id`
* `secret_access_key`
#### IAM Policies
* **S3 Access**: Required for model storage, logs, and artifacts. Permissions: `s3:ListBucket`, `s3:GetObject`, `s3:PutObject`.
* **EKS Full Access (Create Cluster)**: Required when creating new clusters from the platform. Recommended policies: `AmazonEKSClusterPolicy`, `AmazonEKSServicePolicy`, or `AdministratorAccess` (recommended for initial setup).
* **EKS Maintenance Access (Import Cluster)**: Required when importing an existing cluster. Permissions: Node group access, cluster read/write operations, networking updates.
#### Best practices
* Create a separate AWS sub-account for Simplismart.
* Avoid using root credentials.
* Use role-based access where possible.
```json AWS Credentials JSON Example theme={null}
{
"access_key_id": "",
"secret_access_key": ""
}
```
GCP secrets allow Simplismart to manage GKE clusters and access storage.
#### Required Credentials
Provide the JSON service account key for a dedicated service account.
#### IAM Policies
* **GCS Access**: Required for model storage, logs, and artifacts. Recommended role: `Storage Object Admin`.
* **GKE Full Access (Create Cluster)**: Required when creating clusters. Recommended roles: `Kubernetes Engine Admin`, `Compute Admin`.
* **GKE Maintenance Access (Import Cluster)**: Required when importing existing clusters. Recommended roles: `Kubernetes Engine Developer`, cluster read/write permissions.
#### Best practices
* Create a separate GCP project for Simplismart.
* Use a dedicated service account.
* Avoid using personal credentials.
```json GCP Credentials JSON Example theme={null}
{
"auth_provider_x509_cert_url": "",
"auth_uri": "",
"client_email": "",
"client_id": "",
"client_x509_cert_url": "",
"private_key": "",
"private_key_id": "",
"project_id": "",
"token_uri": "",
"type": "",
"universe_domain": ""
}
```
Azure secrets allow Simplismart to manage AKS clusters and storage resources.
#### Required Credentials
Provide the following fields in the JSON format:
* `tenant_id`
* `client_id`
* `client_secret`
* `subscription_id`
#### IAM Policies
* **Azure Blob Storage Access**: Required for model artifacts, logs, and outputs. Recommended role: `Storage Blob Data Contributor`.
* **AKS Full Access (Create Cluster)**: Required when creating clusters. Recommended role: `Contributor` on the subscription or resource group.
* **AKS Maintenance Access (Import Cluster)**: Required when importing existing clusters. Recommended role: `Contributor` on the cluster resource group.
#### Best practices
* Create a separate resource group for Simplismart.
* Use a dedicated service principal.
* Avoid using global subscription credentials.
```json Azure Credentials JSON Example theme={null}
{
"client_id": "",
"client_secret": "",
"subscription_id": "",
"tenant_id": ""
}
```
QBlocks secrets allow Simplismart to access QBlocks infrastructure resources for cluster provisioning and resource management.
#### Best practices
* Use a dedicated account for Simplismart.
* Limit permissions to required resources.
```json QBlocks Credentials JSON Example theme={null}
{
"API_KEY": ""
}
```
## Container Registries
Secrets for container registries enable Simplismart to pull private container images for your deployments and model serving. Each registry type has specific credential requirements.
Docker Hub secrets are used to pull private container images from Docker Hub repositories. Use a **Personal Access Token** instead of your password for authentication.
#### Set up a personal access token
1. Log in to Docker Hub.
2. Go to **Account Settings → Security**.
3. Create a new **Access Token**.
4. Copy the token.
5. Add it as a secret in Simplismart.
#### Best practices
* Create a separate registry or organisation for Simplismart.
* Use read-only tokens where possible.
```json Docker Hub Credentials JSON Example theme={null}
{
"username": "",
"password": ""
}
```
Depot secrets facilitate pulling private containers stored in Depot registries. A **Personal Access Token** is required to authenticate.
#### Set up a personal access token
1. Log in to Depot.
2. Generate a personal access token.
3. Add the token as a secret in Simplismart.
#### Best practices
* Use a dedicated registry or repository for Simplismart.
* Restrict token scope to required repositories.
```json Depot Credentials JSON Example theme={null}
{
"username": "x-token",
"token": ""
}
```
NVIDIA NIM secrets provide access to NVIDIA model containers and other resources on NVIDIA NGC.
#### Set up a personal access token
1. Generate a token from the NVIDIA NGC portal.
2. Add it as a secret in Simplismart.
#### Best practices
* Use a dedicated account for Simplismart.
* Limit token scope to required images.
```json NVIDIA NIM Credentials JSON Example theme={null}
{
"server": "nvcr.io",
"password": "",
"username": "$oauthtoken"
}
```
Amazon ECR secrets are used to pull private container images from Amazon Elastic Container Registry. Authentication uses an AWS IAM access key with permission to pull from ECR.
#### Set up AWS credentials
1. In the AWS IAM console, create (or reuse) an IAM user with ECR pull permissions (e.g. `AmazonEC2ContainerRegistryReadOnly`).
2. Generate an **access key** and **secret access key** for that user.
3. Note the **region** of your ECR registry (e.g. `us-west-2`).
4. Add them as a secret in Simplismart.
#### Best practices
* Use an IAM user scoped to read-only ECR access.
* Restrict permissions to the specific repositories Simplismart needs to pull.
```json Amazon ECR Credentials JSON Example theme={null}
{
"region": "",
"accessKey": "",
"secretKey": ""
}
```
## Model Sources
Secrets for model sources allow Simplismart to access and download private or gated models from external platforms.
Hugging Face secrets enable the download of private or gated models from the Hugging Face Hub. A **Personal Access Token** is required for authentication.
#### Set up an API key
1. Log in to Hugging Face.
2. Go to **Settings → Access Tokens**.
3. Create a new token.
4. Copy the token.
5. Add it as a secret in Simplismart.
#### Best practices
* Create a separate account for Simplismart.
* Use tokens with **read-only access**.
* Grant access only to required models.
```json Hugging Face Credentials JSON Example theme={null}
{
"token": ""
}
```
Support for integrating GitHub-based model or container sources will be available in a future Simplismart release.
## Kubernetes Cluster Credentials
Kubernetes cluster credentials store the necessary authentication details to connect Simplismart to an existing Kubernetes cluster. These are used when importing clusters or deploying workloads to an imported cluster.
Use either token-based or certificate-based authentication, not both.
Kubernetes secrets are required to:
* Import clusters into the platform
* Authenticate API access
* Manage deployments
\*\* Best practices\*\*
* Use a dedicated cluster for Simplismart workloads.
* Avoid sharing clusters with unrelated production systems.
* Use a dedicated subdomain for the cluster.
To authenticate using a service account token:
```json Kubernetes Token JSON Example theme={null}
{
"token": "",
"server": "",
"ca_certificate": ""
}
```
To authenticate using client certificates:
```json Kubernetes Certificate JSON Example theme={null}
{
"server": "",
"client_key": "",
"ca_certificate": "",
"client_certificate": ""
}
```
## OCI Cluster Credentials
OCI credentials enable Simplismart to securely integrate with your Oracle Cloud Infrastructure (OCI) environment. These credentials are required to import existing OCI clusters, allowing you to deploy, manage, and scale models directly on your OCI-hosted infrastructure.
Simplismart supports both token-based and certificate-based authentication for OCI clusters.
To authenticate using an OCI token:
```json OCI Token JSON Example theme={null}
{
"token": "",
"server": "",
"client_key": "",
"ca_certificate": "",
"client_certificate": ""
}
```
To authenticate using OCI certificates:
```json OCI Certificate JSON Example theme={null}
{
"server": "",
"client_key": "",
"client_certificate": "",
"ca_certificate": ""
}
```
## SSH Public Key
SSH Public Key secrets are used to SSH into a running deployment container. See [SSH Access](/model-suite/deployments/ssh-access) for the full setup flow.
Generate a key pair on your local machine:
```bash theme={null}
ssh-keygen -t ed25519 -f simplismart_key
cp simplismart_key simplismart_key.pem
```
* `simplismart_key.pem` — private key, used when connecting via `ssh -i`
* `simplismart_key.pub` — public key, add this to Simplismart as the secret
Paste the contents of `simplismart_key.pub` when creating the secret:
```json SSH Public Key JSON Example theme={null}
{
"public_key": "ssh-ed25519 AAAAC3Nza... user@host"
}
```
## Generic Secrets
Generic secrets provide a flexible way to securely store any custom credentials or sensitive information not covered by the specific secret types above. These can include third-party API keys, custom authentication tokens, or other environment variables.
#### How to add a generic secret?
1. Go to **Integrations → Secrets**.
2. Click **Create Secret**.
3. Select **Generic Secret**.
4. Enter key-value pairs in the required JSON format.
5. Save the secret.
```json Generic Secret JSON Example theme={null}
{
"KEY_NAME": "VALUE"
}
```
# Optimise a Model
Source: https://docs.simplismart.ai/model-suite/optimise-a-model
End-to-end process for adding, configuring, and compiling a model on the Simplismart platform.
This guide walks you through adding a model, choosing infrastructure, and applying model-specific optimisation settings for LLMs, diffusion, and speech (ASR).
Models are scoped to the active workspace. Use the workspace toggle in the breadcrumb navigation to switch workspaces before importing or compiling a model. See [Workspaces](/model-suite/settings/workspaces) for details.
## 1. Enter model details
Navigate to **Add Model** to register a new model in Simplismart.
* **Name (Required)**: A unique identifier for the model within the platform.
* **Description (Optional)**: Short note about the model’s purpose.
### Model source (required)
Specifies where the model artifacts are loaded from.
| Option | Description |
| --------------------- | --------------------------------------- |
| **Hugging Face (HF)** | Load directly from the Hugging Face Hub |
| **AWS S3** | Load from an S3 bucket |
| **GCP GCS** | Load from a Google Cloud Storage bucket |
| **Public URL** | Load from a publicly accessible URL |
If using Hugging Face, you can enable **Private Model** for gated or private repositories.
If you use a **private model from Hugging Face**, add your **Hugging Face access token as a [secret](/model-suite/integrations/secrets)** in [Integrations](https://app.simplismart.ai/integrations/secrets) first, then select that secret when configuring the model.
* Go to [huggingface.co](https://huggingface.co/).
* Use the **search bar** to find the model (e.g. "whisper-large").
* Open the model from the results (e.g. `openai/whisper-large-v3-turbo`).
* Copy the **model path** at the top of the page (format: `creator/model-slug`).
### Model path (required)
The exact path to the model. The platform verifies the path automatically.
* **Hugging Face:** `meta-llama/Llama-3.1-8B-Instruct`
* **AWS S3:** `s3://my-bucket/model/`
* **GCP GCS:** `gs://my-bucket/model/`
* **Public URL:** `https:///model`
**Cloud credentials**: For **AWS S3** or **GCP GCS**, provide the relevant cloud credentials in [Secrets](model-suite/integrations/secrets) tab so the platform can access private storage.
### Model class (required)
Defines the pipeline or architecture class used to load the model. This is usually auto-selected from the model source and path.
Here are some examples of model classes:
| Class | Use case |
| --------------------------------- | --------------------------------------------------------------------- |
| `LlamaForCausalLM` | LLMs |
| `WhisperForConditionalGeneration` | Speech (ASR) models |
| `FluxPipeline` | Diffusion models |
| `CustomPipeline` | [Custom](model-suite/adding-a-custom-model) or non-standard pipelines |
For **LLMs**, only **instruct-style (chat-optimized) models** are supported in model compilation. They often use the suffix `-Instruct` (e.g. `meta-llama/Llama-3.2-3B-Instruct`). Base models such as `meta-llama/Llama-3.2-3B` are **not supported**.
***
## 2. Optimising infrastructure
This section determines **where the model will be deployed**. Configuration depends on whether you choose **Simplismart Cloud** or **Bring Your Own Cloud (BYOC)**.
A fully managed environment where infrastructure is provisioned automatically.
**Accelerator options**
* **L40S**: Recommended for most production speech workloads.
* **H100**: Best for high-throughput or low-latency deployments.
Choose an accelerator that matches your model size and latency requirements.
Deploy the model into your own cloud account. You must provide:
* **Accelerator (Required)**: Hardware for running the model.
* **Cloud account (Required)**: Connected cloud account where the deployment will run. Select an account added under [Cloud Accounts](/model-suite/integrations/cloud-account).
* **Region (Required)**: Cloud region for deployment.
* **Machine type (Required)**: Instance type that includes the chosen accelerator.
* **Machine count (Required)**: Number of machines to deploy.
***
## 3. Model-specific configuration
After **model details** and **optimising infrastructure**, the remaining settings depend on the **type of model** you are adding:
* **LLMs**: Chat, completion, embedding
* **Diffusion models**: Image generation
* **Speech (ASR / Whisper)**: Transcription
* **Custom pipelines**: User-defined or non-standard architectures. For more information check out this doc on [adding a custom model](model-suite/adding-a-custom-model).
The sections below describe the options for each type.
***
## Adding LLMs
LLM models include chat, completion, and embedding workloads.
By default, the platform selects the most suitable compilation settings for LLMs based on the model architecture.
### Backend selection
Controls the inference backend used to serve the model. LLMs support multiple optimised backends.
* **Auto**: Simplismart selects the optimal backend automatically.
* **Latest**: Recommended unless you need a specific version.
For details, see the [LLM Optimization Guide](/guides/optimization-guide).
### Parallelism
| Strategy | Description | Use case |
| ------------------------ | --------------------------------------------------------------------- | -------------------------------------------- |
| **Data parallelism** | Full model replicated on each GPU; each GPU handles separate requests | Higher throughput; concurrent traffic |
| **Pipeline parallelism** | Model layers split across GPUs; each GPU holds part of the model | When the model is too large for a single GPU |
| **Expert parallelism** | For **Mixture-of-Experts (MoE)**; experts distributed across GPUs | MoE scalability and efficiency |
### Pipeline task
Defines what the model is used for. This affects request/response formatting and runtime behaviour.
* **Chat**: Conversational models
* **Completion**: Text generation
* **Embedding**: Vector generation models
### Speculative decoding (optional)
Improves latency by generating tokens using a draft strategy. **Recommended: On** for chat and completion workloads.
### Extra params
Advanced backend-specific configuration in JSON format. Leave empty unless you need custom tuning.
### LoRA configuration (optional)
LoRA (Low-Rank Adaptation) lets you load fine-tuned adapters on top of a base model.
* **Enable LoRA**: Turn this on to attach LoRA adapters to the base model.
* **Via LoRA list**: Add adapters from **different** sources (e.g. one from Hugging Face, another from S3). Use **Add LoRA path** for each adapter.
* **Via LoRA repo**: Add **all** adapters from a **single** source in one go. Use **Add LoRA Repo** and give one repo location; the platform fetches every LoRA in that repo.
For each path or repo you add, set:
| Field | Description |
| --------------------- | ----------------------------------------------------------------------------------------------------- |
| **Source (Required)** | Where the weights are stored (e.g. AWS S3, Hugging Face, GCP GCS). |
| **Secret (Required)** | Credentials for that source. Create or pick a secret in [Secrets](/model-suite/integrations/secrets). |
| **Path (Required)** | Adapter location in the source (e.g. `s3://my-bucket/my-lora`). |
For **Via LoRA repo**, the secret field must be in the JSON format expected by the platform. See [Secrets](/model-suite/integrations/secrets) for the required format.
***
## Adding diffusion models
### Parallelism
| Type | Description | Use case |
| --------------------------------- | -------------------------------------------------------------------- | --------------------------------------------------------- |
| **Context parallelism** | Splits input context or latent representation across GPUs | High-resolution image generation; memory-intensive models |
| **Fully shared data parallelism** | Replicates the model across GPUs; each GPU handles separate requests | High-throughput production; concurrent image generation |
### DiT optimisation (diffusion only)
**Attention backend**: Selects the attention implementation during inference.
* **Flash**: Optimised attention for better performance.
* **Torch**: Standard PyTorch attention.
* **Auto**: Platform selects the best option.
**Recommended:** Auto
### Additional optimisation settings
* **Enable attention caching**: Caches attention states to reduce repeated computation and improve speed.
* **Cache threshold**: When caching is applied (default: `0.25`). Higher values can improve speed but may reduce output quality.
* **Enable compilation**: Compiles the model graph for faster inference.
* **Fullgraph**: Compiles the entire model for maximum performance.
* **Dynamic**: Supports variable input shapes.
**Recommended:** Enable **Fullgraph** for stable production workloads.
***
## Adding ASR (speech) models
### Optional pipeline add-ons
#### **Voice activity detection (VAD) model**
Detects speech segments and removes silence before transcription.
**VAD options:**
* **Auto**: Platform selects the best VAD.
* **Silero**: Lightweight, fast VAD.
* **Frame**: Frame-based detection.
**Recommended:** Auto or Silero
#### **Diarization model (optional)**
Separates and labels different speakers in the audio.
Enable diarization if you need **speaker-wise transcripts**.
# API Keys
Source: https://docs.simplismart.ai/model-suite/settings/api-keys
Generate and manage API keys to authenticate requests to your Simplismart.ai organisation
API keys authenticate requests to the Simplismart.ai platform, giving you programmatic access to deploy, call, and manage models within your organisation.
## Generating an API Key
1. Navigate to **Settings -> API Keys** in your organisation dashboard.
2. Click **Generate Key**. The **Add API Key** popup appears.
3. Enter a **Key Name** (e.g., `prod-inference`, `ci-pipeline`).
4. Select an **Expiration** from the dropdown (e.g., `1 week`). The **Expires on** date is calculated automatically.
5. Click **Generate New Key**.
6. Copy the key.
Once generated, the key appears in the API Keys table.
For non-expiring tokens, contact the [Simplismart team](mailto:support@simplismart.ai).
## Key Expiry
Each key displays its expiry date in the API Keys table. Keys expire at midnight UTC on the configured date and will return `401 Unauthorized` after that point. Rotate keys before expiry to avoid service interruption.
| Field | Description |
| ---------------- | ------------------------------------------------------------ |
| Name | Label you assigned at creation |
| Created at | Date the key was generated |
| Expires on (UTC) | Date the key becomes invalid (`Never` for non-expiring keys) |
| Status | `Active` or `Expired` |
## Using Your API Key
Pass the API key as a Bearer token in the `Authorization` header on every request:
```bash theme={null}
curl 'https://api.simplismart.live/chat/completions' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer ' \
-d '{
"model": "meta-llama/Meta-Llama-3.1-8B-Instruct",
"messages": [
{
"role": "user",
"content": "write a sentence on usa"
}
]
}'
```
For SDK usage, set it via the environment variable your client expects:
```bash theme={null}
export SIMPLISMART_API_KEY=""
```
## Deleting an API Key
Click the **Delete** action next to any key in the table to invalidate it immediately. Deleting a key is permanent and any service using it will need to be updated with a new key.
## Best Practices
* **One key per environment**: Use separate keys for `dev`, `staging`, and `production` so you can rotate one without affecting others.
* **Never commit keys to source control**: Use environment variables or a secrets manager.
* **Set expiry dates**: Short-lived keys reduce the impact even if a key is leaked.
* **Rotate regularly**: Generate a replacement before deleting the old key to avoid downtime.
# Billing
Source: https://docs.simplismart.ai/model-suite/settings/billing
The Billing section provides visibility into how your organisation is charged for platform usage, including credits, invoices, payments, and account balance status.
The **Billing** section helps you manage your account balance, view invoices, and understand how you are charged for platform usage. It includes information about **credits, invoices, payments, and account balance status**, along with guidance on handling low balance scenarios.
***
## Credits
Credits represent the **balance available in your account to pay for platform usage**. When you run workloads such as deployments, training, or compilation, the corresponding cost is deducted from your available credits.
### Credit System
* **1 Credit = \$1** (US Dollar)
### Free Credits
New organisations may receive **free credits** worth \$5 that can be used to explore the platform and run workloads before adding paid credits. Free credits are automatically applied to your account and are consumed in the same way as purchased credits.
### Adding Credits
You can add credits to your account through the **Payments** section. Credits are added immediately after a successful payment and become available for usage across platform services.
***
## Invoices
Invoices provide a **detailed breakdown of charges for your organisation’s usage** during a billing cycle.
Each invoice includes:
* Invoice ID
* Billing period
* Usage details
* Total amount charged
* Applicable taxes
* Payment status
### Invoice Format
Invoices are generated with a structured summary of:
* Usage across services
* Pricing applied
* Total payable amount
* Tax components (if applicable)
Invoices can be accessed from the **Billing section of the platform**.
***
## Billing Models
Simplismart supports both prepaid and postpaid billing models.
In a **prepaid billing model**, usage charges are deducted from the **credits available in your account**.
* Credits must be added in advance.
* Charges are deducted in real-time based on usage.
* Deployments and workloads continue as long as sufficient credits are available.
In a **postpaid billing model**, usage is tracked throughout the billing cycle and **invoiced at the end of the period**.
* Usage is accumulated during the billing cycle.
* Payment is made after the invoice is generated.
* Typically enabled for organisations with predictable or higher usage.
### Converting to Postpaid
Organisations may switch from prepaid billing to postpaid billing based on usage patterns and operational requirements. Postpaid billing may be suitable when:
* Usage is consistent and predictable.
* Teams prefer consolidated billing instead of managing credits.
* Workloads are large or continuous.
To request conversion to postpaid billing, please contact the Simplismart team.
***
## Payments
The **Payments** section allows organisations to add credits and manage billing payments.
Please ensure you have added your **billing address** before adding new credits to the platform. You can update your billing address in the `Organisation` tab.
### For Prepaid
Credits can be added using the following payment methods:
* **Credit Card**: Payments can be made using supported credit cards. Once the payment is successful, credits are automatically added to the account.
* **UPI**: UPI payments are supported for adding credits. After the transaction is completed, the credits are reflected in your balance.
* **Netbanking**: You can also add credits using netbanking through supported banking partners.
### For Postpaid
For postpaid accounts, payments are made **against generated invoices** at the end of the billing cycle. Your organisation will receive invoice details along with the payment instructions.
### Taxation
Applicable taxes are calculated and added to invoices based on the **billing country and regulatory requirements**. Tax details are included in the invoice breakdown.
***
## Low Balance Issues
### What is Low Balance?
A **low balance state** occurs when the available credits in your account fall below the amount required to run active workloads.
### What are the Consequences?
If the balance becomes too low, the platform may not be able to continue running certain workloads. Potential consequences include:
* New deployments may fail to start.
* Existing deployments may stop.
* Training or compilation tasks may not run.
### What to Do When Low Balance?
Go to the **Billing** section of the platform.
Add credits to your account using one of the supported payment methods.
Ensure that the credit balance has been updated in your account dashboard.
Once credits are available, workloads can resume normally.
### Account Suspension
In cases where the account balance remains insufficient for an extended period, **account activity may be restricted** until the balance is replenished.
### Deployment Stoppage
Active deployments may be **automatically stopped** if the account balance cannot support the required compute usage.
# General Settings
Source: https://docs.simplismart.ai/model-suite/settings/general-settings
Manage your profile and organisation info within this section
Here you can manage your profile, organization details, and set up an organisation.
## **Manage Profile and Personal Info**
* **Update Profile**: Edit your personal information here
***
## **Creating an Organization**
* Click on the **Add Organization** button
* Provide a name for the new organization
* Click on the **Create** button to finish creating the organization
# Quotas
Source: https://docs.simplismart.ai/model-suite/settings/quotas
Quotas define usage limits for resources available to your organisation, ensuring fair allocation of infrastructure and preventing excessive usage.
Quotas define **usage limits for resources available to your organisation**. They help ensure fair allocation of infrastructure and prevent excessive usage beyond permitted limits.
A quota is a **limit on the amount of a specific resource your organisation can use** at a given time.
Quotas help control:
* Infrastructure usage
* Concurrent workloads
* Resource allocation across teams
***
## GPU Quotas
GPU quotas determine the **maximum GPU resources your organisation can use simultaneously**.
### Where is it Applicable?
GPU quotas apply to the following platform operations:
* **Training**: GPU usage during **model training jobs** counts toward the quota.
* **Compilation**: Some **model compilation processes** require GPU resources and will consume quota.
* **Private Deployment**: For private deployments, GPU quotas apply to the **maximum replicas allowed**, not the desired replicas configured in the deployment. This ensures that scaling operations remain within the allowed GPU limits.
***
## Default Quotas
By default, every new organization receives:
* **1 × H100 GPUs**
* **1 × L40 GPUs**
### Automatic Quota Release
Quotas are automatically released once:
* A training or compilation job completes successfully, or
* A job fails and is no longer active.
***
## Global/Region Specific Quotas
By default, quotas are configured at a global level and apply across all regions and workloads. These limits control the total amount of resources that can be used by the organisation, regardless of where deployments are running.
While the platform supports configuring quotas at a more granular level (such as region-specific or job-specific quotas), this is **not** enabled by default. In certain cases, custom quotas may be assigned for a specific region and/or job based on requirements.
If you want to deploy models in a certain region, please reach out to us at [support@simplismart.ai](mailto:support@simplismart.ai).
***
## Other Quotas
Depending on the platform configuration, additional quotas may apply to:
* Training jobs
* Compilation tasks
* Deployment replicas
* Other compute resources
***
## Managing Low Quota Issues
If a workload cannot start due to quota limits, you may see errors indicating that the **requested resources exceed the available quota**.
To resolve this:
1. Review your current resource usage.
2. Stop unused deployments or workloads.
3. Reduce the requested compute configuration.
4. Request a quota increase if additional capacity is required.
***
## Requesting a Quota Increase
If your organisation requires higher resource limits, you can **request a quota increase**. Quota increases are typically requested when:
* Scaling production deployments.
* Running larger training jobs.
* Expanding workloads across multiple regions.
To request a quota increase, contact the [Simplismart team](mailto:support@simplismart.ai) with details of the **resource type, region, and expected usage requirements**.
# Usage
Source: https://docs.simplismart.ai/model-suite/settings/usage
This page helps you track your usage across all deployments
The Usage Board provides a comprehensive view of your total usage for all your deployments.
## **Review Usage Overview**
* The board displays total usage data for the chosen date range for all your deployments.
***
## **Access Detailed Request Logs**
* You will also be able to see the request count in the same time frame
* For more details, click on a specific model.
* This will then give information regarding each request with the associated timeline.
***
## **Group By: Deployment or GPU**
On the Private Endpoint usage tab, use the **Group By** dropdown to switch how cost is broken down:
* **Deployment** — cost per individual deployment, same as the default view above.
* **GPU** — cost per accelerator/GPU type, pooled across all deployments on that GPU type.
## **Reservation Commitment (Reserved plan orgs)**
For orgs on a reservation/commitment billing plan, the cost chart also breaks out how usage reconciles against the committed capacity:
* **Reserved** — cost covered by (utilized within) the committed capacity.
* **Reserved not util** — committed capacity paid for but not used in that window.
* **On-demand overage** — usage billed above the committed quantity.
The displayed total cost reflects the real, commitment-adjusted amount rather than a plain metered sum.
# Workspaces
Source: https://docs.simplismart.ai/model-suite/settings/workspaces
Scope models and deployments within your organisation using Workspaces
Workspaces let you partition models and deployments within an organisation. Each workspace acts as an isolated scope, models compiled or deployed inside one workspace are not visible to members of another.
Navigate to **Settings → Workspaces** to manage your workspaces.
***
## **Overview**
Every organisation starts with a **Default** workspace. All organisation members are automatically added to it.
You can create additional workspaces to isolate environments. For example, separating production deployments from experimentation, or giving different teams their own scope.
The **Current Workspace** dropdown at the top of the page lets you switch between workspaces. Each workspace displays its name and a unique **Workspace ID**.
***
## **Creating a Workspace**
Only **organisation admins** can create workspaces.
1. Navigate to **Settings → Workspaces**
2. Click the **Create Workspace** button in the top-right corner
3. Enter a name for the new workspace
4. Click **Create** to confirm
The workspace creator is automatically added as a **Workspace Admin**.
***
## **Workspace Roles**
There are two roles within a workspace:
| Role | What they can do |
| -------------------- | ------------------------------------------------------------------------------------------------------ |
| **Workspace Admin** | Add, remove, and update workspace members. Full access to all models and deployments in the workspace. |
| **Workspace Member** | View and use models and deployments scoped to the workspace. Cannot manage membership. |
Organisation admins have implicit access to **all workspaces** in the organisation, regardless of whether they are explicitly added as a workspace member.
***
## **Managing Members**
### Default Workspace
The Default workspace cannot be deleted and its membership is managed entirely by organisation membership, it automatically mirrors your org member list.
You **cannot** add or remove members from the Default workspace in the Workspaces tab. To manage membership, go to **Organisation → Members**.
* When a user is **added to the organisation**, they are automatically added to the Default workspace. Their workspace role reflects their org role: org admins get **Workspace Admin**, other members get **Workspace Member**.
* When a user is **removed from the organisation**, they are removed from the Default workspace **and all other workspaces** in the organisation.
Membership changes in the Default workspace are made through **Organisation → Members**, not the Workspaces tab. Removing a user from the organisation also removes them from every workspace in the organisation.
### Created Workspaces
For workspaces you create, membership is managed independently from the organisation.
Only users who are already members of the organisation can be added to a workspace. Adding a workspace member requires **Workspace Admin** or **Organisation Admin** access.
1. Use the **Current Workspace** dropdown to switch to the target workspace
2. In the **Workspace Members** section, click **Add Member**
3. Search by email or role to find the user
4. Select the role (**Workspace Admin** or **Workspace Member**) and confirm
Each workspace must have at least one **Workspace Admin** at all times. You cannot remove or demote the last workspace admin.
***
## **Permissions and Visibility**
Workspace isolation applies to both reads and writes. You only see models and deployments that belong to workspaces you are a member of, resources in other workspaces are not visible, even within the same organisation.
This applies throughout the platform:
* The **Models** list only shows models in your accessible workspaces
* The **Deployments** list only shows deployments in your accessible workspaces
* **Filter options** (such as created by, deployment tags) are also scoped, values from inaccessible workspaces do not appear in filter dropdowns
Organisation admins can see all workspaces and all resources across the organisation, regardless of workspace membership.
***
## **Moving Resources Between Workspaces**
Models and deployments can be moved from one workspace to another within the same organisation.
Only **Workspace Admins** of the source workspace and **Organisation Admins** can move resources. Workspace Members cannot.
### Moving a Model
1. Open the model you want to move
2. Select **Move to Workspace** from the actions menu
3. Choose the target workspace and confirm
**Constraints:**
* The target workspace must be in the same organisation
* A model cannot be moved to the workspace it already belongs to
### Moving a Deployment
1. Open the deployment you want to move
2. Select **Move to Workspace** from the actions menu
3. Choose the target workspace and confirm
**Constraints:**
* The model used by the deployment must already exist in the target workspace. If it does not, move the model first, then move the deployment.
* The target workspace must be in the same organisation
* A deployment cannot be moved to the workspace it already belongs to
If the underlying model is a shared marketplace model (public and deployable), the workspace match requirement is waived and the deployment can be moved freely.
## **Deleting a Workspace**
Only **organisation admins** can delete workspaces. The Default workspace cannot be deleted.
A workspace can only be deleted when it contains no active models or deployments. If the workspace has active resources, the platform will return an error indicating the count of models and deployments that need to be removed first.
To delete a workspace:
1. Ensure all active models and deployments within the workspace are deleted
2. Navigate to **Settings → Workspaces**
3. Click **Delete** next to the workspace you want to remove
4. Confirm the deletion
***
# Your Organisation
Source: https://docs.simplismart.ai/model-suite/settings/your-organisation
Manage your organisation(s) and team members within this section
## **Inviting Members to Your Organisation**
* In the Organisations tab, you will find an invitation link to invite new members.
* Share the generated link with the members you want to invite.
***
## **Billing Details**
You can add or edit your billing address and billing email by clicking the `Edit` button.
Please ensure all details are accurate, as the billing address will be used for tax and invoice purposes.
Customers with a billing address in India are subject to an **18% GST**, as per applicable tax laws.
***
## **Quota Management**
Each organization is allocated a predefined compute quota to ensure fair resource distribution and efficient job scheduling.
### Default Quotas
By default, every new organization receives:
* **8 × H100 GPUs**
* **8 × L40 GPUs**
**Automatic Quota Release**: Quotas are automatically released once:
* A training or compilation job completes successfully, or
* A job fails and is no longer active
### Requesting Additional Quotas
If your organization requires higher limits for training or compilation workloads, you can request an increase by contacting the support team at [support@simplismart.ai](mailto:support@simplismart.ai).
Requests are reviewed based on usage history, project requirements, and available capacity.
***
## **Organization Management**
* Each user can create up to **2 organizations** per email
* Users can join **unlimited organizations** created by others
### Role-Based Access Control
The platform supports different roles with varying permission levels:
| Role | Permissions |
| ----------------- | ---------------------------------------------------------------------------------- |
| **Billing Users** | View-only access to all sections except for billing details, which they can update |
| **Members** | Full access to all features except user/role management and billing |
| **Admins** | Full administrative access but **cannot delete themselves** |
Users linked to the billing email **cannot be deleted**.
***
## **View Members**
* The screen will also display all members added to your organisation.
# Create an Alert Rule
Source: https://docs.simplismart.ai/observability/alerting/alert-rules
Learn how to set up alert rules to monitor your deployments and get notified when thresholds are breached
An alert rule monitors a deployment metric against a defined condition. When the condition is met for long enough, the rule transitions to `firing` and sends notifications through the attached [contact points](/observability/alerting/contact-points).
You need at least one [contact point](/observability/alerting/contact-points) before creating an alert rule. Set one up first if you haven't already.
## Create an alert rule
In the sidebar, go to **Alerting**. You'll see all alerts across your deployments. Click **Add Alert** to create a new rule.
Provide a **Name** for the alert rule. Optionally add **Tags** (up to 60 characters each) to help categorise and filter rules, and a **Description** for additional context.
In the **Resource Details** section, the **Type** is set to Deployment. Use the **Resource Name** dropdown to search for and select the deployment you want to monitor.
In the **Alert Condition Setup** section:
* **Condition**: Select a monitoring condition (e.g., High 4xx Error Rate). The available conditions are filtered by your deployment's model type.
* **Parameters**: Fill in the condition's parameters such as thresholds, exclusion patterns, and evaluation window. Each field shows its unit, valid range, and a description.
* **Severity**: Choose **Critical** (immediate attention required) or **Warning** (needs monitoring).
* **Contact Point**: Select the [contact points](/observability/alerting/contact-points) to notify when this rule fires. At least one contact point is required to activate the alert; you can add up to 5.
* **Evaluate every**: How often Grafana evaluates the rule (e.g., `5m`).
* **Pending Period**: How long the condition must be continuously true before the alert transitions from `pending` to `firing`. Use this to suppress noise from transient spikes.
Click **Create Alert Rule**. The rule is provisioned in Grafana and begins evaluating on the next interval.
## Alert Details Page
Click any alert rule in the list to open its detail page. The page shows:
* **General Details**: Severity, deployment, alert condition, threshold, and current value
* **Contact Points**: The notification channels attached to this rule.
* **Meta Details**: Creator, name, and description
* **Alert State** panel: Current state, last evaluation time, evaluation interval, and pending period
## Alert states
| State | Description |
| --------- | --------------------------------------------------------------------------------------- |
| `normal` | The condition is not met; the deployment is within expected bounds. |
| `pending` | The condition is met but the pending period has not elapsed yet. |
| `firing` | The condition has been sustained past the pending period; notifications are being sent. |
| `nodata` | No metric data is being received from the deployment. |
| `error` | The rule evaluation failed due to a query or configuration problem. |
## Mute an alert rule
Muting suppresses notifications for a rule without deleting it. A muted rule continues to evaluate and its state is still visible in the UI, but no notifications are sent.
To mute a rule, open the alert rule detail page and click **Mute**. To resume notifications, click **Unmute**.
## Edit an alert rule
Open the rule, make changes, and save. A confirmation modal shows the full diff of your changes before they are applied.
The following fields can be updated after creation: description, parameters, severity, evaluation interval, pending period, contact points, tags, and enabled state.
The **condition** and **deployment** of an existing rule cannot be changed. To monitor a different metric or deployment, create a new rule.
## Delete an alert rule
Open the rule, click the **⋮** menu, and select **Delete**. This removes the rule from Simplismart.
# Create a Contact Point
Source: https://docs.simplismart.ai/observability/alerting/contact-points
Configure notification channels for your Simplismart deployment alerts
A contact point is a named, reusable notification destination. Each contact point can contain one or more **integrations**, individual channel configurations such as an email address, a Slack webhook, a Microsoft Teams connector, a PagerDuty integration, or a VictorOps endpoint. When an alert fires, notifications are sent through every integration attached to the linked contact point.
## Create a contact point
In the sidebar, go to **Alerting** and click the **Contact Point** tab. You'll see all existing contact points for your organisation. Click **Add a Contact Point**.
Provide a unique **Name** for the contact point and an optional **Description** for additional context.
Click **Add Integration** and select a channel type (Email, Slack, Teams, PagerDuty, or VictorOps). Fill in the required fields and click **Save**. See the **[Supported channel types](/observability/alerting/contact-points#supported-channel-types)** section below for detailed setup instructions per channel.
You can add multiple integrations to a single contact point, all of them will be notified when an alert fires.
Click **Create Contact Point**.
## Supported channel types
Send notifications to one or more email addresses
Post notifications to a Slack channel via incoming webhook
Post notifications to a Teams channel via incoming webhook
Create PagerDuty incidents when alerts fire
Send alert notifications to VictorOps (Splunk On-Call) via REST endpoint
## Edit a contact point
Open the contact point and click **Edit** in the top-right corner. Update the fields you want to change and save.
Sensitive fields such as webhook URLs and API keys are masked after saving. Leave them blank when editing to keep the existing value; fill them in only if you want to replace them.
## Delete a contact point
Open the contact point, click the **⋮** menu in the top-right corner, and select **Delete**.
Before deleting, check the **Alert Rules connected** panel on the right side of the detail page, it lists every alert rule currently using this contact point. A contact point cannot be deleted while it is linked to alert rules. Remove or reassign those rules first, then delete.
# Email
Source: https://docs.simplismart.ai/observability/alerting/contact-points/email
Send alert notifications to one or more email addresses
The Email integration sends notifications to one or more recipients when an alert fires or resolves.
## Configuration
| Field | Required | Description |
| --------------- | -------- | ----------------------------------------------------------------------------------------------------- |
| **Label** | Yes | A display name for this integration, visible in the integrations table |
| **Subject** | Yes | Email subject line (e.g., `4xx Error Alert`) |
| **Addresses** | No | Recipient email addresses, separated by semicolons (`;`) |
| **Single Mail** | No | Send a single email to all recipients instead of individual emails (under **Optional Mail settings**) |
## Add to a contact point
Go to **Alerting** → **Contact Points** and open an existing contact point or create a new one.
Click **Add Integration** and select **Mail** from the **Integration** dropdown.
Enter a **Label** for this integration, a **Subject** for the email, and the recipient **Addresses** separated by semicolons.
To send a single email to all recipients instead of individual emails, expand **Optional Mail settings** and check **Single Mail**.
Review the configurations and click **Save**.
# PagerDuty
Source: https://docs.simplismart.ai/observability/alerting/contact-points/pagerduty
Create PagerDuty incidents when Simplismart alerts fire
The PagerDuty integration creates incidents in PagerDuty using the Events API v2 when an alert fires, and resolves them automatically when the alert clears.
## Configuration
| Field | Required | Description |
| ------------------- | -------- | ------------------------------------------------------------------------------------- |
| **Label** | Yes | A display name for this integration, visible in the integrations table |
| **Integration Key** | Yes | PagerDuty Events API v2 integration key |
| **Severity** | No | Incident severity: `critical`, `error`, `warning`, or `info` (defaults to `critical`) |
| **Component** | No | Logical component that is the source of the alert (e.g., `model-deployment`) |
| **Group** | No | Logical grouping of components (e.g., `production`) |
| **Class** | No | Type of event (e.g., `latency`, `errors`, `gpu-utilization`) |
## Obtain an integration key
In PagerDuty, go to **Services** and select the service you want to receive alerts for, or create a new one.
Click the **Integrations** tab → **Add an integration**.
Search for **Events API v2** and click **Add**.
Copy the **Integration Key** shown on the integrations list.
## Add to a contact point
Go to **Alerting** → **Contact Points** and open an existing contact point or create a new one.
Click **Add Integration** and select **PagerDuty** from the **Integration** dropdown.
Enter a **Label** and paste the **Integration Key**. Optionally set the **Severity**, **Component**, **Group**, and **Class** to provide context for the PagerDuty incident.
Review the configurations and click **Save**.
# Slack
Source: https://docs.simplismart.ai/observability/alerting/contact-points/slack
Post alert notifications to a Slack channel via incoming webhook
The Slack integration posts notifications to a channel using a Slack incoming webhook URL.
## Configuration
| Field | Required | Description |
| --------------- | -------- | ---------------------------------------------------------------------- |
| **Label** | Yes | A display name for this integration, visible in the integrations table |
| **Webhook URL** | Yes | Incoming webhook URL from your Slack app configuration |
## Obtain a webhook URL
Go to [api.slack.com/apps](https://api.slack.com/apps) and select your app (or create a new one).
In the left sidebar, click **Incoming Webhooks** and toggle the feature on.
Click **Add New Webhook to Workspace**, select the target channel, and click **Allow**.
Copy the generated webhook URL. It will look like `https://hooks.slack.com/services/...`.
## Add to a contact point
Go to **Alerting** → **Contact Points** and open an existing contact point or create a new one.
Click **Add Integration** and select **Slack** from the **Integration** dropdown.
Enter a **Label** for this integration and paste the **Webhook URL** you copied from Slack.
Review the configurations and click **Save**.
# Microsoft Teams
Source: https://docs.simplismart.ai/observability/alerting/contact-points/teams
Post alert notifications to a Microsoft Teams channel via incoming webhook
The Microsoft Teams integration posts notifications to a channel using a Teams incoming webhook connector.
## Configuration
| Field | Required | Description |
| --------------- | -------- | ---------------------------------------------------------------------- |
| **Label** | Yes | A display name for this integration, visible in the integrations table |
| **Webhook URL** | Yes | Incoming webhook URL from your Teams channel connector |
## Obtain a webhook URL
In Microsoft Teams, navigate to the channel you want to receive alerts.
Click **...** next to the channel name → **Connectors**. Search for **Incoming Webhook** and click **Configure**.
Give the webhook a name (e.g., "Simplismart Alerts") and click **Create**.
Copy the generated webhook URL and click **Done**.
## Add to a contact point
Go to **Alerting** → **Contact Points** and open an existing contact point or create a new one.
Click **Add Integration** and select **Microsoft Teams** from the **Integration** dropdown.
Enter a **Label** for this integration and paste the **Webhook URL** you copied from Teams.
Review the configurations and click **Save**.
# VictorOps
Source: https://docs.simplismart.ai/observability/alerting/contact-points/victorops
Send alert notifications to VictorOps (Splunk On-Call) via REST endpoint
The VictorOps integration sends alert notifications to VictorOps (now Splunk On-Call) using a REST endpoint URL when an alert fires or resolves.
## Configuration
| Field | Required | Description |
| ---------------- | -------- | ---------------------------------------------------------------------- |
| **Label** | Yes | A display name for this integration, visible in the integrations table |
| **URL** | Yes | VictorOps REST endpoint URL |
| **Message Type** | No | Severity of the incident: `CRITICAL`, `WARNING`, or `INFO` |
## Obtain a REST endpoint URL
Log in to [portal.victorops.com](https://portal.victorops.com/) and go to **Integrations**.
Find and select **REST** from the integrations list.
Click **Generate** to create a new REST endpoint URL and copy it.
## Add to a contact point
Go to **Alerting** → **Contact Points** and open an existing contact point or create a new one.
Click **Add Integration** and select **VictorOps** from the **Integration** dropdown.
Enter a **Label** for this integration, paste the **URL** you copied from VictorOps, and optionally set the **Message Type**.
Review the configuration and click **Save**.
# Alerting Overview
Source: https://docs.simplismart.ai/observability/alerting/overview
Monitor your deployments and get notified when performance thresholds are breached
Simplismart Alerting lets you define conditions on your deployment metrics and route notifications to your team when those conditions are met. It is powered by Grafana alerting under the hood, with a managed setup so you don't need to configure Grafana directly.
There are two building blocks:
Define what triggers a notification: choose a preset condition, set thresholds, attach a deployment, and link to one or more contact points.
Define where notifications are sent: email, Slack, Microsoft Teams, PagerDuty, or VictorOps. Each contact point can hold multiple integrations.
# Datadog
Source: https://docs.simplismart.ai/observability/export-metrics/datadog
Export Simplismart metrics to Datadog
Datadog is a monitoring and security platform for cloud applications. You can forward Simplismart metrics to Datadog using the OpenTelemetry Collector.
## Prerequisites
* A Datadog account with API access
* Datadog API key
* OpenTelemetry Collector installed
* [Simplismart API Key](/model-suite/settings/api-keys)
## OpenTelemetry Collector configuration
```yaml theme={null}
receivers:
prometheus:
config:
scrape_configs:
- job_name: "simpli-metrics"
scrape_interval: 60s
scheme: https
metrics_path: /observability/metrics/federate/
authorization:
type: Bearer
credentials: "${SIMPLISMART_API_KEY}"
params:
namespace: ["DEPLOYMENT_SLUG_HERE"] # your deployment slug
bundle: ["core"]
source: ["deployment"]
static_configs:
- targets: ["api.app.simplismart.ai"]
processors:
batch:
exporters:
datadog:
api:
key: "${DATADOG_API_KEY}"
service:
pipelines:
metrics:
receivers: [prometheus]
processors: [batch]
exporters: [datadog]
```
## Configuration parameters
### namespace
The namespace parameter accepts a comma-separated list of deployment slugs. You can specify up to 10 deployment slugs. To increase this limit, reach out to support at [support@simplismart.tech](mailto:support@simplismart.tech).
**Example:** `["slug-1", "slug-2", "slug-3"]`
### scrape\_interval
The recommended scrape interval is 60 seconds.
It is advised not to reduce the interval below 30 seconds, as shorter intervals may not provide meaningful additional visibility and can lead to unnecessary overhead.
## Test locally
To test this configuration locally, first save the above YAML as `otelcol.yaml`, then set your API keys as environment variables:
```bash theme={null}
export SIMPLISMART_API_KEY="your-simplismart-api-key"
export DATADOG_API_KEY="your-datadog-api-key"
```
Next, execute the following command to start the collector:
```bash theme={null}
docker run --rm \
-e SIMPLISMART_API_KEY \
-e DATADOG_API_KEY \
-v "$PWD/otelcol.yaml:/etc/otelcol/config.yaml:ro" \
otel/opentelemetry-collector-contrib:latest \
--config=/etc/otelcol/config.yaml
```
This will start the OpenTelemetry Collector in a Docker container using your local configuration file.
# New Relic
Source: https://docs.simplismart.ai/observability/export-metrics/new-relic
Export Simplismart metrics to New Relic
New Relic is an observability platform that helps you monitor, debug, and improve your entire stack. You can send Simplismart metrics to New Relic using the OpenTelemetry Collector.
## Prerequisites
* New Relic API key
* OpenTelemetry Collector installed
* [Simplismart API Key](/model-suite/settings/api-keys)
## OpenTelemetry Collector configuration
```yaml theme={null}
receivers:
prometheus:
config:
scrape_configs:
- job_name: "simpli-metrics"
scrape_interval: 60s
scheme: https
metrics_path: /observability/metrics/federate/
authorization:
type: Bearer
credentials: "${SIMPLISMART_API_KEY}"
params:
namespace: ["DEPLOYMENT_SLUG_HERE"] # your deployment slugs
bundle: ["core"]
source: ["deployment"]
static_configs:
- targets: ["api.app.simplismart.ai"]
processors:
batch:
exporters:
otlphttp/newrelic:
endpoint: "https://otlp.nr-data.net"
headers:
api-key: "${NEW_RELIC_API_KEY}"
service:
pipelines:
metrics:
receivers: [prometheus]
processors: [batch]
exporters: [otlphttp/newrelic]
```
## Configuration parameters
### namespace
The namespace parameter accepts a comma-separated list of deployment slugs. You can specify up to 10 deployment slugs. To increase this limit, reach out to support at [support@simplismart.tech](mailto:support@simplismart.tech).
**Example:** `["slug-1", "slug-2", "slug-3"]`
### scrape\_interval
The recommended scrape interval is 60 seconds.
It is advised not to reduce the interval below 30 seconds, as shorter intervals may not provide meaningful additional visibility and can lead to unnecessary overhead.
## Test locally
To test this configuration locally, first save the above YAML as `otelcol.yaml`, then set your API keys as environment variables:
```bash theme={null}
export SIMPLISMART_API_KEY="your-simplismart-api-key"
export NEW_RELIC_API_KEY="your-new-relic-api-key"
```
Next, execute the following command to start the collector:
```bash theme={null}
docker run --rm \
-e SIMPLISMART_API_KEY \
-e NEW_RELIC_API_KEY \
-v "$PWD/otelcol-newrelic.yaml:/etc/otelcol/config.yaml:ro" \
otel/opentelemetry-collector-contrib:latest \
--config=/etc/otelcol/config.yaml
```
This will start the OpenTelemetry Collector in a Docker container using your local configuration file.
# Overview
Source: https://docs.simplismart.ai/observability/export-metrics/overview
Integrate Simplismart metrics with your monitoring and observability tools
Simplismart exposes deployment metrics in Prometheus format, ready for integration with any observability platform. Monitor GPU utilization, Kubernetes health, and HTTP request metrics, all from a single endpoint.
## Quick Start
Below given is the scrape endpoint:
```
https://api.app.simplismart.ai/observability/metrics/federate/
```
The Federate API is rate limited to 5 requests per minute.
Use [Simplismart API KEY](/model-suite/settings/api-keys) for authentication.
```yaml theme={null}
authorization:
type: Bearer
credentials: "${SIMPLISMART_API_KEY}"
```
The recommended scrape interval is 60 seconds.
It is advised not to reduce the interval below 30 seconds, as shorter intervals may not provide meaningful additional visibility and can lead to unnecessary overhead.
## Supported integrations
Send metrics to your preferred observability platform using [OpenTelemetry Collector](https://opentelemetry.io/docs/collector/):
Scrape and query metrics using Prometheus
Forward metrics to Datadog for monitoring
Send metrics to New Relic for observability
For detailed metric descriptions, see the [supported metrics reference](/observability/export-metrics/supported-metrics).
# Prometheus
Source: https://docs.simplismart.ai/observability/export-metrics/prometheus
Export Simplismart metrics to Prometheus
Prometheus is an open-source systems monitoring and alerting toolkit. You can send Simplismart metrics to Prometheus using the OpenTelemetry Collector with the Prometheus remote write exporter.
## Prerequisites
* Prometheus instance with remote write endpoint (or Grafana Cloud)
* OpenTelemetry Collector installed
* [Simplismart API Key](/model-suite/settings/api-keys)
## OpenTelemetry Collector configuration
```yaml theme={null}
receivers:
prometheus:
config:
scrape_configs:
- job_name: "model-suite"
scrape_interval: 60s
scheme: https
metrics_path: /observability/metrics/federate/
authorization:
type: Bearer
credentials: "${MODEL_SUITE_METRICS_TOKEN}"
params:
namespace: ["NAMESPACES_HERE"]
bundle: ["core"]
source: ["deployment"]
static_configs:
- targets: ["api.app.simplismart.ai"]
processors:
batch:
exporters:
prometheusremotewrite:
endpoint: "${PROMETHEUS_REMOTE_WRITE_URL}"
# If your Prometheus requires auth (e.g. Grafana Cloud):
auth:
authenticator: basicauth
extensions:
basicauth:
client_auth:
username: "${PROMETHEUS_USERNAME}"
password: "${PROMETHEUS_PASSWORD}"
service:
extensions: [basicauth]
pipelines:
metrics:
receivers: [prometheus]
processors: [batch]
exporters: [prometheusremotewrite]
```
## Configuration parameters
### namespace
The namespace parameter accepts a comma-separated list of deployment slugs. You can specify up to 10 deployment slugs. To increase this limit, reach out to support at [support@simplismart.tech](mailto:support@simplismart.tech).
**Example:** `["slug-1", "slug-2", "slug-3"]`
### scrape\_interval
The recommended scrape interval is 60 seconds.
It is advised not to reduce the interval below 30 seconds, as shorter intervals may not provide meaningful additional visibility and can lead to unnecessary overhead.
## Test locally
To test this setup locally, first export your environment variables:
```bash theme={null}
export MODEL_SUITE_METRICS_TOKEN='PASTE_JWT_HERE'
export PROMETHEUS_REMOTE_WRITE_URL='PASTE_PROMETHEUS_REMOTE_URL_HERE'
export PROMETHEUS_USERNAME='PASTE_PROMETHEUS_REMOTE_WRITE_USERNAME'
export PROMETHEUS_PASSWORD='PASTE_PROMETHEUS_REMOTE_WRITE_PASSWORD'
```
Then save the configuration above as `otelcol.yaml` and run:
```bash theme={null}
docker run --rm \
-e MODEL_SUITE_METRICS_TOKEN \
-e PROMETHEUS_REMOTE_WRITE_URL \
-e PROMETHEUS_USERNAME \
-e PROMETHEUS_PASSWORD \
-v "$PWD/otelcol.yaml:/tmp/config.yaml:ro" \
otel/opentelemetry-collector-contrib:latest \
--config=/tmp/config.yaml
```
This will start the OpenTelemetry Collector in a Docker container using your local configuration file.
# Supported Metrics
Source: https://docs.simplismart.ai/observability/export-metrics/supported-metrics
Reference for all metrics available from the Simplismart metrics endpoint
# Supported Metrics
The Simplismart metrics endpoint exposes metrics in Prometheus format covering Kubernetes infrastructure health, GPU utilization, inference engine performance, and request lifecycle.
For each metric, you only need to provide one of the listed parameters.
Deployment namespace and deployment slug refer to the same value. Learn how to find it [here](/images/observability/overview/1-find-slug.png).
## Kubernetes Deployment Metrics
Track deployment health and replica status.
### `kube_deployment_spec_replicas`
The number of desired replicas for a deployment, as specified in the deployment spec.
Type: `gauge`
Labels:
Deployment namespace (deployment slug).
Deployment name.
***
### `kube_deployment_status_replicas`
The number of observed replicas for a deployment.
Type: `gauge`
Labels:
Deployment namespace.
Deployment name.
***
### `kube_deployment_status_replicas_available`
Number of replicas that are available (ready for at least minReadySeconds).
Type: `gauge`
Labels:
Deployment namespace.
Deployment name.
***
### `kube_deployment_status_replicas_ready`
Number of replicas that have passed their readiness probes.
Type: `gauge`
Labels:
Deployment namespace.
Deployment name.
For inference servers, readiness means "model is loaded and accepting requests." A container running but not ready consumes resources without serving traffic.
***
### `kube_deployment_status_replicas_unavailable`
Number of replicas that are not yet available.
Type: `gauge`
Labels:
Deployment namespace.
Deployment name.
A non-zero value means capacity is degraded: pods may be crashing, stuck in image pull, or failing health checks.
***
## Kubernetes Pod Metrics
Pod-level visibility into lifecycle and health.
### `kube_pod_info`
Pod metadata information including node, IP, and phase.
Type: `gauge`
Labels:
Pod namespace.
Pod name.
Node name where the pod is scheduled.
Pod IP address.
***
### `kube_pod_status_phase`
Current phase of the pod (Pending, Running, Succeeded, Failed, Unknown).
Type: `gauge`
Labels:
Pod namespace.
Pod name.
Pod phase (Pending, Running, Succeeded, Failed, Unknown).
***
### `kube_pod_container_status_ready`
Whether the container is ready (1) or not (0).
Type: `gauge`
Labels:
Pod namespace.
Pod name.
Container name.
***
### `kube_pod_container_status_running`
Whether the container is running (1) or not (0).
Type: `gauge`
Labels:
Pod namespace.
Pod name.
Container name.
***
### `kube_pod_container_status_restarts_total`
Cumulative count of container restarts.
Type: `counter`
Labels:
Pod namespace.
Pod name.
Container name.
Frequent restarts indicate OOM kills, crash loops, or probe failures. For GPU inference pods, restarts are expensive because model loading can take minutes.
***
### `kube_pod_container_status_waiting_reason`
The reason the container is in waiting state (e.g., ContainerCreating, CrashLoopBackOff, ErrImagePull).
Type: `gauge`
Labels:
Pod namespace.
Pod name.
Container name.
Reason for waiting state.
***
## Container Resource Metrics
Track actual resource consumption.
### `container_cpu_usage_seconds_total`
Cumulative CPU time consumed by the container, in core-seconds.
Type: `counter`
Labels:
Pod namespace.
Pod name.
Container name.
***
### `container_memory_working_set_bytes`
Current working set memory of the container in bytes. This is what the OOM killer uses for eviction decisions.
Type: `gauge`
Labels:
Pod namespace.
Pod name.
Container name.
When this approaches the container's memory limit, OOM kills become imminent.
***
### `kube_pod_container_resource_requests`
Resource requests configured for the container.
Type: `gauge`
Labels:
Pod namespace.
Pod name.
Container name.
Resource type (cpu, memory, nvidia\_com\_gpu).
Unit of measurement (core, byte, etc.).
***
### `kube_pod_container_resource_limits`
Resource limits configured for the container.
Type: `gauge`
Labels:
Pod namespace.
Pod name.
Container name.
Resource type (cpu, memory, nvidia\_com\_gpu).
Unit of measurement (core, byte, etc.).
***
## GPU Metrics
GPU metrics for Simplismart's GPU-accelerated inference workloads.
### `DCGM_FI_DEV_GPU_UTIL`
GPU utilization as a percentage (0–100). Measures what fraction of time the GPU's streaming multiprocessors are active.
Type: `gauge`
Labels:
GPU index.
GPU UUID.
Device identifier.
GPU model name (e.g., "NVIDIA H100").
Host name.
Deployment namespace.
Pod name.
**Example:**
```promql theme={null}
DCGM_FI_DEV_GPU_UTIL{Hostname="simplismart-dell-001",exported_namespace="your-namespace",pod="nvidia-dcgm-exporter-xyz"}
```
Low utilization means inefficient batching; high sustained utilization (>90%) indicates the GPU is at capacity.
***
### `DCGM_FI_DEV_FB_USED`
Frame buffer (GPU VRAM) memory used, in MiB.
Type: `gauge`
Labels:
GPU index.
Host name.
Deployment namespace.
Pod name.
**Example:**
```promql theme={null}
DCGM_FI_DEV_FB_USED{Hostname="simplismart-dell-001",exported_namespace="your-namespace",pod="nvidia-dcgm-exporter-xyz"}
```
GPU memory is the primary constraint for model serving. When VRAM is exhausted, inference requests fail with OOM errors.
***
### `DCGM_FI_DEV_FB_FREE`
Frame buffer (GPU VRAM) memory free, in MiB.
Type: `gauge`
Labels:
Host name.
Deployment namespace.
Pod name.
**Example:**
```promql theme={null}
DCGM_FI_DEV_FB_FREE{Hostname="simplismart-dell-001",exported_namespace="your-namespace",pod="nvidia-dcgm-exporter-xyz"}
```
***
## Ingress Metrics
External traffic entering the Simplismart platform.
### `nginx_ingress_controller_requests`
Total number of requests handled by the NGINX ingress controller.
Type: `counter`
Labels:
Ingress name.
Namespace.
Service name.
HTTP status code.
HTTP method (GET, POST, etc.).
Request path.
**Available metrics:**
* `nginx_ingress_controller_requests` - Total request count
* `nginx_ingress_controller_request_duration_seconds_bucket` - Request duration histogram buckets
* `nginx_ingress_controller_request_duration_seconds_sum` - Total request duration sum
* `nginx_ingress_controller_request_duration_seconds_count` - Total request count for duration
***
### `nginx_ingress_controller_request_duration_seconds`
End-to-end request duration as observed by the ingress controller.
Type: `histogram` (exposes `_bucket`, `_sum`, and `_count` time series)
Labels:
Ingress name.
Namespace.
Service name.
HTTP status code.
HTTP method (GET, POST, etc.).
Request path.
**Example query (p99):**
```promql theme={null}
histogram_quantile(0.99, rate(nginx_ingress_controller_request_duration_seconds_bucket[5m]))
```
***
# Introduction
Source: https://docs.simplismart.ai/overview
Simplismart is an MLOps platform for deploying, serving, and optimizing AI models with superior performance, scalability, and cost-efficiency.
Our custom inference engine intelligently adapts to your specific requirements, whether you need lower latency, higher throughput, or cost savings; allowing you to focus on building exceptional AI product experiences without the burden of managing complex infrastructure.
## How Simplismart Works
Simplismart provides an end-to-end solution for AI model deployment and optimization through a comprehensive suite of services:
### Deploy Models Your Way
**Get started immediately** with 150+ pre-deployed models in our marketplace. Access popular open-source models like Llama, Mistral, and more with simple pay-as-you-go pricing.
**Deploy custom models** (open-source or proprietary) on your private cloud or Simplismart infrastructure with full control over resources, scaling, and configuration.
### Customize and Evalute
**Train models on your data** with blazing-fast speed. Deploy fine-tuned models immediately for inference with the similar performance as base models.
**Evaluate model performance** across qualitative and quantitative metrics. Compare latency, throughput, and accuracy across different configurations to optimize deployments.
## Quick Start Guides
Choose from these common workflows to get started with Simplismart quickly:
Call deployed models via API for real-time predictions
Deploy and scale your own models on dedicated infrastructure
## What You Can Build
Power chatbots, assistants, and interactive experiences with sub-500ms latency
Fine-tune models on your domain-specific data for significantly improved accuracy
Scale large language models securely on your infrastructure or ours
Deploy and monitor models with built-in observability and autoscaling
## Next Steps
[Create an account](/signup) and get your API key to start building
Review our [API Reference](/api-reference/introduction) for detailed integration guides
Follow the [Fine-Tuning guide](/training-suite/introduction) to customize models for your use case
# Deploy Your First Model
Source: https://docs.simplismart.ai/quickstart/deploy
Step-by-step guide to deploying an AI model on Simplismart
This guide walks you through deploying your first AI model on Simplismart. We'll use Gemma 4 31B Instruct as an example, which is a latest open-weight large language model from Google.
## Prerequisites
* A Simplismart account ([Sign up here](/signup) if you haven't already)
* A Simplismart API key ([Generate one here](/model-suite/settings/api-keys) if needed)
## Deployment Process
1. Navigate to the **[Marketplace](https://app.simplismart.ai/model-marketplace)** section in the left sidebar
2. Search for `Gemma 4 31B` in the search bar
3. Click on the **[Gemma 4 31B Instruct](https://app.simplismart.ai/model-marketplace/2efc00b2-4a9a-49a9-ba94-d852e0e7637c)** model card to view its details
4. On the model detail page, click **Deploy Model** to begin the deployment process
In the **[Create Deployment](https://app.simplismart.ai/deployments/create)** screen, fill in the following:
### Deployment Details
* **Deployment Name**: A unique name (e.g. `gemma-4-31b`)
* **Permalink Identifier**: A custom identifier used to create your model endpoint URL. This value will be added as a prefix to your endpoint URL.
* **Model**: Confirm "Gemma 4 31B Instruct" is selected
* **Cloud**: Select **Simplismart Cloud** for managed hosting. Choose **Bring Your Own Cloud** to deploy on your own [cluster](/model-suite/integrations/cloud-account).
* **Accelerator Type**: Select **H100** (or another available GPU based on your quota)
### Scaling Parameters
Set **Minimum Pods** to `1` and **Maximum Pods** to `1`. The GPU scaling capacity is shown below the inputs so you can verify resource availability before deploying.
For production workloads, see [Scaling Parameters](/model-suite/deployments/creating-a-deployment#scaling-parameters) and [Autoscaling Policy](/model-suite/deployments/creating-a-deployment#autoscaling-policy) for stabilization windows and rate-limited scaling.
Tags help filter and organize deployments. Add at least one:
* Key: `env`
* Value: `quickstart`
Click **Add Deployment** in the top-right corner. A **Deploy Model Confirmation** modal appears summarising your configuration:
Review the details, then click **Confirm** to start the deployment.
After confirming, you are taken to the deployment detail page. The **Health Check** panel on the right shows **Progressing** while pods come up and the model loads. Once the model is ready, the status changes to **Healthy**.
The **Details** tab shows the Deployment ID, processing type (SYNC), model endpoint, and scaling configuration. Use the **Logs** and **Events** tabs to follow startup activity.
For the full deployment state machine and monitoring guidance, see [Monitoring and Access](/model-suite/deployments/creating-a-deployment#monitoring-and-access).
Once the deployment status shows **Healthy**, open the **API** tab in the deployment detail page to test it:
1. The **cURL** snippet is pre-filled with your endpoint URL.
2. Set the `Authorization` header to `Bearer `.
3. Copy and run the snippet.
```bash theme={null}
curl -X POST 'YOUR-ENDPOINT-HERE/chat/completions' \
--header 'Authorization: Bearer YOUR_API_KEY' \
--header 'Content-Type: application/json' \
--data '{
"model": "gemma4",
"messages": [
{
"role": "user",
"content": "What is 2+2?"
}
],
"max_tokens": 1024,
"stream": false
}'
```
Replace `YOUR-ENDPOINT-HERE` and `YOUR_API_KEY` with your actual values before running the command.
To free up GPU resources and avoid unnecessary charges, delete the deployment when you are done.
1. Open the **Deployments** tab.
2. Select your deployment.
3. Click the kebab menu (`⋮`) in the top-right of the deployment card and select **Delete**. See [Managing Your Deployment](/model-suite/deployments/creating-a-deployment#managing-your-deployment) for the full action set (Pause, Edit, Clone, Delete).
## Understanding Your Deployment
Your deployed model exposes an OpenAI-compatible endpoint, so you can use it with any client library that supports the OpenAI API format. The endpoint supports:
* Text inputs and completions
* Streaming and non-streaming responses
* Standard OpenAI API parameters like `temperature` and `max_tokens`
## Monitoring and Management
After deployment, you can:
Track usage deployment health, request metrics, latency metrics, LLM metrics, and Pod resouce details in the **Monitor** tab
Scale your deployment up or down based on actual usage patterns
Access detailed logs and events to troubleshoot any issues
Create and revoke API keys for secure access
## Next Steps
Now that you've successfully deployed your first model, consider these next steps:
Learn techniques to improve latency, throughput, and cost-efficiency using Simplismart Copilot.
# Inference
Source: https://docs.simplismart.ai/quickstart/inference
This guide will walk you through making your first API call to Simplismart's pre-deployed models. Before starting, ensure you have [signed up](/signup) for a Simplismart account.
## Prerequisites
* A Simplismart account
* Basic Python knowledge
* Python 3.8+ installed on your system
## Step-by-Step Guide
1. Log in to your [Simplismart account](https://app.simplismart.a)
2. From the left sidebar, click on **Playground**
3. In the model dropdown, select [Gemma 4 31B Instruct](https://app.simplismart.ai/playground?model_id=2efc00b2-4a9a-49a9-ba94-d852e0e7637c). (For example purposes, Gemma 4 31B is considered here. Any other LLM can be used as well.)
4. You'll see an interactive chat interface where you can test the model directly
1. In the Playground, click on **Get API details** in the left sidebar
2. You'll be redirected to a page with ready-to-use code snippets
3. Note that both Python (OpenAI client) and cURL examples are provided
4. Copy the provided code snippet or use the given below
The API is compatible with any OpenAI-compliant client library, not just the official Python SDK.
Create a new file named `inference.py` with the following code:
```python theme={null}
# inference.py
from openai import OpenAI
# Replace with your actual API key from Settings > API Keys
simplismart_api_key = "SIMPLISMART_API_KEY"
# Replace with your endpoint for the Gemma-3-1B model from the Model details page
simplismart_base_url = "https://api.simplismart.live"
try:
# Initialize the OpenAI client with Simplismart endpoint
client = OpenAI(
api_key=simplismart_api_key,
base_url=simplismart_base_url,
)
# Define model and prompt
MODEL_NAME = "google/gemma-4-31B-it"
PROMPT = "What is quantization in GenAI models?"
print(f"User: {PROMPT}\n")
print("AI Assistant: ", end="", flush=True)
# Create a streaming completion request
stream = client.chat.completions.create(
model=MODEL_NAME,
messages=[
{
"role": "system",
"content": "You are a helpful AI assistant."
},
{
"role": "user",
"content": PROMPT
}
],
max_tokens=512, # Response length limit
stream=True, # Enable streaming for faster first token
)
# Process the streamed response
for chunk in stream:
text_delta = chunk.choices[0].delta.content
if text_delta:
print(text_delta, end="", flush=True)
print() # Add newline after response
except Exception as e:
print(f"An unexpected error occurred: {e}")
```
Remember to replace `"YOUR_API_KEY"` and `YOUR_MODEL_ENDPOINT` with the actual API key and model endpoint you generated in the previous steps.
1. Navigate to **Settings > API Keys** from the main sidebar
2. Click **Generate New Key**
3. Provide a descriptive name for your key (must be unique)
4. Set an appropriate expiration date
5. Copy the generated API key (you won't be able to see it again)
Keep your API key secure and never expose it in client-side code or public repositories.
1. Install the OpenAI Python client if you haven't already:
```shell theme={null}
pip install openai
```
2. Run your script:
```shell theme={null}
python inference.py
```
3. You should see the model's response to your query streaming in your terminal!
Congratulations! 🎉 You've successfully made your first API call to a Simplismart model.
## Understanding Shared vs. Dedicated Endpoints
In this quickstart, you used a **shared endpoint** - a pre-deployed model that's available to all Simplismart users. While convenient for testing and development, shared endpoints have some limitations:
* Quick to get started and no deployment required
* Easy switching between different models
* Pay-as-you-go pricing
* Limited customization options
* Private to your organisation and optimised for your needs
* Option to choose from a wide range of customisation
* Deploy and scale your proprietary model hassle-free
* Better control over latency, throughput, and costs
## Next Steps
Ready to take your AI implementation further? Try these next steps:
* [Deploy your own dedicated model](/quickstart/deploy) for better performance and customization
- [Explore the API reference](/api-reference/introduction) for advanced integration options
# Terminology Guide
Source: https://docs.simplismart.ai/reference/terminology-guide
**Marketplace**: A section where you can browse, discover, and acquire various GenAI models and related resources for your needs
**Playground**: An interactive area where you can experiment with and test GenAI models directly, providing inputs and observing outputs to evaluate performance
**Models**: The section where you manage and view the GenAI models you have created or imported, including details about their configurations and statuses
**Clusters**: The area where you manage and monitor compute resources that support your GenAI models, including creating, configuring, and overseeing clusters used for model training and deployment
**Deployments**: The section where you oversee the deployment process of your GenAI models, including creating new deployments, monitoring their statuses, and managing their configurations
**Integrations**: The area where you manage connections with external services, including cloud accounts, hosted zones, and secrets necessary for the operation and security of your GenAI models
**Settings**: The section where you configure and manage your profile, organization details, billing information, usage metrics, and API keys
***
## Cluster Creation Statuses
**Accepted:** Cluster creation request has been received and is in the queue for processing.
**Cluster Created:** Cluster has been successfully created.
**Cluster Configuration Updated:** Configuration settings of the cluster have been updated according to the specified requirements.
**Attached to Hosted Zone:** Cluster has been linked to the appropriate hosted zone for network and DNS management.
**Reachability Verified:** Cluster’s accessibility has been tested and confirmed to ensure it can be reached as expected.
**Tooling Deployed:** Necessary tools and software have been deployed to the cluster for operation and management.
**Cluster Ready:** Cluster has completed all setup processes and is fully operational for use.
**Cluster Creation Failed:** Cluster creation process encountered an issue and was unable to complete successfully.
***
## Deployment Statuses
**Queued:** The deployment request has been received and is waiting in line to be processed.
**Accepted:** The deployment request has been reviewed and accepted for execution.
**Model Deployed:** Model has been successfully deployed to the specified environment.
**Health Check Passed:** Model has undergone a health check, and all critical tests have been passed, indicating it is functioning correctly.
**Model Ready:** Model is fully deployed, operational, and available for use or integration.
# Analytics Commands
Source: https://docs.simplismart.ai/sdk/cli/analytics
CLI commands for monitoring usage and cost on the Simplismart platform
Fetch time-series usage and cost data from the command line using `simplismart usage`.
## Cost & Usage
### Usage Stats
Fetches cost and compute usage for a given plan type and time range.
```bash theme={null}
simplismart usage stats [options]
```
| Option | Description |
| ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `--plan-type TYPE` | Compute plan to query (required). See [Plan Types](#plan-types) |
| `--start-time TIME` | Range start in ISO 8601 format (required) |
| `--end-time TIME` | Range end in ISO 8601 format (required) |
| `--window-size SIZE` | Aggregation bucket size (required). Options are: `MINUTE`, `15MIN`, `30MIN`, `HOUR`, `3HOUR`, `6HOUR`, `12HOUR`, `DAY`, `WEEK` |
| `--workspace-id UUID` | Restrict to a specific workspace UUID (uses org default if omitted) |
| `--deployment-id a,b,...` | Filter by deployment UUID(s). Only valid for `private`, `byoc`, `reserved` |
| `--deployment-slug a,b,...` | Filter by deployment slug(s). Same scope as `--deployment-id` above |
| `--model-name a,b,...` | Filter by model name(s) (e.g. `DeepSeek-R1`). Only valid for `shared` |
| `--training-job-id a,b,...` | Filter by training job UUID(s). Only valid for `training` |
| `--training-job-name a,b,...` | Filter by training job name(s). Only valid for `training` |
| `--model-repo-id a,b,...` | Filter by model repo UUID(s). Only valid for `compilation` |
| `--model-repo-name a,b,...` | Filter by model repo name(s). Only valid for `compilation` |
| `--statuses a,b,...` | Restrict to exactly these resource statuses (e.g. `DEPLOYED`, `STOPPED`, `DELETED`, `FAILED` for deployments; `SUCCESS`, `FAILED` for compilation). Omit for no restriction — every status is included by default. No effect for `training` |
| `--group-by deployment\|accelerator` | `accelerator` pools items per GPU/CPU type instead of per deployment — the same toggle as the dashboard's Group By dropdown. Only valid for `--plan-type` in `private`/`reserved`. For `--plan-type reserved`, `accelerator` (or omitting `--group-by`, with no deployment filter) also gets you the reservation commitment breakdown automatically — see the Reserved example below |
Each filter flag can be passed only once (use comma-separated values like `a,b,c` for multiple values). Passing an unsupported filter for the selected plan type returns an error.
1. You can find `workspace-id` under Settings > Workspaces. Select your workspace and copy the workspace ID.
2. Go to Deployments and select a deployment to find the `deployment-id` and `deployment-slug`.
#### Plan Types
| Value | Description |
| ------------- | --------------------------------------- |
| `shared` | Shared endpoint usage |
| `private` | Private dedicated deployment usage |
| `byoc` | Bring Your Own Compute deployment usage |
| `reserved` | Reserved capacity usage |
| `training` | Training and fine-tuning job usage |
| `compilation` | Model compilation job usage |
**Examples:**
**Dedicated usage (`private`): daily cost for the last 7 days**
```bash theme={null}
simplismart usage stats \
--plan-type private \
--start-time 2026-04-28T00:00:00+00:00 \
--end-time 2026-05-05T00:00:00+00:00 \
--window-size DAY
```
**Shared endpoint usage (`shared`): hourly cost for the last 24 hours, linked to a given workspace**
```bash theme={null}
simplismart usage stats \
--plan-type shared \
--start-time 2026-05-04T00:00:00+00:00 \
--end-time 2026-05-05T00:00:00+00:00 \
--window-size HOUR \
--workspace-id
```
**Dedicated/BYOC usage (`private`): daily cost scoped to deployments by `--deployment-id` (comma-separated UUIDs)**
```bash theme={null}
simplismart usage stats \
--plan-type private \
--start-time 2026-04-01T00:00:00+00:00 \
--end-time 2026-05-01T00:00:00+00:00 \
--window-size DAY \
--deployment-id ,
```
**Shared usage (`shared`): daily cost filtered to inference on specific `--model-name` values**
```bash theme={null}
simplismart usage stats \
--plan-type shared \
--start-time 2026-04-01T00:00:00+00:00 \
--end-time 2026-05-01T00:00:00+00:00 \
--window-size DAY \
--model-name DeepSeek-R1,Llama-3
```
**Training (`training`): weekly rollup for specific jobs (`--training-job-name`)**
```bash theme={null}
simplismart usage stats \
--plan-type training \
--start-time 2026-04-01T00:00:00+00:00 \
--end-time 2026-05-01T00:00:00+00:00 \
--window-size WEEK \
--training-job-name finetune-llama-v1,finetune-llama-v2
```
**Compilation (`compilation`): weekly rollup for `--model-repo-name`:**
```bash theme={null}
simplismart usage stats \
--plan-type compilation \
--start-time 2026-04-01T00:00:00+00:00 \
--end-time 2026-05-01T00:00:00+00:00 \
--window-size WEEK \
--model-repo-name my-model-repo
```
**Reserved (`reserved`): daily cost plus the pooled reservation commitment breakdown**
`--group-by accelerator` (or omitting `--group-by`, with no deployment filter) gets you the full commitment breakdown automatically — no flag to pass:
```bash theme={null}
simplismart usage stats \
--plan-type reserved \
--start-time 2026-04-01T00:00:00+00:00 \
--end-time 2026-05-01T00:00:00+00:00 \
--window-size DAY \
--group-by accelerator | jq '.items[] | {event_name, points: [.points[] | {timestamp, computed_overage_amount, computed_true_up_amount}]}'
# reservation_commitment is a separate, top-level field alongside items/total_cost -
# one entry per accelerator type your org has committed to, each with a `daily`
# array of per-window overage/true-up figures:
simplismart usage stats \
--plan-type reserved \
--start-time 2026-04-01T00:00:00+00:00 \
--end-time 2026-05-01T00:00:00+00:00 \
--window-size DAY \
--group-by accelerator | jq '.reservation_commitment'
```
`total_cost` reflects what your org is actually billed under the reservation. `computed_overage_amount` is usage billed above what you've committed to for that window; `computed_true_up_amount` is committed capacity you paid for but didn't use that window. If your org moved from a private plan to a reserved plan, `items` includes usage from before that migration too, so you get one continuous view instead of a gap at the migration date.
**`--group-by deployment` never returns the commitment breakdown** — overage/true-up cost is pooled across your whole account and can't be attributed to a single deployment, so a pooled, account-wide figure sitting next to a per-deployment cost list would be misleading. Use `--group-by accelerator` (or omit `--group-by`) whenever you want the breakdown.
**`--deployment-id`/`--deployment-slug` can't be combined with an explicit `--group-by accelerator`** — the SDK rejects it locally, and the backend rejects it too (`400`), since a pooled/accelerator-grouped query never resolves per-deployment sources at all. Omitting `--group-by` alongside a deployment filter is fine — for `--plan-type reserved` it auto-corrects to `--group-by deployment` instead of defaulting to the pooled shape.
`--group-by deployment` gets you a flat per-deployment metered cost list instead — it never includes the commitment breakdown:
```bash theme={null}
simplismart usage stats \
--plan-type reserved \
--start-time 2026-04-01T00:00:00+00:00 \
--end-time 2026-05-01T00:00:00+00:00 \
--window-size DAY \
--group-by deployment | jq '.items[] | {source, event_name, total_cost}'
```
`--group-by` can be omitted for a deployment-filtered `reserved` query too — `--deployment-id`/`--deployment-slug` auto-correct an omitted `--group-by` to the per-deployment shape:
```bash theme={null}
simplismart usage stats \
--plan-type reserved \
--start-time 2026-04-01T00:00:00+00:00 \
--end-time 2026-05-01T00:00:00+00:00 \
--window-size DAY \
--deployment-id ,
```
**Private/Reserved: pooled per-accelerator-type breakdown instead of per-deployment**
```bash theme={null}
simplismart usage stats \
--plan-type private \
--start-time 2026-04-01T00:00:00+00:00 \
--end-time 2026-05-01T00:00:00+00:00 \
--window-size DAY \
--group-by accelerator
```
`--group-by` just changes how `items` is organized — it's available for both `--plan-type private` and `--plan-type reserved`, with the same two values (`deployment` or `accelerator`) either way. The reservation breakdown above only ever comes with `--plan-type reserved` — a `--plan-type private` request, even with `--group-by accelerator`, never includes `reservation_commitment`. For `--plan-type reserved`, the breakdown always covers your whole account, and only appears with `--group-by accelerator` (or `--group-by` omitted).
Pooled (`--group-by accelerator`) items gain a `sources` key (a list of every deployment source folded into it) in place of a single `source` value. Each point in a pooled item also carries `computed_commitment_utilized_amount`, `computed_overage_amount`, and `computed_true_up_amount`:
```json theme={null}
{
"timestamp": "2026-07-14T00:00:00Z",
"usage": "21220.0",
"cost": "1448.7226666666668",
"event_count": 9401,
"computed_commitment_utilized_amount": "115.104",
"computed_overage_amount": "2.16",
"computed_true_up_amount": "204.29866666666666"
}
```
* **`computed_commitment_utilized_amount`** — cost covered by capacity you've already committed to.
* **`computed_overage_amount`** — cost billed at on-demand rates because usage went above your committed quantity that window.
* **`computed_true_up_amount`** — committed capacity you paid for but didn't use that window.
**Which field to use, by grouping:**
| `--group-by` | Use |
| ------------- | --------------------------------------------------------------------------------------- |
| `accelerator` | `items[].points[].computed_overage_amount` / `computed_true_up_amount`, per time bucket |
| `deployment` | Never carries these fields - use `accelerator` for that data instead |
**Expected output** — a single JSON object printed to stdout, with cost/usage broken down per `items` entry (one per deployment, or one per accelerator type with `--group-by accelerator`) and per time bucket within each entry's `points`:
```json theme={null}
{
"total_cost": "8.00000000000004",
"currency": "usd",
"items": [
{
"event_name": "2-X-YOUR-EVENT-NAME-HERE",
"source": "pg-llama3p1-8b_369ff438-YOUR-DEPLOYMENT-ID-HERE",
"total_cost": "8.00000000000004",
"total_usage": "120",
"currency": "usd",
"unit_price": {
"amount": "0.066666666666667",
"currency": "usd"
},
"points": [
{
"timestamp": "2026-05-05T16:00:00Z",
"usage": "8",
"cost": "0.533333333333336",
"event_count": 4
}
]
}
]
}
```
Use `total_cost` (top-level) for the overall total, and each item's `event_name` + `total_cost` for the breakdown by deployment (or by accelerator type with `--group-by accelerator`). For `--plan-type reserved`, `event_name` is already the plain accelerator type (`nvidia-h100`, `nvidia-l40s`, `cpu`).
**Post-processing — pipe JSON to `jq` to read the total, or break it down per item:**
```bash theme={null}
simplismart usage stats \
--plan-type private \
--start-time 2026-04-01T00:00:00+00:00 \
--end-time 2026-05-01T00:00:00+00:00 \
--window-size DAY | jq '.total_cost'
# Per-item breakdown (e.g. per deployment, or per accelerator type with --group-by accelerator)
simplismart usage stats \
--plan-type private \
--start-time 2026-04-01T00:00:00+00:00 \
--end-time 2026-05-01T00:00:00+00:00 \
--window-size DAY | jq '.items[] | {event_name, total_cost}'
```
The `--pg-token` global flag or the `SIMPLISMART_PG_TOKEN` environment variable must be set. All times must be in ISO 8601 format and `start-time` must be before `end-time`.
# Deployment Commands
Source: https://docs.simplismart.ai/sdk/cli/deployments
CLI commands for managing deployments on the Simplismart platform
Manage deployments using `simplismart deployments`.
### List Deployments
Lists deployments with optional filtering.
```bash theme={null}
simplismart deployments list [options]
```
| Option | Description |
| ---------------------- | ------------------------------ |
| `--model-repo-id UUID` | Filter by model repo UUID |
| `--status STATUS` | Filter by status |
| `--offset N` | Pagination offset (default: 0) |
| `--count N` | Page size (default: 20) |
#### Status Options
| Value | Description |
| ---------- | --------------------------- |
| `DEPLOYED` | Deployment is running |
| `PENDING` | Deployment is being created |
| `FAILED` | Deployment failed |
| `STOPPED` | Deployment is stopped |
| `DELETED` | Deployment has been deleted |
**Example:**
```bash theme={null}
# List all deployments
simplismart deployments list --offset 0 --count 20
# Filter by status
simplismart deployments list --status DEPLOYED --offset 0 --count 20
# Filter by model repo
simplismart deployments list --model-repo-id --status FAILED
```
**Expected output**
```json theme={null}
[
{
"deployment_id": "",
"deployment_name": "whisper-nemo-diarization",
"model_repo_id": "",
"model_repo_name": "whisper-nemo-diarization",
"model_type": "unknown",
"accelerator_type": ["nvidia-h100"],
"accelerator_count": 1,
"status": "DEPLOYED"
},
{
"deployment_id": "",
"deployment_name": "Gemma-3-4B",
"model_repo_id": "",
"model_repo_name": "gemma-3-4b-optim-v2",
"model_type": "llm",
"accelerator_type": ["nvidia-h100"],
"accelerator_count": 1,
"status": "DEPLOYED"
}
]
```
### List Model Deployments
Lists all model deployments for an organization.
```bash theme={null}
simplismart deployments list-model [options]
```
| Option | Description |
| ------------------------- | ------------------------------------------------------------------ |
| `--org-id UUID` | Organization UUID (uses token org if omitted) |
| `--order-type {asc,desc}` | Sort order: `desc` (latest first, default) or `asc` (oldest first) |
**Example:**
```bash theme={null}
simplismart deployments list-model --order-type desc
```
### Create Deployment
Creates a deployment for a model repo.
```bash theme={null}
simplismart deployments create [options]
```
| Option | Description |
| ---------------------------------------------- | ------------------------------------------------------------------------------------------- |
| `--model-repo UUID` | Model repo UUID (required) |
| `--org UUID` | Organization UUID (required) |
| `--gpu-id ID` | GPU type (required) - e.g., `nvidia-h100`, `A10` |
| `--name NAME` | Deployment name (required) |
| `--min-pod-replicas N` | Minimum pod replicas (required) |
| `--max-pod-replicas N` | Maximum pod replicas (required) |
| `--autoscale-config JSON/@file` | Autoscaling config (required unless `min-pod-replicas` and `max-pod-replicas` are set to 1) |
| `--env-variables JSON/@file` | Environment variables |
| `--deployment-custom-configuration JSON/@file` | Custom deployment config |
| `--healthcheck JSON/@file` | Health check config |
| `--ports JSON/@file` | Port mappings |
| `--metrics-path JSON/@file` | Metrics paths |
| `--persistent-volume-claims JSON/@file` | PVC configurations |
| `--deployment-tag TAG` | Deployment tag |
| `--fast-scaleup` | Enable fast scale-up (use `--no-fast-scaleup` to disable) |
| `--scale-to-zero-enabled` | Traffic-based scale-to-zero (default off: `false`) |
| `--async-deployment-type {SYNC,ASYNC}` | Processing mode |
| `--auth-enabled` | Enable auth on the deployment endpoint (use `--no-auth-enabled` to disable) |
| `--extra-details JSON/@file` | Extra deployment details, e.g. `{"is_websocket_enabled": false}` |
| `--deployment-input-files JSON/@file` | Input file mounts, e.g. `[{"name": "weights", "path": "/mnt/weights"}]` |
A deployment scales using **one** of two approaches, and they cannot be combined:
* **Traffic-based** (`--scale-to-zero-enabled`): scales down when the deployment is idle.
* **Cron-based / schedule-based** (`cronScaling`): runs on a fixed schedule. Set `--min-pod-replicas 0` if you also want it to scale to zero outside the scheduled window.
**Example:**
The command below deploys a model on an H100 serving 1 to 2 replicas, autoscaling on GPU utilization (target 80%), with fast scale-up, async request handling, and endpoint auth enabled.
```bash theme={null}
# Create deployment
simplismart deployments create-private \
--model-repo \
--org "$ORG_ID" \
--gpu-id nvidia-h100 \
--name vision-deploy \
--min-pod-replicas 1 \
--max-pod-replicas 2 \
--autoscale-config '{"targets":[{"metric":"gpu","target":80}]}' \
--fast-scaleup \
--async-deployment-type ASYNC \
--auth-enabled
```
The `targets` in `--autoscale-config` accept these metrics:
| Metric | Description |
| ------------- | ----------------------------------------------------- |
| `concurrency` | Number of concurrent requests |
| `cpu` | CPU utilization percentage |
| `gpu` | GPU utilization percentage |
| `gram` | GPU memory utilization |
| `latency` | Request latency (supports percentiles 50, 75, 90, 95) |
| `ram` | RAM utilization |
| `throughput` | Requests per second |
These are the same scaling metrics you set when [creating a deployment](/model-suite/deployments/creating-a-deployment) on the Simplismart Platform. For what each metric measures and how thresholds trigger scaling, see [Add Scaling Metrics](/model-suite/deployments/creating-a-deployment#add-scaling-metrics).
Cron-based scaling (called schedule-based scaling on the Simplismart platform) runs the deployment on a fixed schedule. For example, to keep it up on weekdays 9am to 6pm UTC and scale to zero outside that window, set `--min-pod-replicas 0` and pass a `cronScaling` config. Each `cronScaling` rule requires `timezone`, `start`, `end`, and `desiredReplicas`:
```bash theme={null}
simplismart deployments create-private \
--model-repo \
--org "$ORG_ID" \
--gpu-id nvidia-h100 \
--name my-deploy \
--min-pod-replicas 0 \
--max-pod-replicas 2 \
--autoscale-config '{"targets":[{"metric":"gpu","target":80}],"cronScaling":[{"timezone":"UTC","start":"0 9 * * 1,2,3,4,5","end":"0 18 * * 1,2,3,4,5","desiredReplicas":2}]}'
```
Each `cronScaling` rule accepts:
| Field | Required | Description |
| ----------------- | -------- | ------------------------------------------------------------ |
| `timezone` | Yes | IANA timezone, e.g. `UTC` |
| `start` | Yes | Cron expression for when the active window starts |
| `end` | Yes | Cron expression for when the active window ends |
| `desiredReplicas` | No | Replicas to run inside the window (default `1`, minimum `1`) |
You can also pass the config as a file with `--autoscale-config @autoscale.json`, where `autoscale.json` contains:
```json theme={null}
{
"targets": [
{"metric": "gpu", "target": 80}
],
"cronScaling": [
{
"timezone": "UTC",
"start": "0 9 * * 1,2,3,4,5",
"end": "0 18 * * 1,2,3,4,5",
"desiredReplicas": 2
}
]
}
```
### Get Deployment
Gets deployment details by ID.
```bash theme={null}
simplismart deployments get [options]
```
| Option | Description |
| ---------------------- | -------------------------- |
| `--deployment-id UUID` | Deployment UUID (required) |
**Example:**
```bash theme={null}
simplismart deployments get --deployment-id
```
**Expected output**
Returns a single deployment object with full details (e.g. `deployment_id`, `deployment_name`, `model_repo_id`, `model_repo_name`, `status`, `accelerator_type`, `accelerator_count`, and other configuration fields).
```json theme={null}
{
"uuid": "",
"avatar": {
...
},
"created_by": {
...
},
"persistent_volume_claims": [],
"autoscale_config": {
"targets": [
{
"unit": "%",
"metric": "cpu",
"target": 80,
"description": "Average CPU usage across all pods"
}
]
},
"deployment_custom_configuration": {
"command": []
},
"ports": {
"http": {
"port": 8000
}
},
"healthcheck": {
"path": "/health",
"port": 8000,
"initialDelaySeconds": 30,
"periodSeconds": 10,
"timeoutSeconds": 5
},
"env_variables": {},
"metrics_path": [],
"metrics_http_method_overrides": {},
"created_at": "2026-03-02T11:53:05.744416Z",
"updated_at": "2026-03-02T12:05:17.018284Z",
"is_public": false,
"name": "whisper-nemo-diarization",
"display_name": "whisper-nemo-diarization",
"proxy_name": "",
"status": "DEPLOYED",
"slug": "fi0pjr7jaf",
"autoscaling": true,
"min_pod_replicas": 1,
"max_pod_replicas": 8,
"scale_to_zero_enabled": false,
"model_cloud": "",
"accelerator_type": "nvidia-h100",
"accelerator_request": 1.0,
"accelerator_limit": 1.0,
"cpu_request": 23.0,
"cpu_limit": 23.0,
"memory_request": 190.0,
"memory_limit": 190.0,
"node_affinity": "none",
"ended_at": null,
"image_url": null,
"tags": null,
"proxy_url": "",
"api_details": {},
"input_configuration": {},
"deleted_at": null,
"deployment_details": {},
"advanced_configuration": {},
"extra_details": {
"deployment_tag": "production",
"deletion_retry_count": 0
},
"external_deployment_id": null,
"is_deployable": true,
"model_output_type": "",
"paused_at": null,
"resumed_at": null,
"async_deployment_type": "SYNC",
"has_custom_proxy": false,
"is_private_request_tracking_enabled": false,
"is_privately_deployed": true,
"status_description": null,
"image_prepuller": false,
"is_warmpool_deployment": false,
"additional_tags": {},
"cluster_selection_logic": [
...
],
"org": "",
"updated_by": null,
"model_repo": "",
"cluster": "",
"pricing_catalog": null,
"additional_usage_details": null,
"input_volume_mounts": null,
"output_volume_mounts": null,
"source_secret": null,
"deployment_config": null,
"pricing_config": null,
"node_groups": [
""
]
}
```
### Update Deployment
Updates deployment configuration.
```bash theme={null}
simplismart deployments update [options]
```
| Option | Description |
| ---------------------- | ------------------------------------------- |
| `--deployment-id UUID` | Deployment UUID (required) |
| `--payload JSON/@file` | JSON object with editable fields (required) |
**Example:**
```bash theme={null}
simplismart deployments update --deployment-id --payload @edit-payload.json
```
### Stop Deployment
Stops a running deployment.
```bash theme={null}
simplismart deployments stop [options]
```
| Option | Description |
| ---------------------- | -------------------------- |
| `--deployment-id UUID` | Deployment UUID (required) |
**Example:**
```bash theme={null}
simplismart deployments stop --deployment-id
```
### Start Deployment
Starts a stopped deployment.
```bash theme={null}
simplismart deployments start [options]
```
| Option | Description |
| ---------------------- | -------------------------- |
| `--deployment-id UUID` | Deployment UUID (required) |
**Example:**
```bash theme={null}
simplismart deployments start --deployment-id
```
### Scale Deployment
Updates the autoscaling configuration of a live deployment.
```bash theme={null}
simplismart deployments scale [options]
```
| Option | Description |
| ----------------------------------- | -------------------------------------------------------------------- |
| `--deployment-id UUID` | Deployment UUID (required) |
| `--min-replicas N` | Minimum replicas (required). `0` requires `--cron-scaling` |
| `--max-replicas N` | Maximum replicas (required) |
| `--scale-to-zero` | Traffic-based scale-to-zero. Cannot combine with `--cron-scaling` |
| `--cooldown-period SECONDS` | KEDA cooldown period |
| `--initial-cooldown-period SECONDS` | KEDA initial cooldown period |
| `--cron-scaling JSON/@file` | List of cron windows (`timezone`, `start`, `end`, `desiredReplicas`) |
| `--targets JSON/@file` | KEDA metric targets (`metric`, `target`, optional `percentile`) |
| `--scale-up-behavior JSON/@file` | HPA scale-up behavior |
| `--scale-down-behavior JSON/@file` | HPA scale-down behavior |
On this endpoint `cronScaling`, `targets`, `scaleDownBehavior`, and `scaleUpBehavior` are **top-level** fields (unlike `create` / `update`, where they nest inside `--autoscale-config`). Two rules are validated client-side before the request: `--min-replicas 0` requires `--cron-scaling`, and `--scale-to-zero` cannot be combined with `--cron-scaling`.
**Examples:**
```bash theme={null}
# Plain min/max replicas
simplismart deployments scale \
--deployment-id \
--min-replicas 1 \
--max-replicas 3
# Traffic-based scale-to-zero with a cooldown
simplismart deployments scale \
--deployment-id \
--min-replicas 1 --max-replicas 3 \
--scale-to-zero --cooldown-period 30
# Cron window — min-replicas 0, run only weekdays 8am–6pm UTC
simplismart deployments scale \
--deployment-id \
--min-replicas 0 --max-replicas 2 \
--cron-scaling '[{"timezone":"UTC","start":"0 8 * * 1-5","end":"0 18 * * 1-5","desiredReplicas":1}]'
# Latency metric target + both HPA behaviors (fast up, gentle down)
simplismart deployments scale \
--deployment-id \
--min-replicas 1 --max-replicas 8 \
--targets '[{"metric":"latency","target":200,"percentile":95}]' \
--scale-up-behavior '{"stabilizationWindowSeconds":0,"selectPolicy":"Max","policies":[{"type":"Pods","value":4,"periodSeconds":15}]}' \
--scale-down-behavior '{"stabilizationWindowSeconds":300,"selectPolicy":"Min","policies":[{"type":"Percent","value":25,"periodSeconds":60}]}'
# Large configs can be read from a file with @
simplismart deployments scale \
--deployment-id \
--min-replicas 1 --max-replicas 8 --scale-up-behavior @scale_up.json
```
### Delete Deployment
Deletes a deployment.
```bash theme={null}
simplismart deployments delete [options]
```
| Option | Description |
| ---------------------- | -------------------------- |
| `--deployment-id UUID` | Deployment UUID (required) |
**Example:**
```bash theme={null}
simplismart deployments delete --deployment-id
```
***
## BYOC Deployment
Create a BYOC deployment with a payload (cluster, nodegroup, etc.). See [Bring your own compute](/inference/bring-your-own-compute) and [Deploy on imported cluster](/model-suite/deployments/deploy-on-an-imported-cluster).
```bash theme={null}
simplismart deployments create-byoc --payload '{
"model_repo": "",
"org": "",
"name": "my-byoc-deploy",
"min_pod_replicas": 1,
"max_pod_replicas": 1,
"nodegroups": [""]
}'
# Or from a JSON file
simplismart deployments create-byoc --payload @byoc-create.json
```
# Model Repository Commands
Source: https://docs.simplismart.ai/sdk/cli/model-repos
CLI commands for managing model repositories on the Simplismart Platform
Manage model repositories using `simplismart model-repos`.
### List Model Repos
Lists model repositories with optional filtering.
```bash theme={null}
simplismart model-repos list [options]
```
| Option | Description |
| -------------------- | ------------------------------------- |
| `--offset N` | Pagination offset (default: 0) |
| `--count N` | Page size (default: 5) |
| `--model-id UUID` | Fetch specific model repo by ID |
| `--name NAME` | Filter by model name (contains match) |
| `--status STATUS` | Filter by status |
| `--model-type TYPE` | Filter by model type |
| `--created-by EMAIL` | Filter by creator email |
**Expected output**
```json theme={null}
{
"limit": 5,
"offset": 0,
"count": 50,
"results": [
{
"uuid": "",
"name": "whisper-nemo-diarization",
"source_type": "docker_hub",
"source_url": "simplismart/whisper-nemo-diarization:latest",
"is_byom": true,
"accelerator": null,
"runtime_gpus": 1,
"byom": {
"image": "simplismart/MODEL-NAME:latest",
"registry": "simplismart/REGISTRY-NAME",
"tag": "latest"
},
"secrets": {
"source_secret": {
"uuid": "",
"name": ""
}
},
"status": "SUCCESS",
"model_type": "byom",
"env": {},
"created_at": "2026-03-02T11:52:16.925151Z",
"updated_at": "2026-03-02T11:52:16.925162Z",
"org_id": "",
"healthcheck": {
"path": "/health",
"port": 8000,
"periodSeconds": 10,
"timeoutSeconds": 5,
"initialDelaySeconds": 30
},
"ports": {
"http": {
"port": 8000
}
},
"metrics_path": [],
"deployment_custom_configuration": {
"command": []
}
}
]
}
```
#### Status Options
| Value | Description |
| ------------- | --------------------------- |
| `SUCCESS` | Model repo is ready |
| `FAILED` | Model repo creation failed |
| `DELETED` | Model repo has been deleted |
| `PROGRESSING` | Model repo is being created |
**Example:**
```bash theme={null}
# List all model repos
simplismart model-repos list --offset 0 --count 5
# Filter by status and name
simplismart model-repos list --status SUCCESS --name vision
# Get specific model repo
simplismart model-repos list --model-id
```
### Get Model Repo
Gets details of a specific model repository.
```bash theme={null}
simplismart model-repos get [options]
```
| Option | Description |
| ----------------- | -------------------------- |
| `--model-id UUID` | Model repo UUID (required) |
**Example:**
```bash theme={null}
simplismart model-repos get --model-id
```
**Expected output**
```json theme={null}
{
"uuid": "",
"name": "whisper-nemo-diarization",
"source_type": "docker_hub",
"source_url": "simplismart/MODEL_NAME:latest",
"is_byom": true,
"accelerator": null,
"runtime_gpus": 1,
"byom": {
"image": "simplismart/MODEL-NAME:latest",
"registry": "simplismart/REGISTRY-NAME",
"tag": "latest"
},
"secrets": {
"source_secret": {
"uuid": "",
"name": ""
}
},
"status": "SUCCESS",
"model_type": "byom",
"env": {},
"created_at": "2026-03-02T11:52:16.925151Z",
"updated_at": "2026-03-02T11:52:16.925162Z",
"org_id": "",
"healthcheck": {
"path": "/health",
"port": 8000,
"periodSeconds": 10,
"timeoutSeconds": 5,
"initialDelaySeconds": 30
},
"ports": {
"http": {
"port": 8000
}
},
"metrics_path": [],
"deployment_custom_configuration": {
"command": []
}
}
```
### Get Model Profiles
Generates/resolves the model profile from a source type and path. Returns the **optimization combinations** available for that model (quantizations, machines, and parallelism options).
```bash theme={null}
simplismart model-repos profiles [options]
```
| Option | Description |
| ------------------ | ------------------------------------------------------- |
| `--type TYPE` | Source type (required) - e.g., `hf`, `s3`, `azure_blob` |
| `--path PATH` | Source path (required) |
| `--secret-id UUID` | Secret UUID (optional) |
**Example:**
```bash theme={null}
simplismart model-repos profiles --type hf --path meta-llama/Llama-3.1-8B-Instruct
```
**Expected output**
```json theme={null}
{
"profile": {
"model_info": {
"type": "llm",
"architecture": "LlamaForCausalLM",
"param_size": "8030261248",
"default_quantization": "float16"
},
"quantizations": {
"float16": {
"machines": [
"nvidia-a100-40gb",
"nvidia-a100-80gb",
"nvidia-h100",
"nvidia-l40s"
]
},
"fp8": {
"machines": [
"nvidia-h100",
"nvidia-h100-pcie",
"nvidia-h100-sxm5"
]
},
"int4": {
"machines": [
"nvidia-a100-40gb",
"nvidia-a10g",
"nvidia-h100",
"nvidia-l4",
"nvidia-l40s",
"nvidia-tesla-t4"
]
}
},
"combinations": [
{
"quantization": "float16",
"machine": "nvidia-h100",
"tensor_parallelism": [1, 2, 4, 8],
"data_parallelism": [1],
"pipeline_parallelism": [1],
"expert_parallelism": [1]
}
]
}
}
```
**Output:** JSON with a `profile` object containing:
* **model\_info** — `type`, `architecture`, `param_size`, `default_quantization`
* **quantizations** — map of quantization (e.g. `float16`, `fp8`, `int4`) to list of supported `machines`
* **combinations** — list of valid (quantization, machine, parallelism) combinations; each has `quantization`, `machine`, `tensor_parallelism`, `data_parallelism`, `pipeline_parallelism`, `expert_parallelism` (each a list of allowed values)
### Bring Your Own Container Model Repo
Bring your own container.
```bash theme={null}
simplismart model-repos create-container [options]
```
| Option | Description |
| ---------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| `--name NAME` | Model repo name (required) |
| `--org-id UUID` | Organization UUID (required) |
| `--source-type TYPE` | Source type (required) - `docker_hub`, `depot`, `nvidiadockersecret` |
| `--runtime-gpus N` | Runtime GPU count (required) |
| `--source-secret UUID` | Source secret UUID (required for `depot`/`nvidiadockersecret`; optional for public `docker_hub` images) |
| `--registry-path PATH` | Registry path/repo (required) |
| `--docker-tag TAG` | Image tag (required) |
| `--env KEY=VALUE` | Environment variable (can be repeated) |
| `--healthcheck JSON/@file` | JSON or file path for healthcheck |
| `--ports JSON/@file` | JSON or file path for ports |
| `--metrics-path JSON/@file` | JSON array or file path for metrics paths |
| `--deployment-custom-configuration JSON/@file` | Custom deployment config |
**Example:**
```bash theme={null}
simplismart model-repos create-container \
--name vision-container \
--org-id "$ORG_ID" \
--source-type docker_hub \
--runtime-gpus 1 \
--source-secret \
--registry-path org/vision \
--docker-tag v1.2.3
```
### Create Private Compile Model Repo
Creates a private compile model repository: the platform compiles the model from a source (e.g. Hugging Face) using config files for model, optimisation, and pipeline.
```bash theme={null}
simplismart model-repos create-private-compile [options]
```
| Option | Description |
| ---------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| `--name NAME` | Model repo name (required) |
| `--source-type TYPE` | Source type (required) - e.g. `huggingface` |
| `--source-url URL` | Source path/URL (required) - e.g. HF repo id |
| `--mode MODE` | Compilation mode (default: `public_hf`) - e.g. `public_hf`, `private_hf`, `aws`, `gcp`, `public_url`, `simplismart` |
| `--model-class CLASS` | Model class (required) - e.g. `LlamaForCausalLM` |
| `--accelerator-type TYPE` | Accelerator type (required) - e.g. `nvidia-h100` |
| `--accelerator-count N` | Accelerator count (default: 0) |
| `--org-id UUID` | Org UUID (optional if inferred from PG token) |
| `--cloud-account UUID` | Cloud account UUID |
| `--source-secret UUID` | Secret UUID for source access |
| `--lora-secret UUID` | LoRA secret UUID |
| `--description TEXT` | Description |
| `--short-description TEXT` | Short description |
| `--dropdown-description TEXT` | Dropdown description |
| `--machine-type TYPE` | Machine type |
| `--region REGION` | Region |
| `--resource-group GROUP` | Resource group |
| `--processing-mode MODE` | One of: `SYNC`, `ASYNC`, `REALTIME_ASYNC` |
| `--model-family FAMILY` | Model family |
| `--env KEY=VALUE` | Environment variable (repeatable) |
| `--model-config JSON/@file` | [Model config](/sdk/python/model-repos#config-files-private-compile) |
| `--optimisation-config JSON/@file` | [Optimisation config](/sdk/python/model-repos#config-files-private-compile) |
| `--pipeline-config JSON/@file` | [Pipeline config](/sdk/python/model-repos#config-files-private-compile) |
| `--tasks JSON/@file` | Tasks list |
| `--tags JSON/@file` | Tags object |
| `--output-metadata JSON/@file` | Output metadata |
| `--additional-details JSON/@file` | Additional details |
**Example:**
```bash theme={null}
simplismart model-repos create-private-compile \
--name llama-sdk-cli \
--source-type huggingface \
--source-url meta-llama/Llama-3.2-1B-Instruct \
--model-class LlamaForCausalLM \
--accelerator-type nvidia-h100 \
--model-config @examples/private-compile-sample/model_config.json \
--optimisation-config @examples/private-compile-sample/optimisation_config.json \
--pipeline-config @examples/private-compile-sample/pipeline_config.json
```
**Config files:** See the [Python SDK Model Repos](/sdk/python/model-repos#config-files-private-compile) for the structure of [model\_config.json](https://github.com/simpli-smart/simplismart-python/blob/main/examples/private-compile-sample/model_config.json), [optimisation\_config.json](https://github.com/simpli-smart/simplismart-python/blob/main/examples/private-compile-sample/optimisation_config.json), and [pipeline\_config.json](https://github.com/simpli-smart/simplismart-python/blob/main/examples/private-compile-sample/pipeline_config.json).
**Example output**
```
{
"uuid": "",
"created_at": "2026-03-02T16:07:31.776954Z",
"updated_at": "2026-03-02T16:07:31.776967Z",
"org": "",
"is_public": false,
"is_deployable": true,
"name": "llama-sdk-cli",
"is_deleted": false,
"deleted_at": null,
"avatar": {
"uuid": "",
"image_url": "",
"font_color": "#000000",
"background_color": "#f3f3f3"
},
"model_class": "LlamaForCausalLM",
"master_model_class": "llm",
"env": {},
"model_type": "platform",
"tags": [],
"short_description": "",
"source_type": "huggingface",
"source_url": "meta-llama/Llama-3.2-1B-Instruct",
"gpu_count": 1,
"is_dynamo": false,
"status": "PENDING",
"logs_pod_hostname": null
}
```
Full examples are in the Simplismart [SDK example repo](https://github.com/simpli-smart/simplismart-python/tree/main/examples/private-compile-sample/).
### Delete Model Repo
Deletes a model repository.
```bash theme={null}
simplismart model-repos delete [options]
```
| Option | Description |
| ----------------- | -------------------------- |
| `--model-id UUID` | Model repo UUID (required) |
**Example:**
```bash theme={null}
simplismart model-repos delete --model-id
```
**Example Output**
```
{"status": "deleted", "model_id": ""}
```
***
# Overview
Source: https://docs.simplismart.ai/sdk/cli/overview
Command-line interface reference for Simplismart
The Simplismart CLI provides command-line access to manage model repositories, deployments, and secrets.
## Installation
After installing the SDK, the CLI is available as the `simplismart` command:
```bash theme={null}
pip install simplismart-sdk
```
## Global Options
These options apply to all CLI commands:
```bash theme={null}
simplismart [global options] [subcommand] [options]
```
| Option | Description | Default |
| ------------------- | ----------------------------- | -------------------------------------------- |
| `--pg-token TOKEN` | Playground token | Falls back to `SIMPLISMART_PG_TOKEN` env var |
| `--base-url URL` | API base URL | `https://api.app.simplismart.ai` |
| `--timeout SECONDS` | Request timeout | `300` |
| `--trace-id ID` | Optional trace/correlation ID | Generated per request |
***
## Quick Reference
| Task | Command |
| ----------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| List model repos | `simplismart model-repos list` |
| Create model repo (container) | `simplismart model-repos create-container --name --source-type docker_hub --runtime-gpus 1 --source-secret --registry-path --docker-tag ` |
| Create model repo (private compile) | `simplismart model-repos create-private-compile --name --source-type huggingface --source-url --model-class --accelerator-type --model-config @model_config.json --optimisation-config @optimisation_config.json --pipeline-config @pipeline_config.json` |
| List deployments | `simplismart deployments list` |
| Create deployment | `simplismart deployments create --model-repo --org $ORG_ID --gpu-id nvidia-h100 --name --min-pod-replicas 1 --max-pod-replicas 2 --autoscale-config @config.json` |
| Stop deployment | `simplismart deployments stop --deployment-id ` |
| Start deployment | `simplismart deployments start --deployment-id ` |
| Delete deployment | `simplismart deployments delete --deployment-id ` |
| Create secret | `simplismart secrets create --org-id $ORG_ID --name --secret-type docker_hub --data @data.json` |
| List secrets | `simplismart secrets list --org-id $ORG_ID` |
# Secret Commands
Source: https://docs.simplismart.ai/sdk/cli/secrets
CLI commands for managing secrets on the Simplismart platform
Manage secrets using `simplismart secrets`.
### Create Secret
Creates a secret for an organization.
```bash theme={null}
simplismart secrets create [options]
```
| Option | Description |
| -------------------- | ------------------------------------------- |
| `--name NAME` | Secret name (required) |
| `--secret-type TYPE` | Secret type (required) - e.g., `docker_hub` |
| `--data JSON/@file` | Secret data as JSON (required) |
**Example:**
```bash theme={null}
simplismart secrets create \
--name demo-secret \
--secret-type docker_hub \
--data @secret-data.json
```
Where `secret-data.json` contains:
```json theme={null}
{
"username": "your-username",
"token": "your-token"
}
```
### List Secrets
Lists secrets for an organization.
```bash theme={null}
simplismart secrets list [options]
```
| Option | Description |
| --------------- | ---------------------------- |
| `--org-id UUID` | Organization UUID (required) |
**Example:**
```bash theme={null}
simplismart secrets list --org-id "$ORG_ID"
```
**Expected output**
```json theme={null}
{
"data": [
{
"uuid": "",
"created_at": "2024-09-12T13:01:55.465292Z",
"updated_at": "2024-09-12T13:01:55.465316Z",
"name": "",
"secret_type": "gcp",
"is_simplismart_managed": false,
"is_system_generated": false,
"reference_count": 0,
"org": ""
}
]
}
```
### Get Secret
Gets details of a specific secret.
```bash theme={null}
simplismart secrets get [options]
```
| Option | Description |
| ------------------ | ---------------------- |
| `--secret-id UUID` | Secret UUID (required) |
**Example:**
```bash theme={null}
simplismart secrets get --secret-id
```
**Expected output**
Returns a single secret object (e.g. `uuid`, `name`, `secret_type`, `created_at`, `updated_at`, `org`). Secret values are never returned.
***
## JSON File Input
Many CLI commands accept JSON input via file path using the `@` prefix:
```bash theme={null}
# Pass JSON directly
simplismart deployments create --autoscale-config '{"targets": [{"metric": "gpu", "target": 80}]}'
# Or pass a file path
simplismart deployments create --autoscale-config @autoscale.json
```
***
## Error Handling
CLI errors are returned as JSON:
```json theme={null}
{
"error": "Deployment is already in stopped state",
"status": 400
}
```
# Analytics
Source: https://docs.simplismart.ai/sdk/python/analytics
Monitor usage and cost using the Simplismart Python SDK
Track GPU compute consumption and cost across plan types using the `client.get_usage_stats()` method.
## Cost & Usage
### `get_usage_stats`
Fetches time-series usage and cost data for a given plan type and time range.
```python theme={null}
from datetime import datetime, timedelta, timezone
from simplismart import Simplismart, UsageStatsParams
import json
client = Simplismart()
now = datetime.now(tz=timezone.utc)
stats = client.get_usage_stats(
UsageStatsParams(
plan_type="private",
start_time=(now - timedelta(days=7)).isoformat(),
end_time=now.isoformat(),
window_size="DAY",
)
)
print(json.dumps(stats, indent=2, default=str))
```
**Expected Output** — `get_usage_stats()` returns a single dict, not a bare list of items:
```json theme={null}
{
"total_cost": "8.00000000000004",
"currency": "usd",
"items": [
{
"event_name": "2-X-YOUR-EVENT-NAME-HERE",
"source": "pg-llama3p1-8b_369ff438-YOUR-DEPLOYMENT-ID-HERE",
"total_cost": "8.00000000000004",
"total_usage": "120",
"currency": "usd",
"unit_price": {
"amount": "0.066666666666667",
"currency": "usd"
},
"points": [
{
"timestamp": "2026-05-05T16:00:00Z",
"usage": "8",
"cost": "0.533333333333336",
"event_count": 4
}
]
}
]
}
```
Use `total_cost` (top-level) for the overall total, and each item's `event_name` + `total_cost` for the breakdown by deployment (or by accelerator type with `group_by="accelerator"` — see below, including a `plan_type="reserved"`-specific breakdown that only shows up in that grouping).
#### `UsageStatsParams`
| Parameter | Type | Description | Required |
| -------------------- | --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------- |
| `plan_type` | `PlanType` | Compute plan to query. See [Plan Types](#plan-types) | Yes |
| `start_time` | `str` | Range start in ISO 8601 format (e.g. `2026-04-01T00:00:00+00:00`) | Yes |
| `end_time` | `str` | Range end in ISO 8601 format | Yes |
| `window_size` | `WindowSize` | Aggregation bucket size. Options are: `MINUTE`, `15MIN`, `30MIN`, `HOUR`, `3HOUR`, `6HOUR`, `12HOUR`, `DAY`, `WEEK` | Yes |
| `workspace_id` | `str \| None` | Restrict to a specific workspace UUID. Uses the org default if omitted | No |
| `deployment_ids` | `list[str] \| None` | Filter by deployment UUID(s). Only valid for `private`, `byoc`, `reserved` | No |
| `deployment_slugs` | `list[str] \| None` | Filter by deployment slug(s). Same scope as `deployment_ids` above | No |
| `model_names` | `list[str] \| None` | Filter by model name(s) (e.g. `DeepSeek-R1`). Only valid for `shared` | No |
| `training_job_ids` | `list[str] \| None` | Filter by training job UUID(s). Only valid for `training` | No |
| `training_job_names` | `list[str] \| None` | Filter by training job name(s). Only valid for `training` | No |
| `model_repo_ids` | `list[str] \| None` | Filter by model repo UUID(s). Only valid for `compilation` | No |
| `model_repo_names` | `list[str] \| None` | Filter by model repo name(s). Only valid for `compilation` | No |
| `statuses` | `list[str] \| None` | Restrict to exactly these resource statuses (e.g. `DEPLOYED`, `STOPPED`, `DELETED`, `FAILED` for deployments; `SUCCESS`, `FAILED` for compilation). Omit for no restriction — every status is included by default. No effect for `training` | No |
| `group_by` | `"deployment" \| "accelerator" \| None` | `"accelerator"` pools items per GPU/CPU type instead of per deployment — the same toggle as the dashboard's Group By dropdown. Only valid for `plan_type` in `private`/`reserved`. For `plan_type="reserved"`, `"accelerator"` (or omitting `group_by`, with no deployment filter) also gets you the reservation commitment breakdown automatically — see the Reserved example below | No |
List parameters accept one or more values (for example `["a", "b"]`). Passing a filter that is not valid for the selected `plan_type` raises a `ValidationError`.
1. You can find `workspace-id` under Settings > Workspaces. Select your workspace and copy the workspace ID.
2. Go to Deployments and select a deployment to find the `deployment-id` and `deployment-slug`.
#### Plan Types
| Value | Description |
| ------------- | ---------------------------------------------------------------------------- |
| `shared` | [Shared endpoint](/inference/shared-endpoint) usage |
| `private` | [Private/dedicated deployment](/inference/dedicated-endpoint) usage |
| `byoc` | [Bring Your Own Compute](/inference/bring-your-own-compute) deployment usage |
| `reserved` | Reserved capacity usage |
| `training` | [Training and fine-tuning](/training-suite/introduction) job usage |
| `compilation` | [Model compilation](/model-suite/optimise-a-model) job usage |
### Examples
**Dedicated Deployment usage (`plan_type="private"`)**
```python theme={null}
stats = client.get_usage_stats(
UsageStatsParams(
plan_type="private",
start_time=(now - timedelta(days=14)).isoformat(),
end_time=now.isoformat(),
window_size="DAY",
)
)
```
**Shared endpoint (`plan_type="shared"`): hourly buckets for the last 48 hours, pin results to one `workspace_id`**
```python theme={null}
stats = client.get_usage_stats(
UsageStatsParams(
plan_type="shared",
start_time=(now - timedelta(days=2)).isoformat(),
end_time=now.isoformat(),
window_size="HOUR",
workspace_id="your-workspace-uuid",
)
)
```
**Dedicated/BYOC: daily cost only for chosen deployments, pass `deployment_ids` (use `deployment_slugs` instead when you have slugs, not UUIDs)**
```python theme={null}
stats = client.get_usage_stats(
UsageStatsParams(
plan_type="private",
start_time=(now - timedelta(days=30)).isoformat(),
end_time=now.isoformat(),
window_size="DAY",
deployment_ids=["uuid-1", "uuid-2"],
)
)
```
**Shared endpoint: daily cost only for listed `model_names`**
```python theme={null}
stats = client.get_usage_stats(
UsageStatsParams(
plan_type="shared",
start_time=(now - timedelta(days=30)).isoformat(),
end_time=now.isoformat(),
window_size="DAY",
model_names=["DeepSeek-R1", "Llama-3"],
)
)
```
**Training (`plan_type="training"`): weekly buckets for the last 90 days, narrow to `training_job_names`**
```python theme={null}
stats = client.get_usage_stats(
UsageStatsParams(
plan_type="training",
start_time=(now - timedelta(days=90)).isoformat(),
end_time=now.isoformat(),
window_size="WEEK",
training_job_names=["finetune-llama-v1", "finetune-llama-v2"],
)
)
```
**Compilation (`plan_type="compilation"`): daily cost for specific `model_repo_names`**
```python theme={null}
stats = client.get_usage_stats(
UsageStatsParams(
plan_type="compilation",
start_time=(now - timedelta(days=30)).isoformat(),
end_time=now.isoformat(),
window_size="DAY",
model_repo_names=["my-llama-repo", "my-mistral-repo"],
)
)
```
**BYOC: daily rollup for one deployment slug, restricted to a specific status (`statuses=["DEPLOYED"]`)**
```python theme={null}
stats = client.get_usage_stats(
UsageStatsParams(
plan_type="byoc",
start_time=(now - timedelta(days=30)).isoformat(),
end_time=now.isoformat(),
window_size="DAY",
deployment_slugs=["my-deploy"],
statuses=["DEPLOYED"],
)
)
```
**Reserved (`plan_type="reserved"`): daily cost plus the pooled reservation commitment breakdown**
`group_by="accelerator"` (or omitting `group_by`, with no deployment filter) gets you the full commitment breakdown automatically — no flag to set:
```python theme={null}
stats = client.get_usage_stats(
UsageStatsParams(
plan_type="reserved",
start_time=(now - timedelta(days=30)).isoformat(),
end_time=now.isoformat(),
window_size="DAY",
group_by="accelerator",
)
)
print(stats["total_cost"]) # real, commitment-adjusted account total
for item in stats["items"]:
print(item["event_name"])
for point in item["points"]:
print(" ", point["timestamp"], "overage:", point["computed_overage_amount"], "true_up:", point["computed_true_up_amount"])
# reservation_commitment is a separate, top-level field alongside items/total_cost -
# one entry per accelerator type your org has committed to, each with a `daily`
# array of per-day (or per-window) overage/true-up figures:
for entry in stats.get("reservation_commitment", []):
print(entry["name"], entry["daily"])
```
`total_cost` reflects what your org is actually billed under the reservation. If your org moved from a private plan to a reserved plan, `items` includes usage from before that migration too, so you get one continuous view instead of a gap at the migration date. `computed_overage_amount` is usage billed above what you've committed to for that window; `computed_true_up_amount` is committed capacity you paid for but didn't use that window.
**`group_by="deployment"` never returns the commitment breakdown** — overage/true-up cost is pooled across your whole account and can't be attributed to a single deployment, so a pooled, account-wide figure sitting next to a per-deployment cost list would be misleading. Use `group_by="accelerator"` (or omit `group_by`) whenever you want the breakdown.
**`deployment_ids`/`deployment_slugs` can't be combined with an explicit `group_by="accelerator"`** — the SDK rejects it locally (`ValidationError`), and the backend rejects it too (`400`), since a pooled/accelerator-grouped query never resolves per-deployment sources at all. An omitted `group_by` alongside a deployment filter is fine — for `plan_type="reserved"` it auto-corrects to `group_by="deployment"` instead of defaulting to the pooled shape.
`group_by="deployment"` gets you a flat per-deployment metered cost list instead — it never includes the commitment breakdown:
```python theme={null}
stats = client.get_usage_stats(
UsageStatsParams(
plan_type="reserved",
start_time=(now - timedelta(days=30)).isoformat(),
end_time=now.isoformat(),
window_size="DAY",
group_by="deployment",
)
)
for item in stats["items"]:
print(item["source"], item["event_name"], item["total_cost"])
```
`group_by` can be omitted for a deployment-filtered `reserved` query too — `deployment_ids`/`deployment_slugs` auto-correct an omitted `group_by` to the per-deployment shape (no `reservation_commitment` either way):
```python theme={null}
stats = client.get_usage_stats(
UsageStatsParams(
plan_type="reserved",
start_time=(now - timedelta(days=30)).isoformat(),
end_time=now.isoformat(),
window_size="DAY",
deployment_ids=["uuid1", "uuid2"],
)
)
```
**Grouping — deployment vs accelerator**
```python theme={null}
stats = client.get_usage_stats(
UsageStatsParams(
plan_type="private",
start_time=(now - timedelta(days=7)).isoformat(),
end_time=now.isoformat(),
window_size="DAY",
group_by="accelerator",
)
)
```
`group_by="accelerator"` pools `items` per GPU/CPU type instead of per deployment. Only valid for `plan_type` in `private`/`reserved`. Each pooled item gains a `sources` key (a list of every deployment source string folded into it) in place of the single `source` value the per-deployment grouping has; `source` itself is `None` on these pooled items.
Each point in a pooled item also carries `computed_commitment_utilized_amount`, `computed_overage_amount`, and `computed_true_up_amount`:
```json theme={null}
{
"timestamp": "2026-07-14T00:00:00Z",
"usage": "21220.0",
"cost": "1448.7226666666668",
"event_count": 9401,
"computed_commitment_utilized_amount": "115.104",
"computed_overage_amount": "2.16",
"computed_true_up_amount": "204.29866666666666"
}
```
* **`computed_commitment_utilized_amount`** — cost covered by capacity you've already committed to.
* **`computed_overage_amount`** — cost billed at on-demand rates because usage went above your committed quantity that window.
* **`computed_true_up_amount`** — committed capacity you paid for but didn't use that window.
**Which field to use, by grouping:**
| `group_by` | Use |
| --------------- | --------------------------------------------------------------------------------------- |
| `"accelerator"` | `items[].points[].computed_overage_amount` / `computed_true_up_amount`, per time bucket |
| `"deployment"` | Never carries these fields - use `"accelerator"` for that data instead |
`group_by` just changes how `items` is organized — it's available for both `plan_type="private"` and `plan_type="reserved"`, with the same two values (`"deployment"` or `"accelerator"`) either way. The reservation breakdown described above only ever comes with `plan_type="reserved"` — a `plan_type="private"` request, even with `group_by="accelerator"`, never includes `reservation_commitment`. For `plan_type="reserved"`, the breakdown always covers your whole account, and only appears with `group_by="accelerator"` (or `group_by` omitted).
***
## Error Handling
The SDK raises `SimplismartError` for API errors. Pydantic validates `plan_type` and `window_size` before the request is sent, so invalid values are caught locally.
```python theme={null}
from simplismart import Simplismart, UsageStatsParams
from simplismart.exceptions import SimplismartError
client = Simplismart()
try:
stats = client.get_usage_stats(
UsageStatsParams(
plan_type="private",
start_time="2026-04-01T00:00:00+00:00",
end_time="2026-04-30T23:59:59+00:00",
window_size="DAY",
)
)
except SimplismartError as e:
print("Status:", e.status_code)
print("Message:", e)
print("Payload:", e.payload)
```
#### SimplismartError Attributes
| Attribute | Type | Description |
| ------------- | ------ | ------------------------------ |
| `status_code` | `int` | HTTP status code |
| `payload` | `dict` | Full error response payload |
| `message` | `str` | Error message from the backend |
# Deployments
Source: https://docs.simplismart.ai/sdk/python/deployments
Manage deployments using the Simplismart Python SDK
Manage deployments using the `Simplismart` client methods below (e.g. `client.create_deployment(...)`).
### `create_deployment`
Creates a deployment for a model repo.
Use env for model repo UUID and organization ID (e.g. `ORG_ID`); do not hardcode secrets.
The example below deploys a model on an H100 with 1 to 2 replicas that autoscale on GPU utilization (target 80%), with fast scale-up enabled.
```python theme={null}
import os
from dotenv import load_dotenv
load_dotenv()
from simplismart import DeploymentCreate, Simplismart
client = Simplismart()
deployment = client.create_deployment(
DeploymentCreate(
model_repo=os.getenv("MODEL_REPO_ID", "model-repo-uuid"),
org=os.getenv("ORG_ID"),
gpu_id="nvidia-h100",
name="vision-private-deploy",
min_pod_replicas=1,
max_pod_replicas=2,
autoscale_config={"targets": [{"metric": "gpu", "target": 80}]},
env_variables={"KEY": "value"},
healthcheck={"path": "/", "port": 8000},
ports={"http": {"port": 8000}},
metrics_path=["/v1/chat/completions"],
fast_scaleup=True,
deployment_tag="v1.0",
auth_enabled=False,
extra_details={"is_websocket_enabled": False},
)
)
```
#### DeploymentCreate
| Parameter | Type | Description | Required |
| --------------------------------- | ---------------------- | ---------------------------------------------------------------------------------------------------- | ----------- |
| `model_repo` | `str` | Model repository UUID | Yes |
| `org` | `str` | Organization UUID (`org_id`) | Yes |
| `gpu_id` | `str` | GPU type identifier. Examples: `nvidia-h100`, `nvidia-a10`, `nvidia-l4` | Yes |
| `name` | `str` | Deployment name (3-255 chars) | Yes |
| `min_pod_replicas` | `int` | Minimum pod replicas (≥ 0). When using `cronScaling`, set to `0` to scale to zero outside the window | Yes |
| `max_pod_replicas` | `int` | Maximum pod replicas (≥ 1) | Yes |
| `autoscale_config` | `AutoscaleConfig` | Autoscaling configuration. Required unless `min_pod_replicas` and `max_pod_replicas` are both `1` | Conditional |
| `env_variables` | `dict \| None` | Environment variables | No |
| `deployment_custom_configuration` | `dict \| None` | Custom deployment config | No |
| `healthcheck` | `dict \| None` | Health check configuration | No |
| `ports` | `dict \| None` | Port mappings | No |
| `metrics_path` | `list \| None` | Metrics paths | No |
| `persistent_volume_claims` | `dict \| list \| None` | PVC configurations | No |
| `fast_scaleup` | `bool \| None` | Enable fast scale up | No |
| `deployment_tag` | `str \| None` | Deployment tag label | No |
| `scale_to_zero_enabled` | `bool` | Traffic-based scale-to-zero (scales down on idle traffic). Default `false` | No |
| `async_deployment_type` | `str \| None` | One of `SYNC`, `ASYNC` | No |
| `auth_enabled` | `bool \| None` | Enable authentication on the deployment endpoint | No |
| `extra_details` | `dict \| None` | Extra container details, e.g. `{"is_websocket_enabled": False}` | No |
| `deployment_input_files` | `list \| None` | Input file mounts, e.g. `[{"name": "weights", "path": "/mnt/weights"}]` | No |
A deployment scales using **one** of two approaches, and they cannot be combined:
* **Traffic-based** (`scale_to_zero_enabled=True`): scales down when the deployment is idle.
* **Cron-based / schedule-based** (`cronScaling`): runs on a fixed schedule. Set `min_pod_replicas=0` if you also want it to scale to zero outside the scheduled window.
#### AutoscaleConfig
```python theme={null}
autoscale_config = {
"targets": [
{
"metric": "gpu", # Required
"target": 80, # Required (number)
"percentile": 95 # Optional, only for latency metric
}
]
}
```
| Metric Option | Description |
| ------------- | ----------------------------------------------------- |
| `concurrency` | Number of concurrent requests |
| `cpu` | CPU utilization percentage |
| `gpu` | GPU utilization percentage |
| `gram` | GPU memory utilization |
| `latency` | Request latency (supports percentiles 50, 75, 90, 95) |
| `ram` | RAM utilization |
| `throughput` | Requests per second |
The `percentile` field is only supported when `metric` is set to `latency`.
These are the same scaling metrics you set when [creating a deployment](/model-suite/deployments/creating-a-deployment) in the Model Suite. For what each metric measures and how thresholds trigger scaling, see [Add Scaling Metrics](/model-suite/deployments/creating-a-deployment#add-scaling-metrics).
#### Cron-based Scaling
Cron-based scaling (called schedule-based scaling on the Simplismart platform) runs your deployment on a fixed schedule. Use it when traffic is predictable: for example, keep the deployment up during weekday business hours and shut it down outside that window. Add a `cronScaling` config to `autoscale_config`, and set `min_pod_replicas=0` if you want it to scale to zero outside the scheduled window.
```python theme={null}
deployment = client.create_deployment(
DeploymentCreate(
model_repo=os.getenv("MODEL_REPO_ID", "model-repo-uuid"),
org=os.getenv("ORG_ID"),
gpu_id="nvidia-h100",
name="my-deployment-cron",
min_pod_replicas=0,
max_pod_replicas=2,
autoscale_config={
"targets": [{"metric": "gpu", "target": 80}],
"cronScaling": [
{"timezone": "UTC", "start": "0 9 * * 1,2,3,4,5", "end": "0 18 * * 1,2,3,4,5", "desiredReplicas": 2}
],
},
)
)
```
The schedule above runs 2 pods (`desiredReplicas`) on weekdays 9am to 6pm UTC, and because `min_pod_replicas=0` it scales to zero outside that window.
##### CronScalingRule fields
Each entry in `cronScaling` is validated against this shape. Unknown keys are rejected.
| Field | Type | Required | Description |
| ----------------- | ----- | -------- | ------------------------------------------------------------ |
| `timezone` | `str` | Yes | IANA timezone, e.g. `UTC` |
| `start` | `str` | Yes | Cron expression for when the active window starts |
| `end` | `str` | Yes | Cron expression for when the active window ends |
| `desiredReplicas` | `int` | No | Replicas to run inside the window (default `1`, minimum `1`) |
### `list_deployments`
Lists deployments with optional filtering.
```python theme={null}
import os
from dotenv import load_dotenv
load_dotenv()
from simplismart import Simplismart
client = Simplismart()
deployments = client.list_deployments(
model_repo_id=os.getenv("MODEL_REPO_ID"), # Optional
status="DEPLOYED",
offset=0,
count=20,
)
print(deployments)
```
**Expected output** — list of deployment summary objects:
```json theme={null}
[
{
"deployment_id": "deployment-uuid",
"deployment_name": "speechbrain-v3",
"model_repo_id": "model-repo-uuid",
"model_repo_name": "speechbrain",
"model_type": "unknown",
"accelerator_type": ["nvidia-l40s"],
"accelerator_count": 1,
"status": "DEPLOYED"
}
]
```
#### Deployment Status Options
| Value | Description |
| ---------- | --------------------------- |
| `DEPLOYED` | Deployment is running |
| `PENDING` | Deployment is being created |
| `FAILED` | Deployment failed |
| `STOPPED` | Deployment is stopped |
| `DELETED` | Deployment has been deleted |
### `list_model_deployments`
Lists all model deployments for an organization.
```python theme={null}
deployments = client.list_model_deployments(org_id="org-uuid")
```
### `get_model_deployment`
Gets deployment details by ID. Set `DEPLOYMENT_ID` in env or use an id from `list_deployments`.
```python theme={null}
deployment = client.get_model_deployment(deployment_id=os.getenv("DEPLOYMENT_ID", "deployment-uuid"))
print(deployment)
```
**Expected output** — deployment object with `uuid`, `name`, `status`, `model_repo`, `org`, `autoscale_config`, `healthcheck`, `ports`, `min_pod_replicas`, `max_pod_replicas`, etc.
### `get_deployment`
Get deployment details by ID.
```python theme={null}
deployment = client.get_deployment(deployment_id=os.getenv("DEPLOYMENT_ID", "deployment-uuid"))
```
### `update_deployment`
Updates deployment configuration.
```python theme={null}
updated = client.update_deployment(
deployment_id=os.getenv("DEPLOYMENT_ID", "deployment-uuid"),
payload={
"min_pod_replicas": 1,
"max_pod_replicas": 2,
"autoscale_config": {"targets": [{"metric": "gpu", "target": 80}]},
},
)
```
### `stop_deployment`
Stops a running deployment.
```python theme={null}
result = client.stop_deployment(deployment_id=os.getenv("DEPLOYMENT_ID", "deployment-uuid"))
```
### `start_deployment`
Starts a stopped deployment.
```python theme={null}
result = client.start_deployment(deployment_id=os.getenv("DEPLOYMENT_ID", "deployment-uuid"))
```
### `restart_deployment`
Restarts a deployment.
```python theme={null}
result = client.restart_deployment(
deployment_id=os.getenv("DEPLOYMENT_ID", "deployment-uuid"),
)
```
### `fetch_deployment_health`
Gets deployment health status.
```python theme={null}
health = client.fetch_deployment_health(deployment_id=os.getenv("DEPLOYMENT_ID", "deployment-uuid"))
print(health)
```
**Expected output**
```json theme={null}
{
"data": "Healthy",
"messages": [
{
"message": "Ready to use, the model is running and available for inference.",
"severity": "info"
}
],
"pods": { "ready": 1, "not_ready": 0 }
}
```
### `update_deployment_autoscaling`
Updates the autoscaling configuration of a live deployment.
`cronScaling`, `targets`, `scaleDownBehavior`, and `scaleUpBehavior` are **top-level** fields here — unlike `create_private_deployment` / `update_deployment`, where they nest inside `autoscale_config`. Two rules are enforced client-side **before** the request, so you get a clear `ValueError` instead of a backend `400`:
* `min_replicas=0` is only allowed together with `cron_scaling`.
* `scale_to_zero` and `cron_scaling` cannot both be set.
| Parameter | Type | Description | Required |
| ------------------------- | ----------------------- | --------------------------------------------------------------- | -------- |
| `deployment_id` | `str` | Deployment UUID | Yes |
| `min_replicas` | `int` | Minimum replicas (≥ 0). `0` requires `cron_scaling` | Yes |
| `max_replicas` | `int` | Maximum replicas (≥ 1, ≥ `min_replicas`) | Yes |
| `scale_to_zero` | `bool` | Traffic-based scale-to-zero. Cannot combine with `cron_scaling` | No |
| `cron_scaling` | `list[CronScalingRule]` | Schedule-based scaling windows | No |
| `cooldown_period` | `int` | KEDA cooldown (seconds) | No |
| `initial_cooldown_period` | `int` | KEDA initial cooldown (seconds) | No |
| `targets` | `list[AutoscaleTarget]` | KEDA metric targets (`metric`, `target`, optional `percentile`) | No |
| `scale_up_behavior` | `HPAScalingBehavior` | HPA scale-up behavior | No |
| `scale_down_behavior` | `HPAScalingBehavior` | HPA scale-down behavior | No |
```python theme={null}
# Plain min/max replicas
client.update_deployment_autoscaling(
deployment_id=os.getenv("DEPLOYMENT_ID", "deployment-uuid"),
min_replicas=1,
max_replicas=3,
)
# Traffic-based scale-to-zero with a cooldown
client.update_deployment_autoscaling(
deployment_id="",
min_replicas=1, max_replicas=3,
scale_to_zero=True, cooldown_period=30,
)
```
```python theme={null}
from simplismart import (
AutoscaleTarget,
CronScalingRule,
HPAScalingBehavior,
Simplismart,
)
client = Simplismart()
# Cron window — min_replicas=0, run only weekdays 8am–6pm UTC
client.update_deployment_autoscaling(
deployment_id="",
min_replicas=0, max_replicas=2,
cron_scaling=[
CronScalingRule(timezone="UTC", start="0 8 * * 1-5", end="0 18 * * 1-5", desiredReplicas=1)
],
)
# Metric targets + both HPA behaviors
# Scale on p95 latency; ramp up fast (4 pods / 15s), scale down gently (25% / 60s).
client.update_deployment_autoscaling(
deployment_id="",
min_replicas=1, max_replicas=8,
targets=[AutoscaleTarget(metric="latency", target=200, percentile=95)],
scale_up_behavior=HPAScalingBehavior(
stabilizationWindowSeconds=0,
selectPolicy="Max",
policies=[{"type": "Pods", "value": 4, "periodSeconds": 15}],
),
scale_down_behavior=HPAScalingBehavior(
stabilizationWindowSeconds=300,
selectPolicy="Min",
policies=[{"type": "Percent", "value": 25, "periodSeconds": 60}],
),
)
```
`AutoscaleTarget` and `HPAScalingBehavior` / `HPAScalingPolicy` validate locally before the request: `percentile` is only valid for the `latency` metric and must be one of `50, 75, 90, 95`; HPA policy `type` is `Pods` or `Percent`, `value` must be a positive integer (`≤ 100` for `Percent`), `periodSeconds` ∈ `[1, 1800]`, and `stabilizationWindowSeconds` ∈ `[0, 3600]`.
### `delete_deployment`
Deletes a deployment.
```python theme={null}
result = client.delete_deployment(
deployment_id=os.getenv("DEPLOYMENT_ID", "deployment-uuid"),
)
```
***
## Error Handling
The SDK raises `SimplismartError` for all API errors.
```python theme={null}
from simplismart import Simplismart, SimplismartError
client = Simplismart()
try:
deployment = client.get_deployment(deployment_id="00000000-0000-0000-0000-000000000000")
except SimplismartError as e:
print("Status:", e.status_code)
print("Message:", e)
print("Payload:", e.payload)
```
**Expected output** (for invalid or missing deployment):
```
Caught SimplismartError:
status_code: 404
message: No ModelDeployment matches the given query. (status=404)
payload: {'detail': 'No ModelDeployment matches the given query.'}
```
#### SimplismartError Attributes
| Attribute | Type | Description |
| ------------- | ------ | --------------------------- |
| `status_code` | `int` | HTTP status code |
| `payload` | `dict` | Full error response payload |
| `message` | `str` | Error message from backend |
***
## BYOC Deployment
Create a BYOC deployment with a payload (cluster, nodegroup, etc.). See [Bring your own compute](/inference/bring-your-own-compute) and [Deploy on imported cluster](/model-suite/deployments/deploy-on-an-imported-cluster).
`create_byoc_deployment` takes a **raw dict** (no typed model). BYOC scheduling fields such as `nodegroups` and `cluster` are intentionally not part of `DeploymentCreate`.
```python theme={null}
from simplismart import Simplismart
client = Simplismart()
resp = client.create_byoc_deployment({
"model_repo": "",
"org": "",
"name": "my-byoc-deploy",
"min_pod_replicas": 1,
"max_pod_replicas": 1,
"nodegroups": [""],
})
print(resp)
```
# Model Repositories
Source: https://docs.simplismart.ai/sdk/python/model-repos
Manage model repositories using the Simplismart Python SDK
Manage model repositories using the `Simplismart` client methods below (e.g. `client.create_model_repo(...)`).
### `list_model_repos`
Lists model repositories with optional filtering. Run with `SIMPLISMART_PG_TOKEN` set as an environment variable (e.g. in `.env`).
```python theme={null}
import os
from dotenv import load_dotenv
load_dotenv()
from simplismart import ModelRepoListParams, Simplismart
client = Simplismart()
repos = client.list_model_repos(
ModelRepoListParams(
offset=0,
count=5,
status="SUCCESS",
name="vision", # optional filter
model_type="BYOM", # optional filter
created_by="user@example.com", # optional filter
)
)
print(repos)
```
**Expected output**
```json theme={null}
{
"limit": 5,
"offset": 0,
"count": 10,
"results": [
{
"uuid": "model-repo-uuid",
"name": "whisper-nemo-diarization",
"source_type": "docker_hub",
"source_url": "simplismart/MODEL-NAME:latest",
"is_byom": true,
"accelerator": null,
"runtime_gpus": 1,
"byom": {
"image": "simplismart/MODEL-NAME:latest",
"registry": "simplismart/REGISTRY-NAME",
"tag": "latest"
},
"secrets": {
"source_secret": {
"uuid": "secret-uuid",
"name": "SECRET-NAME"
}
},
"status": "SUCCESS",
"model_type": "byom",
"env": {},
"created_at": "2026-03-02T11:52:16.925151Z",
"updated_at": "2026-03-02T11:52:16.925162Z",
"org_id": "org-uuid",
"healthcheck": {
"path": "/health",
"port": 8000,
"periodSeconds": 10,
"timeoutSeconds": 5,
"initialDelaySeconds": 30
},
"ports": { "http": { "port": 8000 } },
"metrics_path": [],
"deployment_custom_configuration": { "command": [] }
}
]
}
```
#### ModelRepoListParams
| Parameter | Type | Description | Options |
| ------------ | ------------- | ---------------------------------- | --------------------------------------------- |
| `offset` | `int` | Pagination offset (default: 0) | ≥ 0 |
| `count` | `int` | Page size (default: 5, max: 20) | 0-20 |
| `model_id` | `str \| None` | Filter by specific model repo UUID | - |
| `name` | `str \| None` | Filter by name (contains match) | - |
| `status` | `str \| None` | Filter by status | `SUCCESS`, `FAILED`, `DELETED`, `PROGRESSING` |
| `model_type` | `str \| None` | Filter by model type | - |
| `created_by` | `str \| None` | Filter by creator email | - |
### `get_model_repo`
Gets a specific model repository by ID. Set `MODEL_REPO_ID` in env, or use a UUID from `list_model_repos`.
```python theme={null}
import os
from dotenv import load_dotenv
load_dotenv()
from simplismart import Simplismart
client = Simplismart()
repo = client.get_model_repo(
model_id=os.getenv("MODEL_REPO_ID", "model-repo-uuid"),
)
print(repo)
```
**Expected output**
```json theme={null}
{
"uuid": "f58265ce-cfc4-4d32-8b4f-848f06c5e181",
"name": "Tp-8-mdhv-llama",
"source_type": "docker_hub",
"source_url": "madhavbohra09/llama-3.2-1b:latest",
"is_byom": true,
"accelerator": null,
"runtime_gpus": 8,
"byom": {
"image": "madhavbohra09/llama-3.2-1b:latest",
"registry": "madhavbohra09/llama-3.2-1b",
"tag": "latest"
},
"secrets": {
"source_secret": {
"uuid": "0b8af8a8-d149-4262-b5b4-804ee6b98311",
"name": "docker creds"
}
},
"status": "SUCCESS",
"model_type": "byom",
"env": {},
"created_at": "2026-03-03T13:14:28.714649Z",
"updated_at": "2026-03-03T13:14:28.714660Z",
"org_id": "0bf00b43-430a-4ca3-a8b3-b13cc8dc6d4f",
"is_public": false,
"healthcheck": {
"path": "/health",
"port": 8000,
"periodSeconds": 10,
"timeoutSeconds": 5,
"initialDelaySeconds": 30
},
"ports": {
"http": {
"port": 8000
}
},
"metrics_path": [],
"deployment_custom_configuration": {
"command": []
}
}
```
### `create_model_repo`
Bring your own container-based models from Docker Hub, Depot or NVIDIA NGC registry. Use enviroment vars for credentials (e.g. `SOURCE_SECRET_ID`); do not hardcode secrets.
```python theme={null}
import os
from dotenv import load_dotenv
load_dotenv()
from simplismart import ModelRepoCreate, Simplismart
client = Simplismart()
repo = client.create_model_repo(
ModelRepoCreate(
name="vision-container-demo",
org_id=os.getenv("ORG_ID"),
source_type="docker_hub",
runtime_gpus=1,
source_secret=os.getenv("SOURCE_SECRET_ID"),
registry_path=os.getenv("REGISTRY_PATH", "your-docker-org/your-model"),
docker_tag=os.getenv("DOCKER_TAG", "latest"),
env={"EXAMPLE_KEY": "value"},
healthcheck={"path": "/", "port": 8000},
ports={"http": {"port": 8000}},
metrics_path=["/v1/chat/completions"],
deployment_custom_configuration={"command": ["python", "-m", "server"]},
)
)
```
For a **public** Docker Hub image, omit `source_secret` entirely (`org_id` is optional too). This is the minimal call to bring up a public container:
```python theme={null}
repo = client.create_model_repo(
ModelRepoCreate(
name="gemma3-vllm",
source_type="docker_hub",
registry_path="ai/gemma3-vllm", # public image: https://hub.docker.com/r/ai/gemma3-vllm
docker_tag="latest",
runtime_gpus=1,
healthcheck={"path": "/health", "port": 8000},
ports={"http": {"port": 8000}},
)
)
```
#### ModelRepoCreate
| Parameter | Type | Description | Required |
| --------------------------------- | ---------------------- | ---------------------------------------------------------------------------------------------------------------------------- | ------------- |
| `name` | `str` | Model repo name (1-255 chars) | Yes |
| `org_id` | `str \| None` | Organization UUID. Optional: inferred from your PG token if omitted. Note: `DeploymentCreate` uses `org` for this same value | No |
| `source_type` | `str` | Registry source type. Options: `docker_hub`, `depot`, `nvidiadockersecret` | Yes |
| `runtime_gpus` | `int` | Number of GPUs (≥ 0; typically 0 or 1 for BYOM) | Yes |
| `source_secret` | `str \| None` | Secret UUID for registry authentication | Conditional\* |
| `registry_path` | `str \| None` | Registry path/repo name (max 255) | Yes |
| `docker_tag` | `str \| None` | Image tag (max 255) | Yes |
| `env` | `dict \| None` | Environment variables | No |
| `healthcheck` | `dict \| None` | Health check configuration | No |
| `ports` | `dict \| None` | Port mappings | No |
| `metrics_path` | `list \| None` | List of metrics paths | No |
| `deployment_custom_configuration` | `dict \| list \| None` | Custom deployment configuration | No |
\*`source_secret` is required for `depot` and `nvidiadockersecret`. Public `docker_hub` images do not need it.
#### Source Type Options
| Value | Description |
| -------------------- | ------------------------------------------------------ |
| `docker_hub` | Docker Hub registry |
| `depot` | Depot registry |
| `nvidiadockersecret` | [NVIDIA NGC registry](https://catalog.ngc.nvidia.com/) |
**Expected output**
```JSON theme={null}
{'uuid': 'e20dd190-b0ed-4db5-a471-a580696b99bd', 'name': 'TEST-vision-container-demo', 'source_type': 'docker_hub', 'source_url': 'madhavbohra09/llama-3.2-1b:latest', 'is_byom': True, 'accelerator': None, 'runtime_gpus': 1, 'byom': {'image': 'madhavbohra09/llama-3.2-1b:latest', 'registry': 'madhavbohra09/llama-3.2-1b', 'tag': 'latest'}, 'secrets': {'source_secret': {'uuid': '0b8af8a8-d149-4262-b5b4-804ee6b98311', 'name': 'docker creds'}}, 'status': 'SUCCESS', 'model_type': 'byom', 'env': {'EXAMPLE_KEY': 'value'}, 'created_at': '2026-03-03T15:34:50.901581Z', 'updated_at': '2026-03-03T15:34:50.901592Z', 'org_id': '0bf00b43-430a-4ca3-a8b3-b13cc8dc6d4f', 'is_public': False, 'healthcheck': {'path': '/', 'port': 8000, 'initialDelaySeconds': 30, 'periodSeconds': 10, 'timeoutSeconds': 5}, 'ports': {'http': {'port': 8000}}, 'metrics_path': [], 'deployment_custom_configuration': {'command': []}}
```
### `create_model_repo_private_compile`
Creates a private compile model repository: the platform compiles the model from a source (e.g. Hugging Face) using your **model config**, **optimisation config**, and **pipeline config**.
```python theme={null}
import json
from simplismart import (
ModelRepoCompileCreate,
Simplismart,
)
client = Simplismart()
# Load configs (e.g. from examples/private-compile-sample/)
def load_json_file(path):
with open(path, "r") as f:
return json.load(f)
repo = client.create_model_repo_private_compile(
ModelRepoCompileCreate(
name="my-llama-repo",
description="Llama model - private compile",
source_type="huggingface",
source_url="meta-llama/Llama-3.2-1B-Instruct",
model_class="LlamaForCausalLM",
accelerator_type="nvidia-h100",
accelerator_count=0,
cloud_account="your-cloud-account-uuid",
model_config_data=load_json_file("model_config.json"),
optimisation_config=load_json_file("optimisation_config.json"),
pipeline_config=load_json_file("pipeline_config.json"),
)
)
```
#### ModelRepoCompileCreate
| Parameter | Type | Description | Required |
| -------------------------------- | -------------- | ------------------------------------------------------------------------------------------------------------------ | -------- |
| `name` | `str` | Model repo name | Yes |
| `source_type` | `str` | Source type, e.g. `huggingface` | Yes |
| `source_url` | `str` | Source path/URL (e.g. HF repo id) | Yes |
| `mode` | `str` | Compilation mode (default: `public_hf`). e.g. `public_hf`, `private_hf`, `aws`, `gcp`, `public_url`, `simplismart` | Yes |
| `model_class` | `str` | Model class (e.g. `LlamaForCausalLM`) | Yes |
| `accelerator_type` | `str` | Accelerator type (e.g. `nvidia-h100`) | Yes |
| `org_id` | `str \| None` | Organization UUID (alias: `org`); optional if inferred from token | No |
| `accelerator_count` | `int \| None` | Accelerator count (default: 0) | No |
| `cloud_account` | `str \| None` | Cloud account UUID | No |
| `source_secret` | `str \| None` | Secret UUID for source access | No |
| `lora_secret` | `str \| None` | LoRA secret UUID | No |
| `model_config_data` | `dict \| None` | Model config JSON (alias: `model_config`); see below | No |
| `optimisation_config` | `dict \| None` | Optimisation config JSON (see below) | No |
| `pipeline_config` | `dict \| None` | Pipeline config JSON (see below) | No |
| `env` | `dict \| None` | Environment variables | No |
| `output_metadata` | `dict \| None` | Output metadata | No |
| `additional_details` | `dict \| None` | Additional details | No |
| `tags` | `dict \| None` | Tags object | No |
| `tasks` | `list \| None` | List of tasks | No |
| `model_family` | `str \| None` | Model family | No |
| `description` | `str \| None` | Description | No |
| `short_description` | `str \| None` | Short description | No |
| `dropdown_description` | `str \| None` | Dropdown description | No |
| `processing_mode` | `str \| None` | One of: `SYNC`, `ASYNC`, `REALTIME_ASYNC` | No |
| `machine_type` | `str \| None` | Machine type | No |
| `region` | `str \| None` | Region | No |
| `resource_group` | `str \| None` | Resource group | No |
| `use_simplismart_infrastructure` | `bool \| None` | Use Simplismart infrastructure | No |
#### Config files (private compile)
Example configs are in the SDK repo under `examples/private-compile-sample/`:
* **[`model_config.json`](https://github.com/simpli-smart/simplismart-python/blob/main/examples/private-compile-sample/model_config.json)** — Model architecture and tokenizer options (e.g. `architectures`, `hidden_size`, `max_position_embeddings`, `torch_dtype`). Must match the model you are compiling.
**Example** (Llama-style):
```json theme={null}
{
"architectures": ["LlamaForCausalLM"],
"hidden_size": 2048,
"intermediate_size": 8192,
"max_position_embeddings": 131072,
"model_type": "llama",
"num_attention_heads": 32,
"num_hidden_layers": 16,
"num_key_value_heads": 8,
"torch_dtype": "bfloat16",
"vocab_size": 128256
}
```
* **[`optimisation_config.json`](https://github.com/simpli-smart/simplismart-python/blob/main/examples/private-compile-sample/optimisation_config.json)** — Backend, warmups, and optimisations (e.g. `quantization`, `tensor_parallel_size`, `optimisations.dit_optimisation`, `backend`).
**Example**
```json theme={null}
{
"model_type": "llm",
"quantization": "float16",
"tensor_parallel_size": 1,
"warmups": { "enabled": true, "iterations": 5, "sample_input_data": [] },
"backend": { "name": "auto", "version": "latest" },
"optimisations": {
"dit_optimisation": {
"enabled": true,
"attention_backend": { "type": "auto" },
"compilation": { "enabled": false, "mode": "auto", "fullgraph": true, "dynamic": true }
}
}
}
```
* **[`pipeline_config.json`](https://github.com/simpli-smart/simplismart-python/blob/main/examples/private-compile-sample/pipeline_config.json)** — Pipeline type and options (e.g. `type`, `loras`, `quantized_model_path`, `enable_model_caching`, `mode`).
```json theme={null}
{
"type": "llm",
"loras": [],
"lora_repo": { "type": "", "path": "", "ownership": "", "secret": { "type": "" } },
"quantized_model_path": { "type": "", "path": "", "ownership": "", "secret": { "type": "" } },
"extra_params": {},
"enable_model_caching": true,
"mode": "chat"
}
```
For a datailed example, checkout this code snippet in Python: Full example: [simplismart-python/examples/private-compile-sample/](https://github.com/simpli-smart/simplismart-python/tree/main/examples/private-compile-sample/private_compile.py).
### `delete_model_repo`
Deletes a model repository.
```python theme={null}
result = client.delete_model_repo(model_id=os.getenv("MODEL_REPO_ID", "model-repo-uuid"))
# Returns: True on success
```
# Overview
Source: https://docs.simplismart.ai/sdk/python/overview
Complete Python SDK reference for Simplismart Platform APIs
The Simplismart Python SDK provides programmatic access to manage model repositories, deployments, and secrets.
## Installation
Install the SDK using pip:
```bash theme={null}
pip install simplismart-sdk
```
## Authentication
The SDK uses Playground (PG) token authentication. You can obtain your token from the Simplismart Playground interface.
1. Open [Simplismart](https://app.simplismart.ai/settings?tab=2) **Settings** → **API Key**.
2. Copy the **Playground Token** and set it as `SIMPLISMART_PG_TOKEN` in your `.env` file or environment.
### Environment Variables
Configure authentication using environment variables:
```bash theme={null}
export SIMPLISMART_PG_TOKEN="your_pg_token_here"
export ORG_ID="your_org_uuid"
export SIMPLISMART_BASE_URL="https://api.app.simplismart.ai" # Optional, default: https://api.app.simplismart.ai
export SIMPLISMART_TIMEOUT="300" # Optional, default: 300 seconds
```
## Client Initialization
```python theme={null}
import os
from dotenv import load_dotenv
load_dotenv()
from simplismart import Simplismart
# Token and optional settings from env: SIMPLISMART_PG_TOKEN, SIMPLISMART_BASE_URL, SIMPLISMART_TIMEOUT
client = Simplismart(
pg_token=os.getenv("SIMPLISMART_PG_TOKEN"),
base_url=os.getenv("SIMPLISMART_BASE_URL", "https://api.app.simplismart.ai"),
timeout=int(os.getenv("SIMPLISMART_TIMEOUT", "300")),
)
```
| Parameter | Type | Description |
| ---------- | ------------- | --------------------------------------------------------------- |
| `pg_token` | `str \| None` | Playground token. Falls back to `SIMPLISMART_PG_TOKEN` env var. |
| `base_url` | `str` | API base URL. Default: `https://api.app.simplismart.ai` |
| `timeout` | `float` | Request timeout in seconds. Default: `300` |
***
## Quickstart Example
This end-to-end example covers the full MLOps lifecycle: compiling a model from Hugging Face, polling until it's ready, creating a deployment, and checking its health.
First of all, set necessary environment variables in your `.env` (see [Environment Variables](#environment-variables)).
```python theme={null}
import os
from dotenv import load_dotenv
from simplismart import Simplismart, ModelRepoCompileCreate, ModelRepoListParams, DeploymentCreate
load_dotenv()
from time import sleep
client = Simplismart(pg_token=os.getenv("SIMPLISMART_PG_TOKEN"))
org_id = os.getenv("ORG_ID")
MODEL_REPO_NAME = "llama-3.2-1b-instruct-SDK"
# model compile
payload = ModelRepoCompileCreate(
name=MODEL_REPO_NAME,
description="llama-model - A model deployed using Simplismart",
source_type="huggingface",
source_url="meta-llama/Llama-3.2-1B-Instruct",
model_class="LlamaForCausalLM",
accelerator_type="nvidia-h100",
use_simplismart_infrastructure=True,
)
data = client.create_model_repo_private_compile(payload)
print(
f"Model compilation initiated: {data['name']} | "
f"uuid={data['uuid']} | status={data['status']} | source={data['source_url']}"
)
# Fetch the compiled model repo and wait until it's ready
list_params = ModelRepoListParams(org_id=org_id, offset=0, count=1, name=MODEL_REPO_NAME)
model_repo_id = None
prev_status = None
while True:
repos = client.list_model_repos(list_params)
result = repos["results"][0]
model_repo_id = result["uuid"]
status = result["status"]
if status != prev_status:
print(f"Model Repo {model_repo_id}: {status}")
prev_status = status
if status == "SUCCESS":
break
sleep(10)
# create deployment
deployment = client.create_deployment(
DeploymentCreate(
org=org_id,
model_repo=model_repo_id,
gpu_id="nvidia-h100",
name="llama-3.2-1b-instruct-SDK", # should be unique
min_pod_replicas=1,
max_pod_replicas=2,
autoscale_config={"targets": [{"metric": "gpu", "target": 80}]},
)
)
deployment_id = deployment["deployment_id"]
model_endpoint = deployment.get("model_endpoint", "")
print(
f"Deployment created: id={deployment_id} \n Name={deployment.get('name')} \n "
f"Model Endpoint=https://{model_endpoint}"
)
deployment_detail = client.get_model_deployment(
deployment_id=os.getenv("DEPLOYMENT_ID", deployment_id)
)
print(f"Status: {deployment_detail.get('status', 'unknown')}")
health = client.fetch_deployment_health(deployment_id=deployment_id)
health_status = health.get("data", "unknown")
if health.get("messages"):
msg = health["messages"][0].get("message", "")
print(f"Health: {health_status} — {msg}")
else:
print(f"Health: {health_status}")
if health_status == "Healthy":
print("Deployment is ready.")
else:
print("Deployment is still in progress.")
```
**Expected Output**
```
Model compilation initiated: llama-3.2-1b-instruct-SDK | uuid=e079d5f9-9fa9-4664-82ce-0218b7d1c220 | status=PENDING | source=meta-llama/Llama-3.2-1B-Instruct
Model Repo e079d5f9-9fa9-4664-82ce-0218b7d1c220: PENDING
Model Repo e079d5f9-9fa9-4664-82ce-0218b7d1c220: LAUNCHING_RAY_CLUSTER
Model Repo e079d5f9-9fa9-4664-82ce-0218b7d1c220: OPTIMISING
Model Repo e079d5f9-9fa9-4664-82ce-0218b7d1c220: SUCCESS
Deployment created: id=0ee77f95-a49a-4965-9aa9-311fa9318c47
Name=llama-3.2-1b-instruct-SDK
Model Endpoint=https://YOUR-ENDPOINT.HERE
Status: DEPLOYING
Health: Progressing — The deployment is progressing. Please wait for the application to be healthy.
Deployment is still in progress.
```
***
## Error Handling
The SDK raises `SimplismartError` for all API errors.
```python theme={null}
from simplismart import Simplismart, SimplismartError
client = Simplismart()
try:
deployment = client.get_deployment(deployment_id="00000000-0000-0000-0000-000000000000")
except SimplismartError as e:
print("Status:", e.status_code)
print("Message:", e)
print("Payload:", e.payload)
```
**Expected output** (for invalid or missing deployment):
```
Caught SimplismartError:
status_code: 404
message: No ModelDeployment matches the given query. (status=404)
payload: {'detail': 'No ModelDeployment matches the given query.'}
```
#### SimplismartError Attributes
| Attribute | Type | Description |
| ------------- | ------ | --------------------------- |
| `status_code` | `int` | HTTP status code |
| `payload` | `dict` | Full error response payload |
| `message` | `str` | Error message from backend |
***
# Secrets
Source: https://docs.simplismart.ai/sdk/python/secrets
Manage Docker registry credentials and other secrets using the Simplismart Python SDK
Manage Docker registry credentials and other secrets.
### `create_secret`
Creates a secret for an organization. The `data` payload depends on `secret_type`:
| `secret_type` | `data` payload |
| --------------- | --------------------------------------------------------------------- |
| **docker\_hub** | `{"username": "...", "token": "..."}` |
| **depot** | `{"username": "...", "token": "..."}` |
| **NVIDIA NIM** | `{"server": "nvcr.io", "username": "$oauthtoken", "password": "..."}` |
Use environment variables for credentials; do not hardcode secrets.
```python theme={null}
import os
from dotenv import load_dotenv
load_dotenv()
from simplismart import SecretCreate, Simplismart
client = Simplismart()
# Docker Hub
secret = client.create_secret(
SecretCreate(
name="registry-secret",
secret_type="docker_hub",
data={
"username": os.getenv("SECRET_DOCKERHUB_USERNAME", "your-username"),
"token": os.getenv("SECRET_DOCKERHUB_TOKEN", "your-token"),
},
)
)
# Depot (same data shape as Docker Hub)
# secret = client.create_secret(
# SecretCreate(name="depot-registry-secret", secret_type="depot", data={...})
# )
# NVIDIA NIM
# secret = client.create_secret(
# SecretCreate(
# name="nvidia-secret",
# secret_type="nvidia_nim",
# data={"server": "nvcr.io", "username": "$oauthtoken", "password": os.getenv("NVIDIA_OAUTH_TOKEN")},
# )
# )
```
#### SecretCreate
| Parameter | Type | Description | Required |
| ------------- | ------ | ------------------------------------------------------------- | -------- |
| `name` | `str` | Secret name (1-255 chars) | Yes |
| `secret_type` | `str` | Secret type. Options: `docker_hub`, `depot`, `nvidia_nim` | Yes |
| `data` | `dict` | Secret data; shape depends on `secret_type` (see table above) | Yes |
### `list_secrets`
Lists secrets for an organization.
```python theme={null}
secrets = client.list_secrets(org_id="org-uuid")
```
**Expected output** — object with `data` array of secret summaries (no credential values):
```json theme={null}
{
"data": [
{
"uuid": "secret-uuid",
"name": "registry-secret",
"secret_type": "docker_hub",
"created_at": "2024-09-12T13:01:55.465292Z",
"updated_at": "2024-09-12T13:01:55.465316Z",
"org": "org-uuid"
}
]
}
```
### `get_secret`
Gets a specific secret by ID. **Note:** The API may return secret data (e.g. credentials); do not log or expose it.
```python theme={null}
secret = client.get_secret(secret_id=os.getenv("SECRET_ID", "secret-uuid"))
print(secret)
```
**Expected output** — structure only; actual `data` payload is sensitive and must not be committed or logged:
```json theme={null}
{
"data": {
"uuid": "secret-uuid",
"name": "registry-secret",
"secret_type": "docker_hub",
"org_id": "org-uuid",
"data": ""
}
}
```
# Sign Up
Source: https://docs.simplismart.ai/signup
Quickly create an account and unlock full access to the Simplismart platform
Visit the [Simplismart platform](https://app.simplismart.ai/) to begin your registration process.
You'll be directed to a Sign in page, where new users can Sign Up.
On the sign-up page, enter your work email address.
We'll send a verification code to this email to ensure account security.
After email verification, you'll be prompted to set up an organization.
Your organization serves as the container for all your:
* AI model deployments
* Clusters and infrastructure
* Team members and collaborators
* Usage metrics and billing
You can create an organization for individual use, your team, or your entire company.
## What's Next?
Once your account is active, you can:
Familiarize yourself with the Simplismart interface and available features
Create API keys to start making inference calls to models
Experiment with pre-deployed models in an interactive environment
Follow our quickstart guide to deploy your first AI model
Need help? Our [support team](mailto:support@simplismart.ai) is available to assist with any questions during the signup process.
# CLIP Model Training
Source: https://docs.simplismart.ai/training-suite/custom-models/clip
Train CLIP models on Simplismart to align images and text, customize embeddings, and build accurate vision–language applications
Follow this guide to train CLIP (Contrastive Language-Image Pre-training) models to align visual and textual representations for your specific use cases.
## Prerequisites
Before starting, ensure you have:
* A Simplismart account
* Dataset formatted according to the [CLIP training requirements](#dataset-format)
## Supported Model Architectures
Simplismart currently supports the following CLIP model configurations:
| Component | Model | HuggingFace Link |
| -------------------- | ---------------------------- | ---------------------------------------------------------------------------- |
| **Vision Encoder** | openai/clip-vit-base-patch32 | [clip-vit-base-patch32](https://huggingface.co/openai/clip-vit-base-patch32) |
| **Language Encoder** | FacebookAI/roberta-base | [roberta-base](https://huggingface.co/FacebookAI/roberta-base) |
CLIP training on Simplismart uses **full fine-tuning** and runs on a **single GPU**. Distributed training and LoRA are not currently supported.
## Dataset Preparation
Your dataset must be in **JSONL format** where each line contains an image path and corresponding captions.
**Example JSONL Entry:**
```json theme={null}
{
"image": "images/airport_1.jpg",
"captions": [
"Many aircraft are parked next to a long building in an airport.",
"many planes are parked next to a long building in an airport."
]
}
```
**Field Descriptions**
* **`image`**: Relative path to the image file within your ZIP archive
* **`captions`**: Array of text descriptions for the image (2-5 captions recommended)
### Example JSONL File
```json theme={null}
{"image": "images/airport_1.jpg", "captions": ["Many aircraft are parked next to a long building in an airport.", "Planes parked at the airport terminal."]}
{"image": "images/beach_scene.jpg", "captions": ["A sandy beach with blue ocean waves.", "People enjoying a sunny day at the seaside."]}
{"image": "images/city_street.jpg", "captions": ["Busy urban street with cars and pedestrians.", "Downtown city traffic during rush hour."]}
```
### Dataset Format
1. Organize your files in a directory:
```
dataset/
├── images/
│ ├── airport_1.jpg
│ ├── beach_scene.jpg
│ └── city_street.jpg
└── metadata.jsonl
```
2. Create a ZIP archive:
```bash theme={null}
cd /path/to/dataset
zip -r dataset.zip .
```
Ensure all image paths in your JSONL file match the relative paths within the ZIP archive.
## Creating a Training Job
To create a new training job, navigate to `My Trainings` > `LLM/VLM Model` > `Add a Training Job`
Provide the following details:
1. **Experiment Name**: Enter a descriptive name for your training experiment
2. **Model Details**:
* **Base Model** – Select the base model you want to fine-tune. Supported models (e.g., FacebookAI/roberta-base) are available in the dropdown.
* **Source Type** – Automatically filled based on the selected model source (e.g., Hugging Face).
* **Model Type** – Defines the architecture type for training. (here CLIP)
* **Vision Encoder** – Select the vision encoder used for CLIP-based training (e.g. `openai/clip-vit-base-patch32`).
When a base model is selected, the rest of the parameters get updated automatically with recommended defaults for that model and training type.
You can either create a new dataset or select an existing one.
**Create New Dataset**
* **Source** – Choose the dataset source (e.g., AWS S3, GCP).
* **Dataset Name** – Provide a friendly name for your dataset.
* **Dataset Path** – Specify the full path to your dataset (e.g., `s3://bucket/file.zip`).
* **Dataset Description** – Optional field for describing your dataset.
* **Secret** – If AWS/GCP source, select the AWS/GCP credential secret required to access private buckets.
* **Region** – If AWS/GCP source, choose the AWS/GCP region where your bucket is located.
* **Dataset Type** – Specify the data format, such as **JSONL**.
**Select Existing Dataset**
You can reuse a previously uploaded dataset instead of creating a new one.
1. In the **Dataset Details** section, select **Use Existing Dataset**.
2. A dropdown will appear listing all datasets available under your organization.
3. Choose the dataset you want to attach to this training job.
4. Once selected, key information such as **Dataset Name**, **Source**, **Path**, and **Region** will auto-populate based on the saved configuration.
5. Review the prefilled values to ensure the dataset is still valid and accessible.
6. After selection, proceed to configure **Dataset Configuration** parameters.
* **Lazy Tokenize** – If enabled, tokenization happens during training to reduce load time.
* **Prompt Max Length** – Sets the maximum token length per sample (default: 128 for CLIP).
* **System Prompt** – Optional static prompt prepended to every sample.
* **Prompt Template** – Optional templating format for structured prompt creation.
* **Split Type** – Defines how the dataset is split. Currently, only "random" is supported.
* **Train Split Ratio** – Specifies how much data to use for training (default: 0.9).
* **Validation Split Ratio** – Remaining portion used for validation (default: 0.1).
* **Infrastructure Type** – Choose where the training job runs: Simplismart-managed infrastructure, your own compute, or a standalone cluster.
* **GPU Type** – Select the GPU type (e.g., H100, A100, L40).
* **Node Count** – Specify the number of nodes to allocate. (default 1 for CLIP training)
* **GPU Count per Node** – Define the number of GPUs per node. (default 1 for CLIP training)
Configure your training parameters based on your use case:
| Parameter | Description | Default Value / Example |
| ------------------------------ | ----------------------------------------------------- | ------------------------------ |
| Training Type | Auto-selected based on the chosen model (e.g., CLIP). | CLIP |
| Torch Dtype | Precision type used during training. | bfloat16 |
| Num Epochs | Number of epochs to train for. | |
| Train Batch Size | Batch size per device during training. | 8 |
| Eval Batch Size | Batch size per device during evaluation. | 1 |
| Save Steps | Defines how often model checkpoints are saved. | 100 |
| Save Total Limit | Sets how many checkpoints to retain. | 2 |
| Eval Steps | Determines how frequently evaluations are run. | 100 |
| Logging Steps | Frequency at which logs are recorded. | 5 |
| Learning Rate | Sets the learning rate for the optimizer. | 0.00001 |
| Dataloader Num Workers | Number of parallel workers for loading data. | 1 |
| Distributed Configuration Type | Defines training mode. | Single (for the CLIP training) |
1. Review all settings carefully
2. Click `Create Job` to start training
3. Monitor training progress in the `My Trainings` > `Your Training Job` > `Metrics` tab.
Metrics are updated in real-time as your training progresses. Use these metrics to evaluate whether your model is learning effectively.
## Next Steps
Once training completes successfully, you can [compile and deploy](/training-suite/deploy-fine-tuned-model) your CLIP model for inference.
# Encoder Model Training
Source: https://docs.simplismart.ai/training-suite/custom-models/encoder
Train encoder models on Simplismart for sequence classification tasks, enabling efficient feature extraction and accurate prediction from textual data.
Encoder models are ideal for tasks like sentiment analysis, spam detection, intent classification, and other text categorization problems.
## Prerequisites
Before starting, ensure you have:
* Dataset formatted according to the [Encoder training requirements](#dataset-preparation)
## Supported Model Architectures
Simplismart supports training for the following encoder-only transformer architectures:
* [**BERT**](https://huggingface.co/google-bert/bert-base-uncased) (Bidirectional Encoder Representations from Transformers)
* [**RoBERTa**](https://huggingface.co/FacebookAI/roberta-base) (Robustly Optimized BERT Pretraining Approach)
* [**DeBERTa**](https://huggingface.co/microsoft/deberta-v3-base) (Decoding-enhanced BERT with Disentangled Attention)
* [**DistilBERT**](https://huggingface.co/distilbert/distilbert-base-uncased) (Distilled version of BERT)
## Dataset Preparation
Your dataset must be in **JSONL format**, where each line contains the input text and its corresponding label for text classification.
**Example JSONL Entry:**
```json theme={null}
{
"messages": [
{
"role": "user",
"content": "The weather is really nice today"
}
],
"label": 1
}
{
"messages": [
{
"role": "user",
"content": "Today is really unlucky"
}
],
"label": 0
}
```
**Field Descriptions:**
* **`messages`** – Array containing the input text for classification. Each message has a `role` and `content`.
* **`role`** – Indicates the message source. Use `"user"` for encoder model training.
* **`content`** – The text sequence to be classified (e.g., product review, customer query, email content).
* **`label`** – Integer representing the target class (e.g., `0` for negative sentiment, `1` for positive sentiment).
### Example JSONL File
Here's a complete example for sentiment analysis (binary classification with 2 labels):
```json theme={null}
{"messages": [{"role": "user", "content": "The weather is really nice today"}], "label": 1}
{"messages": [{"role": "user", "content": "Today is really unlucky"}], "label": 0}
{"messages": [{"role": "user", "content": "So happy"}], "label": 1}
{"messages": [{"role": "user", "content": "This product is terrible"}], "label": 0}
{"messages": [{"role": "user", "content": "Excellent service and quality"}], "label": 1}
```
**Label Guidelines:**
* Labels must be integers starting from `0`
* For binary classification: use `0` and `1`
* For multi-class: use `0`, `1`, `2`, etc. (e.g., 5 classes = labels 0-4)
* Ensure all labels in your dataset are represented in the training data
## Creating a Training Job
To create a new training job, navigate to `My Trainings` > `LLM/VLM Model` > `Add a Training Job`
Provide the following details:
1. **Experiment Name**: Enter a descriptive name for your training experiment
2. **Model Details**:
* **Base Model** – Select the base model you want to fine-tune. Supported models (e.g., `FacebookAI/roberta-base`) are available in the dropdown.
* **Source Type** – Automatically filled based on the selected model source (e.g., `Hugging Face`).
* **Model Type** – Defines the architecture type for training. (here `Encoder`)
When the base model is selected, the rest of the parameters get updated automatically with recommended defaults for that model and training type.
You can either create a new dataset or select an existing one.
**Create New Dataset**
* **Source** – Choose the dataset source (e.g., AWS S3, GCP).
* **Dataset Name** – Provide a friendly name for your dataset.
* **Dataset Path** – Specify the full path to your dataset (e.g., `s3://bucket/file.jsonl`).
* **Dataset Description** – Optional field for describing your dataset.
* **Secret** – If AWS/GCP source, select the credential secret required to access private buckets. Learn how to [configure cloud credentials](/model-suite/integrations/secrets).
* **Region** – If AWS/GCP source, choose the region where your bucket is located.
* **Dataset Type** – Specify the data format, such as **JSONL**.
**Select Existing Dataset**
You can reuse a previously uploaded dataset instead of creating a new one.
1. In the **Dataset Details** section, select **Use Existing Dataset**.
2. A dropdown will appear listing all datasets available under your organization.
3. Choose the dataset you want to attach to this training job.
4. Once selected, key information such as **Dataset Name**, **Source**, **Path**, and **Region** will auto-populate based on the saved configuration.
5. Review the prefilled values to ensure the dataset is still valid and accessible.
6. After selection, proceed to configure **Dataset Configuration** parameters.
Configure how your dataset will be processed and split for training:
* **Lazy Tokenize** – Tokenizes text during training rather than upfront, reducing memory usage and initial load time.
* **System Prompt** – Optional instruction prepended to each input sequence (e.g., "Classify the sentiment of the following text:").
* **Prompt Template** – Template for formatting inputs consistently (supports variables like `{content}`).
* **Split Type** – Method for dividing data into train/validation sets. Currently supports `random` splitting.
* **Train Split Ratio** – Proportion of data used for training (default: `0.9` or 90%).
* **Validation Split Ratio** – Proportion reserved for validation to monitor overfitting (default: `0.1` or 10%).
Select the compute resources for your training job:
* **Infrastructure Type** – Choose where to run training:
* **Simplismart Cloud** – Fully managed infrastructure
* [**Bring Your Own Compute**](/inference/bring-your-own-compute) – Use your own cloud resources
* **Imported Cluster** – Use a pre-configured standalone cluster
* **GPU Type** – Select GPU hardware based on your performance needs
* **Node Count** – Number of machines to use
* **GPU Count per Node** – GPUs per machine
Configure your training parameters based on your use case. The configuration is organized into several sections:
### Basic Training Configuration
| Parameter | Description | Default Value |
| ------------- | ----------------------------------------------------------------------------------------- | ------------- |
| Training Type | Training methodology. Auto-selected as `SFT` (Supervised Fine-Tuning) for encoder models. | SFT |
| Torch Dtype | Numerical precision for model weights and activations. `bfloat16` or `float32` | bfloat16 |
| Adapter Type | Parameter-efficient fine-tuning method. `LoRA` or `Full` (full finetuning) | LoRA |
### Tuner Configuration
| Parameter | Description | Default Value |
| ------------- | ------------------------------------------------------------------------------------------------------- | ------------- |
| Tuner Backend | Framework for parameter-efficient fine-tuning. `PEFT` (Parameter-Efficient Fine-Tuning) is recommended. | PEFT |
### Extra Parameters
| Parameter | Description | Default Value |
| ------------------------ | ---------------------------------------------------------------------------------------------------------------------- | ----------------------- |
| Task Type | Defines the model's objective. For encoder training, use `Sequence Classification`. | Sequence Classification |
| Number of Labels | Total number of classes in your dataset (e.g., `2` for binary classification, `5` for 5-class). | - |
| Loss Function File | S3 path to a custom loss function file (e.g., `s3://bucket/loss_function.py`). Must expose `loss_fn_adapter` variable. | - |
| New Special Tokens | Comma-separated list of special tokens to add to the tokenizer | - |
| Normalize Special Tokens | Whether to aggregate embeddings of compound special tokens from their constituent tokens. | False |
| Weighted Attention | Uses attention pooling to create a weighted representation of input tokens instead of relying on the \[CLS] token. | False |
**Special Token Initialization:**
Normalisation of embedding is only performed when `Normalize Special Tokens` is True.
When using compound special tokens (e.g., `<|high_amount|>`), their embeddings can be initialized from constituent tokens (`<|high|>` and `<|amount|>`) by taking the normalized mean of the constituent embeddings. This helps the model understand the semantic relationship between tokens.
**Example:**
If you add tokens `<|high|>`, `<|amount|>`, and `<|high_amount|>`, the embedding for `<|high_amount|>` will be:
`embedding(<|high_amount|>) = (embedding(<|high|>) + embedding(<|amount|>)) / 2`
```python theme={null}
from torch import nn, Tensor
import torch
import os
import torch.nn.functional as F
def my_custom_loss_func(outputs, labels, num_items_in_batch=None, **kwargs) -> torch.Tensor:
logits = outputs.logits if hasattr(outputs, 'logits') else outputs
shift_logits = logits[..., :-1, : ].contiguous()
shift_labels = labels[..., 1:].contiguous()
ce_loss = F.cross_entropy(
shift_logits.view(-1, shift_logits.size(-1)),
shift_labels.view(-1),
reduction='none'
)
gamma = float(os.environ.get('FOCAL_LOSS_GAMMA', '2.0'))
alpha = float(os.environ.get('FOCAL_LOSS_ALPHA', '0.25'))
pt = torch.exp(-ce_loss)
focal_weight = alpha * (1 - pt) ** gamma
focal_loss = focal_weight * ce_loss
mask = (shift_labels. view(-1) != -100)
focal_loss = focal_loss[mask]
if num_items_in_batch is None:
num_items_in_batch = mask.sum()
return focal_loss.sum() / num_items_in_batch
loss_fn_adapter = my_custom_loss_func
```
The custom loss function must expose a variable named `loss_fn_adapter` (a Callable) with the signature shown above. The function receives model outputs, labels, and optionally the number of items in batch, and must return a scalar loss tensor.
Weighted attention pooling computes a learned attention score for each token in the sequence, creating a weighted representation that focuses on the most informative tokens. This approach can be more effective than relying solely on the \[CLS] token for sequence classification tasks.
#### How it works:
1. Each token's contextual embedding from the encoder is scored using a learned linear layer
2. Scores are normalized across the sequence using softmax
3. A weighted sum of token embeddings is computed based on these attention weights
4. The pooled representation is passed to the classification head
Here is an example implementation:
```python theme={null}
import torch
import torch.nn as nn
import torch.nn.functional as F
from transformers import (
BertPreTrainedModel,
BertModel
)
from transformers.modeling_outputs import SequenceClassifierOutputWithPast
class BertWeightedPoolForSequenceClassification(BertPreTrainedModel):
def __init__(self, config):
super().__init__(config)
self.num_labels = config.num_labels
hidden = config.hidden_size
self.eps = 1e-9
# Encoder
self.bert = BertModel(config)
# Attention pooling
self.scorer = nn.Linear(hidden, 1)
self.log_temp = nn.Parameter(torch.tensor(0.0))
self.dropout = nn.Dropout(config.hidden_dropout_prob)
self.classifier = nn.Linear(hidden, self.num_labels)
# HF required
self.post_init()
# Debug hook
self.last_attn_weights = None
def forward(
self,
input_ids=None,
attention_mask=None,
token_type_ids=None,
labels=None,
**kwargs
):
outputs = self.bert(
input_ids,
attention_mask=attention_mask,
token_type_ids=token_type_ids,
return_dict=True,
)
hidden_states = outputs.last_hidden_state # (B, T, H)
# Token scoring
scores = self.scorer(hidden_states).squeeze(-1) # (B, T)
temp = torch.exp(self.log_temp)
scores = scores / (temp + self.eps)
# Mask padding
mask = attention_mask.to(scores.dtype)
scores = scores.masked_fill(mask == 0, -1e9)
# Stable softmax
attn_weights = F.softmax(scores.float(), dim=1).to(scores.dtype)
attn_weights = attn_weights * mask
attn_weights = attn_weights / (attn_weights.sum(dim=1, keepdim=True) + self.eps)
self.last_attn_weights = attn_weights.detach()
# Weighted pooling
pooled = torch.bmm(
attn_weights.unsqueeze(1),
hidden_states
).squeeze(1)
pooled = self.dropout(pooled)
logits = self.classifier(pooled)
loss = None
if labels is not None:
loss = F.cross_entropy(logits, labels)
return SequenceClassifierOutputWithPast(
loss=loss,
logits=logits,
hidden_states=outputs.hidden_states,
attentions=None,
)
```
### Hyperparameters
| Parameter | Description | Default Value |
| ---------------------- | ---------------------------------------------------------------------------------------- | ------------- |
| Num Epochs | Number of complete passes through the training dataset. | 1 |
| Train Batch Size | Number of samples processed together per GPU during training. | 8 |
| Eval Batch Size | Batch size during validation. | 8 |
| Save Steps | Checkpoint frequency. Model is saved every N training steps for recovery and evaluation. | 100 |
| Save Total Limit | Maximum checkpoints to keep. Older checkpoints are deleted to save storage. | 2 |
| Eval Steps | Validation frequency. Model performance is evaluated on validation set every N steps. | 100 |
| Logging Steps | How often metrics (loss, accuracy) are recorded to tracking systems | 5 |
| Learning Rate | Initial learning rate for optimizer | 0.00001 |
| Dataloader Num Workers | Parallel data-loading threads per device | 1 |
### Adapter Configuration
Configure fine-tuning parameters based on your selected **Adapter Type** (LoRA or Full). Different parameters apply depending on your choice. Learn more about [adapter configuration](/training-suite/llms/training-new#lora-adapter-configuration).
| Parameter | Description | Default Value | Applies To |
| --------- | --------------------------------------------------------------------------------------------------------- | ------------- | ----------- |
| Rank (r) | Adapter rank determines capacity. Higher rank = more expressive but slower. 16-64 works for most tasks. | 16 | LoRA only |
| Alpha | Scaling factor for adapter updates. Typically set equal to rank. Higher alpha = stronger influence. | 16 | LoRA only |
| Dropout | Regularization to prevent overfitting. Randomly drops adapter weights during training. | 0.1 | LoRA & Full |
| Targets | Which model layers to fine-tune. `all-linear` targets all linear/attention layers for maximum adaptation. | all-linear | LoRA & Full |
### Distributed Configuration
Configures multi-GPU or multi-node training for large-scale training.
| Parameter | Description | Default Value |
| --------- | ------------------------------------------------------------------------------------------------------- | -------------- |
| Type | Distributed training framework. `DeepSpeed` enables memory-efficient training across GPUs. | DeepSpeed |
| Strategy | Memory optimization strategy. `zero3_offload` splits model states across GPUs and CPU for large models. | zero3\_offload |
1. Review all settings carefully
2. Click `Create Job` to start training
3. Monitor training progress in the `My Trainings` > `Your Training Job` > `Metrics` tab.
## Deployment and Inference
Once training completes successfully, you can [compile and deploy](/training-suite/deploy-fine-tuned-model) your Encoder model for inference.
During model compilation, if your usecase is text-classification please add a field under `extra_params` adding `"task": "text-classification"`.
Sharing below, a sample `Pipeline Configuration` for your reference. By default, it takes `fill-mask` as a task.
```python theme={null}
{
"mode": "chat",
"type": "llm",
"loras": [],
"is_lora": true,
"lora_repo": {
"path": "",
"type": "",
"secret": {
"type": ""
},
"ownership": ""
},
"extra_params": {
"task": "text-classification"
},
"load_lora_dynamic": false,
"enable_model_caching": true,
"quantized_model_path": {
"path": "",
"type": "",
"secret": {
"type": ""
},
"ownership": ""
}
}
```
For encoder models, once deployed, you can run inferences using the example given below. Your request payload and expected output will change according to your use-case.
### **Text Classification Example**
```python theme={null}
import requests
url = "YOUR_MODEL_ENDPOINT"
data = {
"text": "The capital of France is Paris"
}
headers = {
"Authorization": "Bearer "
}
response = requests.post(url, json=data, headers=headers)
print(response.json())
```
**Expected Output:**
```bash theme={null}
[{'label': 'LABEL_1', 'score': 0.5462469458580017}]
```
### **Fill Mask Example**
You can refer to the HuggingFace page of the respective model for more information about the``token.
```python theme={null}
import requests
url = "YOUR_MODEL_ENDPOINT"
data = {
"text": "The capital of France is [MASK]."
}
headers = {
"Authorization": "Bearer "
}
response = requests.post(url, json=data, headers=headers)
print(response.json())
```
For RoBERTa base model replace `[MASK]` with ``
**Expected Output**
```python theme={null}
[
{'score': 0.9036276936531067, 'token': 2201, 'token_str': ' Paris', 'sequence': 'The capital of France is Paris.'
},
{'score': 0.08029197156429291, 'token': 12790, 'token_str': ' Lyon', 'sequence': 'The capital of France is Lyon.'
},
{'score': 0.004803310614079237, 'token': 16911, 'token_str': ' Nice', 'sequence': 'The capital of France is Nice.'
},
{'score': 0.002099075587466359, 'token': 8239, 'token_str': ' Nancy', 'sequence': 'The capital of France is Nancy.'
},
{'score': 0.0011299046454951167, 'token': 35767, 'token_str': ' Napoleon', 'sequence': 'The capital of France is Napoleon.'
}
]
```
# Sequence Classification
Source: https://docs.simplismart.ai/training-suite/custom-models/seq-dataset-prep
Sequence classification dataset preparation
Your dataset must be in **JSONL format**, where each line contains the input text and its corresponding label for text classification.
**Example JSONL Entry:**
```json theme={null}
{
"messages": [
{
"role": "user",
"content": "The weather is really nice today"
}
],
"label": 1
}
{
"messages": [
{
"role": "user",
"content": "Today is really unlucky"
}
],
"label": 0
}
```
**Field Descriptions:**
* **`messages`** – Array containing the input text for classification. Each message has a `role` and `content`.
* **`role`** – Indicates the message source. Use `"user"` for encoder model training.
* **`content`** – The text sequence to be classified (e.g., product review, customer query, email content).
* **`label`** – Integer representing the target class (e.g., `0` for negative sentiment, `1` for positive sentiment).
### Example JSONL File
Here's a complete example for sentiment analysis (binary classification with 2 labels):
```json theme={null}
{"messages": [{"role": "user", "content": "The weather is really nice today"}], "label": 1}
{"messages": [{"role": "user", "content": "Today is really unlucky"}], "label": 0}
{"messages": [{"role": "user", "content": "So happy"}], "label": 1}
{"messages": [{"role": "user", "content": "This product is terrible"}], "label": 0}
{"messages": [{"role": "user", "content": "Excellent service and quality"}], "label": 1}
```
**Label Guidelines:**
* Labels must be integers starting from `0`
* For binary classification: use `0` and `1`
* For multi-class: use `0`, `1`, `2`, etc. (e.g., 5 classes = labels 0-4)
* Ensure all labels in your dataset are represented in the training data
# Deploy Fine-Tuned model
Source: https://docs.simplismart.ai/training-suite/deploy-fine-tuned-model
After training the model, you can deploy the LoRA Model with Simplismart
To deploy your fine-tuned model, follow the detailed steps outlined below, which guide you through the process of optimizing, configuring, and completing the deployment to make your model ready for use.
### **Merge with Base Model**
Click on **Compile** to merge the LoRA adapter back into the base model, creating a fine-tuned model. This step will take you to the [**Add Model**](/model-suite/optimise-a-model) page. Follow the next steps to create an optimised version of the model ready to be deployed via the Simplismart Model Suite.
***
### **Optimize the Fine-Tuned Model**
While compiling the LoRA with the base model, you will have the option to optimize the model for deployment.
***
### **Enter Model Details**
Provide the name for your fine-tuned model.
***
### **Select Optimizing Infrastructure**
Choose the right optimization infrastructure for the model based on the size of the base model, specifically the GPU RAM required to run the model for a given quantization.
For example, a **Llama 3.1 8B** model can run on a **T4 GPU** with a **4-bit quantization** but may run into **CUDA OOM errors** with an **FP16 quantization**.
***
### **Update Optimization Configuration**
Modify the optimization settings as needed, and select the desired quantization for your optimised model. If unsure about the rest of the optimization configuration, leave it at the default values.
Please refrain from changing the **model configuration** in this step.
***
### **Add the Model**
Click **Add Model** to save your fine-tuned model to the [**My Models**](https://app.simplismart.ai/my-models) section.
***
### **Deploy the Model**
Once the model has been successfully optimised and saved to your repository, you can deploy it via the Simplismart Model Suite. You can refer to the deployment steps [here](/model-suite/deployments/creating-a-deployment).
# ECD Training Suite
Source: https://docs.simplismart.ai/training-suite/ecd/create-ecd-training
Step-by-step guide to training and deploying an Encoder-Combiner-Decoder (ECD) model on Simplismart
Learn how to create and deploy a custom Encoder-Combiner-Decoder (ECD) model on Simplismart. This guide covers the complete workflow from initiating a training job to deploying your trained model.
ECD models are particularly effective for tabular data and feature engineering tasks, using the TabNet architecture for superior performance on structured datasets.
## Prerequisites
Before starting, ensure you have:
* A Simplismart account with access to the Training Suite
* A publicly accessible dataset URL
* Your training configuration prepared ([configuration schema](./ecd-training-config-schema))
## Creating a Training Job
1. Navigate to **My Trainings** from the left sidebar
2. Click **Add a Training Job**
3. Select **ECD** as the model type from the available options
Provide the following details:
1. **Experiment Name**: Enter a descriptive name for your training experiment
2. **Dataset URL**: Provide the publicly accessible URL to your dataset
3. **Training Configuration**: Add your ECD model configuration
See the [ECD Model Configuration Schema](./ecd-training-config-schema) section for detailed configuration options and examples.
4. Review all settings and click **Create Job** to start training
Once submitted, your training job will begin processing. You can:
* Monitor training progress in real-time
* View training metrics and logs
* Track loss curves and validation performance
When training completes successfully, you'll see a **Compile** button.
## Compiling Your Trained Model
After training completes, compile your model to prepare it for deployment.
1. Click the **Compile** button on your completed training job
2. You'll be redirected to the model compilation page
3. The page shows your model ready to be added to `My Models`
Provide the following information:
1. **Model Name**: Enter a descriptive name for your compiled model
2. **Infrastructure**: Choose your deployment infrastructure:
* **Simplismart Cloud**: Deploy on Simplismart's managed infrastructure
* **Your Own Cloud**: Use your own infrastructure ([BYOC guide](/inference/bring-your-own-compute))
Most configuration options will be auto-populated based on your model class. Review them before proceeding.
3. Click **Add Model** to proceed with **Model Compilation**.
## Deploying Your ECD Model
Once your model is compiled, click on `Deploy Model` button from the top right corner on the model page.
Go to Set up your deployment with these parameters:
### Basic Details
* **Deployment Name**: Choose a unique, descriptive name
* **Model**: Auto-populated with your compiled model
* **Cloud**: Select your infrastructure (Simplismart Cloud or your own)
* **Accelerator Type**: Choose the GPU type for inference\\
Configure auto-scaling to handle variable workloads:
### Scaling Range
* **Minimum**: 1 instance
* **Maximum**: Up to 8 instances (adjust based on your needs)
### Scaling Metrics
Add metrics that trigger scaling actions:
1. **GPU Utilization**: Set threshold at 80% to scale up
2. **CPU Utilization**: Set threshold at 80% for additional scaling control
Click **Add Metrics** to include additional scaling triggers.
Set appropriate thresholds to balance performance and cost. Too low may cause unnecessary scaling; too high may impact response times.
Organize your deployments with tags (optional but recommended):
Example tags:
* Key: `env`, Value: `staging`
* Key: `model-type`, Value: `ecd`
* Key: `version`, Value: `v1.0`
Tags help filter and manage deployments in production environments.
1. Review all configuration settings
2. Click **Add Deployment** to start the deployment process
3. Monitor the deployment status on the right side of the screen
The deployment typically takes a few minutes to complete.
When the status shows **Deployed**, your model is ready to serve inference requests!
Once deployed, you can find your model endpoint:
1. Navigate to **Deployments** in the left sidebar
2. Click on your deployment name
3. In the **Details** tab, find the **Model Endpoint** URL
4. Copy this endpoint to use in your applications
# ECD Model Trainer Configuration Schema
Source: https://docs.simplismart.ai/training-suite/ecd/ecd-training-config-schema
A detailed overview of the ECD model configuration, outlining each field and its purpose
Understanding the ECD model configuration is crucial for training effective models. This section breaks down each component of the configuration.
### Configuration Overview
The ECD model configuration consists of several key components:
```yaml theme={null}
model_type: ecd
input_features: []
output_features: []
combiner: {}
preprocessing: {}
trainer: {}
```
### Input Features
Input features define how your dataset columns are processed. Each feature is a dictionary with three fields:
* **name**: Field name used during model inference
* **type**: Feature type - supports the following types:
* `binary` - Binary features (0/1, True/False)
* `number` - Numerical/continuous features
* `category` - Categorical features
* `bag` - Bag-of-words features
* `set` - Set features (unordered collections)
* `sequence` - Sequence features (ordered lists)
* `text` - Text features (natural language)
* `vector` - Vector features (dense embeddings)
* **column**: Column name in your dataset
```json theme={null}
"input_features": [
{
"name": "device_name",
"type": "category",
"column": "device_name"
},
{
"name": "hour_sin",
"type": "numerical",
"column": "hour_sin"
}
]
```
### Output Features
Output features define your model's prediction targets. You can specify multiple outputs with custom loss functions.
**Supported Output Feature Types:**
* `binary` - Binary classification (0/1, True/False)
* `number` - Regression/numerical predictions
* `category` - Multi-class classification
* `bag` - Bag-of-words predictions
* `set` - Set predictions (unordered collections)
* `sequence` - Sequence predictions (ordered lists)
* `text` - Text generation
* `vector` - Vector predictions (dense embeddings)
#### Example Configuration
```json theme={null}
"output_features": [
{
"loss": {
"type": "binary_weighted_cross_entropy",
"weight": 1,
"class_weights": {
"0": 0.66,
"1": 2
}
},
"name": "target",
"type": "binary",
"column": "target"
}
]
```
#### Loss Configuration
For classification tasks, configure the loss function:
```json theme={null}
"loss": {
"type": "softmax_cross_entropy", // or "binary_weighted_cross_entropy"
"class_weights": null, // or {"0": 0.75, "1": 0.25}
"weight": 1.0
}
```
**Parameters:**
* `class_weights` (default: `null`): Weights for each class. Use `null` for equal weighting
* `weight` (default: `1.0`): Overall loss weight for multi-task learning
### Combiner Configuration
The combiner merges features before making predictions. ECD uses the **TabNet** architecture.
#### Example Configuration
```json theme={null}
"combiner": {
"type": "tabnet",
"size": 64,
"output_size": 64,
"num_steps": 4,
"num_total_blocks": 4,
"num_shared_blocks": 2,
"relaxation_factor": 1.3,
"bn_epsilon": 0.001,
"bn_momentum": 0.98,
"bn_virtual_bs": 128,
"sparsity": 0.001,
"dropout": 0
}
```
#### TabNet Combiner Parameters
* **size** (default: `32`): Hidden layer size (N\_a in TabNet paper)
* **output\_size** (default: `128`): Fully connected layer output size (N\_d in TabNet paper)
* **num\_steps** (default: `3`): Number of attention steps (N\_steps in TabNet paper)
* **num\_total\_blocks** (default: `4`): Total feature transformer blocks per step
* **num\_shared\_blocks** (default: `2`): Shared feature transformer blocks across steps
* **dropout** (default: `0.05`): Dropout rate for transformer blocks
* **sparsity** (default: `0.0001`): Sparsity loss multiplier (lambda\_sparse in TabNet paper)
* **relaxation\_factor** (default: `1.5`): Feature reuse factor (gamma in TabNet paper)
* Value of 1.0 means each feature used once
* Higher values allow multiple feature usages
* **bn\_epsilon** (default: `0.001`): Epsilon added to batch norm denominator
* **bn\_momentum** (default: `0.05`): Batch norm momentum (1 - m\_B from TabNet paper)
* **bn\_virtual\_bs** (default: `128`): Virtual batch size for batch normalization
### Trainer Configuration
Configure the training process with optimization and validation settings.
* **optimizer**: `{"type": "adam"}` - Adam optimizer for gradient descent
* **learning\_rate** (default: `0.001`): Initial learning rate
* **learning\_rate\_scaling** (default: `"sqrt"`): LR scaling strategy
* **decay** (default: `true`): Enable learning rate decay
* **decay\_rate** (default: `0.8`): Rate of learning rate decay
* **decay\_steps** (default: `20000`): Steps between decay applications
* **epochs** (default: `100`): Maximum training epochs
* **batch\_size** (default: `"auto"`): Batch size (auto-calculated or specify manually)
* **early\_stop** (default: `10`): Stop if no improvement for N epochs
* **validation\_field**: Field name to validate on (e.g., `"target"`)
* **validation\_metric**: Metric for validation (e.g., `"roc_auc"`, `"accuracy"`)
* **sample\_ratio**: Ratio of data to sample (e.g., `0.01` for 1%)
* **sample\_size**: Absolute number of samples to use
* **oversample\_minority**: Oversample minority class for imbalanced data
* **undersample\_majority**: Undersample majority class
* **split**: Configure train/validation/test split
* `type`: `"stratify"` to maintain class distributions
* `column`: Column to stratify on
* `probabilities`: Split ratios (e.g., `[0.8, 0.1, 0.1]` for 80/10/10)
## Complete Configuration Example
Here's a complete end-to-end ECD model configuration for a binary classification task:
```json theme={null}
{
"model_type": "ecd",
"infra_type": "gpu",
"trainer": {
"early_stop": 5,
"decay": true,
"batch_size": 512,
"epochs": 50,
"optimizer": {
"type": "adam"
},
"decay_rate": 0.8,
"decay_steps": 20000,
"learning_rate": 0.02,
"validation_field": "target",
"validation_metric": "roc_auc",
"learning_rate_scaling": "sqrt"
},
"preprocessing": {
"sample_ratio": 0.01,
"sample_size": null,
"oversample_minority": null,
"undersample_majority": null,
"global_max_sequence_length": null,
"split": {
"type": "stratify",
"column": "target",
"probabilities": [0.8, 0.1, 0.1]
}
},
"combiner": {
"type": "tabnet",
"size": 64,
"output_size": 64,
"num_steps": 4,
"num_total_blocks": 4,
"num_shared_blocks": 2,
"relaxation_factor": 1.3,
"bn_epsilon": 0.001,
"bn_momentum": 0.98,
"bn_virtual_bs": 128,
"sparsity": 0.001,
"dropout": 0
},
"input_features": [
{
"name": "input_1",
"type": "category",
"column": "input_1"
},
{
"name": "input_2",
"type": "text",
"column": "input_2"
}
],
"output_features": [
{
"name": "target",
"type": "binary",
"column": "target",
"loss": {
"type": "binary_weighted_cross_entropy",
"class_weights": {
"0": 0.66,
"1": 2
},
"weight": 1
}
}
]
}
```
**Quick Start Tips:**
* Start with default parameters for your first training run
* Adjust `class_weights` if you have imbalanced classes
* Increase `num_steps` (3-7) for more complex feature interactions
* Use `early_stop` to prevent overfitting
* Set `sample_ratio` to a small value (0.01) for faster experimentation with large datasets
## Next Steps
After successfully training and deploying your ECD model:
Track your model's inference performance and usage metrics
Evaluate your model's quality and performance against baselines
Learn techniques to improve model latency and throughput
Integrate your deployed model into your applications
# Fine-Tuned Inference
Source: https://docs.simplismart.ai/training-suite/flux/fine-tuned-inference
Run inference with the fine-tuned LoRA
* Once the training job is completed, click on the job to view its details.
* Click on **Run** to start the inference process on the fine-tuned model.
* You will now be redirected to the playground where the LoRA weights will be populated
* Provide the necessary details in the input fields, select your preferred specifications, and proceed to generate the images as required.
Make sure the **Trigger Word** is included in the prompt to apply the **LoRA** effect to the generated image.
# Initiate a New Training Job
Source: https://docs.simplismart.ai/training-suite/flux/initiate-a-new-training-job
Steps to fine-tune a flux model using the Simplismart platform
* Navigate to the **My Trainings** section in the platform.
* Click on **Add a Training Job** to create a new job.
## **Basic Details and Dataset Upload**
* Provide a name for your experiment.
* Upload your training dataset.
1. **Prepare the Training Dataset**
* Compile all the images to be used for training into a single folder.
2. **Text Files for Images (optional)**
* Each image in the training dataset can have an accompanying `.txt` file with the same name.
* The `.txt` file should contain a description detailing what is required in the corresponding image. *This step will significantly enhance the effectiveness of the training process*
3. **Packaging Files in a ZIP**
* All images and their respective `.txt` files must be included in a single ZIP file.
* Ensuring both image and text files are packaged together improves the quality of the training process.
4. **Trigger Word Assignment**
* Assign one unique trigger word per training job.
* This trigger word will be used to reference the LoRA generated by the training job.
Upload the **training dataset** as a file containing the required images for model training. This ensures that all files are placed at the root of the zip archive, with **no subdirectories considered**.
***
## **Select Training Parameters**
Update the training parameters based on your requirements for the training job.
Here is a short explanation of these parameters:
* Specifies a keyword or phrase that activates a specific behaviour in the model during inference. It enables the model to adjust its responses based on the context or task without requiring further training.
* Controls the dimensionality of the LoRA matrices; a higher rank improves adaptation but increases computational cost.
* Defines the number of fine-tuning iterations; more steps improve model performance but increase training time.
* Controls the size of weight updates during fine-tuning. A higher value accelerates training but may risk overshooting, while a lower value offers more precise updates at the cost of longer training time.
* Controls how the model’s parameters are updated during training to minimize loss.
* **AdamW 8-bit:** A variant of the Adam optimizer that leverages 8-bit precision to optimize memory usage and increase computational speed. This approach is ideal for large-scale models enabling quicker convergence while preserving model stability and high performance.
* **Prodigy**:A custom-built optimizer engineered to boost training speed and model efficiency. It accelerates the convergence process and ensures optimal performance, making it suitable for both fine-tuning and large-scale model training.
***
## **Start and Monitor the Training Job**
Once the configuration is updated, start the training job and monitor its progress in the **Recent Jobs** section of the UI. Keep track of metrics, logs, and any intermediate results to ensure the training meets your requirements.
***
# Introduction
Source: https://docs.simplismart.ai/training-suite/introduction
Simplismart's Training Suite is designed to help you fine-tune **GenAI** models for your specific tasks or output formats.
This documentation provides **step-by-step guidance** on leveraging various fine-tuning methods, configuring the trainer to suit your needs, and running multiple experiments for thorough optimization. With extensive configurability options, you can tailor the training process to meet your unique requirements and achieve precise, task-specific model outputs.
Our training suite supports a wide range of Large Language Models (LLMs). Below is the list of the supported LLM models.
##
Our training suite supports a comprehensive selection of Vision Language Models (VLMs).
Flux.1-dev is a 12-billion-parameter rectified flow transformer optimized for generating high-quality images from text prompts.
# DPO (LLM)
Source: https://docs.simplismart.ai/training-suite/llms/dpo-llm
Specifies how to structure conversational data for DPO-based fine-tuning.
## **OpenAI DPO Format** *(for preference training)*
```json theme={null}
{
"messages": [
{"role": "system", "content": "You are a useful and harmless assistant"},
{"role": "user", "content": "Tell me tomorrow's weather"},
{"role": "assistant", "content": "Tomorrow's weather will be sunny"}
],
"rejected_response": "I don't know"
}
```
## Example JSONL File
```json theme={null}
{"messages": [{"role": "...", "content": "..."},], "rejected_response": "..."}
{"messages": [{"role": "...", "content": "..."},], "rejected_response": "..."}
{"messages": [{"role": "...", "content": "..."},], "rejected_response": "..."}
```
### **Message fields**
* `messages:` A list of role-based conversational turns that provide context for the model.
* `content:` The text of each message exchanged between roles in the conversation.
* `rejected_response:` The assistant’s response that is considered less helpful or incorrect for training purposes.
# GRPO (LLM)
Source: https://docs.simplismart.ai/training-suite/llms/grpo-llm
Guidelines for preparing train_dataset entries to fine-tune a LLM with text prompts.
## Directory Structure
```
.
└── dataset_dir/
├── train.jsonl
└── reward_models.py
```
The directory should be archived in a `.zip` file and stored in an object storage. Example zip command:
`cd path/to/dataset_dir && zip -r dataset_dir.zip ./*`
## Dataset Structure
The `train.jsonl` file should be a **list** of JSON-like objects, serialised in `jsonl` format, where each object has exactly three keys:
```json theme={null}
train_dataset = [
{
"prompt": "...",
"answer": "..."
},
]
```
***
## Example JSONL File
```json theme={null}
{"prompt": "...","answer": "..."}
{"prompt": "...","answer": "..."}
{"prompt": "...","answer": "..."}
{"prompt": "...","answer": "..."}
```
***
## **Field Definitions**
| **Key** | **Type** | **Description** |
| ------- | ----------- | -------------------------------------------------- |
| prompt | List\[Dict] | Chat-style prompt: a list of role-tagged messages. |
| answer | str | Ground-truth response. |
***
## **Prompt Format**
Each prompt entry is a list of one or more messages. Minimal single-turn example:
```json theme={null}
[
{
"role": "user",
"content":"When a spring does work on an object, we cannot find the work by simply multiplying the spring force by the object's displacement. … Provide your reasoning between and and then your final answer between and (put a float here) ."
}
]
```
***
## Message fields
* `role`: usually `user` (extend with `assistant` for multi-turn data).
* `content`: `" + "`- Text message from the user or assistant.
***
## **Answer Format**
The expected answer to the question. Example:
```
1.2
```
***
## **Complete Example**
```json theme={null}
train_dataset = [
{
"prompt": [
{
"role": "user",
"content": "When a spring does work on an object, … provide your reasoning between and and then your final answer between and (put a float here) "
}],
"answer": "1.2",
},
]
```
***
## Reward functions
Depending on the dataset structure and task objectives, you may need to define reward functions for model training. These reward functions are accepted by the trainer through a special `reward_models.py` file. This sections outlines (with examples) the standard method for providing custom reward functions.
Users should define their reward functions in a file named `reward_models.py`, which must expose a list named `reward_functions` containing callable functions.
The **reward functions** list is then passed directly to GRPOTrainer like: \
\
`GRPOTrainer(reward_functions=reward_functions, **kwargs)`
***
## Example implementation
```python theme={null}
from your_tags import reasoning_start, reasoning_end, solution_start, solution_end
import re
from typing import Callable, List
def formatting_reward_func(completions, **kwargs) -> List[float]:
"""
Rewards the presence of both reasoning and answer tags in the model's output.
"""
thinking_pattern = f'{reasoning_start}(.*?){reasoning_end}'
answer_pattern = f'{solution_start}(.*?){solution_end}'
scores = []
for completion in completions:
text = completion[0]['content']
score = 0.0
if len(re.findall(thinking_pattern, text, re.DOTALL)) == 1:
score += 1.0
if len(re.findall(answer_pattern, text, re.DOTALL)) == 1:
score += 1.0
scores.append(score)
return scores
def correctness_reward_func(prompts, completions, answer, **kwargs) -> List[float]:
"""
Rewards exact match of the numeric answer within the tags.
"""
answer_pattern = f'{solution_start}(.*?){solution_end}'
responses = [
re.findall(answer_pattern, comp[0]['content'], re.DOTALL)
for comp in completions
]
# Example debug print
q = prompts[0][-1]['content']
a = answer[0]
resp0 = completions[0][0]['content']
print("-"*20, f"Q: {q}\nA: {a}\nR: {resp0}")
return [
2.0 if len(r)==1 and r[0].strip()==str(a) else 0.0
for r in responses
]
reward_functions: List[Callable] = [formatting_reward_func, correctness_reward_func]
```
***
* `formatting_reward_func` checks that `…` and `…` appear exactly once.
* `correctness_reward_func` validates the extracted answer matches the ground truth.
# Sequence Classification Model Training
Source: https://docs.simplismart.ai/training-suite/llms/sequence-classification
Train LLMs on Simplismart for sequence classification tasks, enabling efficient feature extraction and accurate prediction from textual data.
Sequence classification Language models are ideal for tasks like sentiment analysis, spam detection, intent classification, and other text categorization problems.
## Prerequisites
Before starting, ensure you have:
* Dataset formatted according to the [Sequence Classification Training Requirements](/training-suite/custom-models/seq-dataset-prep)
## Supported models
### LLM/VLM Architectures
* `meta-llama/Llama-3.1-8B-Instruct`
* `meta-llama/Llama-3.2-1B-Instruct`
* `meta-llama/Llama-3.2-3B-Instruct`
* `Qwen/Qwen2.5-3B-Instruct`
* `Qwen/Qwen2.5-14B-Instruct`
## Creating a Training Job
To create a new training job, navigate to `My Trainings` > `LLM/VLM Model` > `Add a Training Job`
Provide the following details:
1. **Experiment Name**: Enter a descriptive name for your training experiment
2. **Model Details**:
* **Base Model** – Select the base model you want to fine-tune. Supported models (e.g., `meta-llama/Llama-3.1-8B-Instruct`) are available in the dropdown.
* **Source Type** – Automatically filled based on the selected model source (e.g., `Hugging Face`).
When the base model is selected, the rest of the parameters get updated automatically with recommended defaults for that model and training type.
You can either create a new dataset or select an existing one.
**Create New Dataset**
* **Source** – Choose the dataset source (e.g., AWS S3, GCP).
* **Dataset Name** – Provide a friendly name for your dataset.
* **Dataset Path** – Specify the full path to your dataset (e.g., `s3://bucket/file.jsonl`).
* **Dataset Description** – Optional field for describing your dataset.
* **Secret** – If AWS/GCP source, select the credential secret required to access private buckets. Learn how to [configure cloud credentials](/model-suite/integrations/secrets).
* **Region** – If AWS/GCP source, choose the region where your bucket is located.
* **Dataset Type** – Specify the data format, such as **JSONL**.
**Select Existing Dataset**
You can reuse a previously uploaded dataset instead of creating a new one.
1. In the **Dataset Details** section, select **Use Existing Dataset**.
2. A dropdown will appear listing all datasets available under your organization.
3. Choose the dataset you want to attach to this training job.
4. Once selected, key information such as **Dataset Name**, **Source**, **Path**, and **Region** will auto-populate based on the saved configuration.
5. Review the prefilled values to ensure the dataset is still valid and accessible.
6. After selection, proceed to configure **Dataset Configuration** parameters.
Configure how your dataset will be processed and split for training:
* **Lazy Tokenize** – Tokenizes text during training rather than upfront, reducing memory usage and initial load time.
* **System Prompt** – Optional instruction prepended to each input sequence (e.g., "Classify the sentiment of the following text:").
* **Prompt Template** – Template for formatting inputs consistently (supports variables like `{content}`).
* **Split Type** – Method for dividing data into train/validation sets. Currently supports `random` splitting.
* **Train Split Ratio** – Proportion of data used for training (default: `0.9` or 90%).
* **Validation Split Ratio** – Proportion reserved for validation to monitor overfitting (default: `0.1` or 10%).
Select the compute resources for your training job:
* **Infrastructure Type** – Choose where to run training:
* **Simplismart Cloud** – Fully managed infrastructure
* [**Bring Your Own Compute**](/inference/bring-your-own-compute) – Use your own cloud resources
* **Imported Cluster** – Use a pre-configured standalone cluster
* **GPU Type** – Select GPU hardware based on your performance needs
* **Node Count** – Number of machines to use
* **GPU Count per Node** – GPUs per machine
Configure your training parameters based on your use case. The configuration is organized into several sections:
### Basic Training Configuration
| Parameter | Description | Default Value |
| ------------- | ----------------------------------------------------------------------------------------- | ------------- |
| Training Type | Training methodology. Auto-selected as `SFT` (Supervised Fine-Tuning) for encoder models. | SFT |
| Torch Dtype | Numerical precision for model weights and activations. `bfloat16` or `float32` | bfloat16 |
| Adapter Type | Parameter-efficient fine-tuning method. `LoRA` or `Full` (full finetuning) | LoRA |
### Tuner Configuration
| Parameter | Description | Default Value |
| ---------------- | ------------------------------------------------------------------------------------------------------- | ----------------------- |
| Tuner Backend | Framework for parameter-efficient fine-tuning. `PEFT` (Parameter-Efficient Fine-Tuning) is recommended. | PEFT |
| Task Type | Defines the model's objective. For encoder training, use `Sequence Classification`. | Sequence Classification |
| Number of Labels | Total number of classes in your dataset (e.g., `2` for binary classification, `5` for 5-class). | Required |
#### Extra Parameters for Tuner Backend
For the PEFT backend, these extra parameters needs to be configured, based on your usecase:
**Task Type (for PEFT Training)**
* Casual Language Modeling: For LLM/VLM finetuning jobs
* Sequence Classification: For sequence classification training jobs.
**Number of Labels**
* Total number of classes in your dataset (e.g., `2` for binary classification, `5` for 5-class).
### Hyperparameters
| Parameter | Description | Default Value |
| ---------------------- | ---------------------------------------------------------------------------------------- | ------------- |
| Num Epochs | Number of complete passes through the training dataset. | 1 |
| Train Batch Size | Number of samples processed together per GPU during training. | 8 |
| Eval Batch Size | Batch size during validation. | 8 |
| Save Steps | Checkpoint frequency. Model is saved every N training steps for recovery and evaluation. | 100 |
| Save Total Limit | Maximum checkpoints to keep. Older checkpoints are deleted to save storage. | 2 |
| Eval Steps | Validation frequency. Model performance is evaluated on validation set every N steps. | 100 |
| Logging Steps | How often metrics (loss, accuracy) are recorded to tracking systems | 5 |
| Learning Rate | Initial learning rate for optimizer | 0.00001 |
| Dataloader Num Workers | Parallel data-loading threads per device | 1 |
### Adapter Configuration
Configure fine-tuning parameters based on your selected **Adapter Type** (LoRA or Full). Different parameters apply depending on your choice. Learn more about [adapter configuration](/training-suite/llms/training-new#lora-adapter-configuration).
| Parameter | Description | Default Value | Applies To |
| --------- | --------------------------------------------------------------------------------------------------------- | ------------- | ----------- |
| Rank (r) | Adapter rank determines capacity. Higher rank = more expressive but slower. 16-64 works for most tasks. | 16 | LoRA only |
| Alpha | Scaling factor for adapter updates. Typically set equal to rank. Higher alpha = stronger influence. | 16 | LoRA only |
| Dropout | Regularization to prevent overfitting. Randomly drops adapter weights during training. | 0.1 | LoRA & Full |
| Targets | Which model layers to fine-tune. `all-linear` targets all linear/attention layers for maximum adaptation. | all-linear | LoRA & Full |
### Distributed Configuration
Configures multi-GPU or multi-node training for large-scale training.
| Parameter | Description | Default Value |
| --------- | ------------------------------------------------------------------------------------------------------- | -------------- |
| Type | Distributed training framework. `DeepSpeed` enables memory-efficient training across GPUs. | DeepSpeed |
| Strategy | Memory optimization strategy. `zero3_offload` splits model states across GPUs and CPU for large models. | zero3\_offload |
1. Review all settings carefully
2. Click `Create Job` to start training
3. Monitor training progress in the `My Trainings` > `Your Training Job` > `Metrics` tab.
## Deployment and Inference
Once training completes successfully, you can [compile and deploy](/training-suite/deploy-fine-tuned-model) your finetuned model for inference.
During model compilation, if your usecase is text-classification please add a field under `extra_params` adding `"task": "text-classification"`.
Sharing below, a sample `Pipeline Configuration` for your reference. By default, it takes `fill-mask` as a task.
```python theme={null}
{
"mode": "chat",
"type": "llm",
"loras": [],
"is_lora": true,
"lora_repo": {
"path": "",
"type": "",
"secret": {
"type": ""
},
"ownership": ""
},
"extra_params": {
"task": "text-classification"
},
"load_lora_dynamic": false,
"enable_model_caching": true,
"quantized_model_path": {
"path": "",
"type": "",
"secret": {
"type": ""
},
"ownership": ""
}
}
```
For sequence classification models, once deployed, you can run inferences using the example given below. Your request payload and expected output will change according to your use-case.
### **Text Classification Example**
```python theme={null}
import requests
url = "YOUR_MODEL_ENDPOINT"
data = {
"text": "The capital of France is Paris"
}
headers = {
"Authorization": "Bearer "
}
response = requests.post(url, json=data, headers=headers)
print(response.json())
```
**Expected Output:**
```bash theme={null}
[{'label': 'LABEL_1', 'score': 0.5462469458580017}]
```
### **Fill Mask Example**
You can refer to the HuggingFace page of the respective model for more information about the``token.
```python theme={null}
import requests
url = "YOUR_MODEL_ENDPOINT"
data = {
"text": "The capital of France is [MASK]."
}
headers = {
"Authorization": "Bearer "
}
response = requests.post(url, json=data, headers=headers)
print(response.json())
```
For RoBERTa base model replace `[MASK]` with ``
**Expected Output**
```python theme={null}
[
{'score': 0.9036276936531067, 'token': 2201, 'token_str': ' Paris', 'sequence': 'The capital of France is Paris.'
},
{'score': 0.08029197156429291, 'token': 12790, 'token_str': ' Lyon', 'sequence': 'The capital of France is Lyon.'
},
{'score': 0.004803310614079237, 'token': 16911, 'token_str': ' Nice', 'sequence': 'The capital of France is Nice.'
},
{'score': 0.002099075587466359, 'token': 8239, 'token_str': ' Nancy', 'sequence': 'The capital of France is Nancy.'
},
{'score': 0.0011299046454951167, 'token': 35767, 'token_str': ' Napoleon', 'sequence': 'The capital of France is Napoleon.'
}
]
```
# SFT (LLM)
Source: https://docs.simplismart.ai/training-suite/llms/sft-llm
Provides schema examples for structuring conversations in SFT training.
## **Dataset Format**
Choose the file type for your dataset. Currently supported types are:
* `jsonl` (JSON Lines)
* `zip`The directory should be archived in a `.zip` file and stored in an object storage.\
Example zip command:`cd path/to/dataset_dir && zip -r dataset_dir.zip ./*`
Each line in a`.jsonl`file should represent a complete training example. The supported format styles are:
## **ShareGPT Format**
```json theme={null}
{
"system": "",
"conversation": [
{"human": "", "assistant": ""},
{"human": "", "assistant": ""}
]
}
```
## Example JSONL File
```json theme={null}
{"system": "...", "conversation": ["...."]}
{"system": "...", "conversation": ["...."]}
{"system": "...", "conversation": ["...."]}
```
### **Message fields**
* `system`: The initial system instruction that sets the behavior or tone for the assistant.
* `conversation:` A list of human-assistant message pairs forming the dialogue history.
* `human`: A user query or input in the conversation.
* ` assistant:` The assistant's response to the corresponding human input.
## **OpenAI SFT Format**
```json theme={null}
{
"messages": [
{"role": "system", "content": ""},
{"role": "user", "content": ""},
{"role": "assistant", "content": ""},
{"role": "user", "content": ""},
{"role": "assistant", "content": ""}
]
}
```
## Example JSONL File
```json theme={null}
{"messages": [{"role": "...", "content": "..."},]}
{"messages": [{"role": "...", "content": "..."},]}
{"messages": [{"role": "...", "content": "..."},]}
```
### **Message fields**
* `messages:` A sequential list of role-based messages representing a full conversation.
* `role:` The identity of the message sender (e.g., system, user, assistant).
* `content:` The actual text of the message corresponding to the role.
# Creating a Training Job
Source: https://docs.simplismart.ai/training-suite/llms/training-new
Comprehensive guide of the Simplismart training suite for LLMs and VLMs
This updated guide provides an overview of our enhanced UI for training large language models and vision language models, supporting both **Supervised Fine-Tuning (SFT)** and **Reinforcement Learning with Human Feedback (RLHF)**. For each training type, you can choose between full-model fine-tuning or parameter-efficient approaches like LoRA.
While full-model fine-tuning is fully supported across both **SFT** and **RLHF**, we recommend using **LoRA** for most use cases due to its faster convergence, lower GPU memory usage, and simplified checkpointing.
## **Starting a Training Experiment**
**Experiment Name**: A unique identifier for each training job within your organization.
### Model Details
* **Base Model**: Select a supported model from the list below.
* **Source Type**: Currently supports models from Hugging Face.
* **Model Type**: Auto-filled based on the selected base model.
### **Supported Models**
* `meta-llama/Llama-3.1-8B-Instruct`
* `meta-llama/Llama-3.2-1B-Instruct`
* `meta-llama/Llama-3.2-3B-Instruct`
* `meta-llama/Llama-3.2-11B-Vision-Instruct`
* `Qwen/Qwen2.5-3B-Instruct`
* `Qwen/Qwen2.5-14B-Instruct`
* `Qwen/Qwen2.5-VL-7B-Instruct`
* `tiiuae/falcon-7b-instruct`
* `OpenGVLab/InternVL3_5-14B-HF`
* `OpenGVLab/InternVL3_5-38B-HF`
**Note:**
* If you select **LLM** as the model type for a **VLM** base model, only the language component will be trained.
* To train the vision component, ensure both **base model** and **model type**are set to **VLM**.
## **Dataset Selection**
Configure your dataset for training using the following fields:
* **Source Options**: Select the source of your dataset. Supported options include
* Hugging Face (public Hub)
* AWS S3
* GCP Storage (GCS)
* **Dataset Name**\
This should be unique within your organization to help with organizing and reusing datasets.
* **Dataset Path**\
Specify the dataset location. For AWS S3 & GCP GCS, use the full path in the format.\
`e.g., s3://your-bucket/your-file.jsonl`
* **Dataset Description** *(Optional)*\
Provide a brief description of the dataset’s contents or purpose. Optional but useful for reference.
* **Secret** *(Required for AWS S3 or GCP GCS)*\
Provide your cloud credentials to enable secure access to private storage buckets.
* **Region** *(Required for AWS S3 or GCP GCS)*\
Select the region where your storage bucket is located.
## **Dataset Format**
We support **JSONL** format for all training data.
* For **VLM** models, use a **ZIP file** containing both the image files and a `train.jsonl` file (the master training file).
The directory should be archived in a `.zip` file and stored in an object storage. \
Example zip command:`cd path/to/dataset_dir && zip -r dataset_dir.zip ./*`
Each line in a `.jsonl` file should represent a complete training example. The supported format styles are:
1. **ShareGPT Format**
```json theme={null}
{
"system": "",
"conversation": [
{"human": "", "assistant": ""},
{"human": "", "assistant": ""}
]
}
```
2. **OpenAI SFT Format**
```json theme={null}
{
"messages": [
{"role": "system", "content": ""},
{"role": "user", "content": ""},
{"role": "assistant", "content": ""},
{"role": "user", "content": ""},
{"role": "assistant", "content": ""}
]
}
```
3. **OpenAI DPO Format** *(for preference training)*
```json theme={null}
{
"messages": [
{"role": "system", "content": "You are a useful and harmless assistant"},
{"role": "user", "content": "Tell me tomorrow's weather"},
{"role": "assistant", "content": "Tomorrow's weather will be sunny"}
],
"rejected_response": "I don't know"
}
```
***
## **Dataset Configuration**
* **Lazy Tokenize**: Delay tokenization until needed. Speeds up dataset loading for large files.
* **Streaming**: Enable only for public HF Datasets to load records on-the-fly, reducing local storage needs.
* **Prompt Max Length**: Maximum token length for prompt. Longer sequences will be truncated.
> **Recommended:** 2048
* **System Prompt**: *(Optional)* A global prefix to every example, e.g., `You are a helpful assistant.`
* **Prompt Template**: *(Optional)* If your data needs wrapping in a custom template, e.g., ` {system_prompt} {prompt}`.
* **Train/Validation Split**: Percentage (fraction) for splitting your `.jsonl` into training and validation sets.
* **Split Type**\
Currently, only **random split** is supported. The dataset will be randomly divided into training and validation sets.
* **Train Split Ratio**\
Enter the ratio of data to be used for training (e.g., `0.9` for 90%).
* **Validation Split Ratio**\
Enter the ratio of data to be used for validation (e.g., `0.1` for 10%).
**Train Split Ratio** should be greater than **0.8**
## **Infrastructure Configuration**
* **GPU Type**: Select instance GPU, e.g., `H100`, `L40s`.
* **GPU Count**: Number of GPUs to allocate for this job.
Adjust based on model size and dataset scale. More GPUs reduces training time.
***
## **Training Configuration**
1. **Core Options**
| **Parameter** | **Description** | **Example** |
| :--------------- | :----------------------------- | :------------- |
| **Train Type** | Select the tuning algorithm | `SFT` |
| **Adapter Type** | Choose adapter method | `LoRA`, `Full` |
| **Torch DType** | Precision setting for training | `bfloat16` |
**Adapter Type**
* **Full** – Use this option for full-model fine-tuning, where all model parameters are updated.
* **LoRA** – Use this for parameter-efficient fine-tuning using Low-Rank Adapters (LoRA), which updates a small subset of weights for faster training and lower resource usage.
> ***Note***: *LoRA is generally recommended for efficiency and ease of deployment.*
2. **Tuner Backend** ***(Applicable only for SFT Training type)***\
The **Tuner Backend** defines the framework used to run fine-tuning and enables faster performance through efficient training strategies.
* **PEFT (Parameter-Efficient Fine-Tuning) Backend**\
Standard backend widely used for LoRA-based fine-tuning.
* Supports distributed training with either `DDP (Distributed Data Parallel)` or `DeepSpeed`.
* **Simplismart Backend**\
Optimized backend designed for more efficient GPU compute and memory utilization.
* Currently supports only `DDP` for distributed training, ensures consistent and predictable scaling across multiple GPUs.
**DDP** replicates the model across GPUs and synchronizes gradients at each step, providing stable multi-GPU training.
**DeepSpeed** adds advanced features like optimizer state partitioning, gradient sharding, and memory offloading, enabling the training of larger models on limited hardware.
3. ***RLHF Configuration (Applicable only for RLHF Training type)***
When selecting **Training Type = RLHF**, additional configuration fields appear under **RLHF Config**. These vary depending on the chosen **RLHF Type**. The platform supports the following RLHF variants:
* **DPO (Direct Preference Optimization)**
* **Beta**\
Controls the trade-off between preference loss and KL regularization.\
**Default:** `0.3`\
**Optional:** Yes, but recommended.
* **GRPO (Generative Rollouts with Preference Optimization)**
* **Beta**\
Similar to DPO, this governs the preference vs. KL loss balance.\
**Default:** `0.0001`
* **Max Num Seqs**\
Number of sequences to use during rollout.\
**Default:** `1`\
**Recommended Value:** `1`
* **Enforce Eager**\
If enabled, forces rollouts to run in eager mode rather than compiled mode. Useful for debugging or compatibility issues.\
**Default:** Unchecked\
**Recommended:** We suggest enabling **Enforce Eager** during **GRPO** training.
* **Common Parameters:**
| **Field** | **Description** | **Required** | **Default** |
| --------------- | ----------------------------------------------------- | ------------ | ----------- |
| RLHF Type | Select the RLHF variant to use | ✅ | - |
| Reference Model | Path to the baseline model used for KL regularization | `Optional` | - |
| Reward Model | Path to the reward mode | `Optional` | - |
4. **Optimization Hyperparameters**
| **Parameter** | **Description** | **Default**
**Values** | **Recommended Values** | **Permissible Range** |
| -------------------------- | ----------------------------------------- | --------------------------- | ---------------------- | --------------------- |
| **Num Epochs** | Number of full passes through the dataset | `1` | `2-5` | \< `50` |
| **Train Batch Size** | Samples per device for training | `8` | `8` | \< `16` |
| **Eval Batch Size** | Samples per device for evaluation | `1` | `8` | \<`16` |
| **Learning Rate** | Initial learning rate for optimizer | `0.0001` | `1×10⁻⁵ to 2×10⁻⁵` | \< `5×10⁻⁵` |
| **Dataloader Num Workers** | Parallel data-loading threads per device | `1` | `4` | \<`10` |
These values are highly dependent on your GPU count. The provided defaults are optimized for setups with 8 GPUs and are suitable for models in the **3B–5B** parameter range. Adjust accordingly based on your GPU configuration.\
\
For larger models, consider reducing the batch size to avoid **out-of-memory issues**.\
\
**Example:** For an 8B model, we recommend using a **train batch size** and **eval batch size** of **4** each.\
(**`Note: this configuration works with DeepSpeed Zero3_Offload)`**
3. **Checkpointing & Monitoring**
| **Parameter** | **Description** | **Default** | **Recommended Values** | **Permissible Range** |
| -------------------- | ------------------------------------------------------------- | ----------- | ---------------------- | --------------------- |
| **Save Steps** | Interval (in steps) between saving model checkpoints. | `100` | `100` | \<= `100` |
| **Save Total Limit** | Max number of checkpoints to keep locally. | `2` | `2-5` | \<`10` |
| **Eval Steps** | Interval (in steps) between running evaluation loop. | `100` | `100 ` | `100 - 200` |
| **Logging Steps** | Interval (in steps) between logging metrics to the dashboard. | `5` | `5` | \< `20` |
***
## **LoRA Adapter Configuration**
| **Parameter** | **Description** | **Default** | **Recommended Value** | **Permissible Range** |
| ------------- | ------------------------------------------------------ | ------------ | --------------------- | --------------------- |
| **Rank (r)** | Dimensionality of the low-rank decomposition. | `16` | `16` | `64` |
| **Alpha** | Scaling factor for the adapter output. | `16` | `32` | `64` |
| **Dropout** | Dropout probability for adapter layers. | `0.1` | `0.1` | `1` |
| **Targets** | Which modules to apply adapters to (e.g., all-linear). | `all-linear` | `all-linear` | `NA` |
These settings control the LoRA injection into your base model. Higher rank increases capacity but uses more memory.
***
## **Distributed Training Configuration**
| **Parameter** | **Description** | **Default** | **Recommended Value** | **Available Options** |
| :------------ | :------------------------------ | :-------------- | :-------------------- | :------------------------------------------------------------------------------ |
| **Type** | Choose your distributed backend | `DeepSpeed` | `DeepSpeed` | `DeepSpeed`, `DDP` |
| **Strategy** | Only available for deepseed | `zero3_offload` | `zero3_offload` | `zero1`,
`zero2`,
`zero2_offload`,
`zero3`,
`zero3_offload` |
Set **Type** to `DeepSpeed` to enable ZeRO optimizations, or `DDP` for native PyTorch distributed training.
\
When using DeepSpeed, select the `zero3_offload` strategy to maximize memory savings by offloading optimizer states to CPU/GPU.
***
## **Launching Your Job**
1. **Review** all settings.
2. Click **Create Job**.
3. Monitor progress under **My Trainings** > **Your Training Job** > **Metrics** .
4. Compile the model and deploy when training completes.
***
# Supported Models
Source: https://docs.simplismart.ai/training-suite/supported-models
List of models supported for fine-tuning on the Simplismart platform
We support a variety of language models (LLMs) and vision-language models (VLMs). Below is a list of the available models:
## **Language Models (LLMs)**
| **Model Name** | **Version** | **Type** | **Description** |
| --------------------------------------------------------------------------------------------- | ----------- | -------- | ----------------------------------------- |
| [`meta-llama/Llama-3.1-8B-Instruct`](https://huggingface.co/meta-llama/Llama-3.1-8B-Instruct) | 3.1, 8B | LLM | Llama 3.1, 8B, Instruct tuned version |
| [`meta-llama/Llama-3.1-8B`](https://huggingface.co/meta-llama/Llama-3.1-8B) | 3.1, 8B | LLM | Llama 3.1, 8B base model |
| [`meta-llama/Llama-3.2-1B`](https://huggingface.co/meta-llama/Llama-3.2-1B) | 3.2, 1B | LLM | Llama 3.2, 1B base model |
| [`meta-llama/Llama-3.2-1B-Instruct`](https://huggingface.co/meta-llama/Llama-3.2-1B-Instruct) | 3.2, 1B | LLM | Llama 3.2, 1B, Instruct tuned version |
| [`meta-llama/Llama-3.2-3B`](https://huggingface.co/meta-llama/Llama-3.2-3B) | 3.2, 3B | LLM | Llama 3.2, 3B base model |
| [`meta-llama/Llama-3.2-3B-Instruct`](https://huggingface.co/meta-llama/Llama-3.2-3B-Instruct) | 3.2, 3B | LLM | Llama 3.2, 3B, Instruct tuned version |
| [`meta-llama/Llama-2-7B-chat-hf`](https://huggingface.co/meta-llama/Llama-2-7B-chat-hf) | 2, 7B | LLM | Llama 2, 7B, Chat (Hugging Face variant) |
| [`meta-llama/Llama-2-7B-chat`](https://huggingface.co/meta-llama/Llama-2-7B-chat) | 2, 7B | LLM | Llama 2, 7B, Chat model |
| [`meta-llama/Llama-2-13B-chat-hf`](https://huggingface.co/meta-llama/Llama-2-13B-chat-hf) | 2, 13B | LLM | Llama 2, 13B, Chat (Hugging Face variant) |
| [`meta-llama/Llama-2-13B-chat`](https://huggingface.co/meta-llama/Llama-2-13B-chat) | 2, 13B | LLM | Llama 2, 13B, Chat model |
| [`meta-llama/Llama-2-7B`](https://huggingface.co/meta-llama/Llama-2-7B) | 2, 7B | LLM | Llama 2, 7B base model |
| [`meta-llama/Llama-2-13B`](https://huggingface.co/meta-llama/Llama-2-13B) | 2, 13B | LLM | Llama 2, 13B base model |
***
## **Vision-Language Models (VLMs)**
| **Model Name** | **Version** | **Type** | **Description** |
| -------------------------------------------------------------------------------------------------- | ----------- | -------- | ----------------------------------------- |
| [`mistral-7b-v0.3`](https://huggingface.co/mistralai/Mistral-7B-v0.3) | 7B, v0.3 | VLM | Mistral 7B, Vision-Language Instruct v0.3 |
| [`mistral-7b-v0.2`](https://huggingface.co/mistralai/Mistral-7B-Instruct-v0.2) | 7B, v0.2 | VLM | Mistral 7B, Vision-Language Instruct v0.2 |
| [`mistral-7b-v0.1`](https://huggingface.co/mistralai/Mistral-7B-v0.1) | 7B, v0.1 | VLM | Mistral 7B, Vision-Language Instruct v0.1 |
| [`llama-3.2-11B-vision-instruct`](https://huggingface.co/meta-llama/Llama-3.2-11B-Vision-Instruct) | 11B | VLM | Llama 3.2, Vision-Instruct |
| [`opengvlab/InternVL2_5-1B`](https://huggingface.co/opengvlab/InternVL2_5-1B) | 1B | VLM | OpenGVLab InternVL2\_5-1B |
| [`opengvlab/InternVL2_5-2B`](https://huggingface.co/opengvlab/InternVL2_5-2B) | 2B | VLM | OpenGVLab InternVL2\_5-2B |
| [`opengvlab/InternVL2_5-4B`](https://huggingface.co/opengvlab/InternVL2_5-4B) | 4B | VLM | OpenGVLab InternVL2\_5-4B |
| [`opengvlab/InternVL2_5-8B`](https://huggingface.co/opengvlab/InternVL2_5-8B) | 8B | VLM | OpenGVLab InternVL2\_5-8B |
| [`opengvlab/InternVL2-1B`](https://huggingface.co/opengvlab/InternVL2-1B) | 1B | VLM | OpenGVLab InternVL2-1B |
| [`opengvlab/InternVL2-2B`](https://huggingface.co/opengvlab/InternVL2-2B) | 2B | VLM | OpenGVLab InternVL2-2B |
| [`opengvlab/InternVL2-4B`](https://huggingface.co/opengvlab/InternVL2-4B) | 4B | VLM | OpenGVLab InternVL2-4B |
| [`opengvlab/InternVL2-8B`](https://huggingface.co/opengvlab/InternVL2-8B) | 8B | VLM | OpenGVLab InternVL2-8B |
| [`aidc-ai/Ovis1.6-Gemma2`](https://huggingface.co/AIDC-AI/Ovis1.6-Gemma2-9B) | 9B | VLM | AIDC AI Ovis1.6 Gemma2 |
| [`aidc-ai/Ovis1.6-Llama-3.2`](https://huggingface.co/AIDC-AI/Ovis1.6-Llama3.2-3B) | 3B | VLM | AIDC AI Ovis1.6 Llama 3.2 |
| [`aidc-ai/Ovis2-1B`](https://huggingface.co/aidc-ai/Ovis2-1B) | 1B | VLM | AIDC AI Ovis2-1B |
| [`aidc-ai/Ovis2-2B`](https://huggingface.co/aidc-ai/Ovis2-2B) | 2B | VLM | AIDC AI Ovis2-2B |
| [`aidc-ai/Ovis2-4B`](https://huggingface.co/aidc-ai/Ovis2-4B) | 4B | VLM | AIDC AI Ovis2-4B |
| [`aidc-ai/Ovis2-8B`](https://huggingface.co/aidc-ai/Ovis2-8B) | 8B | VLM | AIDC AI Ovis2-8B |
| [`aidc-ai/Ovis2-16B`](https://huggingface.co/aidc-ai/Ovis2-16B) | 16B | VLM | AIDC AI Ovis2-16B |
| [`aidc-ai/Ovis2-34B`](https://huggingface.co/aidc-ai/Ovis2-34B) | 34B | VLM | AIDC AI Ovis2-34B |
***
## **Flux (Image Generation)**
| **Model Name** | **Version** | **Type** | **Description** |
| ------------------------------------------------------------------------------------- | ----------- | --------- | --------------------------------------------------------------------------------------- |
| [`black-forest-labs/FLUX.1-dev`](https://huggingface.co/black-forest-labs/FLUX.1-dev) | 1.0, Dev | Image Gen | Flux, black-forest-labs/FLUX.1-dev, for advanced image generation and processing tasks. |
# GRPO (VLM)
Source: https://docs.simplismart.ai/training-suite/vlms/grpo-vlm
Guidelines for preparing train_dataset entries to fine-tune a VLM with both images and text prompts.
## Directory Structure
```
.
└── dataset_dir/
├── images/
│ ├── /path/to/img_1
│ ├── ...
│ └── /path/to/img_i
├── train.jsonl
└── reward_models.py
```
The directory should be archived in a `.zip` file and stored in an object storage. Example zip command:
`cd path/to/dataset_dir && zip -r dataset_dir.zip ./*`
***
## Dataset Structure
The `train.jsonl` file should be a **list** of JSON-like objects, serialised in `jsonl` format, where each object has exactly three keys:
```json theme={null}
train_dataset = [
{
"prompt": "...",
"image": "...",
"answer": "..."
},
]
```
***
## Example JSONL File
```json theme={null}
{"prompt": "...","image": "...","answer": "..."}
{"prompt": "...","image": "...","answer": "..."}
{"prompt": "...","image": "...","answer": "..."}
{"prompt": "...","image": "...","answer": "..."}
```
***
## **Field Definitions**
| **Key** | **Type** | **Description** |
| ------- | ----------- | -------------------------------------------------- |
| prompt | List\[Dict] | Chat-style prompt: a list of role-tagged messages. |
| image | str | Relative path of the image. |
| answer | str | Ground-truth response. |
***
## **Prompt Format**
Each prompt entry is a list of one or more messages. Minimal single-turn example:
```json theme={null}
[
{
"role": "user",
"content": [
{ "type": "image" },
{
"type": "text",
"text": "When a spring does work on an object, we cannot find the work by simply multiplying the spring force by the object's displacement. … Provide your reasoning between and and then your final answer between and (put a float here) ."
}
]
}
]
```
***
## Message fields
* `role`: usually `user` (extend with `assistant` for multi-turn data).
* `content`: ordered list of messages in a turn. Content can have two subtypes:
* `{ "type": "image" }` - placeholder indicating an image input accompanies this turn
* `{ "type": "text", "text": " + " }` - Text message from the user or assistant.
***
## **Image Format**
Path to the image file relative to the root of the dataset files archive. Example:
```
images/cumin_canister_spring.jpg
```
***
## **Answer Format**
The expected answer to the question. Example:
```
1.2
```
***
## **Complete Example**
```json theme={null}
train_dataset = [
{
"prompt": [
{
"role": "user",
"content": [
{ "type": "image" },
{
"type": "text",
"text": (
"When a spring does work on an object, … provide your reasoning between and "
"and then your final answer between and (put a float here) "
)
}
]
}
],
"image": "images/cumin_canister_spring.jpg",
"answer": "1.2",
},
]
```
***
## Reward functions
Depending on the dataset structure and task objectives, you may need to define reward functions for model training. These reward functions are accepted by the trainer through a special `reward_models.py` file. This sections outlines (with examples) the standard method for providing custom reward functions.
Users should define their reward functions in a file named `reward_models.py`, which must expose a list named `reward_functions` containing callable functions.
The **reward functions** list is then passed directly to GRPOTrainer like so: \
\
`GRPOTrainer(reward_functions=reward_functions, **kwargs)`
***
## Example implementation
```python theme={null}
from your_tags import reasoning_start, reasoning_end, solution_start, solution_end
import re
from typing import Callable, List
def formatting_reward_func(completions, **kwargs) -> List[float]:
"""
Rewards the presence of both reasoning and answer tags in the model's output.
"""
thinking_pattern = f'{reasoning_start}(.*?){reasoning_end}'
answer_pattern = f'{solution_start}(.*?){solution_end}'
scores = []
for completion in completions:
text = completion[0]['content']
score = 0.0
if len(re.findall(thinking_pattern, text, re.DOTALL)) == 1:
score += 1.0
if len(re.findall(answer_pattern, text, re.DOTALL)) == 1:
score += 1.0
scores.append(score)
return scores
def correctness_reward_func(prompts, completions, answer, **kwargs) -> List[float]:
"""
Rewards exact match of the numeric answer within the tags.
"""
answer_pattern = f'{solution_start}(.*?){solution_end}'
responses = [
re.findall(answer_pattern, comp[0]['content'], re.DOTALL)
for comp in completions
]
# Example debug print
q = prompts[0][-1]['content']
a = answer[0]
resp0 = completions[0][0]['content']
print("-"*20, f"Q: {q}\nA: {a}\nR: {resp0}")
return [
2.0 if len(r)==1 and r[0].strip()==str(a) else 0.0
for r in responses
]
reward_functions: List[Callable] = [formatting_reward_func, correctness_reward_func]
```
***
* `formatting_reward_func` checks that `…` and `…` appear exactly once.
* `correctness_reward_func` validates the extracted answer matches the ground truth.
# SFT (VLM)
Source: https://docs.simplismart.ai/training-suite/vlms/sft-vlm
# Dataset Preparation
## Overview
This dataset format is designed to represent multi-turn conversations between a **user** and an **assistant**, with optional associated images.\
\
It is particularly suited for fine-tuning dialogue or multimodal models that require both text and image context.
## Directory Structure
```json theme={null}
.
└── dataset_dir/
├── images/
│ ├── /absolute/path/to/img_1.png
│ ├── ...
│ └── /absolute/path/to/img_i.png
└── dataset.jsonl
```
* **images/** – Directory containing image files. Paths must be absolute.
* **dataset.jsonl** – Main dataset file in JSONL format.
## Dataset Structure
Each dataset entry is stored as a single JSON object.
```json theme={null}
{
"messages": [
{"role": "user", "content": "...."},
{"role": "assistant", "content": "...."}
],
"images": ["/absolute/path/to/image1.png", "/absolute/path/to/image2.png"]
}
```
* Multiple turns can be added by extending the `messages` list.
* Multiple images can be included by extending the `images` list.
* `images` must always be a **list** (even if only one image is present).
## Field Definitions
| **Key** | **Type** | **Description** |
| ---------- | ------------ | --------------------------------------------------------- |
| `messages` | `List[Dict]` | Ordered dialogue turns between user and assistant. |
| `role` | `str` | `"user"` or `"assistant"` — identifies the speaker. |
| `content` | `str` | The text content of the message. |
| `images` | `List[str]` | List of **absolute paths** to the associated image files. |
## Example Entry
```json theme={null}
{
"messages": [
{"role": "user", "content": "Which of these states is farthest north?"},
{"role": "assistant", "content": "The answer is: A. West Virginia"},
{"role": "user", "content": "Which of these states is farthest south?"},
{"role": "assistant", "content": "The answer is: C. Texas"}
],
"images": ["/home/datasets/images/000000.png","/home/datasets/images/000001.png"]
}
```
## Usage Notes
* Conversations can contain **any number of turns**.
* The `images` field can contain multiple entries or be empty (`[]`).
* Always use **absolute paths** for image references to avoid path resolution errors.
* Store images in a consistent directory (e.g., `/home/datasets/images/`).
# Model Optimization Troubleshooting Guide
Source: https://docs.simplismart.ai/troubleshooting-faq/model-compilation-troubleshooting
Refer to this guide to ensure proper configuration of infrastructure settings for model compilation and inference. It also helps identify and prevent common issues related to hardware incompatibilities and performance bottlenecks.
## Required Infrastructure Configuration
| **Parameter** | **Value** | **Notes** |
| ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Cluster** | You can either use the Simplismart Infrastructure or select your cluster where you want the model to be compiled. If you haven’t created a cluster yet, you can proceed with the Simplismart Infrastructure option. | - |
| **Region** | If you have selected Simplismart Infrastructure as your cluster option, the region should be set to Global. If you are using your **own cluster**, you will need to select a region where you have sufficient quota available for the machine that will be used to compile the model. | Ensures access to globally available compute resources |
| **Instance Type** | Model-dependent | Select a type based on model size (see below)
✅ Always choose the (any) variant for better availability (If you have selected Simplismart Infrastructure as your cluster option) |
| **Machine Type** | Default | Always choose Default. (If you have selected Simplismart Infrastructure as your cluster option) |
## What is Tensor Parallelism (TP)?
**Tensor Parallelism** allows a model's computation to be split across multiple GPUs or devices, enabling:
* Faster inference for large models
* Support for models too large to fit on a single device
tensor\_parallel\_size controls how many devices the computation is split across:
* 1 = **No tensor parallelism** (single GPU)
* 2, 4, 8, etc. = Enable TP across multiple GPUs
You must have **at least as many GPUs** as the value set in **tensor\_parallel\_size**.
## **Model Mode Types and Compatibility**
Different model versions require specific *modes* to function correctly. When selecting models from Hugging Face, you'll typically find two variants:
* Base models (e.g., *meta-llama/Meta-Llama-3-8B*) - designed for *completion* tasks.
* Instruct models (e.g., *meta-llama/Meta-Llama-3-8B-Instruct*) - optimized for *conversational/chat interactions.*
**Configuration Rule**: The pipeline mode must match the model type, otherwise compilation will fail. For instance, using a base completion model like **meta-llama/Meta-Llama-3-8B** with **chat mode** will cause errors - you must set the mode to **completion** instead.
**Pipeline Mode Settings**: Configure the mode in your pipeline based on your intended use case:
* Set mode to **embedding** when compiling embedding models
* Set mode to **chat** when compiling conversational/instruct models
* Set mode to **completion** when compiling base/completion models
The key is ensuring alignment between your model choice and the corresponding pipeline mode configuration.
## Instance Type Selection Guide
Use the table below to guide instance and TP configuration based on your model size:
| **Model** | **Recommended Instance Type** | **Suggested TP** | **Notes** |
| --------------------------- | ----------------------------- | ---------------- | --------------------------------------------- |
| **Gemma 2B** | L40s (any) | 1 | Lightweight model; fits on a single GPU |
| **LLaMA 3B** | L40s (any) | 1 | Also fits on single GPU with headroom |
| **Gemma 7B** / **LLaMA 8B** | H100 (any) | 2–4 | Benefits from multi-GPU setup |
| **LLaMA 70B** | H100 (any) | 2–4+ | Requires high TP and multi-GPU infrastructure |
## Common Issues & Fixes
| **Issue** | **Cause** | **Fix** |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| 🚫 **Job stuck in queue or not scheduled (machine not available)** | Instance type too specific or unavailable. | ✅ Use (any) variant of **instance type** |
| 🚫 **Out of memory / crashes** | Model too large for single GPU. | ✅ Increase **tensor\_parallel\_size** or upgrade instance type |
| 🚫 **TP value ignored or job fails to start** | TP set higher than available GPUs. | ✅ Ensure instance has **≥ GPUs** than **tensor\_parallel\_size** |
| **🐢** **Slow inference** | Underutilised hardware or no parallelism. | ✅ Tune **tensor\_parallel\_size** and use multi-**GPU instances** |
| **🚫** **Unsupported model type**
`Error message: The given model path is invalid` | The model which you trying to compile is currently not supported through the Simplismart Platform. | You can contact [support@simplismart.ai](mailto:support@simplismart.ai) we will check the feasibility and add support for the model. |
| **Mode Types in Pipeline config Model compilation failing even if the correct model and other parameters are selected.** | The selected model *mode* in the pipeline config may be incorrect. | **Pipeline Mode Settings**: Configure the mode in your pipeline based on your intended use case:
- Set mode to **embedding** when compiling embedding models.
- Set mode to **chat** when compiling conversational/instruct models.
- Set mode to **completion** when compiling base/completion models. The key is ensuring alignment between your model choice and the corresponding pipeline mode configuration. |
| **Machine Clean-up failed**
`Error Message: Cleanup Failure: Exception occured while cleaning up : Error cleaning up Azure resource group` | You can contact [support@simplismart.ai](mailto:support@simplismart.ai) we will check the reason for the failure. | You can contact [support@simplismart.ai](mailto:support@simplismart.ai) we will check the feasibility and add support for the model. |
## FAQs
1. **Can I edit the model name later?**
No, renaming a model after it's been added and compiled is not supported. The model name must be set during the initial setup.
***
2. **What options are available for model sources?**
You can choose HuggingFace, where the base model is downloaded directly, or use AWS S3, GCS, or DockerHub by providing the appropriate path (S3 URL, GCS URL, or DockerHub registry link) along with the required credentials so we can retrieve your custom model.
***
3. **Do I need authentication keys for external sources?**
Yes, for S3, GCS, and DockerHub, you must add your authentication keys on the Secrets page in the Simplismart platform and use those credentials during the compilation process.
***
4. **Why am I getting a “The given model path is invalid” error? How do I verify if my model path is valid?**
While the platform supports most LLM models, this error can occur if a particular model type isn't supported yet. If you encounter this issue, please contact us at [support@simplismart.ai](mailto:support@simplismart.ai), and we’ll work on enabling support for your model.
***
5. **How do I link my AWS/GCP/Azure account?**
You will have to your cloud account details in the integrations section. Refer to this [doc](https://docs.simplismart.ai/model-suite/integrations/secrets) on BYOC.
***
6. **Can I use multiple cloud accounts?**
Yes, the Simplismart platform supports adding and managing multiple cloud accounts.
***
7. **Does region selection affect latency or costs?**
\
For model compilation jobs, the selected region typically doesn't have a major impact on latency or cost. If you're using your own cloud account, you can run the compilation in any region where you have available resource quotas.
***
8. **How do I choose the right accelerator for my model?**\
\
The appropriate accelerator depends largely on the size of your model. Larger models require higher-spec machines for **optimization** and **deployment**.
***
9. **Why is my selected accelerator not available in the region I picked?**\
\
Some high-end GPUs like A100s or H100s are not available in all regions across major cloud providers such as AWS, Azure, or GCP. As a result, those accelerator options may not appear in the region's dropdown list.
***
10. **What happens if I run out of quota for GPUs in my cloud account?**\
\
If your cloud account lacks sufficient GPU quota, the optimization job may fail to start or could get stuck partway through, leading to a failed optimization process.
***
11. **What does \_accelerator count \_mean?**\
\
Accelerator count refers to the number of GPU instances allocated for a job. For example, if you select H100 as the accelerator and set the count to 2, two H100 machines will be provisioned. This is especially important when the tensor parallelism (TP) value is greater than 1.
***
12. **How do I know which machine type to select?**\
\
Even within the same instance family (e.g., AWS EC2 G5), all instances typically share the same underlying GPU for example, the NVIDIA A10G. However, they differ in the number of vCPUs and amount of RAM. It's generally recommended to choose a medium or large instance size to ensure sufficient CPU and memory resources for your ML workload.
***
13. **What is quantization and why should I use it?**
Quantization is the process of reducing the precision of the numbers used to represent a language model’s parameters (e.g., from 32-bit floating point to 8-bit integers) to make the model smaller and faster, with minimal loss in accuracy, helpful for running large language models (LLMs) efficiently
***
14. **Which quantization levels are supported?**\
\
We support FP16, FP8, and AWQ quantization. \
\
Note that FP8 is not supported on Ampere architecture GPUs like A100 and A10G, as these devices do not natively support FP8 precision.
***
15. **Does quantization affect accuracy?**\
\
Yes, quantization can result in a slight reduction in model accuracy.
***
# Model Deployment Troubleshooting Guide
Source: https://docs.simplismart.ai/troubleshooting-faq/model-deployment-troubleshooting
Follow this comprehensive guide to successfully deploy models on Simplismart Platform using the Simplismart Infrastructure, from initial configuration to production monitoring.
## **Deployment Naming**
### **Deployment Name Requirements**
* **Uniqueness**: Each deployment name must be **unique within the organisation.**
* **Naming Convention**: Use descriptive names like `llama-8b-chat-v1` or `gemma-7b-prod`
* **Character Limits**: Use alphanumeric characters and hyphens only. The deployment name should not start with a number.
If you use a duplicate name, you'll receive an error message and cannot proceed with deployment.
### **Best Practices**
```html theme={null}
✅ Good Examples:
- llama-3b-dev-v2
- gemma-7b-production
- mistral-8b-api-staging
❌ Avoid:
- model1, model2 (not descriptive)
- test (too generic)
- prod.model (special characters)
```
***
## **Cluster Selection**
* **Cluster**: Always select `Simplismart Cloud`
***
## **Accelerator Type Selection**
### Accelerator Type**Decision Matrix**
| **Model Type** | **Model Size** | \*\*Recommended Accelerator Type \*\* | **Auto-Selected Instance** |
| :---------------- | :------------------ | :------------------------------------ | :------------------------------------ |
| **Small Models** | Llama 3B, Gemma 2B | `T4` | Based on model TP value |
| **Medium Models** | Llama 8B, Gemma 7B | `L40s` | Single-GPU or Based on model TP value |
| **Large Models** | Llama 70B, Qwen 32B | `H100` | Multi-GPU configuration |
### **Automatic GPU Instance Selection**
The system automatically determines GPU instance count based on your model's **Tensor Parallel (TP)** configuration:
```html theme={null}
Model TP = 1 → 1x GPU instance
Model TP = 2 → 2x GPU instance
Model TP = 4 → 4x GPU instance
Model TP = 8 → 8x GPU instance
```
**Example**: If you select a model with TP=4 and choose H100 node group → System deploys `4xH100` automatically.
***
## **Scaling Configuration**
**Scaling Parameters**
**Pod Scaling Settings**
* **Min Pods**: Minimum number of replicas.
* **Max Pods**: Maximum replicas.
| **Metric** | **Use Case** | **Recommended Threshold** | **Notes** |
| :-------------------- | :--------------------------- | :------------------------ | :----------------------------- |
| **GPU Utilization %** | GPU-intensive inference | 80% | Best for ML model scaling |
| **Memory Usage** | Memory-bound applications | 80% | Prevents OOM errors |
| **GPU Memory Usage** | Large model deployments | 85% | Critical for model performance |
| **Latency** | Response time sensitive apps | 500ms | User experience focused |
| **Throughput** | High-volume applications | 100 req/sec | Capacity-based scaling |
### **Scaling Strategy Examples**
```html theme={null}
# Aggressive Scaling (Variable Traffic)
Min Pods: 1
Max Pods: 20
Metric: GPU Utilisation
Threshold: 60%
# Latency-Sensitive Scaling
Min Pods: 3
Max Pods: 15
Metric: Latency
Threshold: 300ms
```
***
### **Rapid Autoscaling (Simplismart Cloud)**
**Feature Overview**
* **Activation**: Toggle switch at bottom of deployment screen.
* **Benefit**: Pods spin up in **seconds to minutes** instead of standard deployment times
**How It Works**
* **Pre-cached Images**: Model images are cached in pre-puller system.
* **Instant Scaling**: No image download time during scale-up events.
* **Resource Optimization**: Faster response to traffic spikes.
**When to Enable**
✅ **Enable for**:
* Production workloads with variable traffic
* Applications requiring rapid scaling response
❌ **Skip for**:
* Stable workloads with predictable traffic
* Development/testing environments
***
## **Deployment Execution**
**Deployment Process**
1. **Click Deploy Button**: Initiates deployment process
2. **Monitor Progress**: Watch deployment status in real-time
3. **Health Check Monitoring**: Check the health check status bar on the right side
4. **Wait for "Healthy" Status**: Indicates model is fully loaded and ready
\
**Health Check States**
| **Status** | **Meaning** | **Action Required** |
| :--------------- | :--------------------- | :------------------ |
| 🟡 **Pending** | Deployment in progress | Wait for completion |
| 🟢 **Healthy** | Ready for inference | Proceed to testing |
| 🔴 **Unhealthy** | Deployment failed | Check logs |
***
## **API Integration & Testing**
### **Getting API Credentials**
1. Navigate to **API tab** in the deployment page
2. Copy the provided **Python script** or **cURL command**
3. Replace placeholder values with your actual parameters
### **Sample Integration Code**
#### **Python Example**
```python theme={null}
import requests
# Copied from API tab
endpoint = "https://your-deployment-endpoint.com/v1/chat/completions"
headers = {
"Authorization": "Bearer ",
"Content-Type": "application/json"
}
payload = {
"model": "your-deployed-model",
"messages": [{"role": "user", "content": "Hello!"}],
"max_tokens": 100
}
response = requests.post(endpoint, headers=headers, json=payload)
print(response.json())
```
#### **cURL Example**
```bash theme={null}
curl -X POST "https://your-deployment-endpoint.com/v1/chat/completions" \
-H "Authorization: Bearer " \
-H "Content-Type: application/json" \
-d '{
"model": "your-deployed-model",
"messages": [{"role": "user", "content": "Hello!"}],
"max_tokens": 100
}'
```
***
## **Monitoring & Metrics**
### **Monitoring Dashboard**
* **Real-time Data**: Live metrics and performance indicators
* **Historical Data**: Trends and usage patterns over time
### **Key Metrics Available**
#### **Infrastructure Metrics**
* **Active Pods**: Current number of running instances
* **Pod Health**: Health status of each replica
* **Resource Usage**: CPU, GPU, memory consumption per pod
#### **Request Metrics**
* **Request Count**: Total API calls received
* **Success Rate**: Percentage of 2XX responses
* **Error Distribution**: Breakdown of 4XX/5XX errors by type
* **Response Times**: Latency percentiles (P50, P95, P99)
### **Monitoring Best Practices**
```html theme={null}
📊 Daily Monitoring:
- Check overall health status
- Review error rates and types
- Monitor resource utilization trends
📈 Weekly Analysis:
- Analyze traffic patterns
- Review scaling effectiveness
- Plan capacity adjustments
```
## **Common Deployment Troubleshooting**
### **Deployment Stuck in Pending**
**Possible Causes**:
* Insufficient resources in selected node group
* Image pull failures
**Solutions**:
1. Check node group capacity
2. Verify model image availability
### **Health Check Failing**
**Possible Causes**:
* Model loading timeout
* Insufficient memory allocation
* Network connectivity issues
**Solutions**:
1. Increase resource allocation
2. Check deployment logs for specific errors
3. Verify endpoint configuration
### **Poor Performance After Deployment**
**Possible Causes**:
* Suboptimal scaling configuration
* Wrong accelerator type chosen for model size
* Network latency issues
**Solutions**:
1. Adjust scaling metrics and thresholds
2. Switch to higher-spec accelerator
3. Enable rapid autoscaling.
***
## **Deployment Success Checklist**
* ✅ Unique deployment name configured
* ✅ Sakthi Cloud cluster selected
* ✅ Appropriate node group chosen for model size
* ✅ Scaling parameters configured based on expected traffic
* ✅ Node affinity strategy selected
* ✅ Rapid autoscaling enabled (if in **Simplismart Cloud**)
* ✅ Health check shows "Healthy" status
* ✅ API integration tested successfully
* ✅ Monitoring dashboard configured and reviewed
***
## FAQs
1. **Can I deploy the same model multiple times?**
Yes, you can deploy the same model more than once. However, please note that each deployment may spin up a new machine, which could lead to increased costs.
***
2. **Can I change the slug after deployment?**\
\
No, currently we do not support renaming the deployment slug or name once it has been created.
***
3. **Why don’t I see any clusters?**\
\
When a new organization is created on the Simplismart Platform, clusters are not visible by default. Initially, you can deploy using Simplismart Cloud (our managed cluster). To deploy on your own infrastructure (such as your VPC), you’ll need to link your cloud account and create a custom cluster. Refer to the [documentation](https://docs.simplismart.ai/inference/bring-your-own-compute) for detailed steps.
***
4. **Can a deployment span multiple clusters?**\
\
No, we currently do not support deployments across multiple clusters. Each deployment is limited to a single cluster. If you need to deploy the same model in another cluster, you will need to create a separate deployment there.
***
5. **Why is my deployment stuck in “Pending” state?**
\
For large models like *LLaMA 70B*, the container image size can be substantial. This may cause the deployment to remain in the **Pending** state temporarily as the model downloads and initializes.\
\
If the deployment stays in **Pending** for more than 30 minutes, please reach out to [**support@simplismart.ai**](mailto:support@simplismart.ai) for assistance.
***
6. **How do I monitor logs of my model container?**\
\
Each deployment has the logs tabs on it’s deployment page, you can see the deployment logs over there.
***
7. **Can I pause a deployment to save costs?**
Yes, you can pause any active deployment. To do so, go to the **Deployments** section, select the deployment you want to pause, and click the **Pause** button at the top right. While paused, you won’t incur charges for that deployment.
***
8. **What monitoring/metrics are available for deployed models?**\
\
The platform provides real-time metrics including:
* Throughput
* Resource usage
* Pod health
* Number of active pods
* Response times
* Success rates
* Request counts\
These metrics can be used for monitoring model performance and system health.
***
9. **How do I troubleshoot failed deployments?**\
\
You can check the logs on the *status bar* in the deployment page of failed deployment.
\
Please reach out to [**support@simplismart.ai**](mailto:support@simplismart.ai) for further assistance.
***
10. **Does region selection affect latency or costs?**\
\
Yes, selecting a region can impact both latency and cost. Latency is primarily influenced by the geographic location of your end users. For example, if a model is deployed in the India region and requests come from the US, network latency may increase, which can slightly affect performance and costs.
***
11. ***Why am I getting an OOM error? What changes do I need to make next?***\
\
An **Out of Memory** (OOM) error usually indicates that the selected GPU doesn’t have sufficient VRAM to load your model. In such cases, it is recommended to switch to a GPU with a higher memory configuration.
##
12. **How do I know how much memory my model needs?**\
\
The GPU memory requirements for running a model primarily depend on two factors: **Model Size** and **Quantization**.
* For **FP16 precision**, the required **GPU memory** is approximately **2× the model size**. For example, a 70B parameter model would need a minimum of **140 GB** of GPU memory just to load the model, with additional memory needed for inference or serving workloads.
* For **FP8 precision**, the memory requirement is roughly **half the model size**. So, a 70B model would require about **35 GB** of GPU memory.
These are general guidelines and actual requirements may vary based on implementation and additional runtime overhead.
# VAD Parameter Tuning
Source: https://docs.simplismart.ai/troubleshooting-faq/vad-parameter-tuning
Guide to tuning Voice Activity Detection parameters
**Voice Activity Detection (VAD)**, also known as Speech Activity Detection or Speech Detection, is the process of identifying the presence or absence of human speech in an audio signal. It is widely used in speech processing to filter out non-speech segments.
### **How VAD Works**
VAD assigns a probability score to an audio chunk, determining whether it contains speech or noise.
* If audio is missing expected speech segments, lowering this threshold may help include more speech but increases the risk of false positives (hallucinations).
* If hallucinations occur, it indicates that the model is filtering too aggressively.
### **VAD Onset and Offset**
* **VAD Onset:** The probability threshold that determines the start of detected speech.
* **VAD Offset:** The probability threshold that determines the end of detected speech.
#### **Impact of Onset and Offset Settings**
* If the **start** of speech is missing, the **onset** threshold may be too high.
* If the **end** of speech is missing, the **offset** threshold may be too high.
* The model processes audio in **chunks**, so determining exact start and end points can be complex.
* Adjusting onset often requires adjusting offset as well, since both affect how the model processes speech segments.
### **Recommended VAD Ranges**
| **Audio Type** | **Recommended VAD Offset** | **Recommended VAD Onset** |
| --------------------------------------- | -------------------------- | ------------------------- |
| **Normal audio** | 0.3 | 0.5 |
| **Noisy audio (with background noise)** | 0.1 | 0.3 |
| **High-quality clear audio** | 0.5 | 0.7 |
### **VAD Limitations**
* **VAD only provides a probability score** indicating whether a chunk is speech or noise—it does not classify or transcribe speech.
* The effectiveness of VAD also depends on which **Whisper model version** is used.
* VAD tuning is often a **trial-and-error** process to find the best configuration for specific audio.
### **Experimentation and Optimization**
Since VAD performance varies based on audio characteristics, fine-tuning the onset and offset values requires testing different settings. Factors to consider include:
* The **amount of background noise** in the recording.
* The **quality of speech recording** (clarity, volume, and distortion).
* The **model** and being used for processing.
By experimenting with different VAD thresholds and configurations, you can optimize speech detection for your specific use cases.
# Frequently Asked Questions
Source: https://docs.simplismart.ai/troubleshooting-faq/whisper-troubleshooting
## **Language Issues**
**Q: Why is the language detected incorrectly or the transcription quality poor for some languages?**
**A:** This can happen in two scenarios:
* If you are specifying a language and it is incorrect, pass an empty string for the `Language` parameter to allow the model to auto-detect the language.
* If you are already passing an empty string and the issue persists, specify the correct language explicitly.
**Q: Why is the transcription inconsistent when there are multiple languages spoken in the audio?**
**A:** Enable the multilingual flag, but be aware that initial segments may have inconsistencies. Set the `Language` parameter to an empty string and include `"Multilingual": True` in the payload.
**Q: Why is the model not detecting the language correctly, resulting in transcription in the wrong language?**
**A:** The model may sometimes struggle with automatic language detection. To improve recognition, add an `initial prompt` in the expected language, such as `"यह बातचीत हिंदी में है"` for Hindi or `"ಈ ಸಂಭಾಷಣೆ ಕನ್ನಡದಲ್ಲಿದೆ"` for Kannada.
## **Diarization Issues**
**Q: Why is the diarization not matching with transcription timestamps or showing incorrect timestamps?**
**A:** Diarization is handled by a separate model that relies on transcription results. This can lead to cases where two transcriptions spoken by one speaker are combined into a single segment, affecting timestamps. Additionally, if the `without_timestamps` parameter is incorrectly set, it may cause misalignment. Ensure `without_timestamps` is set to `False`, resend the request, and check if the diarization timestamps align correctly. Note that OpenAI models do not support diarization directly.
**Q: Why are incorrect speaker IDs assigned during diarization?**
**A:** Set ***max speakers*** and ***min speakers*** to the actual number of speakers in the audio. Providing an arbitrary number can lead to incorrect speaker assignments.
## **Hallucination Issues**
**Q: What causes repeated transcript/ hallucination in transcription?**
**A:** Hallucinations can occur due to an initial prompt influencing the output, noisy audio, incorrect language selection, or Voice Activity Detection (VAD) settings. To reduce hallucinations, try:
* Removing or refining the initial prompt.
* Improving audio quality by reducing background noise.
* Ensuring the correct language is selected.
* Tuning VAD parameters for better segmentation.
For details on VAD parameters, refer to [VAD Parameter Tuning](/troubleshooting-faq/vad-parameter-tuning) documentation.
***
## **Incorrect Transcriptions**
**Q: Why is the model output different from the expected format (translation vs. transcription)?**
**A:** Set the task to `translate` for an English output or `transcribe` to get the text in the original language.
**Q: Why are transcriptions incorrect on the Streaming Endpoint?**
**A:** For streaming, his may happen due to mismatched audio format, sampling rate, or chunk size. Ensure the source audio is in the correct format (e.g., pcml) and not in the default, potentially mismatched format (e.g., wav or mp3) and matches the expected sampling rate and chunk size.
***
## **Missing Transcriptions**
**Q: Why are some parts of the transcription missing?**
**A:** The issue could be due to incorrect VAD settings. Additionally, if the audio has long pauses, adjust the `VAD onset` to compensate for initial silence and ensure proper transcription
**Q: How do VAD settings affect transcription, and how can I improve missing transcriptions?**
**A:** Improper VAD settings can impact transcription quality. [Adjust onset and offset values](/troubleshooting-faq/vad-parameter-tuning) and fine-tune them based on audio quality. Different VAD settings may be needed depending on the type and noise level of the audio.