Keuntungan:
- Dapat menjelaskan apa itu streaming, jenis acara dan mengapa diperlukan.
- max_tokens menangkap batas waktu dan hubungan keluaran sepanjang 128 ribu
- Dapat menentukan pilihan yang tepat antara permintaan streaming dan non-streaming sesuai dengan beban kerja
Anda mungkin telah memperhatikan bahwa dalam antarmuka obrolan, responsnya "diketik" kata demi kata. Ini bukanlah perkembangan visual; Ini adalah hasil dari teknik yang disebut streaming dan seringkali wajib untuk integrasi LLM berkualitas produksi. Dalam unit ini, Anda akan mempelajari apa itu flow, apa saja isi dari flow, hubungannya dengan output yang panjang dan timeout, serta kapan menggunakan flow dan kapan tidak. Kami akan membahas topik ini melalui tugas nyata seorang profesional — asisten langsung, pembuatan laporan panjang, pemrosesan batch.
Apa itu Aliran?
Dengan permintaan non-streaming (sinkron), Anda menunggu hingga model menghasilkan seluruh respons; Ketika jawabannya sudah siap, jawabannya akan tiba dalam keadaan utuh. Dalam permintaan streaming, server mengirimkan respons sepotong demi sepotong saat model dihasilkan. Secara teknis, hal ini dilakukan dengan peristiwa yang dikirim oleh server (SSE — Peristiwa Terkirim Server, sebuah metode di mana server mengirimkan peristiwa kecil secara berurutan melalui koneksi terbuka).
Perbedaannya menjadi jelas dalam pengalaman pengguna: pada respons yang membutuhkan waktu 8 detik, pengguna non-streaming menatap layar kosong selama 8 detik; Pengguna streaming melihat kata pertama dalam ~0,5 detik dan teks mulai mengalir. Latensi yang dirasakan—waktu tunggu yang dirasakan pengguna—sangat berkurang, sementara total waktu tetap tidak berubah.
Jenis Aliran Peristiwa
Arus adalah rangkaian peristiwa. Secara konseptual, alur umumnya seperti ini:
kejadian
Artinya
pesan_mulai
Responsnya dimulai; Informasi header seperti model dan ID telah tiba.
konten_block_start
Blok konten (misalnya teks) dimulai
konten_block_delta
Sepotong kecil teks (delta) tiba; kamu mengumpulkan ini
konten_block_stop
blok selesai
pesan_delta
Informasi akhir yang diperbarui seperti stop_reason dan penggunaan
pesan_berhenti
Balas selesai
Kode Anda secara berurutan menggabungkan potongan teks dalam peristiwa content_block_delta; Anda akan mendapatkan teks yang sama persis dengan respons non-streaming. penggunaan (nomor token) biasanya jelas di akhir aliran — Anda melacak biaya setelah aliran selesai.
Tip: Sebagian besar SDK resmi (Software Development Kit — pustaka siap pakai penyedia) menyediakan bantuan yang mengumpulkan aliran untuk Anda (misalnya stream.get_final_message()). Anda tidak perlu mengelola semua trek secara manual; Gunakan bantuan ini jika Anda menginginkan teks lengkap, memproses peristiwa individual tetapi untuk pencetakan langsung.
Respons Panjang, max_tokens dan Timeout
Penyebab streaming yang kedua dan lebih teknis adalah batas waktu. Jika permintaan HTTP tidak diselesaikan dalam jangka waktu tertentu, klien akan memutuskan koneksi. Saat Anda meminta keluaran yang besar dari model (misalnya laporan sebanyak 40.000 token), panggilan non-aliran mungkin melebihi batas dan waktu habis ini — permintaan akan gagal, dan Anda harus membayar untuk token yang dihasilkan.
Model modern dapat menghasilkan hingga 128.000 token dalam satu permintaan. Namun aturan praktisnya jelas: gunakan stream jika nilai `max_tokens` tinggi (kira-kira di atas 16.000). Streaming menjaga koneksi tetap hidup dan mencegah waktu habis; Anda juga akan melihat kemajuan secara instan.
- `max_tokens`: Token keluaran maksimum yang dapat dihasilkan model; langit-langit yang keras. Jika terjadi interupsi, stop_reason max_tokens dikembalikan.
- Jendela konteks: Jendela yang memuat jumlah input + output. max_tokens adalah batas atas output; Jangan campur keduanya.
Perhatian: Melemparkan permintaan non-aliran dengan max_tokens yang besar adalah kesalahan klasik dalam produksi. Tanpa respons, koneksi terputus, pengguna melihat kesalahan, dan biaya token terbuang percuma. Keluaran panjang = aliran.
Kapan Harus Mengalir dan Kapan Tidak?
Status
preferensi
Mengapa
Obrolan langsung / asisten
mengalir
Latensi dirasakan turun, pengguna melihat kemajuan
Pembuatan laporan/dokumen yang panjang
mengalir
Mencegah batas waktu, membawa keluaran besar dengan aman
Klasifikasi pendek (misalnya tag kata tunggal)
tidak ada aliran
Outputnya sudah kecil; kompleksitas tambahan tidak diperlukan
Pemrosesan batch
tanpa aliran/batch
Hasil tidak langsung terlihat; Lihat unit 7
Langkah otomatisasi (di latar belakang)
Biasanya tidak ada aliran
Anda meneruskan hasilnya ke langkah berikutnya, tidak ada tampilan langsung
Prompt/Templat yang Dapat Disalin
Aliran itu sendiri bukanlah sebuah prompt, namun prompt sangat penting untuk mengelola output yang dihasilkan oleh aliran tersebut. Dalam produksi yang panjang dan mengalir, penerapan struktur dari depan akan meningkatkan kualitas dan ketertelusuran.
# Bagilah laporan panjang menjadi beberapa bagian (sehingga kemajuannya terlihat dalam alurnya) Tulis laporan dengan judul berikut, dengan urutan yang persis seperti ini. Mulailah setiap judul dengan '## ':## Ringkasan## Temuan## Rekomendasi## Langkah selanjutnya
# Berikan panjang target untuk menghindari pemotongan dalam produksi yang panjang. Total teks akan menjadi sekitar 800 kata. Jaga porsinya tetap seimbang; Jangan tinggalkan setengah kalimat di akhir.
# Segera berikan kalimat pertama untuk asisten streaming. Berikan jawaban langsung satu kalimat terlebih dahulu, lalu jelaskan secara detail. Jadi pengguna langsung melihat hasilnya sambil menunggu.
# Jaga struktur keluaran yang panjang (sehingga dapat diurai nanti) Keluarkan keluaran di bagian ini dan tandai setiap bagian dengan header '###' terpisah sehingga saya dapat menguraikannya secara terprogram: ### PENDAHULUAN ### BODY ### SOURCES
Prompt lemah / Prompt kuat (produksi lama)
# LEMAHTulis laporan yang panjang dan terperinci tentang topik ini.
# KUATTulis laporan sekitar 900 kata tentang topik ini. Judul: ## Ringkasan, ## Analisis, ## Risiko, ## Rekomendasi. Setiap judul maksimal 3 paragraf. Jangan tinggalkan setengah kalimat di akhir.
Versi yang kuat; Ini menentukan panjang, struktur dan kualitas hasil akhir terlebih dahulu. Saat bagian mulai mengalir, pengguna melihat kemajuan dengan jelas dan mengatur sendiri panjangnya terhadap risiko gangguan model.
Tiga Kasus Mini
Kasus 1 — Keluhan layar kosong. Asisten klien tim konsultan merespons tanpa mengalir; respons rata-rata membutuhkan waktu 7 detik, pengguna bertanya "apakah membeku?" dia mengeluh. Begitu saya mulai memahami alurnya, kata pertama muncul dalam ~0,6 detik; Total waktu tetap sama, namun keluhan "lambat" hampir hilang.
Kasus 2 — Laporan kedaluwarsa. Sebuah tim keuangan sedang membuat laporan kuartal setebal 30 halaman; Dengan max_tokens: 30000, permintaan tanpa aliran akan terhenti dalam batas waktu klien 60 detik, permintaan akan gagal — dan token yang dihasilkan akan ditulis ke faktur. Mereka mengikuti arus; sambungan tetap aktif, laporan disampaikan secara lengkap, dan biaya-biaya yang sia-sia dihilangkan.
Kasus 3 — Aliran yang tidak perlu. Tim operasi memberi label email masuk sebagai “mendesak/biasa”; Outputnya adalah satu kata, tetapi mereka biasanya menggunakan flow. Alur tersebut tidak memberikan manfaat dalam respons satu kata, sehingga membuat kode menjadi terlalu rumit. Saat saya beralih ke flowless, kodenya disederhanakan dan perilakunya tetap sama. Pelajaran: streaming berharga dalam keluaran yang panjang/langsung, tidak di semua tempat.
Kesalahan umum
- Tidak menggunakan aliran dalam keluaran panjang: Waktu habis dan biaya token terbuang.
- Menggunakan streaming dalam keluaran singkat: Kompleksitas yang tidak perlu, tidak ada manfaatnya.
- Tidak mencentang `stop_reason` di akhir streaming: respons terpotong dengan max_tokens dianggap selesai.
- Penggabungan delta yang salah: Penjumlahan manual dengan pembantu SDK menghasilkan kesalahan urutan/bagian yang hilang.
- Mencoba membaca `penggunaan` di tengah-tengah: Nomor token biasanya menjadi jelas di akhir; Pantau biaya di akhir.
- Salah mengira streaming sebagai pemotongan biaya: Streaming meningkatkan pengalaman dan daya tahan; Itu tidak mengubah harga token.
Lebih Dalam: Penghancuran Arus dan Ketahanan
Streaming adalah koneksi langsung; Ini adalah kekuatan sekaligus kerentanannya. Jika koneksi terputus di tengah-tengah (fluktuasi jaringan, waktu habis klien), Anda akan menyimpan teks yang telah Anda kumpulkan sejauh ini, namun responsnya tidak lengkap. Klien streaming berkualitas produksi harus siap menghadapi hal ini: klien tersebut tidak boleh memperlakukan sebagian teks sebagai "respons yang telah selesai", dan juga tidak boleh mempertimbangkan respons yang harus diselesaikan hingga ia melihat peristiwa message_stop.
Kehalusan kedua adalah bahwa aliran tidak mengubah biaya. Apakah Anda menerima respons dengan atau tanpa streaming tidak memengaruhi harga token; aliran hanya meningkatkan pengalaman dan daya tahan. Jadi “kalau kita streaming, apakah lebih murah?” Jawaban atas pertanyaannya adalah tidak — untuk biaya, lihat unit ke-5 dan ke-6 (pemilihan model, cache).
Poin ketiga adalah mencapai keseimbangan praktis: dengan asisten langsung, kedatangan kata pertama yang cepat (keterlambatan yang dirasakan) sangat dihargai; Oleh karena itu, meminta model untuk memasukkan jawabannya secara langsung dan memberikan hasil singkat terlebih dahulu (melalui perintah sistem di unit ke-4) akan melipatgandakan manfaat alur tersebut. Jika pengguna melihat sesuatu yang berarti pada detik pertama, mereka dengan sabar menunggu detail selanjutnya. Di sisi lain, aliran tidak memiliki kontribusi terhadap pekerjaan yang berjalan di latar belakang, yang outputnya masuk ke langkah otomatisasi berikutnya; Satu-satunya kriteria yang ada adalah pekerjaan diselesaikan dengan benar dan lengkap.
Singkatnya
Streaming mengambil respons sepotong demi sepotong, mengurangi latensi yang dirasakan dan mencegah batas waktu pada throughput yang besar. Hampir wajib untuk asisten langsung dan produksi dokumen panjang; Ini tidak diperlukan untuk pekerjaan pendek/latar belakang. Dalam produksi yang panjang, menerapkan struktur dan panjang dari depan dengan cepat akan meningkatkan kualitas dan ketertelusuran; Ketika alur selesai, stop_reason dan usage pasti dicentang.
Tugas aplikasi
Pilih dua skenario: satu skenario live/panjang (misalnya laporan ke pelanggan), satu skenario pendek/latar belakang (misalnya pemberian tag). (1) Putuskan dan jelaskan apakah Anda akan menggunakan flow untuk masing-masingnya. (2) Tulis prompt yang menerapkan struktur skrip panjang (judul + panjang target). (3) Tentukan nilai max_tokens. (4) Cantumkan pemeriksaan apa yang akan Anda lakukan dengan stop_reason dan penggunaan di akhir alur.
daftar periksa
- [ ] Saya dapat menjelaskan apa itu streaming dan bagaimana hal itu mengurangi latensi yang dirasakan.
- [ ] Saya memahami jenis peristiwa dasar penggabungan aliran dan delta.
- [] Saya tahu tentang perlunya streaming dengan max_tokens yang besar dan hubungan batas waktu.
- [ ] Saya dapat memutuskan beban kerja mana yang akan saya gunakan streaming dan mana yang tidak.
- [ ] Saya dapat memeriksa stop_reason dan penggunaan di akhir streaming.