两个本地模型、三条提示词，红围巾为什么还是画不出来？

一条红围巾卡在池塘边的芦苇里，这是故事书里最该被画出来的那一幕。可当本地图像模型真的动手去画，围巾却消失了。

这不是一次随手的测试。有人用 llamadart 的 ImageGenerationEngine 做了一个独立实验，想看看本地模型能不能为 Llama Village 的故事书补上一张插图。实验的样本事件很小：一条红色羊毛围巾，缠在村庄池塘边的绿色芦苇丛中。

提示词是用 Dart 直接拼出来的，没有语言模型参与改写。记忆字段里只放了两样东西——主体是"一条卡在绿色芦苇中的红色羊毛围巾"，地点是"一个小村庄的池塘边"。拼进提示词的还有"雨夜""温和的故事书插画风格""不要文字"。

两个模型，同一套题

引擎在本地跑的是 stable-diffusion.cpp。第一次尝试选了 SDXS：单个模型文件，约 683 MB，配方只用一步生成。

实际输出是 SDXS Q8_0，512 × 512，一步，guidance 为 1，种子 42。画面里有芦苇、有水、有房子、有雨，氛围是有的。但围巾认不出来——而围巾恰恰是这个场景被收进故事书的理由。

换个更亮的场景会不会好一点？只把"雨夜"改成"晴朗的早晨"，模型、种子、尺寸和其他设置全部不动。天空亮了，雨没了，围巾还是不见。

固定种子是为了在这个设置下比较不同提示词，它并不锁定构图，也不保证跨运行时版本和设备得到完全相同的像素。天气变了，丢失的物体没有回来。

第三次，干脆让模型把围巾直接放到镜头前：一条红色针织羊毛围巾缠在绿色芦苇中，围巾占满前景，背后是池塘水面，雨夜，温和的故事书插画，不要文字。

这次有了能认出来的红色针织物。但同时也多出了额外的绿色布料，雨也不明显。提示词起了作用，却没有让画面变成一份精确记录。

这就是故事书的边界：日志负责说发生了什么，插画负责想象它当时看起来是什么样。如果游戏需要准确的角色面孔、位置，或者某个事件的证据，那就该保留截图。

换更大的模型，结果变了吗

也许更大的模型会更贴近场景。同样的三条提示词，换成 SD-Turbo Q8_0 加 TAESD 再跑一遍：512 × 512，一步，guidance 为 1，种子 42。TAESD 是文档配方里的小型解码器，所以这相当于比较两套完整配方。

SD-Turbo 的雨夜版本，前景芦苇更分明，但依然没有清晰可辨的围巾，雨也比 SDXS 那张更不明显。晴朗早晨版本里，芦苇丛中出现了红色形状，但读不出是一条羊毛围巾，天气变化也很微弱。特写版本在画面两侧都出现了能认出的红色针织物，却没有做到"一条围巾占满前景"。

就这个故事书场景而言，作者更偏好 SDXS 更柔和的风格。两个模型都不能可靠地遵循每一个细节。这是针对一个种子下三条提示词的视觉判断，不是通用的质量排名。

接近两倍的进程内存、三倍的模型存储，仍然没能换来一张清晰呈现事件的画面。这个原型里，作者会继续用 SDXS。这个选择只针对这些场景和设置；更多 SD-Turbo 步数或它的完整解码器，可能会改变结果。

速度与内存的实测数字

测试环境是 M4 Max、64 GB 内存、Metal、Dart 3.13.5、llamadart 0.11.1。每套配方都在全新进程中单独运行，文件已缓存。先对三条提示词做一轮预热，再测三轮，每套配方共九次生成。

• 生成耗时：SDXS 为 0.383–0.387 秒；SD-Turbo 为 0.545–0.622 秒。计时在 task.result 处结束，不含 PNG 编码和磁盘写入，也不含下载和模型加载。
• 内存：进程 RSS 每 20 毫秒采样一次，覆盖初始化、加载、生成和保存。这测的不是设备或 GPU 的总内存。
• 条件：渲染器关闭，跑在开发机上，而不是隔离的基准测试环境。

对比用的是 TAESD，不是 SD-Turbo 的完整 VAE。四步生成和完整解码器都没有测。两个模型版本和解码器版本都固定在可运行程序里。

想自己试这个围巾场景，程序遵循四个调用：先检查运行时，再加载固定的 ModelSource，然后启动任务并监听进度，最后等待结果并把像素保存为 PNG。task.events 报告提示词编码、采样、解码等阶段，它不流式输出成品图片；要拿图片或失败信息，得等 task.result。程序在 finally 里取消事件订阅，并在三张图都完成后释放引擎。

对 SDXS，要显式使用 steps: 1 和 guidanceScale: 1。这些设置属于这个蒸馏模型；把它们照搬到任意图像模型上，并不是一个有意义的比较。