Dilema Komputasi dan Jejak Energi pada Inferensi LLM
Pemanfaatan model bahasa besar (LLM) seperti GPT-4 atau Claude 3.5 Sonnet untuk tugas-tugas sepele memicu pemborosan komputasi. Menjalankan inferensi model ratusan miliar parameter untuk mengekstrak entitas sederhana atau menyapa pengguna menghabiskan puluhan watt-jam per kueri. Isu jejak energi dan konsumsi daya komputasi AI menuntut arsitektur backend yang lebih bijak dalam mendistribusikan beban kerja inference.
Sebagai backend engineer, keputusan arsitektur tidak lagi terbatas pada metrik latensi dan biaya per 1.000 token (TPM/RPM), melainkan pada efisiensi daya komputasi: kapan harus memanggil Cloud API tersentralisasi dan kapan harus mendelegasikan kueri ke Small Language Model (SLM) self-hosted.
Perbandingan Teknis: Cloud API vs Self-Hosted SLM
Memilih antara Cloud API (OpenAI, Anthropic, Google Vertex) dan SLM self-hosted (Llama-3.2-3B, Mistral-7B, Phi-3 via vLLM atau Ollama) memerlukan analisis multi-variabel.
1. Karakteristik Cloud API
- Kelebihan: Zero operational maintenance, kapasitas scaling horizontal tanpa batas infrastruktur fisik, dan performa nalar (reasoning) superior untuk kueri ambigu.
- Kekurangan: Biaya berbasis token akumulatif tinggi pada volume besar, data privacy/compliance risks (kecuali ada perjanjian BAA/enterprise), potensi rate limiting, serta latensi jaringan eksternal (RTT).
- Beban Energi: Ditanggung oleh penyedia cloud, tetapi secara agregat menggunakan kluster akselerator skala masif yang beroperasi pada TDP tinggi.
2. Karakteristik Self-Hosted SLM (vLLM / Ollama)
- Kelebihan: Latensi deterministik lokal, data sepenuhnya terisolasi dalam VPC/infrastruktur on-premise, tanpa batasan token eksternal, dan hemat energi jika dijalankan pada hardware yang tepat (misalnya GPU hemat daya atau edge server).
- Kekurangan: Perlu alokasi VRAM tetap, manajemen continuous batching dan KV cache, keterbatasan context window, serta kualitas penalaran yang menurun pada instruksi multi-langkah.
Strategi Optimasi: Hybrid Routing Architecture
Pendekatan optimal menghindari solusi biner. Sistem produksi yang tangguh menerapkan Hybrid Gateway Architecture dengan tiga lapisan filter:
- Exact/Semantic Cache: Mengembalikan respons dari Redis atau Vector DB jika kemiripan kosinus (cosine similarity) dari embedding prompt > 0.95. Menghindari kalkulasi forward-pass LLM secara total.
- Heuristic / Complexity Routing: Memeriksa panjang token, keberadaan kata kunci logis kompleks, atau pola intent kueri. Kueri klasifikasi, ekstraksi JSON terstruktur, atau sapaan diarahkan langsung ke SLM lokal.
- Cloud Fallback: Kueri dengan kompleksitas tinggi, instruksi multi-step reasoning, atau tugas yang gagal divalidasi oleh SLM dialihkan ke Cloud API tier atas.
Implementasi: Proxy Router Sederhana dengan FastAPI
Berikut implementasi proxy router minimal menggunakan Python dan FastAPI. Router ini mengukur estimasi token input dan memindai kata kunci penalaran untuk menentukan apakah inferensi dialokasikan ke instance vLLM lokal atau ke API cloud.
import os
import httpx
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
app = FastAPI(title="LLM Inference Router")
VLLM_ENDPOINT = os.getenv("VLLM_ENDPOINT", "http://localhost:8000/v1/chat/completions")
CLOUD_API_ENDPOINT = os.getenv("CLOUD_API_ENDPOINT", "https://api.openai.com/v1/chat/completions")
CLOUD_API_KEY = os.getenv("CLOUD_API_KEY", "")
TOKEN_THRESHOLD = 150
COMPLEX_KEYWORDS = {"analisis", "evaluasi", "bandingkan", "refactor", "bukti", "arsitektur"}
class ChatPayload(BaseModel):
prompt: str
temperature: float = 0.7
def is_complex_query(prompt: str) -> bool:
# ponytail: Estimasi kasar 1 kata ~ 1.3 token. Gunakan tiktoken jika butuh akurasi ketat.
token_estimate = len(prompt.split()) * 1.3
if token_estimate > TOKEN_THRESHOLD:
return True
prompt_words = set(prompt.lower().split())
if not COMPLEX_KEYWORDS.isdisjoint(prompt_words):
return True
return False
@app.post("/v1/inference")
async def route_inference(payload: ChatPayload):
client = httpx.AsyncClient(timeout=30.0)
# 1. Evaluasi Kompleksitas
route_to_cloud = is_complex_query(payload.prompt)
try:
if not route_to_cloud:
# 2. Jalankan via SLM Local (vLLM/Ollama API spec)
response = await client.post(
VLLM_ENDPOINT,
json={
"model": "meta-llama/Llama-3.2-3B-Instruct",
"messages": [{"role": "user", "content": payload.prompt}],
"temperature": payload.temperature
}
)
if response.status_code == 200:
result = response.json()
result["routed_to"] = "local_slm"
return result
# ponytail: Fallback ke cloud jika worker lokal kehabisan VRAM / error 5xx.
# 3. Jalankan via Cloud API (High-cost, high-reasoning)
headers = {"Authorization": f"Bearer {CLOUD_API_KEY}"}
response = await client.post(
CLOUD_API_ENDPOINT,
headers=headers,
json={
"model": "gpt-4o-mini",
"messages": [{"role": "user", "content": payload.prompt}],
"temperature": payload.temperature
}
)
response.raise_for_status()
result = response.json()
result["routed_to"] = "cloud_api"
return result
except httpx.HTTPError as err:
raise HTTPException(status_code=502, detail=f"Upstream inference failure: {str(err)}")
finally:
await client.aclose()
Dilewati pada contoh di atas: Connection pooling persistent client dan layer semantic caching berbasis Redis. Tambahkan kedua komponen tersebut saat traffic mencapai throughput > 50 RPS.
Metrik Monitoring dan Debugging
Saat menjalankan arsitektur hybrid di production, pantau tiga metrik utama:
- Fallback Ratio: Persentase kueri yang gagal dieksekusi oleh SLM lokal dan terpaksa diarahkan ke Cloud API. Jika angka ini > 15%, sesuaikan heuristic threshold atau fine-tune SLM lokal.
- KV Cache Usage (vLLM): Pantau metrik
vllm:gpu_cache_usage_factormelalui Prometheus. Jika metrik mendekati 1.0 terus-menerus, request akan tertahan pada memory queuing. - P99 Latency vs Cost: Pastikan latency kueri SLM lokal tetap berada di bawah throughput Cloud API untuk membenarkan biaya hardware/listrik lokal.
Komentar
0 komentar
Masuk ke akun kamu untuk ikut berkomentar.
Belum ada komentar
Jadilah yang pertama ikut berdiskusi!