| name | together-dedicated-model-inference |
| description | Deploy and operate models on dedicated GPUs with Together AI's Dedicated Model Inference (DMI, the v2 dedicated endpoints API): beta endpoints, deployments, deployment profiles and hardware configs, autoscaling, traffic splitting, A/B tests, shadow experiments, Prometheus metrics, and custom model or LoRA adapter uploads. Reach for it whenever the user mentions together beta endpoints or tg beta commands, client.beta.endpoints, DMI resources like ep_/dep_/cr_/ml_ IDs, or wants production model serving with traffic management on Together AI. This is the current dedicated-hosting API and also covers migrating off the retired legacy v1 endpoints API (non-beta client.endpoints / together endpoints), whose create and restart now return HTTP 403. |
Together Dedicated Model Inference
Overview
Dedicated model inference (DMI) serves a model on reserved single-tenant GPUs. It bills per
minute per running replica (by hardware, not by token), has no hard rate limits, and uses the
same inference API as serverless models.
The resource model has six parts: Project → Model → Config → Endpoint → Deployment → Replica.
- Endpoint — stable inference name; routes traffic across its deployments by weight.
- Deployment — binds one model + one config to an endpoint with an autoscaling policy;
runs the replicas.
- Config — immutable published revision describing how the model runs (engine, GPU type
and count, optimization profile). The model determines the available configs.
- Replica — one model instance on its own dedicated hardware.
Inference goes to https://api-inference.together.ai/v1 with the endpoint string
(<project_slug>/<endpoint_name>) as the model parameter. Management goes through the
Together CLI (tg beta ... — install with uv tool install "together[cli]"; tg and
together are interchangeable), the client.beta.* SDK namespaces, or the /v2 REST API at
https://api.together.ai.
The legacy v1 dedicated endpoints API is retired. The old flow (client.endpoints.create
with model= + hardware=, hardware IDs like 1x_nvidia_h100_80gb_sxm, the together endpoints CLI without beta) no longer accepts new endpoints: POST /v1/endpoints,
client.endpoints.create(...), and tg endpoints create return
endpoints_v1_create_access_disabled (HTTP 403), and a stopped/paused v1 endpoint can't be
restarted. Already-running v1 endpoints keep serving until further notice; everything new —
and any redeploy of a stopped v1 endpoint — uses the v2 flow this skill describes.
When This Skill Wins
- Deploying a model (public, fine-tuned, or uploaded) on dedicated GPUs via the v2 API
- Anything involving
tg beta endpoints / tg beta models (a.k.a. together beta ...) CLI commands
- Anything involving
client.beta.endpoints / client.beta.models SDK namespaces
- Traffic management: splits, A/B tests, shadow experiments
- Autoscaling, scale-to-zero, deployment lifecycle, monitoring (dashboards, events, Prometheus scrape)
- Uploading custom model weights or LoRA adapters for dedicated serving
Hand Off To Another Skill
- Use
together-chat-completions for serverless inference and request-shaping questions
(the request shape is identical once the endpoint is up).
- Use
together-fine-tuning for training the model you'll deploy here.
- Use
together-dedicated-containers for custom Docker runtimes (Sprocket/Jig).
- Use
together-gpu-clusters for raw multi-node compute.
Quick Routing
- Deploy a model end to end
- Endpoint/deployment lifecycle from the SDK or API (create, poll, scale, stop, delete, list filters)
- Split traffic, A/B tests, shadow experiments
- Choose a model or config, pricing, upload custom weights or LoRA adapters
- Autoscaling and monitoring
Workflow
- Pick a model:
tg beta models public (or upload custom weights first).
- Pick a config/precision: read the model's
deploymentProfiles (they carry quantization
like BF16/FP8, gpuCount, and the exact model+config resource names). tg beta models configs <id> is often empty for catalog architectures — see
models-and-configs.md. deploy auto-picks only when the
model has a single profile.
- Deploy:
tg beta endpoints deploy <model> --endpoint <name> — creates the
endpoint, attaches a deployment, and routes 100% of traffic in one step. For a public
catalog model with one profile, pass its name (Qwen/Qwen2.5-7B-Instruct); the catalog
ml_/arch_ ID is owned by a platform project and won't resolve as a deploy/ab
positional in your project. If the model has multiple profiles (e.g. BF16 + FP8), a
bare-name deploy errors — pass the chosen profile's full resolved model resource path as
the positional plus its --config (see models-and-configs.md).
- Poll until
status.state is DEPLOYMENT_STATE_READY. The CLI get now accepts an
endpoint or deployment ID: tg beta endpoints get dep_... --json | jq -r '.status.state'
is the scripted polling loop; the SDK equivalent is
client.beta.endpoints.deployments.retrieve(dep_id, project_id=..., endpoint_id=...).
First-time provisioning commonly takes up to ~20 minutes.
- Send requests to
https://api-inference.together.ai/v1 with the endpoint string as model.
- Scale, reconfigure, or set traffic weights with
tg beta endpoints update <dep_id>
(--min/--max-replicas, --scaling-metric/--scaling-target, --traffic-weight); split traffic or
experiment as needed.
- Clean up:
tg beta endpoints update <dep_id> --min-replicas 0 --max-replicas 0 to stop
billing, or tg beta endpoints rm <ep_id> --force to tear everything down (it scales
deployments to zero itself).
High-Signal Rules
- Billing runs while replicas run, and there is no automatic idle shutdown. Per minute,
per replica, by hardware. The old
inactive_timeout auto-stop was removed — always scale to
zero (min_replicas: 0, max_replicas: 0) or delete when the user is done; a forgotten
deployment bills until someone stops it.
- A
READY deployment serves nothing until it's in the endpoint's traffic split. The CLI's
deploy routes automatically; otherwise set a weight with tg beta endpoints update <dep_id> --traffic-weight N (upserts one entry) or replace the split via SDK
endpoints.update(traffic_split=[...]). A routing_error/503 on a READY deployment almost
always means a missing/zero weight.
- Management IDs vs endpoint string. Management calls take IDs (
ep_, dep_, cr_, ml_,
abx_, exp_); inference takes the endpoint string <project_slug>/<endpoint_name>.
- The SDK requires
project_id on every method — derive it with client.whoami().project_id.
The SDK also takes models/configs as resource names (projects/{p}/models/{ml},
projects/{p}/configs/{cr}), while the CLI takes bare IDs. Use the config's own projectId
(often a platform project) when building its resource name.
- Traffic weights are relative capacity, not percentages. Share = weight × ready replicas.
Prefer shifting traffic by changing replica counts; keep weights stable.
- Scale-to-zero is all-or-nothing:
min_replicas: 0 with a positive max_replicas is
rejected. 0/0 stops; on a running deployment the floor is otherwise 1.
- Autoscaling metric names are their own catalog (
gpu_utilization, inflight_requests,
ttft, ...) — raw Prometheus series names are rejected in scaling policies. Charts live in
the dashboard (https://api.together.ai/endpoints); raw series can be scraped from the
org-scoped Prometheus-compatible metrics endpoint (beta — see api-reference.md).
- Deletion order matters: stop the deployment (wait for
STOPPED), delete it, then
delete the endpoint. The CLI's smart-deletes by ID prefix and auto-detaches from the
split. Deleting still requires a stopped deployment, but now scales down for you:
on a running deployment sets and asks you to retry once , and
scales the endpoint's deployments to zero itself as part of teardown.
Resource Map
Official Docs
