10월 7일에 GLM-5.3 Fast라는 새 모델 ID가 등장했습니다. 이름만 보면 “GLM-5.4급 신모델인가?” 싶지만, 현재 제공 정보를 기준으로 정확히는 그렇지 않습니다. 같은 계열의 capability를 유지하면서 inference acceleration으로 약 1.5~2배 빠른 출력을 노리는 latency-optimized serving option에 가깝습니다. 최대 1M 컨텍스트를 지원하고, 제공처·가격·tool calling 지원은 provider마다 다릅니다.

이 글은 “새로운 지능 모델”이 아니라 “빠른 inference lane”으로 읽는 법을 정리합니다.

먼저 GLM-5.3 본체를 복습하자

Fast를 보기 전에 기준 모델의 위치를 잡아야 합니다. Z.ai 계열 공개 수치 기준으로 GLM-5.3은 GLM-5.2 대비 코딩·Agent 벤치마크에서 큰 향상을 보였다고 보고돼 있습니다.

벤치마크 GLM-5.3 보고 수치 읽는 법
Terminal-Bench 3.0 28.3 터미널 환경 실작업 수행
DeepSWE v1.1 66.9 장시간 소프트웨어 공학 과제
FrontierSWE 78.1 프런티어급 SWE 과제
AutomationBench 48.2 (v1.0.6 기준) 비즈니스 워크플로 자동화

Z.ai는 Max effort 기준 자체 Code Bench에서 5.2보다 더 높은 성공률을 더 적은 output token으로 기록했다고도 밝힙니다. 토큰을 적게 쓰고 성공한다는 말은 비용뿐 아니라 속도에도 직접 연결됩니다. 출력 토큰이 줄면 같은 tokens/sec에서도 작업이 먼저 끝나니까요.

이 기준선을 깔고 Fast를 보면 헷갈리지 않습니다. Fast의 약속은 “더 똑똑해진다”가 아니라 “같은 일을 더 빨리 끝낸다”입니다.

Fast의 정체: 같은 지능, 다른 속도

LLM Gateway 쪽 설명을 기준으로 정리하면 이렇습니다.

GLM-5.3        : 기준 모델 (capability의 기준점)
GLM-5.3 Fast   : 같은 capability + inference acceleration
                 → 약 1.5~2× 빠른 output 목표
                 → 최대 1M context 지원
                 → 새 모델 ID로 제공 (별도 lane)

중요한 뉘앙스 세 가지:

  • 모델 교체가 아니라 lane 선택입니다. 지능이 바뀌는 게 아니라 서빙 경로가 바뀝니다. 점수표가 아니라 지연·처리량 기준으로 고릅니다.
  • 가격이 따로 매겨집니다. 예로 LLM Gateway 경유 SCX.ai 제공 기준은 입력 $2.80, 출력 $8.80 per 1M 토큰 수준으로 표기돼 있습니다. provider·시점에 따라 다르니 “Fast = 무조건 저렴”으로 외우면 안 됩니다.
  • tool calling·구조화 출력 지원이 provider마다 다릅니다. 현재 LLM Gateway 기준 안내에서는 tool calling과 구조화 JSON 출력을 지원하지 않는다고 명시돼 있습니다. Agent에 붙이기 전에 반드시 사용하려는 provider의 스펙을 확인하세요. 이 한 줄을 놓치면 “빠른데 일을 못 시키는” 모델이 됩니다.

GLM 계열의 다른 fast 라인도 참고가 됩니다. GLM-5.3-Flash(X)는 200 tokens/s급 속도를 내세우는 cost-optimized 계열이고, 320B-A18B MoE에 1M 컨텍스트, Terminal-Bench 2.1에서 84.3 같은 수치가 공개돼 있습니다. 이름에 Fast·Flash·Turbo가 붙을수록 “무엇을 희생하고 무엇을 샀는지”를 따져야 합니다. 보통은 지능·도구 지원·긴 문맥 안정성 중 어딘가가 조정됩니다.

