Hacker News

Mercury 2.5 LLM hits 770 tokens per second

Mercury 2.5, 초당 770토큰 생성

Inception의 Mercury 2.5는 출력 속도 780.8토큰/초를 기록했지만, Artificial Analysis Intelligence Index 점수는 12로 비슷한 가격대 추론 모델의 중앙값과 같습니다. Hacker News에서는 빠른 응답이 유용한 작업이 있다는 의견과, 품질이 낮으면 속도와 가격의 이점도 제한적이라는 지적이 맞섰습니다.

AI 요약

Inception의 Mercury 2.5는 텍스트를 입력받아 텍스트를 출력하는 추론 모델입니다. Artificial Analysis 분석에서 출력 속도는 초당 780.8토큰으로 측정됐습니다. 비슷한 가격대 추론 모델의 중앙값인 110.3토큰/초보다 빠르지만, 첫 토큰까지 걸리는 시간(TTFT)은 2.91초로 중앙값 2.22초보다 깁니다. 따라서 생성 속도만으로 응답 대기 시간이 짧다고 보기는 어렵습니다.

성능과 비용

Artificial Analysis Intelligence Index 점수는 12입니다. 페이지는 이를 비슷한 가격대 추론 모델보다 낮은 수준으로 분류하며, 비교 모델의 중앙값도 12로 제시합니다. 평가 과정에서 생성한 출력은 3,500만 토큰으로, 중앙값 8,500만 토큰보다 적었습니다. 평가 작업 하나를 실행하는 데 드는 평균 비용은 0.06달러입니다.

입력 토큰 가격은 100만 개당 0.25달러, 출력 토큰은 100만 개당 0.75달러입니다. 페이지가 제시한 캐시 적중·입력·출력 비율 7:2:1을 적용한 혼합 가격은 100만 토큰당 0.14달러입니다. 문맥 창은 26만 토큰이며, 이미지 입력은 지원하지 않습니다. 모델 크기와 가중치는 공개되지 않았습니다.

속도와 품질을 둘러싼 반응

Hacker News에서는 속도와 모델 성능 중 무엇을 우선할지가 논쟁의 중심이 됐습니다. 일부 이용자는 응답이 빨라야 하는 제품이나 반복적으로 초안을 개선하는 작업에서 속도가 유용하다고 봤습니다. 반면 다른 이용자들은 낮은 품질의 결과를 빠르게 생성해도 소용이 없다고 지적했습니다. 작은 작업으로 나누고 평가·검증 절차를 붙이면 약한 모델의 결과를 개선할 수 있다는 의견도 나왔지만, 작은 모델은 같은 작업을 반복하며 막힐 수 있다는 반론이 이어졌습니다.

비슷한 속도를 내는 다른 모델과의 비교도 나왔습니다. 한 이용자는 Cerebras의 GPT-OSS-120B가 초당 1,400토큰을 내며 비슷한 순위라고 주장했고, 다른 이용자는 해당 모델의 도구 호출과 출력 문제, 캐시 할인 부재에 따른 비용을 지적했습니다. 토론에는 초당 수백 토큰이 코딩 작업에 꼭 필요한지, 여러 에이전트의 답을 빠르게 비교하는 데 쓸 수 있는지를 놓고도 의견이 갈렸습니다.

확산(diffusion) 방식 언어 모델의 활용처에 관한 논의도 있었습니다. 이용자들은 대규모 동시 요청을 처리할 때 하드웨어를 효율적으로 공유하기 어렵다는 점과, 기기 안에서 낮은 지연 시간으로 동작하는 작업에는 가능성이 있다는 점을 언급했습니다. 다만 이번 분석 자료는 Mercury 2.5의 생성 속도와 벤치마크 결과, 가격을 보여주며 모델 구조나 특정 사용 사례의 성능을 설명하지는 않습니다.

