输出不稳时，先别急着换模式或换模型，而是把变量拆开一次只动一个：同一段输入、同一个模式，只改采样参数跑一批；再把采样参数写死，只切模式跑一批；最后按固定步长加长输入，看异常从第几段开始出现。这三步跑完，模式、采样参数、上下文长度通常能各自归因，而不是继续凭手感试配置。判断依据要落在可观察的特征上——输出长度、重复片段、结构是否完整、是否丢前文、是否提前结束，这些字段在日志和返回体里都能直接看到。
先做参数对照，再做模式对照，最后做长度对照，是判断 Nemotron-Labs-Diffusion 输出不稳的稳妥顺序。每组只保留一个变量，其余写死在配置里；判据用可观察特征：输出长度、重复片段、结构是否完整、是否丢前文、是否提前结束。同一设置重复运行仍漂移，先怀疑采样或随机种子；只在切模式后出现，先怀疑模式差异；只在长输入下出现，先怀疑上下文截断。未复现的现象标注待验证，不要急着归因。
固定输入与模式，只改采样参数跑三组
这一步的目的不是找最优参数，而是先看采样设置对结果离散程度的影响。做法是同一提示词、同一模式，只改 temperature/top_p 一类字段，每组重复几次，观察组内差异。字段名以你所用 SDK 为准，下面是通用骨架，替换成实际接口即可。
# 固定模式与提示词，只改采样设置
MODE = "your_mode" # 全程不改
PROMPT = open("case.txt").read() # 固定输入
COMMON = {
"mode": MODE,
"max_tokens": 512,
"seed": 12345, # 先固定种子，再决定是否放开
}
RUNS = [
{"name": "A_low", "temperature": 0.0, "top_p": 1.0},
{"name": "B_mid", "temperature": 0.7, "top_p": 0.9},
{"name": "C_high", "temperature": 1.0, "top_p": 0.95},
]
for cfg in RUNS:
for i in range(3): # 每组多跑几次，看离散程度
out = client.generate(prompt=PROMPT, **COMMON, **cfg)
log(cfg["name"], i, len(out), has_repeat(out), is_complete(out))记录时至少写四个字段：输出长度、是否出现连续重复片段、结构是否完整（标签/列表/JSON 是否闭合）、是否在未给结束条件时提前结束。如果同一组内这四项就有明显差异，说明采样参数在起作用；如果低温度那一组仍然抖动，说明随机性不是唯一来源，需要继续做后面的对照。has_repeat 和 is_complete 可以先写成简单规则，例如同一句出现两次以上判重复、JSON 无法解析判不完整。
固定采样参数，切换模式再跑三组
把采样参数冻结，只动模式字段，才能把模式因素单独分离出来。对照组设置：同一提示词、同一 max_tokens、同一种子、同一组采样参数，只改 mode。每组同样重复几次，避免把单次波动误当成模式差异。
FROZEN = {"temperature": 0.3, "top_p": 0.9, "seed": 12345, "max_tokens": 512}
for mode in ["mode_x", "mode_y", "mode_z"]:
for i in range(3):
out = client.generate(prompt=PROMPT, mode=mode, **FROZEN)
log(mode, i, len(out), has_repeat(out), is_complete(out), lost_context(out))跨模式可比的字段是：输出长度、是否重复、结构是否完整、是否丢前文、是否提前结束——这些都来自返回文本本身。不可直接横向比的是耗时、内部解码步数、计费 token 这类与实现绑定的字段，它们在不同模式下口径可能不同，只能自己和自己比。
逐步加长输入，观察上下文截断的位置
固定模式和采样参数，把输入按固定步长加长：可以每步加固定字数，也可以每步加固定段落数，两种都行，关键是步长全程不变。每步跑一次，记录从第几段开始出现丢前文、重复或提前结束。
BASE = open("case.txt").read()
for step in range(0, 4000, 500): # 每步 +500 字，步长固定
text = BASE + extra_text(step)
out = client.generate(prompt=text, mode=MODE, **FROZEN)
log(step, len(text), lost_head(out), has_repeat(out), early_stop(out))判据建议写死三条：输出里不再出现开头部分给出的关键约束或关键词，判为丢前文；同一句或同一段连续出现两次以上，判为重复；模型未输出结束标志或结构未闭合就停下，判为提前结束。找到最早出问题的那个长度后，在它前后各取一档再跑一次确认，避免把偶发波动当成临界点。
把差异归因到模式、参数或上下文三类
把上面三批记录放在一起比对，就能把现象整理成可验证的假设。归因只是暂定方向，不是结论，需要用下一步动作去证伪。
| 现象 | 最可能原因 | 下一步验证动作 |
|---|---|---|
| 同模式同参数重复跑，长度和结构差异大 | 采样参数或随机种子在起作用 | 固定种子后再跑；若仍抖，降低温度重跑同一批 |
| 只在切模式后出现重复或提前结束 | 模式本身的解码策略不同 | 在两种模式下跑同一组冻结参数，看差异是否消失 |
| 短输入稳定，加长到某段后丢前文 | 上下文被截断或有效上下文不足 | 在临界长度前后各跑一档，确认是否长度触发 |
| 结构完整但内容每次都不同 | 采样随机性主导 | 固定种子多次运行，取多次出现的一致项 |
| 换任务后同样的配置又不稳 | 当前配置只适配原任务 | 对新任务重做一次参数对照，不要直接沿用 |
暂时无法复现或只出现一次的现象，标注为“待验证”，写清当时用的模式、参数和输入长度，不要写成结论。归因表的价值在于给出下一步动作，而不是给出一个漂亮的原因。
给出可复现的稳定参数组合
基于前面的对照，先给一组偏确定性的搭配作为起点：模式选在对照中重复最稳定的那一个，采样温度取低值，固定随机种子。下面是通用占位配置，字段名按你的 SDK 替换。
{
"mode": "your_stable_mode", # 换成对照中表现最稳的模式名
"temperature": 0.3,
"top_p": 0.9,
"top_k": 40,
"seed": 12345, # 需要复现时保留，需要多样性时再放开
"max_tokens": 600,
"stop": ["\n\n\n"]
}适用范围：短到中等长度输入、需要可复现或结构完整的输出场景，例如固定格式抽取、模板化生成。尚未验证的部分要写清楚：长上下文输入下的表现、多轮对话、与其他模式混用、输入接近上下限时的行为，以及放开种子后多样性提升带来的稳定性代价。换任务前建议按第一节的顺序重跑一次参数对照，再决定是否沿用这组配置。