最开始我对比两个模型的回答质量，用的还是最笨的办法：开两个浏览器标签页，把同一个问题分别粘进去，再左右来回切。遇到长回答还得自己对对齐位置，效率低到让人怀疑人生。直到我把这套动作搬进 Dify，用可视化工作流把两个模型接进同一条链路，一次请求发出去，两个模型同时在后台跑，结果通过分栏页面流式打印出来——整个体验完全不一样了。

双模型分栏同步流式输出，这个需求听起来很唬人，其实拆开就是：同题、双答、并排、流式。这篇文章会把完整的实现思路、节点配置和前端接入代码都拆开讲，顺便聊聊为什么在这个场景下，Dify 比起 OpenWebUI 更值得优先考虑。适合正在做模型选型对比、想给团队搭一个多模型评测小工具、或者单纯想在同一个画布上直观感受不同模型输出差异的人。

1. 方案选型与核心需求拆解

1.1 双模型对比场景的需求到底长什么样

很多人做模型对比，第一反应是"我开两个网页不就行了"，但真上手就会发现痛点很明显。同一个问题两遍提问，意味着你要手动维护输入的一致性；两个模型并行回复，意味着你要持续横向对照滚动进度；如果想记录评测结论，还得自己复制粘贴、标注模型名。这套流程如果只是偶尔三五次还能忍，一旦要成规模做评测，纯手工就彻底不行了。

所以双模型对比工具的隐藏需求其实是三块。第一块是输入统一，同一个问题只敲一遍，同时发给两个模型。第二块是输出并排，左右两栏天然形成视觉对照，谁答得长、谁答得短、谁在胡扯，一眼就能看出来。第三块是流式体验，最好两个模型边生成边滚动，像两个选手同时答题，而不是等全部生成完才一次性弹出来。这个需求本身不复杂，但对工具形态提出了明确要求：要能编排多模型调用，要能聚合多路输出，要能支持流式协议。

再说得直白一点，整个需求落到执行层就四个字：同题、双答、并排、流式。目标是把一次评测动作从"手动操作半小时"压缩成"输入问题、点发送、看结果"。

1.2 为什么在这个场景下 Dify 比 OpenWebUI 更合适

先给 OpenWebUI 说句公道话，它是一个很好用的自托管聊天界面，界面清爽，支持接入多种模型后端，社区里也有大量插件。我自己也用过一段时间，日常单聊非常舒服。但它的核心交互模型是"一个会话对应一个模型"，消息列表按时间线平铺，切换模型靠的是下拉选择器。这个架构没问题，可一旦你想让两个模型同时回答同一道题并把结果分栏展示，它默认做不到，需要你去改前端状态管理、改消息渲染逻辑、改 API 调用层，本质上是做二次开发。

Dify 的出发点不一样。它有一个可视化工作流引擎，应用可以被拆成节点图：开始节点拿用户输入，LLM 节点负责调模型，结束节点负责聚合结果。两个 LLM 节点只要相互没有依赖关系，就会并行执行，天然支持"同题双答"这个诉求。再加上结束节点支持多变量输出，前端可以按字段分别渲染左右两栏，等于把最费劲的编排和聚合部分都交给了平台侧。

所以"秒杀"这个说法严格来说是不严谨的，OpenWebUI 本身没做错什么，只是它和 Dify 的定位不一样。如果只用一句话总结我的判断：OpenWebUI 是给"人和模型聊天"设计的，Dify 更适合"人编排模型做事"的场景。双模型分栏对比恰好属于后者。

1.3 两条落地路径：工作流聚合与双请求并行

具体落地时有两条路径可以选，我先把它们摆在前面，免得后面越读越乱。

路径 A 是"单工作流聚合"。在 Dify 里创建一个工作流应用，里面同时挂两个 LLM 节点，前端只需要发一个请求，后端等两条模型分支跑完后，把结果以 SSE 流式吐给前端，前端按输出字段分栏渲染。优点是节点少、逻辑集中、一次请求搞定；缺点是响应时间受制于最慢的那个模型，两边没法"独立逐字跳动"。

