简答：选择在你的 Web 应用延迟和重试预算内达到实测质量门槛的模型，并保持应用边界可移植。DALL-E 3、SDXL 和 Flux 是待测候选项，不是现成结论。对于把供应商发票文本转成可视化教学材料的教育科技系统，运营风险通常是任务缓慢或重复执行，而不是演示图片不够惊艳。
我曾因 cron 和队列基础设施中的任务遗漏和重复投递而被呼叫处理故障。这改变了问题的重点。起初，我把演示成功当作模型已准备就绪的证据；缺少的是围绕模型的队列契约。模型在笔记本中能生成精美结果，如果它的超时行为、请求限制或部署假设让队列难以运维，它仍可能是错误的依赖项。我会先明确模型周边的契约：输入、输出、截止时间、重试策略、幂等键，以及记录在案的质量评估。
演示是最容易的部分。
比较名称之前，先定义图像任务。供应商发票可能会提供文本，用来制作面向学生、解释“净额”“税款”或“到期日”的简短视觉材料。图像应清晰易读、切题，并适合目标受众。这些是验收检查项，与通常对照片写实效果的偏好不同。
构建一套小型固定评测集。纳入普通提示词、长提示词、OCR 产生的不规则换行，以及不得泄露发票标识符的提示词。记录提示词版本、模型标识符、部署模式、请求时间戳、响应状态和审核结果。不要只看单一平均分：如果某个模型在四个提示词上表现出色，却无法处理一个必需版式，那它就没完成任务。
同一项测试还需要设定截止时间。在 Web 边界测量得到可用响应所需的时间，而不只是服务提供方报告的生成时间。记录 p50 和 p95 延迟、超时率、重试次数，以及无需人工重新生成即可被接受的结果比例。这里的质量和速度相互关联：如果快速生成的结果还需要重试两次，那么对面向学生的工作流来说就算不上快。
| 决策信号 | 记录内容 | 拒绝条件 |
|---|---|---|
| 质量 | 按提示词类别记录审核结果 | 必需的发票说明无法使用 |
| 速度 | p50、p95 和超时率 | 未能满足约定的请求截止时间 |
| 可移植性 | 适配器、部署模式和版本 | 更换服务提供方的影响渗入队列逻辑 |
| 可靠性 | 429 响应、重试和重复检查 | 重试可能导致交付第二份素材 |
这张表是检查清单，不是会掩盖严重失败的评分卡。即使平均表现不错，任何一个不可接受的必需输出也应明确列出。
比较 DALL-E 3、SDXL 和 Flux 时，测试中应明确显示部署拓扑。托管端点和自管理运行时面临的故障情况不同。前者可能让容量管理和打补丁成为他人负责的事项；后者可能让你更好地控制部署位置和版本，同时也意味着容量、图像依赖项和升级都由你负责。模型名称本身无法决定这种取舍。
让应用依赖一个精简接口。流水线的其他部分不应关心候选模型名为 DALL-E 3、SDXL 还是 Flux。它们应收到带有稳定状态、内容类型、尺寸和来源信息的结果。这样也能实现受控回退：只有策略允许时才回退，并记录实际生成素材的候选模型。静默回退会让质量分析失去可靠性。
用 Go 实现的一个实用边界如下：
type ImageRequest struct {
\tPrompt string
\tIdempotencyKey string
\tDeadline time.Duration
}
type ImageResult struct {
\tURI string
\tModel string
\tStatusCode int
}
type Generator interface {
\tGenerate(context.Context, ImageRequest) (ImageResult, error)
}
func GenerateOnce(ctx context.Context, g Generator, req ImageRequest) (ImageResult, error) {
\tif req.IdempotencyKey == "" {
\t\treturn ImageResult{}, errors.New("missing idempotency key")
\t}
\tcallCtx, cancel := context.WithTimeout(ctx, req.Deadline)
\tdefer cancel()
\treturn g.Generate(callCtx, req)
}
这个接口刻意保持简单。time.Duration、context.Context、errors和服务提供方适配器应放在完整的软件包中；关键在于，队列工作进程对这项工作只需使用一个截止时间和一个标识。适配器应在调用前持久化幂等键，让已完成的结果可以安全重放；对于结果未知的请求，除非适配器能证明重放安全，否则应避免重试。
HTTP 429 表示服务器在给定时间内收到的请求过多；这是一个调度信号，并不说明提示词有问题。若服务器提供了重试延迟，应遵循该延迟；同时限制指数退避的上限，并为任务的总存续时间设限。重试时间超过用户请求期限，就会变成队列负担。
为交互式请求和后台发票任务设置不同的预算。课堂流量激增不应占满所有工作进程槽位，以致夜间导入任务无法完成。添加队列级并发限制，并分别公开429、超时和上游错误的计数。一个笼统的“生成失败”指标会掩盖需要采取行动的具体情况。
幂等性是防护措施。任务键应标识语义上的素材，例如发票摘要、提示词修订版和目标尺寸。每次重试都生成随机键，会把暂时性超时变成重复图像。若稳定键未包含提示词修订版，提示词有意更改后就可能返回旧素材。这两种错误都很容易发生，交付后却很难排查，代价也很高。
选择在满足 p95 截止时间、重试预算、安全审核和你实际能够承担的运维责任后，在固定验收集上通过率最高的候选模型。之后，只要模型版本、提示词模板、部署模式或队列策略发生变化，就重新测试。保留未通过的样本。它们比满是成功请求的仪表板更有用。
这种方法不能原样用于由人工挑选每张图像的艺术指导工作流，也不能原样用于没有截止时间且审核资源无限的批处理任务。在这些情况下，延迟和自动验收的重要性可能较低。不过，对于关联供应商发票处理、面向学生的 Web 应用，可移植性是一种可靠性属性：它让工作流可以替换，同时保持验收契约稳定。
最终产物应是决策记录，而不是永久排名。写明测试集、门槛、测量时段、部署模式、回退规则和负责人。出现下一个候选项时，按照同一记录重新测试。
-
- OWASP，《大型语言模型应用十大风险》：https://owasp.org/www-project-top-10-for-large-language-model-applications/