参数抄作业也会翻车：温度与核采样的组合边界

【免费下载链接】Qwen3.5-4B-3D-Coder项目地址: https://ai.gitcode.com/hf_mirrors/ccore/Qwen3.5-4B-3D-Coder

把官方模型卡里的四行参数抄进 LM Studio，然后按回车——这大概是当下本地 3D 代码生成最常见的起手式。但 Qwen3.5-4B-3D-Coder 的 README.md 给出的Temperature 0.6–0.8 / Top P 0.90–0.95 / Repeat penalty 1.0 / Top K 20–40，本质是两个量化版本共用的一条矩形区间，而不是四组互不相干的推荐值。温度与核采样在解码器内部是串联生效的：温度先把 logits 拉平或压尖，top-k 再截断候选集，top-p 在残局里决定还要不要继续砍。抄数字的人往往只盯住单个旋钮的上下限，却忽略了它们组合之后落在分布的哪个位置——这正是"参数都对，结果还是翻车"的根源。

更麻烦的是，这个模型有几类故障在表面上极像采样越界，实际成因却完全在参数之外：默认开启的思维链、模板里的<think>前缀、量化权重里并不存在的 MTP 头。 先分清"哪些症状归参数管、哪些不归"，再谈取值 ，比背一张参数表有用得多。

一、温度与核采样不是两个独立旋钮

温度改变的是"候选集本身的质量"

采样时每个 token 的概率为p_i ∝ exp(z_i / T)。在 Transformers 的generate流程里，warper 的应用顺序是温度 → top-k → top-p，也就是说温度先污染分布，top-k/top-p 再在已经被污染过的分布上做裁剪。这意味着同一个top_p=0.95，在T=0.6和T=0.9下覆盖的候选词集合根本不是一个东西：温度升高使分布变平，同样的累积质量阈值需要吞下更多低频 token；温度降低使分布变尖，top_p几乎失去作用，因为第一名自己就接近 1。

Qwen3.5-4B-3D-Coder 的默认值写在 generation_config.json 里：

{ "do_sample": true, "temperature": 0.6, "top_k": 20, "top_p": 0.95, "repetition_penalty": 1.0, "use_cache": true }

注意这里的top_k是 20，正好落在 README 区间的最下端。这不是巧合：在top_k=20的前提下，top_p=0.95基本是个空转的保险丝。top-k 截断并重归一化之后，20 个候选的累积和已经是 1.0，top-p 只需要丢掉最末一两个极小概率项；只有当top_k被放大到 40 以上、或者温度拉到使尾部明显变厚时，top_p才真正开始干活。

于是"抄作业"最常见的翻车姿势出现了：有人为了"更有创意"，把top_k改成 100、top_p保留 0.95、温度固定 0.6——他以为自己在放大核采样，实际上是把候选池从 20 扩到 100，再由 top-p 决定砍到多少。Three.js 的 API 名字长且相似（MeshStandardMaterial、MeshPhysicalMaterial、MeshLambertMaterial共享前缀），候选池一放大，尾部里那些"形似但不存在"的变体就开始有概率被抽中，代码能运行到材质赋值那一行才爆ReferenceError。

repetition_penalty必须是 1.0，因为代码天然重复

