Row: ENG-HYBRID-PLACEMENT
What
ENG-HYBRID-PLACEMENT has two waves that are blocked on hardware, and the issue
that owned them no longer exists.
.agents/specs/hybrid-placement.md cites #149 five times — including as the
row's own campaign issue in its | Row ID | line — and #149 returns 404 to an
unauthenticated reader while a known-live issue returns 200 from the same probe.
#147, cited beside it as the multi-GPU half, is also 404. So the row's records
point at two deleted owners, and its blocked work has had no tracker.
What is actually owed
W0 — the measured DDR:PCIe ratio and the per-MoE-layer round-trip cost.
## The honest bandwidth math in the spec decides whether this row is worth
anything at all, and every number in it comes from published link rates rather
than from measurement. The spec says so itself: the row is worthless if the real
ratio is below ~1.5x, "and that is a plausible outcome on a rig with slow
single-rank memory."
W5 — the speed floor against llama.cpp -ncmoe at pin b10451. The
correctness side is done and measured: NMSE 5.239e-06 for the cpu_moe arm and
3.569e-05 for --fit, on GB10/sm_121 against
Qwen3.8-Flash-Next-UD-IQ1_S. What has never been measured is whether placement
is FASTER than not placing.
Why it is blocked, precisely
Placement moves activations over a bus to buy device memory. On a unified-memory
part there is no bus to cross and no memory to buy, so the capability is inert by
construction and the axis cannot be measured — not "is hard to measure".
rc devices lists dgx:gpu0, orin:gpu0 and thor:gpu0. All three are
integrated parts. The fleet contains no device that can measure this row's
speed axis.
What would unblock it
One discrete-GPU host with a PCIe-attached accelerator and host DRAM. Nothing
else about the row changes: the seam, the plan resolver, the --fit resolver and
the gates all exist and are exercised on CPU today
(test_placed_moe_roundtrip.cpp executes the placed branch with no GPU at all).
Until then
No speed claim may cite this row, and the bandwidth table in the spec stays
marked as an assumption. That is the state today and this issue exists so it is
visible rather than implied by a dead link.
Row:
ENG-HYBRID-PLACEMENTWhat
ENG-HYBRID-PLACEMENThas two waves that are blocked on hardware, and the issuethat owned them no longer exists.
.agents/specs/hybrid-placement.mdcites #149 five times — including as therow's own campaign issue in its
| Row ID |line — and #149 returns 404 to anunauthenticated reader while a known-live issue returns 200 from the same probe.
#147, cited beside it as the multi-GPU half, is also 404. So the row's records
point at two deleted owners, and its blocked work has had no tracker.
What is actually owed
W0 — the measured DDR:PCIe ratio and the per-MoE-layer round-trip cost.
## The honest bandwidth mathin the spec decides whether this row is worthanything at all, and every number in it comes from published link rates rather
than from measurement. The spec says so itself: the row is worthless if the real
ratio is below ~1.5x, "and that is a plausible outcome on a rig with slow
single-rank memory."
W5 — the speed floor against llama.cpp
-ncmoeat pinb10451. Thecorrectness side is done and measured: NMSE 5.239e-06 for the
cpu_moearm and3.569e-05 for
--fit, on GB10/sm_121againstQwen3.8-Flash-Next-UD-IQ1_S. What has never been measured is whether placementis FASTER than not placing.
Why it is blocked, precisely
Placement moves activations over a bus to buy device memory. On a unified-memory
part there is no bus to cross and no memory to buy, so the capability is inert by
construction and the axis cannot be measured — not "is hard to measure".
rc deviceslistsdgx:gpu0,orin:gpu0andthor:gpu0. All three areintegrated parts. The fleet contains no device that can measure this row's
speed axis.
What would unblock it
One discrete-GPU host with a PCIe-attached accelerator and host DRAM. Nothing
else about the row changes: the seam, the plan resolver, the
--fitresolver andthe gates all exist and are exercised on CPU today
(
test_placed_moe_roundtrip.cppexecutes the placed branch with no GPU at all).Until then
No speed claim may cite this row, and the bandwidth table in the spec stays
marked as an assumption. That is the state today and this issue exists so it is
visible rather than implied by a dead link.