Files
llm-atlas/research/DEEPSEEK_V2_LITE_CHAT_COMPLETION_PROTOCOL.md
2026-07-30 00:24:27 +08:00

10 KiB
Raw Permalink Blame History

DeepSeek-V2-Lite-Chat completion-aware 生成与任务评测协议

状态:已执行;正式结果与独立复跑均通过预注册闸门

上一阶段:DEEPSEEK_V2_LITE_CHAT_BEHAVIOR_AUDIT.md

模型:deepseek-ai/DeepSeek-V2-Lite-Chat

revision:85864749cd611b4353ce1decdb286193298f64c7

0. 这一轮要修正什么

Round 04 在 16 个固定 source、8 个条件上生成了 128 个输出,但只有 31 个自然遇到 EOS,另外 97 个在 max_new_tokens=128 处停止。编辑距离和 exact comparison 仍然是 真实观测;任务准确率却不能直接解释,因为:

没有出现最终数值
≠ 数学推理已经失败

代码在第 128 token 处不能解析
≠ 完整代码一定不能通过测试

生成达到长度上限
≠ 模型主动结束回答

本轮因此把“停止”“任务终点”“可评测”和“正确”拆成四张账。


1. 冻结不变的实验对象

下列对象全部继承 Round 04,不因结果调整:

  • 官方 SFT Chat checkpoint、12 个模型/tokenizer 文件及其 SHA-256;
  • 4 个域 × 4 个 source,共 16 个完整公开 source;
  • system off/on × EOS/BOS/x/period 八格;
  • 同 source 八格进入同一个左填充 batch;
  • EOS 为官方序列;BOS、x、句点各只替换一个历史边界 input ID;
  • greedy、do_sample=false、use_cache=true;
  • BF16 权重、官方 eager 实现与 Accelerate 模块级 CPU offload;
  • 数学和代码各只有 4 条,仍不是 benchmark。

数据身份:

  • English / Chinese 只测生成终止与成对输出变化,没有 gold correctness;
  • Math 使用 GSM8K 官方 answer;
  • Code 使用 OpenAI HumanEval 官方 prompt、test 与 entry_point;
  • gold 与 tests 从不进入模型 prompt。

来源: GSM8K、 HumanEval。


2. 统一预算,而不是选择性续写

执行阶梯:

已发布 baseline  = 4 source/domain × 8 conditions × 128 new tokens
512 smoke         = 1 source/domain × 8 conditions × 512 new tokens
512 formal        = 4 source/domain × 8 conditions × 512 new tokens
512 independent   = 1 source/domain × 8 conditions × 512 new tokens

不能只给 97 个截断格追加预算。那会让“之前是否完成”决定后续算力,破坏八格比较。512 正式运行必须重跑全部 128 格。

进入正式运行前,smoke 必须满足:

  1. 32 / 32 prompt token hashes 与 128 baseline 相同;
  2. 32 / 32 新输出的前 min(128, baseline length) 个 token 与 baseline exact;
  3. 没有 OOM、NaN 或 runtime exception;
  4. EOS、PAD、左填充和单 ID edit 合同不变;
  5. evaluator 可以对 32 格全部产出 completion state。

正式运行还必须满足:

128 / 128 prompt hashes exact
128 / 128 baseline token prefixes exact

独立复跑只覆盖每域第 1 条的 32 格,因此只能写“32 / 32 长序列复现”,不能写 “128 / 128 独立复跑”。


3. 正式运行前的显存协议修订

29 GiB static-placement smoke 成功:

CUDA resident  = embedding + layers 0–24
CPU offloaded  = layers 25–26 + final norm + lm_head
32 outputs     = 完成

但 16-source formal 在更长 source 的 512-token KV 状态下,于 offloaded lm_head 临时回装执行设备时申请 400 MiB 失败;脚本在写 JSON 前退出,没有产生可选择的正式结果。 这说明 max_memory=29GiB 只约束静态参数放置,不是 activation、KV 和临时回装后的硬峰值。

正式运行改为:

max_memory[CUDA:0] = 28 GiB
CUDA resident       = embedding + layers 0–23
CPU offloaded       = layers 24–26 + final norm + lm_head
allocator           = expandable_segments:True
八格 batch          = 不拆分

这里的 CPU offloaded 是驻留身份;Accelerate hook 会在 forward 前把模块权重带到执行 设备,不能把 device map 写成“后三层在 CPU 做矩阵乘”。

修订发生在成功 formal 结果之前。为检查它是否改变输出,28 GiB smoke 与此前 29 GiB smoke 逐格比较:

prompt hash exact         32 / 32
generated token IDs exact 32 / 32
decoded text exact        32 / 32
EOS state exact           32 / 32

因此正式运行采用 28 GiB,同时把两次 OOM、两张 device map、峰值显存和跨放置 exact 闸门全部写入审计。若成功 formal 的 baseline 前缀不是 128 / 128 exact,仍判失败。


4. 四张 completion 账

每个输出保存以下互不替代的字段:

4.1 停止账

  • natural_eos:生成序列实际遇到官方 EOS;
  • budget_truncated:未遇 EOS 且正好达到 512-token 上限;
  • other_stop:两者皆否;出现时必须单独调查。

4.2 任务终点账

  • Math:出现明确 \boxed{}、#### 或 final-answer 语言标记;
  • Code:出现闭合 Python code fence,或自然 EOS;
  • English / Chinese:没有任务终点判定器,不用句号冒充完成。

