Panggilan LLM Produksi Pertamamu: Streaming, Retry, Timeout

Baca tabel itu lagi dan tanyakan program seperti apa yang dideskripsikannya. Ia menahan koneksi tetap terbuka selama empat puluh detik. Ia harus bisa dibatalkan dari tombol. Ia mengakumulasi jawaban parsial yang valid untuk ditampilkan dan tidak valid untuk disimpan. Dan ia berjalan di proses server atau di edge worker, di sebelah hal yang merender jawaban, sambil memegang socket.

Itu bukan notebook. Bukan berarti Python tidak bisa melakukannya — bisa, dan orang-orang melakukannya — melainkan bahwa semua yang dibangun tiga belas bab sebelumnya berjenis lain. Bab 1 sampai 13 memegang weights, gradients, logits dan byte tokenizer. Mulai dari sini kode memegang koneksi, retry, pembatalan, state terakumulasi dan, nanti, prompt izin. Kursus ini berganti bahasa tepat di sambungan tempat objeknya berubah.

Jadi aturannya, ditulis sekali:

Jika kode memegang weights, gradients, logits atau byte tokenizer, itu Python. Jika ia memegang koneksi, retries, membatalkan, mengakumulasi state dan meminta izin, itu TypeScript.

Sambungannya tunggal dan jatuh di sini, antara Bab 13 dan Bab 14. Tiga kriteria independen menaruhnya di sini.

Satu: ekosistem, dihitung. Semua yang dikutip paruh kiri kursus ini adalah Python, dan dari dua belas kursus yang diaudit untuk silabus ini tidak ada satu pun preseden backpropagation diajarkan dalam bahasa lain: micrograd (17,4K bintang), nanoGPT (62,8K), nanochat (57,8K), minbpe (10,7K), PyTorch (102,8K), transformers (164,9K). Menulis Bab 5 dalam TypeScript akan memutus tautan dengan sumber-sumber itu, dan tautan adalah setengah nilai dari bab yang hadir untuk dirujuk, bukan untuk ranking. Di sisi ini aritmetikanya berbalik: paket ai milik Vercel berada di 89,4 juta unduhan per bulan dan mengirimkan benda itu sendiri — loop agent tool-calling, diekspor sebagai ToolLoopAgent — jadi konsep yang dicapai kursus ini di Bab 23 memiliki implementasi referensi dalam TypeScript, meskipun, seperti diukur bab itu, belum ada yang sepakat soal namanya; Mastra berada di 27,7K bintang; dan SDK Anthropic, yang digenerasi dari satu spesifikasi, mendeklarasikan 202 endpoint di TypeScript dibanding 201 di Python — parity, bukan port basa-basi.

Dua: sumber normatif MCP. Schema spesifikasi Model Context Protocol adalah file schema.ts. Mengajarkan protokol Bab 26 dalam bahasa lain berarti mengajarkan terjemahan dari dokumen pendirinya.

Tiga: permintaan pencarian, dengan koreksi atas tebakan yang jelas. machine learning python adalah frasa paling jenuh di internet; ai agent typescript punya ekor pencarian sehatnya sendiri. Tetapi “ekosistem MCP sebagian besar TypeScript” hanya benar tergantung cara kamu menghitung: registry resmi mencantumkan 8.275 server di npm dibanding 3.603 di PyPI, sementara berdasarkan unduhan Python menang — 287 juta per bulan untuk mcp plus 72 juta untuk fastmcp dibanding 195 juta untuk @modelcontextprotocol/sdk. MCP adalah satu wilayah yang benar-benar bilingual di sini, itulah sebabnya Bab 27 menulis server yang sama dua kali alih-alih berpura-pura.

Kamu tidak bisa mempelajari semua ini dengan provider nyata. Kamu tidak bisa meminta 429 pada momen yang kamu pilih, atau socket yang menerima koneksimu lalu tidak pernah menjawab, atau stream yang berhenti di tengah kata — dan kamu akan membayar setiap eksperimen, padahal eksperimen yang menarik adalah yang kamu jalankan seratus kali.

