GLM-4.7-Flash API: Panduan Cepat Chat Completions & Streaming

GLM-4.7-Flash API: Panduan Cepat Chat Completions & Streaming

Hei, nama saya Dora. Minggu lalu saya mengalami sedikit hambatan: tugas ringkasan draf yang terasa lebih berat dari seharusnya. Alat yang biasanya saya gunakan terlalu lambat atau terlalu canggih untuk keperluan mereka. Saya menginginkan sesuatu yang cepat dan dapat diprediksi, bahkan jika tidak mencolok.

Jadi saya memberikan GLM-4.7-Flash API uji coba yang tepat (Januari 2026). Saya tidak mencari “wow”. Saya menginginkan permintaan yang bersih, respons cepat, dan pengaturan yang berperilaku sesuai dengan yang mereka katakan. Berikut adalah apa yang saya atur, apa yang membantu, di mana ia tersandung, dan mengapa saya akan menggunakannya lagi ketika saya membutuhkan kecepatan tanpa drama.

Dapatkan Kunci API Anda

Saya memulai dengan sederhana: dapatkan kunci, buat permintaan, lihat apakah dasar-dasarnya terasa masuk akal. Saya menghargai API yang tidak menyembunyikan pengontrolnya. Untuk latar belakang, GLM-4.7-Flash adalah bagian dari keluarga model GLM yang lebih luas oleh Zhipu AI, yang membingkai banyak keputusan desain di sekitar kecepatan dan dapat diprediksi.

Panduan Dashboard WaveSpeed

Saya menggunakan dasbor WaveSpeed, yang membungkus akses ke GLM-4.7-Flash API. Alurnya cukup sederhana:

  • Buat proyek (saya menamai milik saya “flash-notes”).
  • Hasilkan kunci server dan token klien ringan. Saya hanya menggunakan kunci server dalam skrip lokal saya.
  • Tinjau panel penggunaan untuk mengetahui batas laju default. Milik saya menunjukkan batas lonjakan sederhana dan kuota per menit, cukup untuk tes tetapi bukan lonjakan produksi.

Hal kecil yang saya sukai: dasbor menampilkan kesalahan 4xx/5xx terbaru dengan stempel waktu. Ketika saya mencapai batas nanti, saya tidak harus menebak-nebak. Jika Anda melakukan pekerjaan tim, visibilitas kunci berbasis peran membantu: saya menyimpan kunci dengan kemampuan tulis dalam file .env dan memutar sekali selama minggu untuk memeriksa bahwa pencabutan berhasil (itu berhasil, secara instan).

Permintaan Dasar

Pos pemeriksaan pertama saya adalah yang sama saya gunakan untuk model baru apa pun: prompt pendek, jawaban pendek, dan tidak ada kejutan dalam JSON.

Skema API mengikuti pola penyelesaian percakapan yang sama yang diuraikan dalam panduan GLM-4.7 API resmi, yang berarti saya tidak perlu mempelajari kembali semantik permintaan.

Contoh curl

Berikut adalah panggilan paling sederhana yang bekerja secara konsisten untuk saya. Nama titik akhir dapat bervariasi antar penyedia: ini adalah pola yang saya gunakan selama tes.

curl https://api.wavespeed.ai/v1/chat/completions \
  -H "Authorization: Bearer $WAVESPEED_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "GLM-4.7-Flash",
    "messages": [
      {"role": "system", "content": "You are concise and helpful."},
      {"role": "user", "content": "Summarize this in one sentence: GLM-4.7-Flash API quick test."}
    ],
    "temperature": 0.2,
    "max_tokens": 120
  }'

Catatan dari jalannya

  • Latensi: Saya melihat token pertama ~200–400 ms pada prompt kecil di tengah pagi (waktu AS). Penyelesaian end-to-end selesai dalam waktu kurang dari satu detik untuk balasan pendek.
  • Stabilitas: Respons adalah JSON yang terbentuk dengan baik setiap kali streaming dimatikan.
  • Biaya: Saya tidak bisa berbicara tentang paket Anda, tetapi token dilaporkan dengan jelas dalam log penggunaan. Itu penting ketika Anda mendorong iterasi cepat.

Contoh Python

Untuk skrip kecil, saya lebih suka satu fungsi dengan kunci yang dimuat dari lingkungan.

import os
import requests

API_KEY = os.getenv("WAVESPEED_API_KEY")
BASE_URL = "https://api.wavespeed.ai/v1/chat/completions"

