通义千问1.5-1.8B-Chat-GPTQ-Int4 WebUI与ComfyUI工作流结合：可视化AI应用构建

最近在折腾AI应用的时候，我发现了一个挺有意思的玩法：把轻量级的聊天模型和ComfyUI这个可视化工具连起来用。你可能用过通义千问的WebUI来聊天，也用过ComfyUI来画图，但有没有想过，让它们俩“手拉手”一起干活？

想象一下这个场景：你画了一张图，然后让AI自动帮你写一段精彩的描述文案；或者反过来，你输入一段简单的想法，AI帮你把它扩展成一份详细的绘图指令，直接喂给画图模型。这听起来是不是比单独用一个工具要高效得多？

今天我就来分享一下，怎么把通义千问1.5-1.8B-Chat-GPTQ-Int4这个轻量又高效的模型，通过API的方式，变成一个ComfyUI工作流里的“智能节点”。这样一来，你就能在可视化的画布上，轻松搭建起属于你自己的多模态AI流水线了。

1. 为什么要把聊天模型接入ComfyUI？

你可能已经习惯了在Web页面里和通义千问对话，或者在ComfyUI里拖拽节点生成图片。把它们结合起来，到底能带来什么不一样的价值？

首先最直观的，就是自动化。以前你要完成“文生图，再让AI描述这张图”这个流程，得先在ComfyUI里生成图片，保存下来，再打开通义千问的WebUI，上传图片，等它生成描述。现在，你只需要在ComfyUI里设计好一个工作流，点一下“生成”，后面所有步骤就自动串联完成了。省去了来回切换工具、手动搬运数据的麻烦。

其次，是创造力的增强。ComfyUI本身是一个强大的“编排”工具，而通义千问模型是一个“理解与生成”工具。把它们结合，就等于给编排工具加上了大脑。比如，你可以让通义千问模型去分析一张图的风格、元素，然后基于这个分析，再去生成新的、风格匹配的绘图指令。这种循环反馈，能激发出很多单一步骤想不到的创意。

最后，是门槛的降低。对于不熟悉代码的朋友来说，通过API把模型能力封装成一个ComfyUI节点，意味着复杂的逻辑被简化成了“连线”操作。你不用去写调用代码，只需要关心输入是什么、输出要送到哪里，大大降低了构建复杂AI应用的门槛。

简单来说，这么做的核心就是：用可视化拼接，实现智能自动化，让1+1>2。

2. 准备工作：让通义千问模型“待命”

在开始连线之前，我们得先让通义千问模型准备好接受外部指令。这里的关键，就是启动它的API服务。

2.1 启动模型的API服务

假设你已经按照之前的教程，部署好了通义千问1.5-1.8B-Chat-GPTQ-Int4的WebUI。要让它的能力能被ComfyUI调用，我们需要以API模式来启动它。

通常，在启动WebUI的命令中，会有一个指定服务器端口和开启API的选项。一个典型的启动命令可能长这样：

python webui.py --api --port 7860

这里的 --api 参数就是告诉程序：“请打开API接口。” --port 7860 则指定了服务运行的端口号。运行这个命令后，你的模型服务就会在本地机器的7860端口上启动，并提供一个标准的API端点。

启动成功后，你可以在浏览器访问 http://127.0.0.1:7860/docs 看看。如果能看到一个自动生成的API文档页面（通常是Swagger或类似界面），那就说明API服务已经成功开启了。这里面会列出所有可用的接口，比如 /v1/chat/completions，这就是我们等下要用的聊天补全接口。

2.2 理解API的调用方式

模型服务跑起来了，ComfyUI要怎么跟它“说话”呢？它们需要通过HTTP请求来通信。简单来说，ComfyUI的节点会向 http://127.0.0.1:7860/v1/chat/completions 这个地址发送一个POST请求。

这个请求的“身体”（body）里，需要包含一段JSON格式的数据，告诉模型我们想干什么。一个最基本的请求结构如下：

{
  "model": "qwen1.5-1.8b-chat-gptq-int4",
  "messages": [
    {"role": "user", "content": "请描述这张图片的内容。"}
  ],
  "stream": false
}

• model: 指定要使用哪个模型，虽然服务端可能只有一个模型，但最好指明。
• messages: 这是一个列表，里面按顺序存放了对话历史。每一条消息都有 role（角色，如“user”用户或“assistant”助手）和 content（内容）。我们通常只需要构造用户的提问。
• stream: 是否使用流式输出。为了在ComfyUI中处理方便，我们先设为 false，即一次性返回全部结果。

