WaveSpeed의 GLM-5 추론 속도: 지연 시간 및 처리량

온보딩 이메일 초안을 작성하면서 빠른 답변이 필요했다. GLM-5 는 똑똑하다는 느낌이 들었지만, 첫 번째 토큰이 나오기까지 시간이 꽤 걸려서 커서만 멍하니 바라보고 있었다. 큰 문제는 아니지만, 이런 작은 멈춤이 반복되면 보통 뭔가 확인해봐야 한다는 신호가 된다.

나는 Dora다. 워크플로우를 실험실 프로젝트로 만들지 않으면서도 GLM-5 추론 속도를 얼마나 끌어올릴 수 있는지 간단한 테스트를 진행했다. 거창한 건 없고, 실제 작업에서 차이를 느낄 수 있을 정도면 충분했다.

테스트 방법론 (하드웨어, 설정, 프롬프트 길이)

세 가지 접근 경로를 시도했다:

WaveSpeed: 클라이언트/게이트웨이 측에서 요청 형성 및 캐싱을 처리하는 경량 가속 레이어로, 최근 테스트 중인 도구다.
직접 Z.ai API: 제공업체를 통해 GLM-5로 직접 연결되는 경로.
OpenRouter: 몇 가지 부가 기능과 함께 모델 제공업체로 요청을 전달하는 브로커.

하드웨어 및 컨텍스트

로컬 클라이언트: MacBook Pro (M2 Max, 64GB RAM). 안정적인 광섬유 네트워크 (다운로드 약 500Mbps, 미국 주요 엔드포인트까지 약 30ms).
서버 측: 별도 서버 없이 클라이언트 호출만 사용. 단, WaveSpeed는 캐싱 및 배치 형성을 관리하는 소형 로컬 게이트웨이를 실행한다.

별도 언급이 없는 한 고정한 설정

모델: GLM-5 (chat/completions), temperature 0.2, top_p 0.9, max_tokens 512.
스트리밍 활성화 — 실제 작업 방식이기 때문이다.
네트워크 오류를 제외한 재시도 비활성화.

사용한 프롬프트

짧음: 60–80 토큰 (2–3가지 제약 조건이 있는 간결한 지시문).
중간: 약 350 토큰 (브랜드 노트와 예시가 포함된 이메일 초안).
긴 것: 약 1,500 토큰 (제품 컨텍스트, 톤 노트, 권장/금지 목록이 포함된 소형 브리프).

각 조건당 25회 반복 실행하며 기록한 항목:

첫 번째 토큰까지 걸리는 시간 (TTFT): 요청 전송부터 첫 번째 스트리밍 토큰까지.
처리량 (tokens/s): 토큰 생성이 시작된 후의 스트리밍 출력 속도.
“thinking mode” (제공업체의 추론 추적) 토글.

주요 지표

첫 번째 토큰까지 걸리는 시간 (TTFT)

짧은 프롬프트는 좋은 경로에서 250–400ms 사이에 도달했다. 중간 프롬프트는 TTFT를 450–700ms에 가깝게 밀어올렸다. 긴 프롬프트는 캐싱이 작동하지 않으면 1초를 넘어섰다. 증가폭은 선형적이지 않았다: 프롬프트 길이만큼이나 큐잉과 유효성 검사 오버헤드가 중요하다는 느낌이었다.

내 반응: 400ms 미만은 빠릿하게 느껴지고, 1초가 넘으면 흐름이 끊긴다. 실시간으로 카피를 편집할 때는 최종 처리량보다 첫 번째 토큰이 더 중요하다.

초당 토큰 수 (처리량)

스트리밍이 시작되면 thinking 비활성화 시 35–70 tok/s를 기록했다. 카피 작업에는 충분히 빠르지만, 코드 diff에는 아슬아슬하다. 처리량은 출력이 길어질수록 떨어졌는데, 순수한 모델 속도보다는 서버 측 형성 및 안전 처리 때문인 것으로 추정된다.

Thinking 모드 vs 비-thinking 모드

“thinking”을 켜면 TTFT가 30–80% 증가하고, 처리량이 절반으로 줄어드는 경우도 있었다. 까다로운 프롬프트에서는 문장이 더 일관성 있었지만, 일상적인 초안 작성에는 필요하지 않았다. 처음에는 시간 절약이 되지 않았지만, 몇 번 실행해보니 복잡한 편집에서 정신적 부담이 줄어드는 것을 느꼈다. 단순한 작업에서는 끄고 사용한다.

WaveSpeed 가속이 GLM-5에 적용되는 방식

WaveSpeed 는 모델 가중치에 손을 대지 않았다. 내 측에서 두 가지 간단하고 유용한 일을 했을 뿐이다: 중복 작업을 줄이고 요청을 형성해 제공업체가 더 빠르게 처리할 수 있도록 했다. GLM-5에서는 반복 프롬프트의 TTFT 개선과 중간 프롬프트에서의 소폭 향상으로 나타났다.

