GPU batch không phải cứ bật server là xong

Một playbook cho team builder chọn cách chạy workflow AI theo job, thay vì dựng server GPU chỉ vì demo nhìn đã mắt.

Bụi Wire

2026-06-24

“Có cần dựng hẳn một service GPU không?” — câu này mình nghe nhiều nhất vào những tuần team marketing, product và engineering cùng nhìn vào một deadline rồi cùng… im lặng.

Demo ComfyUI chạy trên máy local thì mượt. Kéo node, bấm queue, ra ảnh. Nhưng đến lúc cần sinh vài trăm asset cho campaign, mỗi asset khác prompt, khác kích thước, khác seed, khác brand guideline, câu chuyện bắt đầu lệch nhịp. Một người ngồi canh UI không còn là workflow nữa; đó là buổi độc tấu kéo dài tới khuya.

Tín hiệu đáng để ý không nằm ở riêng ComfyUI hay riêng SageMaker. Nó nằm ở chỗ các nền tảng đang đẩy workload AI nặng GPU về mô hình job: chạy theo lô, có log, có input/output rõ, xong thì tắt. AWS làm chuyện đó với ComfyUI workflow trên SageMaker AI Processing Jobs. Hugging Face cũng đi cùng hướng khi cho GitHub CI chạy qua Hugging Face Jobs để có CPU/GPU phù hợp hơn.

Sau bài này, mình muốn bạn đổi một suy nghĩ: đừng mặc định triển khai AI workflow nghĩa là dựng API server lâu dài. Với nhiều bài toán media generation, job runner mới là nhịp phách đúng.

Sơ đồ minh họa cho bài GPU batch không phải cứ bật server là xong

Sơ đồ tóm tắt ý chính của bài viết.

Mục tiêu: chọn đúng “kiểu chạy” trước khi chọn GPU

ComfyUI là công cụ dựng workflow tạo ảnh/video/audio bằng node graph. Điểm mạnh của nó là biểu diễn pipeline rất trực quan: load model, nhận prompt, chạy sampler, post-process, lưu output. Nhưng khi đưa vào production, câu hỏi không còn là “workflow có chạy không?” mà là:

Ai kích hoạt workflow?
Input được version hóa ở đâu?
Output trả về chỗ nào?
Nếu job lỗi giữa chừng, retry ra sao?
Chi phí GPU có cháy âm thầm không?
Có cần phản hồi realtime cho user không?

SageMaker AI Processing Jobs là kiểu chạy job xử lý dữ liệu/model theo lô trên hạ tầng được quản lý. Dịch sang tiếng người: bạn đóng gói code và workflow, đưa input vào, yêu cầu máy phù hợp chạy, lấy output ra, rồi máy biến mất khỏi hóa đơn chạy liên tục.

Đây là khác biệt lớn với việc dựng một ComfyUI server GPU luôn bật. Server giống một dàn nhạc phải ngồi sẵn trên sân khấu cả ngày, dù chỉ diễn vài bài. Job runner thì gọi ban nhạc lên đúng suất diễn, chơi xong thu nhạc cụ.

Checklist quyết định: server, job, hay CI GPU?

Trước khi viết CDK, Dockerfile hay workflow YAML, hãy chốt bài toán bằng bảng này:

| Câu hỏi | Nghiêng về server GPU | Nghiêng về job runner | Nghiêng về CI GPU |
|---|---|---|---|
| User cần kết quả ngay trong UI? | Có | Không hẳn | Không |
| Workload chạy theo lô? | Ít phù hợp | Rất phù hợp | Chỉ phù hợp cho test/build |
| Input có thể chuẩn bị trước? | Không bắt buộc | Có | Có |
| Cần scale theo campaign/deadline? | Có nhưng phải quản vận hành | Có, tự nhiên hơn | Không phải mục tiêu chính |
| GPU dùng liên tục cả ngày? | Có thể hợp lý | Không tối ưu nếu luôn đầy tải | Không |
| Cần test CUDA trong repo? | Không phải chính | Không phải chính | Có |

