企业官网建设流程全解析

上个月我干了一件在别人看来很无聊的事：把 DeepSeek、Qwen、GLM 三个开源模型同时部署到一台 GPU 算力平台上，给它们同一个辩题，然后让它们轮流读对方的观点、写反驳、再更新自己的立场——也就是一场完全由大模型完成的“辩论赛”。三轮跑下来，印象最深的不是谁赢了，而是单模型回答问题时那些“自己看不见”的盲区，在另一个模型的持续追问下，全都藏不住。

写这篇记录之前先说明一下：标题里提到的算力平台，正文里我不会点具体服务商名字，统一用 GPU 算力平台或云 GPU 实例来称呼。原因是这种玩法跟平台关系不大，只要你手上能租到一张显存足够的卡，整条流程都能复现。文章面向两类读者：一是想尝试多模型协作、但不知道怎么落地的人，二是单纯好奇“让 AI 互相抬杠会是什么场面”的人。

1. 为什么非要让三个模型互相抬杠：单模型回答的盲区

1.1 一个同样的问题，三个模型的答案五花八门

事情的起因是我在调一个技术方案评估任务。同一个问题——比如“未来三年，RAG 会不会被超长上下文完全取代”，我先后问了三个模型，结果很有意思：

• DeepSeek 的推理链最长，先拆“知识更新成本”和“检索延迟”两个维度，结论是 RAG 短期不会死；
• Qwen 的回答最全面，把企业知识库、私有化部署、上下文窗口三个场景都列了一遍，结论是“要看场景”；
• GLM 的中文表达最顺，但前面大半段都在围绕“大模型能力在提升”打转，最后才落到“两者会融合”。

三个答案放在一起，没有一个是明显“错误”的，但也没有一个让人感觉“完整”。它们各自覆盖了不同的侧面，也各自遗漏了别的模型提到的关键点。如果我只信其中任何一个，得到的都是残缺结论。

1.2 单模型为什么会“看不到”自己的盲区

这里有个很现实的原因：不同模型的训练数据分布、架构设计、对齐策略都不一样，所以它们的“错误模式”也不一样。同一个逻辑陷阱，可能 A 模型踩了但 B 模型不会踩；同一个知识盲区，可能 B 模型知道但 A 模型完全没训练到。

更麻烦的是，单模型在生成答案时没有外部反馈机制。它把一段 token 一个接一个地写出来，写完就结束，中间不会有人问它“你这句话的依据是什么”“你刚才是不是自相矛盾了”。模型对自己的输出有一种“内部一致性”的自信，但这种自信并不等于正确。

1.3 多模型辩论的本质：把“自查”变成“他查”

自己做过的都知道，自己检查自己的代码永远不如同事 review 靠谱。模型也一样，让它自己检查自己的回答，它大概率会顺着原来的思路再圆一遍；但让另一个模型来反驳它，它就必须面对一套完全不同的推理框架。

学术上这种做法有个名字，叫 Multi-Agent Debate，核心思路是让多个模型各自生成观点，再通过多轮“阅读—反驳—修正”的循环逼近更高质量的答案。这个机制真正起作用的原因不是“三个臭皮匠顶个诸葛亮”，而是“不同错误的模型互相发现对方的错误”——前提是选出来的几个模型差异足够大。

所以我当时就决定：与其费劲调一个模型的 prompt，不如直接搭一个多模型辩论环境，让它们自己吵。这个项目就是这么开始的。

2. 选型定案：为什么选择在 GPU 算力平台本地部署开源模型

2.1 两条路线对比：调云端 API 还是本地部署

刚开始我其实犹豫过：到底直接调用三个模型的云端 API，还是在 GPU 算力平台上把开源权重拉下来本地跑？我把两条路线的关键差异列了个表，看完基本就有结论了。

2.2 为什么我选了“本地部署”这条路

原因有三个。第一，辩论赛要反反复复跑很多轮。我预期会测试十几个辩题，每个辩题 3 轮 × 3 个模型 × 300~500 字，如果全程走云端 API，token 费用是一笔不必要的开销；本地部署只要租卡费用固定，测试次数再多也不心疼。

第二，辩论的 prompt 策略需要频繁调整。第一版跑完发现模型之间像“各自写作文”而不是“互相反驳”，我得改角色卡、改轮次逻辑、改上下文拼接方式。这种高频调试在本地环境下要舒服得多——改完配置重启一下推理服务就行，不用跟 API 网关和限流策略较劲。

