Liquid AI d1 vs Liquid AI d1-3B: Ollama Library가 하나의 모델로 부르고 벤더가 두 개로 부르는 것

같은 가중치 집합에 이름을 붙이는 방식이 두 가지가 있는데, Liquid AI d1과 Liquid AI d1-3B는 어떤 파라미터 비교보다도 그 차이를 잘 보여준다. 두 번째 이름에서 하이픈 하나와 크기 접미사를 빼면 첫 번째가 되니, 짧은 문자열을 애칭으로 취급하고 싶어진다. 실제로 이 모델들을 등재한 두 카탈로그는 그런 해석에 동의하지 않는다. Liquid AI 자체 문서 색인은 d1을 별도 행에 두고 다운로드 링크가 들어갈 자리에 "API"라는 글자를 넣으며, d1-3B와 d1-omni-600M은 작동하는 Hugging Face 및 GGUF 링크와 훈련 가능 열의 "No"와 함께 별도의 두 행에 둔다. 애초에 이 짝을 두고 글을 쓸 가치가 생긴 이유인 라이브러리 항목을 가진 Ollama는 이 모든 것을 d1이라는 하나의 페이지로 합쳐 놓고, "LFM2.5-VL-3B를 기반으로 한 Liquid AI의 3B 결정 모델"이라고 한 줄로 설명하며, 그 아래에 정확히 세 개의 태그를 제공한다. 따라서 Liquid AI d1과 Liquid AI d1-3B를 비교하는 것은 호스팅 엔드포인트와 오픈 체크포인트를 비교하는 것도 아니고, 두 체크포인트를 비교하는 것도 아니다. 그것은 호스팅 엔드포인트와, 로컬 런타임 생태계가 아무 수식어 없이 그 단어를 말할 때 d1이라고 결정한 오픈 체크포인트를 비교하는 것이다. 이어지는 내용의 대부분은 이 해석들 중 여러분의 배포가 실제로 어느 쪽에 의존하는지에 관한 것이다.

아래 수치의 출처에 대한 주석입니다. 여기서는 형식보다 정직성이 더 중요하기 때문입니다. 여기에 있는 모든 숫자는 Liquid AI의 자체 보고로, 모델 카드나 10월 7일 릴리스 포스트에 나온 것입니다. Decision Index 행은 공개 순위에 제출된 것이 아니라 공식 채점기로 공급업체가 채점한 것이며, 우리가 찾을 수 있는 한 어떤 제3자도 d1 결과를 독립적으로 재현한 적이 없습니다. 숫자가 측정값이 아니라 게시된 수치로부터 계산된 경우, 그렇게 명시되어 있습니다.

두 이름의 유래

더 짧은 이름이 더 오래되었습니다. Liquid AI의 10월 5일 게시물은 이 모델을 Liquid AI d1 — "우리의 첫 의사결정 모델"로 소개했습니다. 해당 릴리스에서는 멀티모달이었고, 텍스트, 이미지 또는 둘 다의 상태에 대해 입력된 질문에 출력 토큰 없이 단 한 번의 순방향 패스로 답합니다. 그 게시물은 백만 입력 토큰당 0.04달러의 호스팅 가격을 제시하고, 입력 토큰에만 요금을 청구하며, 이미지는 32×32 패치당 1.5토큰으로 텍스트와 동일하게 청구되므로 1024×1024 이미지는 1,536토큰이 든다고 언급합니다. 또한 텍스트 의사결정 지연 시간을 200–300ms로 제시합니다. 이는 호스팅 서비스 수치이며, 게시물은 그 뒤의 런타임이 api.liquid.ai/decisions/v1/systemone에 있는 공급업체 자체의 의사결정 엔드포인트라고 분명히 밝힙니다.

