# DeepSeek-V2-Lite 历史边界 Token 控制审计

> 状态：真实官方权重执行（X）<br />
> 模型：`deepseek-ai/DeepSeek-V2-Lite` **base checkpoint**<br />
> revision：`604d5664dddd88a0433dbae533b7fe9472482de0`<br />
> 执行边界：layer 0–6；观测 MoE layer 1–6<br />
> 样本：WikiText-2 / TNEWS / HumanEval / GSM8K 各 32 条<br />
> 正式运行与独立复跑：byte-exact<br />
> 完整 JSON SHA-256：`9bb93834ffd8536aeebe4325e45d2179ba590554c6ff6b6fcceaba2f499b9c37`

## 0. 一句话先说结论

在固定 DeepSeek-V2-Lite base 权重、固定 128 个公开样本、固定重复词元
历史、固定角色标记、固定长度、固定目标位置和固定八格 batch 时：

> 把历史 assistant 后面的官方 EOS token 换成 `x`、句点或换行这三个
> 单 token 对照，会让后续目标内容对 system 开关表现出更大的专家路由差异。

目标内容、prompt-balanced 口径下，六个 MoE 层 × 四个域的平均
system-edge total variation（TV）为：

```text
官方 EOS      .0374
x             .0539
句点          .0553
换行          .0492
```

但这句话必须与下面四条边界一起读：

1. 本实验使用的是 **base checkpoint**，不是 Chat/SFT checkpoint；
2. 三个替换条件不是官方有效对话序列，而是精确的 token-ID 反事实；
3. 下一条 `User:` 角色标记仍然存在，所以没有“移除全部回合边界”；
4. 本实验没有生成答案，因此没有证明 EOS 让回答更好、更稳或更正确。

最准确的命名是：

> **历史 assistant 边界上的单 token 身份路由控制。**

---

## 1. 为什么要继续拆上一轮

上一轮把 system 开/关与三种历史组合成了 2×3：

```text
none → repeated-token filler → fixed demo
```

其中 filler 与 demo：

- 都增加 17 个官方模板 token；
- 都包含一个 user turn；
- 都包含一个 assistant turn；
- 都在 assistant 内容后插入 EOS；
- 都把目标 user 推到同一绝对位置。

这已经把“具体示例文本”从“历史结构”里拆出了一层。

可是 none → filler 仍然同时增加了：

- 历史文本；
- user / assistant 角色切换；
- assistant EOS；
- 目标距离；
- 一整段新的隐藏状态演化。

因此上一轮无法回答：

> 历史缓冲模式中，assistant 后面的那个 EOS token 本身是不是一个特殊边界输入？

本轮只处理这个更窄、也更可辨识的问题。

---

## 2. 先看官方模板到底做了什么

固定 revision 的官方 `tokenizer_config.json` 中，核心模板是：

```jinja
{% if message['role'] == 'user' %}
  {{ 'User: ' + message['content'] + '\n\n' }}
{% elif message['role'] == 'assistant' %}
  {{ 'Assistant: ' + message['content'] + eos_token }}
{% elif message['role'] == 'system' %}
  {{ message['content'] + '\n\n' }}
{% endif %}
```

所以 repeated-token 历史与目标 user 被序列化为：

```text
<BOS>
User: x x x x x x x x x

Assistant: x
<EOS>
User: TARGET

Assistant:
```

这里的 `<EOS>` 不是我们根据字符串猜出来的边界。

在固定 tokenizer 中：

| 名称 | 文本 / special token | token ID | token 数 |
|---|---|---:|---:|
| 官方 EOS | `<｜end▁of▁sentence｜>` | `100001` | 1 |
| 内容对照 | `x` | `87` | 1 |
| 标点对照 | `.` | `13` | 1 |
| 格式对照 | `\n` | `185` | 1 |

四个 ID 完全不同；后三者不是 special token。

