# DeepSeek-V2-Lite-Chat 跨来源采样审计

> 执行日期：2026-07-30
>
> 协议：`llm-atlas-deepseek-chat-cross-source-sampling-v1`
>
> 模型：`deepseek-ai/DeepSeek-V2-Lite-Chat`
>
> revision：`85864749cd611b4353ce1decdb286193298f64c7`
>
> 预注册：`research/DEEPSEEK_V2_LITE_CHAT_CROSS_SOURCE_SAMPLING_PROTOCOL.md`
>
> 前序：Round 06 单来源 × 八 seed × 八条件采样

## 0. 一句话结论

本轮保持 256 条正式生成的总预算不变，把网格从 Round 06 的：

```text
4 sources × 8 seeds × 8 conditions
```

改成：

```text
16 sources × 4 seeds × 4 conditions
```

结果为：

```text
256 sampled outputs
├─ 250 natural EOS
├─   6 budget truncated
├─ 247 个不同的完整 token trajectory hashes
├─ Math：47 / 64 strict exact
├─ Code：52 / 64 official tests pass
├─ R0 / R1：63 / 64 同 source-condition 轨迹分叉
└─ 新进程 R0：64 / 64 格的八项合同字段 exact
```

最重要的不是总正确数下降，而是总数背后的题目异质性终于可见：

```text
Math tasks：14 / 16 · 16 / 16 · 8 / 16 · 9 / 16
Code tasks：16 / 16 ·  8 / 16 · 12 / 16 · 16 / 16
```

Round 06 的 Math `62 / 64` 与 Code `63 / 64` 各来自同一道题的重复采样，不能代表
64 道独立任务。本轮也仍不是完整 benchmark；它只把覆盖单位从每域 1 条扩大到每域
4 条，并第一次允许我们描述这 4 条 source 之间的离散性。

---

## 1. 这轮修复的统计对象错误

### 1.1 seed 是题内重复，不是新题

对固定 Math source 抽 64 个 seed，能够回答：

- 同一道题的有限采样轨迹怎样分叉；
- 这道题的任务结果是否对 seed 敏感；
- 固定 seed 与执行环境时能否复跑出同一轨迹。

它不能回答：

- 模型在 64 道不同 Math 题上的能力；
- source 换成另一题后，条件方向是否保留；
- 这道题是否容易、典型或能代表 GSM8K；
- 一个由 seed 数制造的窄区间是否具有 benchmark 意义。

本轮因此冻结：

```text
主要覆盖单位：source
source 内重复：seed
```

所有方向先在每条 source 内，由四个 seed 的 cell summary 计算；然后只描述四条
source 的正、零、负方向数量。没有把题内 seed 当作独立 source。

### 1.2 为什么仍保留 micro total

`47 / 64` 与 `52 / 64` 仍有用，因为它们精确描述这份固定网格中通过的输出数。但它们
必须与逐题矩阵一起展示：

```text
micro total
≠ 题目难度分布
≠ benchmark accuracy
≠ population estimate
```

### 1.3 本轮不是盲确认

`period` 是在看到 Round 06 结果后选出的定向 follow-up：上一轮句点格在单来源上出现
明显的长度收缩与轨迹集合变化。因此：

- 本轮可以检查前序方向在新增 source 上是否保留；
- 不能称为完全独立、未见结果的 confirmatory experiment；
- 不能从 `11 / 16` 同向构造事后显著性故事。

---

## 2. 冻结执行合同

### 2.1 模型与软件

| 对象 | 冻结值 |
|---|---|
| checkpoint | `deepseek-ai/DeepSeek-V2-Lite-Chat` |
| revision | `85864749cd611b4353ce1decdb286193298f64c7` |
| dtype | BF16 |
| attention | eager |
| PyTorch | `2.11.0+cu128` |
| Transformers | `4.41.2` |
| CUDA placement | embedding + layers 0–23 |
| CPU placement | layers 24–26 + final norm + `lm_head` |
| padding | left padding；`PAD=EOS`；padding mask 为 0 |
| cache | `use_cache=true` |

CPU offload 是本机执行拓扑，不是模型结构或能力属性。

### 2.2 解码参数

固定 revision 的官方 `generation_config.json` 给出：

```text
do_sample   = true
temperature = 0.3
top_p       = 0.95
```

正式执行显式传入：

