FLUX 3 Image 是透過代管 API 提供，而不是讓你在筆電上跑，因此真正有價值的工作發生在請求回來之後。模型交回一張固定高解像度的圖片，完全不在乎你的頁面預算，所以快速網站與慢速網站之間的差距，就在你包在呼叫外面的那條流程。

本文涵蓋多數圖像 API 使用的請求與回應形式，接著說明把結果變成能上線檔案的縮放與編碼步驟。

01代管圖像 API 對流程有什麼影響

本機模型回傳張量或磁碟檔案；代管服務則在 JSON 裡回傳 URL 或 base64 內容，兩種選擇會把成本推到不同位置。URL 讓 API 回應很小，但通常幾小時內就過期，你終究得下載並自行重新託管。base64 讓一切都在同一個回應裡，但傳輸量會膨脹約 33%，也讓請求記錄變得極大。

請對照最新官方文件確認欄位名稱

下面的請求沿用多數圖像 API 的形式——以 JSON 夾帶提示詞與尺寸，並用 bearer token 驗證。Black Forest Labs 公布 FLUX 3 的確切端點與參數名稱，而那些會變動；請把這裡當成模板，而不是凍結的契約。

02向 API 請求一張圖片

送出帶 JSON 內容與授權標頭的 POST。模型與端點名稱各家不同，請把它們放進設定，不要在十個地方硬編碼。

curl -X POST "$IMAGE_API_URL" \
  -H "Authorization: Bearer $IMAGE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "prompt": "isometric illustration of a filing cabinet, soft indigo palette",
    "width": 1024,
    "height": 1024,
    "format": "png"
  }'

請尊重你真正需要的長寬比。生成正方形再裁成橫幅，等於丟掉你付費換來的像素；要求超寬畫布，則會把資源浪費在你之後會裁掉的區域。

03處理回應：URL 或 base64

兩種回應形式需要不同的程式路徑。URL 形式是一小段 JSON，你要再抓一次；base64 形式是一大串字串，你要解碼後寫入磁碟。

{
  "id": "req_9f3c1a",
  "status": "ready",
  "image": {
    "url": "https://cdn.example.invalid/generations/req_9f3c1a.png",
    "expires_at": "2026-10-04T12:00:00Z"
  },
  "seed": 812347
}

const res = await fetch(process.env.IMAGE_API_URL, {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${process.env.IMAGE_API_KEY}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({ prompt, width: 1024, height: 1024, format: 'png' }),
})

const data = await res.json()
const bytes = data.image.url
  ? Buffer.from(await (await fetch(data.image.url)).arrayBuffer())
  : Buffer.from(data.image.b64, 'base64')

await fs.writeFile(`out/${data.id}.png`, bytes)

請把 seed 與檔案一起保存。那是日後重現或微調結果的唯一方法，而從零重新生成幾乎不可能一模一樣。

04先縮放，再壓縮

順序很重要。若先壓縮再縮放，縮放就必須自行生出或丟掉已被破壞性編碼損傷的像素。請先縮到顯示尺寸，再套用一次破壞性編碼。

對一般博客或商品卡片來說，1024 像素的 API 結果已經比你要的大。縮到約顯示寬度的兩倍就停手。

05選好格式，只編碼一次

生成的圖片通常是 PNG，無損所以偏重。攝影類輸出請轉成 WebP；它支援透明度，所以切換格式不會失去 alpha。只有在你能提供備援時才選 AVIF，因為較舊裝置的編碼器支援與解碼成本仍有差異。

# 縮放後，從原檔做一次破壞性編碼。
cwebp -q 82 -m 6 -resize 1200 0 source.png -o output.webp

質素要目視調整，不要只看數字。質素設定不是檔案大小百分比：同一個數值可能讓某張圖減半，卻讓另一張幾乎沒變，取決於模型產生了多少高頻細節。

不要為了縮小檔案而重新編碼已經有損的圖片

把 JPEG 再送進編碼器一次，在相同質素下只會丟掉更多細節。請永遠保留原始 PNG，調整參數後從母檔重新編碼。

06接進建置流程或 CMS

流程要在寫入時跑一次，而不是每次請求都跑。生成圖片後，把原檔寫進物件儲存，再產生兩三種固定寬度的衍生檔，依視窗寬度提供對應版本。

多數網站穩定的組合是 400、800、1600 像素寬，透過 srcset 提供。請把 seed、提示詞與模型名稱跟素材一起存進資料庫，方便日後稽核圖片來源。若頁面用滿版寬度渲染生成圖卻沒有 width 與 height 屬性，你還會在重量問題之外多一個版面位移問題。

07常見錯誤與修正

簡單原則：把 API 輸出當成母素材，永遠不要當成要直接提供的檔案。縮放一次、編碼一次，並保留未動過的原始檔，這樣你改變主意時，不必再向模型要一次同樣的圖。