ParaAttention 및 캐싱 기법

ParaAttention (내 메모): 관련 없는 요청을 배치 처리하는 대신, WaveSpeed는 반복되는 스캐폴딩을 감지했을 때 하나의 긴 프롬프트 내에서 attention 친화적인 청크를 병렬화한다. 실제로는 프리루드(시스템 + 공유 예시)를 재사용하고 변경된 부분만 전송했다. 내부 동작을 직접 확인할 수는 없지만, 효과는 게이트웨이 수준에서의 부분적 KV 재사용처럼 보였다.
캐싱: 프롬프트 프리루드와 짧은 시스템 템플릿의 임베딩을 메모이제이션했다. 같은 작업을 약간의 수정을 가해 반복할 때 TTFT가 약 120–180ms 감소했다. 콜드 프롬프트에서는 이점이 작았지만 (~40ms), 그래도 체감되는 수준이었다.

부딪힌 한계

첫 번째 콜드 실행은 여전히 업스트림에 의존한다. 기적은 없다.
프롬프트를 20% 이상 변경하면 캐시가 도움이 되지 않는다.
Thinking 모드는 이득을 대부분 상쇄시켰다: 추론 추적이 별도 스트림처럼 동작했다.

비교: WaveSpeed vs 직접 Z.ai API vs OpenRouter

여기서 작은 차이들이 중요해진다.

직접 Z.ai API: 일관성이 있다. TTFT 편차가 가장 낮다. 데모를 위해 예측 가능한 시작이 필요할 때 선택했다. 긴 프롬프트에서 TTFT 패널티가 실재했지만 안정적이었다.
OpenRouter: 평균 TTFT가 약간 높고, 편차도 조금 더 있지만 설정이 쉽고 라우팅 유연성이 있다. 여러 모델을 다룰 때 유용하다. 문서도 탄탄하다: OpenRouter 가이드 참고.

WaveSpeed 레이어: 웜 프롬프트와 중간 입력에서 TTFT가 가장 좋았으며, 캐싱과 요청 형성 덕분인 것으로 보인다. 진정한 콜드·긴 프롬프트에서는 직접 연결과 동률이었다.

어느 것도 GLM-5의 핵심 동작을 변경하지 않았다. 모델이 “깨어나는” 느낌이 얼마나 빠른지, 그리고 반복 작업이 얼마나 부드럽게 느껴지는지를 바꾼 것이다.

선택 기준:

안정적인 성능과 단순한 구성이 필요하다면? 제공업체를 통해 직접 연결하라. 참고: ZhipuAI API 문서.
멀티모델 라우팅이나 도구 간 공유 키가 필요하다면? OpenRouter가 적합하다. 몇 밀리초 추가는 감수하면 된다.
하루 종일 비슷한 프롬프트를 반복 작업한다면? 경량 가속 레이어는 순수한 속도보다 정신적 안정감으로 보답한다.

프로덕션 워크로드를 위한 최적화 팁

실제로 도움이 된 것들:

프리루드를 워밍업하라: 시스템 프롬프트와 공유 예시를 안정적으로 유지하라. 클라이언트 측에서라도 캐시하라. 내가 얻은 TTFT 절약: 반복 시 약 100–200ms.
꼬리를 잘라라: max_tokens를 실제로 필요한 수치로 제한하라. 1,000 토큰 상한을 400으로 줄이자 초안 작성 전체 시간이 10–20% 단축됐다.
구조적 재시도를 선호하라: 재시도가 필요하다면, 스트림을 재시작하지 말고 재개하라. 무작정 재시도는 TTFT를 망쳤다.
변동성을 통제하라: 프로덕션에서는 temperature ≤ 0.3. 낮은 엔트로피는 서버 처리를 줄이고 처리량을 더 안정적으로 만들었다.
thinking 모드를 미루어라: 과거에 오류가 자주 발생했던 프롬프트에만 활성화하라. “어려운 프롬프트”를 매핑하고 경로별로 플래그를 전환한다.
긴 컨텍스트를 업스트림에서 청크로 나눠라: 참고자료를 한 번 요약하고, 요약본을 저장해 재사용하라. 두 번째, 세 번째 실행은 확연히 가벼워진다.
토크나이제이션을 주시하라: SDK마다 토크나이제이션이 미묘하게 다르다. 클라이언트를 고정하고 다시 측정하라. 이것 때문에만 가짜 성능 저하를 경험한 적이 있다.
p50이 아닌 p95를 측정하라: 뾰족한 꼬리가 사용자들이 기억하는 체감 지연을 만들어낸다.