Ming-3.0-audio-tiny vs Qwen-Audio 3.1: 산술 연산이 가능한 창 vs 그럴 수 없는 카탈로그

확인하기는 쉽지만 사용하기는 어려운 숫자가 있습니다: Ming-3.0-audio-tiny 내부의 텍스트 백본은 131,072개 위치로 구성되어 있고, 그 앞의 오디오 타워는 한 번에 128개 멜 빈으로 3,000프레임을 받습니다. Qwen-Audio 3.1은 이와 대조적으로 컨텍스트 길이를 전혀 공개하지 않습니다 — 모델 인덱스에도, 세 모델 ID에 붙은 한 줄 설명에도 없습니다. 한쪽은 숫자를 주고 해석은 당신에게 맡깁니다; 다른 쪽은 세 개의 제품 이름을 주고 하드웨어는 A​libaba에 맡깁니다. 그 비대칭이 비교의 전부이며, 어느 모델이 더 잘 듣는지에 관한 비교가 아닙니다. 이는 무엇이든 지출하기 전에 어느 쪽의 규모를 가늠할 수 있는지에 관한 비교입니다. 이와 같은 릴리스 뒤에 있는 문서화된 AI 실패 및 에이전트 사건은 OrcaRouter AI 사건 아카이브에 수집되어 있으며, 각 항목은 자체 출처, 심각도, 신뢰도 등급 및 이의 제기 플래그를 함께 제공합니다.

날짜부터 말하겠습니다. 이 모델은 연대기가 어색하기 때문입니다. Ming-3.0-audio-tiny의 가중치는 2026년 9월 3일 Hugging Face에 올라왔습니다. 저장소는 11:45 UTC에 생성되었고 두 개의 safetensors 샤드는 4분 뒤에 이어졌습니다. 최근에 바뀐 것은 체크포인트가 아닙니다. 2026년 10월 16일부터 19일 사이에 저장소는 그것을 중심으로 다시 작성되었습니다 — 마침내 비디오-언어 모델이 아니라 오디오 모델을 설명한 구성, 음성 출력을 위한 Talker, 전사본이 포함된 두 개의 참조 음성 클립, GitHub의 세 가지 배포 프로필, 그리고 10월 19일 13:19 UTC에 이 저장소가 지금까지 가져본 첫 모델 카드입니다. 아무도 이를 발표하지 않았습니다. 따라서 공정한 질문은 9월에 무엇이 출시되었느냐가 아닙니다. 그것을 실행하는 것에 관해 이제 무엇을 계산할 수 있는지, 그리고 A​libaba의 카탈로그가 대안에 관해 무엇을 계산하게 해 주고 무엇을 계산하게 해 주지 않는지입니다.

131,072 토큰을 분 단위로 환산하기

그 숫자는 실재하며 검증 가능하다. 이는 대부분의 컨텍스트 주장에 대해서는 할 수 없는 말이다. 텍스트 설정은 max_position_embeddings 131,072, 512폭 KV 잠재를 갖는 MLA 어텐션, 그리고 6,000,000의 로터리 베이스를 선언한다. 하지만 토큰 단위의 컨텍스트 윈도는 오디오 1초에 토큰이 얼마나 드는지 알아야 비로소 유용해지는데, 벤더는 그 말을 하지 않는다. 오디오 타워 자체의 숫자에서 이를 도출할 수 있다.

• 인코더 입력 — 128개 멜 빈으로 구성된 3,000개 프레임이며, 이는 Whisper가 10ms 홉에서 사용하는 것과 동일한 30초 창입니다.

• 다운샘플러 — 커널 [3,3,3], 스트라이드 [2,2,2]이므로 하나의 윈도가 1/8로 축소됩니다.

• 윈도당 토큰 — 3,000을 8로 나눈 값, 즉 약 30초 분량의 사운드에 대해 375개의 오디오 토큰.

