Arsitektur Kompresi Prompt LLM: Trade-off Latensi vs Token Cost

Biaya inferensi Large Language Model (LLM) dihitung per unit token, baik pada input (prompt) maupun output (completion). Pada arsitektur Retrieval-Augmented Generation (RAG) atau multi-turn conversational agents, prompt membengkak cepat karena injeksi referensi dokumen, riwayat chat, dan instruksi sistem. Memangkas payload prompt di gateway API sebelum diteruskan ke provider LLM merupakan strategi langsung untuk menekan token cost dan menghindari batasan context window. Namun, kompresi prompt menambahkan compute step baru yang berisiko menaikkan latensi sistem.

Pilihan Pendekatan: Rule-Based vs Lightweight Encoder

Kompresi prompt pada backend gateway umumnya dibagi ke dalam dua paradigma utama:

1. Rule-Based Lexical Pruning

Pendekatan ini beroperasi secara deterministik menggunakan string manipulation, stopwords removal, regex pattern filtering, atau syntax parsing (AST). Token non-esensial dibuang tanpa analisis probabilitas semantik.

• Kelebihan: Latensi minimal (sub-milidetik hingga 5ms), konsumsi memori dan CPU lokal sangat rendah, tidak memerlukan akselerator GPU, serta mudah diprediksi (deterministik).
• Kekurangan: Rawan merusak koherensi instruksi sensitif (misal: negasi logika seperti kata not atau jangan), rentan menghasilkan context loss pada relasi kata yang bergantung pada syntax exact.

2. Lightweight Encoder (LLMLingua / Small LMs)

Pendekatan ini memanfaatkan model bahasa berukuran kecil (seperti Llama-2-7B, GPT-2 small, atau varian BERT) yang dioptimasi untuk mengukur metrik perplexity atau information entropy tiap token. Token dengan perplexity rendah (informasi redunasi tinggi) dipangkas secara adaptif.

• Kelebihan: Menjaga retensi semantik lebih tinggi pada rasio kompresi tinggi (hingga 50-70%), aman untuk instruksi kompleks.
• Kekurangan: Menambah latensi eksekusi lokal (50ms hingga 300ms+ bergantung spek server/GPU), butuh alokasi memori besar untuk memuat model weights, serta meningkatkan kompleksitas maintenance infrastructure.

Analisis Trade-off: Latensi vs Biaya Komputasi

Tabel berikut memetakan trade-off operasional antara kedua pendekatan tersebut:

Jika LLM target Anda berbiaya tinggi (seperti OpenAI o1, GPT-4o, atau Claude 3.5 Sonnet) dan response streaming time mencapai 2-5 detik, penambahan 100ms encoder latency dapat dijustifikasi oleh penghematan 50% token cost. Sebaliknya, jika target model adalah model ultra-fast berbiaya murah (misal: Llama 3.1 8B atau Gemini Flash) pada antarmuka real-time voice/chat, encoder kompresi justru mendegradasi throughput dan user experience.

Implementasi: Middleware Token Pruning Deterministik

Berikut adalah middleware gateway Node.js menggunakan pola deterministik. Middleware ini membersihkan redundant whitespace, deduplikasi newline berulang, dan memangkas stopwords netral hanya dari context payload (bukan pada directive/instruksi sistem):

// tokenPrunerMiddleware.js
const STOPWORDS = new Set([
  'yang', 'untuk', 'pada', 'ke', 'para', 'namun', 'ia', 'adalah',
  'that', 'which', 'at', 'by', 'for', 'with', 'about', 'against',
  'between', 'into', 'through', 'during', 'before', 'after', 'above'
]);

function pruneContextText(text) {
  if (!text || typeof text !== 'string') return '';

  // 1. Normalisasi spasi dan line break
  const normalized = text
    .replace(/[ \t]+/g, ' ')
    .replace(/\n\s*\n+/g, '\n')
    .trim();

  // 2. Lexical filter per kata
  const tokens = normalized.split(' ');
  const filtered = tokens.filter((token) => {
    const cleanWord = token.toLowerCase().replace(/[^a-zA-Z0-9]/g, '');
    return !STOPWORDS.has(cleanWord);
  });

  return filtered.join(' ');
}

export function promptPruningMiddleware(req, res, next) {
  if (!req.body || !Array.isArray(req.body.messages)) {
    return next();
  }

  // Hanya prune message bertipe system context atau user data, pertahankan exact instruction
  req.body.messages = req.body.messages.map((msg) => {
    if (msg.role === 'system' && msg.content.includes('<context>')) {
      // Regex parsing boundary isolasi
      const contextMatch = msg.content.match(/<context>([\s\S]*?)<\/context>/);
      if (contextMatch) {
        const compressedContext = pruneContextText(contextMatch[1]);
        msg.content = msg.content.replace(
          contextMatch[0],
          `<context>${compressedContext}</context>`
        );
      }
    }
    return msg;
  });

  next();
}

Dampak pada Maintainability AI Pipeline

Penerapan layer kompresi prompt menghadirkan tantangan teknis tersendiri dalam jangka panjang:

• Debugging Degradation (Heisenbugs): Output LLM bersifat stokastik. Memotong token sebelum request membuat reproduksi bug model menjadi sulit dilacak jika gateway tidak mencatat raw prompt versus compressed prompt pada audit log.
• Model Sensitivity Discrepancy: Tokenizer tiap LLM berbeda (misal: tiktoken cl100k_base vs Llama byte-fallback BPE). Rule-based pruning yang memotong substring sembarangan dapat memecah token compound menjadi byte-pair terpisah, yang justru meningkatkan konsumsi token total di provider level.
• Technical Debt Infrastruktur: Menyematkan local encoder model (LLMLingua) ke dalam API gateway mengubah service stateless menjadi compute-heavy service yang membutuhkan penyesuaian auto-scaling policy, cold start handling, dan GPU driver management.

Panduan Keputusan Arsitektur

Pilihlah Rule-based pruning jika gateway menangani throughput tinggi (>500 RPS), mengutamakan time-to-first-token (TTFT) di bawah 500ms, dan format dokumen prompt dapat diisolasi via boundary tags. Gunakan Encoder-based compression (LLMLingua) via dedicated asynchronous microservice jika context document berukuran masif (>32k token) pada pipeline batch atau LLM reasoning tingkat lanjut di mana rasio reduksi token sepadan dengan beban latensi.