Jadi program pertama di paruh kursus ini bukan klien. Ia adalah server bermusuhan: empat puluh baris Node polos yang berbicara dengan wire protocol yang sama seperti endpoint chat completions dan sengaja berperilaku buruk sesuai permintaan. Setiap angka dalam bab ini berasal darinya.

import { createServer } from "node:http";

const WORDS = "A tide gauge is a device that measures sea level over time .".split(" ");
const CAPACITY = 3;                      // how many requests it will serve at once
let inflight = 0;

const sse = (res, obj) => res.write(`data: ${JSON.stringify(obj)}\n\n`);

createServer(async (req, res) => {
  const url = new URL(req.url, "http://x");

  if (url.pathname === "/hang") return;                        
  if (url.pathname === "/401") { res.writeHead(401); return res.end("{}"); }

  if (inflight >= CAPACITY) {                                  
    res.writeHead(429, { "retry-after": "1" });                
    return res.end(JSON.stringify({ error: { type: "rate_limit_error" } }));
  }
  inflight++;

  const cut = Number(url.searchParams.get("cut") ?? -1);       // abandon after N chunks
  const how = url.searchParams.get("how");                     // "close" = orderly, else reset
  const max = Number(url.searchParams.get("max_tokens") ?? 999);
  const delay = Number(url.searchParams.get("delay") ?? 60);   // ms per token

  res.writeHead(200, { "content-type": "text/event-stream", "cache-control": "no-cache" });
  for (let i = 0; i < Math.min(WORDS.length, max); i++) {
    if (i === cut) {                                           
      how === "close" ? res.end() : res.destroy();             
      inflight--; return;                                      
    }
    await new Promise((r) => setTimeout(r, delay));
    sse(res, { choices: [{ delta: { content: (i ? " " : "") + WORDS[i] }, finish_reason: null }] });
  }
  sse(res, { choices: [{ delta: {}, finish_reason: max < WORDS.length ? "length" : "stop" }] });
  res.write("data: [DONE]\n\n");
  inflight--;
  res.end();
}).listen(8787);

Empat perilaku bermusuhan, masing-masing satu baris: /hang menerima socket dan tidak pernah menulis ke sana; /401 menolak key; pemeriksaan kapasitas menghasilkan 429 asli dengan header Retry-After asli begitu tiga request sudah berjalan; dan ?cut=N meninggalkan jawaban di tengah jalan, baik dengan mereset socket atau — dengan &how=close — menutupnya secara tertib, yang ternyata sangat penting. Sisanya adalah stream Server-Sent Events sungguhan: satu objek JSON per baris data:, satu baris kosong di antara event, string [DONE] di akhir.¹

Jalankan, dan sisa bab ini adalah pengukuran.

node mock-provider.mjs &
curl -N "http://127.0.0.1:8787/v1/chat?max_tokens=3"

data: {"choices":[{"delta":{"content":"A"},"finish_reason":null}]}

data: {"choices":[{"delta":{"content":" tide"},"finish_reason":null}]}

data: {"choices":[{"delta":{"content":" gauge"},"finish_reason":null}]}

data: {"choices":[{"delta":{},"finish_reason":"length"}]}

data: [DONE]

Request chat adalah daftar pesan, masing-masing dengan role. Daftar itu adalah seluruh state model: tidak ada memori antar-panggilan, dan apa pun yang kamu ingin model ketahui harus ada di dalam array yang kamu kirim kali ini. Bab 15 membahas apa yang harus dimasukkan ke dalamnya dan Bab 16 membahas biayanya, jadi di sini kita hanya melihat bentuknya.

const body = {
  model: "gpt-4.1-mini",
  messages: [
    { role: "system", content: "You explain instruments in one sentence." },
    { role: "user", content: "What is a tide gauge?" },
  ],
  stream: true,
  max_tokens: 200,
};

Role-role itu bukan dekorasi. Mereka dirender ke chat template dari Bab 11 sebelum model melihat satu token pun, itulah sebabnya mengirim role yang salah menurunkan kualitas jawaban secara diam-diam alih-alih memunculkan error.

