9P by GN⁺ 19시간전 | ★ favorite | 댓글 1개
  • 머큐리는 확산(Diffusion) 방식을 활용한 새로운 상용 대규모 언어 모델(LLM)
  • 이 모델은 Transformer 구조에 기반하여 여러 토큰을 병렬로 예측하는 특징이 있음
  • 머큐리 코더는 첫 확산 LLM 세트로, 코드 작성용으로 개발되고, Mini와 Small 두 가지 크기로 제공됨
  • NVIDIA H100 GPU에서 1109(미니), 737(스몰) 토큰/초의 처리량을 기록하며, 동일 품질에서 기존 속도 중심 모델 대비 최대 10배 빠른 성능을 나타냄
  • 실 사용 벤치마크 및 Copilot Arena 등 개발자 평가에서도 2위 품질 및 최고 속도를 기록하고, 공개 API플레이그라운드도 제공함

개요

  • 머큐리(Mercury)확산(diffusion)에 기반한 신규 대규모 언어 모델 시리즈로, 상업적 규모에서 작동하는 신세대 LLM임
  • 모든 모델은 Transformer 아키텍처에 파라미터화되어 있고, 여러 개의 토큰을 병렬로 예측하도록 학습함
  • 본 보고서에서는 주로 코드 생성 앱을 위해 설계된 머큐리 코더(Mercury Coder) 의 첫 라인업을 소개함
  • 머큐리 코더는 현재 MiniSmall 두 가지 모델 크기로 제공됨

주요 기여

  • 머큐리 코더는 속도와 품질 균형에서 새로운 state-of-the-art 수준을 달성함
  • 외부 평가 기관인 Artificial Analysis 기준:
    • Mercury Coder Mini: 초당 1109 토큰
    • Mercury Coder Small: 초당 737 토큰 성능을 NVIDIA H100 GPU에서 기록함
    • 최고 속도 프론티어 모델 대비 평균 최대 10배 빠름과 유사한 품질을 보임
  • 다양한 프로그래밍 언어 및 활용 사례의 코드 벤치마크에서 추가적인 평가 결과도 제공함
  • 실제 개발자 환경(Copilot Arena)에서도
    • 품질 기준 2위
    • 속도 기준 전체 1위 기록 실현함
  • 누구나 활용할 수 있는 공개 API ( platform.inceptionlabs.ai )무료 챗 플레이그라운드( chat.inceptionlabs.ai ) 를 지원함

목차 구조 설명

  • Introduction(소개)
    • 주요 기여(Contributions)
  • Inception Mercury Model Family(모델 계열 설명)
    • 학습 과정(Training)
    • 추론 방법(Inference)
  • Capabilities(모델 기능)
    • 기준선 성능(Baselines)
    • 코드 생성 능력(Coding Capabilities)
      • 평가 벤치마크(Evaluation Benchmarks)

정리

  • 머큐리는 혁신적인 확산 기반 LLM 설계와 병렬 예측 구조를 조합하여, 코드 생성 분야에서 압도적인 속도 및 높은 품질을 실현함
  • 다양한 크기의 모델과 강력한 실 서비스 벤치마크, 쉬운 접근성을 통해 상용 및 개발 환경 모두에 경쟁력 있는 선택지를 제공함
