요약
인셉션이 초당 1,000토큰 넘게 생성하는 디퓨전 언어 모델 Mercury 3를 내놓았습니다.
인셉션은 블로그에서 Mercury 3를 지금까지 나온 디퓨전 언어 모델(문장을 한 토큰씩 잇지 않고 전체를 여러 번 다듬어 만드는 모델) 가운데 가장 뛰어나다고 소개했습니다. GPT-6 Luna와 Claude Haiku 5.5보다 낫거나 비슷한 성능을 내면서 4~8배 빠르다고 주장합니다.
왜 중요한가
- 디퓨전 모델도 기존 언어 모델처럼 크게 키울수록 똑똑해진다는 근거로 내세운 발표입니다.
- 음성 상담이나 실시간 검색처럼 응답 지연이 중요한 서비스에 빠른 대안이 생겼습니다.
핵심 내용
- NVIDIA GPU에서 초당 1,068토큰을 생성했다고 밝혔습니다.
- 매개변수는 Mercury 1의 40배가 넘지만 정확한 규모는 공개하지 않았습니다.
- 컨텍스트 창(한 번에 읽는 분량)은 Mercury 2.5의 26만 토큰에서 100만 토큰으로 늘었습니다.
- 요금은 100만 토큰당 입력 0.20달러, 출력 0.70달러이고 출시 기념으로 절반 할인합니다.
- 초기 고객사들은 브라우저 에이전트, 고객 상담, 실시간 검색에서 더 빨라졌다고 전했습니다.
HN 반응
- 직접 써 본 이용자들은 이전 세대보다 확실히 나아졌다고 평가했지만, 실제 속도는 초당 160~400토큰에 그쳤다는 경험담이 이어졌습니다.
- 구글 Gemini Diffusion이 잠잠한 이유로는 디퓨전 모델이 여러 요청을 묶어 처리할 때 효율이 낮아 대규모 서비스에선 토큰당 비용이 비싸다는 설명이 나왔습니다.
펠리컨 결과가 나쁘지 않아요. 약간 독특하긴 하지만요: https://tools.simonwillison.net/markdown-svg-renderer?url=https%3A%2F%2Fgist.github.com%2Fsimonw%2Ffdde7627991863337b2021c1eeb9f889
위 결과는 OpenRouter를 거쳐서 얻은 것이고, 아래는 Inception API를 직접 호출해서 만든 또 다른 세트입니다: https://tools.simonwillison.net/markdown-svg-renderer?url=https%3A%2F%2Fgist.github.com%2Fsimonw%2Fc435e1d044505887bcf27ffd77fc5b16
지난번 Mercury 2.5로 뽑았던 것보다 훨씬 나은 SVG네요. 저는 3D 모델링을 시켜 봤는데, 놀랄 만큼 빠르게 꽤 멋진 결과가 나왔어요. 다만 반복해서 다듬어도 눈에 띄게 나아지지는 않더라고요(워낙 빠른 모델이라 그렇게까지 기대하진 않았지만요).
그래도 Mercury 인스턴스 10개가 하나의 콘셉트를 두고 동시에 반복 작업하는 모습(개인 데모로 돌려 봤어요)은 현실 같지가 않았어요.
벤치마크를 왜 medium으로 돌렸는지 궁금하지 않았는데, 이제 알겠네요. medium으로 만든 펠리컨이 high보다 낫습니다.
추론을 medium 이상으로 올리면 오히려 출력에 악영향을 주는지도 모르겠습니다.
생성하는 데 얼마나 걸렸나요? 이 모델의 핵심 셀링 포인트가 바로 그 속도인데요.
수정: 아, "3337ms"라고 나와 있네요.
다른 모델로 만든 작품들과 비교하면 어떤가요?
네, 속도는 좀 아쉬웠습니다. 그래서 OpenRouter를 거치지 않고 API에 직접 다시 돌려 봤는데, 딱히 빨라지지는 않더군요.
펠리컨 한 마리를 통째로 만들어 내는 데 3초 걸리는 걸 느리다고 하는 시대라니, 세상 참 미쳤네요.
작년에 공개한 Gemini Diffusion 데모를 구글이 왜 사실상 그대로 방치했는지 아직도 이해가 안 됩니다.
정말 멋지고 빨랐는데, 그냥 조용히 사라졌어요.
몇 달 전에 Diffusion Gemma를 내놓긴 했지만, 그쪽도 큰 반향은 없었던 것 같고요.
구글 잘못이 아니에요. 우리 잘못이죠. llama.cpp는 지원을 안 하고, vllm은 호스트 RAM으로 제대로 오프로딩을 못 하고, huggingface transformers는 지원하긴 하는데 Diffusion Gemma 같은 MoE는 f16 양자화만 돼요. 확산 모델이 정말 속도를 끌어올려 줄 수 있는 저사양 머신에서는 쓸 수가 없다는 겁니다.
이렇게 대단한 모델을 눈앞에 두고도 잠만 자고 있는 셈이에요. 확산 모델에서는 특정 문구를 제대로 금지할 수 있어요. 가중치 하나 건드리지 않고, 역전파 한 번 돌리지 않고도 검열을 풀고 AI 특유의 상투적인 말투(slop)를 걷어낼 수 있다고요.
구글 프리프린트에 따르면 배치 크기가 작을 때는 잘 동작했는데, 지금 대부분의 프로덕션 배포는 여러 사용자를 동시에 서비스하느라 배치 크기가 꽤 큽니다.
좋은 답변이네요, 감사합니다. 그 부분은 놓치고 있었어요.
솔직히 그런 문제 상당수는 더 최적화된 커널로 해결할 수 있고, 지금의 LLM은 그런 커널을 꽤 잘 짜거든요. 구글이 자기회귀 모델을 다시 학습시키지 않고도 확산 추론용으로 바꿀 수 있다는 걸 보여줬으니, 사용률이 낮은 경우에는 Gemini Flash 배포 일부가 확산 방식으로 넘어가더라도 놀랍지 않을 것 같아요.
제 기억으로는 재학습은 필요합니다. 다만 처음부터 사전 학습을 하는 것보다는 파인튜닝에 가까운 수준이에요. 그리고 그렇다는 건 모델의 성능 특성도 달라진다는 뜻이기도 합니다.
그 말이 사실이라면 그게 진짜 답이겠네요. 아니, 오히려 반(反)답에 가깝습니다. 결국 "구글이 못 할 이유가 없다"는 얘기니까요.
구글이 또 구글 했네요...
로컬 모델로 돌리면 더 잘 동작하지 않을까요?
이 발표가 그쪽 진행 상황을 어느 정도 알려 줍니다: https://youtu.be/r305-aQTaU0?si=j3IqG9BAT0uumPeA
큰 틀에서 말하면 이렇습니다. "표준" 자기회귀 모델처럼 배치로 메모리 대역폭 부담을 줄이는 이점을 이 방식은 누리지 못합니다. 그래서 개별 사용자나 동시 접속이 적은 환경에서는 지연 시간을 크게 줄여 주고 일부 작업에서 더 나은 결과도 내지만, 대규모로 돌리면 토큰당 비용이 훨씬 비싸집니다.
이전 세대보다 눈에 띄게 유능해 보입니다. 일부러 모호한 프롬프트로 UML 다이어그램용 HTML 렌더러를 만들어 달라고 했는데, 인상적인 결과물이 나왔어요. 그다음 질문을 하나 던졌고, 세 번째 프롬프트에서 그 HTML을 수정해 달라고 했더니 제대로 고쳐 주더군요.
또 하나 눈에 띈 점은(그냥 신기해서일 수도 있지만) 테마마다 서로 다르고 눈이 덜 아픈 색 구성을 골랐다는 거예요. 개발팀에 축하를 전합니다.
질문이 있습니다(여기 팀 분들이 계시고 저는 API로 Inception을 써 본 적이 없어서요). 코딩 에이전트로 코드베이스에 변경을 요청하면 코드를 얼마나 읽어야 하나요? 도구 호출은 얼마나 잘 처리하나요? 확산 방식은 접근법이 다르니, 예를 들어 큰 작업을 진행할 때 코드베이스를 한 단계씩 바꿀 때마다 필요한 코드량이 궁금합니다.
컨텍스트 요구량은 똑같을 거라고 생각합니다. 작업을 끝내는 데 필요한 지식이 곧 필요한 컨텍스트니까요. 이걸 피할 수 있는 새로운 기법은 없어요.
이걸 피할 수 있는 새로운 기법은 없죠. 하지만 어떤 기법은 상황을 더 나쁘게 만들 수 있어요.
좀 더 설명해 주실 수 있나요? 모델과 하네스 조합이 필요 이상으로 많은 파일을 읽는다는 뜻인가요?
지난 몇 시간 동안 써 봤습니다. 처음에는 꽤 느렸는데 지금은 300~400tps 정도 나와요. 1000tps에는 한참 못 미치지만, 제가 다른 모델들로 겪던 속도에 비하면 여전히 엄청나게 빠릅니다. 성능도 꽤 괜찮아요. 격투 게임을 플레이하는 AI를 학습시키는 전략을 제시해 달라고 했더니 논리가 탄탄한 답을 내놨습니다. 제 기존 지식 베이스에서 녹화/재생을 포함한 게임 내부 동작에 관한 자료를 검색했고, 그 게임이 어떻게 플레이되는지에 대한 자체 일반 지식도 활용했어요. 제 의견에 아부하지도 않았고, 적절하게 반박도 하더군요.
광고하는 속도를 합리적인 가격으로 대규모에서도 낼 수 있다면 정말 괜찮은 모델이 될 것 같아요. 요금제를 단계별로 나누는 방식도 잘 맞을 수 있겠고요.
이 사람들 정말 좋아합니다. 소름 끼치는 "dots" 같은 것이나 Slack에서 거슬리게 @Claude를 부르는 것 따위에 시간을 쓰는 대신, 속도라는 실질적인 개선을 내놓잖아요. 빠른 LLM이 어떤 UX를 가능하게 하는지 상상도 못 하실 겁니다! 코딩에서도 저는 늘 컴파일 타임에 강한 타입 시스템을 옹호해 왔고, 진짜 보일러플레이트 타이핑만 넘겨서 실제로 생각하는 시간과 고정밀 프로토타이핑 속도를 최대한 끌어올리는 쪽이었습니다.
실제로 JetBrains IDE와 연동되는 작은 프로토타입을 만들었어요. IDE 안에서의 활동을 추적하는데(JetBrains 자체의 "파일 단위 탭 자동완성" 기능과 비슷합니다), 언제든 그 컨텍스트를 모두 실어 Codex를 호출해서 당시의 GPT-5.4-nano가 자잘한 작업을 마무리하게 할 수 있었죠. 예를 들어 새 유스케이스를 작성했고 그걸 새 엔드포인트로 노출하는 게 목표인데, 보일러플레이트 성격이 강하고 DRY도 제 스타일이 아니라고 해 봅시다. 그럼 필요한 파일을 열고 단축키를 누르고 원하는 걸 말하면 바로 결과가 나옵니다. 그런데 JetBrains Air가 그 기능을 어느 정도 흡수했고, Codex 토큰은 엄청나게 비싸고(API 비용 얘기는 꺼내지도 마세요), JetBrains는 "Junie Lite"(현재 Qwen 3.6 27B)로 그 비용을 기꺼이 대 주는 상황이라서 프로토타입은 접기로 했습니다. 그래도 속도와 결과 코드에 대한 통제력이 함께 있던 그 느낌이 그립긴 해요.
Mercury 3로 이 아이디어를 다시 해 보거나, JB에 통합해 달라고 요청해 볼지도 모르겠습니다.
이런 새롭고 참신한 방법들이 추진되는 이유 가운데 일부는 "dots" 같은 애플리케이션이 더 나은 기술을 요구하기 때문이라고 주장하고 싶네요.
"dots"는 긴 시간 동안 돌아가야 하는 거 아닌가요? Astra로 구동되는데도 여전히 충분히 좋지 않잖아요. 반면 Mercury는 같은 단위의 지능을 조금 더 싸게, 훨씬 더 빠르게 제공하는 데 집중하는 모델인데, 그건 항상 켜져 있는 예측 불가능하고 비결정적인 텍스트 자동완성에 딱히 필요한 게 아니에요.
@volodia(Inception 공동 창업자)가 여기에 댓글을 남겼는데 flagged/dead 처리돼 있어요. 이상하네요. 그렇게 되면 안 되는데요. 누가 좀 고쳐 줄 수 있을까요?
운영진에게 이메일을 보내세요. 이런 문제를 알리는 가장 좋은 방법입니다.
실제 모델 크기가 얼마인지, 학습 과정이 기존 LLM과 어떻게 달랐는지 정말 궁금합니다. 어쨌든 멋진 작업이에요. 비용은 여전히 많이 들지만, 이제는 신규 진입자가 최첨단에서 몇 달 뒤처진 수준까지 따라잡는 게 달성 가능한 일처럼 보인다는 게 놀랍습니다.
간단 후기입니다. 정말 빠르고, 초기 테스트에서는 아주 잘 동작합니다. 이걸로 백그라운드에서 돌면서 텍스트 OCR과 번역을 도와주는 작은 Swift UI 앱을 만들었어요[1]. CMD + Shift + O를 누르면 화면의 일부 영역을 선택하고(스크린샷 도구를 떠올리시면 됩니다), 그 영역에 OCR을 돌려서 결과를 Google Translate API로 보낸 뒤 영역 위나 아래에 툴팁으로 보여 줍니다. 단축키 조합, 번역 제공자, 목표 언어는 설정에서 바꿀 수 있고, 트레이 아이콘에서 설정에 들어가거나 도구를 켜고 끌 수 있어요. 먼저 이 도구의 계획을 세우게 한 다음 8~9단계에 걸쳐 처음부터 끝까지 구현하게 했습니다. 처음에는 좌표 계산을 틀렸는데 지적하니 금방 고쳤고, 그 외 나머지 단계는 한 번에 성공했어요. 코드에는 테스트도 있고 이 정도 규모치고는 괜찮아 보이며, 지금까지는 아주 잘 동작합니다. 프롬프트 입력, 테스트, 수정, 변경 승인까지 전부 합쳐 45분쯤 걸렸고, 토큰은 2,600만 개(캐시되지 않은 것은 130만 개)를 썼으며 속도는 160TPS 정도였습니다. 하네스는 Oh My Pi를 썼어요.
[1]중국어나 일본어를 공부할 때 가지고 있는 PDF가 macOS 미리보기의 선택 도구로는 안 되는 경우가 많은데, 선택할 수 있는 걸 다른 도구에 일일이 붙여 넣고 싶지는 않아서 이게 유용하더라고요.
블로그 글에서는 1000+TPS라고 하는데 160TPS밖에 안 나온 이유가 뭘까요? 성능이 아직 최전선 모델에 못 미치는 지금은 그게 이 모델의 유일한 매력으로 보이는데요.
PDF가 스캔본이라 디지털 텍스트가 인코딩돼 있지 않은 게 아니라면, OS API로 창에서 실제 텍스트를 가져와서 OCR 단계를 건너뛸 수 있을 텐데요.