엣지에서 바로 결정하는 멀티모달 오픈 d1

이번에 다룰 글은 Liquid AI가 2026년 10월 7일에 공개한 Multimodal open d1 decision models for the edge입니다. 이 글은 d1 결정 모델 계열의 두 가지 오픈 웨이트 모델을 소개하는데, 텍스트와 이미지를 다루는 d1-3B와 텍스트와 이미지 또는 텍스트와 오디오를 다루는 실험적 모델 d1-omni-600M이 그 주인공입니다. 이 글에서 내세우는 주장은 하나의 문장으로 정리할 수 있는데, 토큰을 차례로 생성하는 대신 한 번의 포워드 패스로 구조화된 결정을 내리면 엣지 장치에서도 수십 밀리초 안에 멀티모달 판단을 실행할 수 있다는 것입니다. 원문에 대한 링크는 이 글의 제목 아래에 걸려 있으니 세부 수치와 실행 예제는 그곳에서 바로 확인할 수 있습니다.

토큰을 뱉지 않는 모델이 왜 궁금해졌을까

안녕하세요, 패트릭입니다. 저는 보통 새로운 소형 모델 소식을 들으면 먼저 가중치 크기부터 보는데요. 이번에는 순서가 바뀌었습니다. 결정을 내리는 데 토큰 생성이 왜 필요할까라는 문장이 먼저 걸렸기 때문입니다. 생각해보면 우리가 엣지에서 모델에게 바라는 일은 긴 설명이 아니라 짧은 판단인 경우가 많습니다. 환불 요청이 맞는지, 어느 팀으로 보내야 하는지, 지금 당장 막아야 하는 상황인지 같은 것들이죠.

그렇다면 생성 과정을 통째로 건너뛰면 어떻게 될까요. 이 질문이 이번 글을 끝까지 읽게 만든 이유였습니다. Liquid AI는 결정 모델을 생성 모델과 다른 갈래로 설명하는데, 답을 한 토큰씩 이어 붙이는 대신 하나의 패스로 질문들에 대한 답을 내놓는다는 것입니다. 말이 쉽지 실제로는 꽤 과감한 선택입니다. 왜냐하면 언어 모델의 유연함을 포기하는 대신 속도와 구조를 가져오는 교환이기 때문입니다. 저는 이 교환이 성립하는 조건이 궁금했고, 그래서 지연 수치와 벤치마크 표를 평소보다 꼼꼼하게 뜯어봤습니다.

엣지에서는 설명보다 결정이 먼저입니다

매장 계산대 옆에 놓인 작은 박스를 떠올려 보시면 이야기가 쉬워집니다. 그 박스는 카메라 한 대와 카드 단말기, 그리고 재고용 스캐너에 연결되어 있는데, 손님이 영수증을 흔들며 무언가 항의하고 있습니다. 이때 점원이 원하는 것은 상황을 요약한 에세이가 아니라 환불인지 교환인지, 금액이 얼마인지, 매니저를 불러야 하는지에 대한 답입니다. 게다가 그 답은 다음 손님이 오기 전에 나와야 합니다.

엣지의 현실이 대개 이렇습니다. 네트워크가 끊겨도 돌아가야 하고, 발열이 올라가면 성능이 꺾이며, 배터리가 허락하는 전력 안에서 움직여야 합니다. 클라우드에 물어보면 정확할지 몰라도 왕복 시간이 발목을 잡고, 개인정보 때문에 영상을 밖으로 못 내보내는 경우도 많습니다. 그래서 현장에서는 거대한 지식을 뽐내는 모델보다 작은 입력에서 빠르게 결정을 내리는 장치가 더 요긴할 때가 있습니다. 이번 d1 계열이 겨냥한 자리도 바로 여기인데요. 텍스트와 이미지, 오디오와 센서 신호를 장치 안에서 합쳐서 설명이 아니라 행동이나 분류로 끝내는 것입니다. 저는 이 방향을 연구실 점수 이상으로 평가했습니다. 운영의 아침을 지켜주는 장치이기 때문입니다.

한 번의 패스로 답한다는 말은 무슨 뜻일까요