Satu aturan tanpa pengecualian: API key tidak pernah berjalan ke klien. Tidak dalam environment variable berprefiks untuk browser, tidak dalam konstanta build-time, tidak “sementara”. Key di bundle adalah key di tagihan orang lain dalam hitungan hari. Browser berbicara ke servermu, servermu memegang key dan berbicara ke provider — dan karena servermu berada di tengah, server juga satu-satunya tempat yang bisa mengukur pengeluaran tiap pengguna, tempat accounting Bab 16 harus hidup.

Sekarang eksperimen yang menjadi dasar bab ini. Satu pertanyaan, satu mock provider yang menghasilkan tiga belas token pada 60 md masing-masing, tiga cara bertanya.

Pertama, tanpa streaming. Klien mengirim request dan menunggu seluruh body JSON.

blocking   first visible =  791 ms   complete =  791 ms   finish_reason = stop

Dua angkanya sama, dan itulah seluruh masalahnya. Selama 791 md pengguna melihat spinner, dan tidak satu kata pun tersedia lebih awal — server punya jawabannya, byte demi byte, dan memilih untuk tidak mengatakan apa-apa.

Kedua, dengan streaming. Server yang sama, jawaban yang sama, kerja total yang sama. Bedanya adalah parser.

export async function* readSSE(res: Response) {
  const reader = res.body!.getReader();
  const decoder = new TextDecoder();
  let buffer = "";
  while (true) {
    const { done, value } = await reader.read();
    if (done) break;
    buffer += decoder.decode(value, { stream: true });   
    let sep: number;
    while ((sep = buffer.indexOf("\n\n")) !== -1) {       
      const event = buffer.slice(0, sep);
      buffer = buffer.slice(sep + 2);
      for (const line of event.split("\n")) {
        if (!line.startsWith("data:")) continue;
        const payload = line.slice(5).trim();
        if (payload === "[DONE]") return;
        yield JSON.parse(payload);
      }
    }
  }
}

Tiga detail di sana adalah penyangga utama dan kebanyakan percobaan pertama melewatkan ketiganya. buffer ada karena network chunk tidak punya hubungan dengan event: satu read() bisa mengembalikan setengah event, atau dua setengah. Flag { stream: true } ada karena karakter UTF-8 multi-byte bisa terbelah di dua chunk, dan tanpanya huruf beraksen bisa menjadi karakter pengganti secara acak. Dan event dipisahkan oleh baris kosong, bukan newline, itulah sebabnya loop mencari \n\n.

streaming  first visible =   65 ms   complete =  793 ms   finish_reason = stop

Dua belas kali lebih cepat ke kata pertama, dan dua milidetik lebih lambat ke kata terakhir. Streaming tidak membuat apa pun lebih cepat. Ia mengubah apa yang dilakukan pengguna selama 790 md yang sama: membaca alih-alih menunggu. Itulah seluruh manfaatnya, manfaatnya besar, dan itulah alasan setiap produk chat melakukan streaming.

Ketiga, dengan dua puluh klien sekaligus. Mock provider melayani tiga request pada satu waktu. Tembakkan dua puluh:

jitter=true  clients=20  server capacity=3
HTTP requests made: 74   429s received: 54   200s: 20
wall clock: 7,100 ms
retries per client: 0 0 0 1 1 1 2 2 2 3 4 3 3 5 4 5 4 5 4 5
every answer identical: true

Dua puluh jawaban, tujuh puluh empat request, lima puluh empat penolakan. Tidak ada yang kehilangan apa pun, setiap klien mendapat teks yang sama, dan satu-satunya biaya yang terlihat adalah waktu. Itulah retry policy yang bekerja. Sisa bab ini membahas tiga cara ia bisa gagal.

Sebelum kegagalan, field yang hampir semua orang abaikan pada percobaan pertama. Setiap stream berakhir dengan event yang membawa finish_reason. stop berarti model memutuskan ia selesai. length berarti ia mencapai batas token, jadi jawaban terpotong di tengah kalimat dan itu bukan kesalahan model. Bab-bab berikutnya menambahkan tool_calls (Bab 18) dan content filter.

Sekarang lihat dua akhir yang tidak bisa dibedakan klien naif. Server yang sama, delay yang sama, satu dipotong oleh max_tokens dan satu lagi koneksinya ditutup bersih setelah lima token:

