Update TwIL-LM3: weights, tokenizer and model card

README.md

@@ -211,6 +211,7 @@ carried into the GGUF metadata, so chat mode works without extra flags.
 |---|---|---:|---:|---|
 | `TwIL-LM3-Q4_K_M.gguf` | Q4_K_M | 1.78 GiB | 4.96 | recommended default; runs on CPU or 4 GB of VRAM |
 | `TwIL-LM3-Q8_0.gguf` | Q8_0 | 3.05 GiB | 8.50 | near-lossless, for quality-sensitive use |
+| `TwIL-LM3-F16.gguf` | F16 | 5.73 GiB | 16.00 | unquantized, for requantization or reference runs |
 
 ```bash
 llama-cli -m TwIL-LM3-Q4_K_M.gguf -cnv --temp 0 -n 2048
@@ -221,11 +222,15 @@ evaluation is greedy while the packaged sampling defaults are not. And leave the
 budget large — 2048 tokens or more — since the model emits a `<think>` block before answering
 and a short budget truncates it, which costs far more accuracy than the quantization does.
 
-Q8_0 was produced directly by `convert_hf_to_gguf.py` from the released bf16 weights; Q4_K_M was
-produced from an F16 conversion with `llama-quantize`, without an importance matrix. Both builds
-were smoke-tested for load and generation on CPU. The published Track A and Track B numbers were
-measured on the **bf16** weights through vLLM, not on these GGUF builds, so expect small
-deviations at Q4_K_M that have not been quantified here.
+F16 and Q8_0 were produced directly by `convert_hf_to_gguf.py` from the released bf16 weights;
+Q4_K_M was quantized from the F16 build with `llama-quantize`, without an importance matrix. All
+three were smoke-tested for load and generation on CPU. Note that F16 is not bit-identical to the
+released weights: bf16 and f16 carry the same 16 bits but trade exponent range against mantissa
+precision, so the conversion is a narrowing one, in practice negligible for inference.
+
+The published Track A and Track B numbers were measured on the **bf16** weights through vLLM, not
+on any of these GGUF builds, so expect small deviations — most likely at Q4_K_M — that have not
+been quantified here.
 
 ## How it was built