🔥 釋出 FLUX-Juiced：最快的影像生成端點（速度提升 2.6 倍）！
在過去幾年中，影像生成模型變得異常強大——但也**異常緩慢**。像 FLUX.1 這樣擁有龐大架構的模型，即使在 H100 等尖端 GPU 上，每張影像也通常需要 6 秒以上。雖然壓縮是一種廣泛應用的技術，可以減少推理時間，但其對質量的影響往往不明確，因此我們決定做兩件事。
- 我們構建了 **FLUX-juiced**——目前最快的 FLUX.1 端點。它現在已在 Replicate 上線。🚀
- 我們建立了 **InferBench**，透過對 FLUX-juiced 與 Replicate、Fal、Fireworks 和 Together 等不同推理提供商提供的“FLUX.1 [dev]”端點進行全面基準測試。它現在已在 Hugging Face 🤗 上線。
⚡ 什麼是 FLUX-juiced？
FLUX-juiced 是我們最佳化過的 FLUX.1 版本，其推理速度比官方 Replicate API **快 2.6 倍**，同時**不犧牲影像質量**。
其內部使用了自定義組合：
- 用於最佳化執行路徑的**圖編譯**
- 用於重複操作的**推理時快取**
我們在此不深入探討內部細節，但核心思想是：
我們將編譯器級別的執行圖最佳化與選擇性快取重度操作（如注意力層）相結合，使推理能夠跳過冗餘計算，同時不損失任何保真度。
這些技術透過 **Pruna Pro** 管道進行通用化和即插即用，並且幾乎可以應用於任何基於擴散的影像模型——而不僅僅是 FLUX。對於免費但仍然非常強大的模型，您可以使用我們的開源解決方案。
🧪 立即試用 FLUX-juiced → replicate.com/prunaai/flux.1-juiced
📊 InferBench：比較速度、成本和質量
為了證實這一點，我們對 FLUX-juiced 與以下提供商提供的“FLUX.1 [dev]”端點進行了全面基準測試：
- Replicate: https://replicate.com/black-forest-labs/flux-dev
- Fal: https://fal.ai/models/fal-ai/flux/dev
- Fireworks AI: https://fireworks.ai/models/fireworks/flux-1-dev-fp8
- Together AI: https://www.together.ai/models/flux-1-dev
所有這些推理提供商都提供了 FLUX.1 [dev] 實現，但它們並不總是會說明後臺使用的最佳化方法，而且大多數端點具有不同的響應時間和效能指標。
為了進行比較，我們對不同提供商使用了相同的生成配置和硬體。
- 28 個推理步驟
- 1024×1024 解析度
- 引導比例為 3.5
- H100 GPU (80GB)——僅由 Replicate 報告
儘管我們確實使用此配置和硬體進行了測試，但所應用的壓縮方法也適用於不同的配置和硬體！
雖然此基準測試的完整結果已釋出在 Hugging Face 🤗 上的 InferBench 空間中，但您將在此部落格中瞭解主要發現。
🗂️ 資料集和基準測試
為了進行公平比較，我們決定使用包含提示、影像和人工標註的資料集和基準測試，這些資料集和基準測試旨在以標準化方式評估文字到影像生成模型的能力。
| 名稱 | 描述 | 原始碼 |
|---|---|---|
| DrawBench | 一套全面的提示集，旨在評估文字到影像模型在渲染顏色、物體數量、空間關係和場景文字等各種能力方面的表現。 | 資料集、論文、 |
| HPSv2 | 一個大規模資料集，捕獲了來自不同來源影像的人類偏好，旨在評估生成影像與人類判斷的一致性。 | GitHub，論文 |
| GenAI-Bench | 一個旨在評估多模態大型語言模型判斷 AI 生成內容質量能力的基準，透過比較模型評估與人類偏好進行判斷。 | 資料集、GitHub、網站、論文 |
| GenEval | 一個以物件為中心的框架，用於使用現有物件檢測方法評估文字到影像的對齊，以生成細粒度的例項級分析。 | GitHub，論文 |
| PartiPrompts | 一套包含 1600 多個英語提示的豐富集合，旨在衡量模型在各種類別和挑戰方面的能力。 | 資料集、GitHub、網站、論文 |
📐 指標和評分
除了資料集之外，我們還使用了各種評分標準來定量、客觀地評估文字到影像生成模型在影像質量、與提示的相關性以及與人類偏好的一致性等方面的效能。
| 名稱 | 描述 | 原始碼 |
|---|---|---|
| ImageReward | 一個獎勵模型，透過 13.7 萬次人工偏好比較進行訓練，用於評估文字到影像的生成質量。它作為評估合成質量的自動化指標。 | 論文、GitHub |
| VQA-Score（模型='clip-flant5-xxl'） | 一個視覺-語言生成模型，針對影像-文字檢索任務進行微調，提供反映影像與文字描述之間對齊程度的得分。 | GitHub，論文 |
| CLIP-IQA | 一個基於 CLIP 模型的影像質量評估指標，透過計算影像與預定義提示之間的餘弦相似度來衡量視覺內容質量。 | 論文、TorchMetrics |
| CLIP-Score | 一個無參考指標，使用 CLIP 模型評估生成標題與影像內容之間的相關性，以及文字或影像之間的相似性。 | 論文、TorchMetrics |
| CMMD | CLIP 最大均值差異 (CMMD) 用於評估影像生成模型。CMMD 比 FID 更優秀的指標，並試圖緩解 FID 長期存在的問題。 | GitHub，論文 |
| ARNIQA | 一種無參考影像質量評估指標，可預測影像的技術質量，與人類判斷高度相關，已包含在 TorchMetrics 庫中。 | 論文，TorchMetrics |
| 清晰度（拉普拉斯方差） | 一種透過計算拉普拉斯方差來量化影像清晰度的方法，其中方差越大表示影像越清晰。 | 部落格文章，部落格文章 2 |
🏆 結果
🕷️ 比較概覽
如上所述，我們評估了模型在各種基準和指標下的使用情況。下圖顯示了我們發現的比較概覽。
FLUX-juiced 顯然是領頭羊！雖然該模型實現了可比的質量效能，但其效率更高：每美元可以生成 180 張影像，每張影像僅需 2.5 秒，而基礎模型則需要 6 秒。
🏎️ 速度比較
大多數壓縮技術會權衡推理速度和質量。為了找出 Flux-juiced 端點在這個權衡中的位置，我們根據測量的推理速度繪製了不同的質量維度。
各種 FLUX-juiced 版本構成了帕累託前沿，這意味著在任何給定速度下，沒有其他 API 能夠在不影響質量的情況下提供相同或更低的延遲。
FLUX-extra-juiced 每張圖片只需 2.5 秒，而基線模型需要 7 秒，這種速度提升在大規模應用時會變得非常顯著。生成 100 萬張圖片可節省約 18 小時的計算執行時間。
💸 成本比較
使用這些 API 大規模生成影像並不便宜——大多數需要大約 25,000 美元才能生成 100 萬張影像。因此，我們也考慮了質量與成本之間的關係。
結果呢？FLUX-juiced 始終處於**帕累託前沿**——以**一流的速度**和**一流的價格**提供**一流的質量**。生成 100 萬張影像，您可以節省 2 萬美元的成本。
🖼️ 並排比較
我們還建立了一個網站，比較了 FLUX-juiced 與基線模型在 600 個提示下的輸出。請自行檢視。
🧃獲取您模型的加速版本
使用我們的 Pruna Pro 引擎，我們僅用 10 行程式碼就建立了 FLUX-juiced。您也可以做到，因為這段程式碼適用於幾乎所有 🤗 Diffusers 流水線。
import torch
from diffusers import FluxPipeline
from pruna_pro import SmashConfig, smash
pipe = FluxPipeline.from_pretrained(
"black-forest-labs/FLUX.1-dev",
torch_dtype=torch.bfloat16,
).to("cuda")
smash_config = SmashConfig()
smash_config["compiler"] = "torch_compile"
smash_config["cacher"] = "taylor_auto"
# lightly juiced (0.6), juiced (0.5), extra juiced (0.4)
smash_config["taylor_auto_speed_factor"] = 0.4
smash_token = "<your-token>"
smashed_pipe = smash(
model=pipe,
token=smash_token,
smash_config=smash_config,
)
smashed_pipe("A cute, round, knitted purple prune.").images[0]
⏭️ 接下來是什麼？
我們已經發布了Hugging Face 上的公共模型，並計劃在 Replicate 等推理提供商上釋出更多模型！我們將不僅專注於影像生成，還可能涉足其他模態，實施最新最棒的最佳化技術！
準備好讓您自己的模型跑得更快了嗎？
- 🔌 在 Replicate 上試用 FLUX-juiced
- 🌟 在 GitHub 上給我們點贊，最佳化您自己的模型
告訴我們您接下來想看到哪些模型被“加速”。如果您正在使用擴散模型進行開發——我們很樂意聽取您的意見。
保持活力！我們會的。