Với nguồn AWS, bài toán là chạy ComfyUI workflow để sinh nhiều hình ảnh trong một batch bằng SageMaker Processing Jobs, cấu hình hạ tầng bằng AWS CDK — bộ khai báo hạ tầng bằng code. Với nguồn Hugging Face, tín hiệu là một repo vẫn giữ GitHub Actions làm điểm điều phối, nhưng chuyển nơi chạy job sang Hugging Face Jobs để có máy phù hợp, kể cả GPU.

Hai câu chuyện khác nhau, nhưng cùng một hợp âm: GPU đang được đóng gói thành năng lực chạy việc, không chỉ là máy để SSH vào.

Playbook một buổi: biến workflow đẹp thành job chạy được

Nếu team bạn đang có ComfyUI workflow chạy local, đừng nhảy thẳng sang production hoành tráng. Làm bản nhỏ trước, đủ để biết kiến trúc có đáng theo không.

1. Đóng băng workflow thành artifact

Đừng để workflow chỉ tồn tại trong trí nhớ của một bạn designer kiêm prompt engineer.

Bạn cần tối thiểu:

File workflow ComfyUI đã export.
Danh sách model/checkpoint cần dùng.
Prompt template và biến đầu vào.
Quy ước output: tên file, folder, metadata.

Ví dụ cấu trúc repo:

ai-creative-batch/
  workflows/
    product-hero-image.json
  inputs/
    prompts.csv
  src/
    run_workflow.py
  infra/
    app.py
  Dockerfile

Ở bước này, mục tiêu không phải đẹp. Mục tiêu là tái lập được: hôm nay chạy ra một bộ asset, mai đổi prompt vẫn chạy cùng logic.

2. Tách input khỏi code

Một lỗi rất hay gặp: nhét prompt, seed, model path vào script rồi gọi đó là automation. Làm vậy thì mỗi campaign lại sửa code, dễ sai và khó review.

Hãy để job nhận input từ file như CSV/JSON:

[
  {
    "sku": "ao-thun-den",
    "prompt": "studio product photo, black t-shirt, clean background",
    "seed": 1234
  },
  {
    "sku": "ao-khoac-xanh",
    "prompt": "outdoor lifestyle photo, blue jacket, rainy mood",
    "seed": 5678
  }
]

Với SageMaker Processing Jobs, tinh thần là job nhận dữ liệu đầu vào, chạy trên instance phù hợp, rồi ghi kết quả ra nơi lưu trữ. Bạn không cần biến ComfyUI thành web app nếu thứ bạn cần là batch asset.

3. Đóng gói runtime, đừng cầu may môi trường

Runtime ở đây là môi trường chạy: Python version, dependency, CUDA, model file, script gọi workflow. Nếu local chạy được nhưng container không chạy, production sẽ biến thành buổi diễn mà mỗi nhạc công chơi một bản nhạc khác nhau.

Checklist runtime:

Docker image có dependency cần thiết.
Model được tải từ nơi kiểm soát được, không phụ thuộc thao tác tay.
Script có log từng item trong batch.
Output có metadata: workflow version, input id, thời điểm chạy.

Không cần nhồi mọi thứ vào image nếu model quá nặng. Nhưng cần có quy ước rõ: model nằm đâu, version nào, ai cập nhật.

4. Dựng job orchestration tối thiểu

Orchestration là cách điều phối nhiều bước để hoàn thành việc. Trong bài toán này, orchestration có thể đơn giản:

Upload input batch.
Trigger Processing Job.
Theo dõi log/trạng thái.
Lấy output.
Gắn kết quả vào hệ thống review nội bộ.

Nếu dùng AWS CDK, bạn khai báo hạ tầng bằng code để tránh click tay trong console. Nếu team nhỏ, ban đầu có thể giữ orchestration bằng script CLI hoặc pipeline nội bộ, miễn là có log và có thể chạy lại.

Ví dụ cụ thể: giả sử team bạn cần tạo 300 ảnh nháp cho 30 SKU, mỗi SKU 10 biến thể. Bản production đầu tiên không cần dashboard lung linh. Chỉ cần một command kiểu:

