▲

OpenAI, GPT‑5.4 Mini 및 Nano 공개

 (openai.com)
3P by GN⁺ 4일전 | ★ favorite | 댓글 1개
  • GPT‑5.4의 성능을 빠르고 효율적인 형태로 구현
  • GPT‑5.4 mini는 코딩·추론·멀티모달 이해·도구 사용에서 GPT‑5 mini 대비 크게 향상되었으며, 속도는 2배 이상 빠름
  • GPT‑5.4 nano는 가장 작고 저렴한 모델로, 분류·데이터 추출·랭킹·보조 코딩 작업에 적합함
  • 두 모델 모두 지연시간(latency) 이 중요한 워크로드에 맞춰 설계되어, 반응성이 필요한 코딩 보조나 실시간 멀티모달 응용에 유리함
  • 이 모델들을 통해 속도·비용·성능의 균형을 최적화한 경량 AI 시스템 구성을 가능해짐

GPT‑5.4 mini 및 nano 개요

  • GPT‑5.4 mini와 nano는 GPT‑5.4의 소형·고효율 버전으로, 대량 처리 환경에서 빠른 응답을 목표로 설계됨
    • mini는 GPT‑5 mini 대비 코딩, 추론, 멀티모달 이해, 도구 사용에서 향상
    • nano는 GPT‑5 nano보다 성능이 개선된 가장 작은·가장 저렴한 모델
  • 두 모델은 지연시간이 제품 경험에 직접 영향을 미치는 환경(코딩 보조, 서브에이전트, 스크린샷 해석, 실시간 이미지 추론 등)에 최적화됨
  • OpenAI는 “가장 좋은 모델이 항상 가장 큰 모델은 아니다”라며, 빠른 응답성과 안정적 도구 사용 능력을 강조함

성능 비교

  • 주요 벤치마크에서 GPT‑5.4 mini는 GPT‑5 mini보다 높은 점수를 기록하며, GPT‑5.4에 근접한 성능을 보임
    • SWE‑Bench Pro: GPT‑5.4 57.7%, mini 54.4%, nano 52.4%, GPT‑5 mini 45.7%
    • OSWorld‑Verified: GPT‑5.4 75.0%, mini 72.1%, nano 39.0%, GPT‑5 mini 42.0%
  • Terminal‑Bench 2.0, Toolathlon, GPQA Diamond 등에서도 mini는 성능 대비 속도 효율이 높음
  • nano는 속도와 비용이 중요한 환경에서 최적의 비용 효율성을 제공

코딩 워크플로우

  • 두 모델은 빠른 반복(iteration) 이 필요한 코딩 환경에 적합
    • 코드 편집, 코드베이스 탐색, 프런트엔드 생성, 디버깅 루프 등에서 낮은 지연시간으로 작동
  • GPT‑5.4 mini는 GPT‑5 mini보다 유사한 지연시간에서 더 높은 통과율(pass rate) 을 기록하며, GPT‑5.4 수준에 근접
  • Codex 환경에서는 대형 모델이 계획·판단을 수행하고, mini가 세부 작업을 병렬로 처리하는 서브에이전트 역할 수행
    • 예: 코드 검색, 대형 파일 검토, 문서 처리 등
  • 이러한 구조는 작은 모델의 속도와 성능이 향상될수록 더욱 유용해짐

컴퓨터 사용 및 멀티모달 처리

  • GPT‑5.4 mini는 컴퓨터 사용 관련 멀티모달 작업에서도 강력한 성능을 보임
    • 복잡한 사용자 인터페이스의 스크린샷을 빠르게 해석해 작업 수행
    • OSWorld‑Verified에서 GPT‑5.4에 근접하며 GPT‑5 mini를 크게 상회

제공 방식 및 가격

  • GPT‑5.4 mini
    • API, Codex, ChatGPT에서 사용 가능
    • 지원 기능: 텍스트·이미지 입력, 도구 사용, 함수 호출, 웹·파일 검색, 컴퓨터 사용, 스킬
    • 400k 컨텍스트 윈도우, 입력 100만 토큰당 $0.75, 출력 100만 토큰당 $4.50
    • Codex에서는 GPT‑5.4 쿼터의 30%만 사용하며, 단순 코딩 작업을 약 1/3 비용으로 처리 가능
    • ChatGPT에서는 Free·Go 사용자에게 “Thinking” 기능으로 제공, 다른 사용자에게는 GPT‑5.4 Thinking의 대체 모델(fallback) 로 사용
  • GPT‑5.4 nano
    • API 전용 제공
    • 입력 100만 토큰당 $0.20, 출력 100만 토큰당 $1.25

