Add DSv4.1 Flash DSpark golden AL curve / 新增黄金 AL 曲线

[Oseltamivir]

Commit the DSv4.1 Flash DSpark golden AL curve from run 34493175056: B200 TP4, UVA offload, probabilistic/block sampling, adaptive verification off, SPEED-Bench coding, temperature 1.0, output length 4096, thinking off/on, draft lengths 1–5. YAML matches the artifact byte-for-byte after provenance comments; all 800 requests succeeded and all ten AL values were independently checked against counter deltas. Sampled outputs match the intended modes; 6–8 thinking-on outputs per cell reached the 4096-token cap before ending reasoning. Lengths 6–8 failed config validation and have no fabricated values. Follows #2460: data-only, [skip-sweep]; collector is #2964.

提交上述运行的 DSv4.1 Flash DSpark 黄金 AL：B200 TP4、UVA offload、probabilistic/block 采样、关闭 adaptive verification，SPEED-Bench coding、temperature 1.0、输出上限 4096，覆盖 thinking 开关与草稿长度 1–5。除来源注释外，YAML 与产物逐字节一致；800 个请求全部成功，十个 AL 均已根据 counter 差值独立复核。抽查输出符合预期模式；每个 thinking-on 单元有 6–8 个输出在结束推理前达到 4096 token 上限。长度 6–8 验证失败，未填写虚构数值。参照 #2460，仅提交数据，使用 [skip-sweep]；采集器为 #2964。

---

Note

Low Risk
Documentation and benchmark reference data only; no runtime or auth changes.

Overview
Adds a golden acceptance-length (AL) curve for DeepSeek V4.1 Flash with DSpark (probabilistic draft, block rejection), sourced from Actions run 34493175056.

The new dsv41flash_dspark.yaml records mean AL for draft lengths 1–5 under thinking off and thinking on, with metadata for the vLLM image, TP4, SPEED-Bench coding, and sampling settings. English and Chinese READMEs list the curve in the golden-curves table and note that lengths 6–8 were not measured because the same image failed config validation before serve (run 34494319147).

^{Reviewed by Cursor Bugbot for commit 8a58c9c. Bugbot is set up for automated code reviews on this repo. Configure here.}

[claude]

I reviewed this PR and did not find any bugs. It's a small data + docs addition, but because this directory's own reviewer checklist requires confirming the committed values against the external CI artifact and server logs (things a diff-only review can't verify), a human look is still worthwhile.

What was reviewed: the new dsv41flash_dspark.yaml against the schema/comment conventions of the ten existing golden-curve YAMLs; the bilingual README.md/README_zh.md table and footnote additions for sync; and whether perf-changelog.yaml needed an entry (it wasn't touched, which is reasonable since this adds reference data, not a recipe/config change).

Extended reasoning...

Overview

The diff adds one new golden acceptance-length YAML (golden_al_distribution/dsv41flash_dspark.yaml) for DeepSeek V4.1 Flash under the DSpark probabilistic-draft/block-verification method, plus a matching row and trailing note in README.md/README_zh.md. It is a self-contained, data-and-docs-only change: no code, workflows, or configs are touched, and no other file references the new model or image tag.

Security risks

None. There is no executable code, no new dependency, no auth/permissions surface, and no user input handling — just static YAML data and markdown prose.

Level of scrutiny

This class of change (golden AL curve commit) is explicitly called out in the directory's own README as needing reviewer verification against artifacts a static diff cannot show: that every requested cell completed, that server logs show no fallback/chat-template errors, and that the committed numbers exactly match the workflow artifact. Those are precisely the checks a human with access to the linked Actions run (34493175056) can perform but an automated diff review cannot. I compared the new YAML's structure, comment header, and float formatting against the ten existing golden-curve files and found it schema-consistent (aside from omitting the "Auto-generated by <script>" provenance comment that every prior file has — plausibly because the collector script for this model, per the PR description, lands separately in #2964 rather than in this repo yet). I also checked that the bilingual docs were updated together and that the new footnote in both languages carries the same meaning.

Other factors

perf-changelog.yaml was not touched; I judge that as within scope for this data-only addition since a golden AL curve is reference data that only affects benchmark performance once a future recipe adopts it via synthetic_acceptance_length/equivalent, not on its own. I found no logic to exercise and no plausible functional bug to flag beyond the artifact-verification point above, so I'm deferring rather than approving outright, given the correctness of the committed numbers is inherently unverifiable from the repository alone.