Microsoft-Decision-1 vs Liquid AI d1-omni-600M: 듣는 스코어러 대 읽기만 하는 스코어러

당신은 보험 데스크에서 청구를 배정하고 있으며, 파일은 세 가지로 도착합니다: PDF, 찌그러진 문 사진, 그리고 90초짜리 전화 통화입니다. Liquid AI d1-omni-600M은 문서를 읽고, 사진을 보고, 통화를 들은 다음, 미리 작성한 일련의 질문—이것이 보장 대상인가, 어느 범주인가, 2에서 10까지의 척도에서 심각도는 얼마인가—에 텍스트를 생성하지 않고 구문 분석할 것도 없이 단 한 번에 답할 수 있습니다. Microsoft-Decision-1은 문서를 읽을 수 있습니다. Microsoft Foundry에서 일반 제공을 시작한 날짜는 2026년 10월 8일이며, Qwen3.5-9B를 기반으로 사후 학습된 32,768토큰 창의 호스팅형 텍스트 전용 채점기로서 입력 표면은 거기서 끝납니다: 이미지도, 오디오도, 비디오도 없습니다. 둘 모두 사용자가 제공한 선택지에 대해 보정된 확률을 반환하고, 둘 모두 출력 토큰을 0개 생성하며, 어느 쪽도 보정 수치를 공개하지 않았습니다.

그 마지막으로 공유된 문장은 이 비교에서 불편한 부분이다. 이 둘은 이번 달 출시되는, 센서가 가장 넓은 의사결정 모델과 센서가 가장 좁은 의사결정 모델이며, 둘 사이의 아키텍처적 거리에도 불구하고 정확히 동일한 증거적 위치에 도착했다: 실제 가중치 또는 실제 엔드포인트, 문서화된 계약, 그리고 누군가 그 확률을 신뢰할 수 있는지 묻는다면 벤더 외부의 누구도 가리킬 수 있는 숫자가 없다.

두 조상이지, 두 크기가 아니다

587M라는 수치는 Liquid AI d1-omni-600M을 이 블로그가 이전에 다뤘던 모델들의 축소판 친척으로 읽도록 유도한다. 그렇지 않다. 이 모델은 LFM2.5-Encoder-350M에서 훈련되었는데, 이는 양방향 인코더로, 381M의 공유 트렁크와 결정 헤드, LFM2.5-VL-450M 라인에서 가져온 94M의 비전 인코더, 그리고 17-layer FastConformer를 오디오용으로 갖추고 있다. Microsoft-Decision-1은 전혀 다른 계보이다: Qwen3.5-9B 디코더로, Microsoft가 후속 훈련했으며, Foundry에서 호스팅되고, 가중치는 배포되지 않으며 파인튜닝 경로도 제공되지 않는다.

양방향과 디코더의 대비는 각각이 어떻게 동작하는지를 결정하는 아키텍처적 사실이며, 파라미터 수가 주의를 흐리는 이유이기도 하다. 양방향 인코더는 전체 상태를 한 번에 읽는데, 이는 고정된 입력에 대한 판단에 적합한 형태다. 사후 학습된 디코더는 생성 경로를 포기하는 대신 파운드리 배포에 딸려 오는 토크나이저, 윈도우, 엔터프라이즈 패키징을 유지한다. 어느 쪽도 다른 쪽의 확장 버전이 아니며, 벤치마크 표를 어떻게 해석하든 둘은 서로 맞바꿀 수 없다.

입력 목록이 실제로 주는 것

이것이 d1-omni-600M이 해당 카테고리의 다른 모든 제품과 가장 크게 차별화되는 지점이며, 어떤 주장은 주의 깊게 읽어야 하는 부분이기도 하다.

• 음성 — Liquid AI d1-omni-600M은 텍스트와 최대 30초의 음성을 입력받고 이에 대한 결정을 보고합니다. 이는 어떤 텍스트 전용 평가자도 어떤 정확도로도 할 수 없는 일입니다. Microsoft-Decision-1의 비텍스트 모달리티는 존재하지 않습니다.

• 상호 배제 — d1-omni-600M은 이미지와 오디오가 동일한 요청에 함께 도착하면 ValueError를 발생시킵니다. 이 범주에서 가장 넓은 센서 표면조차 여전히 한 번에 하나의 비텍스트 모달리티에 그칠 뿐이며, 이는 해당 클레임 데스크에 실질적인 제약입니다.

• 트리밍 — 해당 카드에는 텍스트, 이미지, 오디오를 합쳐 16,384개의 포지션이 명시되어 있으며, 이미지가 있는 경우 상태 및 질문 텍스트가 훈련과 일치하도록 896 토큰으로 잘린다고 덧붙입니다. 사진을 첨부한 문서는 무엇이든 그 트리밍과 경쟁하게 됩니다. Microsoft-Decision-1의 32,768 토큰은 전부 텍스트이며 잘리지 않습니다.