추가 벤치마크 세부 결과

  • 코딩
    • SWE‑Bench Pro: GPT‑5.4 mini 54.4%, nano 52.4%
    • Terminal‑Bench 2.0: mini 60.0%, nano 46.3%
  • 도구 호출
    • MCP Atlas: mini 57.7%, nano 56.1%
    • Toolathlon: mini 42.9%, nano 35.5%
    • τ2‑bench(통신): mini 93.4%, nano 92.5%
  • 지능 평가
    • GPQA Diamond: mini 88.0%, nano 82.8%
    • HLE w/ tool: mini 41.5%, nano 37.7%
  • 멀티모달·비전
    • MMMUPro w/ Python: mini 78.0%, nano 69.5%
    • OmniDocBench 1.5(no tools): mini 0.1263, nano 0.2419 (낮을수록 우수)
  • 롱 컨텍스트
    • Graphwalks BFS 0K–128K: mini 76.3%, nano 73.4%
    • MRCR v2 8‑needle 64K–128K: mini 47.7%, nano 44.2%

종합 평가

  • GPT‑5.4 mini와 nano는 속도·비용·성능의 균형을 극대화한 경량 모델로, 대규모 실시간 응용에 적합
  • mini는 서브에이전트 구조나 멀티모달 시스템에서 핵심 역할을 수행할 수 있으며, nano는 단순·대량 처리 작업에 효율적
  • OpenAI는 이 두 모델을 통해 다양한 규모의 AI 시스템을 유연하게 구성할 수 있는 기반을 제공함