payload = {
    "model": "GLM-4.7-Flash",
    "messages": [
        {"role": "system", "content": "You are concise and helpful."},
        {
            "role": "user",
            "content": "Give me 3 bullet points on maintaining a calm writing workflow."
        }
    ],
    "temperature": 0.3,
    "max_tokens": 180
}

headers = {
    "Authorization": f"Bearer {API_KEY}",
    "Content-Type": "application/json"
}

resp = requests.post(BASE_URL, json=payload, headers=headers, timeout=30)
resp.raise_for_status()

data = resp.json()
print(data["choices"][0]["message"]["content"])  # typical OpenAI-style schema

Dua reaksi kecil:

  • Lega: Skema cocok dengan format penyelesaian percakapan biasa, yang berarti tidak ada lapisan adaptor. Saya menjatuhkannya ke dalam alat yang sudah ada dengan perubahan minimal.
  • Batasan: Output yang lebih panjang pada suhu yang lebih tinggi kadang-kadang berputar. Itu normal untuk model tipe “Flash”: saya memotong dengan max_tokens dan nudged tone melalui prompt sistem yang lebih ketat.

Aktifkan Streaming

Saya hanya menghidupkan streaming ketika saya membentuk teks secara langsung atau ketika latensi lebih penting daripada kelengkapan. GLM-4.7-Flash terasa dibuat untuk ini: token pertama cepat, chunking stabil setelah parameter diatur dengan benar.

Pengaturan Parameter Aliran

Untuk mengaktifkan peristiwa yang dikirim server (SSE), saya atur stream: true. Itu saja. Sisanya adalah pekerjaan rumah: pastikan klien Anda membaca baris acara dan berhenti di [DONE].

versi curl yang saya gunakan:

curl https://api.wavespeed.ai/v1/chat/completions \
-H "Authorization: Bearer $WAVESPEED_API_KEY" \
-H "Content-Type: application/json" \
-N \
-d '{
  "model": "GLM-4.7-Flash",
  "messages": [
    {"role": "user", "content": "Draft a two-sentence intro about quiet tools."}
  ],
  "stream": true,
  "temperature": 0.2,
  "max_tokens": 120
}'

Dua catatan lapangan:

  • Jika Anda lupa -N (no-buffer) dengan curl, aliran dapat terlihat macet.
  • Jika Anda mendapatkan blob JSON biasa daripada acara, periksa kembali bahwa stream adalah boolean true dan bukan string.

Tangani Potongan dalam Kode

Dalam Python, saya membaca baris demi baris, mengurai frame data:, dan berhenti di sentinel. Pola ini bekerja dengan mulus.

import os, json, requests

API_KEY = os.getenv("WAVESPEED_API_KEY")
BASE_URL = "https://api.wavespeed.ai/v1/chat/completions"

payload = {
    "model": "GLM-4.7-Flash",
    "messages": [{"role": "user", "content": "Write a calm closing paragraph."}],
    "stream": True,
    "temperature": 0.2,
}

with requests.post(
    BASE_URL,
    json=payload,
    headers={
        "Authorization": f"Bearer {API_KEY}",
        "Content-Type": "application/json"
    },
    stream=True,
    timeout=60
) as r:
    r.raise_for_status()
    for line in r.iter_lines(decode_unicode=True):
        if not line or not line.startswith("data:"):
            continue
        data = line[len("data:"):].strip()
        if data == "[DONE]":
            break
        try:
            delta = json.loads(data)["choices"][0]["delta"].get("content", "")
            print(delta, end="", flush=True)
        except (KeyError, json.JSONDecodeError):
            # Skip malformed or heartbeat frames gracefully
            continue

print()  # newline

Apa yang sedikit mengejutkan saya: waktu potongan stabil. Saya mencoba beberapa prompt yang lebih panjang dan masih mendapat pacuan yang dapat diprediksi. Streaming tidak menghemat waktu dinding pada balasan yang sangat pendek, tetapi itu mengurangi rasa menunggu saya, yang penting ketika saya mengedit langsung di terminal.

Referensi Parameter

Saya hanya menyesuaikan beberapa knob hari demi hari. Dengan GLM-4.7-Flash API, ini berperilaku seperti yang diharapkan.

