Conversion output differences exceed acceptable tolerance

[noahgift]

Summary

MVP qualification tests show that format conversions produce significantly different outputs. The diff values are ~0.5-0.8 while the acceptable epsilon is 1e-6.

Evidence (Source of Truth)

From fresh runs on 2026-02-06 with apr-cli 0.2.12:

0.5B Model (output/mvp-0.5b/evidence.json)

F-CONV-S-G: Conversion SafeTensors → Gguf produced different output (diff: 8.00e-1, ε: 1.00e-6)
F-CONV-S-A: Conversion SafeTensors → Apr produced different output (diff: 7.67e-1, ε: 1.00e-6)
F-CONV-A-S: Conversion Apr → SafeTensors produced different output (diff: 8.12e-1, ε: 1.00e-6)
F-CONV-A-G: Conversion Apr → Gguf produced different output (diff: 8.00e-1, ε: 1.00e-6)
F-CONV-RT-002: Round-trip conversion produced different output
F-CONV-RT-003: Round-trip conversion produced different output

1.5B Model (output/mvp-1.5b/evidence.json)

F-CONV-S-G: Conversion SafeTensors → Gguf produced different output (diff: 7.89e-1, ε: 1.00e-6)
F-CONV-S-A: Conversion SafeTensors → Apr produced different output (diff: 5.44e-1, ε: 1.00e-6)
F-CONV-A-S: Conversion Apr → SafeTensors produced different output (diff: 8.08e-1, ε: 1.00e-6)
F-CONV-A-G: Conversion Apr → Gguf produced different output (diff: 8.07e-1, ε: 1.00e-6)

Expected Behavior

Converted models should produce outputs that differ by less than epsilon (1e-6) from the original.

Actual Behavior

Outputs differ by 0.5-0.8 (50-80% different), which is catastrophically bad for model quality.

Impact

• P0 CRITICAL: Converted models may produce garbage or wrong outputs
• Golden Rule Test violation: "Converted models MUST produce the same output as the original"
• Blocks certification for all formats except ground truth SafeTensors

Test Command

cargo run --release --bin apr-qa -- run playbooks/models/qwen2.5-coder-0.5b-mvp.playbook.yaml --output evidence.json

Root Cause Investigation Needed

1. Are weights being transposed incorrectly during conversion?
2. Is quantization causing significant precision loss?
3. Are tokenizer differences causing output divergence?

Links

• Evidence: apr-model-qa-playbook/output/mvp-0.5b/evidence.json
• Evidence: apr-model-qa-playbook/output/mvp-1.5b/evidence.json
• Playbooks: apr-model-qa-playbook/playbooks/models/qwen2.5-coder-*.playbook.yaml

[noahgift]

2026-02-07 re-run confirms same diffs

Fresh run with apr-model-qa-playbook @ e7335e6:

Gate	Conversion	Diff	ε
F-CONV-A-G	APR → GGUF	8.00e-1	1e-6
F-CONV-S-G	ST → GGUF	8.00e-1	1e-6
F-CONV-A-S	APR → ST	8.12e-1	1e-6
F-CONV-S-A	ST → APR	7.67e-1	1e-6

These are identical to the 2026-02-06 run. The diffs are stable and reproducible.

New data point: F-GOLDEN-RULE-001 still passes (inference on convert(ST→APR) matches inference on raw ST), meaning the APR conversion preserves inference semantics. The pairwise diff metric may be comparing output fingerprint hashes rather than semantic equivalence — the measurement method needs investigation before concluding the conversions are actually broken.

Also: F-CONTRACT-I4-001 (statistical preservation) now runs to completion (path bug fixed) but reports that statistics diverge between SafeTensors and APR. This is consistent with the conversion diff findings.

This blocks 7/45 gates in the 0.5B MVP qualification (see #218).

[noahgift]

Five-Whys Root Cause Analysis

Symptom: Exported GGUF files produce garbage output ("Masksolarsolarsolarsolar...") on both CPU and GPU inference.

1. Why garbage output?

Attention weight tensors (attn_q, attn_k, attn_v, attn_output) in the exported GGUF contained all-zero Q4K blocks — d=6.1e-5, all quant bytes=0x00. With zero attention weights, the transformer can't route information between positions.

2. Why all-zero Q4K blocks?

The export_to_gguf() Q4K quantizer received near-zero f32 input data for attention tensors. The second quantization correctly encoded nearly-zero values as nearly-zero Q4K blocks.

3. Why near-zero f32 data reaching the GGUF quantizer?

Double quantization bug: apply_export_quantization() (line 218) ran a quantize_q4_k() → dequantize_q4_k_to_f32() roundtrip BEFORE export_to_gguf() ran its own Q4K quantization. This quantize→dequantize→requantize chain corrupted small-magnitude attention weights.

4. Why does double quantization corrupt attention but not FFN weights?

Attention weights for Qwen2 0.5B have typical range ±0.05 (small magnitude), while FFN weights have range ±0.3 (larger magnitude). The flat quantize_q4_k() → dequantize_q4_k_to_f32() roundtrip uses sanitize_f16_scale() which zeros f16 subnormal scales (< 6.1e-5). For attention weights, the global Q4K scale d = max_range / (15 × 63) falls near the f16 subnormal boundary, causing precision collapse during the unnecessary first roundtrip.

5. Why wasn't double quantization caught?

apply_export_quantization() was designed for non-GGUF formats (SafeTensors, APR) where pre-quantization is meaningful. When GGUF export added its own Q4K path, no guard was added to skip the pre-quantization step. The existing DOUBLE-QUANT-001 check only caught re-quantizing already-quantized APR sources, not the case where the export format handles quantization internally.

Fix

export.rs:apply_export_quantization(): Skip pre-quantization when options.format == ExportFormat::Gguf, since export_to_gguf() quantizes directly from F32 to Q4K binary format.

Verification:

• apr run /tmp/test-export-gh215.gguf --prompt "What is 2+2?" → 2+2=4. ✓ (was "Masksolarsolar..." before fix)
• Both CPU and GPU produce correct output
• All 162 export tests pass
• Clippy clean

Contract/Tooling Gap

The GGUF export contract should enforce a single-quantization invariant: data must go through exactly one quantization step, never two. The DOUBLE-QUANT-001 check was incomplete — it only validated source format, not the interaction between pre-quantization and format-specific quantization.

[noahgift]

Fixed: removed double quantization in GGUF export path. Attention weights now correctly quantized from F32→Q4K in a single pass.