여기서 재미있는 질문이 생깁니다. 한 번의 패스로 답한다는 것은 도대체 내부에서 무슨 일이 벌어진다는 뜻일까요. 생성 모델에 익숙한 분이라면 질문 하나에 답 하나씩 순차적으로 토큰을 뽑는 장면을 떠올리실 텐데요. 결정 모델은 그 순서를 따르지 않습니다. 여러 개의 이름 붙은 질문들을 미리 묶어서 하나의 상태와 함께 넣으면, 모델이 그 질문들에 대한 답들을 한 번에 내놓습니다. 환불 여부와 담당 팀, 긴급도처럼 서로 다른 형태의 답을 동시에 구하는 것이죠.

이 차이는 생각보다 중요합니다. 토큰 생성이 사라지면 KV 캐시를 길게 끌고 가야 하는 부담이 줄고, 출력 길이에 따라 지연이 들쭉날쭉해지는 현상도 잦아듭니다. 대신 모델은 정해진 질문 형식 안에서만 놀아야 합니다. 자유로운 서술은 못 하지만 정해진 판단은 아주 빠르게 하는 셈입니다. 사람으로 치면 수필가가 아니라 체크리스트를 손에 든 심사위원에 가깝습니다. 그리고 엣지처럼 지연 상한이 엄격한 곳에서는 이 심사위원 스타일이 훨씬 어울립니다. 왜냐하면 최악의 경우에도 얼마나 걸릴지 예측하기 쉽기 때문입니다.

다만 여기서는 조금 조심해서 읽을 필요가 있습니다. 빠르다는 말이 똑똑하다는 뜻은 아니기 때문입니다. 형식이 고정되면 모델이 다룰 수 있는 질문의 폭도 함께 좁아집니다. 그래서 다음에 볼 것은 이 형식을 어떻게 학습시켰는지, 그리고 그 학습이 실제 점수로 이어졌는지입니다.

출발선이 다른 두 개의 등뼈

이번 공개에서 눈에 띄는 점은 두 모델의 출발선이 완전히 다르다는 것입니다. d1-3B는 LFM2.5-VL-3B라는 최신 비전 언어 모델에서 출발했는데요. 이 등뼈는 디코더만으로 이루어진 구조라서 텍스트와 이미지를 받아들이는 방식이 생성 계열과 닮았습니다. 반면 d1-omni-600M은 LFM2.5-Encoder-350M이라는 양방향 인코더에서 출발했고, 여기에 비전 인코더와 오디오 인코더를 얹어서 세 가지 감각을 다루도록 만들었습니다. 입력 조합도 달라서 d1-3B는 텍스트와 이미지를 함께 보고, d1-omni-600M은 텍스트와 이미지 또는 텍스트와 오디오라는 두 가지 조합을 지원합니다.

그런데 용량이 주는 인상과 달리 역할 분담은 분명합니다. d1-3B는 결정 품질이 가장 중요한 자리에서 쓰는 쪽이고, d1-omni-600M은 설치 공간이 빡빡한 자리에서 쓰는 쪽입니다. 후자가 아직 초기 연구 공개 단계라는 점도 솔직하게 밝혀져 있는데요. 속도 수치가 d1-3B 위주로만 제시된 이유도 여기에 있습니다. 저는 이런 구분을 좋아합니다. 하나의 크기로 모든 문제를 덮으려는 대신 어디에 무엇을 올릴지를 고르게 해주기 때문입니다. 저희가 새로운 AI 아키텍처를 볼 때도 벤치마크 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다.

그렇다면 점수는 어디까지 믿을 수 있을까

숫자를 볼 차례인데요. 먼저 Decision Index 0.2.1이라는 결정 특화 지표에서 d1-3B는 48.57을 기록했습니다. 같은 표에서 4B와 9B급 모델들을 앞섰고, 35B-A3B라는 훨씬 큰 결정 모델의 47.11도 넘었다는 것이 글의 설명입니다. 매개변수가 적다고 무조건 뒤처지는 것이 아니라는 점을 보여주는 대목이라서 저도 눈이 갔습니다. 물론 지표 하나만으로 우열을 단정할 수는 없지만, 적어도 결정이라는 좁은 과업 안에서는 작은 쪽이 이기는 구간이 있다는 이야기가 됩니다.

