# DeepSeek-V2-Lite-Chat 跨来源采样协议 > 状态：已按预注册协议执行；正式结果见 > `research/DEEPSEEK_V2_LITE_CHAT_CROSS_SOURCE_SAMPLING_AUDIT.md` > > 注册日期：2026-07-30 > > 协议 ID：`llm-atlas-deepseek-chat-cross-source-sampling-v1` > > 模型：`deepseek-ai/DeepSeek-V2-Lite-Chat` > > revision：`85864749cd611b4353ce1decdb286193298f64c7` > > 前序实验：Round 06 单来源 × 八 seed × 八条件采样 ## 0. 这一轮补什么，不补什么 Round 06 固定四条 source，每条 source 在八个 seed 和八种边界条件下生成： ```text 4 sources × 8 seeds × 8 conditions = 256 outputs ``` 它证明了两件看似矛盾但可以同时成立的事： 1. 不同 seed 会让同一格的 sampled trajectory 分叉； 2. 固定 checkpoint、输入、batch 行顺序、软件与 seed 后，同一 trajectory 可以跨进程逐 token 复现。 但 Math 和 Code 各只有一道题。即使那一道题有 64 个 sampled outputs，也仍然只有一个 任务对象。把 64 个 seed 重复当成 64 道独立 benchmark 题，会制造伪样本量。 Round 07 因此把预算从“同题更多 seed”移动到“更多预先选定的 source”： ```text 16 sources × 4 seeds × 4 conditions = 256 outputs ``` 本轮第一次允许描述固定 4 道 Math / 4 道 Code 之间的离散性，但仍不是完整 GSM8K/HumanEval benchmark，更不是模型总体能力估计。 --- ## 1. 研究问题与证据层级 ### 1.1 主要问题 在固定 source selection、官方 sampling 参数与四行 batch 合同下： 1. Round 06 观察到的 completion-length / EOS 模式能否在另外三条同域 source 上出现？ 2. Math / Code 的 pass count 是否由单一道题主导？ 3. `system off/on × EOS/period` 四格的方向是否跨 source 一致，还是明显依赖题目？ 4. source 间差异与 source 内 seed 差异，哪一个在当前固定网格中更大？ ### 1.2 探索与确认的边界 选择 `period` 作为唯一 ordinary-token 对照，受 Round 06 的结果启发：它在单来源运行中 显示了明显的输出长度与 exact-trajectory 收缩。因此本轮是**定向复查**，不是完全独立、 未见前序结果的 confirmatory experiment。 本轮不会： - 把 Round 06 与 Round 07 合并后计算“独立复现率”； - 把四道题的方向一致写成总体显著性； - 根据本轮结果继续替换 source、condition 或 seed； - 把 period 序列称为官方有效聊天格式； - 把题内四个 seed 当成四道独立题。 --- ## 2. 模型、依赖与解码合同 继承冻结对象： - 官方 SFT Chat checkpoint； - revision `85864749cd611b4353ce1decdb286193298f64c7`； - checkpoint 12 个文件及各自 SHA-256； - Transformers `4.41.2`； - PyTorch `2.11.0+cu128`； - BF16、官方 remote modeling code、eager attention； - CUDA resident：embedding + layers 0–23； - CPU offload：layers 24–26 + final norm + `lm_head`； - `PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True`； - GPU static placement `28GiB`、CPU placement `80GiB`； - 左填充，`PAD=EOS`，padding mask 为 0； - `use_cache=true`、统一 `max_new_tokens=512`。 固定 revision 的官方 `generation_config.json` 给出： ```text do_sample = true temperature = 0.3 top_p = 0.95 bos_id = 100000 eos_id = 100001 ``` 正式执行显式传入： ```text do_sample = true temperature = 0.3 top_p = 0.95 top_k = 0 max_new_tokens = 512 use_cache = true ``` `top_k=0` 用于关闭 Transformers 通用默认 top-k；它不是 checkpoint 文件中的额外作者 结论。 --- ## 3. source 如何在结果之前冻结 source 不按 Round 06 的正确率、完成率或文本质量挑选。它们取自已冻结的 `deepseek-v2-lite-routing-special-token-family-control.json`： ```text sample salt = llm-atlas-deepseek-routing-template-control-v1 每域按 SHA-256 selection_rank 排序，取 within_domain_index 0–3 ``` ### 3.1 English | index | source ID | |---:|---| | 0 | `wikitext2/raw-validation/0443` | | 1 | `wikitext2/raw-validation/0030` | | 2 | `wikitext2/raw-validation/2909` | | 3 | `wikitext2/raw-validation/2746` | ### 3.2 Chinese | index | source ID | |---:|---| | 0 | `tnews/test/4855` | | 1 | `tnews/test/8935` | | 2 | `tnews/test/3448` | | 3 | `tnews/test/1059` | ### 3.3 Code | index | source ID | |---:|---| | 0 | `HumanEval/31` | | 1 | `HumanEval/44` | | 2 | `HumanEval/133` | | 3 | `HumanEval/23` | ### 3.4 Math | index | source ID | |---:|---| | 0 | `gsm8k/test/1069` | | 1 | `gsm8k/test/1228` | | 2 | `gsm8k/test/0144` | | 3 | `gsm8k/test/1251` | 这些正是 Round 05 greedy completion 已执行的 16 条 source。本轮在加载模型前，必须验证 16 × 4 = 64 个 prompt token hashes 与 Round 05 对应格逐格 exact。 --- ## 4. 四格因子与 batch 合同 固定四格： ```text s0_eos, s1_eos, s0_period, s1_period ``` 其中： - `s0/s1`：system off/on； - `eos`：官方 assistant 历史边界； - `period`：把该位置的 EOS 单 ID 替换为普通句点 ID 13； - system 文本、one-shot 内容、target source、角色词头、目标位置与 prompt 其余 token 均继承 前序协议。 每个 source × replicate 的四格在同一个 batch，行顺序永久固定。四行 batch 与 Round 06 的八行 batch 不同，因此即使复用相同 base seed，也不应期待 trajectory exact；本轮使用 新协议派生的新 seed，避免把两种 batch 合同伪装成直接重复。 Transformers `4.41.2` 对整个 batch 调用一次 `torch.multinomial`，不接受逐行 `Generator`。四格只共享 batch seed 与调用时序，每行消费不同 RNG 子流，因此仍是： ```text batch-seed aligned ≠ common-random-number paired ``` --- ## 5. seed 冻结 四个 base seed 由以下字符串做 SHA-256，取前 4 bytes big-endian unsigned integer： ```text llm-atlas-deepseek-chat-cross-source-sampling-v1/seed/{index} ``` 固定结果： | replicate | base seed | |---:|---:| | R0 | 2,101,325,316 | | R1 | 2,511,573,438 | | R2 | 1,677,220,094 | | R3 | 2,412,346,607 | 实际 run seed： ```text SHA256( protocol_id + "/run\0" + decimal(base_seed) + "\0" + source_id )[0:8] big-endian modulo (2^63 - 1) ``` 每次 source × replicate batch 前： ```python torch.manual_seed(run_seed) torch.cuda.manual_seed_all(run_seed) ``` 同时记录 CPU / CUDA RNG state 的执行前后 SHA-256。 --- ## 6. 输入文件身份 | 输入 | SHA-256 | |---|---| | source selection contract | `c372c1b03a8b15f615b54ded5d9257a8fc2cdb7728001735d3d4c1d8534af5bf` | | Round 05 greedy baseline | `6af40512c5868caab0ef58356aaa7728384f2b7acc7c502aa89478fdf5a2a468` | | HumanEval gzip | `b796127e635a67f93fb35c04f4cb03cf06f38c8072ee7cee8833d7bee06979ef` | | GSM8K test JSONL | `3730d312f6e3440559ace48831e51066acaca737f6eabec99bccb9e4b3c39d14` | | TNEWS test JSONL | `74f199325768fbf2d6020711edfff23d653e99e0f8ac31a126a54db29c3a0ca8` | | TNEWS archive | `77c476e70cfe0b014a81b84c6e1db2142a8a2f52f4ae0a8216aa75e673933462` | | WikiText-2 validation parquet | `204929b7ff9d6184953f867dedb860e40aa69c078fc1e54b3baaa8fb28511c4c` | HumanEval `canonical_solution` / tests 与 GSM8K answer 只进入生成后的独立 evaluator，绝不 进入模型 prompt。 --- ## 7. 执行网格与闸门 ### 7.1 16-token smoke ```text 16 sources × R0/R1 × 4 conditions × 16 tokens = 128 short outputs 16 sources × R0 replay × 4 conditions × 16 tokens = 64 replay outputs ``` 通过条件： 1. 64 / 64 prompt hashes 与 Round 05 exact； 2. 128 条 smoke 无 OOM、NaN 或 exception； 3. R0 同进程 replay 的 run seed、prompt hash、token IDs、text 与 stop state 64 / 64 exact； 4. R0/R1 的 64 个同 source-condition cells 至少一格 trajectory 分叉； 5. 正式参数确实是 `.3/.95/top-k 0`。 smoke 输出不进入正式统计。 ### 7.2 正式网格 ```text 16 sources × 4 seeds × 4 conditions × 512 new-token cap = 256 sampled outputs ``` source 顺序固定为 English → Chinese → Code → Math，各域按 `within_domain_index` 升序； replicate 固定 R0 → R3；每个 replicate 内行顺序固定为四格顺序。不能根据中间输出提前 停止或只续写截断格。 ### 7.3 新进程复跑 正式完成后重新启动 Python、重新加载模型，只复跑 R0： ```text 16 sources × 1 seed × 4 conditions = 64 outputs ``` 逐格核对： - run seed； - prompt token hash； - 完整 generated token IDs； - decoded text； - EOS state； - truncation state； - CPU RNG pre-state hash； - CUDA RNG pre-state hash。 只能写“64 / 64 R0 cells independently reproduced”，不能写 256 / 256。 --- ## 8. 独立 evaluator 仍把四张账分开： 1. stopping：natural EOS / budget truncated； 2. task terminal：明确答案、闭合 code fence 或 tests pass； 3. evaluator coverage：数值可抽取，或代码 AST + sandbox 已执行； 4. correctness：GSM8K strict numeric exact / HumanEval official tests pass。 HumanEval 每个独特 candidate 使用固定镜像： ```text python:3.11-alpine@ sha256:25976e9d34a0fab1f278cae931f34c8303d97bf0c0d7f85b6b4dcf641d7702a4 ``` 沙箱： ```text network none · read-only filesystem · user 65534:65534 cap-drop ALL · no-new-privileges · no host mounts 256 MiB memory/swap · pids 64 · cpus .5 · timeout 5s ``` 完全相同的 candidate + task + tests + harness 可以复用 execution cache，但保留每个生成格 自己的 evaluator row。 --- ## 9. 预注册统计 ### 9.1 source × condition 每个集合有 4 个 seed，报告： - natural EOS / 4； - truncated / 4； - generated length mean / min / max； - unique full-token trajectory hashes / 4； - 六对 seed pair 的 token similarity； - Math：4 个抽取答案、严格正确数、唯一绝对多数答案（若存在）； - Code：AST、executed、official tests pass、observed any-pass。 `observed any-pass` 只表示当前四次抽样至少一次通过，不称为标准 HumanEval pass@4。 ### 9.2 domain × condition 每个 domain 的四条 source 等权，报告： - micro count：16 个 outputs 的合计； - source macro mean：先算每条 source 的四 seed 比例，再对四条 source 等权； - source range：四条 source 的最小/最大； - 4 × 4 source-condition 矩阵。 因为每条 source 的 seed 数相同，micro 与 macro 点估计可能数值相同；两者仍分开呈现， 避免未来不等重复数时悄悄改变权重。 ### 9.3 source-blocked 四格 contrast 对每条 source 先算四格 cell mean，再形成描述性 contrast： ```text system main = mean(s1_eos, s1_period) - mean(s0_eos, s0_period) boundary main = mean(s0_period, s1_period) - mean(s0_eos, s1_eos) interaction = (s1_period - s1_eos) - (s0_period - s0_eos) ``` 分别对： - natural EOS rate； - generated-token length； - Math / Code fixed-budget success； - Math / Code strict-complete success。 每个 domain 展示四条 source 的 contrast dots、median、min、max 与正/零/负方向计数。不算 p-value，不给总体置信区间。 ### 9.4 两层离散性 对 generated-token length 与 task success： - `within-source seed range`：同 source-condition 四 seed 的范围； - `between-source cell-mean range`：同 domain-condition 四条 source 均值的范围。 这只是固定网格中的描述，不作随机效应方差分解，也不把四条 source 当作领域总体随机样本。 ### 9.5 前序方向复查 只针对 Round 06 已观察到的方向登记： ```text period 相对 EOS 是否缩短 mean generated tokens？ system on 相对 off 是否提高 natural EOS rate？ ``` 按 source 报告方向，不因结果改写为“改善质量”。Math / Code correctness 单独展示，不能由 长度或 EOS 代替。 --- ## 10. 失败与修订规则 - smoke 前可修实现错误；正式 source/seed/condition/metrics 不随输出改动； - 正式 JSON 完整写出前失败，整轮重新开始，不保留“表现较好”的部分 source； - OOM 优先降低 static GPU placement，并用同 seed smoke 做 placement exact 闸门； - 不拆四行 batch；拆 batch 或改行顺序意味着新协议； - evaluator bug 可以修复并重跑 evaluator，但 sampled output 文件冻结； - 新进程 R0 任一 preregistered 字段不 exact，则结果只作复现失败诊断； - 某题 evaluator uncovered 仍保留该格，不能删题或换题； - 沙箱超时、AST 失败、assertion failure 与 runtime error 分开记录。 --- ## 11. 永久禁止的结论 - 4 道 GSM8K / HumanEval 代表完整 benchmark； - 64 个 task-domain outputs 等于 64 道独立题； - 4 seeds 足以估计完整生成分布； - observed any-pass 等于标准 pass@4； - period 是官方有效聊天边界； - system 或 period 让模型“更聪明”“更稳定”； - natural EOS、语义终点、可评测与正确是同一个指标； - 四条 source 的方向计数是总体显著性； - batch-seed aligned 是 common-random-number pair； - exact same-seed replay 可跨软件、kernel 或硬件保证； - CPU-offloaded eager 延迟等于生产服务吞吐； - 输出关联已经定位到 hidden-state / router mediation。 --- ## 12. 一手来源 - DeepSeek-V2-Lite-Chat pinned `generation_config.json`： - Holtzman et al., *The Curious Case of Neural Text Degeneration*： - Chen et al., *Evaluating Large Language Models Trained on Code*： - Cobbe et al., *Training Verifiers to Solve Math Word Problems*： - OpenAI HumanEval pinned repository：