Liquid AI d1-omni-600M, 이제 Ollama Pull로 제공: 당신의 말을 들을 수 있는 600M 의사결정 모델

Liquid AI d1-omni-600M2026년 10월 17일 22:32 UTC에 Ollama 패키지가 되었다. 그 타임스탬프는 추측이 아니다. Ollama의 레지스트리는 모든 매니페스트에 ollama-push-time 헤더를 제공하며, d1-omni라는 이름 뒤의 네 개 태그는 그날 저녁 22:31:25와 22:32:13 사이에 승인되었는데, 이는 이 글을 쓰기 약 네 시간 전이다. 모델 자체는 새로운 것이 아니다 — Liquid AI오픈 웨이트로 Liquid AI d1-omni-600M와 함께 Liquid AI d1-3B2026년 10월 5일에 공개했고, 10월 7일 "Open d1" 게시물에서 둘 다 발표했다 — 하지만 어젯밤까지 오디오 지원 모델을 자체 하드웨어에서 실행하는 유일한 방법은 trust_remote_code=True를 사용하는 transformers 환경이나 직접 컴파일한 llama.cpp 빌드뿐이었다. 이제는 ollama pull d1-omni다. 아무도 그 사실을 발표하지 않았다. Liquid AI의 블로그도, Ollama도.

패키징이 이야기 그 자체이며, 그중 어느 부분이 문서화되어 있는지 정확히 짚을 가치가 있다. Liquid AI의 가장 최근 블로그 글은 10월 15일의 d1-ultra와 10월 13일의 LFM2.5-24B-A2B이며, 둘 다 Ollama를 언급하지 않는다. 해당 연구소 자체의 Ollama 배포 페이지는 여전히 Hugging Face에서 바로 GGUF 저장소를 ollama run hf.co/LiquidAI/... 로 실행하는 방법을 가르치고 있으며, d1 모델은 전혀 이름을 올리지 않는다. Ollama의 블로그도 마찬가지로 조용하다. 최신 항목은 10월 16일의 Reflection's Beam과 10월 13일의 Fly.io 통합이다. 그 대신 존재하는 것은 레지스트리 항목, 네 개의 태그, 검증 가능한 다이제스트, 그리고 이 기사를 쓰는 동안에도 여전히 작성 중이던 라이브러리 페이지다. 그 페이지의 초기 캡처에서는 "No readme"가 반환되었고, 40분 후 캡처에서는 벤치마크 표와 라이선스 섹션이 포함된 Liquid AI가 작성한 전체 설명이 반환되었다. 지난 7일 동안 날짜가 있고 확인 가능한 사건을 원한다면, 그 헤더가 바로 그것이다.

레지스트리가 실제로 수용한 것

네 개의 태그가 두 개의 이미지로 귀결되는데, 이는 pull하기 전에 가장 먼저 이해해야 할 점입니다. d1-omni:latest, d1-omni:600m, d1-omni:600m-q8_0는 동일한 매니페스트로 다이제스트는 1ba59f63e836이며, d1-omni:600m-bf16은 두 번째 매니페스트로 다이제스트는 c1e95fce6627입니다. 다만 F16 태그는 없습니다. 벤더 자체의 GGUF 저장소가 F16 트렁크를 공개하고 있음에도 그렇습니다.

• 가중치 계층(Q8_0 빌드) — d1-omni-600M-Q8_0.gguf에서 가져온 407MB 트렁크와 mmproj-d1-omni-600M-BF16.gguf에서 가져온 442MB 프로젝터, 그리고 10.5KB 라이선스 블롭과 18바이트 매개변수 블롭으로 구성되며, 총 849,659,968바이트입니다.

• 보고된 크기 — 기본 태그의 경우 850 MB, 600m-bf16의 경우 1.2 GB이며, 둘 다 라이브러리 페이지에 표시된 값입니다.

• 런타임 최소 버전 — 요구 사항: config blob의 0.40.4이며, 또한 model_family: lfm2, model_type: 380.73M 및 file type Q8_0을 보고합니다.

• 컨텍스트 — 매개변수 블롭이 num_ctx를 16,384로 고정합니다.

• 라이선스 — 내장된 텍스트는 LFM Open License v1.0이며, Liquid AI, Inc.를 라이선스 제공자로 명시하고, 모델 카드의 lfm1.0 식별자와 일치합니다.

