Repository navigation
Conversation
This was referenced Oct 14, 2026
Owner
Open
…he release's tf-dsv41-token-map derives the compressed key map from the original's tokenizer.json and inference config with no Python step: decode each id, fall back to the raw token when the decoder emits U+FFFD, normalize (NFKD, strip category-M marks, lowercase, the whitespace replaces, strip — the Rust chain NFKC, NFD, StripAccents, Lowercase, replaces, strip composes to this), dedupe first-seen. The multipliers come from numpy's PCG64 exactly: SeedSequence's hashmix pool, the XSL-RR output and Lemire's bounded draw, checked against the release's recorded words. The generated nfkd_data.zig ships with its generator, tools/zig/nfkd_tables.py, which rebuilds the table from unicodedata 16.0.0 (the version unicode_data.zig pins) and zig fmt, and whose --check fails on drift. The normalizer chain and the PCG64 draws have unit tests, wired into zig build test. The golden test is the release's own 517,680-byte engram-token-map.bin, reproduced byte for byte.
akol1
force-pushed
the
pr-dsv41-a-token-map
branch
from
October 18, 2026 22:21
1771788 to
98072f7
Compare
Owner
|
Thanks @akol1 for #824, alongside @jayleaton's CUDA chain. 1.1.1 includes your shared contribution. The Zig token-map builder and normalization data are shared with the CUDA Engram reader, keeping one metadata contract. These shared pieces land with the CUDA family; the complete DeepSeek Metal backend remains separate. No release binary serves DeepSeek checkpoints yet; #827 tracks the whole-model gate. Posted by Ash's AI Assistant Synthena |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Piece (a) of the #690 split, rebased onto the 1.1.0 release (
76aafcf27): the Engram token map built in Zig, byte-identical to the release's, with the table generator and the unit tests that keep it honest.The Engram metadata the model needs beside the checkpoint — the compressed key map — has so far required a Python step with the HuggingFace tokenizers and NumPy. This builds it in Zig from the original release's tokenizer.json and inference config: decode each id, fall back to the raw token when the decoder emits U+FFFD, normalize, dedupe first-seen.
The normalizer chain mirrors the release's Rust pipeline (NFKC, NFD, StripAccents, Lowercase, the whitespace replaces, strip), which composes to NFKD, strip-M*, lowercase — NFD(NFKC(x)) is NFKD(x), and Rust's StripAccents filters all of category M including Mc. The multipliers come from NumPy's PCG64 exactly: SeedSequence's hashmix pool, the XSL-RR output, Lemire's bounded draw — checked against the recorded words, not assumed. The generated NFKD tables come from unicodedata 16.0.0, the version
unicode_data.zigalready pins.What changed since the first revision, all of it from review feedback on this branch:
tools/zig/nfkd_tables.pyfollowstools/zig/unicode_tables.py: pinnedunicodedataversion and normalization version, the same// Generated by …header, a--checkmode that names the stale file and the script to rerun,zig fmtpost-processing so regeneration is byte-stable, stdlib only. No CI job runs a generator;--checkis there for a byte-identity audit. The table itself is unchanged.tools/zig/lean_check.pyadds the two Unicode table files toGENERATED, mirroring the exemption the checker already grants the Flash Next generator outputs (GENERATOR_OUTPUT). Additive; the 120-column comment rule and every other check still apply. Calling it out because it touches the shared checker.testblocks never compiled or ran underzig build test— which is how a wrong Hangul expectation survived several revisions.build.ziggained ahost_testsflag on the program table and the test step now depends on the program's test artifact. The first gated run caught it: the release chain composes가to U+1100 U+1161 with no recomposition, so the test expects the jamo sequence and says why.The golden test is the release's own file: the builder's output is byte-identical to the 517,680-byte engram-token-map.bin shipped beside the 2.9bpw pack (sha256
b9a7cf9d341f5daf8fc435dbc36153bf4b28c1b8075be20de30d0556fb910511,cmpclean), and the manifest's packed_sha256 matches. Run:zig build tf-dsv41-token-map && ./zig-out/bin/tf-dsv41-token-map --tokenizer <orig>/tokenizer.json --config <orig>/config.json --output /tmp/m.bin.Verification at this head:
zig build test -Dcpu=apple_m1exit 0 (295/295 steps), the token-map suite included.zig build native -Dcpu=apple_m1: 54/54 steps.python3 tools/zig/nfkd_tables.py --check --zig $ZIGexit 0; regeneratingnfkd_data.zigreproduces the committed file.tools/zig/lean_new.py /tmp/lean-base-110.txt …: 503 problems on the 1.1.0 base, 503 here, 0 new.zig fmt --check build.zig zigclean.The load-time wiring (building the map at open when it is missing and the original's tokenizer sits beside the tables) lands with the lane-backend piece, where the host lives. #825 stacks on this branch.