[PD serving] Native Furiosa KV receiver for external decoders #136

Problem

Native Furiosa prefill has no direct Python KV export API for an external torch/ATOM decoder. We need a reproducible, version-bounded receiver and a correctness gate before engine integration.

Evidence

On RNGD with furiosa-llm/native 2026.4.0 and Qwen3-8B-FP8 (context 2048), an independent Python ZMQ receiver obtained 442368 bytes for a four-token prompt, in 18 batches, with no native decoder running. Payload was byte-identical to a native-PD capture; acknowledging the transfer completed the prefiller HTTP request with status 200. The initial receiver replays fixed control messages. Native PD and standalone text matched 3/4 tiny cases; the two-token case diverged, cause unresolved.

Scope

• Standalone experimental protocol codec/receiver with bounded parsing, explicit version/layout limits, reproducible synthetic-prompt tests, and no vendor binary redistribution.
• Replace captured control-message replay with parameterized messages.
• Validate slot-to-layer/K/V mapping and canonical tensors; compare first-step logits before torch/ATOM admission.
• Keep this experimental and outside default serving until correctness is demonstrated. No throughput claim from the current busy-host runs.

Related to #132 (prefill throughput), #59 (heterogeneous engines), #69 (scrubbed evidence), #71 (layout).

Done when

The receiver handles multiple request IDs and prompt lengths without replay files; malformed/incompatible inputs are rejected; hardware evidence is reproducible with hashes and small summaries; canonical KV and first-step logits are validated against a matching reference, or unresolved limitations remain explicitly tracked before integration.

Owner

@gspark-etri (implementation assisted by Codex; maintainer review and merge).