第三，我想看真实的中间过程。辩论最有趣的不是最终结论，而是模型在每一轮里如何被对手“带偏”或“点醒”。本地部署可以直接在日志里看每一条输入输出，甚至能看到模型的思考长度变化，这是黑盒 API 给不了的。

2.3 模型选择：三个开源模型，一个量级，三种性格

为了让辩论足够“有火花”，我特意选了三个风格差异明显的开源模型，同时控制参数规模在同一档，避免出现“体型碾压”：

• DeepSeek-R1-Distill-Qwen-14B：蒸馏版的推理模型，输出会带明显的“推理链”风格，擅长拆解逻辑漏洞；
• Qwen2.5-14B-Instruct：通用指令模型，覆盖面广，表达全面但相对温和；
• GLM-4-9B-Chat：中文对话模型，语言流畅，喜欢做归纳总结。

2.4 显存估算：一张卡够不够，怎么算

部署之前一定要先算显存，不能凭感觉。以 14B 模型为例，FP16 精度下权重占大约 14 × 2 = 28GB，再加上推理时的 KV Cache 和激活值，实际建议留出 40GB 以上。9B 模型的权重约 18GB，跑起来建议至少 24GB，32GB 更稳。

我当时的部署方式是开三台云 GPU 实例，每台实例放一个模型，端口分别用 8001、8002、8003。如果你预算有限，也可以租一张 80GB 显存的卡，依次加载三个模型，但那样只能串行跑，速度会慢不少。

2.5 部署命令其实就三行

在每台实例上执行类似下面的命令，就能起一个 OpenAI 兼容的推理服务。我用的推理框架是 vLLM，它对高并发和长上下文支持都比较成熟：

# 实例 1：DeepSeek 推理模型，端口 8001 python -m vllm.entrypoints.openai.api_server \ --model /models/deepseek-r1-distill-qwen-14b \ --port 8001 \ --max-model-len 16384 \ --gpu-memory-utilization 0.92

# 实例 2：Qwen 指令模型，端口 8002 python -m vllm.entrypoints.openai.api_server \ --model /models/qwen2.5-14b-instruct \ --port 8002 \ --max-model-len 16384 \ --gpu-memory-utilization 0.92

# 实例 3：GLM 对话模型，端口 8003 python -m vllm.entrypoints.openai.api_server \ --model /models/glm-4-9b-chat \ --port 8003 \ --max-model-len 16384 \ --gpu-memory-utilization 0.92

提示：模型权重如果从海外仓库下载比较慢，可以选择国内可用的镜像站拉取，速度会快很多。这里不展开说具体地址，搜一下“模型权重镜像”就能找到。

三个服务都起来之后，用curl /v1/models各测一下，能正常返回模型名就说明部署成功了。后续的所有“争吵”，都由一个 Python 脚本通过 HTTP 请求来驱动。

3. 辩论规则设计：回合制、角色卡与裁判机制

3.1 辩题选择原则：安全、有争议、还是技术圈能聊的

辩论赛的体验很大程度上取决于辩题。我踩过的坑是：选了一个太宏大的题目，结果三个模型都在写“综述”，完全没有交锋感；后来换成“未来三年，RAG 会被超长上下文完全取代吗”这类具体且有明确对立面的题目，效果立刻不一样。

这里有个安全提醒：辩题尽量不要碰社会、政治、历史类话题，一是容易踩红线，二是这类话题的“正确结论”往往需要复杂语境，模型很容易说出不合适的话。我最后用的主题都集中在技术趋势和工程实践上，比如“AI 生成代码是否值得在生产环境信任”“开源模型会不会全面超过闭源模型”。这类题目既有争论空间，又是模型训练数据里大量覆盖的内容，吵起来比较有料。

3.2 角色卡：给每个模型一个固定立场

辩论不能没有立场，否则模型会习惯性地“和稀泥”。我给三个模型分别设了不同的立场：

• DeepSeek 扮演“反方”：坚持 RAG 不可替代，重点是攻击“长上下文解决不了知识更新成本”；
• Qwen 扮演“正方”：主张长上下文将逐步取代 RAG，重点强调“窗口够大就能直接装下知识库”；
• GLM 扮演“观察方”：视角介于两者之间，负责补充双方都忽略的边界条件。

