27B Qwen推理模型调优：思考预算、档位与死循环治理

27B 量级的推理模型一旦打开思考模式，最容易被吐槽的不是能力不行，而是话太多。同一道题，非思考模式两三百 token 就能给结论，思考模式能给你铺两千 token 的推理链，然后在中途开始自我怀疑、反复验证同一件事，最后要么超时，要么输出被max_tokens截断成半句话。更麻烦的是，很多人的第一反应是“那把思考关掉”，结果发现一关就掉能力，数学题算错、代码逻辑漏边界、多步任务直接跳过中间环节。

这篇文章讨论的就是这个问题：在一个 27B 量级的 Qwen 系推理模型上，用什么“剂量”能让它想得少一点、不死循环、能力不掉，同时还能把最高档的推理（下称 XH 档）留着当兜底。需要先说明一点，文中讨论的对象是 27B 量级的 Qwen 系推理模型，不同发布批次的版本号、chat template 细节、tokenizer 配置会有差异，下面的所有参数和模板写法，都要以你本地权重里的tokenizer_config.json、generation_config.json为准，不要照抄硬套。

本文会覆盖六件事：一是把“想得少”拆成三种不同的实现路径并说明哪种会掉能力；二是给出 27B 量级的显存估算与部署方式；三是把推理档位做成可配置参数；四是四组剂量实验的具体调法和验证标准；五是死循环的五种典型形态与处置；六是接口调用、批量任务、资源观察和排查清单。适合已经在本地跑过推理模型、现在卡在“太慢太啰嗦”这一步的读者。

1. 核心能力速览：27B 推理模型的“剂量”维度

先把讨论对象的能力边界列清楚。这里说的“剂量”不是一个玄学概念，它对应四个可以量化的旋钮：思考预算（允许多少 token 花在思考上）、采样温度与截断、重复抑制强度、停止条件与解析方式。这四个旋钮组合起来，才决定模型是“想得少但想得准”，还是“想得少所以想歪”。

这张表里最需要强调的是“硬件门槛”那一行。27B 参数的权重大小是可以算出来的：BF16 每参数 2 字节，权重约 54GB；FP8 或 INT8 每参数 1 字节，约 27GB；INT4 每参数 0.5 字节，约 14GB 到 15GB。这些只是权重，不含 KV cache 和框架自身的显存开销，实际落地时还要往上加。所以 24G 卡跑 INT4 是可行的，但上下文拉到 32k、并发开到 4 路以上，就很容易 OOM。这个估算是按参数量推算的理论值，真实占用必须用nvidia-smi实测。

另外一个容易被忽略的点是：27B 这个规模本身就处在一个尴尬区间。它比 7B、8B 明显更“会想”，但也更容易“想过头”。小模型的思考链通常短，因为它没那么多可说的；27B 有足够的世界知识和推理模式储备，一旦给了充足的思考预算，它会倾向于把所有可能性都过一遍。这就是为什么“剂量”问题在这个规模上特别突出，在 8B 上你几乎不用管，在 27B 上你必须管。

1.1 三种“想得少”，只有一种不掉能力

很多人把“让模型少想”理解成一件事，实际上至少有三种做法，效果差别巨大。

第一种是硬截断：把max_tokens调小，或者到了预算直接掐断。这种做法最省事，但代价明确——思考链没走完就被切断，模型还没来得及把结论写出来，输出就停在半句话上。你看到的现象是回答突然断掉、JSON 不闭合、代码少个右括号。更隐蔽的问题是在流式场景下，前端拿到的是不完整内容，用户以为模型“答错了”，其实是没答完。硬截断不掉的是模型的原始能力，掉的是可用性。

第二种是提示词引导：在 system prompt 里写“请简洁作答”“请用不超过五步完成推理”“不要反复验证”。这种做法成本最低，但稳定性最差。模型对这类指令的服从度，和问题难度强相关——简单题它听话，难题它该想多久还是想多久，甚至会因为“被要求简洁”而跳过必要的验证步骤，导致正确率下降。这是真正会掉能力的一类，因为它改变的是推理过程本身，而不是推理长度。