• 그것이 의미하는 바 — 131,072를 375로 나누면 약 349개의 윈도가 되고, 파이프라인이 윈도 사이에서 다시 버퍼링하지 않고 하나의 연속 스트림을 공급한다면 이는 3시간이 조금 안 되는 오디오 분량이다.

그 마지막 조항은 상당한 역할을 하고 있으므로 이 점을 분명히 밝히고 싶습니다. 3시간이라는 수치는 공개된 두 구성 값에 대한 산술 계산일 뿐 공급업체의 주장이 아니며, 프로세서가 클립 사이에 위치를 재설정한다면 이는 틀린 값이 될 것입니다. 그리고 그것은 ASR 재현 프로필이 프롬프트당 오디오를 클립 하나로 제한할 때 암시하는 바로 그 내용입니다. 이를 인용할 사양이 아니라 테스트할 상한으로 취급하십시오.

산술이 아닌 것은 메모리 영향이다. MLA는 헤드별 키와 값 대신 KV 잠재를 저장하므로, 131K 윈도가 단일 카드에서 애초에 논의될 수 있는 것이다. 참조 텍스트 프로파일은 max_num_batched_tokens 32,768로 단일 GPU의 0.92를 예약하는데, 이는 전체 윈도에 큰 배치를 더한 크기로 잡은 예약이지 하한이 아니다. max_model_len을 줄이면 예약량도 함께 줄어든다. Thinker의 샤드는 총 17.74GB이므로, 24GB 카드에 가중치가 들어가고도 공간이 남는다.

상대 측은 동일한 질문에 제품 분할로 답변합니다.

알리바바의 Model Studio 인덱스는 Qwen-Audio 3.1을 컨텍스트 필드가 있는 하나의 모델이 아니라 세 개의 모델 ID로 나열합니다. qwen-audio-3.1-asr-flash-streaming 및 qwen-audio-3.1-asr-flash-filetrans는 음성 인식 아래에 있고, qwen-audio-3.1-realtime-plus는 음성 대 음성 아래에 있으며 별도의 ASR 및 TTS 호출 없이 엔드투엔드 음성 대화로 설명됩니다. 해당 페이지에는 가중치, 파라미터 수, 컨텍스트 길이, 가격이 없습니다. 각 ID의 상세 문서는 확인했을 때 열리지 않았습니다.

그 분할을 패키징상의 우연이 아니라 긴 오디오 문제에 대한 답으로 읽어야 한다. 파일 전사 SKU는 제공자가 오디오 한 시간을 판매하는 방식이다. 업로드하면 서비스가 원하는 대로 청크로 나누고, 컨텍스트 윈도는 다른 누군가의 엔지니어링 문제가 된다. 스트리밍 SKU는 제공자가 전화 통화를 판매하는 방식이다. 어느 SKU도 Ming이 드러내는 그 숫자를 노출하지 않는다. 즉 Ming-3.0-audio-tiny에서처럼 Qwen-Audio 3.1에 대한 용량 모델을 만들 수는 없고, 청구서만 만들 수 있으며, 그것조차 콘솔이 필요하다.

• 확인할 수 있는 항목 — Ming: 구성, 아키텍처, 라이선스, safetensors 파일 네 개, 벤치마크 이미지 세 개, 배포 YAML. Qwen: 식별자 세 개와 각각 한 문장.

• 산정할 수 있는 것 — Ming: 가중치 17.74GB, 텍스트용 GPU 1개, 음성용 GPU 2개. Q​wen: 여기서는 볼 수 없는 요금표를 읽기 전까지는 알 수 없음.

• 캐시할 수 있는 것 — Ming: 자신의 max_model_len에서 자신의 KV 캐시. Q​wen: 엔드포인트가 내부적으로 처리하는 모든 것, 보이지 않게.

• 실패 모드 — Ming: 당신이 일으켰고 고칠 수 있는 OOM. Qwen: 할당량, 리전, 또는 아무것도 반환하지 않는 문서 페이지.