```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 作者结论。

### 2.3 四格条件

```text
s0_eos
s1_eos
s0_period
s1_period
```

- `s0/s1`：system off/on；
- `eos`：官方 assistant 历史边界；
- `period`：把该位置的 EOS 单 ID 替换为普通句点 ID 13。

句点格是单 ID 反事实，不是官方有效聊天序列。每个 source × replicate 的四格放在同一个
batch，行顺序固定。

### 2.4 四个 seed

| replicate | base seed |
|---:|---:|
| R0 | 2,101,325,316 |
| R1 | 2,511,573,438 |
| R2 | 1,677,220,094 |
| R3 | 2,412,346,607 |

base seed 在结果之前由协议字符串的 SHA-256 派生。每条 source 再从 base seed 与
source ID 派生 run seed。四行共享 batch seed 与随机调用时序，但各行消费不同 RNG
子流，因此仍是：

```text
batch-seed aligned
≠ common-random-number paired
```

本轮不报告 paired p-value。

---

## 3. source 选择与输入身份

source 不是按 Round 06 的正确率、完成率或文本质量挑选，而是来自已经冻结的公开语料
选择合同：

```text
sample salt = llm-atlas-deepseek-routing-template-control-v1
每域按 SHA-256 selection_rank 排序，取 within_domain_index 0–3
```

### 3.1 四域各四条

| domain | index 0 | index 1 | index 2 | index 3 |
|---|---|---|---|---|
| English | WikiText `0443` | `0030` | `2909` | `2746` |
| Chinese | TNEWS `4855` | `8935` | `3448` | `1059` |
| Code | HumanEval `31` | `44` | `133` | `23` |
| Math | GSM8K `1069` | `1228` | `0144` | `1251` |

### 3.2 prompt hash 闸门

本轮的：

```text
16 sources × 4 conditions = 64 prompt cells
```

与 Round 05 已执行的对应输入逐格比较：

```text
64 / 64 prompt token SHA-256 exact
```

HumanEval canonical solution/tests 与 GSM8K gold 只在生成冻结后进入独立 evaluator，
从未进入模型 prompt。

---

## 4. smoke 与正式执行

### 4.1 16-token smoke

```text
16 sources × R0/R1 × 4 conditions = 128 short outputs
16 sources × R0 replay × 4 conditions = 64 replay outputs
```

| 闸门 | 结果 |
|---|---:|
| prompt hash exact | 64 / 64 |
| R0 同进程重放全合同 exact | 64 / 64 |
| R0/R1 可比格 | 64 |
| R0/R1 trajectory 分叉 | 34 / 64 |
| OOM / NaN / exception | 0 |

16-token smoke 只检查执行合同，没有进入正式统计。

### 4.2 正式网格

```text
16 sources
× 4 seeds
× 4 conditions
× 512 new-token cap
= 256 sampled outputs
```

| 检查 | 结果 |
|---|---:|
| sources | 16 |
| sources / domain | 4 |
| conditions / source | 4 |
| seeds / source-condition | 4 |
| total outputs | 256 |
| missing / duplicate cells | 0 |
| prompt hash exact | 64 / 64 |

执行记录：

| 指标 | 值 |
|---|---:|
| generation seconds | `3,520.086` |
| peak CUDA allocated | `29,694,417,408 bytes` |
| unique full trajectory hashes | `247 / 256` |
| R0/R1 trajectory different | `63 / 64` |

这里的耗时属于 CPU-offloaded eager 机制审计，不是服务吞吐 benchmark。

---

## 5. stopping 与轨迹总账

| 指标 | 结果 |
|---|---:|
| natural EOS | 250 / 256 |
| budget truncated | 6 / 256 |
| unique full token trajectory hashes | 247 / 256 |
| R0/R1 comparable cells | 64 |
| R0/R1 different trajectories | 63 |

`247 unique` 只说明完整 token ID 序列的 SHA-256 不同，不说明存在 247 种语义、策略或
推理方法。

高 EOS 率也不等于高正确率：

```text
Math 的 17 条失败全部 natural EOS
Code 有自然 EOS 的 runtime / assertion failure
```

因此仍按四张账处理：

```text
stopping
→ task terminal
→ evaluator coverage
→ correctness
```

---

## 6. Math：47 / 64 怎样分布

独立 evaluator 使用 GSM8K 官方 gold，抽取最终数值；严格成功要求：

```text
自然完成
+ evaluator covered
+ predicted numeric answer == gold numeric answer
```

### 6.1 4 tasks × 4 conditions

| source | S0·EOS | S1·EOS | S0·句点 | S1·句点 | total |
|---|---:|---:|---:|---:|---:|
| GSM8K/1069 | 3/4 | 4/4 | 3/4 | 4/4 | 14/16 |
| GSM8K/1228 | 4/4 | 4/4 | 4/4 | 4/4 | 16/16 |
| GSM8K/0144 | 2/4 | 2/4 | 3/4 | 1/4 | 8/16 |
| GSM8K/1251 | 1/4 | 4/4 | 1/4 | 3/4 | 9/16 |

总计：

```text
47 / 64 strict exact
```

### 6.2 这张矩阵教会什么

同样是预先冻结的 GSM8K source：

- `/1228` 在 16 次生成中全对；
- `/0144` 只有 8 / 16；
- `/1251` 只有 9 / 16；
- `/1069` 的 14 / 16 更接近 Round 06 单题高正确率。

所以 Round 06 的 `62 / 64` 首先是 `/1069` 这一道题的局部性质，不能推广成模型的
GSM8K 采样正确率。

### 6.3 source-blocked task contrast

system main effect 的四条 source 方向：

```text
2 positive · 1 zero · 1 negative
```

句点减 EOS 的 main effect：

```text
0 positive · 3 zero · 1 negative
```

interaction：

```text
0 positive · 2 zero · 2 negative
```

这些是固定四题的描述量，不是总体效应。

### 6.4 失败身份

Math 有 17 条 strict failure：

- `/1069`：2；
- `/0144`：8；
- `/1251`：7；
- `/1228`：0。

17 条全部自然 EOS，全部为 evaluator 已覆盖但最终数值与 gold 不同。失败不是正则抽取器
无法找到答案，也不是长度上限截断。

---

## 7. Code：52 / 64 怎样分布

生成完成后，独立 evaluator：

1. 抽取 Python candidate；
2. 做 AST parse；
3. 在固定容器中执行 HumanEval official tests；
4. 记录 passed、runtime error、assertion failed；
5. 以 candidate/test/harness hashes 做安全缓存。

### 7.1 沙箱合同

| 对象 | 值 |
|---|---|
| image | `python:3.11-alpine@sha256:25976e9d…7702a4` |
| network | none |
| filesystem | read-only |
| user | `65534:65534` |
| capabilities | all dropped |
| no new privileges | true |
| memory / swap | 256 MiB / 256 MiB |
| pids | 64 |
| cpus | 0.5 |
| timeout | 5 seconds |
| unique code cache entries | 47 |
| cache hits | 17 |

64 / 64 candidates 完成 AST 检查与执行身份记录。

### 7.2 4 tasks × 4 conditions

| source | S0·EOS | S1·EOS | S0·句点 | S1·句点 | total |
|---|---:|---:|---:|---:|---:|
| HumanEval/31 | 4/4 | 4/4 | 4/4 | 4/4 | 16/16 |
| HumanEval/44 | 2/4 | 1/4 | 1/4 | 4/4 | 8/16 |
| HumanEval/133 | 4/4 | 4/4 | 4/4 | 0/4 | 12/16 |
| HumanEval/23 | 4/4 | 4/4 | 4/4 | 4/4 | 16/16 |

总计：

```text
52 / 64 official tests pass
```

### 7.3 总 interaction 为 0，却不代表每题为 0

Code strict success 的 source-level interaction：

| source | interaction |
|---|---:|
| HumanEval/31 | 0 |
| HumanEval/44 | +1.0 |
| HumanEval/133 | −1.0 |
| HumanEval/23 | 0 |
| domain mean | 0 |

这是本轮最清楚的聚合陷阱：

```text
domain mean = 0
```

不是“每道题都没有 interaction”，而是 `/44` 与 `/133` 正负完全抵消。

### 7.4 失败身份

12 条 Code strict failure：

```text
HumanEval/44
├─ 5 runtime_error
└─ 3 assertion_failed