第三种是预算式控制：给模型一个明确的思考预算，在预算内正常思考，接近预算时由模板或框架注入收尾信号，强制它把已有推理整理成结论。这种做法不改变推理质量，只改变推理的“收口方式”，是三者里唯一能做到“想得少但能力不掉”的路径。XH 档的价值也在这里——它不是让你天天用，而是当预算式控制在某道题上失效时，你有地方退回去。

后面的实验部分，主要围绕第三种展开，前两种作为对照。

2. 使用边界与场景匹配

这套调参方法不是万能的，先说清楚它适合谁、不适合谁。

适合的场景有三类。第一类是交互式本地部署，用户等不了三十秒，模型必须在几秒内开始输出有意义的内容，这时候缩短思考链是刚需。第二类是批量任务，比如几千条工单分类、几百份文档抽取、大批量代码审查，单条多花两千 token，整体成本会被放大几十倍，这时候预算控制的收益非常直接。第三类是成本敏感的长链推理，你需要模型做多步推理，但不需要它把每一步都复述一遍，只要结论和关键中间结果。

不适合的场景也很明确。形式化证明、复杂算法推导、需要严格自洽的长链条数学题，这类任务上思考链长度和正确率是正相关的，你压预算就是在压正确率，这时候应该老老实实开 XH 档，把钱花在该花的地方。另外，需要完整推理过程做审计的场景（比如某些合规审查、教学演示），思考链本身就是交付物，压缩它等于删掉了交付内容。

还有一类特殊情况：多轮对话中的追问。很多人在多轮场景下发现模型越聊越啰嗦，原因是历史消息里堆积了大量上一轮的思考内容。如果你的框架把reasoning_content也塞回上下文，模型会倾向于模仿自己之前的啰嗦风格。这个问题的解法不是调参，而是把历史轮次的思考内容从上下文里剥掉，只保留最终回答。这一点后面在接口章节会给出具体处理方式。

合规边界方面需要提醒几句。27B 量级的模型本地部署后，输入的数据不出本机，这是优势，但也意味着数据处理的责任完全在你这边。批量处理用户提交的文本、图片、代码时，要确认你有处理这些数据的授权；模型生成的内容对外发布前要人工复核，尤其是涉及事实陈述、法律、医疗、金融建议的部分。权重的使用范围以权重附带的 LICENSE 为准，商用前务必核对清楚，不要凭印象判断。

3. 环境准备与显存估算

3.1 软件栈与版本检查

推理框架的版本差异会直接影响参数名。vLLM 的 reasoning parser 在不同版本里名字不同，早期版本用deepseek_r1，较新版本才有专门的 Qwen 系解析器；llama.cpp 的--jinja参数在旧版本里不存在。所以第一步不是装环境，是确认你手上的框架版本支持哪些参数。

# 环境自检，先把底账摸清楚 nvidia-smi python -c "import torch; print(torch.__version__, torch.version.cuda, torch.cuda.is_available())" python -c "import vllm; print('vllm', vllm.__version__)" ./llama-server --version

这三条命令分别回答三个问题：显卡和驱动是否正常、PyTorch 能不能看到 CUDA、推理框架版本是多少。如果torch.cuda.is_available()返回 False，先别往下走，驱动和 CUDA 版本不匹配的问题在容器环境里特别常见，尤其是宿主机驱动版本低于容器内 CUDA 要求的情况。

磁盘空间也要提前算。27B 的 BF16 权重约 54GB，加上 tokenizer、配置文件、可能的多分片，实际下载量在 55GB 上下；如果同时保留一份 INT4 量化权重做对比，再占 15GB 左右。建议把权重、输入素材、输出结果分成三个目录，不要全堆在项目根目录下，后面做批量任务时目录结构清晰能省很多事。

