APUS-OpenJev-v1 输出不稳定 / 是提示词问题还是量化精度掉了？

同一输入多次运行、输出差异明显时，先不要改提示词，也先别换权重文件；把“提示词写法”和“权重/量化配置”当两个独立变量，用固定输入对照法一组一组跑。实际排查中，先撞上的往往是解码采样带来的随机性（temperature、top_p、seed），其次是提示词对输出格式的约束不足，量化精度的影响通常要在同提示词、同解码参数下换权重对比才能看出来。判断顺序建议是：先确认差异具体表现，再排采样，再排提示词，最后才比权重与量化配置。

遇到 APUS-OpenJev-v1 输出不稳定，可先固定输入、权重和全部解码参数，重复跑若干次并保存输出全文与关键字段，确认差异是措辞级还是字段级；然后把 temperature 调低、seed 固定再复测，采样引起的波动一般会先消失。剩下的差异再用“只改提示词”和“只换权重/量化”两组对照分开验证。适用场景是本地或内网自建推理服务，验证边界是只能证明“在你这套配置下差异是否复现”，不能据此推断模型整体质量。

同一输入重复跑多次，记录差异的具体表现

“不稳定”这个说法太笼统，先把它拆成可记录的现象：是措辞每次不同但意思一致，是输出长度忽长忽短，还是关键字段（JSON 的键、数字、单位、结论标签）取值不同，亦或偶发截断、空输出、格式崩坏。这四类现象指向的原因并不一样，混在一起看只会越查越乱。

做法是用同一条输入连续跑多次，建议 5 到 10 次，具体次数按你手上的时间定，次数越多越容易看出是“每次都变”还是“偶尔变一次”。每次保存输出全文到独立文件，不要只凭印象记“感觉不一样”，同时记录长度和关键字段取值。下面是一个通用骨架，把请求部分换成你自己的调用方式即可：

# 目的：同一输入重复调用，逐次落盘输出，便于事后逐字段对比
# 替换项：URL、模型名、请求体、采样参数
for i in $(seq 1 8); do
  curl -s http://127.0.0.1:8000/v1/chat/completions \
    -H 'Content-Type: application/json' \
    -d '{"model":"apus-openjev-v1","messages":[{"role":"user","content":"<你的固定输入>"}],"temperature":0.7,"top_p":0.95,"max_tokens":512}' \
    > runs/run_$i.json
  wc -c runs/run_$i.json >> runs/length.log
done

记录字段至少包含：run_id、提示词版本号、权重标识、量化配置、temperature/top_p/top_k/seed、输出全文文件路径、字符或 token 长度、关键字段取值、是否截断或报错。这一步只做客观记录，不写“这次明显更好”这类主观归纳，否则后面的对照没有可比性。

固定权重与参数，只改提示词写法

确认了差异表现之后，先单独看提示词的影响。准备两个版本：A 版是当前在用的写法，B 版在原意不变的前提下补上输出格式约束、字段清单、禁止项，并给一个最小输出样例。两版提示词分别存成带版本号的文件（如 prompt_a.txt、prompt_b.txt），避免后面改着改着分不清哪版是哪版。

除提示词文本外，其余条件必须完全一致：同一个权重文件、同一份量化配置、同一组解码参数、同一个 max_tokens、同样的 system 提示、同样的请求参数。观察点建议集中在四项：格式是否稳定符合要求、关键字段是否齐全、长度分布是否收敛、之前那种偶发差异是否仍然出现。如果 B 版在同样重复次数下格式稳定而 A 版不稳，提示词因素就有了比较明确的证据；如果两版都一样飘，说明提示词不是主因，转到权重和解码参数上查。

固定提示词，切换权重或量化配置再跑一次

这一组的目的是把权重精度的影响单独拎出来。切换步骤建议这样做：第一步，记录当前权重的可识别信息（权重文件名、加载日志里打印的路径或校验和），并保存一组基线输出；第二步，把权重换成待比较的那一份，或把量化配置换成另一档，只改这一项；第三步，用完全相同的提示词文件和相同的重复次数重跑，输出落到新目录。

需要保持不变的参数清单：提示词文本及其版本号、system 提示、temperature/top_p/top_k/seed、max_tokens、停止词、请求超时、服务启动时的并发与批处理设置。特别注意服务端默认值和请求体参数可能互相覆盖，换配置时顺手确认一下实际生效的是哪一组。结果记录方式与第一组一致，仍然是全文加长度加关键字段，比较时看“同一提示词下差异是否稳定复现”，而不是比较单次输出的好坏——单次输出来自哪个权重都可能好看，这不能作为判断依据。量化档位是否真的加载成功，需要结合启动日志确认，不能只看配置文件写了什么。

检查解码参数是否引入随机性

采样参数是最容易被忽略的一项，因为它常常在请求体、服务端配置文件、模型目录里的生成配置三处同时存在，谁覆盖谁要看具体实现。查看位置一般有两类：一是服务启动时加载的配置文件（常见如 config.yaml、generation_config.json 或启动命令行里的 `--temperature` 之类参数），二是每次请求体里带的参数。先确认请求里有没有显式传采样参数，再确认服务端默认值是多少。

重点看这几个键：do_sample 是否开启、temperature 取值、top_p、top_k、repetition_penalty、seed 是否支持固定、max_new_tokens。复测方法很直接：把 temperature 调到 0 或一个很小的值，top_p 设为 1，能固定 seed 就固定，然后按原来的次数重跑。如果输出差异基本消失，波动来源基本可以归到采样；如果差异依旧明显，再回头看提示词和权重。这里要留意一点：temperature 极低时部分实现会退化成贪婪解码，输出可能变得重复或死板，这是正常现象，不要误判成量化精度下降。

把可复现差异与偶发差异分开记录

最后一件事是把前面几组结果整理成别人能复核的形式。建议的记录表字段和判定依据如下，可以整理成一个文本表或表格文件：

记录表字段：case_id | prompt_version | weights_id | quant_cfg |
            temperature | top_p | top_k | seed | repeat_n |
            output_path | length | key_fields | status

判定依据：
  可复现差异：同一组条件重复多次，差异每次都出现，或按固定规律出现
  偶发差异：重复多次中仅少数几次不同，且换时间/换机器重跑不一定重现
  尚未确认：只跑过一两次、或某次参数没记录全、或权重加载状态未确认

判定要克制：只有“同样条件下重复多次都出现”的才算可复现差异，比如换了权重后关键字段稳定取值不同、提示词 B 版稳定补齐字段；只出现一两次、或参数记录缺失的，一律标成尚未确认，不要写成结论。交给他人复核时，附上提示词文件、权重标识、生效参数的截图或日志片段、以及原始输出目录，对方才能按同样条件重跑一遍。如果复核发现差异无法重现，那它更可能是环境或采样造成的偶发现象，而不是量化精度问题。