Menjalankan pipeline evaluasi multi-LLM skala besar untuk menguji bias, halusinasi, dan alignment model—seperti pada sistem benchmarking trakkr.ai—memerlukan eksekusi ratusan ribu prompt terhadap beragam model API (OpenAI, Anthropic, maupun self-hosted model). Masalah utama dalam pipeline ini bukan sekadar menjalankan request, melainkan mengelola batas kuota provider (RPM/TPM), biaya eksekusi, serta keandalan saat terjadi kegagalan jaringan atau token exhaustion.

Dua paradigma arsitektur umum yang digunakan untuk menangani beban komputasi ini adalah Ephemeral Batch Tasks (AWS Lambda atau AWS ECS Fargate) dan Dedicated Worker Pool berbasis orkestrator (seperti Go worker dengan Temporal). Memilih pendekatan yang keliru dapat menyebabkan pemborosan biaya komputasi, terhentinya pipeline akibat rate limit, atau inkonsistensi data hasil evaluasi.

Pola 1: Ephemeral Batch Tasks (AWS Lambda / ECS Fargate)

Pada arsitektur ephemeral, setiap evaluasi prompt atau batch kecil dipicu secara modular menggunakan mekanisme antrean pesan (misalnya AWS SQS). Fungsi serverless dijalankan sesuai kebutuhan dan langsung dimatikan setelah eksekusi selesai.

  • AWS Lambda: Cocok untuk prompt tunggal atau evaluasi ringan berbasis teks yang selesai di bawah 15 menit.
  • AWS ECS Fargate: Digunakan jika evaluasi melibatkan judge-model lokal (misalnya menjalankan model Llama-3-8B kuantisasi untuk menguji respons model lain) yang membutuhkan alokasi memori serta CPU lebih besar dan stabil.

Kelebihan utama arsitektur ini adalah zero idle cost dan skalabilitas otomatis. Namun, kelemahannya terletak pada sifat instans yang terisolasi tanpa koordinasi terpusat. Ketika 5.000 instans Lambda berjalan bersamaan, seluruh instans tersebut akan membanjiri endpoint provider yang sama, sehingga memicu HTTP 429 (Too Many Requests) secara serentak.

Pola 2: Dedicated Worker Pool (Go / Temporal)

Arsitektur dedicated worker memanfaatkan sekumpulan worker berumur panjang (long-running instances) yang dikelola oleh orchestration engine seperti Temporal, Cadence, atau sistem antrean internal berbasis Redis/Kafka. Kode worker sering ditulis dalam bahasa dengan konkurensi efisien seperti Go.

Temporal memisahkan definisi alur kerja (workflow) dari eksekusi tugas nyata (activity). Setiap langkah, mulai dari pengiriman prompt, validasi skema, parsing respon, hingga skoring metrik, tercatat dalam event history yang persisten.

// Contoh Activity Worker Go di Temporal untuk memanggil LLM dengan kontrol konkurensi
package main

import (
	"context"
	"crypto/sha256"
	"encoding/hex"
	"fmt"
	"time"

	"go.temporal.io/sdk/activity"
	"golang.org/x/time/rate"
)

type EvalActivity struct {
	Limiter *rate.Limiter // Rate limiter terpusat per worker instance
}

type EvalInput struct {
	ModelID string `json:"model_id"`
	Prompt  string `json:"prompt"`
}

func (a *EvalActivity) ExecuteEvaluation(ctx context.Context, input EvalInput) (string, error) {
	logger := activity.GetLogger(ctx)

	// Menunggu token bucket tersedia sebelum memanggil API LLM
	if err := a.Limiter.Wait(ctx); err != nil {
		return "", fmt.Errorf("rate limiter context canceled: %w", err)
	}

	logger.Info("Menjalankan inferensi", "model", input.ModelID)
	// Logika HTTP client ke provider LLM di sini...
	return "hasil respon model", nil
}

Analisis Trade-Off Kritis

1. Pengelolaan Rate-Limit dan Retry Storm

Setiap provider LLM menerapkan batasan ketat pada Requests Per Minute (RPM) dan Tokens Per Minute (TPM). Pada arsitektur ephemeral, worker tidak memiliki state terpusat. Saat kuota habis dan provider mengembalikan respons HTTP 429, mekanisme retry otomatis dari ribuan instans Lambda secara bersamaan memicu thundering herd problem atau retry storm yang memperpanjang status exhaustion.

Sebaliknya, arsitektur dedicated worker pool memungkinkan penerapan rate limiting presisi di tingkat antrean lokal atau global menggunakan algoritma Leaky Bucket atau Token Bucket. Jika terjadi HTTP 429, worker dapat langsung membekukan sementara pengiriman tugas (backoff circuit breaker) tanpa mengorbankan status evaluasi lainnya.

2. Overhead Cold-Start dan Connection Pooling

