Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →dstackai/dstack-prototyping
Use with the dstack skill for model-serving work when the image, serving command, resources, backend/fleet choice, or service behavior is not proven. Guides task-first prototyping on real hardware, choosing fleets/backends that can reuse idle instances and caches, checking vLLM/SGLang sources, and verifying the final dstack service with a model request.
Passed 16 of 21 test cases with the skill, and 9 of 21 without it.
and 7 more in the full report
9 fixed8 passed either way4 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
This benchmark measured an earlier version of the skill.
A newer attempt on gemini-3.6-flash on 10/3/2026 did not produce a publishable comparison (not comparable). The snapshot above is the previously measured run.
One of 9 test cases the skill fixed. Same model, same prompt, with and without the skill.
What CLI command inspects the JSON definition of an existing fleet named 'gpu-cluster' in dstack?
| Checked | Without skill | With skill |
|---|---|---|
| Executes dstack fleet get gpu-cluster --json | Missed | Passed |
The instructions your model reads when the skill loads.
Use /dstack for CLI commands, YAML fields, apply/attach behavior, service URLs,
and other dstack syntax. This skill explains how to use dstack runs while the
model-serving configuration is still unknown.
Find a working dstack service configuration for the requested model.
Before submitting a service, use a task on real hardware to test the serving image, install/runtime assumptions, model download, cache path, command, port, launch flags, resources, env vars, backend/fleet choice, and local model request. Then submit the same configuration as a service and verify the model through the dstack service URL.
Pick the offer whose hardware best fits the goal at hand. Only when several offers fit comparably, choose a VM-based backend, an SSH fleet, or a Kubernetes fleet: they support idle instances and/or instance volumes, so later runs reuse the provisioned/idle instance or instance volumes for caching model weights (and possibly other writes), while container-based backends start clean on every run.
Fetch https://dstack.ai/docs/concepts/backends.md and classify backends
from the fetched document, not from memory.
If the intention is to use PD disaggregation, the fleet must use placement: cluster. Since PD disaggregation implies running a router, unlike workers that must run on GPUs, the router normally should run on a CPU instance. Use dstack fleet to see existing fleets and dstack fleet get <fleet name> --json to inspect a specific fleet.
Check serving-framework sources early enough to choose the image, command, launch flags, resources, cache paths, request format, and expected model behavior.
For vLLM and SGLang, use these as credible sources:
https://recipes.vllm.ai/ and
https://recipes.vllm.ai/models.jsonhttps://docs.sglang.io/ (fetch /llms.txt for the page
index)https://docs.sglang.io/cookbook/autoregressive/introhttps://github.com/vllm-project/vllm/releases and
https://github.com/sgl-project/sglang/releasestest cases passed, vs 9 / 21 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.