더 긴 이름은 10월 7일 게시물과 Hugging Face에 나타나며, 재현 가능한 세부 정보를 담고 있는 쪽입니다: 3.12B 매개변수, 32,768토큰 컨텍스트, 128,000토큰 어휘, 문서화된 16개 언어, SigLIP2 NaFlex 형태 최적화된 400M 비전 인코더, 그리고 기본 체인 LFM2.5-2.6B-Base → LFM2.5-VL-3B → d1-3B. 해당 카드에는 또한 이 모델이 채팅 모델이 아니며 텍스트를 작성하지 않는다고 분명히 명시되어 있습니다. 이것은 전체 로컬 생태계가 기반으로 구축된 체크포인트입니다: GGUF 저장소에는 Q4_K_M(1.67 GB), Q8_0(2.87 GB), F16 및 BF16(각 5.4 GB)이 있습니다.

어떤 벤더 문서도 공개적으로 말하지 않는 점은 Liquid AI d1과 Liquid AI d1-3B가 동일한 가중치라는 것입니다. 문서 인덱스는 이 둘을 별도의 행으로 할당합니다. 릴리스 게시물은 d1을 하나의 패밀리라고 부르며, 체크포인트라고는 하지 않습니다. 제3자 글들은 이 간극을 알아차렸고, 벤더가 동일성 확인을 하지 않았다고 지적했습니다. 따라서 정직한 진술은 짧습니다: 두 이름과 함께 공개된 수치들은 우리가 찾을 수 있는 어디에서도 충돌하지 않으며, 패밀리 릴리스와 서비스 중인 엔드포인트는 호환되는 설명과 함께 이틀 간격으로 발표되었고, 벤더는 그것들이 같은 모델이라고 말하지 않았습니다. 동등성을 합리적인 작업 가정으로 취급하고, 벤더가 이름을 걸고 보증한 사실로 취급하지는 마십시오.

로컬 빌드가 실제로 변경하는 것

Ollama의 등록 항목은 재출시도 아니고 새로운 체크포인트도 아니다. 그것은 패키징 결정이며, 그 패키징은 벤더 자체 문서가 전혀 언급하지 않는 세 가지 제약을 부과한다. 첫 번째는 태그 목록이다: d1:latest, d1:3b, d1:3b-q8_0 — 하나의 양자화를 가리키는 세 개의 태그다. Liquid가 공개하는 GGUF 저장소에는 네 가지 정밀도가 들어 있으며, 노트북에서 대부분의 사용자가 가장 먼저 선택할 만한 1.67 GB Q4_K_M은 Ollama 태그 중에 없다. pull할 수 있는 것은 2.87 GB Q8_0과 그것이 로컬 저장소에서 확장되는 크기뿐이다. 라이브러리 페이지는 다운로드 용량을 3.7 GB로 보고한다.

두 번째는 요청 계약입니다. Ollama는 /v1/systemone에서 이 모델들에 응답하며, state와 questions 객체를 받아 output_tokens: 0이 포함된 타입 지정된 답변을 반환합니다. 이는 벤더의 호스팅 엔드포인트에서 사용하는 것과 동일한 형태이며, 이것이 로컬과 호스팅 간 전환을 재작성이 아니라 구성 변경으로 만들어 줍니다. 세 번째 제약은 모델 페이지가 아니라 Ollama의 엔드포인트 문서에 있으며, 생성 모델의 제약보다 더 엄격합니다: 요청은 이미지가 없으면 64 KiB 이내, 이미지가 있으면 32 MiB 이내여야 하며, 스트리밍은 지원되지 않고, 클라우드 호스팅 모델은 거부되며, 이미지는 요청 본문에 base64 PNG, JPEG 또는 WebP여야 합니다 — 원격 URL은 거부됩니다. 이미지는 한 요청의 모든 질문에서 공유되므로, 단 하나의 답변에서만 고려되길 원하는 그림은 별도의 호출이 필요합니다. 입력은 절대 잘리지 않으므로, 너무 큰 state는 조용히 잘리는 대신 오류를 반환합니다. 이는 더 나은 실패 모드이지만, 여전히 클라이언트가 처리해야 하는 실패 모드입니다.

