用途：在模型服务配置尚未确定时，用 dstack 任务（task）在真实硬件上做原型验证，找到可用的服务配置，再提交为 dstack 服务。CLI 命令、YAML 字段、apply/attach 行为与服务 URL 等语法请配合 /dstack 技能使用。
主要能力与流程：先选运行位置，按目标硬件匹配 offer；仅在多个 offer 相当接近时，优先 VM 后端、SSH fleet 或 Kubernetes fleet，因为它们支持空闲实例或实例卷，后续运行可复用已配置实例或实例卷缓存模型权重，而容器后端每次运行都从干净状态开始。后端分类需抓取 https://dstack.ai/docs/concepts/backends.md 后按文档判断，不要凭记忆。若计划使用 PD 分离，fleet 必须使用 placement: cluster；路由器通常跑在 CPU 实例上。可用 dstack fleet 查看现有 fleet，用 dstack fleet get <fleet name> --json 检查具体 fleet。
使用方式：提交服务前先启动长驻任务，例如 commands: - sleep infinity，分离提交后 attach 或 SSH 进入，在真实环境中测试镜像、安装、模型下载与缓存路径、服务命令、端口、启动参数、本地模型请求与预期行为。非交互 SSH 后台启动长命令时用 nohup 并重定向，例如 nohup vllm serve ... </dev/null > /tmp/vllm.log 2>&1 &。若镜像、硬件或主要安装路径变化，需重新提交任务测试。不要只检查 GPU 可见性、导入、日志或健康端点就转服务，必须在任务内启动服务器并发送使用目标模型的请求。任务验证通过后再提交服务，用服务 URL 复测同一模型请求。
限制与注意：服务验证失败若涉及镜像、安装、模型下载、命令、资源、缓存或模型行为，应回到任务；若仅 dstack 服务配置有误，修正后重新提交。使用路由器时，任务用 node groups、服务用 replica groups；任务即使分组也要用 sleep infinity（写在每个 group 的 commands 中，分组时不允许顶层 commands），实际命令通过 SSH 交互执行；测试推理应调用路由器端点而非直接调用 worker。尽可能用 gRPC 而非 HTTP 连接 worker。可参考 dstack 文档中 tasks 的 Prototyping services、services 的 Router 与 PD disaggregation 章节。