3.2 显存档位与显卡匹配

这张表里的数字都是按参数量乘字节数推算的理论值，不含 KV cache。KV cache 的占用和层数、注意力头数、上下文长度、并发数都相关，27B 量级在 32k 上下文、单条序列的情况下，KV cache 可能是几 GB 的量级；并发开到 8 路，这部分会成倍增长。所以“24G 能跑 INT4”这句话要加限定条件：短上下文、低并发、可以跑；长上下文、高并发，大概率 OOM。

一个实用的判断方法是先按最保守的配置起服务，跑通之后再逐步加并发和上下文，每次加完用nvidia-smi -l 1持续观察，找到显存占用稳定在 90% 以下的那个配置点，把它记为你的“安全档”。这个安全档比任何理论估算都可靠。

4. 部署启动与档位参数化

4.1 vLLM 起服务：把解析器配对

# vLLM 启动示例，路径、端口、解析器名称需按实际版本调整 python -m vllm.entrypoints.openai.api_server \ --model /models/qwen-reasoning-27b \ --served-model-name qwen-27b \ --dtype bfloat16 \ --max-model-len 32768 \ --gpu-memory-utilization 0.90 \ --max-num-seqs 4 \ --reasoning-parser qwen3 \ --host 127.0.0.1 \ --port 8000

几个参数值得说。--reasoning-parser是让框架把思考内容和最终回答分开的关键，配对成功之后，返回体里会多出一个reasoning_content字段，正文在content里。这个分离很重要，因为批量任务里你通常只想要content，思考内容留着做调试但不进下游。如果这个参数名在你用的版本里报错，去看该版本的文档，换用对应的解析器名字，不要硬猜。

--gpu-memory-utilization 0.90是给框架的显存上限，不是实际占用。设太高容易和其他进程抢显存，设太低会浪费。--max-num-seqs 4控制并发序列数，这个值直接决定 KV cache 的峰值占用，是 24G 卡上调优的第一优先级参数。

4.2 llama.cpp / Ollama：量化路线

# llama.cpp 启动示例，GGUF 文件名和量化等级按实际权重替换 ./llama-server \ -m /models/qwen-27b-q4_k_m.gguf \ -c 32768 \ -ngl 99 \ --jinja \ --host 127.0.0.1 \ --port 8080 \ --temp 0.6 \ --top-p 0.95 \ --min-p 0.0 \ --repeat-penalty 1.05

--jinja是必须的，没有它 chat template 不会生效，思考开关也就无从谈起。-ngl 99表示尽量把所有层都放到 GPU 上，显存不够时框架会自动回退部分层到 CPU，这时候你会看到速度断崖式下降，所以看到 token/s 突然掉到个位数，第一反应应该是查-ngl和显存，而不是怀疑模型。

Ollama 路线适合想要“一条命令起服务”的场景，用一个 Modelfile 把参数固定下来：

FROM /models/qwen-27b-q4_k_m.gguf PARAMETER num_ctx 32768 PARAMETER temperature 0.6 PARAMETER top_p 0.95 PARAMETER top_k 20 PARAMETER min_p 0.0 PARAMETER repeat_penalty 1.05 PARAMETER stop "<|im_end|>"

num_ctx是上下文长度，这个值设大了会直接吃掉显存，设小了会导致长文档被静默截断——注意是静默，不会报错，你只会发现模型“没看到”文档后半部分。这是排查长文档任务时最容易被漏掉的一项。

4.3 把档位做成配置

档位不要散落在代码各处，做成一份配置，用的时候只改档位名：

