如果你以为“AI绘画跑在本地”最大的门槛是显卡那其实只猜对了一半。真正让人头疼的是模型能出图但它不一定听你的话。你明明说的是“雨夜霓虹城、戴帽子的侦探、赛博朋克风”它给你拼出一副元素完全不在一个次元的画面。折腾下来我的结论是问题不在扩散模型笨而在“你脑子里那幅画”和“模型真的能看懂的提示词”之间缺了一层翻译。这篇文章要聊的就是怎么用 FastAPI、ollama、diffusers 三件套把本地文生图接口完整搭起来并且让 AI 绘画“更听话”。核心思路其实很朴素让 ollama 跑一个本地大模型负责把你随口说的人话转成绘图模型真正能理解的提示词让 diffusers 加载本地扩散模型负责正经出图最后用 FastAPI 把这些串成一个带接口的服务。适合正在做本地 AI 工具、想批量出图、或者准备把自己的业务系统接入 AI 绘画能力的开发者参考。1. 先理清楚AI 绘画“不听话”的问题到底出在哪很多人一上来就抱怨模型画得差但真实情况往往不是模型能力不够而是指令传达有问题。你给 Stable Diffusion 撒了一句话它只能从这句话里硬猜你想要什么猜错了画面自然就跑偏。1.1 扩散模型读的是“提示词”不是你的人话Stable Diffusion 这类扩散模型本质上是把一段文本编码成条件向量再引导图像生成过程。它吃的是一个结构相对明确的描述画面里有什么主体、什么场景、什么光线、什么镜头语言以及一定不能出现什么。而普通人描述需求时给的往往是“感觉型”的话要有气氛、要酷一点、要那种赛博朋克的感觉。问题就在这扩散模型对“感觉”的理解非常有限它更擅长处理“具体元素”。你可以让 SD 画“一名戴软呢帽的侦探站在霓虹灯下的雨夜街道”但如果你只给它“赛博朋克侦探雨夜”结果大概率是元素乱炖——侦探不像侦探雨夜不像雨夜赛博朋克更像是霓虹灯管批发市场。这也是为什么很多人觉得 AI 绘画“不听话”不是它故意跟你对着干是它真的读不懂你的潜台词。你想要的是一个完整的画面构想你给的却是一个模糊的关键词。这中间有巨大的信息损耗。1.2 加一层 LLM 当“翻译官”思路就通了既然扩散模型不懂人话那就在它前面放一个懂人话的模型。这就是 ollama 在这套架构里的角色让本地大语言模型去理解你的意图再把它翻译成扩散模型能执行的“需求文档”。我实际搭起来的链路是这样的用户的一句话 → FastAPI 接收请求 → 调 ollama 的对话接口让本地大模型生成一份结构化绘图指令 → 指令里包含正面提示词、负面提示词、画面尺寸、步数、采样参数 → 把这份指令交给 diffusers 里的扩散模型 → 模型出图FastAPI 把图片返回给调用方用生活化的比喻解释LLM 是“甲方翻译”专门把含糊的需求整理成需求文档扩散模型是“乙方画师”拿到需求文档按图施工FastAPI 是“前台”统一接待所有请求。以前你是直接把甲方原话丢给乙方现在多了一个能听懂人话、还会写需求文档的中间人出图自然“听话”得多。1.3 这套方案适合谁不适合谁先泼盆冷水如果你追求的是顶级画质、成熟的工作流、或者一大堆微调模型组合那本地跑 ComfyUI / WebUI 加手动调参可能更直接。这套 FastAPI ollama diffusers 的组合优势不在“画得最好”而在“能编程、能集成、能批量”。它适合三种场景一是你想把 AI 绘画做成内部服务给其他业务系统调用二是你想对“自然语言 → 绘图指令”这条链路做批处理或自动化改造三是你想在本地完全离线跑通“理解需求 出图”的完整闭环。反过来如果你只是偶尔玩票出图图形界面的 WebUI 更省事不值得为了接口化付出额外复杂度。2. ollama让本地大模型先当一把“提示词翻译官”ollama 在这套架构里的任务非常明确它负责把用户的自然语言输入改写成一串扩散模型能读懂的结构化指令。这一层做得好不好直接决定最终出图“听不听话”。所以模型选型和提示词设计都不能太随意。2.1 模型怎么选显存决定天花板我在实际项目中优先推荐 qwen 系列。7B 指令版量化后在 8G 显存上跑得很流畅如果机器显存到了 16G 以上可以上 14B 级别中文理解力和风格词汇的把握都会明显高一档。有朋友问过 deepseek-r1 系列行不行。说实话绘图指令解析这件事不需要模型“深度推理”r1 那种带思考链的特性反而麻烦——你想让它快点输出个 JSON它先给你推理一大段。也不是不能用但通常要在提示词里明确禁止输出思考过程才能稳定拿到干净的 JSON。所以我的结论是这层任务选 chat 模型比选推理模型更合适。另外模型参数大小和响应速度的平衡很实际。7B 量化在普通显卡上解析一句话通常两三秒内能返回14B 会更慢但对中文意图的捕捉更好。如果跑批处理耐得住等优先选大一点的模型翻译质量更稳。2.2 让 LLM 输出 JSON别给它自由发挥的空间“更听话”的第一步是让 LLM 的输出格式固定下来。我的做法是给 ollama 配一个强约束的 system prompt明确规定必须输出 JSON并且把字段和取值范围都写清楚。比如这样{ positive_prompt: 描述画面主体、场景、光线、构图、风格的详细英文提示词, negative_prompt: 低质量、畸形、多余元素等负面提示词, width: 512, height: 512, steps: 20, guidance_scale: 7.5, seed: 42 }为什么要用 JSON很简单FastAPI 拿到之后可以直接解析成字典再映射到 diffusers 的参数上去链路短、不容易出错。如果你让模型自由发挥输出一段自然语言的绘图描述那后面还得再套一层解析逻辑而且不同时候吐出来的结构还不一样调试起来能把人逼疯。我实际用的 system prompt 会明确写你只输出一个 JSON 对象不要解释、不要代码块标记、不要多余的对话。等模型跑上一次把输出样例拉出来看看如果它还是不老实加了一堆说明文字你就在提示词里再补一句“任何非 JSON 字符都会导致系统故障”。对大多数指令模型来说这招很管用。2.3 调用细节直接用 OpenAI 兼容接口最省事ollama 本身带 HTTP 接口而且兼容 OpenAI 的接口格式。这意味着你可以直接拿 openai 库去连本地服务一行客户端代码都不用额外封装。举例from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:11434/v1, api_keyollama ) resp client.chat.completions.create( modelqwen2.5:7b, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: 雨夜霓虹都市戴帽子的侦探赛博朋克风}, ], temperature0.7, top_p0.8, )两个参数值得注意。temperature 我一般控制在 0.6 到 0.8太高会让 LLM 发挥过头把好好的 prompt 改得面目全非太低又会导致遣词造句太死板画面缺细节。top_p 设置 0.8 左右配合 temperature 用能保证输出质量稳定。这层的目标不是让 LLM 当艺术家而是让它的输出尽量可复现、可预期。如果不想引入 openai 库直接用 requests 打/api/chat或者/api/generate也行返回结构解析稍麻烦一点而已。我在生产项目里还是推荐 OpenAI 兼容接口后续替换成本低哪天你想从 ollama 切到别家本地推理框架代码改动量会小很多。3. diffusers把出图引擎调教到“指哪打哪”有了 LLM 输出的结构化指令接下来就是 diffusers 的活真的把画面渲染出来。这一步最容易出问题的不是“能不能跑”而是“跑出来是不是你想要的”。3.1 本地扩散模型怎么选从 SD 1.5 起步不容易劝退diffusers 可以加载多种开源模型。我最常用的两条线Stable Diffusion 1.5 和 SDXL。SD 1.5 的优点是生态成熟、显存门槛低、出图速度快4G 到 6G 显存就能跑得很顺畅模型文件也不大。缺点是画质上限一般分辨率默认 512细节丰富度不如 SDXL。SDXL 默认 1024 分辨率画质和构图能力明显更强但对显存的要求也水涨船高8G 显存是起步想舒服跑得 12G 以上。我的建议是第一次跑通链路先用 SD 1.5把接口流程调顺再换 SDXL 提升画质。很多人一上来就上 SDXL发现加载慢、显存爆、推理时间长直接放弃治疗其实大可不必。先让流程转起来再优化画质这种推进节奏才稳。3.2 加载与推理设置别让默认配置拖后腿diffusers 加载 SDXL 的代码大致是这个样子from diffusers import StableDiffusionXLPipeline import torch pipe StableDiffusionXLPipeline.from_pretrained( stabilityai/stable-diffusion-xl-base-1.0, torch_dtypetorch.float16, variantfp16, use_safetensorsTrue, ) pipe.enable_model_cpu_offload()两个细节值得说。一是torch_dtypetorch.float16用半精度加载能大幅降低显存占用画面质量损失在多数场景下几乎可忽略。二是variantfp16和use_safetensorsTrue一个负责下载对应的精简权重文件一个保证加载格式安全初次下载都会省不少时间和磁盘。显存不够的小机器重点看enable_model_cpu_offload()。它会把模型的不同模块按需在 CPU 和 GPU 之间搬移跑 SDXL 时能让边缘显存的机器也动起来。代价是速度变慢每一次切换模块都有开销。显存够的话就不需要这行直接pipe.to(cuda)更快。还有一个很容易忽略的点首次加载模型要下载权重文件、把模型读进内存耗时可能几十秒甚至几分钟。所以我一般会在服务启动时把 pipeline 初始化好而不是每次请求来了再加载。同样ollama 那边首次请求也有模型加载延迟服务预热之后就舒服了。3.3 出图参数与“听话”的对应关系参数映射是整个链路里最见功夫的部分。LLM 输出的 JSON 字段和 diffusers 的生成参数要一一对应我整理了一张常用的映射表LLM 输出字段diffusers 参数典型默认值说明positive_promptprompt无正面提示词画面内容描述negative_promptnegative_prompt无负面提示词排除烂图元素width / heightwidth / height512 / 512出图尺寸SDXL 用 1024stepsnum_inference_steps20采样步数越多越细腻但更慢guidance_scaleguidance_scale7.5提示词服从度越高越“听话”seedgenerator42随机种子固定后可复现其中guidance_scale就是“听话程度”最直接的旋钮。设置太低模型会自由发挥画面可能很有创造性但跟你的描述关系不大设置太高画面会死板地贴在提示词上色彩容易发灰发硬。7.5 左右是个比较均衡的值追求更听话可以调到 8 到 9但不建议超过 12。steps和seed也很有讲究。SD 1.5 用 20 步基本够用再往上收益递减SDXL 建议 25 到 30 步。seed 固定之后同一份提示词每次出的图都一致这对调试接口非常有用——你能分清到底是参数问题还是随机因素。生成代码核心就几行result pipe( promptprompt_spec[positive_prompt], negative_promptprompt_spec[negative_prompt], widthprompt_spec[width], heightprompt_spec[height], num_inference_stepsprompt_spec[steps], guidance_scaleprompt_spec[guidance_scale], generatortorch.Generator(cuda).manual_seed(prompt_spec[seed]), ) image result.images[0]4. FastAPI把“翻译官 画师”串成一个正经服务前面的部分解决的是“怎么算得对”FastAPI 部分解决的是“怎么给别人用”。一套本地接口要真跑起来目录结构、路由设计、并发处理都不能含糊。4.1 项目目录别拍脑袋先定结构FastAPI 项目最忌讳一上来就单文件堆到八百行。我的划分方式是这样app/ main.py # FastAPI 入口 routers/ generate.py # /v1/generate 路由 services/ llm.py # ollama 调用封装 diffusion.py # diffusers 生成封装 schemas/ request.py # 请求体模型 response.py # 响应体模型 output/ # 生成的图片落地目录 models/ # 本地权重文件 requirements.txt理由很直接路由层只负责参数校验和结果返回服务层负责真正的业务逻辑数据模型用 Pydantic 定义清楚边界。以后你想把 ollama 换成其他推理框架只需要改services/llm.py内部实现想换出图模型改services/diffusion.py。接口层完全不用动这就是分层带来的可维护性。4.2 主路由接收一句话返回一张图请求体和响应体设计尽量简单。请求就传一个文本再加几个可选的覆盖参数例如用户想临时指定尺寸或种子。from fastapi import FastAPI from pydantic import BaseModel app FastAPI(titleLocal Text-to-Image API) class GenerateRequest(BaseModel): text: str width: int | None None height: int | None None seed: int | None None app.post(/v1/generate) async def generate(req: GenerateRequest): prompt_spec await llm_service.parse_instruction(req.text) if req.width: prompt_spec[width] req.width if req.height: prompt_spec[height] req.height if req.seed is not None: prompt_spec[seed] req.seed image await diffusion_service.generate(prompt_spec) return {image: image_b64, prompt: prompt_spec, seed: prompt_spec[seed]}响应里我会同时返回imagebase64 编码的图片、promptLLM 生成的完整指令和seed。这很有用调用方不仅拿到了图还能看到模型到底把你的话理解成了什么。出图不满意时调试成本直线下降。4.3 别让接口卡死生图任务不能直接丢进 async 路由这是最容易踩的坑。diffusers 推理是典型的 CPU/GPU 密集型任务如果你在 async 函数里直接同步调用它会阻塞整个事件循环服务同时只能处理一个请求其他人全部排队等到天荒地老。我的做法是封装成阻塞函数再丢进线程池执行import anyio async def generate_wrapper(prompt_spec: dict): return await anyio.to_thread.run_sync( pipe, prompt_spec )如果任务真的很重比如单次生成要几十秒更稳妥的方案是引入任务队列请求进来先登记任务返回 task_id调用方轮询/v1/tasks/{id}获取结果。虽然接口变复杂了但用户体验好得多还能天然支持批量任务。我自己的项目里生成长图时就是这么干的。4.4 跨域、日志、产物落地这些“上了生产才发现”的细节几个小问题每个都能让你调试到怀疑人生。第一CORS。如果你有前端页面在浏览器里调接口FastAPI 默认不允许跨域请求需要在入口处配CORSMiddleware否则前端只能靠代理绕过去。第二日志。生图任务耗时较长强烈建议在关键节点打日志收到请求、LLM 返回指令、开始推理、推理完成。这样一来出问题能直接定位是哪个环节慢了而不是两眼一抹黑。第三产物落地。生成结果除了返回给调用方我一般还会在output/目录按时间戳存一份。这样后续想看历史出图效果、做对比分析都有原始素材可查。第四健康检查。加一个/health接口返回当前 ollama 连接状态和模型是否已加载。部署到后台跑批处理时这个接口能让你快速判断服务是否正常而不是等到超时才发现进程早挂了。5. 从零搭建踩过的坑按真实排查顺序讲整个流程跑通我反复折腾了不止一次。有几个地方如果你提前知道能省非常多时间。5.1 ollama 下载慢、模型拉不下来怎么办这是个能劝退不少人的问题。ollama 的官网和默认模型仓库都在国外网络不好的时候安装包下载到一半断掉、模型拉取提示连接超时都是家常便饭。我的处理方式是安装包不直连官网下找国内镜像源拿安装包模型拉取时给 ollama 配置国内镜像地址比如设置OLLAMA_API_BASE_URL这样的环境变量指向镜像。如果你在公司内网也可以自己搭一个模型仓库缓存团队共享一套权重省得每个人各自下载。还有一点必须强调从网上找离线安装包或者别人分享的模型包下载完之后务必核对哈希值。本地跑这类工具本来就涉及模型加载跟代码执行用来历不明的文件风险很高多花一分钟验一下哈希比后面出了安全问题再后悔值得多。5.2 ollama 报 500 Internal Server Error: llama-server process 的排查链路如果你跑ollama run qwen2.5:7b直接给我抛这个错别慌照这个顺序排查。先看是不是显存不够。模型默认会占用显存如果你的显存本来就被其他程序占着llama-server 进程启动就会失败。用nvidia-smi看一眼显存余量再查ollama ps看有哪些模型在跑把不用的先停掉。再看num_ctx是不是设置太大。上下文窗口越长占用的 KV cache 越多。有些模型配置文件里默认值很高显存小的机器扛不住可以在模型配置里把num_ctx调小比如 4096 甚至 2048对绘图提示词解析来说完全够用。如果都不是试试把 ollama 服务以前台模式跑一遍ollama serve这个命令的好处是能看到完整日志错误信息比后台模式具体得多。我碰到过一次模型文件损坏就是在前台日志里看到加载 mismatch 才定位出来的。修复方式也简单删掉本地模型重新拉一遍。5.3 diffusers 和 torch 的版本、缓存路径问题diffusers 版本迭代很快不同版本对 torch 的要求不一样。最常见的坑是你装了一个新版 diffusers但 torch 是旧版加载模型时直接报错cannot import name xxx from diffusers。我建议安装时直接按官方文档给的版本组合装不要只锁 diffusers 的版本。还有一个隐藏很深的问题Hugging Face 的模型默认缓存到你的用户目录下比如 Windows 上的 C 盘。模型权重文件动辄几个 GC 盘被塞满只是时间问题。我的做法是显式设置缓存路径export HF_HOME/path/to/your/hf_cache export HF_HUB_CACHE/path/to/your/hf_cache写到启动脚本里让权重文件落在数据盘或独立目录。这个问题在“安装到 D 盘”这类诉求里特别常见提前设置好能省掉后续清理磁盘的麻烦。5.4 还有几个小坑每个都让我白调半天FastAPI 默认跑在 8000 端口ollama 默认跑在 11434如果本机有其他服务占了端口起服务时会报错。先查端口再排查业务逻辑能省很多时间。返回图片时base64 字符串可能会非常大。一张 1024 分辨率出图转 base64 也要几 MB网络传输慢不说前端处理也卡。我的做法是先把图片转成 JPEG 并且适当压缩再 base64 编码。尺寸和画质损失都不大接口响应速度却快不少。如果你用的是 macOS 或者 Windows 的 AMD 显卡请一定要先去查目标模型和 torch 对你的硬件支持到什么程度。CPU 跑不是不行SD 1.5 出张 512 图可能要一两分钟SDXL 就更久。接口能通、效果能用但性能预期要对齐别到部署时才发现机器扛不住真实负载。6. 让“听话”落到实处一次实测对比与后续扩展架构讲完坑也排完最后聊点实际的体验。这套系统搭好之后到底比直接跑 diffusers 听话多少6.1 同一个需求直接跑 vs LLM 改写后跑我拿“雨夜的霓虹都市戴帽子的侦探赛博朋克风”这句话做过对比。直接作为 prompt 丢给 SD 1.5出来是这么个感觉画面确实有夜晚和霓虹但侦探和赛博朋克元素经常对不上号有时连“戴帽子”这种明确要求都表达不清。走了 ollama 改写之后LLM 给出的正面提示词会变成类似这样cinematic wide shot of a detective in a fedora standing on a rain-soaked neon-lit city street at night, reflections on wet asphalt, cyberpunk aesthetic, moody teal and magenta lighting, futuristic billboards in background, highly detailed, dramatic shadows, film grain负面提示词也会带上一串“low quality, blurry, distorted face, extra limbs, bad anatomy”这类词汇。把结构调整成这个粒度扩散模型“听懂”的概率就大多了。实测下来画面完整度和风格一致性提升非常明显。这还没算上 LLM 能根据用户描述自动补充光线、构图这类细节——靠人工想 prompt 的时候这些经常被漏掉。6.2 把“听话”继续往深了做几个我后面想折腾的方向链路跑通只是一个起点。大模型加扩散模型的组合可以扩展的空间其实很大。一个是多轮对话式出图。用户先描述需求出图后如果觉得不够满意直接回复修改意见LLM 把修改意见和之前的 prompt 一起融合输出一版新指令。这就相当于给 AI 绘画加了一个“实时改稿”的对话窗口比反复手动改 prompt 自然得多。一个是把 RAG 接进来。你可以把不同风格、不同画师风格的描述词存到向量库里用户说“我想要莫奈那种朦胧的光线感”系统先去检索对应的风格描述再交给 LLM 融合进提示词。这样“听话”就不只是字面理解了带上了风格知识库的加持。还有一个很实际的场景是批量生成和定时任务。借助 FastAPI 的接口能力和上面的任务队列把一批需求文本排队逐个出图完全可以当一个自动化的“灵感板”来用。我准备把历史生成记录和对应的 seed 存起来后面就能做“看着满意就锁定 seed 复用”的功能让每次出图都稳定可回溯。我个人实际用下来的体会是这套架构最有价值的地方不是某个单点技术多前沿而是它把“理解需求”和“渲染画面”这两件事拆开了各用各的擅长模型去处理再通过一个干净的服务层组合起来。你想要的每一次“更听话”其实都是这一层翻译和调度在起作用。如果哪天你也发现 AI 绘画总是“答非所问”不妨先别急着换更大的模型试试在这条链路上多下功夫。