角色卡以 system prompt 的形式固定下来，内容大致如下：

你是大模型辩论赛中“反方”辩手。 辩题：{topic} 你的核心立场：{stance} 辩论规则： 1. 每一轮先直接回应对手上一轮里的核心论据，再提出你的新论点； 2. 每轮输出不超过 400 字； 3. 禁止人身攻击，只讨论论点本身； 4. 如果对手让你改变立场，你必须明确说明“我改变/保留了哪个观点”以及理由，不能无理由附和； 5. 不能复述自己的上一轮回答，每一轮必须有增量信息。

这套角色卡是我调了好几版才定下来的。最开始忘记写“先回应对手”，结果三个模型各自输出了一大段“立论”，第二轮开始还是各说各的，根本不像辩论。后来加上“先回应对手核心论据”这一条，效果立刻不一样。

3.3 回合结构：立论、交叉辩论、最终陈词

我的回合设计分三个阶段：

1. 第 0 轮：三个模型互不看到对方，各自亮明核心立场，限 400 字。这一步是为了让每个模型先建立“原始观点”，不受干扰；
2. 第 1~3 轮：每轮从 DeepSeek 开始，让它看到其他两位最近的发言，然后输出反驳或补充；接着轮到 Qwen、GLM。这样每个模型每一轮都能基于“更新后的战况”发言；
3. 最终轮结束后，调用裁判对三方做综合评分。

固定三轮是我试出来的经验值。两轮太浅，模型的观点还没来得及修正；四轮以上会出现大量重复，而且上下文长度会膨胀。三轮刚好能让每个模型表达两到三次完整观点，同时不至于让成本和延迟失去控制。

3.4 裁判机制：让模型当评委，还是用规则打分

裁判我用的是模型评分。具体做法是把三方的最终陈词连同评分维度一起发给裁判模型，让它按四个维度打分：论点明确性、论据强度、反驳命中率、新信息贡献，每个维度 0~5 分。

你是这场大模型辩论赛的裁判。请基于三方的最终陈词和整场辩论记录进行评分。 评分维度（每项 0~5 分）： - 论点明确性：立场是否清晰，论证结构是否完整； - 论据强度：是否使用可信的事实、数据或逻辑推理； - 反驳命中率：是否准确攻击了对手的薄弱点； - 新信息贡献：是否不断提出新论据，而不是复述已有内容。 请输出 JSON 格式结果： {"deepseek": {"论点明确性": 0, "论据强度": 0, "反驳命中率": 0, "新信息贡献": 0}, "qwen": {...}, "glm": {...}}

用模型当裁判的好处是它能理解语义，能判断“反驳是否真的命中”。坏处是裁判本身也有偏好，比如我用 Qwen 当裁判时，它对 Qwen 自己的表达风格会有微弱偏向。所以如果你要横向对比，建议用一个跟三位辩手不同源的模型当裁判，或者干脆把四个评分维度做成规则化打分。

4. 主持脚本的骨架：串行调用、历史上下文与异常处理

4.1 全局数据结构的简化设计

整个辩论过程由一个 Python 脚本担任“主持人”。我没有用复杂的对话树，而是维护了一个全局发言日志：

debate_log = [ {"speaker": "deepseek", "round": 0, "content": "..."}, {"speaker": "qwen", "round": 0, "content": "..."}, {"speaker": "glm", "round": 0, "content": "..."}, ]

每个辩手只保留自己的 system prompt（角色卡），对手的发言不塞进“聊天历史”，而是拼进 user prompt。这样做的好处是结构简单、上下文可控，坏处是模型看不到完整的你来我往链条，只能看到最近几条。所以上下文选择策略就变得很关键，我会在下一节专门讲。

4.2 核心调用函数：兼容 OpenAI 协议

三个推理服务都兼容 OpenAI 的 chat/completions 接口，所以可以用统一的 requests 调用：