그 프로젝터는 다시 볼 가치가 있습니다. 왜냐하면 그것은 자신이 붙어 있는 모델보다 더 크기 때문입니다. 레지스트리 blob에서 GGUF 메타데이터를 직접 읽어 보면 같은 파일에 clip.has_vision_encoder = True와 clip.has_audio_encoder = True가 표시됩니다. 즉 768차원 임베딩과 256픽셀 입력에서 12개 블록에 걸친 197개의 비전 텐서, 그리고 128개 mel bin을 사용하는 512차원 임베딩에서 17개 블록에 걸친 641개의 오디오 텐서가 있습니다. 이는 SigLIP2 타워와 FastConformer 인코더가 둘 다 멀티모달 번들 안에서 함께 이동한다는 뜻이며, 그래서 381M 매개변수 트렁크가 442 MB 첨부 파일 뒤에 함께 제공되는 것입니다. 오디오 기능은 다운로드하는 패키지 안에 물리적으로 들어 있습니다. 엔드포인트가 그것에 도달할 수 있는지에 대한 질문은 나중에 다룹니다.

이 모델은 587M개의 파라미터를 가지며, 125K 배지는 실제 값보다 큽니다.

Ollama의 페이지는 모든 태그에서 "125K 컨텍스트 창"을 홍보합니다. 패키지 자체의 num_ctx는 16,384이며, Liquid AI의 모델 카드도 같은 내용을 말로 설명합니다. 즉 텍스트, 이미지, 오디오 위치를 합쳐 16,384토큰이고, 이미지가 있을 때마다 상태와 질문 텍스트는 896토큰으로 잘립니다. 125K라는 수치는 추적 가능합니다. 트렁크 GGUF에는 lfm2.context_length = 128000이 들어 있습니다. 하지만 이는 아키텍처의 상한선일 뿐 실제로 얻는 창이 아니며, 장문 맥락 분류기를 대체할 모델을 고르는 사람을 가장 잘못 인도할 가능성이 높은 숫자입니다. 16,384를 실질 기준 수치로 보고, 이미지가 상태에 포함되어 있을 때는 텍스트 896토큰을 실질 기준 수치로 보십시오.

나머지 메타데이터는 마케팅 문구보다는 모델 카드와 부합한다. 트렁크는 18개 블록, 1,024차원 임베딩, 65,536 어휘로 구성되며 디코더가 아니다: lfm2.attention.causal은 False다. 레이어별 KV 헤드 수는 0, 0, 8, 0, 0, 8, …로 나타나며, 이는 해당 블록 대부분이 전혀 어텐션 블록이 아님을 의미한다. 이는 양방향 인코더 계보가 드러난 것이다. 결정 헤드는 두 블록이며(lfm2.decision.block_count = 2), 벤더가 config.json에 보관하는 보정 상수도 이 GGUF에 들어 있다 — 선택형 질문은 옵션이 두 개일 때 온도 1.7465, 3~5개일 때 1.3999, 6~10개일 때 1.1751, 11개 이상일 때 1.3725를 사용한다. 예/아니오는 1.6663이고, 점수형 질문은 3~5단계일 때 1.7301, 6~10단계일 때 1.0이다. 이는 전체 설계를 한곳에 보여 준다: 이름이 붙은 고정된 답변 세트를 한 번의 패스로 점수화하고, 질문 형태별로 보정하며, 끝에 output_tokens: 0을 둔다.

이것은 채팅 모델이 아니며 텍스트를 작성하지 않습니다. Liquid AI는 15개 언어를 나열하고, 오디오 학습 데이터는 영어로만 넣으며—화자와 어시스턴트 간의 요청—클립 길이는 30초로 제한합니다. 이 카드는 또한 GPU에서 bfloat16 사용에 대해 경고합니다. 공급업체 자체 점검에서 bfloat16은 텍스트 행의 0.8%와 오디오 행의 1.7%에서 최상위 답변을 바꾼 반면, float16은 모든 곳에서 float32와 일치했습니다.

오디오는 가중치 안에 있으며 문서화된 API에는 없습니다.

버그를 제출하기 전에 알아둘 만한 불일치입니다. Liquid AI가 작성한 라이브러리 페이지의 README는 오디오를 /v1/systemone 요청의 images 배열 안에 base64 WAV를 넣는 방식으로 문서화합니다. 동일한 체크포인트에 대한 벤더의 Hugging Face GGUF README는 이를 다르게 문서화하는데, files 배열에 data:audio/wav;base64,…를 담아 llama.cpp 서버로 전달하는 방식입니다. 그리고 Ollama가 공개한 엔드포인트 레퍼런스는 둘 다 문서화하지 않습니다. 요청 스키마에는 state, images, questions, keep_alive가 있고, images를 “Clef와 같은 비전 모델이 필요합니다”라고 설명하며, audio 필드와 files 필드는 전혀 포함하지 않습니다. 한편 Ollama 자체의 의사결정 모델 가이드는 Nimble, Tev1, Clef, Clef Flash를 의사결정 모델로 명명하고 Clef 모델이 이미지도 판단할 수 있다고만 말합니다.