路径 B 是"双请求并行"。在 Dify 里分别创建两个对话应用，一个用模型 A，一个用模型 B，前端同时向两个应用的 API 发请求，各自独立接收流式数据，再放到同一页面的一左一右两个容器里。优点是流式体验最真实，两个模型谁先出字谁先展示；缺点是要维护两套应用，上下文割裂，后端没法做统一聚合和后续扩展。

路径 A 在"架构简洁"上完胜，路径 B 在"流式细腻度"上占优。如果你的核心诉求是快速搭建一个对比台子，路径 A 已经足够；如果你想追求极致的逐字双栏跳动，可以看路径 B 的补充说明。本文主体按照路径 A 来讲，因为它在 Dify 侧的"零代码"优势最明显。

2. 环境准备与模型接入

2.1 部署 Dify 并做基础初始化

Dify 的部署本身不算复杂，官方提供了 Docker Compose 编排模板，基本上是在一台装有 Docker 和 Docker Compose 的机器上，拉取编排文件后执行启动命令，然后等待服务起来就行。我第一次部署时大概花了十几分钟，主要是镜像拉取需要一点时间。

docker compose up -d

启动完成后，访问部署机器的对应端口，会进入初始化页面。这里需要创建一个管理员账号，邮箱和密码按你自己的习惯填，建议密码用强密码记在密码管理器里。初始化完成后进入工作台，左侧能看到应用列表、工具、知识库等菜单。不同版本界面布局会略有差异，但核心概念是稳定的。

有一个小建议：部署时把服务器时区、网络策略提前确认好，尤其是后面要调用外部模型 API 时，网络连通性决定你能不能正常走通两个模型节点。如果你在本地跑通后要迁移到服务器，Docker 的 volume 数据是跟着 compose 工程走的，记得一并备份迁移。

2.2 接入两个模型供应商

工作台里找到"设置"，进入"模型供应商"页面。Dify 会列出一批主流接入方式，包括商业 API、开源模型本地部署、以及各类兼容协议。我们要做双模型对比，至少需要接两家，或者接同一家但使用两个不同的模型实例。

接入时的核心动作是填 API 密钥和模型名称。商业 API 一般是在对应的模型服务平台申请密钥，然后把密钥配到 Dify 里，选择具体的模型标识。本地部署的开源模型则要看你的模型服务是否暴露了兼容接口，把服务地址和模型名填进去，跑通连通性测试即可。

这里建议你做一张接线表，把两个模型各自的模型名称、上下文长度、最大输出 Token 上限、服务地址、密钥归属方记录清楚。别嫌麻烦，后面配置 LLM 节点时，Max Token 和上下文长度都要参考这张表填，填错了要么报错，要么输出被截断。

2.3 创建应用并确认接口形态

模型接入完成后，回到应用列表，新建一个"工作流"应用。为什么用工作流而不是聊天助手，原因很简单：工作流应用的完成形态是"输入一堆变量、输出一堆变量"，非常适合双模型聚合；聊天助手的默认形态是单会话对话，虽然也可以拖节点，但要做多变量分栏输出反而不够直接。

如果之后你确实希望保留多轮会话上下文，比如用户追问时不丢失前面说过的话，可以改用"聊天流"应用类型。它的节点编排思路和工作流基本一致，但系统会自动维护会话历史，LLM 节点可以用记忆能力。单次对比评测用工作流足够，想要追问式评测再切聊天流。

应用创建完成后，先记住两个入口：一个是 WebApp 的预览地址，适合在浏览器里直接点击测试；另一个是"API 访问"页面，里面能看到应用专属的 API 密钥和请求地址。后面我们要走的就是 API 接口，因为分栏展示需要自定义前端页面，不走 Dify 自带的 WebApp 界面。

提示：应用 API 密钥是数据访问凭证，在浏览器前端直接暴露等于裸奔，生产环境必须放到你自己的后端服务里，通过服务端转发请求，不要直接下发到页面。

3. 双模型分栏工作流编排

3.1 工作流的节点结构长什么样