Hacker News 의견
  • LLM 에이전트가 도입되면 테스트 성능이 더 심각한 CPU 병목 현상으로 이어질 전망이고, 이미 지금도 모든 팀이 CI 속도로 인해 병목을 겪는 상황임을 강조함
    에이전트가 사람보다 100배 빨리 코드를 써도, 테스트에 한 시간이 소요되면 의미가 없는 상황
    내가 일했던 많은 프로젝트에서 변경사항이 반영되길 기다리며 낭비되는 개발자 시간이 많았고, 많은 실행이 I/O 또는 작업자 부족으로 인해 병목됨
    코딩 에이전트가 단순 티켓을 빠르게 PR로 전환하고 테스트 실패에 반응해 실시간으로 수정하면서, CI 병목은 더욱 악화될 것
    대부분 프로젝트 테스트 환경에 개선 여지가 많은데, 실제로는 수년간 별다른 진전 없이 느린 CI와 높은 비용을 당연시하게 여겨온 분위기
    빌드를 완전히 격리하기 위해 캐싱을 끄거나, 온프레미스에서 느린 클라우드 VM으로 이전하면서 CI가 오히려 더 느려짐
    Mercury 속도가 미친 듯이 빠르고 몇 번 테스트해본 결과, 코드 품질도 훌륭하고 정확했으나, 이제는 테스트 실행까지 이 속도를 따라가게 하는 일이 과제로 남음

    • 내가 일한 대부분 프로젝트에서 PR 승인 기다리며 개발자 시간이 낭비된다는 점이 납득이 잘 되지 않음
      기업 입장에서 개발 시간은 기계 시간보다 훨씬 비싸므로, 개발자 불만이 나오면 CI 워커를 배로 늘릴 수 있는 문제임
      구글에서는 테스트 불안정성 디버깅 때 1만 대 머신에서 1만 번 테스트하며 드물게 발생하는 실패를 찾아내는 경우도 있었음
      내 현 직장도 유사한 방식을 제공하며, 커맨드 하나로 모든 테스트를 1천 워커로 병렬 실행해 1M LOC 프로젝트도 5분 내 피드백 받는 목적임
      빌드를 완전히 격리하는 것과 캐싱을 쓰지 않는 것은 별개이며, 빌드를 완전히 격리하면서도 모든 캐시를 최대한 활용해야 한다는 관점

    • 구현 속도가 빨라지면 병목이 PM 쪽으로 옮겨가고, 이 경우 변경이 더 직렬처리됨에 따라 충돌이 크게 줄어드는 현상 발생 예상
      스펙 정의 언어(TLA+ 등)의 부활 가능성도 있는데, 에이전트가 이를 빠르게 작성 및 검증하면서 전체 통합 테스트 수가 줄어들 수도 있음
      백그라운드 에이전트가 중복 코드를 정리할 때 중복 테스트도 함께 정리 가능성
      AI는 인간 엔지니어 팀과 달리 모놀리식 구조에서 더 효율적으로 일할 것으로 보이며, 이러면 로컬에서 돌릴 수 있는 테스트 커버리지 증가로 인해 flaky 감소 및 CI 부하 감소 효과
      AI가 효율성을 높여도 그만큼 더 많은 코드, 더 빠른 코드 생성 및 실행으로 새로운 문제가 계속 생길 것이며, 인간 엔지니어가 해결해야 할 새로운 문제가 지속적으로 나오리라는 확신

    • LLM이 100줄 미만의 빠른 수정, 또는 러버덕 역할 정도는 괜찮지만, 대형 프로젝트 CI 파이프라인에 LLM을 직접 넣으면 수백 시간 단위의 생산성 하락 우려
      실제로 코드 작성 실력을 키워야 할 시간에 프롬프트 튜닝과 컨텍스트 조정만 하게 된다면 의미 없음
      LLM 툴링에 대한 자신감이 너무 크다고 느끼며, 복잡한 시스템에는 잘 적용되지 않는다고 생각
      중요한 저장소에 무감독으로 LLM을 투입하는 일은 '총구를 들이대지 않는 이상' 있을 수 없다는 과한 불신
      결국 LLM의 결과를 반쯤 다시 손보게 되고, 그럴 바에야 직접 하는 게 낫다는 입장

    • 자동차 이전에는 기름, 오일, 정비 등에 거의 돈을 쓰지 않았으나, 시스템이 발전하면서 그에 맞는 부대 인프라와 비용이 따라오는 구조
      AI로 병목을 해결하거나 더 많은 기능을 만들어 수익을 극대화하고, 그 추가 수익으로 더 많은 CI 리소스를 확보하는 식의 순환 고리
      AI를 10명의 개발자 늘린 것과 다를 게 없고, 당연히 지원 비용이 늘어나는 현상
      효율성을 논리적으로 설득해 더 많은 CI 리소스를 확보하거나 최적화 방향을 제시할 수 있는지 되돌아보라는 관점
      CI 리소스 한 대당 비용이 얼마나 되는지 궁금

    • Python 앱에서 astral.sh 도구체인과 uv 패키지 설치 + 캐싱 활용으로 CI 속도를 크게 끌어올린 경험
      조만간 mypy 대신 astral의 타입체커로 옮길 예정이고, 이러면 더 빨라질 전망
      프론트엔드가 있는 앱의 경우 Playwright 테스트가 가장 느린 파트겠지만, 그마저도 다른 앱에선 해당 없음
      (추신: 혹시 Mike가 맞다면, 2000년대 초반 Google Maps에서 같이 일했던 SRE로 기억, 신뢰가 가는 의견임)

  • 내가 Mercury playground에서 정규표현식 패턴을 요청했더니, 모델이 스스로 계획을 세우고 패턴을 쓴 후 테스트를 생성하기 시작
    그런데 끝없이 테스트를 늘려가다 문맥 한도에 다다르자 응답이 끊겨버린 경험
    30개쯤 지나니 테스트 결과 주석을 잘못 붙이기 시작했고, 120개 넘어서부턴 테스트 입력 자체가 이상해져서 난수 문자가 잔뜩 나옴
    패턴 자체도 정답이 아니었으나, 이 ‘무한루프’ 현상이 더 흥미로운 이슈

    • 참고로, 불과 얼마 전까지 일반 LLM도 이런 ‘거의 무한루프’처럼 보이는 반복 출력을 하곤 했던 기억
      출력이 조금씩만 달라지는 패턴에 갇히는 일

    • 이 사례가 ‘토큰 예측만으로 코드를 정확하게 만들 수 없다’는 대표적 증거라고 생각
      LLM은 애초에 코드 사고에 적합하게 설계된 게 아니라는 평가

  • 내가 기술 보고서를 읽어본 결과, Mercury가 논문 Lou et al. 2023, SEDD 기반임을 확인
    내가 최초(아마도)로 SEDD를 from-scratch로 재구현했으며, 코드 공개
    복잡한 디노이징 방법도 직접 구현
    기존 SEDD보다 깔끔하고 읽기 쉽도록 설계했고, 단일 GPU에서 장난감 데이터셋 기준 몇 시간 내 구동 가능

  • 참고로 DeepMind에서도 diffusion 기반 Gemini 모델이 있음 (링크)
    직접 테스트해보니 Mercury처럼 속도는 미쳤지만, 답변 품질은 다른 Gemini에 비해 많이 떨어졌던 경험

    • 간단히 써본 바로는 속도는 인상적이지만 정답률이 많이 떨어지는 현상에 동의

    • Gemini Diffusion 데모가 무료인지 궁금
      며칠째 웨이팅리스트 중이라 실제 써 볼 기회가 없어 아쉬움

  • 개인적으로 이런 발전이 굉장히 기대됨
    최근 게임잼 때 AI로 간단한 게임을 코딩했는데, 결과 기다리며 보내는 시간이 절반 이상 차지
    프롬프트당 결과가 1~2분씩 걸리는 현상에서 10초만 기다리면 된다면, 기존에 한 번 테스트할 동안 다섯~열 번 실험이 가능
    아직 Mercury가 실용적으로 사용할 수 있을 만큼 성숙하진 않았으나, Claude 3.0도 1년 전은 미흡했으니 앞으로는 더 나아질 전망
    앞으로가 정말 기대되는 시점

  • Mercury playground 써보니 속도가 정말 굉장함
    확산모드(diffusion mode) 시각화도 신선하지만, 실질적으로는 시각화된 선 노이즈에서 점점 더 정확한 상태로 다듬어지는 과정을 보여주는 듯함
    실제로는 임의 벡터 공간에서 점점 확실한 토큰으로 수렴하는 과정으로 봄

    • 일부 텍스트 diffusion 모델은 연속적인 잠복 공간(latent space)을 사용하지만, 성능이 썩 좋지 않음
      최근에는 대개 실제 토큰 출력 예측에 집중하며 단계별로 이전 값을 수정해 최종 결과로 수렴
      내가 쓴 텍스트 diffusion 작동 원리 설명 링크 참고 추천

    • 링크 : https://chat.inceptionlabs.ai/

    • 진짜 말도 안 되게 빠르다고 느낌

  • 대부분 GPU 인접 코드에 성능 최적화 여지가 매우 큼
    하지만 arXiv 논문이 실제 연구라기보다 마케팅에 가깝다는 의문 제기
    다른 의견 환영

    • 그렇게 틀린 포인트는 아니지만, arXiv에서 이런 사례는 이번이 처음이 아니라는 점
  • Mercury 모델 가격정책
    출력 토큰 100만 개당 1달러, 입력 토큰 100만 개당 0.25달러
    자세한 요금정책은 여기 참고

    • 가격이 살짝 높은 편
      성능 민감한 경우, Mercury와 Groq(Llama 3.1 8b, Llama 4 Scout) 비교 시 성능은 비슷했으나 Groq의 가격이 훨씬 유리
      디퓨전 모델의 오픈소스 출현을 기대하며 관심 있게 지켜보는 중
  • playground 코드와 API 응답에서 gpt-3.5-turbo"openai": true 항목이 보여 실제로 자체 dLLM이 아닌 OpenAI를 부르는 건지 궁금
    우측 상단 diffusion effect 기능은 단순 애니메이션 효과로 보여짐

    • 실시간 같은 속도라 실제 OpenAI 백엔드 쓴다고 보기엔 너무 빠름
  • 모든 것이 멋지게 들리긴 하지만,
    서비스에 사용자 게시물을 제출하면 전 세계적으로 독점적이지 않고, 영구적이며, 로열티 없는 무료, 전면 양도 가능한 라이선스를 Inception에 부여하게 되는 약관임
    즉, 사용자의 컨텐츠를 AI 모델 훈련 목적으로 쓸 수 있음
    (단, OpenRouter 경유 접속분은 학습에 사용하지 않는다는 예외 조항 있음)