다음 표는 일곱 개의 공개 데이터셋에 걸친 결과인데, 독해와 유해 댓글 판별, 의도 분류, 의료 질의응답, 다국어 이해를 함께 봅니다. 평균으로 보면 d1-3B가 82.9로 가장 높았고, Decider 4B의 81.1을 앞섰습니다. d1-omni-600M은 78.4로 Decider 2B의 77.1을 넘었는데, 매개변수가 4분의 1 수준이라는 점을 함께 적어두면 이 숫자의 결이 달라 보입니다. 세부적으로 들어가면 SQuAD 2.0에서 d1-3B가 83.3으로 가장 높았고, Civil Comments에서는 d1-omni-600M이 95.8로 표의 맨 위에 섰습니다. MASSIVE 의도 분류에서는 86.9와 86.1로 두 모델이 나란히 좋은 편이었고, PubMedQA에서는 d1-3B가 68.3으로 앞섰습니다. 반면 BoolQ와 XNLI에서는 Decider 계열의 큰 쪽이 각각 89.0과 88.6으로 더 높았고, PAWS-X에서는 d1 계열이 76.4와 79.5로 앞서는 식이라서 과업마다 강점이 갈렸습니다.

표면적으로 보면 단순합니다. 실제로는 그렇지 않습니다. 평균이 높다는 것이 모든 과업에서 이긴다는 뜻은 아니기 때문입니다. 저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 작은 인코더 기반 모델이 특정 분류와 paraphrase 계열에서 선전했다는 것은 결정 과업의 문법이 생성 능력과 꼭 같은 방향으로 크지 않는다는 방증이기 때문입니다.

16밀리초라는 숫자를 어떻게 읽어야 할까

속도 이야기로 넘어오면 분위기가 바뀝니다. NVIDIA와의 협업으로 측정했다는 전제가 붙는데요. d1-3B가 질문 하나에 답하는 데 걸린 시간은 Jetson AGX Thor에서 16밀리초, Jetson AGX Orin 64GB에서 26밀리초, Jetson Orin Nano에서 50밀리초였습니다. 모든 측정 장치에서 50밀리초 아래에 들어갔다는 점이 먼저 눈에 들어옵니다. 질문 세 개를 묶으면 Thor 기준 20밀리초로 늘어나는데, 하나를 물을 때의 1.3배 수준이라서 묶음 처리의 이득이 분명합니다.

상태가 길어지면 그림이 달라집니다. 3.4K 토큰짜리 상태를 읽는 데는 Thor에서 220밀리초, Orin에서 560밀리초, Nano에서 1640밀리초가 걸렸고, 384픽셀 이미지 하나를 처리하는 데는 각각 35밀리초와 83밀리초, 202밀리초가 들었습니다. 초당 처리하는 상태 수로 환산한 packed 조건에서는 Thor가 262, Orin이 110, Nano가 38을 기록했습니다. GPU 쪽은 더 여유가 있어서 RTX 4090에서 질문 하나가 8밀리초, AMD MI325X에서 9밀리초였고, 이미지 처리는 두 플랫폼 모두 17밀리초와 18밀리초 아래에 들어갔습니다. Apple M5 Pro에서의 수치도 함께 실렸는데 질문 하나에 30밀리초, 세 개에 41밀리초, 이미지 처리에 62밀리초였습니다.

여기서 제가 멈칫했던 부분은 측정 조건입니다. 엣지의 체감 속도는 모델 크기만으로 정해지지 않고, 양자화와 런타임, NPU 드라이버, 발열로 인한 쓰로틀링이 함께 얽히기 때문입니다. 이번 글만으로는 4비트 양자화 여부나 구체적인 그래프 최적화 내역이 확정되지 않아서, 같은 Jetson이라도 현장 조건에서는 숫자가 달라질 수 있습니다. 그럼에도 방향은 분명합니다. 질문을 묶을수록 개당 비용이 내려가고, 이미지가 길어질수록 Nano급에서는 부담이 커진다는 것입니다. 실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 우리 카메라 해상도와 상태 길이를 기준으로 예산을 어디에 쓸 것인가 하는 것이죠.

질문 세 개를 한 번에 던지면 무슨 일이 생길까

사용법은 이번 공개에서 가장 손에 잡히는 부분입니다. transformers의 비교적 최신 버전을 깔고 모델을 불러오는 방식인데, 자체 실행 코드를 함께 싣고 있어서 신뢰된 원격 코드를 허용하는 형태로 적재합니다. 장치가 CUDA인지 MPS인지 CPU인지에 따라 정밀도를 고르는 대목도 그대로 따라가면 됩니다. 실행 예제에서 좋았던 점은 추상적인 설명 대신 티켓 두세 장을 실제로 분류하는 장면을 보여준다는 것입니다.

예를 들어 이중 청구로 환불을 요청하는 문장이 하나 있으면, 그 문장에 환불 여부와 담당 팀, 긴급도라는 세 가지 질문을 한꺼번에 붙입니다. 환불 여부는 이진에 가까운 판단이고, 담당 팀은 과금과 기술, 부정 사용 가운데 고르는 선택이며, 긴급도는 기다려도 되는지 오늘 처리할지 지금 막아야 할지를 고르는 점수형입니다. 모델은 이 세 가지를 한 번의 호출로 내놓는데요. 이미지 입력도 같은 호출 틀 안에 들어갑니다. 소파 위에 고양이 두 마리가 앉은 사진을 넣고 마릿수를 고르라는 선택 질문을 던지면 사진 전체가 상태가 되는 식입니다. 여러 요청을 묶을 때는 패딩 없이 묶는 배치 호출이 있어서, 서로 다른 티켓들을 각자의 질문과 함께 포장해서 보낼 수 있습니다.

이 설계가 주는 감각은 일종의 주문서와 비슷합니다. 상태라는 재료 위에 질문이라는 주문을 올리면 주방에서 한 번에 요리를 내오는 것이죠. 주문이 늘어날수록 주방이 바빠지는 것은 당연하지만, 손님마다 주방을 새로 여는 것보다는 훨씬 낫습니다. d1-omni-600M의 실행법은 모델 카드 쪽에 따로 실려 있어서 이번 글에서는 d1-3B 예제만 다룹니다. 저는 앞으로 보고 싶은 것은 이 주문서 문법이 현장의 예외 케이스를 얼마나 견디는지입니다. 환불과 욕설이 한 문장에 섞이거나 사진이 심하게 흔들렸을 때 답이 어떻게 흔들리는지가 진짜 내구성이기 때문입니다.

생성형 소형 모델과 헷갈리면 놓치는 것들

이쯤에서 오해를 하나 풀어야 할 것 같습니다. d1 계열을 그냥 작은 멀티모달 생성 모델로 보면 이야기가 어긋나기 때문입니다. 생성 모델은 무엇이든 말할 수 있지만 그만큼 답의 모양이 매번 달라지고, 길이에 따라 비용도 달라집니다. 반면 결정 모델은 말할 수 있는 모양을 미리 정해두고 그 안에서만 답합니다. 유연함을 줄이고 예측 가능성을 사는 선택이죠. 그래서 긴 요약을 뽑아내는 일에는 어울리지 않고, 분류와 선택, 점수 매기기처럼 답의 틀이 정해진 일에 어울립니다.

문제는 그다음입니다. 틀이 정해졌다는 것은 학습과 평가의 문법도 달라져야 한다는 뜻입니다. 지시 따르기와 함수 호출, 불확실성 보정이 결정용 미세조정으로 묶여서 소개되는 이유가 여기에 있습니다. 모델이 맞다고 말하는 것만으로는 부족하고, 얼마나 확신하는지도 함께 다뤄야 현장에서 쓸 수 있기 때문입니다. 예컨대 긴급도를 매기는 모델이 항상 가장 높은 단계를 고른다면 정확도는 몰라도 운영은 망가집니다. 그래서 보정은 점수 옆에 붙는 장식이 아니라 운영의 일부입니다. (참고로 이번 글에서 비전과 오디오 자체의 벤치마크 수치는 따로 제시되지 않았는데요. 결정 지표의 공개 분할에 비전이 없고 오디오 결정 벤치마크는 아직 열린 문제라는 설명이 붙었습니다.)

카메라와 마이크 앞에서는 무엇이 달라질까

멀티모달이라는 말을 엣지에서 꺼내면 곧바로 따라오는 질문이 있습니다. 좋은 건 알겠는데, 이걸 실제로 어떻게 서빙할까요. 카메라는 흔들리고 마이크에는 매장 음악이 섞이며, 밤이 되면 조도가 떨어집니다. 어느 한 감각이 통째로 비는 경우도 생깁니다. 렌즈에 김이 서리거나 오디오 케이블이 빠지는 날이 실제로 있기 때문입니다. 그래서 엣지용 평가는 정확도만 보지 않고 지연과 전력, 발열 한계, 그리고 감각이 깨졌을 때의 버팀목을 함께 봅니다.

이번 글의 어휘로 말하면 modality dropout과 KV 캐시 최적화 같은 대목이 여기에 걸립니다. 학습 때 일부 감각을 일부러 빼고 훈련하면, 현장에서 한 감각이 빠져도 모델이 덜 흔들립니다. ONNX와 llama.cpp, ExecuTorch, TensorRT-LLM, NPU SDK 같은 배포 스택이 함께 언급되는 것도 같은 맥락인데요. 어떤 런타임에 올리느냐에 따라 수십 TOPS급 NPU의 성능을 얼마나 뽑아내는지가 달라지기 때문입니다. 0.5B에서 7B 사이의 오픈 모델들이 4비트 양자화와 최적화된 런타임을 만나 엣지 NPU 위에서 돌기 시작했다는 큰 흐름도 이 글의 배경에 깔려 있습니다. 가벼운 비전 인코더와 작은 언어 디코더를 프로젝터나 perceiver resampler로 잇는 구성이 자주 등장하는 이유도 여기에 있습니다. 무거운 이해보다 빠른 판단에 맞춰 부품을 고른 것이죠.

저는 여기서 한 가지 상상을 해봅니다. 새벽 물류 창고에서 박스 낙하 소리와 함께 카메라 한 대가 흔들리는 장면 말입니다. 오디오만으로는 위치를 모르고 영상만으로는 소리의 원인을 모르는데, 두 감각을 함께 보면 낙하 지점과 파손 여부를 바로 판단할 수 있습니다. 물론 이런 장면이 매번 완벽할 수는 없습니다. 그래서 남는 질문은 단순합니다. 감각 하나가 비었을 때 모델이 모른다고 말할 수 있는가 하는 것입니다.

그래서 엣지에서 무엇을 맡기고 무엇을 남길까요

마지막으로 시야를 넓혀 보겠습니다. 이번 공개를 관통하는 태도는 모든 판단을 모델에게 넘기자는 것이 아니라 판단의 모양을 나누자는 것에 가깝습니다. 정형화된 결정은 장치 안에서 수십 밀리초에 끝내고, 애매하고 책임이 무거운 판단은 사람이나 더 큰 모델에게 넘기는 것이죠. d1-3B가 Decision Index에서 큰 모델들을 앞선 대목은 이 분업이 허황된 것이 아니라는 신호로 읽힙니다. 작은 쪽이 이기는 과업이 실제로 있다는 것이니까요.

다만 남는 숙제도 분명합니다. 엣지에서 스스로 행동하는 장치가 늘어날수록 안전과 책임의 문제도 함께 커집니다. 잘못된 차단과 잘못된 허용 가운데 어느 쪽이 더 아픈지, 하드웨어마다 다른 성능을 어떤 기준으로 비교할지, 멀티모달 학습 데이터의 권리는 어떻게 정리할지가 그것인데요. 이번 글에서도 이 부분은 열린 질문으로 남겨져 있습니다. 저는 그 여백이 오히려 솔직하게 느껴졌습니다. 모든 답을 다 안다고 말하는 것보다 어디까지 모르는지를 밝히는 편이 현장에서는 더 도움이 되기 때문입니다.

그래서 저는 이 글을 이렇게 기억하려 합니다. 엣지의 문제는 모델이 작아도 된다는 것이 아니라 결정의 모양을 먼저 정해야 한다는 것이었습니다. 모양이 정해지면 속도와 비용과 평가가 함께 정해지고, 그때서야 작은 모델이 큰 일을 할 수 있습니다. 다음에 카메라 앞에서 판단을 내려야 하는 장치를 본다면 저는 먼저 이 질문을 던질 것 같습니다. 이 장치에게 필요한 것은 긴 설명일까요, 아니면 지금 당장의 결정일까요.