버그를 제출하기 전에 알아 두면 좋은, 아직 해결되지 않은 문서상 세부 사항이 두 가지 있습니다. Ollama의 엔드포인트 참조에서는 선택 질문 유형이 2~255개의 옵션 키를 허용한다고 설명하지만, decision-models 기능 페이지에서는 2~26이라고 합니다. 둘 중 하나는 오래된 내용입니다. 그리고 해당 기능 페이지에는 지원 모델로 Nimble, Tev1, Clef, Clef Flash가 나열되어 있을 뿐 d1은 언급되어 있지 않습니다. 그런데 d1 패키지 자체의 README에는 /v1/systemone 및 --ask 지원이 문서화되어 있으며, 이 패키지는 Ollama 0.40.4를 요구하지만 엔드포인트 자체에 문서화된 최소 버전은 0.35.0입니다. 가이드에 있는 버전 요구 사항이 아니라 패키지에 있는 버전 요구 사항을 읽으세요.

숫자들, 그리고 그것들이 어떤 이름으로 출판되었는지

이것은 페어링에서 가장 틀리기 쉬운 부분입니다. 두 이름 모두 성과 수치와 함께 공개되는데, 그 수치가 예상하는 방식으로 정리되어 있지 않기 때문입니다.

• Decision Index 0.2.1 — 48.57, 출처: Liquid AI d1-3B. Liquid는 이를 10B 매개변수 미만의 의사결정 모델을 위한 최고 점수라고 설명하며, 47.11을 기록한 35B-A3B 모델보다 앞세웁니다. • 텍스트 의사결정 지연 시간 — 200–300ms, 출처: Liquid AI d1 (호스팅 API 게시물). 오픈 체크포인트 자체 명칭에 연결된 동등한 수치는 없습니다. • 로컬 하드웨어에서 단일 질문 지연 시간 — RTX 4090에서 8ms, Jetson AGX Thor에서 16ms, Jetson AGX Orin 64GB에서 26ms, Orin Nano에서 50ms, Apple M5 Pro에서 30ms. 출처: Liquid AI d1-3B. • 처리량 — RTX 4090에서 초당 475건, 질문을 배치로 묶었을 때 AMD MI325X에서 초당 1,106건. 출처: Liquid AI d1-3B. • 비전 — 11개 공개 이미지 벤치마크에서 평균 74.1, 기반이 된 LFM2.5-VL-3B의 73.9와 비교됩니다. 출처: Liquid AI d1-3B. • 이미지 제거 실험 — 이미지를 제거한 상태로 동일한 질문 세트에 답했을 때 45.1점을 기록하며, 이는 비전 경로가 기여하는 바에 대한 벤더 자체 측정치입니다. 출처: Liquid AI d1-3B.

그 목록에서 두 가지 문제가 도출되는데, 둘 중 어느 것도 치명적이지는 않습니다. 바로 그렇기 때문에 이 문제들은 간과됩니다. 호스티드 수치와 로컬 수치는 25~37배 차이입니다 — 200–300ms 대 8ms — 그리고 이들은 벤더가 비교 가능한 기준으로 설명하지 않는 대상에서 측정되었습니다. 이 격차를 "로컬이 더 빠르다"라고 해석하는 것은 뒷받침되지 않습니다. 호스티드 수치는 API를 거치는 종단 간 수치이고, 8ms는 이름이 명시된 GPU에서의 순전파이기 때문입니다. 이 둘은 같은 측정이 아니며, 벤더는 결코 그렇다고 주장하지 않습니다.

