Proposal: a ds4-worker worker hive
Summary
A worker hive whose bees raise ds4 distributed workers as cells. ds4.c already implements distributed (layer-sliced coordinator/worker) and 50/50 tensor-parallel modes, so this hive wraps the already-built data plane into hum's stencil model.
Motivation
This is the most directly valuable new hive: the distributed inference machinery already exists in ds4.c, but it is not yet a hum hive. Making it a worker hive lets hum commission ds4 distributed sessions as first-class cells, coordinated by the Nest pool and ensemble gossip, rather than running them ad hoc.
Hive stencil
- Typology: worker, optionally worker + forager (ds4-server already exposes OpenAI, Anthropic, and completion surfaces, so a dual-role bee is natural).
- Bee binary:
ds4-worker, launches ds4 as its cell with --role worker --layers A:B (or --role coordinator).
- Propensity:
StatefulSession (ds4 holds KV and session state) or StatelessPerCall.
- Richness: medium to rich (system, content, tools, pollen).
- Wire: thrum as a worker; optionally OpenAI
/v1/chat/completions as the forager surface so clients can hit the coordinator directly.
Egg spec (candidate)
- model gguf path, layer slice, kv-disk shard
- coordinator/worker listen addresses, activation bits (32/16/8)
- quant and ctx
Cell shape
One ds4 process. feed is the prompt JSON, mmm is the chunk stream, emerged is the process exit, silence cancels. Standard WorkerBee::raise(egg) -> Cell, tended by lifecycle.rs.
Integration with humd / Nest
Workers handshake a humd, announce bee:["worker"], become nestable. The coordinator waits for a complete layer route and streams hidden states through workers; humd should report route coverage. Ensemble gossip can coordinate worker discovery across humds on different machines.
Risks
- ds4 is DwarfStar-specific (V4 Flash and GLM-5.2 families); this hive is specialized, not generic.
- Network latency and bandwidth for hidden-state streaming between workers.
- Requires a ds4 worker binary on each participating machine.
Open questions
- How does the Nest / ensemble discover remote ds4 workers across machines?
- Should the coordinator be a dual-role (worker + forager) bee, or two separate hives?
- What is the right default activation-bit width given the bandwidth tradeoff (32/16/8)?
Proposal: a
ds4-workerworker hiveSummary
A worker hive whose bees raise ds4 distributed workers as cells. ds4.c already implements distributed (layer-sliced coordinator/worker) and 50/50 tensor-parallel modes, so this hive wraps the already-built data plane into hum's stencil model.
Motivation
This is the most directly valuable new hive: the distributed inference machinery already exists in ds4.c, but it is not yet a hum hive. Making it a worker hive lets hum commission ds4 distributed sessions as first-class cells, coordinated by the Nest pool and ensemble gossip, rather than running them ad hoc.
Hive stencil
ds4-worker, launches ds4 as its cell with--role worker --layers A:B(or--role coordinator).StatefulSession(ds4 holds KV and session state) orStatelessPerCall./v1/chat/completionsas the forager surface so clients can hit the coordinator directly.Egg spec (candidate)
Cell shape
One ds4 process.
feedis the prompt JSON,mmmis the chunk stream,emergedis the process exit,silencecancels. StandardWorkerBee::raise(egg) -> Cell, tended bylifecycle.rs.Integration with humd / Nest
Workers handshake a humd, announce
bee:["worker"], become nestable. The coordinator waits for a complete layer route and streams hidden states through workers; humd should report route coverage. Ensemble gossip can coordinate worker discovery across humds on different machines.Risks
Open questions