{ "levels": { "L": { "enable_thinking": false, "budget": 0, "temperature": 0.7, "top_p": 0.8, "top_k": 20 }, "M": { "enable_thinking": true, "budget": 1024, "temperature": 0.6, "top_p": 0.95, "top_k": 20 }, "H": { "enable_thinking": true, "budget": 4096, "temperature": 0.6, "top_p": 0.95, "top_k": 20 }, "XH": { "enable_thinking": true, "budget": 16384, "temperature": 0.6, "top_p": 0.95, "top_k": 20 } }, "default": "M" }

这里的 L / M / H / XH 是本文自定义的档位命名，对应非思考、短预算、中预算、高预算四档，你完全可以在自己的系统里换成reasoning_effort之类的字段名。关键是四个档位的采样参数要保持一致，只让预算变化。原因很简单：如果预算和温度一起变，你无法判断效果差异是预算带来的还是采样带来的，实验就没法归因。

档位切换的默认策略建议是：日常问答走 M，代码和抽取类任务走 H，遇到 M 和 H 都答错的题才升到 XH，L 档只用于明确的简单任务，比如改写、翻译、格式转换。这个策略的核心是“按需升级”，而不是“默认最高”。

5. 四组剂量实验与效果验证

这一节是核心。四组实验分别对应四个旋钮，每组都要有明确的验证方法和失败判据，不能只看“感觉好点了”。

5.1 剂量一：思考预算的边界在哪

实验目的：找到“能力开始下降”的预算临界点。

做法：准备一组固定题目，覆盖四类任务——单步事实问答、多步数学计算、代码改写、需要跨段信息整合的长文档问答。每类各准备 10 到 20 道，答案可判定。然后用 M、H、XH 三档分别跑一遍，记录每档的正确率、平均思考 token 数、平均总耗时。

判断标准不是“正确率越高越好”，而是找正确率曲线的拐点。正常情况下，从 M 升到 H 会有明显提升，从 H 升到 XH 提升会变小甚至持平，同时耗时继续上升。如果某个任务类型在 M 档就已经达到 H 档的正确率，那这类任务就固定用 M，省下的预算是纯收益。反过来，如果某类任务在 M 档正确率明显掉，说明它的推理深度需求超过了 M 的预算，应该抬到 H。

失败判据要单独看：如果出现“思考 token 数已经接近预算上限，但content为空或极短”，说明模型没能在预算内收口，这是预算给少了，不是模型不行。这类样本要单独统计比例，比例超过两成就说明这一档的预算设置不合理。

5.2 剂量二：温度与截断的配合

实验目的：确认采样设置是否在放大啰嗦和重复。

推理模型对温度比通用模型更敏感。温度压到 0，贪心解码会出现“确定性重复”——模型在同一个思路上来回走，因为每次选到的都是同一个 token。温度开太高，思考链会发散，出现“想到一半跑题”的情况。经验区间通常在 0.5 到 0.7 之间，配合 top_p 0.9 到 0.95。

min_p 这个参数值得单独提。它按概率相对最高 token 的比例截断，比 top_p 更能抑制低概率噪声，而且不会像 top_p 那样在分布平坦时放进太多候选。对于思考链这种长序列生成，min_p 设一个小的正值（比如 0.02 到 0.05）往往能让推理更“收得住”，但设太高会导致用词单一、句式重复。这需要在你自己的题目集上试。

import requests, json LEVELS = { "M": {"budget": 1024, "temperature": 0.6, "top_p": 0.95, "min_p": 0.02}, "H": {"budget": 4096, "temperature": 0.6, "top_p": 0.95, "min_p": 0.02}, } def ask(question, level="M", base_url="http://127.0.0.1:8000/v1"): cfg = LEVELS[level] payload = { "model": "qwen-27b", "messages": [{"role": "user", "content": question}], "temperature": cfg["temperature"], "top_p": cfg["top_p"], "max_tokens": cfg["budget"], "chat_template_kwargs": {"enable_thinking": True}, } r = requests.post(f"{base_url}/chat/completions", json=payload, timeout=300) r.raise_for_status() data = r.json()["choices"][0]["message"] return { "reasoning": data.get("reasoning_content", ""), "answer": data.get("content", ""), }

