31,8x Tốc độ tăng chỉ với một thay đổi tệp

Tôi đã kiểm tra một pipeline nạp dữ liệu RAG và gặp phải một nút thắt cổ chai: một tài liệu mất tới 50 giây để xử lý.

CPU của tôi ở trạng thái rảnh rỗi. Ứng dụng không thực hiện các phép toán hay logic; nó chỉ đơn giản là chờ một yêu cầu HTTP hoàn tất trước khi bắt đầu yêu cầu tiếp theo.

Tôi đã viết lại module embedding để chạy bất đồng bộ. Thời gian chạy giảm từ 49,61 giây xuống còn 1,56 giây—mà không cần thay đổi hạ tầng.

Chi tiết thử nghiệm

  • Model: Amazon Titan Text Embeddings V2 (AWS Bedrock)
  • Dataset: 33 chunks văn bản
  • Region: us-east-1

Kết quả

  • Tuần tự (Sequential): 49,61 s
  • Đồng thời (Concurrent): 1,56 s
  • Tốc độ tăng: 31,8×

Tại sao nó hiệu quả Mã tuần tự gửi một yêu cầu và bị chặn cho đến khi nhận được phản hồi, sau đó lặp lại cho từng chunk. Với 33 chunks, mỗi chunk mất 1,5 giây, bạn sẽ lãng phí khoảng 50 giây.

Mã bất đồng bộ (async) gửi tất cả các yêu cầu cùng một lúc; tổng thời gian sẽ bằng thời gian của yêu cầu chậm nhất.

Tác động khi mở rộng (Scaling)

  • 31 chunks: 49,61 s → 1,56 s
  • 100 chunks: ~160 s → ~3 s
  • 500 chunks: ~800 s → ~5 s
  • 1.000 chunks: ~1.600 s → ~10 s

Lời khuyên cho pipeline của bạn

  • Hãy tìm kiếm thời gian rảnh (idle time). Đừng nâng cấp phần cứng nếu mã của bạn chỉ đang chờ đợi mạng.
  • Tuân thủ giới hạn tốc độ (rate limits) của AWS Bedrock. Sử dụng asyncio.Semaphore để giới hạn số lượng yêu cầu đồng thời.
  • Ưu tiên các thư viện không chặn (non-blocking). Chuyển từ boto3 sang aioboto3 hoặc bao bọc các lời gọi hàm bằng asyncio.to_thread().

Chỉ thay đổi một tệp duy nhất đã loại bỏ được nút thắt cổ chai. Nỗ lực thấp. Hiệu quả cao.

Nguồn: https://dev.to/edwardyun/318x-speedup-by-changing-one-file-async-embedding-calls-on-aws-bedrock-4l61

Cộng đồng học tập tùy chọn: https://t.me/GyaanSetuAi