그래서 현재 Ollama의 오디오에 대한 정직한 입장은 이렇다: 인코더가 blob 안에 존재한다는 것은 검증되었고, 벤더의 readme에는 이미지를 통해 작동한다고 나와 있지만, 공개된 스키마는 이를 허용하지 않는다. 같은 모델의 이미지 입력은 더 확실한 근거를 갖는다. 비전은 문서화된 System One 기능이며 d1-omni는 Ollama의 비전 카테고리 목록에 나타난다. 그와 나란히 두 가지 더 작은 문서 공백이 있다. 엔드포인트 참조는 선택형 질문에서 최대 255개의 옵션 키를 허용하는 반면, 결정 가이드는 2~26개라고 말한다. 그리고 패키지의 런타임 최소 버전 0.40.4는 엔드포인트 문서가 명시하는 0.35.0보다 높다.

비전 아래에 분류되었으며, 결정 아래는 아닙니다.

Ollama의 모델 검색은 의사 결정 모델을 자체 카테고리로 필터링합니다. 여기에는 nimble-v3, pplx-decider, kev, tev1, nimble, clef-flash, clef, laya, strands-decider의 9개 항목이 포함되어 있으며, d1과 d1-omni는 둘 다 그 안에 없습니다. d1-omni 페이지에는 vision 및 600m 태그가 붙어 있고 vision 목록에는 실제로 나타나므로, 'decision model'을 찾아보는 독자는 가장 최신 모델을 찾지 못할 것입니다. 이는 능력 문제라기보다는 발견 가능성 문제이지만, Ollama 자체 카탈로그에서 의사 결정 계열들을 비교하려 했는데 이 모델이 존재하지 않는다고 결론 내렸다면 중요한 문제입니다.

즉, 이것은 d1-omni가 Ollama 라이브러리에서 음성을 아예 입력받을 수 있는 최초의 의사결정 모델이라는 뜻입니다 — 오디오 인코더가 패키지에 포함되어 있으며, 그 9개 모델 목록에서 다른 어떤 모델도 오디오 인코더를 갖고 있지 않습니다. 엔드포인트가 당신의 WAV를 d1-omni에 넘겨줄지는 위 섹션에서 나온 미해결 질문이며, 이 글을 읽을 때쯤이면 가장 바뀌었을 가능성이 큰 단 하나의 사항입니다.

숫자들, 그리고 그 하나하나를 만들어낸 사람

에 표기된 모든 정확도 수치는Liquid AI d1-omni-600M Liquid AI 자체의 것이며, 우리가 확인할 수 있는 한 현존하는 어떤 d1 모델에 대해서도 독립적인 평가는 존재하지 않습니다 — 리더보드 행도, 제3자 실행 결과도, 벤더의 점수 산정에 대한 공개된 반박도 없습니다. 벤더는 두 d1 체크포인트를 공개 리더보드에 제출하는 대신 공식 Decision Index 채점기로 직접 채점했으며, 모델 카드에 그렇게 밝히고 있습니다. 표에 있는 경쟁 항목은 모두 리더보드 v0.2.1에서 가져온 것으로, 이는 이 비교가 외부에서 채점된 수치들 옆에 자기 채점 수치를 나란히 놓은 것임을 의미합니다.

• Decision Index 0.2.1 — d1-omni-600M의 15.95(지식 8.3, 언어 12.9, 검색 35.0, 도구 15.1, 예술 6.8) 대비 d1-3B의 48.57.

• 의사결정 기준으로서의 벤치마크, 7회 평균 — d1-omni-600M은 78.4, d1-3B는 82.9이며, 600M 모델은 Civil Comments(95.8 대 93.0)와 PAWS-X(79.5 대 76.9)에서 앞서고 BoolQ(77.7 대 86.7)와 SQuAD 2.0(74.0 대 85.3)에서는 뒤진다.

• Fast Decisions, dev split — 76.9, 공급업체 보고, 비교 행 미게시.

• 속도 — 없음. 모델 카드에는 이것이 활발히 개발 중인 초기 연구 릴리스이므로 추론 수치가 보고되지 않는다고 분명히 명시되어 있습니다. 따라서 다른 곳에서 이에 관해 보이는 지연 시간 주장은 모두 누군가의 자체 측정치입니다.

• Ollama 페이지의 픽스처 수치 — README의 예제에서는 urgent가 0.998, technical이 0.995로 응답된 것으로 보여 줍니다. 이는 런타임이 게시한 한 요청의 예시 출력이며, 벤치마크가 아닙니다.

