Parallel Processing
Sesi 9.4 · ~5 menit baca
Dari Sequential ke Parallel
Three-agent chain kamu memproses satu konten dalam satu waktu. Agent 1 selesai, Agent 2 mulai, Agent 2 selesai, Agent 3 mulai. Buat satu konten, ini oke. Buat sepuluh konten, artinya nunggu ketiga agent selesai di konten 1 sebelum mulai konten 2. Itu sequential processing, dan ga scalable.
Parallel processing menjalankan beberapa chain secara bersamaan. Sementara Agent Riset ngerjain topik 5, Agent Penulis ngerjain topik 3, dan Agent Editor ngerjain topik 1. Kesepuluh konten bergerak lewat pipeline secara bersamaan, dibatasi hanya oleh API rate limit dan budget kamu.
Perbedaan Throughput
Asumsikan setiap panggilan agent butuh 10 detik. Three-agent chain butuh 30 detik per konten. Secara sequential, 10 konten butuh 300 detik (5 menit). Dengan full parallelism, kesepuluh konten menjalankan Agent Riset secara bersamaan, lalu kesepuluh Agent Penulis, lalu kesepuluh Agent Editor: total 90 detik.
Dalam praktiknya, kamu ga bisa menjalankan panggilan parallel tanpa batas. API punya rate limit. Budget kamu punya batas. Solusinya adalah controlled concurrency: jalankan N chain secara bersamaan, di mana N dibatasi oleh semaphore.
(limit: 5 bersamaan)"] B --> C1["Chain 1: R→P→E"] B --> C2["Chain 2: R→P→E"] B --> C3["Chain 3: R→P→E"] B --> C4["Chain 4: R→P→E"] B --> C5["Chain 5: R→P→E"] C1 --> D["Selesai → Lepas slot"] C2 --> D C3 --> D C4 --> D C5 --> D D --> E["Topik berikutnya masuk"] E --> B style A fill:#222221,stroke:#c8a882,color:#ede9e3 style B fill:#222221,stroke:#c47a5a,color:#ede9e3 style C1 fill:#222221,stroke:#6b8f71,color:#ede9e3 style C2 fill:#222221,stroke:#6b8f71,color:#ede9e3 style C3 fill:#222221,stroke:#6b8f71,color:#ede9e3 style C4 fill:#222221,stroke:#6b8f71,color:#ede9e3 style C5 fill:#222221,stroke:#6b8f71,color:#ede9e3 style D fill:#222221,stroke:#8a8478,color:#ede9e3 style E fill:#222221,stroke:#c8a882,color:#ede9e3
| Mode Processing | 10 Konten (30d/chain) | 50 Konten | 100 Konten |
|---|---|---|---|
| Sequential | 300d (5 mnt) | 1.500d (25 mnt) | 3.000d (50 mnt) |
| Parallel (5 bersamaan) | 90d (1,5 mnt) | 330d (5,5 mnt) | 630d (10,5 mnt) |
| Parallel (10 bersamaan) | 60d (1 mnt) | 180d (3 mnt) | 330d (5,5 mnt) |
| Parallel (25 bersamaan) | 30d | 90d (1,5 mnt) | 150d (2,5 mnt) |
Mengimplementasi Concurrency
Library asyncio di Python menangani panggilan API secara concurrent. Polanya straightforward: definisikan fungsi async buat agent chain kamu, pake asyncio.Semaphore buat membatasi concurrency, dan jalankan semua chain dengan asyncio.gather.
Struktur konseptualnya kaya gini:
import asyncio
semaphore = asyncio.Semaphore(5) # max 5 chain bersamaan
async def run_chain(topic):
async with semaphore:
research = await call_research_agent(topic)
draft = await call_writing_agent(research)
review = await call_editing_agent(draft)
return review
async def main():
topics = ["topic1", "topic2", ..., "topic10"]
results = await asyncio.gather(*[run_chain(t) for t in topics])
asyncio.run(main())
AI coding assistant kamu bisa mengisi panggilan API yang sebenarnya, error handling, dan penyimpanan file. Pola struktural di atas adalah yang perlu kamu pahami. Sisanya detail implementasi.
Rate Limit dan Throttling
Setiap API provider menerapkan rate limit: request maksimum per menit, token maksimum per menit, atau keduanya. Melebihi limit ini mengembalikan error 429 (Too Many Requests). Script kamu harus menangani ini dengan graceful.
Dua strategi:
- Proactive throttling: Set semaphore count cukup rendah supaya kamu ga pernah kena rate limit. Kalo API mengizinkan 60 request/menit dan setiap chain bikin 3 request, set semaphore ke 15-18 buat tetap aman di bawah limit.
- Reactive retry: Waktu error 429 terjadi, tunggu sesuai durasi yang ditentukan di response header (biasanya
Retry-After), lalu retry. Kombinasikan dengan exponential backoff: tunggu 1 detik, lalu 2, lalu 4, sampai maksimum.
Pendekatan proaktif lebih mulus. Pendekatan reaktif menangani edge case. Pake keduanya.
Isolasi Kegagalan
Waktu menjalankan 25 chain secara parallel, beberapa akan gagal. API timeout di chain 7 seharusnya ga menghancurkan chain 1 sampai 6 dan 8 sampai 25. Setiap chain berjalan secara independen. Kegagalan dicatat, dan chain yang gagal di-retry setelah semua chain yang sukses selesai.
Ini namanya failure isolation, dan ini perbedaan antara script yang menghasilkan 24 dari 25 konten dan script yang menghasilkan 0 karena satu kegagalan menumbangkan seluruh batch.
Parallel processing ga mengubah apa yang dilakukan pipeline kamu. Yang berubah adalah berapa banyak konten yang bergerak lewat pipeline secara bersamaan. Quality gate, handoff contract, human review, semuanya tetap identik. Skala itu perubahan throughput, bukan perubahan kualitas.
Bacaan Lanjutan
- Asynchronous LLM API Calls in Python: A Comprehensive Guide, Unite.AI
- Mastering asyncio.gather for LLM Processing, Instructor
- Python Asyncio for LLM Concurrency: Best Practices, Newline
Tugas
Ambil three-agent chain kamu yang udah berfungsi dan jalankan di 3 topik berbeda secara bersamaan:
- Kalo kamu nyaman dengan coding: tulis (atau minta AI assistant kamu tuliskan) script async dengan semaphore di-set ke 2. Jalankan ketiga chain secara concurrent.
- Kalo ga: buka 3 jendela terminal dan jalankan setiap chain secara manual secara parallel.
- Catat waktu seluruh operasi. Bandingkan dengan menjalankan ketiganya secara sequential.
Dokumentasikan: total waktu (parallel vs. sequential), kegagalan yang ditemui, dan kualitas setiap output. Apakah eksekusi parallel mempengaruhi kualitas output? (Seharusnya ga.) Hitung penghematan waktu sebagai persentase.