두 번째 문제는 비전 항목입니다. 열한 개 이미지 벤치마크 전반에 걸친 베이스 모델 대비 0.2포인트 향상은 대부분의 벤치마크 보고에서 노이즈 범위에 들어가므로, 결정 헤드가 무엇을 얻어 주든 그것이 실질적으로 더 나은 이미지 인코더인 것은 아닙니다. 절제 실험 항목은 반대 방향으로 훨씬 더 인상적으로 보입니다. 이미지가 추가될 때 대략 29포인트의 변화가 나타나지만, 이는 하나의 질문 세트의 두 버전이 아니라 서로 다른 두 질문 세트를 비교한 것이며, Liquid도 게시물에서 이를 밝히고 있습니다. 두 항목 모두 유용합니다. 그러나 어느 것도 시각적 결정 품질에 대한 강한 주장을 뒷받침하지 못하며, 제3자가 어느 쪽도 실행한 적이 없습니다.

두 이름이 실제로 갈라지는 지점

구매자 입장에서 그 구분은 네 가지 질문으로 귀결되는데, 그 답이 모두 같은 방향을 가리키지는 않는다.

• 비용 구조 — Liquid AI d1은 입력 토큰당 벤더의 공개 요율로 청구되며, 지불할 출력 토큰은 없습니다. Liquid AI d1-3B는 Ollama 패키징에서 2.87GB 다운로드이거나 벤더의 GGUF 저장소에서 1.67GB 다운로드이며, 호출당 미터가 전혀 없습니다. • 지연 시간, 측정 가능 — 호스팅 경로는 텍스트 결정당 200–300ms를 제시합니다. 로컬 경로의 공개된 8ms는 워밍된 모델을 사용하는 RTX 4090에서의 포워드 패스이며, 이는 실제 수치이고 요청 왕복 시간이 아닙니다. • 데이터 경로 — 호스팅 경로는 상태를 벤더로 전송합니다. 로컬 경로는 이를 머신에 보관하는데, 지원 티켓, 의료 메모 또는 사진의 경우 이는 보통 논의를 끝내는 논거입니다. • 버전 고정 — Liquid AI d1은 엔드포인트 뒤에 있으면 벤더가 오늘 서빙하는 무엇이든 됩니다. Liquid AI d1-3B는 Ollama에서 사용자가 통제하는 고정 패키지이며, 그 대가는 업그레이드를 직접 관리하는 것입니다.

네 가지 모두의 밑바탕에 깔린 불편한 현실은, 오픈 체크포인트가 호스팅 모델의 대체물이 아니라 그 형제 격이라는 점이며, 벤더는 그와 다른 말을 한 적이 없다. 오픈 체크포인트의 모델 카드는 이를 라우팅 및 트리아지, 모더레이션, 의도 분류, 추출 검사, 리랭킹, LLM-as-a-judge, 가드레일에 권장하고, LFM2.5-VL-3B에서 단일 패스로 보정된 의사결정을 위해 후속 학습되었다고 설명한다. 호스팅 모델 관련 게시물은 같은 작업 집합을 다른 말로 설명하고 호스팅 가격을 제시한다. 그것들이 하나의 모델이라면, 로컬 빌드는 호스팅 제품의 무료 복사본이며, 이는 연구소가 그런 말 없이 출시하기에는 이례적인 일일 것이다. 그것들이 공통 베이스의 두 가지 파인튜닝이라면, 공개된 수치는 어느 방향으로든 전이된다고 가정해서는 안 된다. 두 번째 설명은 벤더에 더 적은 것을 요구하며 우리가 가진 증거에 더 부합한다.

두 개의 스택을 운영하지 않고 결정의 양쪽 절반을 실행하기

어떤 이름을 정하든, 그 주변의 파이프라인은 대개 비슷해 보인다. 지원 큐에는 목적지 팀에 대한 선택 질문 하나, 환불이 요청되고 있는지에 대한 noul 질문 하나, 긴급도에 대한 점수 질문 하나가 들어온다 — 하나의 상태, 세 개의 답변, 한 번의 패스. 두 이름이 진정으로 갈라지는 지점은, 그 결정이 직접 실행하는 대신 임대해 쓰는 생성 모델 호출을 게이팅하는 지점이다. 그 호출은 다른 실패 프로필을 지닌 다른 문제이며, 그것은 파이프라인에서 d1이 맞는 것이 가장 덜 중요한 부분이다: 0.98 확률의 라우팅 답변 뒤에 라우팅한 모델이 보내는 502가 뒤따른다면, 어느 쪽이든 실패한 요청이다.