Agent UX에서는 1~2점이 아니라 latency가 체감을 정한다

벤치마크 1~2점 차이는 실무에서 오차처럼 느껴질 때가 많습니다. 반면 token generation latency는 매일 체감됩니다. 속도·지연시간 가이드에서 정리한 것처럼 지표는 세 개로 나눠야 합니다.

요청 ──→ [생각 + 입력 처리] ──→ 첫 토큰 ──→ 토큰 술술 ──→ 작업 완성
          └──── TTFT ────┘                        └── tokens/sec ──┘
          └────────────── 작업 완료 시간 (wall-clock) ───────────┘

Fast lane이 건드리는 건 주로 가운데에서 오른쪽 구간입니다. 출력이 1.5~2배 빨라지면:

  • 짧은 답변: 체감이 조금 좋아진다 (TTFT가 지배적이라 효과 제한)
  • 긴 답변·Agent trace: 체감이 크게 좋아진다 (출력 토큰이 많아서)
  • 재시도 많은 작업: 효과가 곱해진다 (시도 횟수 × 매 시도 시간)

그래서 Coding Agent 모델 평가에서는 quality만 재면 안 됩니다. 최소 이 다섯 개를 같이 재야 합니다.

task success (성공률, 기준 사전 정의)
TTFT (첫 토큰까지, 초)
tokens/sec (출력 속도)
total wall-clock (끝까지 걸린 시간)
cost (성공 1건당 총비용)

성공률 얘기가 나오면 성공 1건당 비용 글의 계산을 그대로 가져오세요. 토큰 단가가 아니라 성공까지 든 총비용입니다. Fast lane은 wall-clock을 줄여주지만, 성공률이 떨어지면 재시도 때문에 총비용이 오히려 늘 수 있습니다.

CodeBridge Mini Lab: Fast lane 도입 테스트

후보 모델을 Fast lane으로 옮기기 전에 10개 태스크로 검증하세요.

준비물: 자주 하는 일 10개 (코드 수정, 요약, 분류, 표 분석 등)

A(기준 lane)와 B(Fast lane)에 같은 프롬프트 실행, 각각 기록:
- 성공 Y/N (기준 예: 테스트 통과 + 근거 인용)
- TTFT __초 / tokens/sec __ / wall-clock __초
- 총 토큰·비용
- 실패 유형: 지시 불이행 / 환각 / 도구 호출 실패 / 형식 오류

판정:
1. 성공률이 떨어지면 탈락 (속도는 성공을 못 산다)
2. 성공률 동점이면 wall-clock 짧은 쪽 채택
3. wall-clock도 비슷하면 성공 1건당 비용 낮은 쪽 채택
4. tool calling 필수 task에서는 지원 여부 먼저 확인 (미지원이면 측정 전에 탈락)

서빙을 직접 한다면 평균이 아니라 p95와 동시성으로 보세요. 방법은 NVIDIA AIPerf 글에 정리돼 있습니다.

결론: Fast는 점수표가 아니라 스톱워치로 고른다

정리하면 한 줄입니다.

GLM-5.3 Fast는 “새로운 지능”이 아니라 “같은 지능의 빠른 lane”이다.

그래서 고르는 방법도 다릅니다. 벤치마크 점수 옆에 스톱워치 숫자를 붙이세요. task success, TTFT, tokens/sec, wall-clock, cost. 이 다섯 숫자가 Fast lane의 값어치를 정합니다. provider 스펙(tool calling·가격·컨텍스트)은 계약서처럼 읽고, 최종 결정은 내 태스크 10개의 측정으로 내리세요.

함께 읽으면 좋은 글

참고 자료

이 주제를 직접 따라가며 배우고 싶다면

빠른 lane을 고르는 것만으로는 Agent가 완성되지 않습니다. 작업을 나누고 검증하는 실행 구조를 이해하면 속도 지표가 어디에 붙는지 보이기 시작합니다. 하네스·루프·그래프 관점의 설계 연습이 이 글의 측정 실험과 바로 이어집니다.