GLM-4.7-Flash API: 채팅 완료 및 스트리밍 빠른 시작

안녕하세요, 저는 Dora입니다. 지난주 저는 작은 문제에 부딪혔습니다: 생각보다 무거워 보이는 초안 요약 작업이었습니다. 제가 일반적으로 사용하는 도구들은 너무 느리거나 자기 역할을 너무 잘해서 문제였습니다. 저는 화려하지는 않아도 빠르고 예측 가능한 무언가를 원했습니다.

그래서 GLM-4.7-Flash API를 제대로 테스트해봤습니다(2026년 1월). 저는 “와!” 같은 감탄을 찾지 않았습니다. 저는 깔끔한 요청, 빠른 응답, 그리고 예대로 작동하는 설정을 원했습니다. 제가 설정한 것, 도움이 된 것, 어디서 잘못됐는지, 그리고 드라마 없이 속도가 필요할 때 왜 다시 사용할 것인지 알려드리겠습니다.

API 키 발급받기

저는 간단하게 시작했습니다: 키를 받고, 요청을 하고, 기초가 합리적인지 확인하세요. 저는 노출된 컨트롤이 있는 API를 감사히 여깁니다. 배경 설명으로, GLM-4.7-Flash는 Zhipu AI의 더 넓은 GLM 모델 패밀리의 일부이며, 속도와 예측 가능성에 대한 많은 설계 결정을 담고 있습니다.

WaveSpeed 대시보드 둘러보기

저는 GLM-4.7-Flash API 접근을 래핑하는 WaveSpeed 대시보드를 사용했습니다. 흐름은 충분히 명확했습니다:

프로젝트를 생성합니다(저는 제 것을 “flash-notes”라고 이름 지었습니다).
서버 키와 가벼운 클라이언트 토큰을 생성합니다. 저는 로컬 스크립트에서만 서버 키를 사용했습니다.
사용량 패널을 훑어보고 기본 속도 제한을 확인합니다. 제 것은 적당한 버스트 상한과 분당 할당량을 보여주었으며, 테스트에는 충분하지만 프로덕션 스파이크에는 부족했습니다.

제가 작은 것을 좋아했던 점: 대시보드는 최근 4xx/5xx 오류를 타임스탬프와 함께 표시합니다. 나중에 제한에 도달했을 때, 저는 추측할 필요가 없었습니다. 팀 작업을 하는 경우 역할 기반 키 가시성이 도움이 되었습니다: 저는 쓰기 가능한 키를 .env 파일에 보관하고 취소가 작동했는지 확인하기 위해 한 주 동안 한 번 회전했습니다(작동했습니다, 즉시).

기본 요청

제 첫 번째 체크포인트는 새로운 모델에 대해 제가 사용하는 것과 동일했습니다: 짧은 프롬프트, 짧은 답변, JSON에서 놀라움 없음.

API 스키마는 공식 GLM-4.7 API 가이드에 설명된 것과 같은 채팅 완성 패턴을 따릅니다. 즉, 요청 의미론을 다시 배울 필요가 없었습니다.

curl 예제

제게 일관되게 작동한 가장 간단한 호출입니다. 엔드포인트 이름은 제공자마다 다를 수 있습니다: 이것은 테스트 중에 제가 사용한 패턴입니다.

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
  }'

실행 중 알게 된 점

지연시간: 오전 미국 시간에 작은 프롬프트에 대해 첫 토큰 ~200–400 ms를 봤습니다. 짧은 답변의 경우 전체적으로 1초 미만에 완료됐습니다.
안정성: 스트리밍이 꺼졌을 때 응답은 항상 형식이 올바른 JSON이었습니다.
비용: 저는 귀하의 계획에 대해 말할 수 없지만 토큰은 사용량 로그에 명확하게 보고되었습니다. 빠른 반복을 진행할 때 중요합니다.

Python 예제

작은 스크립트의 경우 저는 환경 로드 키를 포함한 단일 함수를 선호합니다.

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

두 가지 작은 반응:

안도감: 스키마가 일반적인 채팅 완성 형식과 일치했으므로 어댑터 계층이 필요하지 않았습니다. 최소한의 변경으로 기존 도구에 드롭했습니다.
제한: 더 높은 온도에서 더 긴 출력은 때때로 방황했습니다. 이는 “Flash” 타입 모델에서 정상입니다: max_tokens로 자르고 더 엄격한 시스템 프롬프트를 통해 톤을 조정했습니다.

스트리밍 활성화

저는 텍스트를 실시간으로 형성하거나 지연시간이 완전성보다 더 중요할 때만 스트리밍을 켭니다. GLM-4.7-Flash는 이를 위해 만들어진 것 같았습니다: 빠른 첫 토큰, 매개변수가 올바르게 설정되면 안정적인 청킹.

스트림 매개변수 설정

서버 전송 이벤트(SSE)를 활성화하려면 stream: true를 설정합니다. 끝입니다. 나머지는 하우스키핑입니다: 클라이언트가 이벤트 라인을 읽고 [DONE]에서 중지하는지 확인합니다.

제가 사용한 curl 버전:

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
}'

두 가지 현장 메모:

curl에서 -N (no-buffer)을 잊으면 스트림이 멈춘 것처럼 보일 수 있습니다.
data: 프레임 대신 일반 JSON 블롭을 얻으면 stream이 부울 true이고 문자열이 아닌지 다시 확인합니다.

코드에서 청크 처리

Python에서 저는 라인별로 읽고, data: 프레임을 파싱하고, 센티넬에서 중지합니다. 이 패턴은 부드럽게 작동했습니다.

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

조금 놀랐던 것: 청크 타이밍이 안정적이었습니다. 몇 가지 더 긴 프롬프트를 시도했는데도 여전히 예측 가능한 속도를 얻었습니다. 스트리밍은 매우 짧은 답변의 경우 벽시계 시간을 절약하지 못했지만 대기 시간의 감각을 줄였습니다. 이는 터미널에서 직접 편집할 때 중요합니다.

매개변수 참조

저는 매일 몇 가지 조정만 합니다. GLM-4.7-Flash API를 사용하면 이들은 예상대로 작동했습니다.

temperature / top_p / max_tokens

temperature: 프로덕션 스타일 작업의 경우 0.1에서 0.4 사이를 유지했습니다. 낮은 숫자는 더 팽팽하고 덜 상상력 있는 표현을 주었습니다. 요약 및 지원 텍스트에 좋습니다. 0.7 이상으로 드리프트하면 접선을 기대합니다.
top_p: top_p를 약 0.9로 둡니다. 낮은 온도로 0.6으로 조였을 때 출력이 잘린 것처럼 느껴졌습니다. 글머리 기호에는 유용하지만 미묘한 글쓰기에는 덜합니다.
max_tokens: 이것이 제 안전 장치였습니다. 단문 작업의 경우 150–250은 비용을 깔끔하게 유지하고 횡설수설을 방지했습니다. 개요의 경우 600–800이 충분했습니다. 모델이 일찍 중지하면 일반적으로 버그가 아닙니다.

명확하고 사실적인 답변이 필요할 때 저에게 잘 작동했던 작은 설정:

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

이것이 실제로 중요한 이유: 속도를 원할 때 다시 쓰기를 원하지 않습니다. 보수적인 온도와 넉넉하지만 무제한이 아닌 max_tokens는 단지 표현을 자르기 위해 같은 호출을 두 번 실행하지 않아도 됩니다.

공통 오류

테스트하는 동안 저는 옆에 작은 노트북을 두었습니다. 두 가지 오류가 언급할 가치가 있을 만큼 자주 나왔습니다.

429 속도 제한

제가 본 것:

병렬 요청의 버스트(한 번에 5–10개)는 때때로 429를 유발했습니다. 새로운 키의 첫 분에 더 자주 발생했습니다.

도움이 된 것:

백오프: 지터 지수 지연(예: 200ms, 400ms, 800ms, ~3s까지)은 제가 보모할 필요 없이 스파이크를 제거했습니다.
큐: 거의 동일한 프롬프트를 짧은 배치 윈도우(100–200ms)로 병합하면 피크 속도를 약 30% 줄었습니다.UX는 변경되지 않았습니다.
대시보드 확인: 사용량 패널은 제가 문제인지 확인했습니다. 수수께끼 없음, 감사했습니다.

누가 이를 유발하는가: GLM-4.7-Flash를 UI 미리보기 및 서버 훅에 동시에 배치하는 팀입니다. 중요하면 제공자에게 더 높은 분당 상한을 물어보거나 가벼운 메모리 내 큐를 사용합니다.

유효하지 않은 JSON 응답

제가 본 것:

스트리밍이 활성화되어 있으면 일부 클라이언트는 모든 data: 프레임을 전체 JSON으로 구문 분석하려고 시도합니다. SSE가 그렇게 작동하지 않습니다. 프레임은 부분입니다.
한 번, 노이즈가 있는 연결로 잘린 이벤트 라인이 엄격한 파서를 깼습니다.

도움이 된 것:

파서 보호: data: 후의 JSON만 파싱하고 전체 메시지가 아닌 작은 델타를 포함할 것으로 예상합니다. [DONE]에서 중지합니다.
타임아웃: 합리적인 읽기 타임아웃을 유지하지만 단일 잘못된 형식의 프레임에 대해 스트림을 중지하지 않습니다.
비스트림 JSON이 필요한 경우: 스트림을 끄면 일반적으로 깔끔한 단일 JSON 개체를 얻습니다. 제 실행에서 비스트림 모드는 절대 잘못된 형식의 JSON을 생성하지 않았습니다.

한 가지 더 작은 문제: 프록시 또는 서버가 로그를 stdout에 주입하면 스트림을 오염시킬 수 있습니다. 로그를 응답 파이프와 별도로 유지합니다.

이 모든 테스트 후 저는 WaveSpeed를 고집한 이유는 매우 간단합니다: 배관에 대해 생각하고 싶지 않았습니다. 우리는 WaveSpeed를 코드와 GLM-4.7-Flash와 같은 빠른 모델 사이의 지루하고 신뢰할 수 있는 계층이 되도록 구축했습니다. 깔끔한 엔드포인트, 예측 가능한 동작, 그리고 속도 제한, 오류, 사용량 등 실제로 일어난 일을 추측 없이 알려주는 대시보드.