outfit remote deploy can carry a companion weight — a speculative drafter, an mmproj — to the cloud, but only from the model's own repo. parseCompanions rejects any value containing / (remote/lambda/shared/deploy-config.ts:255), buildSeedJob carries a single modelId (seed/launch.ts:96), applySelection resolves the companion inside that one repo's listing (seed/contract.ts:273), and companionsFrom reduces the preset value to its basename (cmd/outfit/remote.go:1347).
That holds for Muse-Glimmer, whose DFlash drafter ships beside its weights. It does not hold in general.
Example: DFlash2 on Qwen3.8-27B
The base weights are ggml-org/Qwen3.8-27B-GGUF:Q4_K_M (19 GB); the drafter is published separately as incoai/Qwen3.8-27B-DFlash2-GGUF (1.1 GB at Q4_K_M). Both fit an L40S alongside a 128k q8 KV cache, and llama.cpp has carried DFlash2 since b10658 — but the drafter cannot be seeded, so the endpoint has to run without it.
Neither workaround is attractive. Mirroring both files into one repo means owning a 20 GB copy. Letting --spec-draft-hf pass through to llama-server reintroduces a Hugging Face fetch at engine start — unpinned, absent from _seed.json, and repeated on every fresh launch, which is the dependency the S3 seed exists to remove.
Proposal
Let a companion name its own repo. The preset dialect already has the spelling: hfd = incoai/Qwen3.8-27B-DFlash2-GGUF:Q4_K_M, canonicalised to spec-draft-hf. outfit remote deploy would read it the way it already reads hf for the model and emit a repo-qualified companion, instead of letting it pass through into serveArgs.
Touches:
companionsFrom and DeployConfig.Companions (Go)parseCompanions — relax the / rule to a repo-qualified formSeedSelection.companions and applySelection- the seeder — a second
listSelectedFiles/resolveRevision, and a manifest recording both revisions
outfit remote deploycan carry a companion weight — a speculative drafter, an mmproj — to the cloud, but only from the model's own repo.parseCompanionsrejects any value containing/(remote/lambda/shared/deploy-config.ts:255),buildSeedJobcarries a singlemodelId(seed/launch.ts:96),applySelectionresolves the companion inside that one repo's listing (seed/contract.ts:273), andcompanionsFromreduces the preset value to its basename (cmd/outfit/remote.go:1347).That holds for Muse-Glimmer, whose DFlash drafter ships beside its weights. It does not hold in general.
Example: DFlash2 on Qwen3.8-27B
The base weights are
ggml-org/Qwen3.8-27B-GGUF:Q4_K_M(19 GB); the drafter is published separately asincoai/Qwen3.8-27B-DFlash2-GGUF(1.1 GB at Q4_K_M). Both fit an L40S alongside a 128k q8 KV cache, and llama.cpp has carried DFlash2 since b10658 — but the drafter cannot be seeded, so the endpoint has to run without it.Neither workaround is attractive. Mirroring both files into one repo means owning a 20 GB copy. Letting
--spec-draft-hfpass through tollama-serverreintroduces a Hugging Face fetch at engine start — unpinned, absent from_seed.json, and repeated on every fresh launch, which is the dependency the S3 seed exists to remove.Proposal
Let a companion name its own repo. The preset dialect already has the spelling:
hfd = incoai/Qwen3.8-27B-DFlash2-GGUF:Q4_K_M, canonicalised tospec-draft-hf.outfit remote deploywould read it the way it already readshffor the model and emit a repo-qualified companion, instead of letting it pass through intoserveArgs.Touches:
companionsFromandDeployConfig.Companions(Go)parseCompanions— relax the/rule to a repo-qualified formSeedSelection.companionsandapplySelectionlistSelectedFiles/resolveRevision, and a manifest recording both revisions