4.3 可评测账

  • Math:终点范围内能抽取规范化数值;
  • Code:抽出的 candidate 能通过 Python AST,并进入隔离沙箱;
  • 截断后的“最后一个数字”只保存为 fallback 诊断,不进入严格完成指标。

4.4 正确账

  • Math:规范化预测数值与 GSM8K gold final exact;
  • Code:HumanEval 官方 check(candidate) 在隔离沙箱退出 0;
  • 同时报告固定预算 pass 与 strict-complete pass;
  • completion-conditioned accuracy 只作选择偏差明显的诊断,不作为主准确率。

由此得到五种状态:

NATURAL_EOS
TASK_TERMINAL_BEFORE_EOS
BUDGET_TRUNCATED_WITH_FALLBACK_ONLY
BUDGET_TRUNCATED_UNRESOLVED
OTHER_STOP

5. 数学答案抽取

按以下优先级只取最后一个命中:

  1. \boxed{number};
  2. #### number;
  3. 明确的 answer/result/total/profit ... is/= number;
  4. 文本最后数值,仅作 fallback。

数字统一:

  • 去逗号;
  • Decimal 规范化;
  • 去无意义末尾零;
  • -0/+0 → 0。

主指标:

fixed_budget_numeric_exact = gold 与任何抽取结果 exact
strict_complete_numeric_exact
  = gold exact
  AND (natural EOS OR explicit final marker)

fallback exact 可以显示,但不能冒充 strict completion。


6. HumanEval 执行合同

代码抽取优先级:

  1. 包含目标 def entry_point 的 Python fence;
  2. 其他 Python fence;
  3. 文本中目标函数定义起点;
  4. 作为官方 prompt 的 completion suffix。

每个 candidate 单独进入一个全新 Docker 容器:

network          = none
filesystem       = read-only
user             = 65534:65534
capabilities     = drop ALL
no-new-privilege = true
memory / swap    = 256 MiB / 256 MiB
pids             = 64
cpus             = 0.5
wall timeout     = 5 s
/tmp             = 16 MiB tmpfs, noexec,nosuid
Python           = pinned image digest

容器没有 host mount,不读取仓库、Docker socket、凭据或网络。官方 test 和 check(entry_point) 只在容器内拼接;结果 JSON 不复制隐藏测试正文,只保存输入数据 hash、 harness hash、退出分类与运行时间。

退出分类:

  • passed;
  • assertion_failed;
  • runtime_error;
  • timeout;
  • ast_error;
  • sandbox_error。

HumanEval 官方仓库本身警告不要在不受信环境中直接执行生成代码;这里把容器隔离合同当作 结果的一部分,而不是一句“用了 sandbox”。


7. 预注册汇总

每个 condition 与 domain 同时报告:

  • natural EOS / budget truncated;
  • explicit task terminal;
  • evaluator coverage;
  • math fixed-budget exact / strict-complete exact;
  • code AST / executed / passed;
  • completion class 计数;
  • mean generated tokens。

成对比较继续报告:

  • token IDs exact;
  • common prefix;
  • edit distance;
  • normalized similarity。

另外新增:

  • 128→512 completion gain;
  • 128-token prefix exact;
  • 32-cell 独立复跑 exact;
  • 每个比较边两侧的 completion class,防止“一个完整、一个截断”被压成单个 edit distance。

每域只有 4 条,因此所有 task 分数都保留分子/分母,不报告总体能力置信区间。


8. 仍然禁止的结论

  • 512 tokens 足以代表模型最大能力;
  • EOS 条件让答案更好;
  • ordinary token 让回答更差;
  • 4 条 GSM8K / HumanEval 等于 benchmark;
  • completion-conditioned accuracy 可以与标准 pass@1 横比;
  • greedy deterministic exact 等于 sampling robustness;
  • HumanEval 通过说明代码安全;
  • Chat 输出变化由 Base 前六层 route TV 造成;
  • CPU offload 延迟代表生产吞吐。

9. 与全 27 层 trace 的接口

完整 27 层 forward 是另一条证据线:

completion evaluator → 回答“输出是否结束、可评测、正确”
27-layer trace       → 回答“同一输入怎样经过全部层与 26 个 MoE gates”

二者只有在同 checkpoint、同完整输入、同 condition、同 prompt hash 下才能做预注册关联; 即使 route feature 与输出分叉相关,也不能自动升级为中介因果。


10. 执行后登记(不回写预注册定义)

正式结果见 DEEPSEEK_V2_LITE_CHAT_COMPLETION_DEPTH_AUDIT.md。这里只登记协议闸门:

512 formal
  prompt hash 与 baseline exact       128 / 128
  baseline generated prefix exact     128 / 128
  natural EOS                         121 / 128
  budget truncated                      7 / 128

512 independent subset
  完整 generated token IDs exact       32 / 32
  decoded text / EOS / truncation exact 32 / 32

full-depth independent subset
  source object 去 runtime 后 exact      4 / 4
  hidden tensor hashes exact         1,856 / 1,856
  ordered route hashes exact         1,664 / 1,664
  route-weight hashes exact          1,664 / 1,664

正式生成 SHA-256: 6af40512c5868caab0ef58356aaa7728384f2b7acc7c502aa89478fdf5a2a468。

正式全深度 trace SHA-256: 5678ed238f13e3b0d5cf7a3db2268dbddf13f047cdc3730771ba1c66d96426e8。