进入工作流画布后，默认会有一个开始节点和一个结束节点。我们要在中间挂两个并行的 LLM 节点，最终结构是：开始节点连接 LLM 节点 A 和 LLM 节点 B，这两个节点再分别连接结束节点。

从画布上看，两个 LLM 节点是并排放在开始节点之后的。它们之间没有连线，也没有数据依赖，Dify 在调度时会认为这两个分支互不阻塞，于是并行执行。这里有一个常见误解要澄清：并行不是"两个模型同时从一个节点里被调用"，而是"两个独立节点同时运行"。你可以在结束节点里看到两个分支的名字，在运行记录里看到两个节点的耗时，它们是两条独立执行线。

我给这套结构取了名字，叫做"1 拖 2 汇 1"：一个开始节点拖出两条模型分支，最后汇聚到一个结束节点。后面你想扩展成三模型、四模型，只需继续往中间加"拖"出去的 LLM 节点，结构逻辑完全一样。

3.2 开始节点与 LLM 节点的参数配置

开始节点决定用户输入从哪里进来。工作流应用默认情况下，用户的问题会被放在sys.query这个系统字段中，你可以在开始节点里把它显式暴露成一个输入变量，命名为query，类型选择"段落"。这样后续 LLM 节点就能直接引用这个变量，保证两个模型拿到的是同一个用户问题。

LLM 节点 A 的配置是这样：模型选择"模型 A"，系统提示词填"你是模型 A 的评测实例，请客观、结构化地回答用户问题，不要提及你的身份名称"，用户提示词填{{query}}，温度设为 0.2，Max Token 设为 1024。LLM 节点 B 完全对标，只是模型改成"模型 B"，系统提示词里对应改成"你是模型 B 的评测实例"。

温度为什么要设低？因为我们在做对比评测，要的是可复现的、稳定输出的结果，不是天马行空的创作。温度高会让同一个问题每次回答都不一样，对比失去参考意义。如果你做的是创意文案对比，可以把温度调到 0.7 左右，这是场景差异，不是铁律。

3.3 结束节点与流式输出开关

两个 LLM 节点之后，来到结束节点。结束节点是整条工作流的出口，这里有两个关键设置。

第一是"流式输出"模式。Dify 的结束节点允许在"普通输出"和"流式输出"之间切换，普通输出会把所有变量打包成 JSON 一次性返回，流式输出则会以 SSE 协议边生成边推送给客户端。我们要做的是流式打字机效果，必须把结束节点的输出类型选成"流式输出"。

第二是输出变量的定义。在结束节点里新增两个输出变量，一个叫model_a_answer，取值来源指向 LLM 节点 A 的输出；另一个叫model_b_answer，取值来源指向 LLM 节点 B 的输出。保存后在节点输出区域能看到完整输出字段。前端解析流式数据时，就是按这两个字段名来分别更新左右两栏的。

这里你可能会问，为什么结束节点要等两个分支都跑完才输出？因为结束节点必须拿到全部输入变量，而它的输入来自两条分支，所以天然要等最后一个模型完成。这意味着整体响应时间是 max(模型 A 耗时, 模型 B 耗时)。这个"等最慢模型"的特性在路径 A 里是明确的取舍，想要两边独立先到先得，那就去看路径 B 的双请求方案。

3.4 发布应用并拿到 API 凭证

到这一节，Dify 侧的核心配置就算完成了。点击画布右上角的"发布"按钮，让应用进入已发布状态。注意，未发布的应用调试时只能从画布内部跑，发布后才能通过外部 API 和 WebApp 访问。

发布之后进入"API 访问"页面，新建一个 API 密钥，复制保存。接下来用 curl 或者 API 调试工具做一个冒烟测试，确认工作流能正常返回流式数据。一个最简请求长这样：

curl -X POST 'https://your-domain/v1/workflows/run' \ -H 'Authorization: Bearer app-xxxxxx' \ -H 'Content-Type: application/json' \ -d '{ "inputs": {"query": "请用三点理由说明为什么需要多模型对比评测"}, "response_mode": "streaming", "user": "tester" }'