模型处理完后，会返回一个JSON响应。我们最关心的部分在 choices[0].message.content 这个路径下，里面就是模型生成的文本答案。

搞清楚了怎么“呼叫”和“接收”，我们就可以去ComfyUI里搭建桥梁了。

3. 在ComfyUI中创建自定义API节点

ComfyUI的强大之处在于其节点系统，我们可以通过安装自定义节点来扩展功能。对于调用外部API，社区已经有了一些非常优秀的节点，让我们不用从零开始写代码。

3.1 安装必要的自定义节点

这里我推荐使用 ComfyUI-Custom-Scripts 或 was-node-suite-comfyui 这类节点包，它们里面通常包含了用于发送HTTP请求的节点。你可以通过ComfyUI Manager（如果你安装了的话）来搜索和安装，或者直接到GitHub上找到对应的仓库，按照说明克隆到你的 custom_nodes 文件夹里。

安装并重启ComfyUI后，你应该能在节点列表里找到类似 HTTP Request、API Call 或 Fetch Data from URL 这样的节点。我们就要用这个节点来充当“信使”。

3.2 配置API调用节点

让我们从节点菜单中拖出一个HTTP请求节点（具体名字可能因节点包而异）。它的配置面板里通常需要填写以下几项：

1. URL: 这里填入我们模型的API端点地址：http://127.0.0.1:7860/v1/chat/completions
2. Method: 选择 POST。
3. Headers: 我们需要告诉服务器，我们发送的是JSON数据。添加一个Header，键为 Content-Type，值为 application/json。
4. Body/Data: 这是最关键的部分，我们要在这里构造上面提到的JSON请求体。但是，我们的提示词（prompt）可能是动态的，比如来自前一个节点的输出。所以这里不能写死。

这时候，我们就需要用到ComfyUI的文本处理节点了。我们可以先用一个 String 节点或者 Text Concatenate （文本拼接）节点，来动态构造这个JSON字符串。

假设我们有一个输入框节点，让用户输入问题。我们可以这样连接：

• 用户输入节点 -> 文本拼接节点，拼接成完整的JSON字符串 -> HTTP请求节点的Body输入。

一个简单的文本拼接节点配置可能是这样的：将固定部分和变量部分组合。 固定部分：{"model": "qwen1.5-1.8b-chat-gptq-int4", "messages": [{"role": "user", "content": " 变量部分：{来自上一个节点的用户问题} 固定结尾："}], "stream": false}

3.3 解析API返回结果

HTTP请求节点成功调用后，会返回整个响应体，通常是一个字符串。我们需要从这个JSON字符串里，把模型生成的文本“挖”出来。

这就需要另一个节点：JSON Parse （JSON解析）节点。同样，它可能存在于你安装的自定义节点包里。

将HTTP请求节点的输出（Response Text）连接到JSON解析节点的输入。然后在JSON解析节点的“路径”（Path）或“键”（Key）字段里，填入 choices[0].message.content。这样，这个节点就会输出我们想要的纯文本结果了。

至此，一个最基本的“用户提问 -> 模型回答”的ComfyUI工作流就搭建好了。你可以把这个流程保存为一个模板，以后随时调用。

4. 实战：构建多模态AI工作流

有了基础的通义千问API节点，我们就可以玩些更酷的了。下面我分享两个实用的工作流设计思路。

4.1 工作流一：图生文，自动配文案

这个工作流的目的是：自动为生成的图片创作描述文案。

1. 图像生成：工作流的起点，使用Stable Diffusion（SD）系列节点生成一张图片。比如，用一个 KSampler 节点配合你的大模型和提示词，生成一张风景图。
2. 图像编码：ComfyUI本身不能直接把图片传给文本模型。我们需要一个桥梁。这里可以用到 CLIP Vision Encode 节点（如果你的SD模型包含CLIP视觉编码器），或者更通用的方法：将图片保存为Base64编码的字符串。有些自定义节点提供了 Image to Base64 功能。
3. 构造视觉提问：将Base64图片字符串（或CLIP视觉特征，如果API支持）与文本指令拼接，作为通义千问模型的输入。例如，提示词可以是：“这是一张图片的数据：[IMAGE_DATA]。请详细描述这张图片中的场景、物体、颜色和氛围。”
4. 调用通义千问API：将构造好的提示词，通过我们上一节搭建的“API调用+解析”节点链，发送给模型。
5. 输出结果：将模型返回的文本描述，连接到一个 Preview Text 节点进行显示，或者连接到一个 Save Text 节点保存到文件。