• 라이선스 — Ming: MIT, 카드의 메타데이터와 GitHub 저장소의 LICENSE에 명시되어 있으나, Hugging Face 저장소에는 자체 LICENSE 파일이 포함되어 있지 않다는 점에 유의하세요. Qwen: Model Studio의 상용 약관을 따릅니다. 읽을 수 있는 가중치 라이선스가 없기 때문입니다.

아무도 솔직하게 답할 수 없는 벤치마크 질문

Ming-3.0-audio-tiny는 assets/에 세 가지 평가 이미지를 제공하며, 그 안의 모든 셀은 inclusionAI가 inclusionAI를 측정한 것입니다. 카드는 자기 평가 행에 별표를 표시하고 비교 모델이 자체 프롬프트와 디코딩 설정에서 재현되었다고 인정합니다. 이는 일반적인 공개이며 액면 그대로 받아들일 가치가 있습니다. 이는 결과가 아니라 설계 목표입니다.

이번 맞대결에서 숫자는 이중으로 어색하다. 유용한 열이 실제로 있는 열이 아니기 때문이다. 중국어 인식에서 이 소형 모델은 평균 3.79의 문자 오류율을 기록한 반면, 더 큰 형제 모델은 3.45였고, 방언에서는 10.29 대 9.40이었다. 오디오 지능에서는 확실히 뒤처진다. MMAU는 75.90 대 82.00, MMAU-Pro는 56.42 대 66.41이며, URO-Bench-Pro의 음성 상호작용 점수는 81.92에서 54.15로 무너진다. 이 모든 것은 flash에 비하면 미미하다. 그러나 Qwen-Audio 3.1에 비하면 어느 것도 미미하지 않다. Qwen-Audio 3.1은 비교 가능한 점수를 공개하지 않았고, 공유 테스트 세트도, 공유 디코딩 구성도, 둘 모두를 실행한 제3자도 없기 때문이다.

두 번째 격차도 이름 붙일 가치가 있습니다. 10초면 확인할 수 있기 때문입니다. 카드에는 공유 도표가 두 Ming 변형 모두의 결과를 포함한다고 적혀 있습니다. 이는 인식 이미지와 오디오 지능 이미지에는 해당됩니다. 텍스트 지능 이미지는 네 개의 열로 되어 있고 그 소형 모델은 그중 하나가 아닙니다 — 열은 Ming-3.0-audio-flash, Qwen3.8-Omni Flash, Qwen3.5-Omni Plus, Qwen3.5-Omni Flash입니다. 질문이 2.7B 활성 백본이 오디오에 관한 추론 대화를 할 수 있는지 여부라면, inclusionAI는 그 이미지에서 그것에 답하지 않았습니다. 이미지 위의 문장이 무엇을 말하든 말입니다.

3시간째에 두 형태가 서로 다르게 실패하는 방식

긴 오디오는 제품 분할이 겉치레에 그치지 않게 되는 지점입니다. 131K 창을 가진 단일 체크포인트는 하나의 모델이 전체 녹음을 읽고 마지막에 도달했을 때 처음 10분을 기억한다는 약속입니다. 그 약속에는 특정한 실패 모드가 있습니다. 모든 것이 함께 저하된다는 것입니다. 오디오가 창을 넘치면 청크로 나누게 되고, 청크 분할은 청크 간 추론이 조용히 죽는 곳입니다 — 2분에 등장한 화자는 40분에는 다시 낯선 사람이 됩니다.

파일 전사 SKU는 그 문제를 숨기고 다른 문제를 물려받는다. 청킹을 제어할 수 없으므로 잘못된 전사본을 재현할 수 없고, 서비스가 청크 간에 문맥을 유지했는지 아니면 독립적인 윈도들을 이어 붙였는지 알 수 없으며, 동일한 업로드 두 번 사이에서 출력이 달라질 때 격리할 변수가 없다. 스트리밍 SKU는 이름에서 그 제약을 솔직하게 드러낸다. 오디오가 도착하는 대로 내보내도록 만들어졌으며, 이는 자막에는 맞는 형태이고 90분 통화의 규정 준수 검토에는 틀린 형태다.