import requests import time DEBATERS = { "deepseek": { "url": "http://127.0.0.1:8001/v1/chat/completions", "model": "/models/deepseek-r1-distill-qwen-14b", "system_prompt": "你是反方辩手...（完整角色卡）" }, "qwen": { "url": "http://127.0.0.1:8002/v1/chat/completions", "model": "/models/qwen2.5-14b-instruct", "system_prompt": "你是正方辩手...（完整角色卡）" }, "glm": { "url": "http://127.0.0.1:8003/v1/chat/completions", "model": "/models/glm-4-9b-chat", "system_prompt": "你是观察方辩手...（完整角色卡）" } } def call_llm(name, user_prompt, temperature=0.9, max_tokens=600): cfg = DEBATERS[name] messages = [ {"role": "system", "content": cfg["system_prompt"]}, {"role": "user", "content": user_prompt}, ] for attempt in range(3): try: resp = requests.post( cfg["url"], json={ "model": cfg["model"], "messages": messages, "temperature": temperature, "max_tokens": max_tokens, }, timeout=180, ) resp.raise_for_status() return resp.json()["choices"][0]["message"]["content"] except Exception as e: print(f"[{name}] 第{attempt + 1}次调用失败: {e}") time.sleep(3) return ""

这里有两个容易踩的细节。第一，vLLM 的model参数要跟启动时传入的路径一致，否则会报模型不存在。第二，推理模型（尤其是 DeepSeek-R1 蒸馏版）在输出前会先“思考”很长一段，必须把 timeout 设到 180 秒，否则大概率超时。

4.3 主流程：先并行立论，再串行吵架

第 0 轮三个模型互不依赖，可以用线程池并行调用，节省时间。从第 1 轮开始必须串行，因为每个辩手都要看到对手“最新”的发言。主流程如下：

from concurrent.futures import ThreadPoolExecutor def run_debate(topic, max_rounds=3): log = [] # 第 0 轮：并行立论 with ThreadPoolExecutor(max_workers=3) as pool: futures = { pool.submit(call_llm, name, f"辩题：{topic}\n请先亮明你的核心立场，限400字。"): name for name in DEBATERS } for future in futures: content = future.result() log.append({"speaker": futures[future], "round": 0, "content": content}) # 第 1 ~ max_rounds 轮：串行辩论 for rnd in range(1, max_rounds + 1): for name in DEBATERS: recent = format_recent_speeches(log, name) prompt = ( f"辩题：{topic}\n" f"最近辩论记录：\n{recent}\n" f"现在轮到你发言。请先指出对手论据中最薄弱的一点，" f"再给出你的反驳或补充，限400字。" ) content = call_llm(name, prompt) log.append({"speaker": name, "round": rnd, "content": content}) return log

format_recent_speeches是把最近几条发言整理成带 speaker 前缀的纯文本。这一步看似简单，但对辩论质量影响非常大，下一节再细说。

4.4 结果落盘：把每一轮都存下来

调试和复盘都需要留痕，所以每跑完一场辩论，我会把完整的log、辩题、角色卡、参数设置存成一个 JSON 文件：

import json, datetime output = { "topic": topic, "params": {"temperature": 0.9, "max_tokens": 600, "max_rounds": 3}, "log": log, "created_at": datetime.datetime.now().isoformat(), } with open("debate_result.json", "w", encoding="utf-8") as f: json.dump(output, f, ensure_ascii=False, indent=2)

存盘看起来是个小动作，但如果没有它，后面分析“哪一轮的哪个策略起了作用”就完全无据可查。

5. 实测回放：三个模型的“性格”差异和辩论翻车现场

5.1 一句话总结三位的辩论风格

用同一个辩题“未来三年，RAG 会被超长上下文完全取代吗”跑完三轮后，三位的风格差异非常明显：

5.2 辩论过程里发生的事

第一轮最有意思。DeepSeek 率先发难，说“长上下文解决的是‘看得到’的问题，RAG 解决的是‘找得到’和‘更新得起’的问题，两者根本不是一回事”，这论点抓得挺准。Qwen 立刻回应，举了企业私有知识库的例子，说“如果上下文窗口能装下整个知识库，为什么还要维护一套检索系统”，也算站得住。GLM 这时候没有急着站队，而是补充了一个边界条件：“检索延迟和上下文成本的权衡会随场景变化”。

第二轮开始出现翻车迹象。Qwen 在 DeepSeek 的连续追问下，直接说“你说得对，我部分改变立场”，但没有给出新的论据。DeepSeek 立刻抓住这一点输出了一段“这就是缺乏独立论据的表现”，导致 Qwen 在第三轮有点找不到方向。与此同时，GLM 开始“复读”自己第二轮的观点——它把上一轮的话换了几种说法又写了一遍，增量信息很少。

