One-Click Frontier Catalog
Stage: Ship · What it does: deploy full-weight frontier models — DeepSeek V4 Flash (284B, MIT) and Qwen3.8-Flash-Next (~180B) — as your own endpoint in a few clicks, with honest context presets and per-hour costs shown up front.
Why it matters
- No fine-tuning needed. These are complete, frontier-class models ready to serve — the "bring the big model, don't train it" path.
- Honest cost first. The catalog shows the real per-hour rate for the instance your context choice requires — no surprise $100/hr endpoint at the end.
- Context you can actually use. You pick a context preset (e.g. 8K / 128K / 1M), and the platform only offers instances that can genuinely serve that context — it refuses combos that can't fit.
The models
| Model | Params | Artifact | License | Context presets |
|---|---|---|---|---|
| DeepSeek V4 Flash | 284B total · 13B active | ~160 GB | MIT | 8K · 128K · 1M |
| Qwen3.8-Flash-Next | ~180B | ~360 GB | Qwen Community 1.0 | 8K · 64K · 128K · 256K |
The 1M / 256K presets require the biggest GPU tier (H200-class) — the UI says so, with the VRAM reason, before you pick.
How to use
- Ship → deploy from the catalog (the one-click card on the training dashboard).
- Pick the model.
- Pick a context preset — the recommended instance auto-fills and the hourly cost updates.
- Optionally override the instance — but only within the set that actually supports the preset (the platform enforces this, so you can't create an endpoint the model can't fit).
- Deploy. The platform resolves the exact artifact (pinned to the baked commit), provisions the instance, and serves it with a vLLM-based serving image.
- The endpoint appears in Ship and is callable through the Inference Gateway like any other deployment.
New model lands automatically. The catalog is a registry — when a new frontier model is added, it appears with its presets and costs with no client update.
How the weights get there ("bake")
Before a catalog model is deployable, the platform bakes it: a background job downloads the exact model revision from HuggingFace into the platform's managed model storage, verifies it, and writes a manifest. Deploying requires the manifest — so you can never deploy a half-downloaded model. Baking is idempotent (re-running doesn't re-download) and admin-triggered.
Real-world examples
🧑💼 SaaS — a frontier model without the fine-tune project
A team wants DeepSeek V4 Flash for a research copilot. They pick the 128K preset, see the honest p5 per-hour rate, deploy, and point the gateway at it the same afternoon.
🏦 Financial services — long-context contract analysis
A legal-ops group needs to reason over entire contracts in one call. They pick the 1M context preset on DeepSeek V4 Flash — and the platform tells them exactly which instance class that requires (and its hourly cost) before they commit.
Gotchas
- Context presets are floors, not ceilings to guess at. Pick the smallest preset that fits your workload — 1M-context serving on H200-class hardware is the premium tier and prices accordingly.
- First deploy needs the artifact baked. If the model shows as "baking," it isn't deployable yet — that's the manifest gate protecting you from a broken endpoint.
- These are full-weight models on big instances. The honest per-hour rate is the point — plan around it (delete or keep-for-later when idle, see 13-cost-control.md).