Update model card and export table

README.md

@@ -271,18 +271,20 @@ A vLLM serving path for GPU servers is in preparation.
 
 ### Ready-made GGUF
 
-`parallax-8b-lambda-431B-tokens.gguf` at the repository root (2,133,006,592 bytes, 2.13 GB, sha256
-`687296380f21e2c133b6d00668e09a70e1fc5488186b27a4e4ca20cdf4ddd694`, also in the `.sha256` file next to it) was
-converted from `exports/431B-tokens_step35140` (431.9B training tokens, step 35140).
+`parallax-8b-lambda-525B-tokens.gguf` at the repository root (2,133,006,592 bytes, 2.13 GB, sha256
+`7a20cb014a3b125e14979871e9adb6bc57a9b194f46d6638325ee9daf8cb5aec`, also in the `.sha256` file next to it) was
+converted from `exports/525B-tokens_step42242` (525.2B training tokens, step 42242).
 It keeps the export's bf16 trunk and stores the routed experts' exact ternary codes and per-row scales;
 no weight is requantized. Each GGUF is a snapshot of one export and is not updated as new exports are added.
 To use a later export, convert it yourself (see `tools/parallax/README.md` on the branch).
 
-The earlier snapshot, `parallax-8b-lambda-381B-tokens.gguf`, from `exports/381B-tokens_step30942`, remains at
-the repository root (sha256 `86312194ffc72b7b8d87f37389fe0fdfe7c510e2f6066f0c424cc0eaf592aedf`).
+The earlier snapshots remain at the repository root: `parallax-8b-lambda-431B-tokens.gguf`, from
+`exports/431B-tokens_step35140` (sha256 `687296380f21e2c133b6d00668e09a70e1fc5488186b27a4e4ca20cdf4ddd694`),
+and `parallax-8b-lambda-381B-tokens.gguf`, from `exports/381B-tokens_step30942` (sha256
+`86312194ffc72b7b8d87f37389fe0fdfe7c510e2f6066f0c424cc0eaf592aedf`).
 
 ```bash
-hf download chutesai/parallax-8b-lambda parallax-8b-lambda-431B-tokens.gguf --local-dir .
+hf download chutesai/parallax-8b-lambda parallax-8b-lambda-525B-tokens.gguf --local-dir .
 hf download NousResearch/Meta-Llama-3-8B tokenizer.json --local-dir .   # Llama 3 tokenizer
 ```
 
@@ -299,12 +301,12 @@ pip install tokenizers
 
 # Apple GPU
 python tools/parallax/run.py --binary build/bin/llama-parallax \
-  --model ../parallax-8b-lambda-431B-tokens.gguf --tokenizer ../tokenizer.json \
+  --model ../parallax-8b-lambda-525B-tokens.gguf --tokenizer ../tokenizer.json \
   --backend metal --experts lut9 --prompt 'The capital of France is' --predict 64
 
 # CPU (x86-64 or ARM64)
 python tools/parallax/run.py --binary build/bin/llama-parallax \
-  --model ../parallax-8b-lambda-431B-tokens.gguf --tokenizer ../tokenizer.json \
+  --model ../parallax-8b-lambda-525B-tokens.gguf --tokenizer ../tokenizer.json \
   --backend cpu --experts lut8 --threads 8 --prompt 'The capital of France is' --predict 64
 ```
 
@@ -330,22 +332,22 @@ same results but is not tuned for speed: on a shared, loaded 64-core AMD EPYC 95
 
 ### Fidelity
 
-The 431B GGUF was checked on CPU with `lut` against the training code's own model loaded from the same
+The 525B GGUF was checked on CPU with `lut` against the training code's own model loaded from the same
 export, with FP32 activations in both, on the same 2,555 held-out positions from public text and code
-passages as before. Mean KL was 1.7e-6 nats/token, the top-1 next token agreed at 2,554 of 2,555 positions,
+passages as before. Mean KL was 4.0e-7 nats/token, the top-1 next token agreed at all 2,555 positions,
 and three 48-token greedy continuations matched exactly.
 
-The small differences trace to two tokens where the router's expert-selection scores for the 12th and
-13th expert were tied or within a few FP32 rounding steps (in one case exactly tied in the reference).
-The two implementations picked different experts there, and the difference carried forward in that
-passage. When the reference was given the runtime's choice at those two tokens, mean KL was about
-6e-10 nats/token and the top-1 next token agreed at every position.
+The remaining differences trace to two tokens where the router's 12th- and 13th-ranked expert-selection
+scores were within a few FP32 rounding steps. The two implementations picked different experts there,
+and the difference carried forward in that passage. Excluding the positions from each of those two
+tokens onward in its passage (2,261 positions remain), mean KL was 7.6e-10 nats/token with top-1
+agreement at every position.
 
 The training code itself runs in bf16; against that bf16 forward the top-1 agreement was 94.9% (mean
 KL 0.0027, measured on the earlier `270B-tokens_step23035` export), which reflects the bf16 rounding
 of the reference, not an error of the runtime.
 
-On the 431B GGUF, Metal and CPU had per-layer relative error within 2.2e-5 at the final position of
+On the 525B GGUF, Metal and CPU had per-layer relative error within 1.9e-5 at the final position of
 a 512-token text, and identical 48-token greedy continuations on three prompts. `lut8` (CPU)
 quantizes expert lookup tables to 8 bits and is slightly approximate; `lut` and `lut9` are exact.
 
@@ -371,4 +373,4 @@ alignment or safety tuning, and it is small and far from converged.
 
 MIT.
 
-<sub>Table updated 2026-10-07 11:56 UTC.</sub>
+<sub>Table updated 2026-10-07 11:58 UTC.</sub>