feat: add DeepSeek Chat behavior evidence
This commit is contained in:
wuyang
@@ -0,0 +1,434 @@
|
||||
# DeepSeek-V2-Lite-Chat 最终生成行为审计
|
||||
|
||||
> 状态：Round 04 正式结果
|
||||
>
|
||||
> 正式原始 JSON：`src/data/deepseek-v2-lite-chat-behavior.json`
|
||||
>
|
||||
> 长序列复跑 JSON：`src/data/deepseek-v2-lite-chat-behavior-repro-1pd.json`
|
||||
>
|
||||
> 执行脚本：`experiments/deepseek/v2_lite_chat_special_token_behavior_probe.py`
|
||||
>
|
||||
> 预注册协议：`research/DEEPSEEK_V2_LITE_CHAT_BEHAVIOR_PROTOCOL.md`
|
||||
|
||||
## 0. 一句话结论
|
||||
|
||||
固定官方 SFT Chat checkpoint、greedy decoding 与同 source 八格 batch 后，一处历史边界
|
||||
ID 或一条 system message 经常足以让最终 token 轨迹分叉；但本轮 128 个输出中只有 31 个
|
||||
在 128-token 上限内遇到 EOS，因此它识别的是**小样本确定性输出敏感性**，不是任务能力、
|
||||
采样分布稳定性，也不是“某种 token 更好”。
|
||||
|
||||
---
|
||||
|
||||
## 1. 为什么上一轮还不能回答这个问题
|
||||
|
||||
上一组 special-token family 实验加载的是 `DeepSeek-V2-Lite` Base checkpoint，只观察
|
||||
前六个 MoE 层的 hidden states 与 top-6 expert routes。它能回答：
|
||||
|
||||
```text
|
||||
同一个 pre-target input ID 被替换以后，
|
||||
后续目标 token 的专家路径怎样改变？
|
||||
```
|
||||
|
||||
但它不能回答：
|
||||
|
||||
```text
|
||||
完整模型最后生成了什么？
|
||||
两格输出是否逐 token 相同？
|
||||
任务结果有没有改变？
|
||||
```
|
||||
|
||||
本轮因此换到官方
|
||||
[`deepseek-ai/DeepSeek-V2-Lite-Chat`](https://huggingface.co/deepseek-ai/DeepSeek-V2-Lite-Chat)
|
||||
SFT checkpoint，并真正调用 `generate()`。DeepSeek 官方仓库把 Lite-Chat 明确列作
|
||||
16B total / 2.4B active / 32K context 的 **SFT** 模型；它与较大的 V2-Chat (RL) 不是
|
||||
同一个 checkpoint 身份。
|
||||
来源：
|
||||
[DeepSeek-V2 官方仓库](https://github.com/deepseek-ai/DeepSeek-V2)、
|
||||
[DeepSeek-V2 报告](https://arxiv.org/abs/2405.04434)。
|
||||
|
||||
这也意味着：
|
||||
|
||||
- Base routing 与 Chat generation 是两种证据层；
|
||||
- 不能把二者的 effect size 直接相减；
|
||||
- 不能把 Chat 输出分叉倒推成某个 expert 的因果中介；
|
||||
- 不能把 SFT checkpoint 写成 R1、RL 或当前线上 DeepSeek。
|
||||
|
||||
---
|
||||
|
||||
## 2. 固定了什么
|
||||
|
||||
### 2.1 模型工件
|
||||
|
||||
| 对象 | 固定值 |
|
||||
|---|---:|
|
||||
| 模型 | `deepseek-ai/DeepSeek-V2-Lite-Chat` |
|
||||
| revision | `85864749cd611b4353ce1decdb286193298f64c7` |
|
||||
| checkpoint 身份 | SFT Chat |
|
||||
| dtype | BF16 |
|
||||
| safetensors shards | 4 |
|
||||
| index tensor bytes | `31,412,968,448` |
|
||||
| shard file bytes（含 headers） | `31,413,626,576` |
|
||||
| 文件数 | 12 |
|
||||
| revision metadata | 12 / 12 同一 revision |
|
||||
|
||||
运行时参数 bytes 按 dtype 汇总也是 `31,412,968,448`，全部为 `torch.bfloat16`，与
|
||||
index 的 `metadata.total_size` 精确相等。
|
||||
|
||||
正式原始结果：
|
||||
|
||||
```text
|
||||
542,559 bytes
|
||||
SHA-256 54496955d0dd20a3116e6b758a55f56e2444c43dd99bfef94a2cb7b140e6196e
|
||||
```
|
||||
长序列复跑：
|
||||
|
||||
```text
|
||||
153,819 bytes
|
||||
SHA-256 b74c31606c0fc70a8e52cc6c3d6135c4e916d698b4d5dae51863124d025b0c72
|
||||
```
|
||||
|
||||
### 2.2 tokenizer
|
||||
|
||||
Chat 与 Base 的 `tokenizer.json`、`tokenizer_config.json` 逐字节相同：
|
||||
|
||||
```text
|
||||
tokenizer.json
|
||||
41f3bf64213da8c012d8bd0871a58a1fdf70463e8f08f110ddbb1082f529f669
|
||||
|
||||
tokenizer_config.json
|
||||
31181eaf79394ea26728d95ecb54fe7c8413e6f56085dbabc8b0818134380ec8
|
||||
```
|
||||
|
||||
固定边界 ID：
|
||||
|
||||
| level | ID | 类别 | 官方合法历史边界 |
|
||||
|---|---:|---|---|
|
||||
| EOS | `100001` | special；同时是 PAD alias | 是 |
|
||||
| BOS | `100000` | special | 否 |
|
||||
| `x` | `87` | ordinary content | 否 |
|
||||
| `.` | `13` | ordinary punctuation | 否 |
|
||||
|
||||
EOS 与 BOS 穷尽这个固定 tokenizer 的 special-token inventory。BOS / `x` / 句点三格
|
||||
都不是官方合法 Chat 序列，它们只是在 official rendering 后替换一个 pre-target
|
||||
input ID 的反事实控制。
|
||||
|
||||
---
|
||||
|
||||
## 3. 八格设计
|
||||
|
||||
```text
|
||||
system off/on × EOS / BOS / x / period
|
||||
```
|
||||
|
||||
同一 system 水平内：
|
||||
|
||||
- 四格 token 数相同；
|
||||
- target content、generation prompt 与 target position 相同；
|
||||
- EOS 格相对官方序列改 0 个 ID；
|
||||
- BOS / `x` / period 各恰好改 1 个 ID。
|
||||
|
||||
system on 比 system off 多 16 个 token。八格同 batch 时使用：
|
||||
|
||||
```text
|
||||
PAD = EOS
|
||||
left padding
|
||||
attention_mask = 0 on padding
|
||||
generation prefix ends at the same batch column
|
||||
```
|
||||
|
||||
这次协议修订发生在成功加载模型之前。最初“八格全部同长度”的检查忽略了 system 文本本身
|
||||
会增加长度；失败后把合同改成“同一 system 水平内等长 + batch 左填充”。这不是结果后改
|
||||
统计口径，而是修复一个无法构造 tensor 的前置序列错误。
|
||||
|
||||
---
|
||||
|
||||
## 4. source 合同
|
||||
|
||||
正式运行：
|
||||
|
||||
```text
|
||||
4 domains × 4 sources/domain = 16 sources
|
||||
16 sources × 8 conditions = 128 outputs
|
||||
```
|
||||
|
||||
四域：
|
||||
|
||||
- English encyclopedia / WikiText-2 raw validation；
|
||||
- Chinese news / CLUE TNEWS public test；
|
||||
- Python code / HumanEval；
|
||||
- Grade-school math / GSM8K test。
|
||||
|
||||
source ID、selection rank 与域内顺序直接复用 Base special-token 正式实验。每条 source
|
||||
的文本 SHA-256 重新核验；但本轮使用**完整 source 文本**，而路由实验使用固定目标前
|
||||
23 tokens。这是为了让数学题和代码 prompt 不在半句话上生成。
|
||||
|
||||
因此：
|
||||
|
||||
```text
|
||||
同 source 身份 = 是
|
||||
同 checkpoint = 否（Base → SFT Chat）
|
||||
同输入文本长度 = 否（23-token prefix → full source）
|
||||
同证据对象 = 否（routes → generated outputs）
|
||||
```
|
||||
|
||||
每域 4 条是预定 source 顺序的前四条，不是 benchmark 的代表性抽样，也没有能力估计所需
|
||||
的样本量。
|
||||
|
||||
---
|
||||
|
||||
## 5. 解码合同
|
||||
|
||||
正式运行固定：
|
||||
|
||||
```text
|
||||
decode = greedy
|
||||
do_sample = false
|
||||
temperature = unset
|
||||
top_p = unset
|
||||
max_new_tokens = 128
|
||||
use_cache = true
|
||||
```
|
||||
|
||||
官方 `generation_config.json` 另行记录：
|
||||
|
||||
```text
|
||||
do_sample = true
|
||||
temperature = 0.3
|
||||
top_p = 0.95
|
||||
```
|
||||
|
||||
它没有用于本轮。选择 greedy 的目的，是先建立逐 token 复跑闸门，不是宣称 greedy 比
|
||||
官方 sampling 更真实。
|
||||
|
||||
---
|
||||
|
||||
## 6. 完整 BF16 权重怎样装进本机
|
||||
|
||||
官方 Lite model card 写明 BF16 inference 需要一张 40GB GPU。本机 RTX 5090 可见
|
||||
32,607 MiB，因此不能声称“单卡完整 BF16”。实际运行使用：
|
||||
|
||||
```text
|
||||
Accelerate device_map = auto
|
||||
max_memory[CUDA:0] = 29 GiB
|
||||
max_memory[CPU] = 80 GiB
|
||||
attention = official eager path
|
||||
```
|
||||
|
||||
Hugging Face 的
|
||||
[Big Model Inference 文档](https://huggingface.co/docs/accelerate/main/concept_guides/big_model_inference)
|
||||
说明，`hf_device_map` 是查看自动放置的正式入口；CPU-offloaded weights 会通过 hook 在
|
||||
需要时进入执行设备。正式 device map：
|
||||
|
||||
```text
|
||||
CUDA:0 embed_tokens + layers 0–24
|
||||
CPU layers 25–26 + final norm + lm_head
|
||||
```
|
||||
|
||||
| 执行账 | 观测 |
|
||||
|---|---:|
|
||||
| CUDA 参数 tensor bytes | `28,654,142,464` |
|
||||
| offload hooks 暴露为 meta 的 tensor bytes | `2,758,825,984` |
|
||||
| load peak CUDA allocation | `29,786,618,368` bytes |
|
||||
| formal peak CUDA allocation | `31,578,740,224` bytes ≈ `29.41 GiB` |
|
||||
| process max RSS | `18,665,132 KiB` ≈ `17.80 GiB` |
|
||||
| model load | `8.58 s` |
|
||||
| 16 个 source batch generation | `369.67 s` |
|
||||
|
||||
`29GiB max_memory` 约束参数放置，不是包含 KV cache、activation 和 CUDA runtime 的硬峰值；
|
||||
因此实际 generation peak 高于 29GiB 不构成合同矛盾。
|
||||
|
||||
Accelerate-offloaded modules 在 forward 间可把 `parameter.device` 暴露为 `meta`；这里用
|
||||
`hf_device_map` 判断 CPU placement，不能把 `meta` 字面解释为“参数不存在”。
|
||||
|
||||
这些延迟只描述本机 eager + CPU offload 审计，不代表 SGLang、vLLM、FlashMLA 或生产
|
||||
serving 吞吐。DeepSeek 官方仓库也明确区分 Hugging Face 开源实现与优化 serving 路径。
|
||||
|
||||
---
|
||||
|
||||
## 7. 正式结果：输出是否 exact
|
||||
|
||||
十条预注册比较边：
|
||||
|
||||
| edge | exact / 16 | mean common prefix | mean edit distance | mean token similarity |
|
||||
|---|---:|---:|---:|---:|
|
||||
| system · EOS | 2 / 16 | 32.875 | 64.625 | 48.26% |
|
||||
| system · BOS | 1 / 16 | 22.125 | 74.000 | 40.95% |
|
||||
| system · x | 0 / 16 | 4.875 | 95.188 | 24.15% |
|
||||
| system · period | 0 / 16 | 4.500 | 94.813 | 24.82% |
|
||||
| BOS − EOS · S0 | 2 / 16 | 24.563 | 75.125 | 39.89% |
|
||||
| BOS − EOS · S1 | 1 / 16 | 17.500 | 77.813 | 37.49% |
|
||||
| x − EOS · S0 | 0 / 16 | 12.563 | 79.188 | 37.18% |
|
||||
| x − EOS · S1 | 0 / 16 | 9.813 | 85.500 | 29.82% |
|
||||
| period − EOS · S0 | 1 / 16 | 22.250 | 80.375 | 35.88% |
|
||||
| period − EOS · S1 | 0 / 16 | 3.688 | 85.750 | 30.30% |
|
||||
|
||||
`token similarity = 1 - Levenshtein distance / max(output lengths)`。
|
||||
|
||||
能写的最窄结论：
|
||||
|
||||
> 在这 16 条固定 source、固定 SFT Chat checkpoint 与 greedy contract 下，system
|
||||
> message 和一个历史边界 ID 都可能改变最终生成 token 序列；完整 exact 是少数，而不是
|
||||
> 默认状态。
|
||||
|
||||
不能写：
|
||||
|
||||
- system / EOS “普遍重要”；
|
||||
- x / 句点“更差”；
|
||||
- special token “更稳定”；
|
||||
- edit distance 越大，能力变化越大；
|
||||
- 输出分叉由前六层 route TV 解释。
|
||||
|
||||
四个 ID 既不是随机从 token 类别总体抽样，16 条 source 也不是总体样本，所以不存在可靠
|
||||
的 “special vs ordinary 类别效应”。
|
||||
|
||||
---
|
||||
|
||||
## 8. 分域结果最醒目的差异
|
||||
|
||||
### 8.1 official system edge（S0 EOS ↔ S1 EOS）
|
||||
|
||||
| 域 | exact / 4 | mean similarity |
|
||||
|---|---:|---:|
|
||||
| English encyclopedia | 0 / 4 | 51.37% |
|
||||
| Chinese news | 0 / 4 | 28.57% |
|
||||
| Python code | 0 / 4 | 29.10% |
|
||||
| Grade-school math | 2 / 4 | 83.98% |
|
||||
|
||||
数学格在这个极小 cohort 上更常 exact，但不能据此说“数学更不受 system 影响”。它可能来自
|
||||
source 内容、固定 greedy path、输出长度或 checkpoint 特定模式；每域只有 4 条。
|
||||
|
||||
### 8.2 x / period 下的 system edge
|
||||
|
||||
system × `x` 和 system × period 都是 0 / 16 exact，平均 similarity 分别为 24.15% /
|
||||
24.82%。这说明两个固定 ordinary counterfactual 下，system on/off 的 greedy 轨迹在本
|
||||
cohort 中更常早分叉；它仍不证明 ordinary token 类别导致更强 system effect。
|
||||
|
||||
---
|
||||
|
||||
## 9. 截断率是主结果，不是脚注
|
||||
|
||||
按 condition 的 EOS 完成数：
|
||||
|
||||
| condition | hit EOS / 16 | max-128 truncated / 16 |
|
||||
|---|---:|---:|
|
||||
| S0 EOS | 2 | 14 |
|
||||
| S1 EOS | 3 | 13 |
|
||||
| S0 BOS | 3 | 13 |
|
||||
| S1 BOS | 3 | 13 |
|
||||
| S0 x | 2 | 14 |
|
||||
| S1 x | 8 | 8 |
|
||||
| S0 period | 2 | 14 |
|
||||
| S1 period | 8 | 8 |
|
||||
| **合计** | **31 / 128** | **97 / 128** |
|
||||
|
||||
因此本轮保存了 math final-number 与 Python AST parse 作为诊断字段，却不把它们做成能力
|
||||
比较。比如某格的数学 final number 没出现，可能只是输出仍在推导；某格 AST parse 失败，
|
||||
也可能只是 code fence 在第 128 token 被截断。
|
||||
|
||||
在公平能力表之前，下一协议至少需要：
|
||||
|
||||
1. 足够高的 completion contract，或明确定义 stop / answer extractor；
|
||||
2. 代码实际执行与 sandbox；
|
||||
3. 每个任务足够样本；
|
||||
4. 对所有格使用相同完成预算与失败规则；
|
||||
5. 报告 truncation、refusal、format failure；
|
||||
6. 与 greedy 分开的多 seed sampling protocol。
|
||||
|
||||
---
|
||||
|
||||
## 10. 复跑闸门
|
||||
|
||||
### 10.1 128-token 长序列复跑
|
||||
|
||||
复跑每域首条，共 4 source / 32 格。与正式 16-source 结果按
|
||||
`source_id × condition` 对齐：
|
||||
|
||||
```text
|
||||
prompt token hash exact 32 / 32
|
||||
generated token IDs exact 32 / 32
|
||||
decoded text exact 32 / 32
|
||||
EOS state exact 32 / 32
|
||||
```
|
||||
|
||||
其余 96 格没有做完整 128-token 独立复跑，网站和文档都不写成“128 / 128 rerun”。
|
||||
|
||||
### 10.2 smoke 与正式前缀
|
||||
|
||||
4 source / 32 格的 32-token smoke 做了独立复跑，32 / 32 generated token IDs 与文本
|
||||
exact；正式 128-token 结果的前 32 tokens 也与 smoke 32 / 32 exact。
|
||||
|
||||
这支持“固定 greedy contract 可复跑”，不支持 sampling distribution 稳定。
|
||||
|
||||
---
|
||||
|
||||
## 11. 执行过程中暴露并记录的问题
|
||||
|
||||
### 11.1 system 长度
|
||||
|
||||
最初错误地检查“八格全等长”。system on 本来就多 16 tokens；改为同一 system 水平内
|
||||
四个 boundary 格等长，并用显式左填充组成八格 batch。
|
||||
|
||||
### 11.2 Python 环境污染
|
||||
|
||||
早期命令把 `/usr/lib/python3/dist-packages` 混入 pyenv Python 3.10，触发 Pillow
|
||||
`_imaging` 二进制不匹配。当前虚拟环境已经包含 pandas / pyarrow / Pillow，正式运行移除
|
||||
系统路径。
|
||||
|
||||
### 11.3 `flash_attn` 动态依赖检查
|
||||
|
||||
Transformers 4.41 的 remote-code import scanner 把官方源码中受
|
||||
`is_flash_attn_2_available()` 保护的 import 仍判成硬依赖。本机没有 flash-attn，正式运行
|
||||
沿用前轮审计过的 loader，把官方 `configuration_deepseek.py` /
|
||||
`modeling_deepseek.py` 作为本地 package 直接加载，并走官方 eager attention。
|
||||
|
||||
官方模型源码没有打补丁：
|
||||
|
||||
```text
|
||||
modeling_deepseek.py
|
||||
7d8e5221095286eea991137760893fd7ba52727c0b4ebf48ec09e8bc56b45b9c
|
||||
```
|
||||
|
||||
### 11.4 official sampling config 的 warning
|
||||
|
||||
第一次 smoke 明确传 `do_sample=False`，但 model 自带 `.3 / .95` 导致 warning。正式脚本
|
||||
同时把 `temperature` / `top_p` unset，消除“记录但未使用”的歧义；生成前缀复跑仍逐格
|
||||
exact。
|
||||
|
||||
---
|
||||
|
||||
## 12. 这轮最重要的非结论
|
||||
|
||||
1. **不是 benchmark。** 每域 4 条，且 97 / 128 截断。
|
||||
2. **不是 token 类别总体效应。** 两个 special、两个人为选择的 ordinary ID。
|
||||
3. **不是合法 Chat 对比。** BOS / `x` / period 是单 ID 反事实。
|
||||
4. **不是 route → output 中介分析。** Base / Chat checkpoint 与输入长度都不同。
|
||||
5. **不是 sampling robustness。** 只测 greedy。
|
||||
6. **不是单卡 BF16。** 明确使用 CPU offload。
|
||||
7. **不是生产性能。** eager + CPU offload 延迟只供执行审计。
|
||||
8. **不是 RL checkpoint。** Lite-Chat 是 SFT。
|
||||
|
||||
---
|
||||
|
||||
## 13. 下一闸门
|
||||
|
||||
优先级：
|
||||
|
||||
1. 把正式行为实验扩成 completion-aware protocol，先解决 97 / 128 截断；
|
||||
2. 对数学做完整 answer extraction，对代码做 sandbox execution；
|
||||
3. 独立设计多 seed sampling distribution 对照；
|
||||
4. 在 Base 与 Chat 上用同一完整输入抽取 27 层 hidden / routes；
|
||||
5. 预注册 route features 与 output divergence 的关联分析，并明确它仍不是中介因果；
|
||||
6. 再推进支持硬件上的 FlashMLA、FP8 / pipeline traces 与 R1-like 小模型训练。
|
||||
|
||||
本轮真正完成的是从：
|
||||
|
||||
```text
|
||||
“路由看起来变了”
|
||||
```
|
||||
|
||||
前进到：
|
||||
|
||||
```text
|
||||
“完整 SFT Chat 权重实际生成后，哪些固定格子逐 token 相同，
|
||||
哪些分叉，以及证据为什么仍然不能越界。”
|
||||
```
|
||||
Reference in New Issue
Block a user