这段代码里chat_template_kwargs的字段名和reasoning_content的返回位置，不同框架版本会有差异，跑之前先用一条最简单的请求打印完整返回体确认结构，不要直接批量跑。

5.3 剂量三：重复抑制的强度

这一组最容易踩坑。很多模型卡明确不建议开启频率惩罚和存在惩罚，原因是这类惩罚对思考链的破坏远大于对正文的改善——它会把“必要的重复”也惩罚掉，比如数学推导里反复出现的符号、代码里重复的变量名，模型为了避开惩罚会换成同义词，导致推理不严谨。

比较稳妥的做法是把重复抑制压到很低甚至关闭，靠温度和 min_p 来控制重复，只在确实出现病态重复时才小幅开启。开启时建议从 1.03 到 1.05 这个区间起步，观察是否有改善，如果没有改善反而变差，直接关掉。判断“病态重复”的标准很具体：同一段话在思考链里出现三次以上，或者同一个验证动作反复执行。

5.4 剂量四：停止条件与收口

这一组决定“想得少”能不能真正落地。预算式控制的关键是让模型在接近预算时主动收口，而不是被硬切断。实现方式有几种，可以叠加使用。

第一种是在提示词末尾加收口指令，比如“请在推理结束时用『结论：』开头给出最终答案”。这个做法利用了模型对格式的敏感性，它在看到这个约定后，会倾向于在推理后期主动转入结论段。第二种是在模板层面注入预算提示，部分 chat template 支持把剩余预算写进系统提示，模型能感知到“时间不多了”。第三种是后处理兜底：检测到content为空但reasoning_content有内容时，从思考链末尾提取结论段作为答案，同时打上标记，方便后续人工复核。

下面这段是批量跑完之后做归因统计的脚本，把每条结果分成四类，方便你判断问题出在哪个旋钮上：

def classify(item, budget): reasoning = item.get("reasoning") or "" answer = (item.get("answer") or "").strip() if not answer and reasoning: return "unclosed" # 思考了但没给结论，预算或收口问题 if len(answer) < 10 and reasoning: return "thin_answer" # 结论过短，可能被截断 if reasoning.count("重新检查") >= 3 or reasoning.count("wait") >= 3: return "loop_suspect" # 疑似死循环 if not reasoning: return "no_thinking" # 思考开关没生效 return "ok"

这个分类函数里的关键词是启发式的，你需要按自己模型的表达习惯调整。它的价值不在于精确，而在于让你批量跑完之后能一眼看出“两千条里有多少条属于哪类问题”，而不是靠抽样几条凭感觉判断。

6. 死循环归因与处置

死循环是这类模型最典型的故障形态，但“死循环”其实是一个笼统说法，背后至少有五种不同成因，处置方式完全不同。混在一起调参，往往越调越乱。

第一种“确定性重复”最好判断，把温度从 0 调到 0.6 重跑同一题，如果重复消失，就是它。第二种“语义打转”最容易被误判成模型能力问题，实际上它的信号是“思考 token 数很充足但始终不转入结论”，本质是缺少收口约束，处置方式是加格式约定而不是降预算。第三种“格式崩溃”在低比特量化上出现频率明显更高，尤其是 Q3 及以下等级，如果你在 Q4 上正常、Q3 上崩溃，那基本可以确定是量化损失，别在参数上浪费时间。

第四种“截断假死”在流式接口下特别有迷惑性，前端看起来像卡住了，实际上服务端已经返回结束。检查方法是看finish_reason字段，如果是length，说明是max_tokens命中；如果没有停止符配置，模型可能会一直生成到上限。第五种“上下文污染”在多轮场景下最常见，处置方式是在构造历史消息时只保留content，把reasoning_content丢掉。这一条对长对话的稳定性影响非常大，值得单独写进你的请求封装里。