README 和 generation_config.json 都把重复惩罚锁死在1.0（等于关闭）。这个选择在自然语言里显得保守，在代码里却是硬约束：new THREE.、scene.add(、const geometry这类 token 序列在单文件里出现几十上百次是正常结构，一旦开启 1.05 以上的惩罚，模型在生成到文件后半段时会被迫"换个说法"，症状就是变量名被替换成近似但不一致的拼写——而 README.md 的 Known issues 一节写得很清楚：目前观察到的 Bug"generally involved duplicate variable names, rather than major structural problems"。

重复变量名不是采样温度高导致的"质量下降"，而是对代码施加自然语言式惩罚的直接后果。 所以第一条边界是：温度与核采样可以调，repetition_penalty不能动。

量化档位应该反向收窄区间

README 明确说明 Q4_K_M 与 Q8_0"生成参数相同"，但这是为了减少使用者的心智负担，不代表两个权重的输出分布一致。量化噪声在经验上会抬高低概率尾部，因此同样的T=0.8 / top_k=40，Q4_K_M 抽到长尾异常 token 的机会高于 Q8_0。两者体积差得很实在：LFS 指针显示 Q4_K_M 为 2,708,804,096 字节（2.52 GiB），Q8_0 为 4,482,402,816 字节（4.17 GiB）。工程上的稳妥做法是让 Q4_K_M 贴区间下端（0.6 / 20 / 0.90），Q8_0 才有资格往上放（0.7–0.8 / 30–40 / 0.95）。这条属于推导而非实测结论，第五节的脚本可以让你在自己的提示词上验证它。

二、越界后的症状图谱

把社区反馈和仓库源码对照之后，能整理出一张"症状 → 真实成因"的对照表。这张表的价值在于：四类症状里只有一类真的该调参数。

第三、四行值得展开，因为它们最容易被误判成采样问题

模板层面，chat_template.jinja 在生成提示段的逻辑是：

{%- if add_generation_prompt %} {{- '<|im_start|>assistant\n' }} {%- if enable_thinking is defined and enable_thinking is false %} {{- '<think>\n\n</think>\n\n' }} {%- else %} {{- '<think>\n' }} {%- endif %} {%- endif %}

也就是说，不显式关闭思维链，模型默认先写推理再写代码。对于动辄几千 token 的自包含 HTML，推理段会把生成长度预算吃掉一大截；如果max_new_tokens卡在 4096，正文写到一半被截断，用户看到的是"后半段没了"，很自然地归罪于温度太高导致模型"发散"。实际上温度和截断之间没有因果关系。

MTP 这一条更值得说，因为它可以在源码层面被证实。config.json 的text_config里确实声明了 MTP：

"mtp_num_hidden_layers": 1, "mtp_use_dedicated_embeddings": false

但打开 model.safetensors.index.json 清点 723 个张量，只有model.language_model.*（426 个，含 32 层）和model.visual.*（297 个），没有任何mtp前缀的权重。配置声明了推测解码头，权重里却没有这个头——推理框架若按配置去启用多 token 预测，拿不到对应参数，输出自然崩坏。这解释了为什么"反复调整 Temperature、Top P 完全无效"：出问题的层级根本不在采样器。

核对这条只需要一行脚本：

python - <<'PY' import json w = json.load(open("model.safetensors.index.json"))["weight_map"] print(sum(k.startswith("model.language_model.") for k in w), sum(k.startswith("model.visual.") for k in w), sum("mtp" in k.lower() for k in w)) PY # 426 297 0

另外，generation_config.json 里eos_token_id是数组[248046, 248044]，对应<|im_end|>与<|endoftext|>；tokenizer_config.json 的eos_token是<|im_end|>。如果你的前端只按</html>或\n\n做停止串，模型在<|im_end|>之后还可能继续吐内容，或者反过来在自然位置被强停。停止条件属于"参数"的一部分，但它和温度无关。

检查点在变，参数没变

README.md 记录了 10 月 27 日检查点更新：Q4_K_M 与 Q8_0 都换成了新权重，"one-shot success has improved substantially"，而生成参数"remain unchanged"。同一套参数在不同检查点上的表现会漂移，这是判断"翻车是不是参数的锅"的重要参照——如果换了检查点症状就消失，那说明它本来就不是采样边界问题。

三、分题材的取值表

下面这张表以 README.md 给出的矩形区间为硬边界，按仓库画廊中十件作品的几何特征做区间内定位。它不是基准测试结果，而是"该题材对 token 级不确定性的敏感度"推导出来的起点；每一条都应该用第五节的脚本在自己的提示词上复核。

两张图恰好代表了这个表的两端。园林类作品依赖大量随机分布参数，温度压到 0.6 会让树形、石组、水面波纹都趋向同一种"安全构图"，重复运行十次得到同一个园子：

而机械类作品相反。LGA 3647 插槽的针脚阵列是纯计数与阵列规律问题，任何一个坐标偏移都会让整体观感崩塌，这里需要的是确定性而不是想象力：

一个容易被忽略的取舍：把温度降到 0.6 以下（比如 0.3）在语法层面通常更"安全"，但对 4B 模型来说会显著削弱思维链的探索能力，模型倾向于复用最熟悉的模板代码——表现是十个不同提示词生成出结构雷同的场景。官方把下限卡在 0.6，大概率就是这个平衡点的产物，不建议继续下探。

四、固定随机种子不等于可复现

"我 seed 都固定了，为什么两次结果不一样"是这个模型被问得最多的问题之一。固定种子只固定了随机数流，没有固定产生 logits 的那条路径。四个变量里任何一个变化，采样轨迹就会在某个 token 处分叉，而采样是自回归的——分叉一次，后面全不同。

实践上要区分两种"可复现"：

• 工程可复现：同一台机器、同一份 GGUF、同一后端、同一提示词模板、--seed固定，输出逐字节一致。这是可以做回归测试的级别。
• 语义可复现：换后端、换量化后场景结构大体一致，但坐标与颜色不同。这是跨环境迁移时能期待的上限。

会踩坑的地方在于把这两者混为一谈：有人用 Q4_K_M 调出一版满意的场景，把 seed 和参数交给用 Q8_0 的同事复现，结果不一样，于是怀疑参数抄错了。实际上权重换了，logits 就换了。

五、一份可执行的参数体检清单

5.1 Transformers 侧：显式关闭思维链，固定种子，保留 scores

import torch from transformers import AutoProcessor, AutoModelForImageTextToText repo = "ccore/Qwen3.5-4B-3D-Coder" processor = AutoProcessor.from_pretrained(repo) model = AutoModelForImageTextToText.from_pretrained( repo, dtype=torch.float16, device_map="cuda" ) # 若本地 transformers 未注册该 Auto 类，可改为 # from transformers import Qwen3_5ForConditionalGeneration # 与 config.json 的 architectures 字段保持一致 SYSTEM_PROMPT = """Use only the Three.js core ES module from https://cdnjs.cloudflare.com/ajax/libs/three.js/0.160.0/three.module.min.js. Do not import addons or legacy examples/js paths; implement any camera controls directly inside the HTML.""" messages = [ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": "Please create one self-contained HTML file with Three.js from cdnjs showing a canal lock and weir complex with a central island."}, ] text = processor.apply_chat_template( messages, tokenize=False, add_generation_prompt=True, enable_thinking=False, # 关键：不关闭会白烧一大段预算 ) inputs = processor(text=text, return_tensors="pt").to(model.device) torch.manual_seed(20261029) out = model.generate( **inputs, do_sample=True, temperature=0.6, top_k=20, top_p=0.95, repetition_penalty=1.0, use_cache=True, max_new_tokens=8192, output_scores=True, return_dict_in_generate=True, ) new_tokens = out.sequences[0, inputs["input_ids"].shape[1]:] print(processor.decode(new_tokens, skip_special_tokens=True))

5.2 量一下你的top_k和top_p到底谁在生效

output_scores=True拿到的是 warper 之前的原始 logits，所以可以离线重放温度、top-k、top-p 三步，看清实际候选集规模：

T, K, P = 0.6, 20, 0.95 for i, s in enumerate(out.scores): p = torch.softmax(s[0].float() / T, dim=-1) top = torch.topk(p, K) kept = top.values / top.values.sum() # top-k 截断后重归一化 n_p = int((kept.cumsum(0) < P).sum().item()) + 1 if i < 3 or i % 200 == 0: print(f"step {i:5d} top{K}原始质量={top.values.sum():.3f} " f"top_p实际保留={n_p}/{K}")

判读方法很直接：

• top{K}原始质量接近 1.0 → top-k 截掉的几乎都是垃圾 token，说明当前温度下top_k是主要约束。
• top{K}原始质量明显低于 1.0 → 大量概率质量被 top-k 硬砍，模型被强行限制在 20 个候选里，容易陷入模板化。
• top_p实际保留长期等于K→ top-p 完全没生效，你调它不会有任何变化。

这三行输出比任何参数表都更能说明问题：它告诉你在你的提示词、你的量化版本上，哪个旋钮是真的在动。

5.3 llama.cpp / LM Studio 侧

llama-cli -m Qwen3.5-4B-3D-Coder-Q8_0.gguf \ --temp 0.6 --top-k 20 --top-p 0.95 --repeat-penalty 1.0 \ --seed 20261029 -c 16384 -n 8192

两点必须在命令行之外确认：

1. 不要启用推测解码/多 token 预测。理由在第二节：权重里没有 MTP 头。LM Studio 需要在高级设置中手动关闭，它默认是开的。
2. 显式给-c。 config.json 里max_position_embeddings是 262144，但这不代表你的运行时会给这么多；上下文不足时表现为 HTML 尾部缺失，和采样参数无关。该模型 32 层中只有 8 层是full_attention（每 4 层一个），其余 24 层是linear_attention，长上下文成本比同规模全注意力模型低，但依然不是免费的。

5.4 收尾检查

生成完成后按这个顺序核对，比反复试温度高效：

1. 文件是否以 <!DOCTYPE html> 或 <html 开头？ -> 否则检查 <think> 是否被剥离 2. 是否以 </html> 结尾？ -> 否则检查 max_new_tokens / -c 3. 是否存在同名 const/let 重复声明？ -> 否则检查 repetition_penalty 是否被改动 4. 是否出现 THREE.MeshXxx 形式的不存在 API？ -> 否则下调 top_k 5. 是否十次运行结构高度雷同？ -> 否则上调 temperature

这五条把第二节的症状图谱变成了可执行的判定流程，也把参数调整的边界钉在了正确的位置上：参数只管"分布有多宽"，不管"模板对不对、权重全不全、预算够不够"。

回到标题那句话。官方那张表之所以能用，是因为它是在repetition_penalty=1.0、top_k=20、思维链开启、MTP 关闭这四个隐藏前提同时成立时才成立的。抄数字的时候把这四个前提一起抄走，参数区间才是区间；只抄数字，区间就变成了碰运气。

【免费下载链接】Qwen3.5-4B-3D-Coder项目地址: https://ai.gitcode.com/hf_mirrors/ccore/Qwen3.5-4B-3D-Coder