如果你期望看到三个模型吵得不可开交，现实可能让你失望。模型的“辩论”本质上还是概率生成，它们会在“迎合对手”和“坚持立场”之间摇摆，而且越到后面的轮次越容易陷入重复。

5.3 裁判打分到底怎么解读

用裁判模型跑出来的分数大概长这样：

但别把这个分数当成“谁更聪明”的结论。同一套辩题换一个方向，比如“开源模型会不会全面超过闭源模型”，赢家可能就变成 Qwen，因为它的知识面更适合列举实际案例。裁判分数只反映这场特定辩论里的表现，更有价值的用法是横向比较“我改了哪些规则之后，谁的总分提升了”。

6. 从翻车到能用：五个直接有效的调优技巧

6.1 强制“先引用对手观点，再反驳”

这是整套实验里回报率最高的改动。初版 prompt 没有明确要求模型回应对手，结果三个模型像在写三篇独立作文。改成“最近辩论记录如下……请先指出其中最薄弱的一点，再反驳”之后，辩论才真正“吵”起来。我建议你在自己的脚本里也把这句话写进每一轮的用户提示词。

6.2 上下文截断策略：只保留最近两轮，旧的做压缩摘要

辩论到第三轮时，完整日志已经很长。如果每次都把全部历史塞进 prompt，不仅 token 消耗大，模型还会因为信息太多而答得空泛。我后来的做法是：

• 保留最近 2 轮共 6 条完整发言；
• 更早的发言在进入 prompt 之前，每条截断成不超过 60 字的摘要；
• 如果模型支持更长的上下文，可以适当放宽，但不要无脑堆全部历史。

这个策略让辩论质量稳定了不少，模型能把注意力集中在“当前交锋点”上，而不是被一堆历史细节带偏。

6.3 对抗“复读机效应”：模型必须说明自己改变了什么

前面提到 GLM 会在第三轮复读自己的观点，这其实是模型没有收到“必须有增量”的约束。我在角色卡里加了这样一条规则：

如果你与对手观点一致，必须明确说明你改变了原有观点中的哪一个部分，以及为什么改变；如果你不同意，必须指出对手论据中的事实错误、逻辑跳跃或遗漏变量。不能简单重复上一轮内容。

加了这个规则后，复读明显减少。虽然偶尔还会出现“换几个词再说一遍”的情况，但总体增量信息多了很多。

6.4 温度设置在 0.8 ~ 1.0 之间，裁判温度要低

我对比过几组温度：

• 0.2：输出稳定，但辩论枯燥，像三个客服轮流读稿；
• 0.9：模型更愿意尝试新说法，也更容易产生“交锋感”；
• 1.2：开始编造数据和例子，甚至出现前后不一致的幻觉。

所以辩论阶段我固定用 0.9。但我给裁判模型单独设了 0.3 的低温度，因为裁判需要稳定、可复现的打分，不需要创造力。

6.5 成本控制：租卡按小时计费，先跑通小规模再正式跑

本地部署虽然绕开了 token 费用，但算力平台的租卡费用是按小时算的。我的做法是先用“单轮单模型”的最小脚本验证部署和调用链路，等确认没问题后再跑完整辩论。完整辩论一场大约要 2~5 分钟，取决于三个模型的推理速度，所以调试阶段一定不要直接上大规模测试，否则卡租着没跑出多少有效数据，费用先上去了。

另外部署实例要记得在脚本跑完后立刻释放。我有一回跑完测试忘记释放三台实例，白白多付了几个小时的卡费，这是真金白银踩出来的教训。

最后再分享一个小技巧

如果你看完也想搭一个，我建议第一次不要上三个模型，两台就够了：正方一个，反方一个，让它们来回各说三轮。你会发现“两个模型互相反驳”的效果已经足够惊艳，而且排查问题的时候，日志只有两条线，脑子完全跟得上。

这场实验跑完之后，我对“多模型协作”的看法变了不少——它并不是把几个模型简单堆在一起，而是让不同训练背景的模型互相做“外部审查”。单模型回答不了的漏洞，换个模型来反驳，往往一眼就能看穿。这大概就是这场“吵架”最有价值的地方。希望这篇记录能让你少走点弯路，也欢迎把你的辩论实录拿来一起聊。