15.95와 48.57 사이의 격차는 카드에서 가장 유용한 정보입니다. 왜냐하면 그것은 구매 관련 질문을 공급업체 자신의 표현으로 해결해 주기 때문입니다. readme는 텍스트와 이미지 전반의 정확도가 중요할 때는 d1을 사용하고, 크기가 중요하거나 오디오가 필요할 때는 d1-omni를 선택하라고 알려줍니다. 7개의 공개 벤치마크에서 78.4점을 기록한 587M 모델을 의사결정으로 재구성해 보면 그럴듯한 엣지 분류기입니다. 그것은 3B의 더 작은 버전이 아닙니다.

OrcaRouter가 적합한 경우와 그렇지 않은 경우

우리는 이 모델을 제공하지 않습니다. 10월 18일 우리 카탈로그를 확인한 결과 208개의 모델 ID가 반환되었고 그중 Liquid AI의 것은 하나도 없었으므로, 여기에는 가용성 주장이 없으며 우리 쪽에서 이를 가져올 경로도 없습니다. 원하신다면 Liquid AI d1-omni-600M의 경우 로컬 경로는 위에서 설명한 것이고, 호스팅 경로는 벤더 자체 API와 이를 받아들이는 제3자 플랫폼입니다.

패키징이 바꾸는 것은 그 주변 시스템의 형태이며, 바로 그 지점에서 우리가 유용합니다. 의사결정 모델이 전체 파이프라인인 경우는 거의 없습니다. 모델이 라벨을 붙이는 티켓, 플래그를 지정하는 프레임, 라우팅하는 트랜스크립트는 여전히 텍스트를 작성하는 무언가에 의해 응답되거나 요약되거나 에스컬레이션되어야 합니다. 이러한 생성형 호출은 다음 뒤에 있습니다: 제공자의 정가로 200개 이상의 호스팅 모델을 이용할 수 있는 OpenAI 호환 키 하나이며, 0% 마크업으로 그대로 전달됩니다. 따라서 공급업체의 가격 변경은 새 계약이 아니라 같은 날 여러분에게 도달합니다.공급자 간 자동 장애 조치 — 자신 있는 호출은 처리하게 하고, 그렇지 않을 때는 빠져나갈 경로를 남겨 두어, 587M 파라미터가 트리아지 단계의 단일 장애점이 되지 않게 하십시오. 결정은 로컬에 남습니다. 폴백은 그럴 필요가 없습니다.

무엇이 이 읽기를 바꿀까요?

네 가지 사항이며, 그중 어느 하나만으로도 패키징 노트가 다른 기사로 바뀔 수 있다. Ollama가 System One 요청 스키마에서 오디오를 문서화하는 것 — 이는 README의 이미지 속 WAV 트릭을 지원되는 입력으로 전환하고, 이것을 한 명령으로 실행할 수 있는 최초의 음성 지원 의사결정 모델로 만들 것이다. 두 회사 중 한 곳이 이 포팅을 인정하는 것 — Liquid AI가 배포 문서의 Ollama 페이지에 d1-omni를 추가하거나, Ollama가 이를 비전이 아닌 의사결정 모델 아래에 나열하는 것. 벤더든 아니든 누구로부터든 속도 수치가 나오는 것 — 오늘날에는 그러한 수치가 존재하지 않기 때문이다. 그리고 어느 d1 모델이든 그에 대한 독립적인 Decision Index 행이 나오는 것 — 이는 전체 제품군에서 여전히 유일하게 빠져 있는 조각이다.

그때까지는 결정이 간단합니다. 이미 Ollama 0.40.4 이상을 실행하고 있다면 pull은 명령 하나이고, 다운로드는 850MB이며, 얻게 되는 것은 텍스트와 이미지에 대한 단일 순방향 패스로 입력한 질문에 답하는 587M 분류기입니다. 그리고 리드미가 맞다면 영어 음성 30초 이상도 처리합니다. 상태가 길다면 125K 배지보다는 16,384토큰 창과 896토큰 텍스트 예산을 염두에 두세요. 그리고 고객이 보는 어떤 것에든 라벨을 붙이기 전에 그것이 정확하다는 증거가 필요하다면, 그 증거는 아직 존재하지 않습니다. 이 모델이나 그 형제 모델 중 어느 것에도요.

이번과 같은 릴리스의 배경이 되는, 문서화된 AI 실패 및 에이전트 사건들은 OrcaRouter AI Incident Archive에 수집되어 있으며, 각 항목에는 자체 출처, 심각도, 신뢰도 등급 및 이의 제기 플래그가 포함되어 있습니다.