这样，当你运行工作流时，它会先生成图，然后自动调用通义千问模型“看图说话”，最后把图和文案都输出给你。非常适合需要批量给图片配文的场景。

4.2 工作流二：文生文，优化绘图指令

这个工作流更侧重于文本的加工和增强，帮助你写出更好的绘图提示词（Prompt）。

1. 原始指令输入：使用一个 String 节点，输入你初步的、可能比较简单的想法。例如：“一只在星空下奔跑的狐狸”。
2. 调用通义千问进行扩展：将你的原始指令稍作包装，发送给通义千问模型。包装的提示词可以这样设计：“你是一个专业的AI绘画提示词工程师。请将以下简单描述扩展为一段详细、富有画面感、包含具体风格和细节的英文AI绘画提示词。用户描述：‘{原始指令}’。请直接输出优化后的提示词，不要有其他解释。”
3. 接收并清洗提示词：通义千问模型会返回一段优化后的英文Prompt。有时它可能会在开头或结尾加上一些多余的话（如“好的，这是优化后的提示词：”）。我们可以再接一个简单的文本处理节点（比如用 Replace Text 节点），去掉这些固定的前缀后缀，得到干净的Prompt。
4. 送入文生图模型：将清洗后的、高质量的Prompt，输入到SD的 CLIP Text Encode 节点（正向提示词），然后进入采样器生成图像。
5. （可选）循环优化：你甚至可以设计一个反馈循环。将生成的图片再用工作流一的方法进行描述，然后对比生成的描述和最初的Prompt，让通义千问模型分析差异并提出进一步的修改建议，实现提示词的迭代优化。

这个工作流相当于给你的ComfyUI配了一个“提示词助理”，能显著提升出图的质量和可控性。

5. 使用技巧与注意事项

在实际搭建和运行这些工作流时，有几个小技巧和坑需要注意一下。

保持服务稳定：确保你的通义千问WebUI API服务在ComfyUI工作流运行期间一直处于开启状态。如果API服务崩溃或中断，ComfyUI的节点调用就会失败。

处理网络延迟：模型推理需要时间，API调用也有网络开销。在ComfyUI中，这些节点执行时会“转圈”等待响应。对于复杂的工作流，要有耐心。可以考虑在HTTP请求节点上设置一个合理的超时时间。

错误处理：自定义的HTTP节点可能不会处理所有错误。如果API返回了错误信息（比如模型忙、请求格式不对），工作流可能会卡住或传递一个错误结果。一个更健壮的做法是，可以尝试使用更高级的自定义节点，或者自己写一个简单的Python脚本节点，在里面用try...except来捕获异常。

提示词工程：通义千问模型的表现很大程度上取决于你给的提示词。在工作流中构造提问时，尽量清晰、具体。对于“图生文”，可以指示它描述“场景、主体、动作、颜色、风格、情绪”。对于“文生文”，明确告诉它你想要什么格式的输出（比如“只输出提示词，不要任何其他文字”）。

资源管理：同时运行ComfyUI和通义千问的API服务，会占用一定的显存和内存。确保你的硬件资源足够。通义千问1.5-1.8B-Chat-GPTQ-Int4版本已经非常轻量，这对大多数有独立显卡的电脑来说应该不是问题。

---

把通义千问接入ComfyUI，就像是在你的可视化工厂里新增了一个智能机器人。它不直接参与“生产”（绘图），但负责“质检”、“设计”和“调度”（描述、优化指令）。这种组合打破了大模型应用“单打独斗”的局限，让你能像搭积木一样，自由组合不同的AI能力。

我上面分享的两个工作流只是抛砖引玉。你可以基于这个思路，创造出更多玩法：比如用通义千问分析用户评论情感，再生成对应情绪的图片；或者构建一个多轮对话界面，在ComfyUI里实现更复杂的交互逻辑。可视化编程的魅力就在于，一旦基础节点搭建好，复杂的逻辑就变成了直观的连线，创意实现的路径变得清晰可见。

动手试试吧，从复制一个简单的工作流开始，慢慢调整，加入自己的想法。你会发现，构建一个属于自己的智能应用，并没有想象中那么难。

---

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。