HumanEval/133
└─ 4 assertion_failed（全部 s1_period）
```

其中只有 1 条属于 budget-truncated unresolved；其余失败不能归因于 512-token 上限。
AST 合法、自然 EOS 或说明流畅都不能替代 official tests。

---

## 8. 句点是否普遍缩短生成

每条 source 内先计算：

```text
period main
= mean(S0·period, S1·period)
− mean(S0·EOS, S1·EOS)
```

负数表示句点格更短。

### 8.1 四域方向

| domain | shorter sources | domain mean | source median |
|---|---:|---:|---:|
| English | 1 / 4 | −8.5 | +21.2 |
| Chinese | 3 / 4 | −13.9 | −13.0 |
| Code | 4 / 4 | −130.0 | −166.1 |
| Math | 3 / 4 | −19.8 | −9.6 |
| total | 11 / 16 | — | — |

### 8.2 English 直接修正 Round 06 的单来源印象

| source | period − EOS mean tokens |
|---|---:|
| WikiText/0443 | −121.0 |
| WikiText/0030 | +44.5 |
| WikiText/2909 | +41.0 |
| WikiText/2746 | +1.375 |

如果只看 Round 06 的 `/0443`，会写成：

```text
句点大幅缩短 English 输出
```

加入三条预先冻结的 English source 后：

```text
1 条更短
3 条更长
domain mean 仍是 −8.5
source median 却是 +21.2
```

均值与多数方向相反，是因为 `/0443` 的 `−121` 足以压过另外三条正值。这正是为什么
本轮在前端同时展示四个 source 点、均值和中位数。

### 8.3 其余三域

Chinese：

```text
+0.375 · −30.0 · −7.5 · −18.5
```

Code：

```text
−178.625 · −164.375 · −167.875 · −9.0
```

Math：

```text
−4.625 · −68.75 · +8.875 · −14.5
```

Code 的四条 source 同向，是当前固定网格里最一致的长度模式；仍不能写成对
HumanEval 总体或所有代码任务的普遍规律。

---

## 9. system main effect 也依赖 source

平均生成长度的 system main effect：

| domain | negative | zero | positive | mean |
|---|---:|---:|---:|---:|
| English | 4 | 0 | 0 | −137.0 |
| Chinese | 2 | 0 | 2 | −6.9 |
| Code | 4 | 0 | 0 | −143.3 |
| Math | 3 | 0 | 1 | −13.6 |

English 与 Code 在这四条 source 上都呈 system-on 更短；Chinese 则正负各半。不能把
一个域的方向复制到另一个域。

自然 EOS 已接近天花板：

- system-on 提升 EOS 的 source：English 2 / 4；
- Chinese、Code、Math：均 0 / 4；
- 这主要说明多数 cell 已经 4 / 4 EOS，不是 system 没有其它行为差异。

---

## 10. source 间与 source 内离散

每个 domain-condition 同时保存：

```text
within-source seed length range
between-source mean length range
within-source seed success range
between-source success-rate range
```

这些量回答不同问题：

- within-source：固定一道题，四个 seed 能让长度或成功怎样变化；
- between-source：固定域与 condition，四道题的均值或成功率跨度多大。

它们没有被压成一个“哪种随机性更大”的全局数字，因为：

- length 与 correctness 量纲不同；
- 四条 source 太少，不适合稳定估计方差分量；
- seed 并不是逐行 common random numbers；
- source 不是从总体随机抽样。

前端允许逐域逐 condition 检查两个范围，但不输出伪精确的总体方差比例。

---

## 11. 独立新进程复跑

正式生成后，全新进程只重跑：

```text
16 sources × R0 × 4 conditions = 64 outputs
```

逐格比较八项预注册字段：

| 字段 | exact |
|---|---:|
| run seed | 64 / 64 |
| prompt hash | 64 / 64 |
| complete generated token IDs | 64 / 64 |
| decoded text | 64 / 64 |
| EOS state | 64 / 64 |
| truncation state | 64 / 64 |
| CPU RNG pre-state hash | 64 / 64 |
| CUDA RNG pre-state hash | 64 / 64 |

因此这份固定合同同时满足：

```text
不同 seed：63 / 64 同格轨迹分叉
相同合同：64 / 64 新进程轨迹 exact
```

“采样会变化”和“采样可复现”并不矛盾。

exact replay 不承诺跨 PyTorch、Transformers、CUDA kernel、硬件或 batch 合同复现。

---

## 12. 工件与 hash chain

| 工件 | bytes | SHA-256 |
|---|---:|---|
| formal sampling | 1,980,601 | `f013132485f27adce008f03f781bed9982efc0d7939f13faede01c9f6f3d7f7c` |
| independent evaluation | 370,580 | `e88b274599fc5951561f9e5e7438fb4d6d25f341ae3bc4a2c4121877a0db8975` |
| fresh-process R0 rerun | 597,066 | `143dc9d0f7c914db4781e36b1401cdc9fbc2971a0dca71188bab0f8cedb002a6` |
| reproduction comparison | 30,037 | `ec4a47894953f5d73bb62211b588632ef7032da0e915218992b7fc3ef9c2a556` |
| source-blocked analysis | 168,001 | `d0dece388998fee419d34ff33f140695a9fedef6e79799cdf42eb283b047bc84` |

前端压缩工件：

```text
src/data/deepseek-v2-lite-chat-cross-source-sampling-compact.json
SHA-256 d0ab65646c6119bdeafeb451103dc6afebff3624a1e05f13a45a52ad965be1af
```

builder 在生成前端数据之前验证：

1. evaluator 输入 hash 指向正式 sampling；
2. reproduction 的 formal/rerun hashes 指向对应文件；
3. analysis 的三项输入 hashes 全部一致；
4. 64 格八项复现字段全部 exact；
5. `16 × 4 × 4 = 256` 网格合同成立。

---

## 13. 一手来源与实现身份

### 13.1 官方 checkpoint 配置

- DeepSeek-V2-Lite-Chat generation config：
  <https://huggingface.co/deepseek-ai/DeepSeek-V2-Lite-Chat/blob/main/generation_config.json>

这里只把固定 revision 文件中的 `.3/.95` 记为作者发布配置；`top_k=0` 是本实验为关闭
Transformers 通用 top-k 而显式加入的执行参数。

### 13.2 nucleus sampling

- Holtzman et al., *The Curious Case of Neural Text Degeneration*：
  <https://arxiv.org/abs/1904.09751>

本轮使用 nucleus sampling 的有限样本，不声称恢复完整生成分布。

### 13.3 任务来源

- Chen et al., *Evaluating Large Language Models Trained on Code*：
  <https://arxiv.org/abs/2107.03374>
- Cobbe et al., *Training Verifiers to Solve Math Word Problems*：
  <https://arxiv.org/abs/2110.14168>

HumanEval official tests 与 GSM8K gold 只服务于本轮固定四题的独立评测，不生成
benchmark 总体分数。

---

## 14. 可以说与不能说

### 可以说

- 在固定 16 条 source 的网格中，250 / 256 条生成自然 EOS；
- 247 / 256 条完整 token trajectories 唯一；
- R0/R1 在 63 / 64 同 source-condition cells 分叉；
- 新进程 R0 在 64 / 64 格、八项预注册字段 exact；
- 四道 Math 的 strict pass 从 8 / 16 到 16 / 16；
- 四道 Code 的 tests pass 从 8 / 16 到 16 / 16；
- 句点在 11 / 16 条 source 上缩短平均生成长度；
- English 的域均值与多数 source 方向相反；
- Code 的 task interaction 域均值为 0，但两条非零 source 正负抵消。

### 不能说

- DeepSeek-V2-Lite-Chat 的 GSM8K 准确率是 47 / 64；
- DeepSeek-V2-Lite-Chat 的 HumanEval pass@1 是 52 / 64；
- 16 条 source 随机代表四个数据集总体；
- 4 个 seed 是 4 道独立题；
- 11 / 16 构成总体显著性；
- period 是官方有效聊天边界；
- period 普遍缩短所有 English、Math 或中文输出；
- domain mean 为 0 说明每条 source 都没有效应；
- natural EOS、AST parse 或可执行等同于正确；
- exact replay 会跨软件、硬件和 batch 合同自动成立。

---

## 15. 下一步

本轮修复了“单题多 seed 冒充多题覆盖”，但仍只有每域 4 条 source。下一轮优先级应是：

1. 把任务覆盖扩大到足以报告 task-level bootstrap，并在结果前冻结抽样框；
2. 为每条 source 使用独立 per-row RNG stream，构造真正可解释的 common-random-number
   条件对；
3. 分离 ordinary boundary token 的词法身份、频率与位置作用，不只复查句点；
4. 对 HumanEval/44 与 /133 的相反 interaction 做预注册 failure taxonomy；
5. 在足够 source 覆盖后，再决定是否值得进行干预式 mediation；
6. 继续保持生成、evaluator、统计分析与 reproduction 四套工件分离。

本轮已经回答的是：

```text
同样的 sampling 配方与输入干预，换一条 source 后，方向会不会变？
```

答案是：

```text
会，而且聚合均值有时会与多数 source 方向相反。
```