max_tokens=5           loop ended NORMALLY   chunks=5  finish_reason=length  text="A tide gauge is a"
socket closed cleanly  loop ended NORMALLY   chunks=5  finish_reason=null    text="A tide gauge is a"
socket destroyed       threw TypeError: terminated (UND_ERR_SOCKET)
                                             chunks=4  finish_reason=null    text="A tide gauge is"

Baca dua baris pertama dengan saksama. Teks identik. Jumlah chunk identik. Tidak ada exception di keduanya. Loop for await selesai normal pada keduanya, karena dari sudut pandang reader, body berakhir dan hanya itu yang bisa dilakukan body. Satu-satunya perbedaan dalam seluruh observasi adalah satu membawa finish_reason: "length" dan yang lain tidak membawa apa pun.

Jadi aturannya bukan “tangkap error saat streaming”. Aturannya adalah:

Stream yang berakhir tanpa finish_reason tidak berakhir. Ia berhenti.

Perlakukan finish_reason yang hilang sebagai kegagalan, selalu, dan jangan pernah persist teks itu sebagai jawaban selesai. Baris ketiga menunjukkan kasus yang lebih mudah — socket yang dihancurkan memang throw, dan juga kehilangan chunk yang sedang berjalan, itulah sebabnya teksnya satu kata lebih pendek daripada dua di atas.

Kebiasaan paling mahal produk baru adalah satu blok catch untuk semua yang dikembalikan provider. Kode-kode ini bukan variasi dari “gagal”. Mereka adalah lima instruksi, dan empat di antaranya saling bertentangan.

Garis yang penting berada di antara 4xx dan sisanya. 400 atau 401 mengembalikan jawaban yang persis sama jika kamu mengirimnya seribu kali, karena tidak ada yang berubah di kedua ujung antara percobaan. Mencoba ulang bukan kehati-hatian, melainkan delay dengan langkah ekstra. Terukur: satu klien yang melakukan enam attempt — lima retry dengan exponential backoff — dan satu yang membaca kodenya dulu.

retry everything  ->  6 requests, gave up after 6,325 ms, still HTTP 401
triage first      ->  1 request,  gave up after     4 ms, still HTTP 401

Enam detik spinner untuk mencapai jawaban yang tersedia dalam empat milidetik. Dan itu versi ringan: retries dalam produk biasanya bertumpuk — HTTP client yang retry di dalam job runner yang retry di dalam queue dengan redelivery-nya sendiri — jadi enam detik menjadi enam menit deployment yang rusak permanen terlihat seperti deployment lambat.

Triage-nya sembilan baris dan tempatnya satu saja:

export type Verdict = "retry" | "retry-after" | "fatal";

export function classify(status: number): Verdict {
  if (status === 429) return "retry-after";        
  if (status === 408 || status >= 500) return "retry";
  return "fatal";  // 400, 401, 403, 404, 422 — nothing changes by waiting
}

Dua lagi untuk daftarmu: 402, yang dipakai sebagian provider untuk “kreditmu habis” dan membutuhkan layar dengan tautan untuk membeli lebih banyak, bukan retry, dan 529 atau padanan spesifik vendornya, yang berperilaku seperti 503.

Retry itu mudah. Retry kapan adalah bagian yang punya jawaban benar terukur.

Exponential backoff adalah standar: tunggu delay dasar, gandakan setelah setiap kegagalan, berhenti di plafon. Ia ada karena server yang overload makin buruk jika klien yang baru gagal langsung kembali.

Masalahnya semua orang menggandakan dari titik awal yang sama. Jika seratus klien terkena limit pada momen yang sama — dan mereka akan begitu, karena itulah traffic spike — maka semua seratus menunggu 200 md, semua seratus retry bersama, semua seratus gagal bersama, dan semua seratus menunggu 400 md. Jadwal retry telah menyinkronkan mereka. Itu adalah thundering herd, dan randomness adalah perbaikannya.²

Satu perubahan itu — memilih secara uniform dari interval alih-alih mengambil ujung atasnya — disebut full jitter. Itu satu panggilan ke Math.random(), dan layak diukur alih-alih dipercaya begitu saja:

export const backoffNaive = (n: number, base = 200, cap = 20_000) =>
  Math.min(cap, base * 2 ** n);

export const backoffFull = (n: number, base = 200, cap = 20_000) =>
  Math.random() * Math.min(cap, base * 2 ** n);      

Seratus klien, satu server yang melayani tiga pada satu waktu, semua hal lain identik, tiga run masing-masing:

Ada dua hal di tabel itu, dan yang kedua yang penting.

Yang pertama adalah median: 226 detik melawan 2,2, faktor sekitar seratus, dengan kurang dari setengah request. Window retry tersibuk menjelaskan alasannya. Tanpa jitter, hingga 97 dari seratus klien tiba di slot 50 milidetik yang sama; server punya tiga, jadi 94 ditolak dan tidur bersama, masih tersinkronisasi, untuk melakukannya lagi dengan tunggu yang lebih lama. Dengan jitter, seratus yang sama tersebar di window yang sama dalam kelompok sekitar tiga puluh dan terkuras hampir seketika.

Yang kedua adalah variance. Tanpa jitter: 65,6 dtk, 245,7 dtk, 225,6 dtk. Dengan itu: 2,2, 2,3, 1,8. Sistem tanpa jitter tidak hanya berkinerja buruk, ia berkinerja tak terduga, karena hasilnya ditentukan oleh kecelakaan scheduling mikroskopis yang memilih tiga mana dari seratus klien tersinkronisasi yang tiba lebih dulu. Itulah tanda bug ini di produksi: endpoint yang baik-baik saja, baik-baik saja, baik-baik saja, lalu butuh empat menit, dan tidak ada perubahan darimu yang menjelaskannya.

Dan retry termurah adalah retry yang tidak pernah terjadi. Letakkan concurrency gate di depan provider — counter yang tidak pernah membiarkan lebih dari N request berjalan — dan dua puluh klien yang tadi membutuhkan 74 request dan 7,1 detik berperilaku seperti ini:

client-side gate of 3: 20 HTTP requests, 0 429s, wall 883 ms

Dua puluh request untuk dua puluh jawaban, nol penolakan, delapan kali lebih cepat. Retry adalah permintaan maaf; gate adalah tidak perlu meminta maaf.

Ketika provider mengembalikan 429, biasanya ia memberitahumu berapa lama harus menunggu, di header Retry-After.³ Angka itu bukan nasihat: provider adalah satu-satunya pihak dalam pertukaran yang tahu kapan window-nya reset.

Jadi waktu tunggu adalah yang lebih besar dari keduanya: jangan pernah kurang dari Retry-After, dan jangan pernah kurang dari backoff-mu sendiri juga, karena header memberitahumu kapan limiter memaafkanmu, bukan kapan server punya ruang.

const header = res.headers.get("retry-after");
const floor = header ? Number(header) * 1000 : 0;   // seconds -> ms
const wait = Math.max(floor, backoffFull(attempt));  

Trace dari klien paling tidak beruntung dalam run dua puluh klien menunjukkan header melakukan tugasnya. Empat backoff draw pertamanya semuanya di bawah satu detik, dan keempatnya dioverride:

t+   26ms  attempt 0  HTTP 429  -> sleep 1000 ms
t+ 1032ms  attempt 1  HTTP 429  -> sleep 1000 ms
t+ 2034ms  attempt 2  HTTP 429  -> sleep 1000 ms
t+ 3046ms  attempt 3  HTTP 429  -> sleep 1000 ms
t+ 4047ms  attempt 4  HTTP 429  -> sleep 2782 ms
t+ 6852ms  attempt 5  HTTP 200  -> sleep 0 ms

Dua catatan praktis. Retry-After bisa berupa tanggal HTTP, bukan jumlah detik, jadi parse keduanya. Dan provider melakukan rate-limit pada dua axis sekaligus — requests per minute dan tokens per minute — itulah sebabnya prompt panjang ditolak jauh di bawah batas request yang terdokumentasi. Headernya terlihat sama di kedua kasus; perbaikannya tidak.

Minta mock provider untuk /hang. Ia menerima koneksi, lalu tidak melakukan apa pun sama sekali: tanpa header, tanpa body, tanpa close. Ini bukan hal eksotis — begitulah load balancer berperilaku ketika proses di belakangnya mati tanpa menutup socket.

Dua klien, satu perbedaan:

AbortSignal.timeout(5s)   gave up after   5.0 s  (TimeoutError: The operation was aborted due to timeout)
no timeout                gave up after 300.8 s  (TypeError: fetch failed)
                          cause: HeadersTimeoutError UND_ERR_HEADERS_TIMEOUT

Tiga ratus detik. Lima menit socket tetap terbuka, slot request terisi, dan pengguna menatap spinner, berakhir dengan TypeError generik yang tidak mengatakan apa pun tentang apa yang terjadi. Angka itu bukan bug: itu default headers timeout Node, masuk akal untuk HTTP client generik dan katastrofik untuk request yang menghadap pengguna. Setiap runtime punya default semacam itu, kebanyakan orang tidak pernah mencarinya, dan satu-satunya cara menemukan milikmu adalah sengaja menggantung socket seperti yang baru saja kita lakukan.

Jadi: setiap outgoing request mendapat deadline eksplisit, dipilih olehmu.

const res = await fetch(url, {
  method: "POST",
  headers: { "content-type": "application/json", authorization: `Bearer ${key}` },
  body: JSON.stringify(payload),
  signal: AbortSignal.timeout(20_000),   
});

Untuk panggilan streaming, satu deadline tidak cukup, karena ada dua kegagalan berbeda. Yang pertama adalah stream tidak pernah terbuka: tidak ada event yang tiba sama sekali, dan sepuluh sampai tiga puluh detik tepat. Yang kedua adalah stream terbuka lalu stall: token mengalir lalu berhenti, selamanya, sementara socket tetap sehat. Timeout durasi total tidak bisa membedakan stream macet dari jawaban benar yang panjang, jadi yang kamu inginkan adalah idle timeout — timer yang di-reset oleh setiap event, menyala hanya ketika tidak ada apa pun yang tiba selama, misalnya, lima belas detik.

Cancellation adalah mesin yang sama diarahkan ke manusia. AbortSignal.timeout dan pengguna menekan Stop sama-sama tiba sebagai AbortError, jadi gabungkan keduanya dan catat mana yang menyala:

const user = new AbortController();
const signal = AbortSignal.any([user.signal, AbortSignal.timeout(20_000)]);
// stopButton.onclick = () => user.abort();

Abort penting bukan sekadar demi kerapian: token sedang dihasilkan dan ditagih saat kamu tidak mendengarkan. Bab 16 memberi harga pada itu.

Sekarang kegagalan yang menghabiskan uang, bukan waktu. Sebuah request timeout di klien, dan langkah yang tampak jelas adalah mengirimnya lagi — tetapi timeout tidak memberi tahu apa pun tentang apakah server menerimanya. Sangat sering server menerimanya, dan masih bekerja.

Terukur. Mock provider membutuhkan 780 md untuk jawaban. Klien menyerah pada 300 md dan retry. Server menghitung berapa banyak jawaban yang benar-benar ia hasilkan, yaitu apa yang akan ia tagih:

idempotency-key: no    attempt 0: TimeoutError after 300 ms  |  attempt 1: TimeoutError after 300 ms
                       answers generated (and billed): 2

idempotency-key: yes   attempt 0: TimeoutError after 300 ms  |  attempt 1: HTTP 200 (replay) id=cmpl_1
                       answers generated (and billed): 1

Tanpa key: dua generation penuh, dibayar dua kali, dan klien menerima tidak satu pun. Dengan key: server mengenali request kedua sebagai request yang sama dan langsung membalas dengan jawaban yang sudah ia hasilkan, sehingga retry menghindari tagihan ganda sekaligus menjadi attempt yang akhirnya berhasil.

Idempotency key adalah string unik yang kamu buat per operasi logis — bukan per attempt — dan kamu kirim tanpa perubahan pada setiap retry operasi itu. Server menyimpan outcome terhadap key dan memutar ulangnya. Itulah mekanisme yang dipakai payment API, karena alasan yang sama.⁴

