Requirements
Before you begin, make sure you have:- A Hugging Face account and an access token with read permission.
- A Hugging Face repository (private or public) containing all required files for the model, including weights in Safetensors format.
- It must include model files and any required processor (tokenizer, image processor, feature extractor, and so on).
Deploy a model
Open the deployment wizard in the dashboard.
Important notes
- Custom Python code in Hugging Face repositories is not supported. Use architectures available in
transformersordiffusers. - Model weights must be in Safetensors format. See Convert models to Safetensors if your repo only has
.binfiles. - The
README.mdfile must include apipeline_tag. For example:
Deployment type
Choose how quickly model instances should be able to serve requests. See Core concepts for a comparison table.- Production
- At least one model instance is kept running and ready to serve.
- Uses fast scaling for immediate capacity increases.
- You pay for this model 24/7.
- Serverless (recommended)
- Model instances are prepared to load very quickly when they receive traffic.
- Startup times are minimized while keeping costs lower than always-on.
- You pay for this model only when it has active instances.
- Enterprise
- Dedicated infrastructure for high-volume or custom requirements.
- Deployment options and pricing are tailored to your needs.
- Contact support to get started.
Precision
Select the numeric precision for running your model. Higher precision uses more memory, which can increase cost, while lower precision reduces memory usage.- Examples: Float32 (higher memory), BFloat16 (lower memory)
- See pricing notes in Core concepts.
Quantization
If your model supports quantization, you can select from available options such as EETQ or FP8. Quantization reduces memory and can improve throughput, with some impact on accuracy depending on the method. See Optimizing costs for guidance on INT4, INT8, and FP8 trade-offs.Worker timeout
If a model instance receives no requests during the configured timeout period, it will shut down automatically. This helps control idle costs. Worker timeout applies to Serverless deployments. See Autoscaling for how worker timeout interacts with scale-down behavior.What you configure during deployment
- Model source — Hugging Face repository and revision (branch, tag, or commit)
- Deployment type — Production, Serverless, or Enterprise
- Precision and quantization — if supported by the model
- Autoscaling policy — minimum/maximum instances, scale thresholds, cooldown
- Worker timeout — idle shutdown for non-always-on deployments
Need help? Contact support at any time.