▲
GN⁺ 4일전  [-]
Hacker News 의견들

  • API를 통해 현재 속도를 확인해봤는데 꽤 인상적이었음
    GPT-5 Mini는 보통 55~60 tokens/s, priority 모드에서는 115~120 t/s 정도였고, GPT-5.4 Mini는 평균 180~190 t/s, GPT-5.4 Nano는 약 200 t/s 수준이었음
    비교하자면 Gemini 3 Flash는 약 130 t/s (Gemini API), Vertex에서는 120 t/s 정도였음
    가격도 함께 보면 Claude Opus 4.6은 $5/$25, GPT-5.4는 $2.5/$15, Gemini 3.1 Pro는 $2/$12 등으로 구성되어 있음

    • token/s만으로는 충분하지 않음. TTFT(첫 토큰 대기시간) 과 전체 지연(latency)도 함께 봐야 실제 API 사용 성능을 알 수 있음
    • 속도만 빠르고 생각 단계(reasoning) 가 길다면 오히려 느릴 수 있음. 낮은 token/s라도 집중된 사고면 더 효율적일 수 있음
    • Google이 리소스나 비용 면에서 유리할 것 같은데도 사람들이 GPT나 Claude를 택하는 이유가 궁금함
    • 출력 속도뿐 아니라 프롬프트 처리 속도도 주요 제공자별로 측정해줬으면 함
    • 저가 모델의 가격이 꽤 올랐음. 예전엔 편했는데 이제는 부담스러움

  • 여러 모델의 펠리컨 이미지를 비교한 그리드를 공유함

    • 이제 이런 작업은 아마 훈련 데이터에 포함되어 있을 것 같음
    • 일부 이미지는 악몽 같은 느낌이지만 그래서 더 마음에 듦
    • 개인적으로는 nano xhigh 버전의 펠리컨이 가장 마음에 듦
    • nano medium은 서버가 불타던 시점에 생성된 것 같음

  • GPT 모델은 대화용으로는 좋아하지만 에이전트형 작업(agentic work) 에서는 경험이 나빴음
    속도도 느리고, 지시를 잘 이해하지 못함. 같은 프롬프트로 다른 모델은 잘 작동함

    • 5.4 Mini는 음성 애플리케이션에 적합할 만큼 빠르지만, 지시 수행 능력은 부족함. Qwen 3.5 9B를 미세조정해볼 생각임
    • Gemini 3.1과 Claude Opus 4.6은 기준을 통과했지만 ChatGPT 계열은 대화형에 치중되어 있음. 맥락 유지가 약해 결과 검증이 필요함
    • GPT 5.2 Codex는 맥락을 자주 잃고, Claude는 GitHub Copilot에서 훨씬 자연스럽게 작동함. GPT는 단순 리팩터링에도 20분이 걸림
    • 5.4 Pro로 데이터 분석을 했는데 너무 느렸음. Sonnet 4.6은 훨씬 빨랐음. 대부분의 작업엔 Haiku 정도면 충분함
    • 반대로 나는 Codex가 가장 뛰어나다고 느낌. 다만 너무 냉정한 스타일이라 대화가 짧고, 개입하기 어렵다는 점이 아쉬움
      Opus는 협업적이지만 가끔 이상한 제안을 함. Codex 프롬프트는 OpenCode 저장소에 있음

  • 나는 소형(mini) 모델 릴리스가 SOTA보다 더 의미 있다고 생각함
    대형 모델은 이미 충분히 좋아서 차이를 느끼기 어렵지만, 작은 모델은 버전이 바뀔 때 품질 도약이 큼
    게다가 훨씬 저렴해 실제 서비스에 적용하기 쉬움

    • Gemini 웹앱은 자동으로 Flash로 전환되는데, 답변이 이상하거나 논리가 어긋나면 바로 눈치챔. 일상용으로는 아직 부족하지만 단순 자동화에는 충분히 좋음
    • GPT 5.4는 Svelte UI 작업에 약하고, Gemini는 토론보다 바로 구현하려는 경향이 있음. Claude는 타입스크립트에서 any 타입을 남용함
    • 비교 결과를 보면 5 mini와 5.4 mini의 차이는 작지만, 5.4 mini는 불안정하지만 정답률이 높음
    • 실제로는 가격이 오름세임. GPT 5.4 mini는 5.0 mini보다 약 3배 비쌈. Gemini 3.1 Flash Lite도 이전보다 비쌈
    • 오픈모델 대비 그렇게 싸지도 않고, 지능도 낮음. 지연(latency) 을 최소화해야 하는 경우가 아니라면 굳이 쓸 이유가 적음

  • LLM 평가를 왜 감(‘vibe check’) 으로 하는지 의문임
    대부분의 비교가 체계적 실험이 아니라 즉흥적 테스트에 기반함

    • 단순한 엔지니어링 문제는 아님. 지능과 능력의 정의 자체가 불완전하기 때문임. 기존 벤치마크는 결함이 많음
    • 벤치마크를 만들면 “무의미하다”는 불평이 나오지만, 감으로 평가하는 건 그보다 훨씬 나쁨
    • 공개된 평가셋은 금세 다크 포레스트 문제로 무력화됨. 예측력도 약하므로, 오히려 비공식적 접근을 과학적으로 다루는 게 낫다고 봄
    • “감으로 평가하고, 감으로 코딩한다”는 농담도 나옴

  • 벤치마크에 따르면 GPT 5.4 Nano가 GPT-5 Mini보다 대부분의 영역에서 우수하지만, 가격은 오히려 상승함
    GPT 5 mini: 입력 $0.25 / 출력 $2.00 → GPT 5.4 mini: 입력 $0.75 / 출력 $4.50

    • 모델이 비싸졌지만 성능 대비 가격 효율은 개선됨. 저성능 모델을 유지할 이유가 줄었을 수도 있음
    • 더 큰 모델이므로 서빙 비용이 낮을 수 없음. 성능이 좋아졌다면 비싼 게 당연함

  • OSWorld 점수가 흥미로움. Mini가 72.1%, 인간 기준 72.4%로 거의 동일함
    따라서 특정 실패 케이스가 아니라면 Mini를 기본으로 써도 무방함
    다만 멀티모델 파이프라인에서 nano 서브에이전트가 전체 메시지 히스토리를 그대로 전달하면, “저렴한 단계”가 의미 없어짐
    실제로 어느 정도 컨텍스트 길이에서 nano가 더 이상 빠르지 않은지 측정해본 사람이 있는지 궁금함

    • (이건 봇 같음)

  • 내 벤치마크에서도 Nano가 Mini보다 더 나은 결과를 보임
    5.4 mini는 일관성 문제가 있고, temperature 0에서도 정답과 오답이 섞여 나옴
    비교 링크 참고

  • 5.4 Mini의 OSWorld 점수가 놀라움. 과거엔 모델이 느리고 부정확해서 실시간 에이전트에 쓸 수 없었는데, 이제는 가능성이 보임

    • 일부는 OSWorld를 “OpenClaw”라며 무시하지만, 안전한 전체 상호작용 평가로서 강력함
      예를 들어 Win32 앱과 웹 버전의 동작을 비교해 자동 테스트를 만들 수 있음. 대규모로 확장할 때도 비용 효율적임

  • SWE-Bench 기준으로 보면 5.4 mini high는 GPT 5.4 low와 정확도·가격이 비슷하지만 지연 시간(latency) 은 더 김 (254초 vs 171초)
    단순 작업에는 낮은 effort 레벨로 돌리는 게 비용 절감에 유리함. 다만 긴 컨텍스트 처리 성능은 여전히 약함

답변달기