Hacker News 반응

  • @rvz — 최첨단 AI 회사들의 모델과 비교하면 거의 꼴찌로 끝나는데, 속도가 무슨 의미가 있나요?
    • @copperx — 역시 ‘좋거나, 빠르거나, 싸거나. 둘 중 하나를 고르라’는 옛말이 맞네요.
    • @voiceeh — 사용 사례가 속도를 요구한다면 그렇지 않습니다. 제 제품 중 하나는 TTFT p99가 700밀리초를 넘는 LLM을 쓸 수 없습니다.
    • @timClicks — 속도는 의미가 있습니다. 반복 작업 흐름에서는 토큰을 더 쓰더라도 약한 모델이 초안을 조금씩 개선해 작업을 해낼 수 있습니다.
  • @walrus01 — 입력 0.25달러, 출력 0.75달러면 DeepSeek V4 Flash나 Qwen 3.8-Flash-Next 같은 비슷한 급의 오픈 웨이트 모델을 평판 좋은 추론 제공업체에서 쓰는 것보다 이미 훨씬 비쌉니다. 그래서 쓸 이유가 안 보입니다.
    • @RussianCow — 쓸 이유는 속도입니다.
    • @_aavaa_ — 모델이 멍청해서 결과가 나쁘면, 얼마나 빨리 내놓는지는 신경 쓰지 않습니다.
    • @calgoo — 문제를 훨씬 작은 작업으로 쪼개고, 답을 확인한 다음 매 라운드의 문맥, 작업 분해, 작업 정의, 검증을 처리하는 하네스를 만들면 가능합니다.
    • @RussianCow — 그래도 비교적 멍청한 모델이면 충분한 사용 사례가 많습니다.
  • @bearjaws — 속도가 중요하다면 Cerebras GPT-OSS-120B는 초당 1,400토큰이고 순위상 ‘비슷하게 똑똑합니다’. 재미 삼아 몇 가지 프로젝트에 써봤는데 속도가 정말 놀랍습니다.
    • @LoganDark — Cerebras에서 GPT-OSS-120B를 쓰지 마세요. 도구 호출을 자주 망치고, 사고 블록을 끝내지 못하는 등 문제가 많습니다. 속도는 놀랍지만 그만한 값어치는 없습니다. 입력 캐시 가격도 따로 없어서 에이전트 하나만 돌려도 분당 5~10달러가 들 수 있습니다.
  • @nylonstrung — 확산 방식 LLM은 막다른 길이라고 생각합니다. Google 같은 선도 연구소가 실험했지만 속도와 비용에 민감한 소형 모델에도 더 투자하지 않은 점이 눈에 띕니다. 어떤 사용 사례에서 최선의 선택인지 아직 불분명합니다.
    • @LarsDu88 — 작은 스타트업과 Anthropic의 학습 환경을 같은 기준으로 비교할 수는 없습니다. Google이 DiffusionGemma로 바꾸지 않은 주된 이유는 큰 배치로 서빙할 때 확산 방식의 속도 이점이 사라지기 때문일 수 있습니다. 한 기기에서 많은 사용자를 처리하는 대신 로봇 같은 기기 내 저지연 작업이라면 이야기가 달라질 수 있습니다.
    • @clhodapp — 텍스트 확산이 완전히 막다른 길이라기보다 에이전트 작업 흐름에 잘 맞지 않는다고 봅니다. 규모를 키우고 최적화했을 때 작성과 편집 작업에서 어떨지 여전히 궁금합니다.
  • @freakynit — Mercury 2.5를 여러 작업에 써봤지만 아직 부족합니다. 제 경험으로는 기껏해야 14B 모델 수준인 것 같습니다. GPT-OSS-20B도 제 테스트에서는 훨씬 나았습니다. 속도와 가격 조합이 좋아서 정말 쓰고 싶었지만, 기본 작업에도 쓰지 않고 있습니다.
    • @nostrebored — Celeris-magnus-1을 써보세요. 비슷한 속도인데 Qwen 27B 밀집 모델에 훨씬 가깝습니다.
    • @nostrebored — 사용 사례에 따라 다릅니다. 작고 거래 중심인 작업에서는 꽤 강하고 빠릅니다.

원문: Artificial Analysis / 번역·요약: Trawling