Skip to content

Prototype and A/B a fused per-card Stage C/D worker against #669's pooled batching #675

Description

@WilfordGrimley

Question on record

Raised 2026-08-03: would a single fused worker doing fetch -> compute -> Stage D per card beat
PR #669's pooled batching (a fetch thread pool feeding a compute process pool, with Stage D
serialized in the parent)?

Estimates, not benchmarks

Explicitly modelled, not measured. Both numbers below are derived from the n=200 profile in
docs/reports/2026-07-20-pipeline-compute-profile.md (per-card means: fetch 743.0ms,
compute 1175.7ms at the time of measurement, since roughly halved).

Pooled (#669 as shipped): ~3.3 cards/s — the min of 3 fetch threads at ~909ms and 3 compute
processes at ~655ms. Costs ~1.8MiB of pickle/IPC per card, plus Stage D serialized in the parent.

Fused (6-8 workers, each ~50% CPU-busy): ~4.4 cards/s. No IPC. Reuses the
run_image_evidence_cohort pattern, which is proven in production at 63.1% parallel efficiency.
Costs per-worker efficiency and eats host-load headroom near the 7.0 envelope trip ceiling —
which matters because the prod stage-e-fullcat pass still shares this box.

Recommendation on record

Do not cancel #669. Prototype the fused worker (~1 day) and A/B it on the same box after
#669 merges and pooled is proven in production. The comparison is only meaningful against a
pooled baseline that has actually run against the catalogue.

Acceptance

  • a fused prototype exists behind a flag, not replacing the pooled path
  • both are measured on the same host, same cohort, same time-of-day, with host-load envelope
    readings captured for each
  • the decision is recorded with the measurement, not with the estimate above

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions