Kecepatan Inferensi GLM-5 di WaveSpeed: Latensi & Throughput

Saya ingin mendapat balasan cepat saat menyusun email orientasi. GLM-5 terasa cerdas, tapi token pertama muncul cukup lama sampai saya mendapati diri menatap kursor. Bukan masalah besar, hanya jeda kecil yang terus berulang. Itu biasanya jadi sinyal bagi saya untuk memeriksa apa yang sebenarnya terjadi.

Tersedia di WaveSpeedAI — harga per-token transparan, endpoint kompatibel OpenAI. GLM 5.1 API → · Buka Playground →

Nama saya Dora. Saya menjalankan serangkaian pengujian sederhana untuk melihat seberapa besar kecepatan inferensi GLM-5 yang bisa saya peras tanpa mengubah alur kerja saya menjadi proyek ilmiah. Tidak ada yang mewah, cukup untuk merasakan perbedaannya dalam pekerjaan nyata, bukan di laboratorium.

Metodologi pengujian (perangkat keras, pengaturan, panjang prompt)

Saya mencoba tiga jalur akses:

• ​WaveSpeed​: lapisan akselerasi ringan yang sedang saya uji, yang menangani pembentukan permintaan dan caching di sisi klien/gateway.
• ​Z.ai API langsung: jalur langsung ke GLM-5 melalui penyedia.
• ​OpenRouter​: broker yang meneruskan ke penyedia model dengan beberapa fitur tambahan.

Perangkat keras dan konteks

• Klien lokal: MacBook Pro (M2 Max, 64 GB RAM). Jaringan pada fiber stabil (≈500 Mbps unduh, ≈30 ms ke endpoint AS umum).
• Sisi server: tidak ada server khusus, hanya pemanggilan klien, kecuali WaveSpeed yang menjalankan gateway lokal kecil untuk mengelola caching dan pembentukan batch.

Pengaturan yang saya pertahankan kecuali disebutkan

• Model: GLM-5 (chat/completions), temperature 0.2, top_p 0.9, max_tokens 512.
• Streaming aktif, karena begitulah cara kerja saya sesungguhnya.
• Retry dinonaktifkan kecuali untuk error jaringan.

Prompt yang saya gunakan

• Pendek: 60–80 token (instruksi ringkas dengan 2–3 batasan).
• Sedang: ~350 token (draf email dengan catatan merek dan contoh).
• Panjang: ~1.500 token (brief kecil dengan konteks produk, catatan nada, dan daftar boleh/tidak boleh).

Saya menjalankan 25 iterasi per kondisi dan mencatat:

• Waktu hingga token pertama (TTFT): dari pengiriman permintaan hingga token streaming pertama.
• Throughput (token/detik): kecepatan output streaming setelah token mulai muncul.
• Toggle untuk “mode berpikir” (jejak penalaran penyedia).

Metrik utama

Waktu hingga token pertama (TTFT)

Prompt pendek mendarat di antara 250–400 ms pada jalur yang baik. Prompt sedang mendorong TTFT lebih dekat ke 450–700 ms. Prompt panjang melewati satu detik kecuali caching aktif. Lonjakan ini tidak linier: tampaknya overhead antrean dan validasi sama pentingnya dengan panjang prompt.

Reaksi saya: di bawah 400 ms terasa responsif; apa pun di atas satu detik membuat saya keluar dari alur. Saat mengedit teks secara langsung, token pertama lebih penting dari throughput akhir.

Token per detik (throughput)

Setelah streaming dimulai, saya melihat 35–70 tok/detik pada run tanpa thinking. Itu cukup cepat untuk teks, hampir cukup untuk diff kode. Throughput turun pada output yang lebih panjang, yang saya duga disebabkan oleh pembentukan sisi server dan pemeriksaan keamanan, bukan kecepatan model murni.

Mode berpikir vs mode tidak berpikir

Dengan “thinking” aktif, TTFT melonjak 30–80%, dan throughput berkurang setengah dalam beberapa kasus. Prosa lebih koheren pada prompt yang rumit, tapi untuk pengeditan sehari-hari saya tidak membutuhkannya. Ini tidak menghemat waktu pada awalnya, tapi setelah beberapa run, saya menyadarinya mengurangi usaha mental pada pengeditan kompleks. Untuk tugas sederhana, saya biarkan nonaktif.

Cara akselerasi WaveSpeed diterapkan pada GLM-5

WaveSpeed tidak menyentuh bobot model. Ia melakukan dua hal sederhana dan berguna di sisi saya: mengurangi pekerjaan redundan dan membentuk permintaan agar penyedia dapat bergerak lebih cepat. Pada GLM-5, hal itu diterjemahkan menjadi TTFT yang lebih baik pada prompt berulang dan sedikit keuntungan pada prompt sedang.

ParaAttention dan teknik caching

