DeepSeek-V2-Lite-Chat 生成行为对照协议

状态：已执行；正式结果见 DEEPSEEK_V2_LITE_CHAT_BEHAVIOR_AUDIT.md

官方模型：deepseek-ai/DeepSeek-V2-Lite-Chat

固定 revision：85864749cd611b4353ce1decdb286193298f64c7

checkpoint 身份：SFT Chat，而非 base / RL

权重：官方 BF16，四个 safetensors shards，约 31.4 GB

0. 为什么这一轮必须换证据层

前十组实验都观察 base checkpoint 的 hidden states 与 MoE routing。它们能回答：

输入协议变化后，目标 token 的专家路径怎样改变？

但不能回答：

模型最后生成了什么？答案是否保持一致？任务结果是否改变？

因此本轮不把 route TV 继续解释成能力，而是加载完整 Chat checkpoint，实际调用 generate()。

1. 硬件边界先写在结果前面

官方 model card 明确写 BF16 inference 需要一张 40GB GPU。本机 RTX 5090 的可见显存为 32,607 MiB，所以：

不能声称“单卡 BF16 完整模型运行”；
不能因为模型最终能生成，就隐去 CPU offload；
必须记录 hf_device_map、各设备参数 bytes、峰值 CUDA memory 和进程 RSS；
若 offload 失败，量化路线必须单独命名，不能与官方 BF16 混账。

首选执行：

official BF16 weights
official modeling/configuration Python modules
eager attention（本机未安装 flash-attn，不伪装为 FlashAttention 路径）
GPU limit 29 GiB
CPU limit 80 GiB
Accelerate device_map=auto

2. 八格与上一轮保持同构

system off/on × EOS / BOS / x / period

每个 source 的八格：

先由固定官方 chat template 渲染；
EOS 为官方序列；
BOS / x / 句点在 tokenization 后只改历史边界上的一个 input ID；
同一 system 水平内等长、同目标位置、同 generation prompt；
system off/on 因 system 文本而不同长，batch 内使用 PAD=EOS 左填充且 attention_mask=0，让八格的 generation prefix 结束于同一列；
八个条件进入同一个 generation batch。

三种反事实不是官方合法 chat。它们只识别这个固定 pre-target ID 对生成的影响。

3. source 身份与前轮如何衔接

source ID、selection rank 和每域顺序直接取自 base-routing 的 special-token 正式实验，但行为探针使用完整 source 文本：

route 实验固定目标前 23 tokens，利于等长统计；
generation 需要完整问题，尤其数学与代码不能在半句话上算行为；
因此“同 source”不等于“同输入长度”，这一差异必须写进结果。

首个 smoke 只取每域 1 条，共 4 sources / 32 outputs。闸门通过后，正式运行扩到每域 4 条、16 sources / 128 outputs。

4. 解码合同

三道执行闸门固定：

smoke       = 1 source/domain × 8 conditions × 32 new tokens
formal      = 4 sources/domain × 8 conditions × 128 new tokens
long repro  = 1 source/domain × 8 conditions × 128 new tokens

do_sample   = false
decode      = greedy
use_cache   = true
EOS / PAD   = official tokenizer IDs

官方 generation_config.json 的 temperature=.3 / top_p=.95 只记录，不在首轮使用。理由不是 greedy 更“真实”，而是它能提供确定性复跑闸门。之后的 sampled distribution 必须另起协议、固定 seeds，并报告多次采样。

5. 行为输出记什么

逐条件保存：

prompt token hash；
generated token IDs 与 hash；
解码文本与 hash；
EOS 是否出现；
输出长度；
数学最后数值匹配；
Python 输出 AST 是否可解析。

逐 source 比较：

system edge：同一边界下 S0↔S1；
direct edge：同一 system 下 EOS↔BOS/x/句点；
token IDs 是否 exact；
common-prefix tokens；
token Levenshtein distance；
normalized token similarity。

代码只解析，不执行。首轮也不把 1–4 个样本称为 benchmark accuracy。

6. 通过闸门

smoke 至少需要：

四个官方 shards 与 tokenizer/model code hash 固定；
Chat tokenizer 的四个边界 ID 与前轮完全相同；
每个 source 在同一 system 水平内四个边界格等长；system off/on 的差长只由 system 文本造成，并由显式左填充吸收；
official 零 ID、counterfactual 恰好一 ID；
32 个生成调用全部正常返回，无 OOM / NaN / runtime exception；是否自然命中 EOS 另作 completion 字段，不能把达到长度上限写成完整回答；
device map 与 offload 事实进入 JSON；
独立复跑的 generated token IDs 可逐格比较；
结果只命名为小规模 deterministic behavior probe。

7. 暂时不允许的结论

“EOS 让回答更好”；
“special token 普遍优于普通 token”；
“路由 TV 解释了输出差异”；
“Chat SFT 让某个 expert 学会角色语义”；
“4 条样本代表 HumanEval / GSM8K / 中英文能力”；
“CPU offload 的延迟代表生产吞吐”；
“greedy exact / non-exact 等于采样分布稳定 / 不稳定”。

8. 执行入口

PYTHONPATH=/path/to/pinned/python-deps \
python -B \
  experiments/deepseek/v2_lite_chat_special_token_behavior_probe.py \
  --artifact-dir /path/to/deepseek-v2-lite-chat \
  --reference-routing-json \
    src/data/deepseek-v2-lite-routing-special-token-family-control.json \
  --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 /tmp/deepseek-v2-lite-chat-behavior-smoke.json \
  --per-domain 1 \
  --max-new-tokens 32 \
  --gpu-memory 29GiB \
  --cpu-memory 80GiB

smoke 通过后，正式运行把 --per-domain / --max-new-tokens 改为 4 / 128；长序列复跑保持 1 / 128，写入独立 JSON。正式与复跑都必须使用相同模型 revision、工件 hashes、数据来源、依赖版本、设备映射上限与 greedy contract。

6.0 KiB Raw Blame History Unescape Escape