그래서 결정은 "어느 쪽이 더 정확한가"가 아닙니다 — 어느 쪽도 그것을 판가름할 숫자를 당신에게 주지 않았습니다. 결정은 "어떤 실패를 내가 디버깅할 수 있는가"입니다. 전사본을 바이트 단위까지 재현해야 한다면 체크포인트를 직접 소유하십시오. 20분 안에 전사본이 필요하고 다른 사람의 호출기를 써야 한다면, 그 SKU를 빌리십시오.

이 파이프라인에서 라우터가 진가를 발휘하는 곳

OrcaRouter는 Ming-3.0-audio-tiny를 제공하지 않습니다. 이 모델은 저희 카탈로그에 없으며 이에 대한 엔드포인트를 드릴 수 없습니다. 여기 어떤 내용도 이를 제공하겠다는 제안이 아닙니다. 라우터가 실제로 담당하는 것은 긴 오디오 파이프라인에서 오디오 모델이 아닌 부분입니다. 즉, 어떤 녹음을 로컬 2.7B 모델로 보내고 어떤 녹음을 더 큰 모델로 보낼지 결정하고, 전사본에서 요약을 작성하고, 실행 항목을 추출하고, 통화에 태그를 지정하는 일입니다. 이는 텍스트 호출이며, 하나의 키 뒤에 200개 이상의 모델은 네 개의 벤더 계약보다 더 짧은 경로입니다 — 공급자 정가에 0% 마크업이 적용되므로, 벤더가 가격을 인하하면 지불하는 금액도 같은 날 바뀝니다. 자동 장애 조치는 여기서 평소보다 더 중요합니다. 90분짜리 파일의 80분 지점에서 실패한 전사 작업은 처음부터 다시 시작하지 않고 두 번째 경로에서 재시도해야 합니다.

경계는 분명히 말할 가치가 있습니다. 라우터는 호출을 라우팅합니다. 라우터가 17.74GB 체크포인트를 호스팅 엔드포인트로 바꿔주지도 않고, Ming의 131K 창이 실제인지 알려주지도 않습니다. 그것은 오직 당신의 한 시간 분량 오디오만이 해줍니다.

결판을 내는 실험

이미 답을 알고 있는 녹음 하나를 — 세 명의 화자가 있고 그중 한 명이 문장 중간에 언어를 바꾸는 회의 녹음을 — 선택해 두 방식 모두에 통과시켜 보세요. Ming-3.0-audio-tiny의 경우 trust_remote_code=True로 로드하고, 카드가 검증하는 ASR 프롬프트를 사용하세요(언어를 말하고, 탭, 그 다음 전사 — 그 탭이 파서입니다). 그리고 max_model_len은 기본값이 아니라 정확히 필요한 길이로 설정하세요. Qwen-Audio 3.1의 경우 같은 파일을 파일 전사 SKU와 실시간 SKU 모두에 실행해 보세요. 서로 다른 제품이라 결과가 일치하지 않을 것이기 때문입니다.

그런 다음 세 가지를 비교하세요. 그중 어느 것도 벤치마크 점수는 아닙니다. 모델이 파일 전체에 걸쳐 화자 신원을 유지했나요? 음역하지 않고 언어 전환을 견뎌냈나요? 그리고 변수 하나를 바꿔 다시 실행할 수 있을 만큼 결과를 잘 설명할 수 있었나요? 마지막 질문은 여러분이 모델을 평가하는지 벤더를 오디션하는지를 결정하는 질문이며, 이 둘이 비슷하지 않은 유일한 지점입니다.