동일한 가중치입니다. 동일한 K2.6 모델입니다. 그런데 공식 Kimi 엔드포인트는 163.7초, Cerebras는 5.6초. 29배 차이입니다.
모델이 아니라 인프라가 성능을 결정하는 시대가 왔습니다. 왜 이런 일이 가능한지 — Wafer-Scale Engine의 원리부터 에이전트 개발자가 지금 당장 고려해야 할 것까지 정리합니다.
핵심 요약
→ 측정일: 2026년 5월 6일, Artificial Analysis 독립 검증
→ 결과: Kimi K2.6 기준 981 토큰/초 — 1조 파라미터 모델 역대 최속 기록
→ GPU 클라우드 대비: 차순위 대비 6.7배, 중간값 대비 23배 빠름
→ 에이전틱 워크로드(입력 10K + 출력 500 토큰): 공식 Kimi API 163.7초 → Cerebras 5.6초 (29배)
→ 핵심 원인: LLM 추론은 연산이 아니라 메모리 대역폭 병목 — WSE-3이 이걸 구조적으로 해결
→ WSE-3: 웨이퍼 한 장 = 칩 한 개, 온칩 SRAM 대역폭 21 PB/s — H100 HBM 대비 수천 배
→ NVLink 대비 온웨이퍼 패브릭: 200배 이상 대역폭
→ K2.6에 최적: INT4 가중치 저장 + FP16 연산 + 웨이퍼 간 활성값 스트리밍
→ Cerebras IPO: 2026년 5월, 시가총액 $950억
→ AWS Bedrock 통합: 프리필은 Trainium, 디코드는 WSE-3 분리 아키텍처
→ 에이전트 개발자 시사점: 모델 선택과 인프라 선택은 이제 별개의 결정
실전 1 — LLM 추론이 느린 진짜 이유
981 토큰/초가 왜 충격적인지 이해하려면, 먼저 GPU 클라우드가 왜 느린지 알아야 합니다.
LLM 추론의 병목: 연산이 아니라 메모리
흔한 오해:
"GPU 연산 능력(FLOPS)이 높으면 추론이 빠르다"
실제:
토큰 1개 생성 = 모델 가중치 전체를 메모리에서 읽어와야 함
→ 병목은 메모리 → 연산 유닛으로의 데이터 이동 속도
→ 즉, FLOPS가 아니라 메모리 대역폭이 추론 속도를 결정
GPU 클러스터의 구조적 한계
GPU 클러스터 (예: 8×H100):
GPU 1 ←──NVLink──→ GPU 2 ←──NVLink──→ GPU 3 ...
↑ ↑
HBM 메모리 HBM 메모리
문제:
- 각 GPU가 자기 HBM에서 가중치를 읽음
- GPU 간 통신은 NVLink를 거쳐야 함
- NVLink는 오프칩 → 레이턴시 + 대역폭 한계
- 모델이 클수록 GPU 간 통신 폭발적으로 증가
K2.6 같은 1조 파라미터 모델은 여러 GPU에 분산될 수밖에 없고, 레이어마다 GPU 간 통신이 발생합니다. 이게 163.7초의 원인입니다.
실전 2 — WSE-3: 웨이퍼 한 장을 칩으로 쓴다
Cerebras의 해법은 개념 자체를 바꾼 것입니다.
기존 반도체 제조 vs WSE-3
일반 반도체:
웨이퍼(300mm 원판) → 다이 수백 개로 절단 → 패키징 → GPU 칩
WSE-3:
웨이퍼(300mm 원판) → 절단하지 않음 → 그 자체가 칩
WSE-3 스펙
항목 WSE-3 H100 비교
| 공정 | TSMC 5nm | TSMC 4nm | 유사 |
| 다이 면적 | 46,225 mm² | 814 mm² | 57배 |
| 트랜지스터 | 4조 개 | 800억 개 | — |
| AI 코어 | 900,000개 | 16,896 CUDA | — |
| 온칩 SRAM | 44 GB | — | — |
| SRAM 대역폭 | 21 PB/s | 3.35 TB/s (HBM) | 수천 배 |
| 인터커넥트 | 온웨이퍼 패브릭 | NVLink | 200배+ |
왜 이게 K2.6에 맞는가
K2.6는 MoE 구조라 토큰마다 384개 전문가 중 8개만 활성화됩니다. Cerebras의 서빙 방식은 이렇습니다:
K2.6 가중치 저장: INT4 (원본 그대로)
실제 연산: FP16 (정확도 유지)
가중치 분산: 여러 웨이퍼에 걸쳐 저장
활성값(activations): 웨이퍼 간 스트리밍
레이어 간 통신 경로:
GPU 방식: GPU → NVLink → 다음 GPU (오프칩, 고레이턴시)
WSE-3 방식: 코어 → 온웨이퍼 패브릭 → 인접 코어 (온칩, 단일 클록)
Cerebras 공식 블로그 설명: "올-투-올 레이어 간 통신이 전부 온웨이퍼 네트워크 패브릭 위에서 돌아간다. NVL72의 NVLink 대비 200배 이상의 대역폭."
실전 3 — 29배 레이턴시의 실제 의미
숫자로 보면 이렇습니다.
같은 워크로드, 같은 가중치
항목 공식 Kimi API Cerebras
| 워크로드 | 입력 10K + 출력 500 토큰 | 동일 |
| 응답 시간 | 163.7초 | 5.6초 |
| 출력 속도 | ~43 TPS (중간값) | 981 TPS |
| GPU 대비 | 기준 | 6.7배 빠름 |
개발 리듬이 달라지는 지점
GPU 클라우드 (43 TPS):
에이전트 실행 → 2~3분 대기 → 결과 검토 → 수정 → 반복
→ 개발자가 다른 창 열고 다른 작업 하다가 돌아옴
→ 컨텍스트 스위칭 비용 발생
Cerebras (981 TPS):
에이전트 실행 → 5~10초 대기 → 결과 검토 → 수정 → 반복
→ 개발자가 화면 앞에서 바로 다음 단계 진행
→ 단일 태스크 집중 유지
Cerebras 블로그 표현: "에이전틱 코딩이 대기-검토 루프에서 실시간 개발로 전환된다." Claude Opus 같은 인기 모델 대비 한 자릿수 빠른 게 아니라 한 오더 오브 매그니튜드(10배 이상) 차이입니다.
Agent Swarm과의 시너지
K2.6의 Agent Swarm은 300개 서브에이전트를 4,000 스텝까지 조율합니다. 각 서브에이전트 응답이 43 TPS면 전체 Swarm 완료까지 시간이 폭발합니다. 981 TPS면 병렬 에이전트 루프 자체가 실용적인 레이턴시 안에 들어옵니다.
실전 4 — Cerebras IPO와 AWS Bedrock 통합: 인프라 판도 변화
단순한 벤치마크 얘기가 아닙니다. 시장 구조가 바뀌고 있습니다.
Cerebras IPO (2026년 5월)
- 상장 시가총액: $950억
- 2025년 매출: $5억 1천만 (2024년 $2,460만 → 20배 성장)
- 2025년 순이익: $2억 3,780만 (2024년 순손실 $4억 8,160만에서 흑자 전환)
- 주요 고객: OpenAI (코딩 모델 추론), Cognition (에이전트), G42
OpenAI가 Cerebras 인프라 위에서 내부 코딩 모델을 돌리고 있습니다. 경쟁사의 하드웨어를 쓰는 구조 — 추론 속도가 그만큼 중요하다는 방증입니다.
AWS Bedrock 통합 (2026년 3월)
AWS가 Cerebras CS-3를 Bedrock 내부에 배포한 방식이 흥미롭습니다:
분리 아키텍처:
프리필(Prefill) 단계 → AWS Trainium 처리
(입력 토큰 처리, 연산 집약적)
디코드(Decode) 단계 → Cerebras WSE-3 처리
(토큰 생성, 메모리 대역폭 집약적)
결과: 동일 하드웨어 풋프린트에서 5배 더 많은 고속 토큰 처리 용량
프리필은 연산 중심(compute-bound), 디코드는 메모리 대역폭 중심(bandwidth-bound)입니다. AWS는 각 단계에 최적화된 칩을 분리 투입한 겁니다.
실전 5 — 에이전트 개발자를 위한 인프라 선택 기준
이제 모델 선택과 인프라 선택은 별개의 결정입니다. 동일한 K2.6 가중치가 14개 프로바이더에서 서로 다른 성능으로 돌아갑니다.
워크로드 유형별 선택 가이드
워크로드 우선순위 추천 이유
| 실시간 에이전트 코딩 | 레이턴시 최소화 | Cerebras | 981 TPS, 5.6초 응답 |
| 대량 배치 처리 | 비용 최소화 | Parasail / DeepInfra | 최저가, TTFT 덜 중요 |
| 스트리밍 UI | 첫 토큰 속도 | Fireworks | 350 TPS, 빠른 체감 |
| Agent Swarm 프로덕션 | 비용+속도 균형 | DeepInfra | 캐시 가격 투명, 77 TPS |
| IDE 통합 | MCP 지원 | Atlas Cloud | Cursor/VS Code 네이티브 |
| 엔터프라이즈 컴플라이언스 | 데이터 주권 | 셀프호스팅 (SGLang) | 온프레미스 가중치 |
레이턴시가 실제로 중요한 경우 vs 그렇지 않은 경우
레이턴시가 게임 체인저인 경우:
→ 사용자 대면 실시간 코딩 어시스턴트
→ 인터랙티브 Agent Swarm (사용자가 기다리는 루프)
→ Generative UI (매 인터랙션마다 인터페이스 생성)
→ 멀티에이전트 파이프라인 (에이전트 간 응답 의존성 있을 때)
레이턴시보다 비용이 중요한 경우:
→ 오프라인 코드 분석 배치 (밤사이 실행)
→ 대규모 문서 처리
→ 테스트 스위트 자동 생성
→ 비동기 백그라운드 작업
실전 6 — WSE-3의 한계: 냉정한 평가
Cerebras가 모든 워크로드에서 답은 아닙니다.
WSE-3의 구조적 한계:
1. 온칩 메모리 44 GB
→ 가중치 전체를 담으려면 여러 웨이퍼 필요
→ MemoryX 외부 확장 스토리지 필요 (별도 비용)
2. 학습(Training) 부적합
→ 역전파는 연산 집약적 → GPU 우위 유지
→ Cerebras 자신도 추론 전문 포지셔닝
3. 웨이퍼 수율 문제
→ 46,225 mm² 다이 = 결함 확률 높음
→ 중복 설계로 보완하지만 제조 비용 상승
→ NVIDIA는 작은 다이 → 높은 수율 → 낮은 단가
4. 엔터프라이즈 트라이얼 단계
→ K2.6 서비스는 아직 엔터프라이즈 고객 대상
→ 일반 개발자 공개 API는 추후 (현재 문의 필요)
5. CUDA 생태계 없음
→ 커스텀 커널, 파인튜닝, 실험적 워크로드는 GPU 우선
마무리
항목 평가
| ✅ 981 TPS — Artificial Analysis 독립 검증 | 벤더 주장 아님, 신뢰 가능 |
| ✅ 29배 엔드투엔드 레이턴시 개선 | 에이전트 루프 개발 리듬 전환점 |
| ✅ MoE 희소 활성화 + WSE-3 대역폭 궁합 | 구조적으로 잘 맞는 조합 |
| ✅ AWS Bedrock 통합 → 접근성 향상 | 엔터프라이즈 도입 경로 생김 |
| ✅ IPO 후 $950억 → 인프라 투자 지속 | 단기 서비스 종료 리스크 낮음 |
| ❌ 아직 엔터프라이즈 트라이얼 단계 | 일반 개발자 직접 접근 제한 |
| ❌ 학습 워크로드 부적합 | 추론 전용 인프라 |
| ❌ 온칩 메모리 44 GB 한계 | 초대형 모델 서빙 시 추가 비용 |
핵심 시사점 하나: 모델 가중치가 오픈소스가 되는 순간, 인프라가 경쟁의 축이 됩니다. K2.6은 14개 프로바이더에서 돌아갑니다. 속도가 43배 차이 납니다. 같은 모델, 다른 결과입니다. 앞으로 "어떤 모델 쓸까"만큼 "어디서 돌릴까"가 중요해집니다.
관련 글
- Kimi K2.6 완전분석 2편 — 1T MoE 아키텍처, Agent Swarm, 벤치마크
- Kimi K2.6 × Cerebras 3편 — 981 토큰/초의 원리: Wafer-Scale Engine이 GPU를 29배 앞서는 이유