Published on

Batch processing system: giảm 50% chi phí khi dùng AI

Authors
  • avatar
    Name
    Dinh Nguyen Truong
    Twitter

Thiết kế một hệ thống sử dụng AI Provider có khá nhiều bài toán cần cân nhắc, một trong số đó mình nghĩ sẽ là chi phí. Model càng mạnh thì chi phí càng cao, còn model rẻ hơn đôi khi lại không đảm bảo chất lượng đầu ra.

Vậy có cách nào khác để tối ưu không? Đặc biệt là trong những trường hợp hệ thống không cần phản hồi ngay lập tức?

Một giải pháp mà nhiều AI provider đưa ra là Batch Processing, với mức chi phí có thể rẻ hơn tới khoảng 50% so với cách gọi API thông thường.

Batch processing hoạt động ra sao?

Khác với cách gọi API thông thường, batch processing không trả kết quả ngay tại thời điểm request được gửi đi.

Thay vào đó, hệ thống sẽ gom nhiều input thành một batch, gửi sang provider để xử lý bất đồng bộ và nhận về một batchId. Khi batch hoàn tất, hệ thống cần fetch lại kết quả của cả batch và map lại tương ứng cho từng job.

Mô hình này rẻ hơn vì provider có thể tối ưu tài nguyên tốt hơn khi xử lý theo batch. Nhưng đổi lại, hệ thống phải chấp nhận độ trễ cao hơn và thiết kế theo một hướng khác.

Trong bài viết này, anh em hãy cùng mình đi qua cách thiết kế một hệ thống AI batch processing, cũng như các trade-off cần cân nhắc khi áp dụng nó nhé.

Bài toán này cần những yêu cầu gì?

Trước khi đi vào kiến trúc, ta cần chốt lại một vài yêu cầu cơ bản của hệ thống AI batch processing

  • Hệ thống nhận request (từ người dùng hoặc internal system) và đưa sang AI Provider để xử lý dạng batch.
  • Hệ thống có thể lấy kết quả về sau và cập nhật lại từng job.
  • Có khả năng chịu được lỗi, retry khi cần thiết.

Thiết kế tổng quan

Từ các yêu cầu ở trên, ta có thể thấy hệ thống này nên được tách thành 3 phần khá rõ:

  1. Nhận request và tạo job
  2. Gom job rồi gửi sang AI provider theo batch
  3. Theo dõi batch, lấy kết quả về và cập nhật lại từng job

Ta có thể hình dung kiến trúc tổng quan như sau:

Ở mức tổng quan, hệ thống sẽ có 4 thành phần chính:

  • API Service nhận request từ user hoặc từ internal system.
  • Database lưu job, trạng thái xử lý, thông tin batch và mapping giữa batch với từng job.
  • Blob Storage lưu file nếu bài toán cần làm việc với file lớn.
  • Cronjob chạy các tiến trình nền như gom batch, submit sang provider, polling trạng thái và lấy kết quả về.


Luồng xử lý tổng quát sẽ như sau:

  1. User hoặc internal system gửi request vào API.
  2. API lưu input cần thiết, tạo job và ghi trạng thái ban đầu vào database.
  3. Một cronjob quét các job đang chờ, gom chúng thành batch và submit sang AI provider.
  4. Hệ thống lưu lại batchId cùng thông tin liên kết giữa batch và từng job.
  5. Một cronjob khác định kỳ kiểm tra trạng thái của các batch chưa hoàn tất.
  6. Khi batch hoàn tất, hệ thống lấy kết quả về, đọc output của từng item rồi cập nhật lại database.
  7. Nếu có lỗi, hệ thống quyết định retry hay đánh dấu failed tuỳ theo trạng thái và số lần thử lại.

Bước 1: Nhận request và tạo job

Đây là phần đơn giản nhất của flow.

API chỉ cần nhận request, lưu input cần thiết, tạo job với trạng thái ban đầu như pending, rồi trả response sớm cho caller.

Bước 2: Gom batch và xử lý

Sau khi các job được tạo với trạng thái pending, một cronjob sẽ định kỳ quét chúng, gom lại thành từng batch rồi gửi sang AI provider.

Mục tiêu chính của bước này là tối ưu chi phí. Nếu gọi AI theo từng request riêng lẻ, chi phí thường khá cao. Trong khi đó, batch processing cho phép xử lý nhiều job trong một lần submit với mức giá tốt hơn, có thể lên đến 50%.

Ngoài chi phí, cách làm này còn có thêm một vài lợi ích:

  • giảm số lượng API call
  • dễ kiểm soát throughput và concurrency hơn
  • phù hợp với những bài toán không yêu cầu kết quả ngay lập tức.

Sau khi submit thành công, hệ thống lưu lại batchId cùng mapping giữa batch và các job bên trong. Đây là dữ liệu cần thiết để theo dõi và đồng bộ kết quả ở bước tiếp theo.


Bước 3: Poll kết quả và cập nhật trạng thái

Sau khi gửi batch sang AI provider, hệ thống vẫn chưa có kết quả ngay. Lúc này, một cronjob khác sẽ chạy định kỳ để kiểm tra xem batch đã xử lý xong chưa.

Nếu chưa xong thì chờ tiếp. Nếu đã xong thì tải output về, tách kết quả ra theo từng item ban đầu, rồi cập nhật lại trạng thái của từng job trong hệ thống.

Tuy nhiên, có thể trong cùng một batch sẽ có một số trường hợp xảy ra như sau:

  • một số job parse không thành công,
  • một số job trả về lỗi.
  • một số job có dữ liệu sai.

Vì vậy hệ thống sẽ cần thêm một logic xử lý các lỗi, mỗi job nên có retryCount để hệ thống biết khi nào cần thử lại và khi nào nên dừng hẳn. Nếu retry quá nhiều lần mà vẫn lỗi, job nên được chuyển sang failed.

Scaling

Do gần như tất cả các thành phần trong hệ thống đã được tách biệt rõ ràng nên việc hệ thống này khá đơn giản. Tuy nhiên có một phần lưu ý đó chính là việc gửi API batch sang các provider sẽ bị giới hạn số lượng batch cũng như size mỗi batch mỗi giờ. Anh em cần xem xét kĩ hơn để triển khai đúng phần này.

Summary

Để thiết kế cho mô hình chạy batch processing mình nghĩ khá là dễ, và có thể hiện tại cũng đang có nhiều anh em chuyển sang hướng này để tiết kiệm chi phí cho doanh nghiệp.

Mong rằng bài phân tích của mình sẽ giúp anh em triển khai nhanh gọn lẹ hơn. Hẹn gặp lại trong những bài viết tiếp theo.