Panggilan ke API LLM dilakukan melalui HTTPS. Dedicated worker yang berjalan terus-menerus dapat memanfaatkan kembali koneksi TCP dan TLS handshake melalui http.Transport connection pooling (HTTP/2 multiplexing). Pada Ephemeral Lambda, inisialisasi runtime berulang (cold-start) dan handshake TLS baru pada setiap invocation meningkatkan latensi kumulatif dan membuang siklus CPU yang tidak perlu pada jutaan eksekusi.

3. Biaya: Compute vs. Data Transfer / Egress

Biaya evaluasi batch besar dianalisis melalui dua faktor utama:

  • Compute: Jika beban evaluasi bersifat periodik (misal: hanya berjalan tiap akhir pekan), Ephemeral Lambda atau Fargate Spot jauh lebih murah karena biaya komputasi turun ke nol saat tidak digunakan. Dedicated cluster (EC2/EKS) menuntut alokasi biaya konstan meskipun worker dalam posisi idle.
  • Egress & Endpoint Cost: Menjalankan ribuan fungsi Lambda di dalam VPC untuk mengakses database analitik memerlukan NAT Gateway. Biaya data transfer melalui NAT Gateway pada beban evaluasi tinggi dapat melampaui biaya komputasi Lambda itu sendiri. Dedicated worker pada public/private subnet terkontrol dapat diarahkan melalui VPC peering atau gateway khusus yang lebih hemat biaya.

Idempotensi dan Deduplikasi Prompt

Evaluasi multi-LLM sering mengulang kumpulan dataset uji yang sama untuk berbagai variasi model atau temperature. Untuk mencegah pembengkakan biaya akibat pemanggilan API yang tidak disengaja, setiap request wajib memiliki kunci idempotensi deterministik berbasis content-hash.

Kunci Hash = SHA256(ModelID + ":" + Temperature + ":" + SystemPrompt + ":" + UserPrompt + ":" + Seed)

Sebelum tugas dikirim ke antrean eksekusi, periksa keberadaan kunci hash di layer penyimpanan. Jika hash sudah dievaluasi dengan konfigurasi parameter yang identik, sistem langsung mengambil output dari cache/storage tanpa mengeksekusi panggilan ulang ke provider LLM.

Skema Hybrid Storage: PostgreSQL + Object Storage

Menyimpan seluruh payload evaluasi (prompt lengkap, output teks panjang, token logprobs, dan metadata audit) langsung ke dalam tabel PostgreSQL akan mempercepat kehabisan ruang disk (table bloat), menurunkan performa index, dan membuat proses autovacuum menjadi lambat.

Gunakan pendekatan Hybrid Storage:

  • Relational DB (PostgreSQL): Menyimpan metadata terstruktur, metrik performa (latensi, waktu eksekusi), biaya token, dan skor evaluasi kuantitatif (akurasi, bias score, toxicity score). Ini memastikan query analitik, agregasi, dan pengurutan (ranking) tetap berjalan cepat.
  • Object Storage (Amazon S3 / Google Cloud Storage): Menyimpan raw JSON request dan response, token usage detail, serta jejak reasoning berukuran besar dengan penamaan berbasis hash.
-- Skema DDL PostgreSQL untuk Metadata dan Agregat Skor
CREATE TABLE evaluation_runs (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    benchmark_suite VARCHAR(64) NOT NULL,
    model_id VARCHAR(64) NOT NULL,
    created_at TIMESTAMPTZ DEFAULT NOW()
);

CREATE TABLE evaluation_results (
    prompt_hash CHAR(64) PRIMARY KEY, -- SHA-256 ID
    run_id UUID REFERENCES evaluation_runs(id) ON DELETE CASCADE,
    model_id VARCHAR(64) NOT NULL,
    latency_ms INT NOT NULL,
    input_tokens INT NOT NULL,
    output_tokens INT NOT NULL,
    cost_usd NUMERIC(10, 6) NOT NULL,
    score_accuracy NUMERIC(5, 4),
    score_bias NUMERIC(5, 4),
    payload_s3_uri VARCHAR(255) NOT NULL, -- s3://eval-lake/payloads/{prompt_hash}.json.gz
    created_at TIMESTAMPTZ DEFAULT NOW()
);

CREATE INDEX idx_eval_results_model_metrics 
ON evaluation_results (model_id, score_bias, score_accuracy);

Panduan Keputusan Arsitektur

Pilih arsitektur berdasarkan volume pengujian dan kapasitas operasional tim engineering:

  1. Pilih Ephemeral Batch (Lambda/Fargate) jika: Evaluasi hanya dijalankan sesekali (misal: ad-hoc saat rilis model baru bulanan), volume prompt di bawah 50.000 per eksekusi, tim tidak ingin mengelola kluster server secara berkala, dan beban evaluasi tidak memerlukan sinkronisasi rate-limit yang ketat.
  2. Pilih Dedicated Worker Pool (Go/Temporal) jika: Pipeline berjalan secara kontinu (integrasi CI/CD benchmarking harian), volume prompt melampaui ratusan ribu item per hari, memerlukan kontrol ketat terhadap batas TPM/RPM multi-provider, serta membutuhkan kemampuan replay dan stateful recovery tanpa memulai evaluasi dari awal saat terjadi kegagalan sistem.