ChatGLM3-6B 高效 Prompt Engineering 实战：从模型调优到生产部署-编程阁

背景痛点：ChatGLM3-6B 在业务里“水土不服”的三道坎

把 ChatGLM3-6B 从 Hugging Face 拖到生产环境，就像把实验室里的盆栽直接种到戈壁：能活，但长得不好。过去三个月，我们团队踩过的坑集中在三点：

多轮对话状态漂移
用户聊过 5 轮之后，模型开始“自说自话”，把前面约定的字段名、日期格式全忘掉，导致下游 JSON 解析直接报错。
长文本理解偏差
超过 2 k Token 的工单描述，模型对“问题根因”的总结与人工标注的 ROUGE-1 只有 42%，远低于短文本的 68%。
推理延迟毛刺
在 4×A10 的推理池里，P99 延迟偶尔蹦到 18 s，追查发现是 batch 内部序列长度差异过大，导致 GPU 空转等内存碎片。

这三道坎背后，其实都指向同一个根因：Prompt 设计没有跟模型特性、业务上下文、硬件资源做“三维对齐”。下面我们把解题思路拆开聊。

技术对比：三种提示策略的“性价比”现场实测

为了把“玄学”变“工程”，我们在同一批 1 000 条线上真实对话上做了 AB 实验，控制数据、GPU、解码参数，只看 Prompt 差异。结果如下：

策略	短文本准确率	长文本准确率	平均延迟	显存峰值	备注
Zero-shot + 基础指令	0.63	0.42	1×	21 GB	baseline
Few-shot 3 例	0.71	0.55	1.1×	22 GB	例子的顺序敏感
CoT 分步推理	0.76	0.68	1.4×	23 GB	需要 400+ Token 做“思考”
System Prompt + 动态模板	0.79	0.72	1.05×	21 GB	下文详述，性价比最高

结论：

短文本场景，Few-shot 就能赚；长文本必须让模型“慢思考”，CoT 收益明显。
System Prompt 如果写得好，可以把 CoT 的“慢”压缩到 5% 以内，同时把显存峰值压住。
线上并发高时，显存比时间更贵，System Prompt 方案因此胜出。

核心实现：让 Prompt“长”在业务数据上

1. 动态模板引擎（带异常兜底）

我们用一个 60 行的 Python 类把“角色-约束-例子-输出格式”拆成四块，渲染时只填变量，不拼字符串，避免注入污染。

from jinja2 import Template, StrictUndefined import json class PromptBuilder: def __init__(self, system_role: str, rules: list, output_schema: dict): self.sys_tmpl = Template( "You are {{role}}.\nConstraints:{% for r in rules %}\n- {{r}}{% endfor %}", undefined=StrictUndefined ) self.user_tmpl = Template( "Context:\n{{context}}\n\nPlease answer in JSON: {{schema}}", undefined=StrictUndefined ) self.role = system_role self.rules = rules self.schema = json.dumps(output_schema, ensure_ascii=False) def build(self, context: str, examples: list = None) -> list: try: system = self.sys_tmpl.render(role=self.role, rules=self.rules) user = self.user_tmpl.render(context=context, schema=self.schema) msgs = [{"role": "system", "content": system}, {"role": "user", "content": user}] if examples: # 把 Few-shot 插在 system 之后、当前 user 之前 for ex in examples: msgs.append({"role": "user", "content": ex["user"]}) msgs.append({"role": "assistant", "content": ex["assistant"]}) return msgs except Exception as e: # 兜底：异常时返回最简指令，防止服务雪崩 return [{"role": "user", "content": context[:500]}]

关键参数解释：

StrictUndefined：变量没填会抛异常，避免静默出错。
context[:500]：异常时截断，防止超大文本把显存直接打爆。

2. System Prompt 设计三板斧

角色定义一句话：
“你是阿里云售后工单助手，只回答技术问题，拒绝政治、宗教话题。”
把“边界”钉死，减少幻觉。
约束条件三条以内：
- 输出必须可 JSON 解析
- 关键字段不超过 50 字
- 遇到模糊描述请反问确认
  人类好记，模型也好记。
输出格式给“活”例子：
不要只写“返回 JSON”，而是给一段真实返回值，把字段名、单位、枚举值都写全。模型一次就能对齐。

生产考量：并发、显存与批处理

1. GPU 内存管理三件套

提前预留 10% 显存做碎片缓冲：
torch.cuda.set_per_process_memory_fraction(0.9)
开启use_cache=False把 KV 缓存降到 1/3，牺牲 5% 延迟换 20% 显存。
动态 batch：按剩余显存实时算最大 batch_size，而不是固定 16 条。代码片段：

def auto_batch(req_list, max_token=2048, gpu_mem_left=None): if gpu_mem_left is None: gpu_mem_left = torch.cuda.mem_get_info()[0] / 102**3 # GB # 粗略估算 1 token ≈ 0.7 MB safe_token = int(gpu_mem_left * 1024 / 0.7) batch, cur_token = [], 0 for r in req_list: cur_token += len(r["prompt"]) if cur_token > safe_token: yield batch batch, cur_token = [r], len(r["prompt"]) else: batch.append(r) if batch: yield batch

2. vLLM 批处理配置

vLLM 的 PagedAttention 能把显存碎片压到 3% 以内，启动参数如下：

from vllm import LLM, SamplingParams llm = LLM(model="THUDM/chatglm3-6b", gpu_memory_utilization=0.9, # 与上面预留对齐 max_num_seqs=128, max_model_len=4096, dtype="half", # A10 支持 bfloat16，可改 enable_prefix_caching=True) # 多轮对话复用 KV 缓存 sampling = SamplingParams( temperature=0.3, # 低温度保证输出稳定 top_p=0.85, max_tokens=512, stop=["<|user|>", "<|observation|>"])

实测在 4×A10 上 QPS 从 8 提到 26，显存峰值反而降了 1.2 GB。

避坑指南：三个“看起来对”的错误

过度依赖单一模板
症状：业务换场景，模型突然“变傻”。
解法：把模板拆成“角色+规则+格式”三文件，上线前跑自动化回归，ROUGE<0.6 自动报警。
把 temperature 当“创造力开关”一味调高
症状：输出开始“写诗”，字段对不齐。
解法：temperature 0.2~0.4 区间做网格搜索，每 0.05 一档，用下游解析成功率当指标，而不是人工“感觉”。
忽略 Token 窗口的“软”上限
ChatGLM3-6B 官方写 8 k，实际 6.5 k 后注意力显著衰减。
解法：长文本先让 LLM 自己写“摘要占位符”，再送进主流程，把有效上下文压到 4 k 以内，准确率提升 9%。