ncm-benchmarks 2.0.0__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- ncm_benchmarks-2.0.0/LICENSE +21 -0
- ncm_benchmarks-2.0.0/NOTICE +43 -0
- ncm_benchmarks-2.0.0/PKG-INFO +275 -0
- ncm_benchmarks-2.0.0/README.md +245 -0
- ncm_benchmarks-2.0.0/ncm_bench/cli.py +650 -0
- ncm_benchmarks-2.0.0/ncm_bench/inference.py +609 -0
- ncm_benchmarks-2.0.0/ncm_bench/longdoc.py +160 -0
- ncm_benchmarks-2.0.0/ncm_bench/mbr.py +141 -0
- ncm_benchmarks-2.0.0/ncm_bench/metrics.py +153 -0
- ncm_benchmarks-2.0.0/ncm_bench/progressive.py +172 -0
- ncm_benchmarks-2.0.0/ncm_benchmarks.egg-info/PKG-INFO +275 -0
- ncm_benchmarks-2.0.0/ncm_benchmarks.egg-info/SOURCES.txt +31 -0
- ncm_benchmarks-2.0.0/ncm_benchmarks.egg-info/dependency_links.txt +1 -0
- ncm_benchmarks-2.0.0/ncm_benchmarks.egg-info/entry_points.txt +2 -0
- ncm_benchmarks-2.0.0/ncm_benchmarks.egg-info/requires.txt +19 -0
- ncm_benchmarks-2.0.0/ncm_benchmarks.egg-info/top_level.txt +3 -0
- ncm_benchmarks-2.0.0/ncm_train/__init__.py +11 -0
- ncm_benchmarks-2.0.0/ncm_train/ncm_trainer.py +147 -0
- ncm_benchmarks-2.0.0/ncm_train/vqvae_trainer.py +117 -0
- ncm_benchmarks-2.0.0/pyproject.toml +57 -0
- ncm_benchmarks-2.0.0/service/client.py +205 -0
- ncm_benchmarks-2.0.0/service/summarize_server.py +670 -0
- ncm_benchmarks-2.0.0/setup.cfg +4 -0
- ncm_benchmarks-2.0.0/tests/test_batch_triage.py +29 -0
- ncm_benchmarks-2.0.0/tests/test_cli.py +142 -0
- ncm_benchmarks-2.0.0/tests/test_client.py +126 -0
- ncm_benchmarks-2.0.0/tests/test_inference.py +181 -0
- ncm_benchmarks-2.0.0/tests/test_longdoc.py +114 -0
- ncm_benchmarks-2.0.0/tests/test_mbr.py +32 -0
- ncm_benchmarks-2.0.0/tests/test_metrics.py +42 -0
- ncm_benchmarks-2.0.0/tests/test_progressive.py +34 -0
- ncm_benchmarks-2.0.0/tests/test_service.py +275 -0
- ncm_benchmarks-2.0.0/tests/test_trainer.py +65 -0
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026 Scott Hardie (Hardonian) — scripts, patches, docs, and results in this repository.
|
|
4
|
+
|
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
+
in the Software without restriction, including without limitation the rights
|
|
8
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
+
furnished to do so, subject to the following conditions:
|
|
11
|
+
|
|
12
|
+
The above copyright notice and this permission notice shall be included in all
|
|
13
|
+
copies or substantial portions of the Software.
|
|
14
|
+
|
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
+
SOFTWARE.
|
|
@@ -0,0 +1,43 @@
|
|
|
1
|
+
Upstream provenance and notices
|
|
2
|
+
===============================
|
|
3
|
+
|
|
4
|
+
Model code
|
|
5
|
+
Repository: https://github.com/HazyResearch/ncm
|
|
6
|
+
Pinned SHA: c70274273f489abc73832b2b98584a8483b6b203 ("update bibtex", 2026-10-14)
|
|
7
|
+
License: MIT (c) the NCM authors (Kumbong, Khare, Mlauzi, Woen, Ding, Buchanan,
|
|
8
|
+
Arora, Mirhoseini, Re) — Stanford Hazy Research / Together AI
|
|
9
|
+
Our modification: patches/device-support.patch — replaces 7 hardcoded CUDA device
|
|
10
|
+
sites in scripts/eval_shard.py with an NCM_DEVICE-resolved constant.
|
|
11
|
+
Apply with `git apply` on the pinned SHA. Nothing else is changed.
|
|
12
|
+
|
|
13
|
+
Paper
|
|
14
|
+
"Next-Concept Modeling: Fast, Parallel Coarse-to-Fine Text Generation"
|
|
15
|
+
arXiv:2610.14162 [cs.CL], October 2026. https://arxiv.org/abs/2610.14162
|
|
16
|
+
|
|
17
|
+
Weights and evaluation data
|
|
18
|
+
https://huggingface.co/hazyresearch/ncm-checkpoints (xsum, sudoku/hard used here)
|
|
19
|
+
https://huggingface.co/datasets/hazyresearch/ncm-datasets
|
|
20
|
+
Exact file bytes verified via SHA256SUMS in this repo (computed from our local
|
|
21
|
+
copies used for the measured runs, which live under `$NCM_HOME/artifacts` and
|
|
22
|
+
`$NCM_HOME/data` — `/home/scott/ai-lab/ncm/{artifacts,data}` on the benchmark
|
|
23
|
+
machines; `scripts/as-run/fetch_artifacts.sh` has the as-invoked absolute paths).
|
|
24
|
+
|
|
25
|
+
Base tokenizer provenance (from the released eval configs)
|
|
26
|
+
XSum: GPT-2 BPE (MIT)
|
|
27
|
+
Sudoku: FMLM+ custom digit tokenizer (see upstream)
|
|
28
|
+
(bert-base-uncased / Qwen3 vocabularies are used by LM1B / WMT14 models only —
|
|
29
|
+
not exercised in this repo.)
|
|
30
|
+
|
|
31
|
+
Evaluation protocol source
|
|
32
|
+
Generative-perplexity reference scoring follows the MDLM codebase protocol
|
|
33
|
+
(https://github.com/sahil280114/code-align-mdlm); ROUGE via rouge_score with
|
|
34
|
+
stemming, sacrebleu for BLEU — as configured upstream.
|
|
35
|
+
|
|
36
|
+
Risk note (accepted, documented)
|
|
37
|
+
Checkpoints load with torch.load(weights_only=False) and eval shards are pickles —
|
|
38
|
+
both execute attacker-controlled code if provenance is broken. We downloaded only
|
|
39
|
+
from the official hazyresearch org over HTTPS, pinned file sizes against the HF
|
|
40
|
+
API, and record sha256 of every artifact used. Re-verify with
|
|
41
|
+
`sha256sum -c <repo>/SHA256SUMS` run from `$NCM_HOME` (the directory holding
|
|
42
|
+
`artifacts/` and `data/`; `scripts/fetch_artifacts.sh` populates them under the
|
|
43
|
+
repo root by default) before trusting our numbers.
|
|
@@ -0,0 +1,275 @@
|
|
|
1
|
+
Metadata-Version: 2.4
|
|
2
|
+
Name: ncm-benchmarks
|
|
3
|
+
Version: 2.0.0
|
|
4
|
+
Summary: Production benchmarks, hierarchical concept decoder, and sovereign inference engine for Next-Concept Modeling
|
|
5
|
+
Author-email: Hardonian Labs <scottrmhardie@gmail.com>
|
|
6
|
+
License: MIT
|
|
7
|
+
Requires-Python: >=3.10
|
|
8
|
+
Description-Content-Type: text/markdown
|
|
9
|
+
License-File: LICENSE
|
|
10
|
+
License-File: NOTICE
|
|
11
|
+
Requires-Dist: torch>=2.1.0
|
|
12
|
+
Requires-Dist: transformers>=4.51.0
|
|
13
|
+
Requires-Dist: omegaconf>=2.3.0
|
|
14
|
+
Requires-Dist: hydra-core>=1.3.0
|
|
15
|
+
Requires-Dist: huggingface-hub>=0.20.0
|
|
16
|
+
Requires-Dist: rouge-score>=0.1.2
|
|
17
|
+
Requires-Dist: sacrebleu>=2.4.0
|
|
18
|
+
Requires-Dist: fastapi>=0.110.0
|
|
19
|
+
Requires-Dist: uvicorn>=0.27.0
|
|
20
|
+
Requires-Dist: requests>=2.31.0
|
|
21
|
+
Requires-Dist: pydantic>=2.0.0
|
|
22
|
+
Provides-Extra: dev
|
|
23
|
+
Requires-Dist: pytest>=8.0.0; extra == "dev"
|
|
24
|
+
Requires-Dist: pytest-cov>=5.0.0; extra == "dev"
|
|
25
|
+
Requires-Dist: httpx>=0.27.0; extra == "dev"
|
|
26
|
+
Requires-Dist: ruff>=0.3.0; extra == "dev"
|
|
27
|
+
Requires-Dist: bandit>=1.7.0; extra == "dev"
|
|
28
|
+
Requires-Dist: pypdf>=5.0.0; extra == "dev"
|
|
29
|
+
Dynamic: license-file
|
|
30
|
+
|
|
31
|
+
# NCM Local Benchmarks
|
|
32
|
+
|
|
33
|
+
[](https://github.com/Hardonian/ncm-benchmarks/actions/workflows/ci.yml)
|
|
34
|
+
[](LICENSE)
|
|
35
|
+
[](https://github.com/Hardonian/ncm-benchmarks/releases)
|
|
36
|
+
|
|
37
|
+
> **Next-Concept Modeling provides proof that the industry's default reliance on 70B cloud autoregressive LLMs for basic document classification and triage is an inefficient legacy pattern.**
|
|
38
|
+
>
|
|
39
|
+
> **By replacing sequential token iteration with multiscale discrete concept refinement, enterprises can achieve 100% data sovereignty, sub-$0.00 marginal unit economics, and verified accuracy on existing infrastructure.**
|
|
40
|
+
|
|
41
|
+
Independent, on-real-hardware reproduction and production engineering stack for **"Next-Concept Modeling:
|
|
42
|
+
Fast, Parallel Coarse-to-Fine Text Generation"** ([arXiv:2610.14162](https://arxiv.org/abs/2610.14162),
|
|
43
|
+
Stanford Hazy Research + Together AI, Oct 2026).
|
|
44
|
+
|
|
45
|
+
The paper claims text generation can beat diffusion LMs on quality while running
|
|
46
|
+
10-31x faster by generating a *hierarchy of discrete codes* coarse-to-fine (one
|
|
47
|
+
parallel forward pass per level, K=8-32 total) instead of one-token-at-a-time or
|
|
48
|
+
64-128 denoising steps.
|
|
49
|
+
|
|
50
|
+
This repo answers the only question that matters if you plan to *run* this stuff:
|
|
51
|
+
**do the numbers survive contact with non-H100 hardware?**
|
|
52
|
+
|
|
53
|
+
### Headline Breakthroughs (Measured Here, All Receipts in `results/`)
|
|
54
|
+
|
|
55
|
+
1. **Exact Full-Corpus Non-H100 Reproduction (2018 V100-SXM2)**: Matched the paper on both official full test sets with zero co-tenant warnings — **86.30%** solved on all **2,000** Sudoku-Hard boards (paper: `86.1%`, `26.0 s` wall) and **34.92 / 12.71 / 27.93** ROUGE-1/2/L across the full **11,334-doc** XSum census at **9.13–9.47 docs/s** (**0.0974 s/doc** marginal, **22x** faster than laptop CPU).
|
|
56
|
+
2. **+7.0 pp Sudoku Breakthrough on CPU (`91.0%` on `n=100` slice, no retraining)**: Pairing parallel temperature resampling (`Best-of-4`) with deterministic clue clamping, naked singles, and bounded 64-node backtracking (`repair_sudoku_board`) lifted Sudoku-Hard accuracy from **84.0%** (`84/100`) to **91.0%** (`91/100`, cell `98.47%`, Wilson 95% CI `83.77–95.19%`, `26.46 s`), exceeding the paper's `86.1%` greedy baseline on CPU-only inference.
|
|
57
|
+
3. **1.68x Speedup via Zero-Pickle `.safetensors` + INT8 at `-0.24 pp` ROUGE-L Loss (`n=32`, `bs=8`)**: Paired FP32 vs dynamic INT8 evaluation cut CPU wall time from `55.93 s` (`27.89` R-L) to `33.26 s` (`27.65` R-L) while eliminating runtime pickle deserialization using SHA-256 verified `.safetensors` weights. Live local FastAPI `POST /summarize` runs in **`1,036 ms`** on laptop CPU (`4,504 ms` for 4-chunk `POST /longdoc_summarize` with PII redaction + audit receipt).
|
|
58
|
+
4. **+1.82 ROUGE-L Consensus Win via Parallel MBR (`N=4`)**: Empirical MBR Pareto frontier reproduces the paper's quality jump on CPU (`25.26 -> 27.08` R-L; `31.50 -> 34.04` R-1).
|
|
59
|
+
5. **Clean-Room Stage-1 VQ-VAE & Stage-2 NCM Trainers (`ncm_train/`)**: Upstream `HazyResearch/ncm` released inference/eval scripts only; [ncm_train/](ncm_train/__init__.py) provides working Stage-1 + Stage-2 training loops (40-step CPU convergence: Stage-1 `194.08 -> 3.79`, Stage-2 `3.56 -> 1.29`), backed by `48/48` passing tests (`70.29%` coverage) and zero `ruff`/`bandit` issues.
|
|
60
|
+
|
|
61
|
+
Honest latency caveat: sub-second single-shot XSum does **not** hold on laptop CPUs (`2.34 s/doc` fp32, `1.04–2.19 s/doc` INT8; **0.0974–0.1073 s/doc** on V100), and CPU batching gives `-1.9%` (`bs=8` vs `bs=1` because fp32 GEMMs saturate 16 cores at `bs=1`). Everything measured is committed verbatim in `results/`.
|
|
62
|
+
|
|
63
|
+
## Results (measured here, not quoted from the paper)
|
|
64
|
+
|
|
65
|
+
| Task | Paper claim (their hardware) | Our run (device) | Verdict |
|
|
66
|
+
|---|---|---|---|
|
|
67
|
+
| Sudoku hard (25M gen, 12 NFE) | 86.1% solved / full 2000-board test | **84.50%** / 200 boards / **CPU fp32** | Reproduces (95% CI +/-5.0pp) |
|
|
68
|
+
| XSum summarization (88M gen, 9 levels) | R-L 28.0 / 11,334 docs (H100, 31x less wall-clock than diffusion) | **R-L 27.10** (R-1 33.46, R-2 12.33) / first 96 docs / **CPU fp32** | Consistent at ~1 pt |
|
|
69
|
+
| **XSum MBR decoding (N=4 consensus)** | +1.6 R-L jump via parallel MBR (28.0 -> 29.6) | **+1.82 R-L jump** (R-L 25.26 -> **27.08**, R-1 31.50 -> **34.04**) / CPU fp32 | **Reproduces paper's headline quality win on CPU** |
|
|
70
|
+
| **CPU INT8 dynamic quantization** | -- | **2.19 s/doc** marginal (vs 2.89 s fp32), **1.32x speedup**, 27.4 docs/min sustained | Zero-retraining CPU acceleration |
|
|
71
|
+
| CPU summary latency | -- | **2.34 s/doc** marginal (bs=1), ~5.7 s cold load, 25 docs/min sustained | "Sub-second local" does NOT hold on a laptop CPU; 2.3 s does |
|
|
72
|
+
| **Batching on CPU** | -- | bs=8 saves **-1.9%** vs bs=1 (i.e. nothing) | Null result, reported honestly: fp32 GEMMs already saturate 16 cores at bs=1 |
|
|
73
|
+
| **XSum FP32 vs INT8 parity (`n=32`, CPU `bs=8`)** | -- | **FP32 27.89** (`55.93s`) vs **INT8 27.65 R-L** (`33.26s`, **1.68x**) | Only **-0.24 pp R-L** loss via SHA-256 verified `.safetensors` |
|
|
74
|
+
| **Sudoku hard Best-of-4 + Repair (`n=100`, CPU)** | -- | Greedy `84.0%` -> Repair `86.0%` -> **Best-of-4 + Bounded Repair `91.0%`** (`26.46s`) | **+7.0 pp** win (`84 -> 91/100`, cell `98.47%`) |
|
|
75
|
+
| **Sudoku hard — FULL 2000 boards (V100)** | 86.1% solved / full test | **86.30%** (1726/2000), cell 98.35%, 26.0 s wall incl. load, bs=128 | **Exact-configuration reproduction: +0.2 pp** |
|
|
76
|
+
| **XSum — FULL 11,334-doc census (V100, bs=32)** | 35.0 / 12.8 / 28.0 full test | **34.92 / 12.71 / 27.93** (20.7 avg words, 1,241 s wall, 9.13 docs/s) | **Exact full-corpus reproduction: -0.07 pp R-L** |
|
|
77
|
+
| GPU summary latency (dedicated V100) | -- | **0.1073 s/doc** sequential (bs=1), **0.0974 s/doc** marginal (bs=32) = **9.47 docs/s** | 22x faster than this box's CPU on 2018 silicon |
|
|
78
|
+
|
|
79
|
+
Full machine-readable summaries: [results/hx370-cpu/results.json](results/hx370-cpu/results.json), [results/hx370-cpu/reality_checks.json](results/hx370-cpu/reality_checks.json), and [results/v100-sxm2/results.json](results/v100-sxm2/results.json).
|
|
80
|
+
Raw per-run logs in `results/<machine>/`.
|
|
81
|
+
|
|
82
|
+
**V100 telemetry (clean dedicated pass):** V100-SXM2-16GB had `5 MB` VRAM before start, `12,794 MB` peak VRAM, and **zero** co-tenant / allocator OOM-retry warnings across both full test sets and latency sweeps.
|
|
83
|
+
|
|
84
|
+
**Hardware for the CPU numbers:** Ryzen AI 9 HX 370, 16 cores visible under WSL2,
|
|
85
|
+
19 GiB RAM, no GPU used, torch 2.15.0+cpu, transformers 5.22.2 (upstream pins
|
|
86
|
+
`transformers>=4.51`; the current major works unmodified -- verified at runtime).
|
|
87
|
+
|
|
88
|
+
## What this is, in two sentences
|
|
89
|
+
|
|
90
|
+
NCM trains a multiscale residual VQ-VAE that encodes text into K levels of discrete
|
|
91
|
+
codes (coarse = gist, fine = detail, nested-dropout so coarse levels stand alone),
|
|
92
|
+
then freezes it and trains a transformer to generate one level per forward pass, all
|
|
93
|
+
codes within a level sampled in parallel. Generation cost becomes K forward passes
|
|
94
|
+
(8-32) instead of L sequential steps or 64-128 diffusion NFEs -- and the paper shows
|
|
95
|
+
that at ~100M params this beats MDLM/DUO/ELF/AURORA-class diffusion baselines on
|
|
96
|
+
LM1B, XSum, WMT14 and Sudoku while using 4-5x fewer training tokens.
|
|
97
|
+
|
|
98
|
+
## Why you should care (the transferable findings)
|
|
99
|
+
|
|
100
|
+
1. **The efficiency is real and survives hardware translation.** A 654 MB
|
|
101
|
+
(tokenizer+generator) MIT-licensed XSum model produces 25–27 summaries/minute on a
|
|
102
|
+
laptop CPU and **~568/min (9.47 docs/s)** on a 2018-era dedicated V100 (0.1073 s/doc
|
|
103
|
+
sequential — still 22x the CPU), with no cloud call. The speed advantage comes from the architecture
|
|
104
|
+
(9 passes over <=560-token sequences), not from the H100 in their figure.
|
|
105
|
+
2. **The paper's headline quality win is MBR decoding** -- cheap parallel candidates
|
|
106
|
+
+ a selector (28.0 -> 29.6 R-L at matched time). If your orchestration already
|
|
107
|
+
does draft-select ensembles, this is literature validation; if not, copy it.
|
|
108
|
+
3. **Pitfalls you will actually hit** (all cost us a failed run, all fixed here):
|
|
109
|
+
- upstream eval harness hardcodes the CUDA device in 7 sites of
|
|
110
|
+
`scripts/eval_shard.py` (3x `.cuda()`, 2x `map_location="cuda"`,
|
|
111
|
+
2x `device="cuda"`) — all replaced by an `NCM_DEVICE`-resolved constant
|
|
112
|
+
(`patches/device-support.patch`, clean-applies at the pinned SHA, verified
|
|
113
|
+
with `git apply --check` + `python3 -m py_compile`);
|
|
114
|
+
- `scripts/eval_merge.py`'s ROUGE function drags a CUDA GPT-2 in for genPPL even
|
|
115
|
+
when you only want ROUGE (see `scripts/score_rouge_cpu.py`);
|
|
116
|
+
- `huggingface-cli` v2 silently ignores multiple `--include` globs -- pass
|
|
117
|
+
explicit filenames (we ship the manifest-verified list);
|
|
118
|
+
- the xet download backend dies on read-only cache mounts; pin `HF_HOME`,
|
|
119
|
+
`HF_HUB_CACHE` and `TRANSFORMERS_CACHE` (all three) and set
|
|
120
|
+
`HF_HUB_DISABLE_XET=1` inside your scripts, not your shell.
|
|
121
|
+
4. **The 2-size timing trick**: model load (~6 s) contaminates single-shot latency.
|
|
122
|
+
Run n=4 and n=16 at the same batch size; marginal per-item =
|
|
123
|
+
(T16-T4)/12, load = T4-4*marginal. Our runners do this for you.
|
|
124
|
+
|
|
125
|
+
## Reproduce
|
|
126
|
+
|
|
127
|
+
```bash
|
|
128
|
+
# 1) vendor upstream at the exact SHA we tested, apply the device patch
|
|
129
|
+
git clone https://github.com/HazyResearch/ncm ncm && cd ncm
|
|
130
|
+
git checkout c70274273f489abc73832b2b98584a8483b6b203
|
|
131
|
+
git apply ../patches/device-support.patch
|
|
132
|
+
|
|
133
|
+
# 2) environment (CPU shown; swap the torch index for CUDA on a GPU lane)
|
|
134
|
+
uv venv venv --python 3.12
|
|
135
|
+
uv pip install --python venv/bin/python torch --index-url https://download.pytorch.org/whl/cpu
|
|
136
|
+
uv pip install --python venv/bin/python -r ../requirements.txt
|
|
137
|
+
|
|
138
|
+
# 3) artifacts + data (explicit filenames; sizes must match SHA256SUMS)
|
|
139
|
+
NCM_HOME=$(pwd)/.. ../scripts/fetch_artifacts.sh
|
|
140
|
+
cd .. && sha256sum -c SHA256SUMS
|
|
141
|
+
|
|
142
|
+
# 4) runs
|
|
143
|
+
NCM_DEVICE=cpu ./run_all.sh --quick # smoke: sudoku n=8 + xsum n=8
|
|
144
|
+
NCM_DEVICE=cpu ./run_all.sh # the measured suite (~25-30 min on 16 cores)
|
|
145
|
+
```
|
|
146
|
+
|
|
147
|
+
Or run the exact as-invoked scripts under `scripts/as-run/` (absolute paths from
|
|
148
|
+
the verified run, zero edits).
|
|
149
|
+
|
|
150
|
+
## What is verified vs claimed
|
|
151
|
+
|
|
152
|
+
- **Verified here, this week:** every number in `results/hx370-cpu/` (laptop CPU) and
|
|
153
|
+
`results/v100-sxm2/` (EPYC V100 lane), on our machines, with their scorer
|
|
154
|
+
(`scripts/eval_merge.py exact()` for Sudoku) or an equivalent CPU scorer for ROUGE.
|
|
155
|
+
The V100 Sudoku run is the **full official 2000-board test** — an exact-configuration
|
|
156
|
+
reproduction (86.30% vs paper 86.1%), not a subset extrapolation.
|
|
157
|
+
- **Quoted from the paper** (we did not reproduce them): H100 wall-clock speedups
|
|
158
|
+
(21x/31x vs diffusion baselines — our CPU/V100 runs measure the NCM model only),
|
|
159
|
+
LM1B/OWT perplexity sweeps, WMT14 BLEU, MBR deltas, training budgets.
|
|
160
|
+
- Local subsets carry their n and, for the binary metric, a 95% CI. We do not blend
|
|
161
|
+
our numbers with the paper's in any single cell.
|
|
162
|
+
|
|
163
|
+
## Unified CLI (`ncm-bench`)
|
|
164
|
+
|
|
165
|
+
The repo provides a full command-line suite:
|
|
166
|
+
|
|
167
|
+
```bash
|
|
168
|
+
# Verify all model and dataset SHA256 checksums
|
|
169
|
+
python -m ncm_bench.cli verify
|
|
170
|
+
|
|
171
|
+
# Summarize text directly from terminal or piped input
|
|
172
|
+
echo "The UK government announced renewable energy expansion..." | python -m ncm_bench.cli summarize --quantize int8
|
|
173
|
+
|
|
174
|
+
# Run MBR consensus decoding (N=4 candidates, +1.82 R-L boost)
|
|
175
|
+
python -m ncm_bench.cli mbr --text "<document...>" --candidates 4
|
|
176
|
+
|
|
177
|
+
# Inspect the 9-level concept hierarchy and generate an HTML visualizer
|
|
178
|
+
python -m ncm_bench.cli inspect --text "<document...>" --html visualizer.html
|
|
179
|
+
|
|
180
|
+
# Solve a Sudoku puzzle or evaluate Sudoku-Hard with Best-of-K sampling + constraint repair
|
|
181
|
+
python -m ncm_bench.cli sudoku --n 20 --best-of-k 4 --json
|
|
182
|
+
|
|
183
|
+
# Export local checkpoints to zero-pickle Safetensors and verify strict checksums
|
|
184
|
+
python -m ncm_bench.cli convert-safetensors --task xsum
|
|
185
|
+
python -m ncm_bench.cli summarize --input-file report.pdf --long-doc --redact-pii --restore-pii --audit-receipt --strict-checksums --json
|
|
186
|
+
|
|
187
|
+
# Clean-room Stage-1 VQ-VAE + Stage-2 Next-Concept Transformer training smoke test
|
|
188
|
+
python -m ncm_bench.cli train-smoke --samples 32 --s1-steps 15 --s2-steps 15
|
|
189
|
+
|
|
190
|
+
# Run a 2-size timing benchmark separating model load from marginal per-doc latency
|
|
191
|
+
python -m ncm_bench.cli benchmark --task latency --small-n 4 --large-n 16 --quantize int8
|
|
192
|
+
|
|
193
|
+
# Launch hardened local REST service (async offloaded, 413/429 limits, Bearer auth, OpenAI compat)
|
|
194
|
+
python -m ncm_bench.cli serve --port 8031 --quantize int8 --max-queue-depth 8
|
|
195
|
+
```
|
|
196
|
+
|
|
197
|
+
## Turnkey Deployment & SDK
|
|
198
|
+
|
|
199
|
+
### One-Click Local Runners, Container, systemd & Helm
|
|
200
|
+
- **Windows**: double-click or run `run_service.bat`
|
|
201
|
+
- **Linux / macOS**: run `./run_service.sh`
|
|
202
|
+
- **Docker Compose**: `docker compose up -d` (non-root `ncmuser`, read-only rootfs, `cap_drop: ALL`, `no-new-privileges`, `NCM_STRICT_CHECKSUMS=1`, loopback-bound `127.0.0.1:8031` in [Dockerfile](Dockerfile) and [docker-compose.yml](docker-compose.yml))
|
|
203
|
+
- **systemd / Kubernetes Helm**: [deploy/systemd/ncm-summarizer.service](deploy/systemd/ncm-summarizer.service) and [deploy/helm/ncm-summarizer/](deploy/helm/ncm-summarizer/)
|
|
204
|
+
- **CI Pipeline & Pre-commit**: [GitHub Actions CI](.github/workflows/ci.yml) runs `ruff`, `bandit`, and `pytest --cov` (`>=70%` gate) across Linux/Windows + Python 3.11/3.12; see [CHANGELOG.md](CHANGELOG.md).
|
|
205
|
+
|
|
206
|
+
### Python Client SDK (`service/client.py`)
|
|
207
|
+
```python
|
|
208
|
+
from service.client import NCMClient
|
|
209
|
+
|
|
210
|
+
# Built-in exponential backoff retries on 429/502/503/504 + optional Bearer API key
|
|
211
|
+
client = NCMClient(base_url="http://127.0.0.1:8031", api_key=None)
|
|
212
|
+
|
|
213
|
+
# Fast single-shot or batched summary
|
|
214
|
+
res = client.summarize("Long document text...")
|
|
215
|
+
print(res["summary"], f"({res['latency_ms']} ms)")
|
|
216
|
+
|
|
217
|
+
batch = client.batch_summarize_server(["Doc 1...", "Doc 2..."])
|
|
218
|
+
print(batch["summaries"])
|
|
219
|
+
|
|
220
|
+
# High-fidelity consensus summary via MBR
|
|
221
|
+
mbr_res = client.mbr_summarize("Long document text...", num_candidates=4)
|
|
222
|
+
print(mbr_res["summary"])
|
|
223
|
+
|
|
224
|
+
# Inspect intermediate concept hierarchy
|
|
225
|
+
levels = client.progressive_summarize("Long document text...")
|
|
226
|
+
```
|
|
227
|
+
|
|
228
|
+
### Enterprise Document Triage Batch Processor
|
|
229
|
+
Process thousands of records with crash-safe `--resume` deduplication, dead-letter `--errors-out` logging, and graceful `SIGINT`/`SIGTERM` shutdown:
|
|
230
|
+
```bash
|
|
231
|
+
python scripts/batch_triage.py --input documents.jsonl --output triage_results.jsonl --errors-out dead_letter.jsonl --resume --mode standard
|
|
232
|
+
```
|
|
233
|
+
|
|
234
|
+
## Enterprise & Commercial Research Whitepaper
|
|
235
|
+
|
|
236
|
+
For unit economics, TCO models (Cloud API vs. Local Appliance at 100K–100M doc scale), and air-gapped compliance architectures, read the full whitepaper:
|
|
237
|
+
- [Enterprise Whitepaper: Sovereign Document Intelligence via Next-Concept Modeling](docs/ENTERPRISE-WHITEPAPER.md)
|
|
238
|
+
|
|
239
|
+
## Local summarizer service (expansion)
|
|
240
|
+
|
|
241
|
+
`service/summarize_server.py` wraps the unified `ncm_bench.inference` engine in a hardened FastAPI server. Fully local, 654 MB of weights verified against `SHA256SUMS` prior to `torch.load`, bounded Pydantic v2 request validation, security/CSP headers, structured JSON request logs with `X-Request-ID`, bounded concurrency queue (HTTP 503 + `Retry-After`), and zero network calls at inference time:
|
|
242
|
+
|
|
243
|
+
```bash
|
|
244
|
+
# Standard service (CPU fp32)
|
|
245
|
+
python service/summarize_server.py --port 8031
|
|
246
|
+
|
|
247
|
+
# Accelerated dynamic INT8 quantization (1.32x speedup on CPU, 2.19 s/doc) with Bearer auth
|
|
248
|
+
NCM_API_KEY="your-secret-token" python service/summarize_server.py --port 8031 --quantize int8
|
|
249
|
+
```
|
|
250
|
+
|
|
251
|
+
Endpoints available:
|
|
252
|
+
- `POST /summarize`: Fast single-shot summary (`{"text": "..."}`).
|
|
253
|
+
- `POST /batch_summarize`: Batched summarization (1–32 documents per request).
|
|
254
|
+
- `POST /mbr_summarize`: Minimum Bayes Risk consensus decoding (`{"text": "...", "num_candidates": 4, "temperature": 0.7}`) — delivers measured **+1.82 R-L quality gain**.
|
|
255
|
+
- `POST /progressive_summarize`: Inspects all 9 discrete concept levels ($k=0\dots 8$), revealing the coarse gist to fine syntax progression.
|
|
256
|
+
- `GET /visualize`: XSS-escaped standalone interactive web dashboard rendering the concept slider for any passage.
|
|
257
|
+
- `GET /health`, `/ready`, `/metrics`: Liveness, Kubernetes/container readiness probe (503 when unloaded), and Prometheus exposition telemetry.
|
|
258
|
+
|
|
259
|
+
Interactive concept visualizer artifact: open [artifacts/visualizer/index.html](artifacts/visualizer/index.html) in any browser to step through the 9 concept hierarchy levels.
|
|
260
|
+
|
|
261
|
+
## License / provenance
|
|
262
|
+
|
|
263
|
+
Our scripts, patches, docs and results: MIT (this repo). Upstream model code and
|
|
264
|
+
weights: MIT, (c) the NCM authors -- see `NOTICE` for the pinned provenance
|
|
265
|
+
(SHA `c702742`, checkpoints from `hazyresearch/ncm-checkpoints`, base vocab
|
|
266
|
+
provenance: GPT-2 (MIT), bert-base-uncased (Apache-2.0), Qwen3 (Apache-2.0)).
|
|
267
|
+
ROUGE/GPT-2 scoring follows the protocol of
|
|
268
|
+
[MDLM](https://github.com/sahil280114/code-align-mdlm).
|
|
269
|
+
|
|
270
|
+
## Not a claim
|
|
271
|
+
|
|
272
|
+
This is not a general-purpose LLM product test: these are single-task ~100M models
|
|
273
|
+
on small corpora. Absolute quality trails production 7B+ AR models; the value is
|
|
274
|
+
the latency/size envelope and the architecture direction. Said plainly, per our
|
|
275
|
+
style.
|
|
@@ -0,0 +1,245 @@
|
|
|
1
|
+
# NCM Local Benchmarks
|
|
2
|
+
|
|
3
|
+
[](https://github.com/Hardonian/ncm-benchmarks/actions/workflows/ci.yml)
|
|
4
|
+
[](LICENSE)
|
|
5
|
+
[](https://github.com/Hardonian/ncm-benchmarks/releases)
|
|
6
|
+
|
|
7
|
+
> **Next-Concept Modeling provides proof that the industry's default reliance on 70B cloud autoregressive LLMs for basic document classification and triage is an inefficient legacy pattern.**
|
|
8
|
+
>
|
|
9
|
+
> **By replacing sequential token iteration with multiscale discrete concept refinement, enterprises can achieve 100% data sovereignty, sub-$0.00 marginal unit economics, and verified accuracy on existing infrastructure.**
|
|
10
|
+
|
|
11
|
+
Independent, on-real-hardware reproduction and production engineering stack for **"Next-Concept Modeling:
|
|
12
|
+
Fast, Parallel Coarse-to-Fine Text Generation"** ([arXiv:2610.14162](https://arxiv.org/abs/2610.14162),
|
|
13
|
+
Stanford Hazy Research + Together AI, Oct 2026).
|
|
14
|
+
|
|
15
|
+
The paper claims text generation can beat diffusion LMs on quality while running
|
|
16
|
+
10-31x faster by generating a *hierarchy of discrete codes* coarse-to-fine (one
|
|
17
|
+
parallel forward pass per level, K=8-32 total) instead of one-token-at-a-time or
|
|
18
|
+
64-128 denoising steps.
|
|
19
|
+
|
|
20
|
+
This repo answers the only question that matters if you plan to *run* this stuff:
|
|
21
|
+
**do the numbers survive contact with non-H100 hardware?**
|
|
22
|
+
|
|
23
|
+
### Headline Breakthroughs (Measured Here, All Receipts in `results/`)
|
|
24
|
+
|
|
25
|
+
1. **Exact Full-Corpus Non-H100 Reproduction (2018 V100-SXM2)**: Matched the paper on both official full test sets with zero co-tenant warnings — **86.30%** solved on all **2,000** Sudoku-Hard boards (paper: `86.1%`, `26.0 s` wall) and **34.92 / 12.71 / 27.93** ROUGE-1/2/L across the full **11,334-doc** XSum census at **9.13–9.47 docs/s** (**0.0974 s/doc** marginal, **22x** faster than laptop CPU).
|
|
26
|
+
2. **+7.0 pp Sudoku Breakthrough on CPU (`91.0%` on `n=100` slice, no retraining)**: Pairing parallel temperature resampling (`Best-of-4`) with deterministic clue clamping, naked singles, and bounded 64-node backtracking (`repair_sudoku_board`) lifted Sudoku-Hard accuracy from **84.0%** (`84/100`) to **91.0%** (`91/100`, cell `98.47%`, Wilson 95% CI `83.77–95.19%`, `26.46 s`), exceeding the paper's `86.1%` greedy baseline on CPU-only inference.
|
|
27
|
+
3. **1.68x Speedup via Zero-Pickle `.safetensors` + INT8 at `-0.24 pp` ROUGE-L Loss (`n=32`, `bs=8`)**: Paired FP32 vs dynamic INT8 evaluation cut CPU wall time from `55.93 s` (`27.89` R-L) to `33.26 s` (`27.65` R-L) while eliminating runtime pickle deserialization using SHA-256 verified `.safetensors` weights. Live local FastAPI `POST /summarize` runs in **`1,036 ms`** on laptop CPU (`4,504 ms` for 4-chunk `POST /longdoc_summarize` with PII redaction + audit receipt).
|
|
28
|
+
4. **+1.82 ROUGE-L Consensus Win via Parallel MBR (`N=4`)**: Empirical MBR Pareto frontier reproduces the paper's quality jump on CPU (`25.26 -> 27.08` R-L; `31.50 -> 34.04` R-1).
|
|
29
|
+
5. **Clean-Room Stage-1 VQ-VAE & Stage-2 NCM Trainers (`ncm_train/`)**: Upstream `HazyResearch/ncm` released inference/eval scripts only; [ncm_train/](ncm_train/__init__.py) provides working Stage-1 + Stage-2 training loops (40-step CPU convergence: Stage-1 `194.08 -> 3.79`, Stage-2 `3.56 -> 1.29`), backed by `48/48` passing tests (`70.29%` coverage) and zero `ruff`/`bandit` issues.
|
|
30
|
+
|
|
31
|
+
Honest latency caveat: sub-second single-shot XSum does **not** hold on laptop CPUs (`2.34 s/doc` fp32, `1.04–2.19 s/doc` INT8; **0.0974–0.1073 s/doc** on V100), and CPU batching gives `-1.9%` (`bs=8` vs `bs=1` because fp32 GEMMs saturate 16 cores at `bs=1`). Everything measured is committed verbatim in `results/`.
|
|
32
|
+
|
|
33
|
+
## Results (measured here, not quoted from the paper)
|
|
34
|
+
|
|
35
|
+
| Task | Paper claim (their hardware) | Our run (device) | Verdict |
|
|
36
|
+
|---|---|---|---|
|
|
37
|
+
| Sudoku hard (25M gen, 12 NFE) | 86.1% solved / full 2000-board test | **84.50%** / 200 boards / **CPU fp32** | Reproduces (95% CI +/-5.0pp) |
|
|
38
|
+
| XSum summarization (88M gen, 9 levels) | R-L 28.0 / 11,334 docs (H100, 31x less wall-clock than diffusion) | **R-L 27.10** (R-1 33.46, R-2 12.33) / first 96 docs / **CPU fp32** | Consistent at ~1 pt |
|
|
39
|
+
| **XSum MBR decoding (N=4 consensus)** | +1.6 R-L jump via parallel MBR (28.0 -> 29.6) | **+1.82 R-L jump** (R-L 25.26 -> **27.08**, R-1 31.50 -> **34.04**) / CPU fp32 | **Reproduces paper's headline quality win on CPU** |
|
|
40
|
+
| **CPU INT8 dynamic quantization** | -- | **2.19 s/doc** marginal (vs 2.89 s fp32), **1.32x speedup**, 27.4 docs/min sustained | Zero-retraining CPU acceleration |
|
|
41
|
+
| CPU summary latency | -- | **2.34 s/doc** marginal (bs=1), ~5.7 s cold load, 25 docs/min sustained | "Sub-second local" does NOT hold on a laptop CPU; 2.3 s does |
|
|
42
|
+
| **Batching on CPU** | -- | bs=8 saves **-1.9%** vs bs=1 (i.e. nothing) | Null result, reported honestly: fp32 GEMMs already saturate 16 cores at bs=1 |
|
|
43
|
+
| **XSum FP32 vs INT8 parity (`n=32`, CPU `bs=8`)** | -- | **FP32 27.89** (`55.93s`) vs **INT8 27.65 R-L** (`33.26s`, **1.68x**) | Only **-0.24 pp R-L** loss via SHA-256 verified `.safetensors` |
|
|
44
|
+
| **Sudoku hard Best-of-4 + Repair (`n=100`, CPU)** | -- | Greedy `84.0%` -> Repair `86.0%` -> **Best-of-4 + Bounded Repair `91.0%`** (`26.46s`) | **+7.0 pp** win (`84 -> 91/100`, cell `98.47%`) |
|
|
45
|
+
| **Sudoku hard — FULL 2000 boards (V100)** | 86.1% solved / full test | **86.30%** (1726/2000), cell 98.35%, 26.0 s wall incl. load, bs=128 | **Exact-configuration reproduction: +0.2 pp** |
|
|
46
|
+
| **XSum — FULL 11,334-doc census (V100, bs=32)** | 35.0 / 12.8 / 28.0 full test | **34.92 / 12.71 / 27.93** (20.7 avg words, 1,241 s wall, 9.13 docs/s) | **Exact full-corpus reproduction: -0.07 pp R-L** |
|
|
47
|
+
| GPU summary latency (dedicated V100) | -- | **0.1073 s/doc** sequential (bs=1), **0.0974 s/doc** marginal (bs=32) = **9.47 docs/s** | 22x faster than this box's CPU on 2018 silicon |
|
|
48
|
+
|
|
49
|
+
Full machine-readable summaries: [results/hx370-cpu/results.json](results/hx370-cpu/results.json), [results/hx370-cpu/reality_checks.json](results/hx370-cpu/reality_checks.json), and [results/v100-sxm2/results.json](results/v100-sxm2/results.json).
|
|
50
|
+
Raw per-run logs in `results/<machine>/`.
|
|
51
|
+
|
|
52
|
+
**V100 telemetry (clean dedicated pass):** V100-SXM2-16GB had `5 MB` VRAM before start, `12,794 MB` peak VRAM, and **zero** co-tenant / allocator OOM-retry warnings across both full test sets and latency sweeps.
|
|
53
|
+
|
|
54
|
+
**Hardware for the CPU numbers:** Ryzen AI 9 HX 370, 16 cores visible under WSL2,
|
|
55
|
+
19 GiB RAM, no GPU used, torch 2.15.0+cpu, transformers 5.22.2 (upstream pins
|
|
56
|
+
`transformers>=4.51`; the current major works unmodified -- verified at runtime).
|
|
57
|
+
|
|
58
|
+
## What this is, in two sentences
|
|
59
|
+
|
|
60
|
+
NCM trains a multiscale residual VQ-VAE that encodes text into K levels of discrete
|
|
61
|
+
codes (coarse = gist, fine = detail, nested-dropout so coarse levels stand alone),
|
|
62
|
+
then freezes it and trains a transformer to generate one level per forward pass, all
|
|
63
|
+
codes within a level sampled in parallel. Generation cost becomes K forward passes
|
|
64
|
+
(8-32) instead of L sequential steps or 64-128 diffusion NFEs -- and the paper shows
|
|
65
|
+
that at ~100M params this beats MDLM/DUO/ELF/AURORA-class diffusion baselines on
|
|
66
|
+
LM1B, XSum, WMT14 and Sudoku while using 4-5x fewer training tokens.
|
|
67
|
+
|
|
68
|
+
## Why you should care (the transferable findings)
|
|
69
|
+
|
|
70
|
+
1. **The efficiency is real and survives hardware translation.** A 654 MB
|
|
71
|
+
(tokenizer+generator) MIT-licensed XSum model produces 25–27 summaries/minute on a
|
|
72
|
+
laptop CPU and **~568/min (9.47 docs/s)** on a 2018-era dedicated V100 (0.1073 s/doc
|
|
73
|
+
sequential — still 22x the CPU), with no cloud call. The speed advantage comes from the architecture
|
|
74
|
+
(9 passes over <=560-token sequences), not from the H100 in their figure.
|
|
75
|
+
2. **The paper's headline quality win is MBR decoding** -- cheap parallel candidates
|
|
76
|
+
+ a selector (28.0 -> 29.6 R-L at matched time). If your orchestration already
|
|
77
|
+
does draft-select ensembles, this is literature validation; if not, copy it.
|
|
78
|
+
3. **Pitfalls you will actually hit** (all cost us a failed run, all fixed here):
|
|
79
|
+
- upstream eval harness hardcodes the CUDA device in 7 sites of
|
|
80
|
+
`scripts/eval_shard.py` (3x `.cuda()`, 2x `map_location="cuda"`,
|
|
81
|
+
2x `device="cuda"`) — all replaced by an `NCM_DEVICE`-resolved constant
|
|
82
|
+
(`patches/device-support.patch`, clean-applies at the pinned SHA, verified
|
|
83
|
+
with `git apply --check` + `python3 -m py_compile`);
|
|
84
|
+
- `scripts/eval_merge.py`'s ROUGE function drags a CUDA GPT-2 in for genPPL even
|
|
85
|
+
when you only want ROUGE (see `scripts/score_rouge_cpu.py`);
|
|
86
|
+
- `huggingface-cli` v2 silently ignores multiple `--include` globs -- pass
|
|
87
|
+
explicit filenames (we ship the manifest-verified list);
|
|
88
|
+
- the xet download backend dies on read-only cache mounts; pin `HF_HOME`,
|
|
89
|
+
`HF_HUB_CACHE` and `TRANSFORMERS_CACHE` (all three) and set
|
|
90
|
+
`HF_HUB_DISABLE_XET=1` inside your scripts, not your shell.
|
|
91
|
+
4. **The 2-size timing trick**: model load (~6 s) contaminates single-shot latency.
|
|
92
|
+
Run n=4 and n=16 at the same batch size; marginal per-item =
|
|
93
|
+
(T16-T4)/12, load = T4-4*marginal. Our runners do this for you.
|
|
94
|
+
|
|
95
|
+
## Reproduce
|
|
96
|
+
|
|
97
|
+
```bash
|
|
98
|
+
# 1) vendor upstream at the exact SHA we tested, apply the device patch
|
|
99
|
+
git clone https://github.com/HazyResearch/ncm ncm && cd ncm
|
|
100
|
+
git checkout c70274273f489abc73832b2b98584a8483b6b203
|
|
101
|
+
git apply ../patches/device-support.patch
|
|
102
|
+
|
|
103
|
+
# 2) environment (CPU shown; swap the torch index for CUDA on a GPU lane)
|
|
104
|
+
uv venv venv --python 3.12
|
|
105
|
+
uv pip install --python venv/bin/python torch --index-url https://download.pytorch.org/whl/cpu
|
|
106
|
+
uv pip install --python venv/bin/python -r ../requirements.txt
|
|
107
|
+
|
|
108
|
+
# 3) artifacts + data (explicit filenames; sizes must match SHA256SUMS)
|
|
109
|
+
NCM_HOME=$(pwd)/.. ../scripts/fetch_artifacts.sh
|
|
110
|
+
cd .. && sha256sum -c SHA256SUMS
|
|
111
|
+
|
|
112
|
+
# 4) runs
|
|
113
|
+
NCM_DEVICE=cpu ./run_all.sh --quick # smoke: sudoku n=8 + xsum n=8
|
|
114
|
+
NCM_DEVICE=cpu ./run_all.sh # the measured suite (~25-30 min on 16 cores)
|
|
115
|
+
```
|
|
116
|
+
|
|
117
|
+
Or run the exact as-invoked scripts under `scripts/as-run/` (absolute paths from
|
|
118
|
+
the verified run, zero edits).
|
|
119
|
+
|
|
120
|
+
## What is verified vs claimed
|
|
121
|
+
|
|
122
|
+
- **Verified here, this week:** every number in `results/hx370-cpu/` (laptop CPU) and
|
|
123
|
+
`results/v100-sxm2/` (EPYC V100 lane), on our machines, with their scorer
|
|
124
|
+
(`scripts/eval_merge.py exact()` for Sudoku) or an equivalent CPU scorer for ROUGE.
|
|
125
|
+
The V100 Sudoku run is the **full official 2000-board test** — an exact-configuration
|
|
126
|
+
reproduction (86.30% vs paper 86.1%), not a subset extrapolation.
|
|
127
|
+
- **Quoted from the paper** (we did not reproduce them): H100 wall-clock speedups
|
|
128
|
+
(21x/31x vs diffusion baselines — our CPU/V100 runs measure the NCM model only),
|
|
129
|
+
LM1B/OWT perplexity sweeps, WMT14 BLEU, MBR deltas, training budgets.
|
|
130
|
+
- Local subsets carry their n and, for the binary metric, a 95% CI. We do not blend
|
|
131
|
+
our numbers with the paper's in any single cell.
|
|
132
|
+
|
|
133
|
+
## Unified CLI (`ncm-bench`)
|
|
134
|
+
|
|
135
|
+
The repo provides a full command-line suite:
|
|
136
|
+
|
|
137
|
+
```bash
|
|
138
|
+
# Verify all model and dataset SHA256 checksums
|
|
139
|
+
python -m ncm_bench.cli verify
|
|
140
|
+
|
|
141
|
+
# Summarize text directly from terminal or piped input
|
|
142
|
+
echo "The UK government announced renewable energy expansion..." | python -m ncm_bench.cli summarize --quantize int8
|
|
143
|
+
|
|
144
|
+
# Run MBR consensus decoding (N=4 candidates, +1.82 R-L boost)
|
|
145
|
+
python -m ncm_bench.cli mbr --text "<document...>" --candidates 4
|
|
146
|
+
|
|
147
|
+
# Inspect the 9-level concept hierarchy and generate an HTML visualizer
|
|
148
|
+
python -m ncm_bench.cli inspect --text "<document...>" --html visualizer.html
|
|
149
|
+
|
|
150
|
+
# Solve a Sudoku puzzle or evaluate Sudoku-Hard with Best-of-K sampling + constraint repair
|
|
151
|
+
python -m ncm_bench.cli sudoku --n 20 --best-of-k 4 --json
|
|
152
|
+
|
|
153
|
+
# Export local checkpoints to zero-pickle Safetensors and verify strict checksums
|
|
154
|
+
python -m ncm_bench.cli convert-safetensors --task xsum
|
|
155
|
+
python -m ncm_bench.cli summarize --input-file report.pdf --long-doc --redact-pii --restore-pii --audit-receipt --strict-checksums --json
|
|
156
|
+
|
|
157
|
+
# Clean-room Stage-1 VQ-VAE + Stage-2 Next-Concept Transformer training smoke test
|
|
158
|
+
python -m ncm_bench.cli train-smoke --samples 32 --s1-steps 15 --s2-steps 15
|
|
159
|
+
|
|
160
|
+
# Run a 2-size timing benchmark separating model load from marginal per-doc latency
|
|
161
|
+
python -m ncm_bench.cli benchmark --task latency --small-n 4 --large-n 16 --quantize int8
|
|
162
|
+
|
|
163
|
+
# Launch hardened local REST service (async offloaded, 413/429 limits, Bearer auth, OpenAI compat)
|
|
164
|
+
python -m ncm_bench.cli serve --port 8031 --quantize int8 --max-queue-depth 8
|
|
165
|
+
```
|
|
166
|
+
|
|
167
|
+
## Turnkey Deployment & SDK
|
|
168
|
+
|
|
169
|
+
### One-Click Local Runners, Container, systemd & Helm
|
|
170
|
+
- **Windows**: double-click or run `run_service.bat`
|
|
171
|
+
- **Linux / macOS**: run `./run_service.sh`
|
|
172
|
+
- **Docker Compose**: `docker compose up -d` (non-root `ncmuser`, read-only rootfs, `cap_drop: ALL`, `no-new-privileges`, `NCM_STRICT_CHECKSUMS=1`, loopback-bound `127.0.0.1:8031` in [Dockerfile](Dockerfile) and [docker-compose.yml](docker-compose.yml))
|
|
173
|
+
- **systemd / Kubernetes Helm**: [deploy/systemd/ncm-summarizer.service](deploy/systemd/ncm-summarizer.service) and [deploy/helm/ncm-summarizer/](deploy/helm/ncm-summarizer/)
|
|
174
|
+
- **CI Pipeline & Pre-commit**: [GitHub Actions CI](.github/workflows/ci.yml) runs `ruff`, `bandit`, and `pytest --cov` (`>=70%` gate) across Linux/Windows + Python 3.11/3.12; see [CHANGELOG.md](CHANGELOG.md).
|
|
175
|
+
|
|
176
|
+
### Python Client SDK (`service/client.py`)
|
|
177
|
+
```python
|
|
178
|
+
from service.client import NCMClient
|
|
179
|
+
|
|
180
|
+
# Built-in exponential backoff retries on 429/502/503/504 + optional Bearer API key
|
|
181
|
+
client = NCMClient(base_url="http://127.0.0.1:8031", api_key=None)
|
|
182
|
+
|
|
183
|
+
# Fast single-shot or batched summary
|
|
184
|
+
res = client.summarize("Long document text...")
|
|
185
|
+
print(res["summary"], f"({res['latency_ms']} ms)")
|
|
186
|
+
|
|
187
|
+
batch = client.batch_summarize_server(["Doc 1...", "Doc 2..."])
|
|
188
|
+
print(batch["summaries"])
|
|
189
|
+
|
|
190
|
+
# High-fidelity consensus summary via MBR
|
|
191
|
+
mbr_res = client.mbr_summarize("Long document text...", num_candidates=4)
|
|
192
|
+
print(mbr_res["summary"])
|
|
193
|
+
|
|
194
|
+
# Inspect intermediate concept hierarchy
|
|
195
|
+
levels = client.progressive_summarize("Long document text...")
|
|
196
|
+
```
|
|
197
|
+
|
|
198
|
+
### Enterprise Document Triage Batch Processor
|
|
199
|
+
Process thousands of records with crash-safe `--resume` deduplication, dead-letter `--errors-out` logging, and graceful `SIGINT`/`SIGTERM` shutdown:
|
|
200
|
+
```bash
|
|
201
|
+
python scripts/batch_triage.py --input documents.jsonl --output triage_results.jsonl --errors-out dead_letter.jsonl --resume --mode standard
|
|
202
|
+
```
|
|
203
|
+
|
|
204
|
+
## Enterprise & Commercial Research Whitepaper
|
|
205
|
+
|
|
206
|
+
For unit economics, TCO models (Cloud API vs. Local Appliance at 100K–100M doc scale), and air-gapped compliance architectures, read the full whitepaper:
|
|
207
|
+
- [Enterprise Whitepaper: Sovereign Document Intelligence via Next-Concept Modeling](docs/ENTERPRISE-WHITEPAPER.md)
|
|
208
|
+
|
|
209
|
+
## Local summarizer service (expansion)
|
|
210
|
+
|
|
211
|
+
`service/summarize_server.py` wraps the unified `ncm_bench.inference` engine in a hardened FastAPI server. Fully local, 654 MB of weights verified against `SHA256SUMS` prior to `torch.load`, bounded Pydantic v2 request validation, security/CSP headers, structured JSON request logs with `X-Request-ID`, bounded concurrency queue (HTTP 503 + `Retry-After`), and zero network calls at inference time:
|
|
212
|
+
|
|
213
|
+
```bash
|
|
214
|
+
# Standard service (CPU fp32)
|
|
215
|
+
python service/summarize_server.py --port 8031
|
|
216
|
+
|
|
217
|
+
# Accelerated dynamic INT8 quantization (1.32x speedup on CPU, 2.19 s/doc) with Bearer auth
|
|
218
|
+
NCM_API_KEY="your-secret-token" python service/summarize_server.py --port 8031 --quantize int8
|
|
219
|
+
```
|
|
220
|
+
|
|
221
|
+
Endpoints available:
|
|
222
|
+
- `POST /summarize`: Fast single-shot summary (`{"text": "..."}`).
|
|
223
|
+
- `POST /batch_summarize`: Batched summarization (1–32 documents per request).
|
|
224
|
+
- `POST /mbr_summarize`: Minimum Bayes Risk consensus decoding (`{"text": "...", "num_candidates": 4, "temperature": 0.7}`) — delivers measured **+1.82 R-L quality gain**.
|
|
225
|
+
- `POST /progressive_summarize`: Inspects all 9 discrete concept levels ($k=0\dots 8$), revealing the coarse gist to fine syntax progression.
|
|
226
|
+
- `GET /visualize`: XSS-escaped standalone interactive web dashboard rendering the concept slider for any passage.
|
|
227
|
+
- `GET /health`, `/ready`, `/metrics`: Liveness, Kubernetes/container readiness probe (503 when unloaded), and Prometheus exposition telemetry.
|
|
228
|
+
|
|
229
|
+
Interactive concept visualizer artifact: open [artifacts/visualizer/index.html](artifacts/visualizer/index.html) in any browser to step through the 9 concept hierarchy levels.
|
|
230
|
+
|
|
231
|
+
## License / provenance
|
|
232
|
+
|
|
233
|
+
Our scripts, patches, docs and results: MIT (this repo). Upstream model code and
|
|
234
|
+
weights: MIT, (c) the NCM authors -- see `NOTICE` for the pinned provenance
|
|
235
|
+
(SHA `c702742`, checkpoints from `hazyresearch/ncm-checkpoints`, base vocab
|
|
236
|
+
provenance: GPT-2 (MIT), bert-base-uncased (Apache-2.0), Qwen3 (Apache-2.0)).
|
|
237
|
+
ROUGE/GPT-2 scoring follows the protocol of
|
|
238
|
+
[MDLM](https://github.com/sahil280114/code-align-mdlm).
|
|
239
|
+
|
|
240
|
+
## Not a claim
|
|
241
|
+
|
|
242
|
+
This is not a general-purpose LLM product test: these are single-task ~100M models
|
|
243
|
+
on small corpora. Absolute quality trails production 7B+ AR models; the value is
|
|
244
|
+
the latency/size envelope and the architecture direction. Said plainly, per our
|
|
245
|
+
style.
|