Inception Mercury 2.5 출시, 확산 언어 모델은 속도 경쟁을 어디까지 바꿀까
AI를 활용하여 생성한 이미지입니다.
AI 모델을 고를 때 ‘초당 토큰 수’가 눈에 먼저 들어오지만, 빠른 출력이 곧 좋은 업무 결과를 뜻하지는 않습니다. Inception은 2026년 9월 8일 Mercury 2.5를 공개하면서 확산 언어 모델(diffusion language model, dLLM)을 상용 API와 호스팅 경로에 연결하는 방향을 제시했습니다.[1] 이번 출시는 속도·비용·품질을 따로 측정해야 하는 개발자에게는 흥미로운 선택지이지만, 기존 모델을 즉시 바꿔야 한다는 결론과는 거리가 있습니다.
Mercury 2.5는 무엇이 다른가
일반적인 자기회귀 언어 모델은 앞에서부터 토큰을 하나씩 예측하며 문장을 이어 갑니다. dLLM은 무작위에 가까운 텍스트에서 시작해 여러 위치의 토큰을 반복적으로 다듬는 방식으로 설명됩니다.[1] 이 구조가 서비스 환경에서 안정적으로 구현되면, 계산 작업을 더 병렬화해 첫 응답과 전체 생성 시간을 줄일 여지가 있습니다. 다만 모델이 내부적으로 병렬 처리를 한다고 해서 모든 요청이 같은 속도로 끝나는 것은 아닙니다.
Inception은 Mercury 2.5가 프로덕션에서 초당 1,100토큰 이상을 처리한다고 밝혔고, Inception API·OpenRouter·Baseten에서 사용할 수 있다고 소개했습니다.[1] 여기서 ‘프로덕션’이라는 표현은 회사가 제시한 제품 설명이지, 모든 언어·프롬프트·출력 길이에서 재현되는 독립 측정값은 아닙니다. 실제 서비스에서는 네트워크 왕복, 큐 대기, 스트리밍 방식, 도구 호출 시간이 함께 들어갑니다.
공개된 성능·가격을 읽는 법
Inception은 Mercury 2.5가 이전 Mercury 2보다 지능 평가에서 10포인트 높아졌고 비용도 낮아졌다고 설명합니다.[1] 같은 발표는 Mercury 2가 Claude Haiku와 GPT Mini 수준의 지능을 유지하면서 약 10배 높은 처리량을 냈다고 주장하고, 2.5가 그 구조를 이어받으면서 더 높은 지능을 목표로 한다고 말합니다.[1] 여기서 ‘지능 평가’의 구체적인 벤치마크·프롬프트·채점 방식이 모두 공개되지 않았다면, 해당 숫자를 일반 업무 품질로 그대로 옮겨서는 안 됩니다.
독립 보도는 회사 공개 자료를 바탕으로 처리량을 약 1,107토큰/초로 정리하고, 표준 가격을 입력 100만 토큰당 0.20달러, 출력 100만 토큰당 0.75달러로 소개했습니다.[2] 출시 기간에는 입력 0.04달러, 출력 0.15달러의 80% 할인도 언급됐습니다.[2] 할인은 기간·계정·호스팅 경로에 따라 달라질 수 있으므로, 예산을 짤 때는 현재 API 콘솔의 단가와 할인 종료 뒤 단가를 각각 적어야 합니다. 평균 응답 토큰 수와 재시도율까지 넣어야 실제 비용에 가까워집니다.
빠른 모델이 특히 맞을 수 있는 작업
첫 토큰을 빨리 보여 줘야 하는 음성 에이전트, 짧은 검색 요약, 반복적인 코드 보조처럼 사용자가 기다리는 시간이 곧 이탈로 이어지는 작업은 후보가 될 수 있습니다. Inception은 음성·코딩 에이전트 사용을 설명하면서 첫 토큰까지 170ms 미만을 목표로 하는 Mercury Voice와 Mercury Router 미리보기도 함께 공개했습니다.[1] ‘목표’와 실제 보장값을 구분해야 하며, 긴 요청이나 외부 도구를 호출하는 동안에는 모델 자체의 속도만으로 체감 지연을 판단할 수 없습니다.
반대로 긴 문서의 조건을 빠짐없이 따르는 업무, 복잡한 함수 호출, 정교한 JSON 출력, 한국어 문서 편집처럼 정확성이 더 중요한 작업은 속도 순위만으로 선택하기 어렵습니다. 짧은 답변을 빠르게 내더라도 잘못된 도구 인자 하나가 전체 파이프라인을 다시 실행하게 만들면 비용과 시간이 늘어납니다.
교체 전 비교 절차
- 업무를 나눕니다. 짧은 요약, 한국어 장문 작성, 코드 수정, 구조화 출력, 함수 호출을 한 묶음으로 평가하지 말고 별도 시나리오로 만듭니다.
- 조건을 고정합니다. 같은 시스템 지침, 입력 문서, 최대 출력 토큰, temperature 등 서비스에서 실제 쓰는 조건을 기록합니다. 한 모델만 유리한 프롬프트를 쓰면 비교가 무너집니다.
- 시간을 분리해 기록합니다. 첫 토큰까지의 시간, 전체 응답 시간, 외부 도구 대기 시간을 따로 측정합니다. 초당 토큰 수는 이 세 값을 대신하지 않습니다.
- 형식을 검사합니다. 함수 호출 JSON이 매번 유효한지, 필드가 빠지지 않는지, 스트리밍 중 중복 토큰이 생기지 않는지 확인합니다.
- 실패 비용을 계산합니다. 재시도 횟수, 사람이 고치는 시간, 긴 입력에서의 누락, 할인 종료 후 단가를 포함해 월 비용을 다시 산출합니다.
확산 모델을 검토할 때 놓치기 쉬운 예외
병렬 생성의 장점은 출력 길이와 작업 유형에 따라 다르게 나타날 수 있습니다. 짧은 답변에서는 네트워크 지연이 더 크게 보일 수 있고, 긴 출력에서는 속도 이점이 있어도 품질 검수 시간이 늘어날 수 있습니다. 코드 보조에서는 빠른 자동완성보다 중괄호·인용부호·함수 인자의 정확성이 중요합니다. 음성 서비스에서는 첫 응답이 빨라도 사용자의 발화를 잘못 분리하면 대화가 끊깁니다.
또한 OpenAI 호환 API라는 이유만으로 모든 기능이 그대로 작동한다고 가정하면 안 됩니다. 스트리밍 이벤트, 도구 호출 스키마, 구조화 출력, 문맥 길이, 오류 코드, 사용량 집계 필드가 서비스마다 다를 수 있습니다. 작은 트래픽을 별도 라우트로 보내 로그를 남기고, 실패하면 기존 모델로 되돌리는 방식이 안전합니다.
자주 묻는 질문
초당 1,100토큰이면 기존 모델보다 항상 빠른가요?
아닙니다. 그 수치는 회사 발표와 이를 인용한 보도에 나온 처리량입니다.[1][2] 입력 길이, 출력 길이, 동시 요청, 네트워크와 도구 호출에 따라 실제 응답 시간은 달라집니다.
할인 가격을 기준으로 서비스를 설계해도 되나요?
할인 종료 시점을 확인하기 전에는 안 됩니다. 표준 단가, 재시도율, 캐시 사용, 호스팅 수수료를 넣어 할인 없는 월 비용을 먼저 계산하세요.
dLLM이면 품질이 낮거나 높다고 볼 수 있나요?
구조만으로 품질을 판단할 수 없습니다. 실제 업무 데이터에서 정확성, 형식 준수, 긴 문맥 누락, 한국어 표현을 별도로 평가해야 합니다.
작은 트래픽으로 시작할 때의 운영 기준
새 모델을 시험할 때는 기존 모델과 결과를 무작정 섞지 말고, 요청 유형별로 라우팅 규칙을 정하는 것이 좋습니다. 예를 들어 짧은 초안과 자동완성은 Mercury 2.5 후보로 보내되, 계약서 요약이나 고객에게 바로 노출되는 답변은 기존 모델과 사람 검토를 유지할 수 있습니다. 로그에는 모델명, 입력·출력 토큰, 첫 토큰 시간, 전체 시간, 재시도 횟수, 오류 유형을 남겨야 할인 효과와 실제 운영 효과를 구분할 수 있습니다.
품질 검토표에는 정답률만 넣지 말고 형식 준수와 복구 가능성도 포함하세요. 도구 호출이 실패했을 때 오류 메시지를 이해하고 다시 요청하는지, 빈 응답이나 잘린 JSON을 안전하게 차단하는지, 사용자가 기다리는 동안 진행 상태를 보여 주는지도 서비스 품질입니다. 이런 안전장치가 없다면 높은 처리량이 오히려 실패를 빠르게 늘릴 수 있습니다.
Mercury 2.5에서 확실히 읽을 수 있는 신호는 dLLM을 빠른 API와 여러 배포 경로에 연결하려는 Inception의 전략입니다. 개발자는 ‘가장 빠른 모델’을 찾기보다 첫 토큰, 전체 시간, 오류율, 검수 비용을 함께 비교해 좁은 작업부터 도입하는 편이 좋습니다. 관련 모델 소식은 AI·LLM 글 더 보기에서도 확인할 수 있습니다.
운영 단계에서는 새 모델의 가격표만 구매팀에 넘기지 말고, 장애 때 기존 경로로 되돌리는 방법과 키·로그의 보관 범위도 문서화하세요. 여러 호스팅 경로를 지원하더라도 사용량 집계가 다르면 비용 보고서가 어긋날 수 있습니다. 작은 샘플에서 통과한 뒤에도 배포 전에는 실제 트래픽과 비슷한 입력을 다시 돌려야 합니다.
운영팀은 모델 이름보다 회귀 기준을 먼저 정해 두어야 합니다. 기존 모델에서 통과하던 샘플이 새 모델에서 실패하면 자동 전환을 멈추고 원인을 분류한 뒤 다시 비교하세요.
기업에서 사용할 때는 모델 제공자의 데이터 보관·학습 사용·지역 처리 조건과 내부 보안 규정을 함께 검토해야 합니다. 응답 속도가 좋아도 민감한 원문을 외부 경로로 보내는 결정은 별도의 승인 대상입니다.