python submit_batch.py \
  --workflow workflows/product-hero-image.json \
  --input inputs/campaign-jan.json \
  --output s3://your-bucket/comfyui-runs/2026-jan/

Con số 300 ở đây chỉ là ví dụ minh họa. Điểm quan trọng là batch có danh tính, output có đường về, và job có thể chạy lại khi prompt/template đổi.

Pitfall: job runner không cứu workflow lộn xộn

Có ba bẫy mình thấy team Việt Nam dễ dính khi chuyển từ demo sang triển khai.

Bẫy 1: Scale lỗi lên nhanh hơn. Nếu workflow local đã hay lỗi model path, thiếu VRAM, node custom không ổn định, đưa lên GPU job chỉ làm lỗi xuất hiện có hệ thống hơn. Trước khi scale, hãy chạy batch nhỏ 5-10 item và ghi log kỹ.

Bẫy 2: Quên cost shape. Job runner giúp tránh máy GPU nằm chờ, nhưng không có nghĩa là rẻ tự động. Nếu mỗi asset kéo model lớn, retry vô tội vạ, hoặc output quá nặng, hóa đơn vẫn phồng. Hãy log thời gian chạy theo item và tách lỗi do input khỏi lỗi do hạ tầng.

Bẫy 3: Dùng sai nơi cho CI. Nếu mục tiêu là test repo có CUDA, nguồn Hugging Face Jobs gợi ý một hướng khác: giữ GitHub Actions làm nhạc trưởng, chuyển phần chạy sang nơi có máy phù hợp. Nhưng CI GPU không nên bị biến thành xưởng sinh asset. CI để kiểm chứng code; batch job để sản xuất output.

Tín hiệu thị trường: ai đang đổi vị thế?

AWS hưởng lợi khi workload media generation của enterprise chuyển từ notebook/local UI sang hạ tầng quản lý được: có IAM, log, job history, storage, CDK. Đây là sân quen thuộc của họ.

Hugging Face hưởng lợi ở lớp developer workflow: repo vẫn nằm trên GitHub, nhưng compute có thể trượt sang Hugging Face Jobs khi GitHub-hosted runners không đủ phù hợp, đặc biệt với GPU.

Còn team builder bị ép đổi cách nghĩ. Trước đây, câu hỏi thường là “chọn model nào?” hoặc “dùng tool nào?”. Bây giờ câu hỏi thực dụng hơn:

Workload này là interactive hay batch?
GPU cần luôn bật hay bật theo việc?
Output cần review thủ công hay đẩy thẳng vào hệ thống?
Failure có được retry từng item hay phải chạy lại cả lô?

Nói thẳng ra thì, cái mới không phải là “AI tạo ảnh hàng loạt”. Cái mới là các nhà cung cấp đang chuẩn hóa đường ray để chạy workload AI như việc vận hành phần mềm nghiêm túc.

Nếu là mình, mình sẽ chọn thế này

Với team đang xây hệ thống AI nội bộ, mình sẽ dùng khung quyết định ba nhịp:

Nhịp 1: Prototype trong ComfyUI. Cho creative và ML cùng chỉnh workflow nhanh. Đừng vội production hóa.

Nhịp 2: Batch hóa bằng job runner. Khi workflow ổn và nhu cầu là tạo nhiều asset, đóng gói nó thành job. SageMaker Processing Jobs là một lựa chọn hợp lý nếu team đã ở AWS và cần governance kiểu enterprise.

Nhịp 3: Tách CI GPU khỏi production batch. Nếu repo cần test CUDA, hãy nhìn các job platform như Hugging Face Jobs theo hướng bổ sung cho GitHub Actions. Đừng trộn test pipeline với asset generation pipeline.

Kết luận gọn: đừng mua tiếng ồn của GPU; hãy mua đúng nhịp chạy của workload. Server cho tương tác, job cho batch, CI GPU cho kiểm thử. Chọn sai nhịp thì dàn nhạc có giỏi mấy cũng nghe lệch phách.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng