LiquidAI, 단일 패스로 판단하는 멀티모달 모델 d1-3B 공개

AI 요약

LiquidAI의 d1-3B는 LFM2.5-VL-3B를 기반으로 판단 작업에 맞게 후학습한 31억 파라미터 모델입니다. 대화형 응답을 작성하는 모델이 아니라, 텍스트·JSON·이미지 또는 이들의 조합을 상태(state)로 받아 정해진 질문에 답합니다. 예·아니요, 이름이 붙은 선택지, 순서가 있는 점수 등 결과 형식을 지정할 수 있으며, 답변은 확률과 신뢰도 같은 필드를 포함한 구조화 데이터로 돌아옵니다. 추론 한 번에 출력 토큰을 0개 생성하는 방식입니다.

입력을 한 번 읽고 여러 판단 수행

system_one(state, questions) 호출은 하나의 상태를 읽어 여러 질문에 답합니다. 예를 들어 고객 문의 하나를 입력하고 환불 요청 여부, 담당 팀, 긴급도를 함께 판정할 수 있습니다. 질문은 Decision Index 스키마에 맞춰 유형, 지시문, 선택 기준을 지정합니다. 이미지도 상태에 포함할 수 있어 사진을 보고 선택지 중 하나를 고르는 작업도 가능합니다. 배치 호출은 여러 요청을 패딩 없이 묶어 처리합니다.

모델은 총 3.12B 파라미터이며, 400M 규모의 SigLIP2 NaFlex 비전 인코더를 포함합니다. 컨텍스트 길이는 32,768토큰, 어휘 크기는 128,000입니다. LiquidAI는 라우팅과 분류, 콘텐츠 관리, 정보 추출 확인, 재정렬, LLM-as-a-judge, 에이전트 가드레일, 시각 검사 등을 사용 사례로 제시합니다. 일반 대화나 자유 형식 글쓰기에는 맞지 않습니다.

지연 시간과 처리량

공개된 지연 시간은 워밍업을 마친 뒤 한 번에 요청 하나를 처리한 결과입니다. RTX 4090에서는 질문 하나에 8ms, 한 상태에 질문 세 개를 묶으면 21ms가 걸립니다. AMD MI325X는 각각 9ms와 14ms입니다. 3,400토큰 상태를 처리할 때는 4090에서 102ms, MI325X에서 44ms가 걸렸고, 384픽셀 이미지 입력은 각각 17ms와 18ms였습니다. 상태 64개를 묶었을 때 처리량은 4090에서 초당 475개, MI325X에서 1,106개입니다.

Apple M5 Pro에서는 단일 질문 30ms, Jetson AGX Thor에서는 16ms, Jetson AGX Orin 64GB에서는 26ms, Jetson Orin Nano에서는 50ms로 측정했습니다. 64개 상태를 묶은 처리량은 기기에 따라 초당 38~262개입니다. NVIDIA GPU에서는 model.compile(mode="reduce-overhead")를 적용해 CUDA 그래프로 실행할 수 있습니다. 4090의 단일 질문 결과에는 이 설정이 적용됐으며, 적용하지 않으면 16ms가 걸립니다. 새 입력 형태는 커널 선택이나 컴파일 비용이 들기 때문에 서비스에 넣을 형태로 미리 워밍업해야 합니다.

공개 벤치마크 결과

Decision Index 0.2.1에서 d1-3B는 48.57점을 받았습니다. 4B·9B 모델과 Decider 35B-A3B의 47.11점보다 높은 점수입니다. 다만 LiquidAI가 공식 스코어러로 직접 계산한 결과이며, 리더보드 제출 점수는 아닙니다. 같은 표에서 지식 점수는 23.8로 Winnow-12B의 33.8보다 낮지만, 도구 영역은 74.5로 비교 모델 중 가장 높습니다.

공개 이미지 벤치마크 11종의 평균은 d1-3B 74.1점, 기반 모델 LFM2.5-VL-3B 73.9점입니다. 벤치마크별로는 결과가 엇갈립니다. VL-RewardBench에서는 65.0점으로 기반 모델의 50.9점보다 높았지만, CV-Bench에서는 82.1점으로 기반 모델의 87.6점보다 낮았습니다. 같은 이미지 질문에서 이미지를 제거하면 점수가 45.1로 떨어졌다고 LiquidAI는 밝혔습니다.

Reddit 반응

• @u/Main-Wolverine-1042 — 정말 엄청나다고들 하네요.
  • @u/ivxk — 이제 과열 국면에 들어서서 새로 띄울 게 없어, 옛것을 다시 데워서 화제를 만드는 건가요?
  • @u/philmarcracken — 저는 그냥 그저 그렇습니다.
• @u/switchandplay — :( 일반적인 모델을 공개하길 바랐는데, 또 다른 판단 모델이라 아쉽습니다.
  • @u/jld1532 — 거의 자금이 바닥났거나, 적어도 학습 자원이 부족한 것 같습니다. 6개월쯤 전에 20B대 모델 업데이트를 약속했잖아요.
  • @u/theintersepter — 저도요. 판단 모델이 왜 이렇게 화제가 되는지 모르겠습니다.
  • @u/Pro-Row-335 — 사용 사례도 모르면서, 사용 사례가 없다고 하는 건가요?
• @u/No-Marionberry-772 — 이런 모델의 사용 사례를 아직도 잘 모르겠습니다.
  • @u/durden111111 — 아주 빠르게 판단을 내리는 모델입니다. 이메일이 스팸처럼 보이는지 우리는 대개 바로 알아차립니다. 굳이 생각할 필요가 없죠. 판단 모델은 입력·출력 토큰을 아주 적게 써서 판단을 거의 즉시 내립니다. LLM은 전체 응답을 만들며 추론 토큰을 쓰는데, 시간과 전력, 컨텍스트를 소모합니다. 지금 흔한 LLM 사용 사례와는 다를 수 있지만, 더 큰 시스템에 통합하면 쓸 곳이 많습니다.
  • @u/claythearc — 분류 작업에 쓰고 있습니다. 예를 들어 의미 검색에서 상위 k개 문서를 가져온 뒤, 판단 모델에 가장 적합한 문서를 고르게 합니다.
  • @u/-Cubie- — 검색에서 일반적인 CrossEncoder 재정렬 모델보다 성능이 좋나요? 그 모델도 판단 모델처럼 분류기잖아요.
  • @u/claythearc — 저희 영역에서는 정확도가 비슷하지만, 공유 상태를 활용해서 훨씬 빠릅니다.
  • @u/-Cubie- — 흥미롭네요. 공유 상태란 쿼리 하나를 여러 문서와 동시에 비교하면서 쿼리를 재사용한다는 뜻인가요?
  • @u/claythearc — 네, 대체로 그렇습니다. 재정렬 모델은 쿼리·문서 쌍마다 순전파를 해야 하지만, 판단 모델은 프리필 비용을 한 번만 냅니다. 규모가 작을 때는 별 차이가 없지만 커지면 차이가 납니다.
• @u/debackerl — 기존 LLM에 문법 제약 출력을 적용해 구조화 결과를 안정적으로 파싱할 수는 있습니다. 그래도 보정된 확률은 얻지 못합니다. 토큰별 확률을 구할 수는 있지만, 그 확률은 실제 정답 확률이 아니라 토큰 샘플러에 맞춰 조정된 값입니다.
• @u/illhaveubent — 비디오 게임 NPC가 유한한 행동 목록에서 선택할 때 쓸 수 있습니다. RTX 4090에서 8ms처럼 빠릅니다. 60fps에서는 한 프레임이 16ms이므로, 실시간으로 NPC 여러 명의 판단을 이어서 계산할 수 있습니다.
  • @u/Infamous_Mud482 — 그렇지 않습니다. 많아야 제품으로 이어지지 않을 기술 데모를 설명하고 있네요. 사람들이 관심을 가질 만한 게임 중에서, 편집하고 검증한 스크립트 대신 이 판단 모델에 GB 단위 메모리를 쓰는 게임을 하나만 말해보세요.
• @u/Tamitami — 좋네요! 엣지 하드웨어에서 시험할 사용 사례가 이미 있습니다. 수정: 두 모델을 모두 시험해 봤는데 800M 모델조차 제 용도에는 너무 큽니다. 제가 직접 학습한 분류기는 100ms인데, 800M 모델은 75,000ms가 걸리고 성능도 더 나쁩니다. 그래도 프롬프트를 입력하고 확률을 포함한 답을 얻는 범용 분류기가 새로 나온 건 좋습니다.

원문: Hugging Face / 번역·요약: Trawling