bf16: weights and card from the text-to-SQL panel

README.md

@@ -14,7 +14,7 @@ license_link: https://huggingface.co/mistralai/Mistral-7B-Instruct-v0.3
 
 # Mistral-7B-Instruct-v0.3 text-to-SQL, bf16
 
-mistralai/Mistral-7B-Instruct-v0.3 fine-tuned on text-to-SQL, merged and left in bf16. It is the ceiling arm of a panel of 7 arms: every quantized arm below was made from this checkpoint and allocated the same byte budget, so their accuracies differ by method and not by size.
+mistralai/Mistral-7B-Instruct-v0.3 fine-tuned on text-to-SQL, merged and left in bf16. It is the ceiling arm of a panel of 9 arms: every quantized arm below was made from this checkpoint and allocated the same byte budget, so their accuracies differ by method and not by size.
 
 ## What this is
 
@@ -22,6 +22,7 @@ mistralai/Mistral-7B-Instruct-v0.3 fine-tuned on text-to-SQL, merged and left in
 |---|---|
 | base model | [mistralai/Mistral-7B-Instruct-v0.3](https://huggingface.co/mistralai/Mistral-7B-Instruct-v0.3) |
 | fine-tune | lora r=32, 2.0 epoch over 39,531 text-to-SQL conversations |
+| the adapter it merged | [VikramPal/mistral-7b-instruct-v0.3-text2sql-lora](https://huggingface.co/VikramPal/mistral-7b-instruct-v0.3-text2sql-lora) |
 | training data | `gretelai/synthetic_text_to_sql`, `Salesforce/wikisql`, `b-mc2/sql-create-context` |
 | quantization | none -- this is the bf16 fine-tune every quantized arm was made from |
 | size on disk | 13.500 GiB (16.0000 bits per parameter) |
@@ -40,6 +41,8 @@ Execution match on 2,454 held-out text-to-SQL problems: the generated query is r
 | gptq_3b | 6.68% | 2.858 GiB | 3.3869 |
 | awq_3b | 74.16% | 2.858 GiB | 3.3869 |
 | dq_3b | 75.22% | 2.857 GiB | 3.3859 |
+| gptq_3b_asym_noao | 76.08% | 2.858 GiB | 3.3869 |
+| gptq_3b_asym | 3.99% | 2.858 GiB | 3.3869 |
 
 This arm, by evaluation source:
 
@@ -64,7 +67,7 @@ McNemar exact over the per-item hits, so every row is a paired test on the same
 
 ## What is not claimed
 
-- **The baselines run at their own libraries' defaults, and those defaults are not the same scheme.** GPTQ here is symmetric with no activation reordering; AWQ and DynQuant are asymmetric. Where a comparison above pairs a symmetric arm against an asymmetric one its delta spans two differences at once -- how the bits were allocated, and whether a zero point was stored per group -- so a large gap between those two arms is not on its own evidence about allocation. The comparison that would isolate it, two arms of the same scheme at the same byte anchor, is not in this panel.
+- **The arms above are not all the same scheme.** In this panel GPTQ runs symmetric with no activation reordering, asymmetric with no activation reordering, and asymmetric with group activation reordering; AWQ runs asymmetric with no activation reordering. DynQuant's quantizer is asymmetric and does not reorder columns, which is a property of the method rather than a recipe flag, so the panel records no scheme for its arms. Where a comparison above pairs a symmetric arm against an asymmetric one its delta spans two differences at once -- how the bits were allocated, and whether a zero point was stored per group -- so a large gap between those two arms is not on its own evidence about allocation. The comparison that isolates it is in this panel: `gptq_3b` and `gptq_3b_asym_noao` are the same method at the same byte anchor and differ in the scheme alone, so the difference between those two rows is the scheme and nothing else.
 - **Storage, measured; throughput, not.** The number reported here is bytes on disk and execution match. This card makes no claim about decode speed or peak VRAM against an fp16 baseline, because this panel did not measure either.
 - **One task.** Execution match on held-out text-to-SQL is what was scored. It says nothing about how this arm behaves on anything else, and a quantization that holds one task can lose another.