• 형식 — d1-omni-600M에는 세 가지 질문 유형이 있습니다: noul 유형은 0과 1 사이의 P(yes)를 반환하는 이진 결정을 위한 것이고, choice 유형은 사용자가 지정한 집합에서 각 옵션에 대한 신뢰도와 확률과 함께 하나의 레이블을 반환하기 위한 것이며, score 유형은 분포와 함께 2~10개 수준의 순서형 척도에서 위치를 나타내기 위한 것입니다. 여러 질문이 하나의 상태에 연결되어 한 번의 패스로 읽히며, 사용량 카운터는 output_tokens: 0을 보고합니다. Microsoft는 예/아니요, 객관식, 평점, 분류 및 루브릭 형태를 문서화하며, 증거가 불충분할 때 "판단할 수 없음"과 같이 명시적으로 지원되는 기권 옵션도 포함합니다 — 이는 Microsoft 페이지에서 여기에 직접적인 대응물이 없는 유일한 설계 세부 사항입니다.

• 런타임 — d1-omni-600M은 사용자 지정 코드를 함께 제공하므로 trust_remote_code=True가 필요하며, 해당 카드에서는 GPU에서 float16을 권장하면서 일부 행에서는 bfloat16이 최상위 답변을 바꾸었다고 경고합니다. 이는 벤더가 문서화한 서빙 시점의 민감도이지 결함이 아닙니다. Microsoft-Decision-1은 배포 형태가 유일한 런타임 변수인 관리형 엔드포인트이며, 배치 추론이 비활성화되어 있다는 점은 주목할 만합니다. 대량 스코어링 실행을 분산 상각할 오프라인 채널이 없습니다.

양방향의 증거 격차

Liquid AI는 2026년 10월 7일 릴리스 게시물과 문서 세트와 함께 d1-omni-600M을 포함한 오픈 d1 패밀리를 발표했습니다. 공개되지 않은 것은 멀티모달 주장을 구체화할 수치입니다. 자체 대표 기능, 즉 94M 및 112M 인코더를 정당화하는 비전 및 오디오 의사 결정 품질에 특화된 정확도 벤치마크는 없으며, 비전 부분은 공개된 평가 자료에서 제외되었습니다. 지연 시간 수치도 공개되지 않았으므로, 모델의 처리량은 자신의 하드웨어에서 직접 알아내야 하는 것입니다.

Microsoft의 입장은 구조적으로 동일하며 한 단계 더 나아가 있습니다. Benchmarks 탭은 정확도, 보정 오류, 안전 재현율, 거짓 양성 비율, 공정성 일관성 같은 지표를 명시하고, 평가가 공개 및 커뮤니티 의사결정 벤치마크와 학습에 사용되지 않은 보류된 내부 테스트 세트에서 실행되었으며, 선택지 순서가 다양하게 바뀌었고, 짝지은 통계 검정이 적용되었다고 밝히며, 이 모델이 "동일한 방법론으로 평가된 다른 오픈 의사결정 모델보다 앞서고 선도적인 의사결정 모델과 대등한 성능을 발휘한다"고 주장합니다. 결과는 하나도 제시하지 않습니다. 25개 언어가 지원되는 것으로 나열되어 있으며, 일본어, 한국어, 아랍어, 베트남어, 태국어, 터키어, 힌디어, 벵골어, 스와힐리어, 히브리어, 페르시아어, 우크라이나어가 포함됩니다. 다만 적용 범위, 품질 및 보정이 "언어별로 다를 수 있다"는 솔직한 경고와 함께, 비영어, 특히 저자원 언어가 약점이라는 점도 밝힙니다. 가격도 모델 페이지에 없으며, Microsoft의 가격 책정 페이지로 연결됩니다.

그러니까 이 둘 사이의 비교는 증거 대 증거의 비교가 아니다. 그것은 두 가지 종류의 빠진 숫자 사이의 선택이다. Liquid AI는 센서 표면을 내놓았지만 그 표면의 정확도는 공개적으로 측정되지 않은 채로 남겨두었다. Microsoft는 조달 경로—Azure 인증, 거버넌스, Responsible AI 평가, 문서화된 방법론—를 내놓았지만 확률 제품의 보정은 정량화되지 않은 채로 남겨두었다.

둘 중 누구도 대답하지 않는 교정 질문

의사결정 모델에서 확률은 곧 산출물이다. 그 이후의 모든 것은 임계값이다. 0.7은 에스컬레이션하고, 0.95는 자동 승인하며, 그 선을 잘못 그은 대가는 토큰이 아니라 잘못된 자동 결정으로 치러진다. 이 범주에는 그 수치를 공개하는 계열이 적어도 하나 있다 — InternLM의 Intern-Decision 체크포인트는 모델 카드에 Brier 및 expected-calibration-error 수치를 기재한다 — 그리고 이 글에 등장하는 어느 모델도 그렇게 하지 않는다. 그 비대칭성은 아키텍처만으로 확정하기보다 선택지를 넓게 유지해야 하는 실질적 이유다.

