Context
Since the seal-based registration contract (fix/mtp-layer-count), the engine derives the instance layer-id space from the layers workers actually register: sorted layer names → dense ids, slot ownership validated at seal time. Blocks are stored keyed by (namespace, hash) with a slot array of num_layers * tp_size entries.
The namespace is still entirely client-chosen. Two instances whose layer sets differ — the obvious case is the same model with MTP enabled vs disabled (num_nextn_predict_layers present in config, drafter layers registered or not) — can legally point at the same namespace. Their blocks are mutually unusable:
- Different slot counts: load now fails loudly (
stored block has N slots but instance expects M), which is correct but means a warm namespace keeps reporting hits that can never be served.
- Same slot count, different layer sets or geometry: undetectable today. The block decodes "successfully" into the wrong layers.
We currently operate under the assumption that a namespace is only ever used by one KV layout (deployment discipline). This issue is about whether the engine should enforce that instead.
Proposal
At seal time the engine has everything that defines block layout compatibility:
fingerprint = hash(sorted (layer_name, bytes_per_block, segments))[:8]
namespace_final = f"{client_namespace}.{fingerprint}"
Appending the fingerprint server-side would make incompatible layouts land in disjoint namespaces by construction — MTP on/off, different quantization (bytes_per_block), different attention layouts all separate automatically, with zero client coordination.
Open questions:
block_size (tokens per block) is part of compatibility but not visible to the engine at registration — it lives in the connector's hash computation. Include it in the register RPC so the fingerprint covers it?- MetaServer entries and SSD index keys would inherit the final namespace; cross-node discovery then only matches truly compatible peers. Any migration concern for existing SSD/metaserver data?
- Should the fingerprint be part of the namespace string (observable, greppable in logs) or a separate validated field?
Related
pd_connector still rejects models whose config carries MTP fields even when MTP is disabled (PdConnector does not support MTP layout assertion keyed off num_nextn_predict_layers). Same family of bug as the one the seal contract fixed for the main connector: decisions keyed off config guesses instead of the actual runtime layer set.
Context
Since the seal-based registration contract (fix/mtp-layer-count), the engine derives the instance layer-id space from the layers workers actually register: sorted layer names → dense ids, slot ownership validated at seal time. Blocks are stored keyed by
(namespace, hash)with a slot array ofnum_layers * tp_sizeentries.The namespace is still entirely client-chosen. Two instances whose layer sets differ — the obvious case is the same model with MTP enabled vs disabled (
num_nextn_predict_layerspresent in config, drafter layers registered or not) — can legally point at the same namespace. Their blocks are mutually unusable:stored block has N slots but instance expects M), which is correct but means a warm namespace keeps reporting hits that can never be served.We currently operate under the assumption that a namespace is only ever used by one KV layout (deployment discipline). This issue is about whether the engine should enforce that instead.
Proposal
At seal time the engine has everything that defines block layout compatibility:
Appending the fingerprint server-side would make incompatible layouts land in disjoint namespaces by construction — MTP on/off, different quantization (bytes_per_block), different attention layouts all separate automatically, with zero client coordination.
Open questions:
block_size(tokens per block) is part of compatibility but not visible to the engine at registration — it lives in the connector's hash computation. Include it in the register RPC so the fingerprint covers it?Related
pd_connectorstill rejects models whose config carries MTP fields even when MTP is disabled (PdConnector does not support MTP layoutassertion keyed offnum_nextn_predict_layers). Same family of bug as the one the seal contract fixed for the main connector: decisions keyed off config guesses instead of the actual runtime layer set.