우리는 어떤 Liquid AI 모델도 호스팅하지 않습니다 — 이 글을 쓰기 전에 우리 자체 카탈로그를 확인했습니다 — 따라서 여기 어떤 내용도 우리를 통해 이 가중치들을 호출하는 것에 대한 주장이 아닙니다. 우리가 하는 일은 그 결정의 반대편에 있는 계층입니다: 트리아지된 요청이 팬아웃하는 모델들에 대해 하나의 OpenAI 호환 키를, 각 제공자의 정가로 0% 마크업으로 그대로 전달하여, 벤더 가격 인하가 계약 갱신 때가 아니라 적용되는 날 바로 여러분에게 도달하도록 하며, 제공자 간 자동 장애 조치를 통해 트리아지된 요청이 라우팅된 모델이 작동을 멈춰도 살아남도록 합니다. 결정 모델을 처음으로 파이프라인에 연결하는 경우, 바로 그 절반을 지루하게 만들어 두는 것이 가치가 있습니다.

상황에 따라 어떤 이름을 사용할지

이번 주에 유지할 가치가 있는 Python 환경 없이 모델을 사용해 보고 싶다면, 로컬 런타임이 사용하는 이름을 사용하세요. 가져오기: Liquid AI d1을 라이브러리에서 선택하고 Q8_0과 3.7GB를 받아들이고, 64KiB 요청 상한과 스트리밍 없음 규칙을 성가신 일이 아니라 설계 제약으로 간주하세요. 첫날부터 실제 엔드포인트와 실제 타입이 지정된 답변을 얻고 호출당 요금 측정기도 없습니다.

Q8_0보다 더 작은 풋프린트가 필요하다면 사용해야 할 이름은 Liquid AI d1-3B입니다. 1.67 GB Q4_K_M 빌드가 라이브러리 항목이 아니라 벤더의 GGUF 리포지토리에 있기 때문입니다. 이 한 가지 사실이 오늘날 두 이름 사이의 가장 실용적인 차이이며, 라이브러리 페이지를 읽고 거기서 멈추는 사람이 가장 놓치기 쉬운 바로 그 점입니다.

유료 사용자에게 이걸 선보이려 하고 먼저 정확도 근거가 필요하다면, 아직은 어느 이름도 도움이 되지 않습니다. 우리가 찾을 수 있는 한 어떤 d1 모델에 대한 독립적 평가도 없고, Decision Index 행들은 자체 채점된 것이며, 벤더는 오디오 결정 벤치마크를 전혀 공개하지 않았습니다. 할 수 있는 일은 모델이 이미 반환하는 신뢰도 값 — 0에서 1 사이로, 그 답이 맞을 가능성보다 확률이 한 답을 얼마나 강하게 지지하는지를 반영하는 — 을 계측하고, 자체 트래픽에서 이게 불확실한 지점을 직접 찾아내는 것입니다. 그 측정은 위의 어떤 슬라이드보다 가치가 있으며, 하루면 됩니다.

결정 모델은 파이프라인에서 값싼 절반이다. 그것이 라우팅하는 생성 모델이야말로 계약이 필요한 절반이다 — OpenAI 호환 키 하나가 분류된 요청이 뻗어 나가는 모델들을 담고 있으며, 각 모델은 공급자의 정가에 0% 마크업만 붙여 그대로 전달된다.

증류된 체크포인트를 자체 정식 릴리스와 비교하며 크기를 줄이는 일은 기록을 점검하기에도 좋은 시점입니다. 소형 Liquid 모델과 관련된 문서화된 AI 사고와 에이전트 실패는 OrcaRouter AI Incident Archive에 모여 있으며, 각 항목에는 자체 출처, 심각도, 신뢰도 등급, 이의 제기 플래그가 함께 표시되어 있습니다.