不同版本的 Dify 在 API 路径和字段上可能有细微差异，以你部署平台上"API 访问"页给出的接口文档为准。第一次调通流式接口后，你会看到响应体是一串data:开头的事件流，里面带着输出字段的增量信息，这就是下一步前端要解析的内容。

4. 前端分栏同步流式渲染

4.1 流式响应的底层格式

为什么前端能拿到"打字机"效果，底层靠的是 SSE，也就是 Server-Sent Events。它不是 WebSocket，而是一种基于 HTTP 的长连接协议，服务端可以持续向客户端推送数据，客户端用一个普通的 fetch 请求就能读取流式内容。

Dify 的流式接口返回的 SSE 数据，每一段长这样：以data:开头，后面跟着一个 JSON 字符串，以空行分隔不同事件。JSON 里通常包含执行元信息和输出数据，其中输出数据再嵌套outputs字段。我们需要关心的是outputs.model_a_answer和outputs.model_b_answer。每次收到新的 data 事件，这两个字段的内容往往是截至当前的累计文本，所以前端可以简单地直接把当前值赋给对应容器。

一个比较容易踩的点是 SSE 数据会被网络传输切成多个 chunk，你不能假设一次 fetch read 就拿到完整一行。正确做法是维护一个缓冲区，把读取到的数据按换行符切分，完整的行再做解析，半截的行留在缓冲区等下一个 chunk。这部分逻辑不复杂，但写错会导致字段丢失和 JSON 解析报错。

4.2 一个可直接用的分栏页面

页面结构很简单：顶部一个输入框和一个发送按钮，下方左侧放模型 A 的回答，右侧放模型 B 的回答。布局直接用 CSS Grid 就能实现，两栏宽度相等，中间留一点间距。

<div id="inputBar"> <input id="questionInput" placeholder="输入你想对比的问题" /> <button id="sendBtn">发送</button> </div> <div id="compareGrid"> <div class="col" id="colA"> <div class="col-title">模型 A</div> <div class="col-body" id="outputA"></div> </div> <div class="col" id="colB"> <div class="col-title">模型 B</div> <div class="col-body" id="outputB"></div> </div> </div>

#compareGrid { display: grid; grid-template-columns: 1fr 1fr; gap: 16px; min-height: 400px; } .col { border: 1px solid #e5e5e5; border-radius: 8px; padding: 16px; background: #fafafa; } .col-title { font-weight: 600; margin-bottom: 8px; } .col-body { white-space: pre-wrap; word-break: break-word; }

前端读取流式的核心逻辑封装在一个异步函数里。发送请求后，从response.body拿到读取器，循环读取数据块，解码后切行，遇到data:开头就解析 JSON，再根据outputs更新两个栏位。用white-space: pre-wrap是为了保留换行，否则多行回答会挤成一坨。

async function runCompare() { const query = document.getElementById('questionInput').value.trim(); if (!query) return; const outputA = document.getElementById('outputA'); const outputB = document.getElementById('outputB'); outputA.textContent = '模型 A 思考中...'; outputB.textContent = '模型 B 思考中...'; const resp = await fetch('/api/dify/workflow', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ query }) }); const reader = resp.body.getReader(); const decoder = new TextDecoder(); let buffer = ''; while (true) { const { done, value } = await reader.read(); if (done) break; buffer += decoder.decode(value, { stream: true }); const lines = buffer.split('\n'); buffer = lines.pop() || ''; for (const line of lines) { const trimmed = line.trim(); if (!trimmed.startsWith('data:')) continue; const payload = JSON.parse(trimmed.slice(5).trim()); const outputs = payload.data && payload.data.outputs; if (outputs) { if (outputs.model_a_answer != null) { outputA.textContent = outputs.model_a_answer; } if (outputs.model_b_answer != null) { outputB.textContent = outputs.model_b_answer; } } } } } document.getElementById('sendBtn').addEventListener('click', runCompare);

