Belajar Hermes AI Agent - Performance Optimization

#Pendahuluan

Di episode 14 kalian menyiapkan agent untuk bertahan dari jaringan yang tidak sempurna: exponential backoff saat kena rate limit, circuit breaker untuk mengisolasi dependency yang mati, dan graceful degradation supaya service lain tumbang tidak ikut mematikan agent. Agent kalian kini tangguh. Tapi tangguh saja tidak cukup — agent yang membakar token dua kali lebih banyak dan merespons dua kali lebih lambat juga memakan biaya.

Roadmap episode ini: memangkas biaya prompt dan pemakaian token, memanfaatkan cache untuk respons model dan hasil tool, lalu memprofil latensi runtime untuk menemukan titik hambat yang sebenarnya.

#Menghitung Biaya per Percakapan

Setiap turn membayar dua hal: token input (prompt, riwayat, hasil tool) dan token output (respons). Biaya dihitung per token per model, dan setiap karakter yang dikirim ke model ikut dihitung. Maka satu-satunya cara menghemat adalah mengurangi jumlah token yang lewat — bukan menawar harga model.

Mulai dengan anggaran token yang eksplisit:

budget:
  max_input_tokens: 12000
  max_output_tokens: 800
  summarize_history_at: 9000
  hard_stop_on_exceed: true

max_input_tokens membatasi total prompt yang boleh masuk ke model; ketika lewat, request dibatasi. max_output_tokens memaksa jawaban ringkas dan sekaligus menurunkan latensi. summarize_history_at memicu ringkasan riwayat (ingat episode 8) sebelum prompt membengkak. Kalau di episode 9 kalian mengatur prompt window secara manual, di sini Hermes mengaturnya otomatis berdasarkan ambang itu.

#Memangkas Token di Prompt dan Konteks

Model membaca semua yang kalian berikan. Jika system prompt berisi 40 baris instruksi yang tidak pernah memengaruhi output, itu ongkos tetap di setiap turn. Prinsipnya: instruksi yang tidak pernah mengubah output adalah token yang terbuang.

Audit rutin yang bisa kalian lakukan:

• Buang baris instruksi yang tidak terpakai dalam seminggu terakhir — bisa dicek dari event log episode 7.
• Pindahkan detail ke retrieval, jangan selalu menjejalkan seluruh knowledge base ke prompt.
• Ringkas riwayat percakapan yang sudah tua dan hanya sertakan turn yang relevan dengan pertanyaan saat ini.
• Batasi panjang jawaban; output yang tidak terkendali adalah pemborosan ganda, di biaya dan di latensi.

Jangan lupa model routing: tugas sederhana tidak perlu model besar. Hermes memungkinkan aturan rute berbasis tipe task:

routing:
  default: gpt-4o
  rules:
    - match: type == "translation" or type == "summarize"
      model: gpt-4o-mini
    - match: type == "code_analysis"
      model: gpt-4o

Dengan routing ini, sebagian besar request yang bersifat ringan memakai model kecil, dan model besar hanya dipanggil saat benar-benar dibutuhkan. Ini penghematan terbesar dengan perubahan terkecil.

#Caching Respons Model

Pemborosan paling umum berikutnya adalah kerja duplikat: ratusan user menanyakan hal yang hampir sama, dan setiap kali model menjawab dari nol. Solusinya semantic cache — simpan jawaban, lalu pada request berikutnya cocokkan berdasarkan kemiripan makna, bukan kecocokan string persis.

import { embed, vectorSearch } from "@hermes/cache";
 
const THRESHOLD = 0.92;
const TTL_MS = 24 * 60 * 60 * 1000;
 
export async function cachedReply(agent, input) {
  const query = await embed(input);
  const hit = await vectorSearch("reply_cache", query, {
    threshold: THRESHOLD,
    ttl: TTL_MS,
  });
  if (hit) return { reply: hit.reply, fromCache: true };
 
  const reply = await agent.run(input);
  await vectorSearch("reply_cache", query, {
    store: { reply },
    ttl: TTL_MS,
  });
  return { reply, fromCache: false };
}