• ParaAttention (catatan saya): Alih-alih membatch permintaan yang tidak terkait, WaveSpeed memparalelkan potongan yang ramah perhatian di dalam satu prompt panjang ketika mendeteksi scaffolding berulang. Dalam praktiknya, ia menggunakan ulang pembukaan (sistem + contoh bersama) dan hanya mendorong delta. Saya tidak dapat memverifikasi internalnya, tapi efeknya terlihat seperti penggunaan ulang sebagian KV di tingkat gateway.
• Caching: Ia memoize embedding untuk pembukaan prompt dan template sistem pendek. Saat saya mengiterasi tugas yang sama dengan sedikit editan, TTFT turun ~120–180 ms. Pada prompt dingin, manfaatnya lebih kecil (~40 ms) tapi tetap terasa.

Batasan yang saya temui

• Run dingin pertama masih terikat oleh upstream. Tidak ada keajaiban.
• Jika saya mengubah lebih dari ~20% prompt, cache tidak membantu.
• Mode berpikir sebagian besar menetralkan keuntungan: jejak penalaran berperilaku seperti stream terpisah.

Perbandingan: WaveSpeed vs Z.ai API langsung vs OpenRouter

Di sinilah perbedaan kecil itu penting.

• Z.ai API langsung: Konsisten. Varians TTFT terendah. Saat saya membutuhkan awal yang dapat diprediksi untuk demo, ini pilihan saya. Pada prompt panjang, penalti TTFT nyata tapi stabil.
• OpenRouter: TTFT rata-rata sedikit lebih tinggi, sedikit lebih banyak varians, tapi pengaturan mudah dan fleksibilitas perutean. Bagus saat saya mengelola banyak model. Dokumentasinya solid: lihat panduan OpenRouter.

• Lapisan WaveSpeed: TTFT terbaik pada prompt hangat dan input sedang, kemungkinan dari caching dan pembentukan permintaan. Pada prompt panjang yang benar-benar dingin, ia setara dengan akses langsung.

Tidak satu pun dari ini yang mengubah perilaku inti GLM-5. Mereka mengubah seberapa cepat saya merasakan model “bangun,” dan seberapa mulus iterasi terasa.

Jika Anda sedang memutuskan:

• Perlu performa stabil dan lebih sedikit bagian yang bergerak? Gunakan langsung melalui penyedia. Referensi: dokumentasi ZhipuAI API.
• Perlu perutean multi-model atau kunci bersama di seluruh alat? OpenRouter cukup, terima beberapa milidetik ekstra.
• Mengiterasi prompt serupa sepanjang hari? Lapisan akselerasi ringan memberikan ketenangan mental lebih dari kecepatan mentah.

Tips optimasi untuk beban kerja produksi

Yang benar-benar membantu dalam praktik:

• Hangatkan pembukaan: Pertahankan sistem prompt dan contoh bersama tetap stabil. Cache mereka, bahkan di sisi klien. Penghematan TTFT saya: ~100–200 ms pada pengulangan.
• Pangkas ekor: Batasi max_tokens sesuai kebutuhan sesungguhnya. Memotong batas 1.000 token menjadi 400 menghemat 10–20% total waktu untuk draf saya.
• Utamakan retry terstruktur: Jika harus retry, lanjutkan stream, jangan restart. Retry buta merusak TTFT.
• Kendalikan variabilitas: temperature ≤0.3 untuk produksi. Entropi lebih rendah mengurangi pemeriksaan server dan membuat throughput lebih stabil.
• Tunda mode berpikir: Aktifkan hanya pada prompt yang secara historis sering gagal. Saya memetakan “prompt sulit” dan mengaktifkan flag per rute.
• Potong konteks panjang di hulu: Ringkas referensi sekali, simpan ringkasannya, dan gunakan ulang. Run kedua dan ketiga terasa jauh lebih ringan.
• Perhatikan tokenisasi: SDK yang berbeda melakukan tokenisasi sedikit berbeda. Kunci kliennya dan ukur lagi: saya melihat regresi palsu hanya dari ini.
• Ukur p95, bukan hanya p50: Ekor yang melonjak menyebabkan lag terlihat yang diingat pengguna.

Data benchmark mentah (tabel)

Berikut snapshot dari run saya (25 iterasi per baris). Semua angka bersifat perkiraan tapi mewakili apa yang saya rasakan di keyboard.

Catatan

• “Pembukaan hangat” berarti sistem + contoh bersama di-cache oleh gateway.
• Throughput diukur setelah token pertama. Total waktu = TTFT + token_keluar / throughput.
• Jaringan stabil: saat saya menguji di Wi‑Fi hotel, semuanya terlihat lebih buruk sebesar 10–20%.

Satu pengamatan terakhir: memangkas 150 ms dari TTFT lebih berarti bagi saya daripada menambahkan 5 tok/detik, karena mengurangi jeda kecil yang memicu pergantian konteks. Itu bukan aturan universal, hanya cara otak saya menangani stream.