如果你希望回答里的 Markdown 标题、加粗、列表能被渲染成样式，可以把textContent改成innerHTML，再在写出内容前调用一个 Markdown 渲染库，把纯文本转成 HTML 后塞进栏位。不引入额外库也可以，纯文本阅读对评测场景完全够用。

我把这段逻辑放在服务于"零代码"目标下做了一个边界说明：Dify 侧确实全程零代码，但前端总得要一小段接入代码，这是所有平台 API 模式下都绕不开的。好在代码是通用的，第一次写好之后，以后换模型、换任务都不用改前端。

4.3 追求极致流式：双请求并行方案

路径 A 的缺点是两边要等最慢的模型。如果你对"两边独立出字"有执念，可以走双请求并行方案：在 Dify 里分别建两个模型单应用的对话助手，各自露出一个 API 接口，前端同时发两个 fetch 请求。

核心改动是去掉同一个请求里对两个字段的依赖，改成两个独立的异步流各自写各自的容器。两个 fetch 之间没有等待关系，哪个模型先出字，哪一栏就先滚动。缺点也很明显，两条请求对应两套应用，你需要在 Dify 侧维护两个应用的应用配置和提示词，如果之后想加裁判模型、加知识库，还要在外部把它们串起来。

我的建议是，先把单工作流聚合跑通，它已经能满足绝大多数对比需求。只有当你在意"两边完全独立逐字渲染"时，再去尝试双请求并行，不要在第一步就上复杂方案。

5. 实操中常见的坑与排查

5.1 流式输出不生效，先查这三处

我实测下来，流式输出不生效通常不是前端问题，而是后端三个设置中的一个没到位。

第一，结束节点的输出模式是否真的切到了"流式输出"。它和普通输出在画布上看不出来，但运行记录里能明显看到差异，普通输出是整体包在 JSON 里返回，流式输出则是一段一段data:推出来。

第二，请求体里的response_mode是否传了streaming。如果你在 API 请求里没传或者传了blocking，Dify 就不会走流式协议，而是等完整结果一次性返回。

第三，反向代理是否缓冲了响应。如果前端和 Dify 之间隔着一层 Nginx，默认的proxy_buffering会等响应积累到一定程度才统一转发，表现就和流式完全相反。需要在代理层关闭缓冲：