좋은 소식은 이 테스트가 저렴하고 공급업체의 협조가 필요 없다는 점입니다. 실제 트래픽처럼 보이는 레이블이 지정된 사례 수백 개를 모으고, 애플리케이션이 실제로 보낼 질문 스키마를 작성한 뒤, 두 모델 모두에 대해 실행하고 출력에서 기대 보정 오차를 계산하십시오. 그러면 현재 두 공급업체 밖에서는 아무도 모르는 두 가지를 알게 될 것입니다. Microsoft-Decision-1의 확률이 귀하의 분포에서 정확도를 얼마나 잘 따라가는지, 그리고 d1-omni-600M의 오디오 및 이미지 경로가 그들이 탑재한 인코더만큼 가치가 있는지입니다. Microsoft의 자체 문서화된 지침도 같은 방향을 가리킵니다. 대표성 있는 데이터로 검증하고, 오류 비용에 따라 임계값을 설정하고, 항상 기권 옵션을 포함하고, 선택지 순서를 무작위화하고, 중대한 결정에는 인간을 루프에 유지하십시오.

각각이 어디에 속하는지, 그리고 OrcaRouter가 어디에 속하는지

Microsoft-Decision-1은 결정적 자료가 텍스트이고 걸림돌이 조달인 모든 곳에 어울립니다. 긴 문서, 검색된 구절, 제안된 도구 호출, 루브릭에 따라 채점되는 생성된 답변처럼, 무엇이든 프로덕션에 도달하기 전에 Azure 인증, 통합 청구, 공급업체 평가가 필요한 경우입니다. 이것은 하나의 수단이며, 승인받기가 더 쉬운 쪽입니다.

Liquid AI d1-omni-600M은 결정적인 자료가 텍스트가 아닌 곳—양식에 첨부된 사진, 짧은 통화 녹음, 스크린샷—에, 그리고 통제 가능한 경계 안에서 실행하고 미세 조정할 수 있는 lfm1.0 가중치를 원하는 곳에 어울린다. 이것은 더 폭넓은 도구이며 검증하기는 더 어려운 도구다. 멀티모달이라는 주장이 바로 공개된 벤치마크가 뒷받침되지 않는 부분이기 때문이다.

어느 쪽도 우리 카탈로그에 없으며, 여기서 어느 쪽에 대해서도 가용성을 주장하지 않습니다. 텍스트 대신 확률을 반환하는 모델은 채팅 완성을 라우팅할 대상이 아니며, 채점석에 앉지 않는 것이 바로 이 도구의 설계 전체입니다. OrcaRouter가 제공하는 것은 동일한 루프의 생성 측면입니다:하나의 OpenAI 호환 키 뒤에 있는 200개 이상의 모델 — 이들이 채점기가 기준으로 삼아 채점할 루브릭을 작성하고, 자료가 상태가 되기 전에 이를 전사하거나 요약하며, 채점기가 실행 전에 승인하는 도구 호출을 내보냅니다. 제공업체 정가는 0% 마크업으로 그대로 전달되므로, 생성 측의 벤더 가격 인하는 같은 날 우리 쪽에도 적용됩니다. 자동 장애 조치는 단일 제공업체가 성능 저하될 때 그 측을 살려둡니다 — 검색된 모든 문서를 채점하는 파이프라인이라면 이를 즉시 알아차리죠 — 그리고 하나가 아니라 여러 작성자를 평가하고 싶다면, 라우팅 DSL이 이들을 단일 호출로 구성하고 모델 퓨전이 이들의 일치도를 채점기가 다른 필드처럼 읽을 수 있는 필드로 보고합니다.

결론

Microsoft-Decision-1은 2026년 10월 8일 Microsoft Foundry에서 정식 출시되었습니다: 텍스트 전용, 32,768토큰, 포스트 트레이닝된 Qwen3.5-9B 기반, 가중치 없이 호스팅되며, 모델 페이지에 가격도, 지연 시간 수치도 없고, 벤치마크 섹션은 결과를 출력하지 않은 채 방법론만 설명합니다. Liquid AI d1-omni-600M은 2026년 10월 7일 587M 양방향 인코더 의사결정 모델로 업로드되었으며, 텍스트, 이미지 또는 30초 음성을 읽습니다 — 한 번에 하나의 비텍스트 모달리티만, 이미지가 있을 때 텍스트는 896토큰으로 잘림 — lfm1.0 라이선스 하에, 대표 기능에 대한 정확도 벤치마크도, 비전 분할도, 공개된 지연 시간도 없습니다. 점수가 아니라 모달리티와 제어를 기준으로 선택하세요. 점수는 존재하지 않기 때문입니다: 자료가 사진이나 전화 통화라면 이 중 하나만 답할 수 있고, 조달 검토가 첨부된 40페이지 문서라면 다른 하나만 배포할 수 있습니다.

OrcaRouter가 담당하는 것은 동일한 루프의 생성적 측면입니다: 200개 이상의 모델이 하나의 OpenAI 호환 키 뒤에서, 당신의 스코어러가 채점 기준으로 삼는 루브릭을 작성하고, 자료가 상태가 되기 전에 이를 전사하거나 요약하며, 실행되기 전에 당신의 스코어러가 승인하는 도구 호출을 내보냅니다.