def build_history(records): """构造多轮历史时剥离思考内容，避免模型模仿自己的啰嗦风格""" messages = [] for r in records: messages.append({"role": "user", "content": r["question"]}) messages.append({"role": "assistant", "content": r["answer"]}) # 只保留正文 return messages

这段逻辑看着简单，但它是很多“越聊越啰嗦”问题的真正解法。调参调半天不如把历史里的思考内容清掉。

7. 接口 API 与批量任务

7.1 接口调用示例

# OpenAI 兼容接口调用，模型名、端口按实际服务替换 curl http://127.0.0.1:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen-27b", "messages": [ {"role": "system", "content": "回答简洁，推理结束用『结论：』开头给出最终答案。"}, {"role": "user", "content": "把下面这段 SQL 改成等价的窗口函数写法：..."} ], "temperature": 0.6, "top_p": 0.95, "max_tokens": 2048, "chat_template_kwargs": {"enable_thinking": true} }'

chat_template_kwargs这个字段能不能用，取决于你的框架版本是否把模板变量透传出来。如果不支持，替代方案是在消息内容里加软开关标记，比如在用户消息末尾追加/think或/no_think这类约定标记，前提是你的 chat template 里处理了这些标记。这一点必须看你本地模板的实际内容，不要凭网上的写法硬套。

7.2 批量任务设计

批量任务的核心不是“把请求循环发出去”，而是三条：并发控制、失败重试、结果落盘。

import json, time, requests from concurrent.futures import ThreadPoolExecutor def run_one(task, base_url, retries=2): for attempt in range(retries + 1): try: payload = { "model": "qwen-27b", "messages": [{"role": "user", "content": task["prompt"]}], "temperature": 0.6, "top_p": 0.95, "max_tokens": task.get("budget", 2048), "chat_template_kwargs": {"enable_thinking": True}, } r = requests.post(f"{base_url}/chat/completions", json=payload, timeout=300) r.raise_for_status() msg = r.json()["choices"][0]["message"] return { "id": task["id"], "status": "ok", "answer": msg.get("content", ""), "reasoning_len": len(msg.get("reasoning_content", "") or ""), "attempt": attempt, } except Exception as e: if attempt == retries: return {"id": task["id"], "status": "failed", "error": str(e), "attempt": attempt} time.sleep(2 ** attempt) # 指数退避 def run_batch(tasks, base_url="http://127.0.0.1:8000/v1", workers=2): results = [] with ThreadPoolExecutor(max_workers=workers) as pool: for res in pool.map(lambda t: run_one(t, base_url), tasks): results.append(res) with open("results.jsonl", "w", encoding="utf-8") as f: for r in results: f.write(json.dumps(r, ensure_ascii=False) + "\n") return results

三个细节值得强调。workers不要设大，本地单卡部署时并发数超过--max-num-seqs只会让请求排队，还容易因为 KV cache 打满触发 OOM，从 2 开始试比较稳。重试要做指数退避，服务刚启动或显存紧张时前面的失败往往是瞬时的，立刻重试大概率还是失败。结果必须写 JSONL 而不是等到最后一次性 dump，批量跑几千条的时候，中途崩一次全丢是很难受的。

日志字段里建议保留reasoning_len，它是判断“这一档预算够不够”的最直接指标。批量跑完之后按这个字段做分布统计，如果大量样本的思考长度贴着预算上限，说明这一档普遍不够，需要整体上调。

8. 资源占用、性能观察与排查

8.1 怎么观察

观察显存最直接的是nvidia-smi -l 1，但要注意区分“启动后静态占用”和“跑起来之后的峰值占用”。静态占用只能说明权重加载成功，峰值占用才决定你会不会 OOM。

# 持续观察显存与利用率，跑批量任务时开着 nvidia-smi --query-gpu=timestamp,memory.used,memory.total,utilization.gpu \ --format=csv -l 1