async function send(url: string, payload: unknown) {
  const key = crypto.randomUUID();      // once per turn, not per attempt

  for (let attempt = 0; attempt < 5; attempt++) {
    const res = await fetch(url, {
      method: "POST",
      body: JSON.stringify(payload),
      headers: { "content-type": "application/json", "idempotency-key": key },  
      signal: AbortSignal.timeout(20_000),
    });
    if (res.ok) return res;
    if (classify(res.status) === "fatal") throw new Error(`HTTP ${res.status}`);
    await sleep(backoffFull(attempt));
  }
  throw new Error("out of attempts");
}

Dua batas jujur. Tidak semua provider mendukung idempotency key pada completions, dan ketika endpoint tidak idempotent, jumlah retry yang benar untuk POST yang mungkin sudah berjalan adalah nol. Dan stream yang gagal di tengah jalan tidak bisa di-replay dalam kasus umum: kamu restart dan membayar lagi, atau menyimpan teks parsial dan menandainya incomplete. Mana yang dilakukan produkmu adalah keputusan produk, bukan keputusan networking, dan layak dibuat dengan sengaja.

Klien yang ditulis dalam bab ini tidak tahu apa yang ada di balik port. Arahkan base URL-nya ke provider komersial dan ia men-stream token dari model dengan triliunan parameter. Arahkan ke server yang dibangun di atas aritmetika Bab 13 — melayani model yang kamu pretrain di Bab 10, dengan KV cache dan weights terkuantisasinya — dan kode yang sama, tanpa perubahan, men-stream token dari model yang kamu bangun.

const BASE = process.env.LLM_BASE_URL ?? "http://127.0.0.1:8000/v1";  

Satu baris itu adalah sambungan kursus ini. Di satu sisinya ada apa yang dibangun tiga belas bab pertama; di sisi lain, apa yang dibangun enam belas bab berikutnya. Batasnya bersih karena kontraknya HTTP dan SSE, dan tidak ada sisi yang tahu hal lain tentang sisi lainnya.

Perlu diperhatikan apa yang hilang ketika kamu menyeberang. Di balik endpoint komersial, kamu tidak mengendalikan weights, maupun implementasi sampling, maupun versi yang kamu ajak bicara, maupun apakah versi itu berubah pagi ini. Yang kamu kendalikan adalah kontrak: pesan yang kamu kirim, deadline yang kamu tetapkan, kode yang kamu bedakan, dan apa yang kamu lakukan ketika tidak ada yang kembali. Itu permukaan yang lebih kecil daripada yang kamu miliki di Bab 5, dan setiap bab tersisa membahas cara menggunakannya dengan baik.

Kamu kini punya klien yang streaming, menyerah tepat waktu, retry hal yang benar, dan tidak pernah retry hal yang salah. Yang dikirimkannya masih apa pun yang kamu ketik.

Bab 15 membahas konten itu, dan datang dengan disiplin. Internet penuh dengan saran prompting — tawari model tip, ancam dia, suruh dia menarik napas panjang — dan hampir tidak ada yang datang dengan pengukuran. Sebagian teknik itu menggeser output sangat besar, sebagian tidak menggeser sama sekali, dan setidaknya satu membuat tugas klasifikasi lebih buruk sambil menghabiskan lebih banyak token. Mana yang mana tidak jelas dari membacanya, dan tidak selesai lewat debat.

Jadi bab berikutnya membangun bench: enam puluh kasus dengan jawaban yang diketahui, empat varian prompt yang sama, dijalankan paralel melalui klien yang baru saja kamu tulis, ditabulasikan dengan confidence interval dari Bab 4 — karena empat varian atas dua puluh kasus tidak membedakan apa pun sama sekali. Satu kalimat mengatur seluruh bab: prompt diukur, bukan diperdebatkan.

Setiap angka di atas berasal dari mock provider, pada Node 22 melalui loopback interface, jadi latensinya lebih bersih daripada jaringan nyata mana pun. Itu disengaja: tidak satu pun kegagalan yang diukur disebabkan oleh jaringan, dan server bermusuhan yang bisa kamu restart mengajar lebih baik daripada server nyata yang harus kamu bayar dan tidak bisa kamu rusak.