Ho thanks for the comment.
Verification does not depend on temperature.
Expert execution is deterministic (pure matmul).
LUMABRI_VERIFY=N re-runs N% of the calls on a second replica and requires byte-identical output.
Temperature (and sampling) happens only on the chatter, after the experts return their activations.
So it can be any value (0, 0.7, 1.2…) without affecting the verification contract.
There are fixed-point models too which can be deterministic. But for floating point you are very instruction-set dependent, never mind floating point operations not being commutative.
The harder case isn't same-hardware determinism; it's that lumabri wants CPU and GPU peers in the same swarm. Accumulation order differs across hardware, not just across runs.
Ho thanks for the comment. Verification does not depend on temperature. Expert execution is deterministic (pure matmul). LUMABRI_VERIFY=N re-runs N% of the calls on a second replica and requires byte-identical output. Temperature (and sampling) happens only on the chatter, after the experts return their activations. So it can be any value (0, 0.7, 1.2…) without affecting the verification contract.
> Expert execution is deterministic (pure matmul).
Isn't that only true in theory but wrong in practice due to floating points?
There are fixed-point models too which can be deterministic. But for floating point you are very instruction-set dependent, never mind floating point operations not being commutative.
The harder case isn't same-hardware determinism; it's that lumabri wants CPU and GPU peers in the same swarm. Accumulation order differs across hardware, not just across runs.
[dead]