temperature / top_p / max_tokens

  • temperature: Saya menyimpan ini antara 0,1 dan 0,4 untuk tugas berasa produksi. Angka yang lebih rendah memberikan frasa yang lebih ketat dan kurang imajinatif, yang baik untuk ringkasan dan teks dukungan. Jika Anda melayang di atas 0,7, harapkan garis singgung.
  • top_p: Saya meninggalkan top_p sekitar 0,9. Ketika saya mengencangkannya menjadi 0,6 dengan suhu rendah, output terasa dipotong, berguna untuk poin-poin bullet, kurang begitu untuk tulisan bernuansa.
  • max_tokens: Ini adalah pagar saya. Untuk tugas bentuk pendek, 150–250 menyimpan biaya rapi dan mencegah memulung. Untuk garis besar, 600–800 cukup. Jika model berhenti lebih awal, biasanya ini, bukan bug.

Pengaturan kecil yang bekerja dengan baik untuk saya ketika saya membutuhkan jawaban yang rapi dan faktual:

{
  "model": "GLM-4.7-Flash",
  "temperature": 0.2,
  "top_p": 0.9,
  "max_tokens": 200
}

Mengapa ini penting dalam praktik: ketika Anda menginginkan kecepatan, Anda tidak menginginkan penulisan ulang. Suhu konservatif dengan max_tokens yang murah hati tetapi tidak terbatas menyelamatkan saya dari harus menjalankan panggilan yang sama dua kali hanya untuk memangkas frasa.

Kesalahan Umum

Saya menyimpan buku catatan kecil di samping saya saat pengujian. Dua kesalahan muncul cukup untuk bernilai penyebutan biasa.

429 Batas Laju

Apa yang saya lihat:

  • Ledakan permintaan paralel (5–10 sekaligus) kadang-kadang memicu 429. Ini terjadi lebih banyak dalam menit pertama kunci segar.

Apa yang membantu:

  • Backoff: jittered exponential delay (mis., 200 ms, 400 ms, 800 ms, hingga ~3 s) menghapus lonjakan tanpa saya harus menjaga.
  • Antrian: menggabungkan prompt yang hampir identik ke dalam jendela batch pendek (100–200 ms) mengurangi laju puncak saya dengan ~30% tanpa mengubah UX.
  • Pemeriksaan dasbor: panel penggunaan mengkonfirmasi ketika saya adalah masalahnya. Tidak ada misteri di sana, yang saya hargai.

Siapa yang ini memicu: tim yang memasang GLM-4.7-Flash ke dalam pratinjau UI dan hook server secara bersamaan. Jika itu penting, tanyakan penyedia Anda tentang tutup per menit yang lebih tinggi atau gunakan antrian dalam memori yang ringan.

Respons JSON Tidak Valid

Apa yang saya lihat:

  • Ketika streaming menyala, beberapa klien mencoba mengurai setiap frame data: sebagai JSON penuh. Itu bukan cara SSE bekerja. Frame sebagian.
  • Sekali, dengan koneksi bising, saya mendapatkan baris acara yang dipotong yang memecahkan parser ketat.

Apa yang membantu:

  • Lindungi parser Anda: hanya mengurai JSON setelah data: dan harapkan itu berisi delta kecil, bukan pesan lengkap. Berhenti di [DONE].
  • Timeouts: simpan timeout pembacaan yang wajar tetapi hindari membunuh aliran untuk satu frame yang salah bentuk.
  • Jika Anda membutuhkan JSON non-aliran: matikan aliran dan Anda biasanya akan mendapatkan satu objek JSON yang bersih. Dalam jalanku, mode non-aliran tidak pernah menghasilkan JSON yang salah bentuk.

Satu lagi masalah kecil: jika proxy atau server Anda menyuntikkan log ke stdout, itu dapat mengotori aliran. Simpan log terpisah dari pipa respons.

Setelah semua pengujian ini, alasan saya tetap dengan WaveSpeed cukup sederhana: saya tidak ingin memikirkan tentang pipa. Kami membangun WaveSpeed menjadi lapisan yang membosankan dan andal antara kode Anda dan model cepat seperti GLM-4.7-Flash. Titik akhir yang bersih, perilaku yang dapat diprediksi, dan dasbor yang memberi tahu Anda apa yang benar-benar terjadi ketika sesuatu salah—batas laju, kesalahan, penggunaan—tanpa dugaan.

Jika Anda memasang Flash ke dalam ringkasan, draf, pratinjau UI, atau pekerjaan latar belakang dan hanya menginginkannya tetap di luar jalan, itulah celah yang kami coba isi. → Klik di sini!