官方模板事实可以在
[固定模型工件](https://huggingface.co/deepseek-ai/DeepSeek-V2-Lite/blob/604d5664dddd88a0433dbae533b7fe9472482de0/tokenizer_config.json)
中直接检查。

---

## 3. 为什么不直接“删掉 EOS”

最直觉的 EOS 消融是：

```text
有 EOS  vs  没有 EOS
```

但直接删除会同时改变：

- 总 token 数；
- 目标 user 的绝对位置；
- RoPE 位置；
- padded sequence；
- 矩阵形状或有效 attention mask；
- 后续所有 token 在批中的列号。

那样看到差异时，无法知道它来自 EOS 身份还是“一格位置移动”。

因此本轮采用一条更干净的干预：

```text
官方 token IDs
... Assistant :  x  EOS  User : ...

反事实 token IDs
... Assistant :  x   x   User : ...
... Assistant :  x   .   User : ...
... Assistant :  x  \n   User : ...
```

每次只改一个历史 token ID。

这样可以固定：

- 序列长度；
- 目标绝对位置；
- user / assistant 文本；
- `User:` / `Assistant:` 角色标记；
- attention mask；
- generation prompt；
- 同一次 forward 的 batch shape。

代价是：

> 三个替换条件不再是官方 chat template 能自然产生的合法序列。

所以它们必须叫 **token-ID counterfactuals**，不能叫三种官方模板。

---

## 4. 2×4 设计

两个因子是：

- `S`：system 关闭 / 开启；
- `B`：边界 ID 为 EOS / `x` / `.` / `\n`。

八格如下：

| 条件 | system | 历史边界 | 官方序列 |
|---|---:|---|---:|
| `S0 / EOS` | 0 | EOS `100001` | 是 |
| `S1 / EOS` | 1 | EOS `100001` | 是 |
| `S0 / X` | 0 | `x` ID `87` | 否，单 ID 反事实 |
| `S1 / X` | 1 | `x` ID `87` | 否，单 ID 反事实 |
| `S0 / PERIOD` | 0 | `.` ID `13` | 否，单 ID 反事实 |
| `S1 / PERIOD` | 1 | `.` ID `13` | 否，单 ID 反事实 |
| `S0 / NEWLINE` | 0 | `\n` ID `185` | 否，单 ID 反事实 |
| `S1 / NEWLINE` | 1 | `\n` ID `185` | 否，单 ID 反事实 |

同一个 source prompt 的八格进入同一个 right-padded batch。

正式运行采用：

```text
batch-prompts = 4
rows per batch = 4 prompts × 8 conditions = 32
```

---

## 5. 三个问题，三个不同统计量

### 5.1 system 对目标路由影响多大

设：

```text
P(s, b, l, d)
```

为 system 水平 `s`、边界 `b`、层 `l`、域 `d` 的目标内容专家份额分布。

边界 `b` 下的 system edge 是：

```text
Δ_b = P(S1, b) - P(S0, b)
```

实际两分布之间的 standard TV 是：

```text
TV_b = 1/2 × Σ_e |P(S1, b, e) - P(S0, b, e)|
```

它回答：

> 开关固定 system 消息，目标 token 的总体专家份额移动了多少？

### 5.2 替换 EOS 后，system edge 变大还是变小

对每个普通 token 对照：

```text
C_x       = TV_x       - TV_EOS
C_period  = TV_period  - TV_EOS
C_newline = TV_newline - TV_EOS
```

若 `C_x > 0`，只表示：

> 在这个协议里，把 EOS 换成 `x` 后，system 开关造成的目标路由距离更大。

它不表示：

- EOS 更正确；
- EOS 更有语义；
- EOS 提高准确率；
- `x` 是噪声；
- system 的内容被“记住”或“忘掉”。

### 5.3 EOS 替换本身改了多少路由

固定 system 水平，定义：

```text
D_s,b = TV(P(s, EOS), P(s, b))
```

再比较：

```text
I_b = D_1,b - D_0,b
```

它回答：

> system 的存在是否会改变目标路由对边界 ID 替换的敏感度？

`I_b` 不是传统线性模型中的标量主效应，而是两个实际分布距离的差。

---

## 6. 为什么 bootstrap 必须八格共用

每个域有 32 个 source prompts。

本轮使用 2,000 次 source-paired bootstrap：

1. 对一个 layer × domain × scope × aggregation 生成一张
   `2000 × 32` source index 矩阵；
2. 同一张矩阵同时重采八个条件；
3. 每次先重算八个专家分布；
4. 再计算 TV、JSD、CV 与对比；
5. 最后取 2.5% / 97.5% 分位数。

这样：

- 八格的 source 构成逐次完全相同；
- `TV_x - TV_EOS` 是配对差；
- `D_1,x - D_0,x` 也是配对差；
- 不会把 token 当成独立样本。

24 个 layer × domain 区间仍然是描述性格子：

> 没有进行家族级多重检验校正。

---

## 7. 正式执行账

### 7.1 语料与变体

| 项目 | 数量 |
|---|---:|
| 源 prompts | 128 |
| 每域 | 32 |
| 条件数 | 8 |
| prompt variants | 1,024 |
| canonical target tokens | 每条 23 |
| 六层逐条件精确对齐目标 token | 2,874 |

### 7.2 输入 token

| 条件 | 输入 token |
|---|---:|
| `S0 / EOS` | 6,074 |
| `S1 / EOS` | 8,122 |
| `S0 / X` | 6,074 |
| `S1 / X` | 8,122 |
| `S0 / PERIOD` | 6,074 |
| `S1 / PERIOD` | 8,122 |
| `S0 / NEWLINE` | 6,074 |
| `S1 / NEWLINE` | 8,122 |
| **合计** | **56,784** |

每个 source × system 分组内，四种边界逐条同长度。

### 7.3 路由量

```text
56,784 input tokens
× 6 observed MoE layers
× top-6 routed experts
= 2,044,224 route selections
```

加上前序公开实验：

```text
3,112,848 + 2,044,224 = 5,157,072
```

截至本轮，网站公开账本累计记录 **5,157,072 次真实 top-6 路由**。

### 7.4 单 ID 合同

| 校验 | 结果 |
|---|---:|
| source × system 分组 | 256 |
| 四格逐组同输入长度 | 256 / 256 |
| 四格逐组同目标起始位置 | 256 / 256 |
| 官方 EOS 格相对官方模板改 0 个 ID | 256 / 256 |
| 三个反事实格相对官方模板改 1 个 ID | 768 / 768 |

---

## 8. 主结果：24 张目标内容问题账

口径：

- scope：`target_content`
- aggregation：`prompt_balanced`
- 数字：system-edge TV
- 括号：replacement − EOS 的 source-paired 95% interval

| 层 | 域 | EOS | X | 句点 | 换行 | X−EOS | 句点−EOS | 换行−EOS |
|---:|---|---:|---:|---:|---:|---|---|---|
| 1 | 英文 | .0559 | .0836 | .0807 | .0802 | +.0277 [.0187,.0353] | +.0248 [.0166,.0310] | +.0243 [.0168,.0295] |
| 1 | 中文 | .0276 | .0505 | .0517 | .0510 | +.0229 [.0168,.0310] | +.0241 [.0169,.0319] | +.0234 [.0168,.0319] |
| 1 | 代码 | .0571 | .0804 | .0810 | .0917 | +.0233 [.0172,.0301] | +.0239 [.0173,.0298] | +.0346 [.0280,.0407] |
| 1 | 数学 | .0784 | .1069 | .1055 | .1056 | +.0285 [.0211,.0360] | +.0271 [.0197,.0342] | +.0272 [.0194,.0345] |
| 2 | 英文 | .0305 | .0432 | .0427 | .0463 | +.0127 [.0059,.0208] | +.0122 [.0047,.0202] | +.0158 [.0076,.0227] |
| 2 | 中文 | .0207 | .0272 | .0281 | .0286 | +.0066 [.0029,.0152] | +.0075 [.0029,.0143] | +.0079 [.0029,.0147] |
| 2 | 代码 | .0327 | .0532 | .0509 | .0468 | +.0205 [.0152,.0286] | +.0182 [.0126,.0252] | +.0141 [.0088,.0222] |
| 2 | 数学 | .0404 | .0522 | .0547 | .0516 | +.0118 [.0060,.0195] | +.0144 [.0082,.0222] | +.0113 [.0057,.0189] |
| 3 | 英文 | .0312 | .0432 | .0445 | .0423 | +.0120 [.0042,.0198] | +.0133 [.0052,.0189] | +.0111 [.0036,.0180] |
| 3 | 中文 | .0229 | .0317 | .0277 | .0263 | +.0088 [.0034,.0161] | +.0048 [.0003,.0126] | +.0034 [−.0008,.0122] |
| 3 | 代码 | .0403 | .0473 | .0446 | .0432 | +.0070 [.0018,.0125] | +.0043 [.0000,.0091] | +.0029 [−.0010,.0082] |
| 3 | 数学 | .0333 | .0360 | .0360 | .0422 | +.0027 [−.0014,.0100] | +.0027 [−.0008,.0104] | +.0089 [.0035,.0155] |
| 4 | 英文 | .0324 | .0510 | .0515 | .0453 | +.0187 [.0119,.0263] | +.0191 [.0128,.0267] | +.0129 [.0068,.0210] |
| 4 | 中文 | .0293 | .0404 | .0422 | .0331 | +.0111 [.0063,.0192] | +.0129 [.0085,.0204] | +.0039 [−.0002,.0109] |
| 4 | 代码 | .0413 | .0609 | .0750 | .0591 | +.0197 [.0134,.0266] | +.0337 [.0284,.0401] | +.0178 [.0133,.0259] |
| 4 | 数学 | .0512 | .0705 | .0705 | .0607 | +.0193 [.0132,.0289] | +.0192 [.0130,.0283] | +.0094 [.0045,.0168] |
| 5 | 英文 | .0342 | .0503 | .0508 | .0409 | +.0161 [.0109,.0225] | +.0165 [.0120,.0222] | +.0067 [.0012,.0137] |
| 5 | 中文 | .0256 | .0365 | .0447 | .0276 | +.0109 [.0077,.0195] | +.0191 [.0134,.0281] | +.0021 [−.0014,.0110] |
| 5 | 代码 | .0389 | .0501 | .0515 | .0384 | +.0113 [.0058,.0181] | +.0126 [.0067,.0185] | −.0004 [−.0054,.0059] |
| 5 | 数学 | .0442 | .0555 | .0530 | .0455 | +.0113 [.0049,.0195] | +.0088 [.0022,.0181] | +.0013 [−.0057,.0089] |
| 6 | 英文 | .0300 | .0562 | .0607 | .0434 | +.0262 [.0165,.0355] | +.0307 [.0220,.0395] | +.0134 [.0073,.0231] |
| 6 | 中文 | .0258 | .0428 | .0469 | .0292 | +.0170 [.0114,.0263] | +.0211 [.0152,.0315] | +.0034 [−.0007,.0118] |
| 6 | 代码 | .0320 | .0603 | .0634 | .0546 | +.0283 [.0207,.0345] | +.0314 [.0240,.0383] | +.0226 [.0137,.0307] |
| 6 | 数学 | .0427 | .0643 | .0690 | .0470 | +.0216 [.0154,.0304] | +.0264 [.0201,.0350] | +.0043 [−.0003,.0135] |

---

## 9. 把 24 张账压成可读摘要

### 9.1 平均 system-edge TV

| 边界 | 平均 TV | 相对 EOS |
|---|---:|---:|
| EOS | .03744 | — |
| X | .05393 | +.01649，约 +44% |
| 句点 | .05531 | +.01787，约 +48% |
| 换行 | .04920 | +.01176，约 +31% |

### 9.2 方向计数

| 对比 | 点估计 replacement > EOS | 区间完全高于 0 | 跨 0 |
|---|---:|---:|---:|
| X − EOS | 24 / 24 | 23 / 24 | 1 / 24 |
| 句点 − EOS | 24 / 24 | 23 / 24 | 1 / 24 |
| 换行 − EOS | 23 / 24 | 16 / 24 | 8 / 24 |

token-weighted 口径得到几乎相同的总体图景：

```text
EOS .03742
X .05392
句点 .05531
换行 .04919
```

因此主现象不是由某几个长 prompt 在 token-weighted 口径里取得更高权重造成的。

---

## 10. 深度与领域不是平的

### 10.1 按层平均

| MoE 层 | EOS | X | 句点 | 换行 |
|---:|---:|---:|---:|---:|
| 1 | .0548 | .0803 | .0797 | .0821 |
| 2 | .0311 | .0440 | .0441 | .0433 |
| 3 | .0319 | .0396 | .0382 | .0385 |
| 4 | .0385 | .0557 | .0598 | .0496 |
| 5 | .0357 | .0481 | .0500 | .0381 |
| 6 | .0326 | .0559 | .0600 | .0436 |

边界替换效应不是简单随深度单调放大或衰减。

Layer 3 的差距最小；Layer 6 的 X / 句点差距又明显扩大。

### 10.2 按域平均

| 域 | EOS | X | 句点 | 换行 |
|---|---:|---:|---:|---:|
| 英文 | .0357 | .0546 | .0552 | .0498 |
| 中文 | .0253 | .0382 | .0402 | .0326 |
| 代码 | .0404 | .0587 | .0611 | .0556 |
| 数学 | .0484 | .0642 | .0648 | .0588 |

四个域都保留 EOS 较小的总体模式，但幅度不同。

---

## 11. 逐 token 专家集合给出第二条证据

分布 TV 可能掩盖“哪些 token 改路由”。

因此本轮同时对 2,874 个精确对齐目标 token 聚合：

- ordered top-6 exact；
- unordered top-6 set exact；
- mean top-6 Jaccard；
- mean overlap。

下面报告 system 开/关两格之间的 set exact 与 Jaccard：

| 层 | EOS exact / Jaccard | X | 句点 | 换行 |
|---:|---:|---:|---:|---:|
| 1 | .565 / .864 | .437 / .815 | .441 / .817 | .441 / .815 |
| 2 | .695 / .905 | .551 / .855 | .554 / .856 | .566 / .860 |
| 3 | .682 / .901 | .573 / .865 | .573 / .865 | .588 / .868 |
| 4 | .673 / .895 | .522 / .839 | .511 / .834 | .538 / .846 |
| 5 | .656 / .887 | .522 / .839 | .525 / .840 | .575 / .859 |
| 6 | .651 / .888 | .486 / .827 | .474 / .821 | .519 / .845 |

六层中，EOS 条件的 system-pair top-6 set exact 和 Jaccard 都高于三个普通 token 对照。

这与“EOS 下 system-edge TV 更小”同向，但不是同一个统计量：

- TV 看聚合专家份额移动；
- exact / Jaccard 看逐 token 专家集合是否保持。

---

## 12. system 会不会改变对 EOS 替换的敏感度

目标内容、prompt-balanced 下，EOS → 普通 token 的直接 TV 均值：

| 替换 | system 关 | system 开 | S1 − S0 |
|---|---:|---:|---:|
| EOS → X | .03655 | .04396 | +.00741 |
| EOS → 句点 | .03630 | .04525 | +.00896 |
| EOS → 换行 | .04094 | .04652 | +.00557 |

点估计 `S1 > S0` 的格数：

```text
X       20 / 24
句点    21 / 24
换行    18 / 24
```

但配对区间完全高于零的格数只有：

```text
X       11 / 24
句点    12 / 24
换行     8 / 24
```

所以可以报告平均交互模式，不能写成每层每域都成立的规律。

---

## 13. target content 与 full input 必须分开

### 13.1 目标内容

```text
EOS .0374 → X .0539 / 句点 .0553 / 换行 .0492
```

方向高度一致。

### 13.2 完整输入

```text
EOS       .13894
X         .14159
句点      .14026
换行      .14076
```

replacement > EOS 的点估计仅为：

```text
X       16 / 24
句点    15 / 24
换行    15 / 24
```

完整输入包含：

- system 本身；
- filler 历史；
- 被替换的边界 token；
- `User:` / `Assistant:` 包装；
- 目标内容；
- generation prompt。

一个 ID 的替换在完整输入总体计数里很容易被稀释。

因此本轮最有辨识力的结论应限定在：

> **完全相同的后续目标内容 token。**

---

## 14. 负载“更均衡”仍然不是结论

若把每个条件的专家份额压成 CV，replacement − EOS 的 system-edge
CV 对比方向为：

| 替换 | 点估计负 | 点估计正 | 区间负 / 正 / 跨零 |
|---|---:|---:|---:|
| X | 6 | 18 | 4 / 8 / 12 |
| 句点 | 6 | 18 | 4 / 10 / 10 |
| 换行 | 6 | 18 | 2 / 9 / 13 |

它不像 TV 那样高度一致。

因此本轮不能推出：

- EOS 让专家更均衡；
- ordinary token 让专家更集中；
- 更小 system-edge TV 等于更优负载均衡。

TV 衡量两条件间的路由距离，CV 衡量单条件内的份额离散程度。
两者回答不同问题。

---

## 15. BF16 batch shape 再次显示为真实复现边界

新实验的官方 EOS 条件与上一轮 filler 条件具有逐条完全相同的 token IDs：

```text
256 / 256 condition sequences token-ID hash exact
```

但上一轮 batch 是：

```text
5 prompts × 6 conditions = 30 rows
```

本轮 batch 是：

```text
4 prompts × 8 conditions = 32 rows
```

跨两次运行比较六层、128 prompts、system 开关两格：

| 对象 | exact / 1,536 |
|---|---:|
| 完整 ordered top-6 route hash | 359 |
| 目标内容 ordered top-6 route hash | 758 |
| 完整 expert-load vector | 577 |
| 目标内容 expert-load vector | 996 |

逐层完整 route hash exact：

```text
Layer 1   242 / 256
Layer 2    57 / 256
Layer 3    30 / 256
Layer 4     2 / 256
Layer 5    11 / 256
Layer 6    17 / 256
```

这不是 token 合同漂移，而是矩阵形状改变后，BF16 前向中的微小数值差异
沿层传播，并让接近 top-k 边界的 gate 排序分叉。

因此正式主结论只使用：

> 同一次 32-row 八格 batch 内的配对对比。

不能把上一轮 `.0378` 与本轮 `.0374` 当成“EOS 效应复现误差”做统计比较。

---

## 16. 这次能说“因果”到哪一层

本轮比观察性相关更强，因为在每个 EOS → control 对比中：

- source prompt 相同；
- system 相同；
- token 数相同；
- attention mask 相同；
- 目标位置相同；
- 角色标记相同；
- batch 相同；
- 只有一个历史 input ID 被替换。

因此在固定模型与固定 forward 合同内，可以说：

> 这个单 input-ID 干预造成了观测到的后续路由差异。

但不能继续跳到：

> “EOS 的语义导致模型正确关闭回合。”

缺失的证据包括：

- Chat/SFT checkpoint 对照；
- 行为生成与任务指标；
- attention / residual / gate-logit 中介；
- EOS embedding 与多个 special-token 对照；
- 去掉 `User:` 角色标记的独立实验；
- 完整 27 层。

这是“输入干预的路由因果”，不是“语义机制的完整因果解释”。

---

## 17. 文献脉络：哪些来源支持什么

### 17.1 DeepSeek 官方工件

[DeepSeek-V2-Lite tokenizer config](https://huggingface.co/deepseek-ai/DeepSeek-V2-Lite/blob/604d5664dddd88a0433dbae533b7fe9472482de0/tokenizer_config.json)
直接规定 assistant 内容后拼接 `eos_token`。

它支持：

- 本实验边界位置来自官方工件；
- 不是自行发明的字符串模板。

它不支持：

- base checkpoint 已经学习了聊天角色层级；
- EOS 的内部功能就是“回合关闭”。

### 17.2 Chat template 是序列化合同

[Hugging Face Chat Templates](https://huggingface.co/docs/transformers/en/chat_templating)
明确说明 chat 消息最终仍会变成一条线性 token 序列，角色和边界通常通过
模型特定的 control tokens 注入。

它支持：

- 角色字段本身不会被 Transformer 神奇地看见；
- 真正进入模型的是序列化 token。

它不支持：

- 任意模型都共享相同 role / EOS 语义。

### 17.3 EOT 可以成为监督目标

[LIMA: Less Is More for Alignment](https://arxiv.org/abs/2305.11206)
在用户与 assistant 说话者之间加入专门 EOT token，并训练模型在回答结束时
预测它。

它支持：

- 对话边界 token 可以通过监督训练学成。

它不支持：

- DeepSeek-V2-Lite base 的 EOS 等同于 LIMA 的 EOT；
- 本轮结果来自 instruction tuning。

### 17.4 EOS 会改变隐藏状态动力学，但任务不同

[The EOS Decision and Length Extrapolation](https://aclanthology.org/2020.blackboxnlp-1.26/)
比较训练时预测 / 不预测 EOS 的序列模型，发现 EOS 决策会伴随 length
manifolds 与 length attractors，并影响长度外推。

它支持：

- EOS 不是只能在 decoder 外部解释的“停止按钮”；
- EOS 训练目标可能改变内部表示动力学。

它不支持：

- 把 LSTM / SCAN 的结论直接迁移到 DeepSeekMoE；
- 解释本轮具体专家路由。

### 17.5 跨模型的 end-of-turn 规范

[Meta Llama 3 official prompt format](https://github.com/meta-llama/llama3)
规定每条消息以 `<|eot_id|>` 结束。

它支持：

- 现代 chat 模型确实把 message boundary 编成特殊 token。

它不支持：

- Llama 的 EOT 与 DeepSeek base EOS 具有相同内部机制。

### 17.6 irrelevant context 不是 routing 论文

[Large Language Models Can Be Easily Distracted by Irrelevant Context](https://proceedings.mlr.press/v202/shi23a.html)
与
[Lost in the Middle](https://aclanthology.org/2024.tacl-1.9/)
说明额外上下文和位置会影响行为表现。

它们支持：

- 历史内容、位置与边界值得独立控制。

它们不支持：

- route TV 必然与准确率同向；
- repeated `x` 就是一般 irrelevant context。

### 17.7 干预方法也有边界

[Towards Best Practices of Activation Patching](https://arxiv.org/abs/2309.16042)
说明干预结论会受到 metric 与 corruption method 选择影响。

本轮因此：

- 不用一个 CV 指标代表全部路由现象；
- 同报 TV、JSD、逐 token exact/Jaccard；
- 明确普通 token 对照不是自然语言合法模板；
- 不把单 ID 输入干预升级为完整内部机制定位。

---

## 18. 正式运行与独立复跑

主结果：

```text
src/data/deepseek-v2-lite-routing-history-boundary-token-control.json
```

独立复跑：

```text
src/data/deepseek-v2-lite-routing-history-boundary-token-control-repro.json
```

两者：

```text
bytes   54,254,445
SHA256  9bb93834ffd8536aeebe4325e45d2179ba590554c6ff6b6fcceaba2f499b9c37
cmp     byte-exact
```

执行命令：

```bash
PYTHONPATH=/path/to/transformers-4.41.2-deps:/usr/lib/python3/dist-packages \
python -B experiments/deepseek/v2_lite_routing_history_boundary_token_control.py \
  --artifact-dir /path/to/deepseek-v2-lite \
  --human-eval /path/to/HumanEval.jsonl.gz \
  --gsm8k /path/to/gsm8k/test.jsonl \
  --tnews /path/to/tnews/test.json \
  --tnews-archive /path/to/tnews_public.zip \
  --wikitext /path/to/wikitext-validation.parquet \
  --output src/data/deepseek-v2-lite-routing-history-boundary-token-control.json \
  --per-domain 32 \
  --content-tokens 23 \
  --batch-prompts 4 \
  --layers 7 \
  --bootstrap 2000 \
  --seed 20260729 \
  --captured-at 2026-07-29T11:12:00+00:00
```

---

## 19. 已证明、未证明、下一步

### 已证明

- 官方历史 EOS 在固定模板中是独立 token ID；
- 三个反事实条件逐条只替换该一个 ID；
- 八格逐组同长度、同目标位置、同 batch；
- EOS 下的目标内容 system-edge TV 平均小于三个普通 token 对照；
- X / 句点的方向在 24 / 24 格一致；
- 逐 token set exact / Jaccard 与分布 TV 同向；
- 正式运行与独立复跑 byte-exact。

### 未证明

- EOS “理解”了回合结束；
- base checkpoint 具有 chat role hierarchy；
- EOS 让回答更正确；
- 更小 TV 就是更优；
- `x` / 句点 / 换行代表全部普通 token；
- 现象覆盖全部 27 层；
- 现象覆盖 DeepSeek-V2-Lite-Chat；
- 现象在不同 batch shape 下 route hash 不变。

### 下一步

1. **角色标记控制**：固定内容与长度，替换 / 移除下一条 `User:` 标记；
2. **special-token 家族控制**：加入 BOS、其他已训练 special token 与多个普通 token；
3. **Chat checkpoint 对照**：比较 base 与 V2-Lite-Chat；
4. **行为联结**：生成答案，测任务正确率、格式终止与 route TV 的关系；
5. **gate-logit 中介**：记录替换后 router logits、top-k margin 与翻转位置；
6. **完整 27 层**：获得其余 shards 后扩展；
7. **固定 batch-shape 复跑**：用 dummy rows 锁定矩阵形状，验证跨实验可比性。

---

## 20. 最终课程表述

可以写：

> 在 DeepSeek-V2-Lite base 的固定前六个 MoE 层中，官方 assistant EOS
> 与三个单 token 反事实对照产生了可重复的后续路由差异；EOS 条件下，
> system 开关对精确目标内容的专家分布影响更小，且逐 token top-6 集合
> 更稳定。

不可以写：

> DeepSeek 用 EOS 理解并关闭了对话，所以回答更稳定。

前一句是当前证据。

后一句仍需要 Chat 权重、行为指标与内部中介实验。