Query di-embed menjadi vektor lalu dibandingkan dengan jawaban tersimpan. Kemiripan di atas ambang 0.92 dianggap pertanyaan yang sama, dan jawaban lama dikembalikan tanpa panggilan model. Respons dari cache juga jauh lebih cepat — ini memangkas latensi sekaligus biaya.

#Caching Output Tool

Pemanggilan tool sering menjadi bagian paling lambat dan paling sering kena rate limit seperti yang kalian atasi di episode 14. Tool yang deterministik — ambil kurs, cek cuaca, baca konfigurasi — boleh di-cache dengan TTL sesuai kesegaran datanya.

const ttlCache = new Map();
 
export async function cachedTool(name, args, { ttlMs = 60_000 } = {}) {
  const key = name + ":" + JSON.stringify(args);
  const entry = ttlCache.get(key);
  if (entry && Date.now() - entry.at < ttlMs) return entry.value;
 
  const value = await invoke(name, args);
  ttlCache.set(key, { value, at: Date.now() });
  return value;
}

Aturan emasnya: cache hanya untuk tool read-only. get_weather, fetch_currency, dan query_catalog boleh; send_email, create_order, dan delete_record tidak pernah. Dan seperti di episode 14, tandai respons yang berasal dari cache supaya agent maupun user tahu datanya mungkin basi.

#Profiling Latensi Runtime

Setelah biaya turun, giliran kecepatan. Sebelum mengoptimalkan, kalian harus tahu di mana waktu sebenarnya terbuang. Latensi agent bisa dipecah menjadi tiga fase: plan (menyusun langkah), tool (memanggil tool), dan respond (menghasilkan jawaban).

export async function profileRun(agent, task) {
  const t0 = performance.now();
  const plan = await agent.plan(task);
  const t1 = performance.now();
  const result = await agent.execute(plan);
  const t2 = performance.now();
  const reply = await agent.respond(result);
  const t3 = performance.now();
 
  return {
    reply,
    phases: {
      planMs: Math.round(t1 - t0),
      toolMs: Math.round(t2 - t1),
      respondMs: Math.round(t3 - t2),
    },
  };
}

Baca hasilnya dengan kepala dingin:

• planMs dominan: model terlalu banyak berpikir — perkecil max_output_tokens, pakai model yang lebih cepat, atau permudah instruksi.
• toolMs dominan: optimalkan tool itu sendiri atau perkuat tool cache di atas.
• respondMs dominan: kurangi panjang jawaban atau route ke model kecil.

Untuk gambaran keseluruhan lintas sesi, Hermes menyediakan agregator bawaan: jalankan hermes perf report setelah agent melayani beberapa sesi. Laporannya berisi p50 dan p95 untuk tiap fase. Jarak yang besar antara p50 dan p95 menandakan ada sesi yang nyangkut — sering kali karena satu tool lambat atau cache miss.

#Penutup

Episode 15 membuat agent kalian hemat dan cepat. Kalian menetapkan anggaran token dan merampingkan prompt, menyimpan hasil duplikat lewat semantic cache dan tool cache ber-TTL, serta memprofil latensi per fase untuk tahu persis ke mana optimasi harus diarahkan. Kombinasi anggaran token yang disiplin dan cache yang tepat bisa memangkas biaya hingga puluhan persen tanpa mengubah kualitas jawaban.

Inti yang harus dibawa pulang:

• Token adalah uang — hitung biaya per turn dan pasang max_input_tokens serta max_output_tokens.
• Ramahkan prompt; instruksi yang tidak terpakai adalah ongkos tetap di tiap turn.
• Route tugas ringan ke model kecil, simpan model besar untuk tugas berat.
• Semantic cache untuk pertanyaan berulang, tool cache untuk tool read-only yang deterministik.
• Profiling per fase menjawab "lambatnya di mana" sebelum kalian mengoptimalkan dengan menebak.

Episode 16 berikutnya kita memberdayakan agent dengan kemampuan yang tidak ada di bawaan: Agent Customization & Extensions — menulis custom actions dan plugin, memperluas kapabilitas dengan tool khusus domain, serta mengemas modul agent agar bisa dipakai ulang lintas project. Sampai jumpa!