오늘(2026.4.30) 智谱(Zhipu / Z.ai)이 공개한 기술 블로그 **「Scaling Pain:超大规模 Coding Agent 推理实践」**는 GLM-5 시리즈가 초대규모 Coding Agent 호출 시나리오에서 겪은 추론 인프라 문제와, 이를 해결하기 위한 엔지니어링 최적화 결과를 처음으로 체계적으로 공개한 글입니다. 단순한 자랑이 아니라, 수요가 공급을 초과해 신규 구독을 제한해야 했던 몇 달의 누적 이슈에 대한 공식 답변에 가깝습니다.
원문: Scaling Pain — Z.ai Blog (2026-04-30)
핵심 도발
“Scaling up하니, 진짜 본 적 없는 아픔이 나왔다.”
이 정서가 글 전체의 톤입니다. 회피하지 않고 공개했다는 사실 자체가 이번 포스트의 위치를 결정합니다.
세 줄
- 무엇이 문제였나 — Coding Agent 워크로드(긴 컨텍스트, 다중 도구 호출, 장시간 세션)는 일반 챗 워크로드와 추론 부하 패턴이 완전히 달라서 기존 서빙 스택이 흔들렸다.
- 무엇을 했나 — DSA(DeepSeek Sparse Attention) 기반 GLM-5의 인덱서·디코딩·결정성(determinism) 등 저수준 단을 손봤다.
- 어디까지 갔나 — 처리량 +132%, 이상 출력률 1/3 미만으로 축소, 수정 사항을 자체 폐쇄 최적화가 아니라 SGLang 업스트림 PR #22811로 환원했다.
배경 맥락 — 왜 “Scaling Pain"이라 불렀는가
이 글은 갑자기 나온 게 아니라, 지난 몇 달간 누적된 Z.ai의 인프라 이슈에 대한 공식 답변입니다.
수요가 공급을 초과한 상태가 지속됨
Zhipu는 GLM-4.7 수요가 인프라를 압도해 신규 구독을 용량의 20%로 제한해야 했고, 기존 사용자도 피크 시간대 슬로우다운을 겪었습니다. z.ai의 LinkedIn 공지에서도 이렇게 인정했습니다.
“GLM-5에 대한 글로벌 수요가 모든 예측을 초과했고, 여러 차례의 클러스터 확장 후에도 수요가 가용 추론 용량을 계속 앞지르고 있다.”
하드웨어 제약이 더 심하다
GLM-5는 NVIDIA가 아니라 Huawei Ascend 위에서 학습/서빙되는 구조입니다. 일반적인 H100/H200 기반 최적화 노하우를 그대로 가져올 수 없다는 추가 제약이 깔려 있습니다.
모델 크기·아키텍처의 부담
- 파라미터 확장 — GLM-4.5의 355B(활성 32B) → GLM-5의 744B(활성 40B)
- 아키텍처 변화 — DeepSeek Sparse Attention(DSA) 도입, 긴 컨텍스트 용량은 보존하면서 배포 비용을 줄이는 구조
- 부작용 — DSA는 새 메커니즘이라 인덱서의 결정성(determinism) 같은 미묘한 이슈가 생산 환경에서 새로 드러난다
정량 결과 — 무엇이 얼마나 좋아졌나
| 지표 | 변화 |
|---|---|
| 시스템 처리량 | 최대 +132% |
| 이상 출력률 | 만분의 십몇 → 만분의 3 미만 |
| 수정 환원처 | SGLang 업스트림 PR #22811 |
처리량 132%는 같은 클러스터로 두 배 가까운 트래픽을 받는다는 뜻입니다. 그러나 더 중요한 숫자는 이상 출력률입니다 — 단발 평가에서는 거의 무시될 만한 차이지만, 멀티턴 에이전트에서는 의미가 다릅니다.
시사점 1 — “Chat 워크로드 ≠ Agent 워크로드"가 인프라 차원에서 공식화되고 있다
챗봇 호출은 짧은 prompt-completion 1회전입니다. Coding Agent는 다릅니다:
- 긴 컨텍스트 — 코드베이스 200K+ 토큰
- 수십 회의 tool call — 파일 읽기·쓰기·실행·검색
- 멀티턴 reasoning — 한 세션 안에서 수십 번 모델이 다시 호출됨
부하 패턴이 달라서 KV 캐시 재사용, 결정성, 처리량/지연 트레이드오프 전부가 다시 설계돼야 합니다.
API를 외부 의존성으로 쓰더라도, 어느 워크로드에 최적화된 엔드포인트인지는 이제 의식해야 하는 변수가 됐다.
시사점 2 — 비결정성이 멀티턴 에이전트 신뢰성의 진짜 적이다
이상 출력률 만분의 십몇 → 만분의 3은 단발 호출에서는 안 보이는 숫자입니다. 그러나 30턴짜리 에이전트 루프를 떠올려 보면 게임이 바뀝니다.
- 한 번의 이탈이 컨텍스트에 들어가 다음 턴을 오염
- 잘못된 가정 위에 다음 도구 호출
- 결국 전체 task 실패
GLM-5 기술 보고서에서도 비슷한 이야기가 나옵니다 — DSA Indexer의 비결정적 CUDA top-k 연산자가 RL 단계에서 몇 스텝 만에 성능 급락과 엔트로피 붕괴를 일으켰고, deterministic torch.topk로 바꿔야 했다는 디테일.
내가 만드는 파이프라인이 실패해도 retry로 자연스럽게 복구되는 구조인지, 한 번 어긋나면 카스케이드되는지 — 이번 포스트가 던지는 점검 질문이다.
시사점 3 — 자체 호스팅 vs API 결정에 “운영 깊이” 변수가 추가됐다
오픈웨이트를 받아서 SGLang/vLLM에 띄우는 것 자체는 쉬워졌습니다. 그러나 132% throughput 차이를 만든 건 모델이 아니라:
- 인덱서 패치
- 스케줄러 튜닝
- 디코딩 레이어 수정
즉 *“내가 직접 띄우면 동일 성능”*이라는 가정이 점점 위험해지고 있습니다. 특히 Coding Agent처럼 부하 패턴이 까다로운 영역에서는 모델 제공자의 인프라 노하우 자체가 제품 차별점이 되고 있습니다.
시사점 4 — 오픈소스 환원이 신호다
수정안을 사내에서 안 끌어안고 SGLang 업스트림 PR #22811로 보낸 것은, 단순 선의가 아닙니다.
- DeepSeek (DSA 메커니즘 원작자)
- SGLang (오픈소스 추론 프레임워크)
- Huawei Ascend (하드웨어 스택)
세 진영을 가로지르는 공동 표준화 흐름으로 읽힙니다. 동시에 NVIDIA 외부 스택의 성숙도가 빨라지고 있다는 신호이기도 합니다.
멀티 프로바이더 전략(Anthropic, OpenAI, Z.ai/GLM, DeepSeek 등)을 짤 때, GLM 계열을 코딩 에이전트 비용 최적화 슬롯으로 진지하게 평가할 만한 시점이 됐다.
시사점 5 — “코딩 에이전트의 SLA"라는 새 지표가 곧 일반화될 것
처리량이 좋아도 만분의 몇 단위의 이상 출력률이 누적되면 long-horizon agent에선 치명적입니다. 앞으로 모델 선택의 기준은:
SWE-bench 점수 → (throughput × determinism × long-context 안정성) 결합 지표
쪽으로 이동할 가능성이 높습니다. Z.ai가 이번 글을 통해 그 프레이밍을 선점하려는 의도도 함께 읽힙니다.
핵심 어휘 정리
- Scaling Pain — 단일 모델·단일 클러스터에서는 안 보이다가, 트래픽 스케일업이 일어났을 때 처음 드러나는 인프라 결함
- DSA (DeepSeek Sparse Attention) — 긴 컨텍스트 용량을 보존하면서 배포 비용을 줄이는 어텐션 메커니즘; 인덱서 결정성이 새로운 운영 변수
- Determinism — 같은 입력에 같은 출력을 보장하는 성질; 단발 챗에서는 사치, 멀티턴 에이전트에서는 신뢰성의 토대
- Open-source Reciprocity — 자체 최적화를 사내에 가두지 않고 업스트림으로 환원하는 패턴; 표준화 협상력이 됨
실행 체크리스트 — 이번 글을 본 뒤 점검할 것
- 우리 에이전트가 호출하는 모델이 챗 워크로드 최적화인지 에이전트 워크로드 최적화인지 명확히 분리해 평가
- 멀티턴 루프의 카스케이드 실패 시나리오 시뮬레이션 — 0.1% 이탈이 30턴에서 어떻게 누적되는지
- 자체 호스팅을 검토 중이라면, 인덱서·디코딩·스케줄러 레이어의 운영 노하우 비용을 별도 항목으로 산정
- GLM-5 / DeepSeek / Qwen 계열을 코딩 에이전트 슬롯에 후보로 올려 비용·안정성 벤치
- SLA 정의에 throughput만이 아니라 determinism, long-context 안정성을 명시적으로 포함
왜 이 글이 중요한가
대부분의 모델 카드 발표는 벤치마크 점수에 머무릅니다. 「Scaling Pain」은 그 한 층 아래를 공개합니다 — 생산 환경에서 실제로 무엇이 부서졌고 어떻게 고쳤는가.
- 솔직함의 신호 — 수요가 인프라를 압도했다고 공식적으로 인정한 사례는 드물다
- 메커니즘적 진단 — 챗 vs 에이전트 워크로드의 부하 패턴 차이를 인프라 차원에서 정의
- 정량 환원 — +132% / 만분의 3이라는 측정 가능한 결과
- 개방성 — PR #22811이라는 재사용 가능한 출구
모델은 점수표가 아니라 운영 환경에서 부서지는 방식으로 평가받는 시대로 옮겨가고 있다.
핵심 결론
- Coding Agent 워크로드는 챗 워크로드와 다르다 — 긴 컨텍스트 + 다중 도구 호출 + 장시간 세션이 한 번에 묶인다
- 이상 출력률 만분의 몇은 멀티턴에서 카스케이드된다 — 단발 평가가 가리는 진짜 SLA
- 인프라 노하우가 제품 차별점이다 — 같은 오픈웨이트라도 132% throughput 차이가 난다
- 오픈소스 환원이 표준화 신호다 — SGLang PR #22811은 DeepSeek/SGLang/Ascend 공동 진영의 협상력
- 모델 선택 기준이 이동한다 — SWE-bench → throughput × determinism × long-context
당신의 에이전트가 의존하는 모델은, 30턴 뒤에도 같은 모델인가.