除了显存，还要看两个指标：首 token 延迟和输出速度。首 token 延迟反映的是 prefill 阶段的效率，长文档场景下这个值会明显变长；输出速度反映的是 decode 阶段的效率，受并发数影响很大。这两个指标要分开看，混在一起谈“快慢”没有意义。

8.2 影响性能的几个因素

上下文长度对显存和速度都是非线性影响，32k 上下文和 8k 上下文不是四倍关系，注意力计算的复杂度更高。分辨率、步数这类参数在图像模型上是主要变量，在文本模型上对应的是批量大小和序列长度。

并发数是最容易被低估的变量。单条请求跑得飞快，并发开到 8 就卡住，这不是模型的问题，是 KV cache 打满之后框架在做调度。判断方法是看 GPU 利用率：如果显存满了但利用率不高，说明在等调度；如果两个都高，说明真的算不过来，该降并发或换更小的量化。

降低显存的手段按性价比排序：降并发、降上下文、换更低比特量化、开 KV cache 量化。前两个不损失精度，第三个会损失精度，第四个在长上下文下可能有精度影响。顺序不要搞反，先降不损失精度的，再考虑量化。

8.3 常见问题排查表

这张表里的每一条都是实际会遇到的高频问题，排查顺序建议从“服务是否活着”开始，再往“参数是否被支持”“资源是否够”“输出是否正确”逐层往下。很多看起来像模型质量问题的现象，实际上是配置问题——先排除配置，再怀疑模型。

9. 最佳实践与落地建议

把上面这些收敛成几条可以直接用的做法。

第一，先建最小可运行配置，再做实验。最小配置指：一个能起服务的启动命令、一条能跑通的 curl、一个能写盘的批量脚本。这三样齐了再调参，否则你每次改参数都要重新排查环境问题，实验效率极低。

第二，档位默认走中间档，按需升级。M 档覆盖大部分任务，H 档处理代码和抽取，XH 档只用来兜底那些 M 和 H 都答错的题。把 XH 当默认是典型的资源浪费，而且会让批量任务的耗时不可控。

第三，四组剂量一次只动一个。预算、采样、重复抑制、停止条件，任意两组同时改，你就无法归因。这个原则听起来简单，执行起来很容易破功，尤其是调到最后着急的时候。

第四，把思考内容和正文的分离做在封装层。不管用哪个框架，你的请求封装里应该统一处理：历史只保留正文、结果里单独存思考长度、返回体字段缺失时有兜底。这三件事做在封装层，比散落在业务代码里可靠得多。

第五，批量任务必须留日志、必须能续跑。JSONL 落盘、按 id 记录状态、失败条目单独一个文件，这样跑到一半崩了能接着跑，不用从头再来。几千条的任务重跑一次成本是很高的。

第六，量化等级不要一味求低。Q3 及以下的权重在 27B 这个规模上，思考链的稳定性下降会比较明显，尤其是长链推理任务。如果显存只够跑低比特量化，就要接受“思考链更容易崩”这个前提，把预算和收口约束设得更保守一些，而不是指望调参把损失补回来。

第七，涉及用户数据的批量任务，先确认授权范围。本地部署不等于没有合规问题，输入数据的处理授权、输出内容的复核责任、权重许可的使用范围，这三件事要在上线前确认清楚。生成内容对外发布前建议保留人工复核环节，尤其是事实性内容。

最后说一个判断标准，用来决定什么时候该停手：当你发现继续调参带来的收益，已经小于“换一个更合适的档位”带来的收益时，就该停了。27B 推理模型的能力上限是固定的，调参能做的是让它在大部分任务上“用够用少的思考拿到足够的正确率”，做不到让它变聪明。XH 档存在的意义，就是承认有些题确实需要多想，给它留一条路，而不是逼着所有题都用最短的思考链解决。把这句话记住，参数就不会越调越偏。