location /api/dify/ { proxy_pass http://your-dify-backend/; proxy_buffering off; proxy_cache off; proxy_read_timeout 300s; }

5.2 输出字段是空的，或前端取不到

这是第二个高频坑。Dify 工作流里自动生成的节点输出变量名，常常带上一长串前缀，比如llm_xxx_text，看起来和你在结束节点里定义的名字不直接对应。如果前端解析时硬编码了model_a_answer，而实际返回的是带前缀的名字，就会一直取不到内容。

解决办法有两个。一个是在结束节点里把输出变量的 key 手动改成model_a_answer这种简洁名字，这样前端代码就能按预期解析。另一个办法是先打印一次完整的 API 返回结构，把实际的字段名抄下来再写前端。

另一个细节是 JSON 转义。SSE 里传输的字段是 JSON 字符串，多行文本会以\n呈现，如果你没有调用JSON.parse就直接用，输出的内容会是一堆反斜杠 n。前端的解析代码里一定要严格走JSON.parse再取字段，不要在未解析的字符串上做正则截取。

5.3 两边模型速度差异大，出现明显空窗

模型 A 可能秒回，模型 B 可能要等二十秒，合并输出时两栏的进度感非常不对称。这个问题的根子在模型本身的生成速度和 Max Token 上限差异。

处理的办法是尽量把两个 LLM 节点的 Max Token 设为相同值，避免一方因为上限小提前收尾，另一方还在长篇大论。如果生成速度本身差异大，可以考虑给快的模型在系统提示词里加一句"请尽可能详细地展开你的回答"，让两边篇幅更接近。前端方面，发送请求后两栏可以先显示"模型思考中..."的占位状态，避免用户看着空白误以为卡死。

5.4 长回答被截断与请求超时

当模型回答很长，超过节点配置的 Max Token 上限，输出会在到达上限处戛然而止，这个被截断的长短取决于设置。排查时先看两个 LLM 节点的 Max Token 是否足够，再确认模型服务商侧的上下文上限是否匹配。

请求超时则是另一个常见现象。模型生成慢、回答长、代理层读超时时间又设得短，就会出现连接被服务端或中间层掐断。前端 fetch 请求如果中断，两栏都停在半截状态。处理方式：代理层proxy_read_timeout调长，Dify 侧配长一点的超时窗口，前端读取循环里做简单容错，断流后提示"连接中断，请重试"。

5.5 快速排查速查表

5.6 跨域与密钥保护

最后这点非常重要，直接关系到生产环境能不能用。Dify 的 API 密钥一旦暴露在公网页面里，任何人都能拿着你的密钥去调用应用，额度会被刷爆甚至被拿去跑别的任务。所以前端页面不应该直接拿 API 密钥请求 Dify 接口。

正确姿势是自己做一个极薄的转发层：前端请求你自己的域名下的某个路径，你的服务端在这个路径里带上 Dify 的 API 密钥转发到 Dify 接口，再把流式响应原样返回给前端。前面 4.2 节示例代码里请求的是/api/dify/workflow，而不是 Dify 的真实域名，就是给这个转发层留的位置。CORS 跨域问题也在转发层统一解决，因为同域请求不存在跨域限制。

6. 扩展：从双模型对比到评测工作台

6.1 多模型扩展与布局调整

双模型跑通之后，加第三个、第四个模型只是重复劳动。回到工作流画布，把新的 LLM 节点拖出来，接在开始节点之后，输出引到结束节点。前端布局从两栏改成四栏，只需改动一行 CSS 的grid-template-columns，把1fr 1fr换成repeat(4, 1fr)。模型多了以后，建议给每栏加上模型标识、响应耗时等元信息，让对比结果更有参考价值。

6.2 加一个"裁判"模型做自动点评

多模型对比离不开最终结论。你可以在两个模型答案的基础上，再挂第三个 LLM 节点，专门扮演裁判角色。它的输入引用model_a_answer和model_b_answer，提示词写成"请从准确性、完整性、结构化程度三个维度对比两个回答，并给出你的倾向结论"。这样一次请求下来，你不仅拿到两个模型的回答，还拿到一份自动生成的评测意见。

Dify 节点之间传递变量非常方便，裁判节点的用户提示词直接用双大括号引用前面节点的输出变量即可。不需要写任何胶水代码，这是工作流模式对比起代码拼接的又一大优势。

6.3 接上知识库，变成双模型 RAG 对比

如果你的评测场景涉及私有知识，比如公司内部文档或产品资料，可以给工作流加一个知识检索节点。用户问题进来后，先走知识检索，把召回结果拼进两个 LLM 节点的提示词里，让两个模型都基于同一份参考资料作答。这样做的好处是两者拿到的是完全相同的检索上下文，评测公平性更有保证。

知识检索节点在 Dify 里是独立节点，输出变量通常是一段包含召回内容的文本。把这段文本插入到 LLM 节点的用户提示词前面，比如"请基于以下资料回答问题：{{knowledge}}"，两个节点各自引用同一个知识变量，检索只需要执行一次，不会额外消耗双倍检索费用。

6.4 沉淀成团队工具的一点个人心得

整套流程跑通后，我最直接的体感是：再做模型对比，我不会开一堆标签页了。打开工具页面，输入问题，点发送，两栏同时滚动，答案稳定排列，旁边还挂着裁判点评，效率和体验是手工方案没法比的。

最后分享一条我踩了几次坑才总结出来的经验。评测对比时，两个模型的温度、Max Token、系统提示词必须严格对齐，任何一边的不同都会让结果失去可比性。建议把评测用的问题集固定下来，输出结果用非流式模式另存一份 JSON 存档，流式分栏只用来给人类实时查看。真正要做数据分析和结论沉淀时，结构化的非流式数据比流式界面可靠得多。这套模板改一改提示词、换一换模型，几乎可以复用到所有"我到底该选哪个模型"的决策场景里。