GPT-5.6 Sol Ultrafast 모드
Cerebras와 OpenAI가 2026년 8월 13일, Cerebras 기반의 새로운 서비스 티어인 Ultrafast Mode를 OpenAI API에서 먼저 공개함
GPT-5.6 Sol Ultrafast는 최대 초당 750개 출력 토큰을 제공하면서 품질 저하 없이 시간에 민감한 핵심 업무를 가속함
현재 일부 고객만 이용할 수 있으며, 용량이 늘어나는 대로 접근 범위를 확대할 예정

속도와 벤치마크
GPT-5.6 Sol Ultrafast는 속도와 지능 사이의 기존 절충을 줄여, 매초가 중요한 제품과 워크플로에 프런티어급 성능을 제공함
Artificial Analysis가 보고한 출력 속도와 비교하면 Fable 5보다 11배, Fast mode의 Opus 4.8보다 5배 빠름

Humanity's Last Exam(HLE) 2,500문항을 11시간 11분 만에 처리해 Claude Fable 5와 비슷한 정확도에 약 7배 빠르게 도달함
HLE는 화학·경제학·문학 등에서 일반적으로 박사급 전문성이 필요한 2,500개 질문으로 구성된 고난도 벤치마크임
Claude Fable 5는 같은 결론에 도달하는 데 78시간 27분, 즉 3일이 넘는 연속 연산이 필요했음
Cerebras가 다음 조건으로 벤치마크를 수행함
GPT 5.6 Sol Ultrafast는 7월 10일 Codex에서 xhigh reasoning으로 실행함
Claude Fable 5는 7월 13~15일 Claude Code에서 xhigh reasoning으로 실행함
경제적 가치가 높은 지식 업무에서도 품질 저하 없이 전체 작업 시간을 단축함
GPT-5.6 Sol은 법률 서면, 재무 모델, 엔지니어링 보고서 작성에 적합한 OpenAI 모델이며, GDP-Val에서 Ultrafast가 엔드투엔드 기준 5.6배 속도 향상을 기록함

GDP-Val 비교는 Cerebras가 2026년 7월 31일 Codex에서 GPT 5.6 Sol과 GPT 5.6 Sol Ultrafast를 medium reasoning으로 실행해 측정함
중요 업무에 미치는 영향
응답이 빨라지면서 에이전트를 매초가 중요한 업무의 핵심 경로에 투입할 수 있음
사고·코딩·협업의 흐름을 따라갈 만큼 빠르게 결과를 제공해, 작업이 끝나기를 기다리며 다른 맥락으로 전환할 필요가 줄어듦
웹 서비스 운영 기업은 프로덕션 장애의 근본 원인을 신속히 찾아 대응함으로써 고객 신뢰와 매출을 지키고 SLA상 다운타임을 줄일 수 있음
적대적이고 위험도가 높은 사이버 공격에서는 보안팀이 공격자를 빠르게 탐지·대응해 막대한 손실을 억제하는 데 활용 가능
실시간 인사이트와 업데이트를 제공하므로 여러 병렬 세션 사이를 오가지 않고도 에이전트를 활용할 수 있음
중요한 일부 문제에는 깊이 집중하고, 일반 작업의 병렬 처리에는 Standard processing을 계속 사용할 수 있음
이전에는 몇 분을 기다리던 작업이 맥락을 전환하기도 전에 끝나 연구자와 엔지니어의 생산성을 높임
Wafer-Scale Engine 아키텍처
Ultrafast의 속도는 프런티어 AI 워크로드용 Cerebras Wafer-Scale Engine 아키텍처에서 나옴
GPU에서 대형 모델을 추론할 때는 연속 토큰을 생성할 때마다 모델 가중치를 온칩 메모리와 오프칩 저장소 사이에서 반복 전송해야 하므로 메모리 대역폭이 병목이 됨
Cerebras는 웨이퍼 크기 칩마다 44GB SRAM을 탑재해 비효율적인 데이터 이동을 제거함
가중치는 칩 내부에 유지되고, 토큰은 여러 웨이퍼에 걸쳐 파이프라인화된 모델 계층을 중단 없이 통과함
모델 크기가 커져도 원활하게 확장되므로 향후 프런티어 모델에서도 속도 우위를 이어갈 기반이 됨
제한적 프리뷰
Ultrafast mode의 GPT-5.6 Sol은 현재 일부 고객을 대상으로 제한적 프리뷰를 제공함
용량 증가에 맞춰 접근 범위를 확대할 예정이며, 업데이트를 신청할 수 있음
source https://www.cerebras.ai/blog/accelerating-gpt-5-6-sol-ultrafast-with-openai
HN에서는 초당 토큰 수보다 이 속도가 개발 과정과 결과물의 품질을 실제로 바꿀 수 있는지가 핵심 쟁점이었다. 빠른 응답 때문에 상대적으로 가벼운 모델을 선택해 왔다는 개발자들은 대기 시간이 짧을수록 집중을 유지하기 쉽다고 봤다. 초안을 거듭 고치고, 다른 모델에 반론을 요청하거나 자체 검토를 반복할 여유도 생긴다. 속도는 단순한 편의가 아니라 같은 시간에 더 많은 시행착오를 거쳐 완성도를 높이는 조건이라는 판단이다.
다만 토큰 생성 속도가 빨라진 만큼 전체 작업이 단축되지는 않는다. 대규모 코드베이스에서는 테스트와 타입 검사, 빌드, 검색, 도구 호출이 이미 큰 비중을 차지한다. 한 시간 걸리는 종단 간 테스트는 모델이 빨라져도 그대로이며, 사람이 변경 사항을 확인하는 시간도 남는다. 반대로 응답을 기다리며 집중이 끊기는 시간이 줄고 수정과 검증을 더 자주 수행할 수 있으므로, 사람의 검토 과정까지 수월해질 수 있다는 실무 경험도 제시됐다.
성능 비교를 그대로 받아들이기 어렵다는 시각도 강했다. 서로 독립된 2,500개 문항은 병렬 처리에 유리해, 어려운 질문 하나를 끝까지 해결하거나 여러 도구를 호출하는 실제 업무와 조건이 다르다. 기존 Sol과 품질이 같다는 설명 역시 추론 수준과 평가 조건이 충분히 드러나지 않았다. 최고 속도 수치보다 동일한 과제에서 성능이 유지되는지 직접 확인해야 한다는 뜻이다.
