Liquid AI, 온디바이스 벤치마크 Pipette 오픈소스 공개

Pipette에서 비교 대상 한 줄은 모델 + 양자화 + 런타임 + 기기로 묶여요. 예를 들면 'LFM2.5-1.2B-Instruct를 q4_k_m으로 압축해 llama.cpp/ios 런타임에서 아이폰 17 프로에 올린 상태' 하나가 비교 단위가 되는 식이죠.

여기서 양자화는 모델 가중치의 정밀도를 낮춰 용량과 메모리 사용량을 줄이는 압축 방식이에요. 4비트로 줄이면 폰에 들어가지만 정확도는 조금 깎이고요. llama.cpp는 서버가 아니라 개인 기기에서 모델을 돌릴 때 널리 쓰이는 오픈소스 실행 엔진인데, 첫 공개분의 런타임은 이 계열로 채워져 있어요.

실제로 대시보드에 올라온 모델 목록을 보면 Liquid AI 자사의 LFM2.5 계열(230M·350M·1.2B·2.6B·8B-A1B)과 함께 Qwen3.5, gemma-4, granite-4 계열, Llama-3.2, Ministral-3, MiniCPM5, Olmo-3, Falcon-H1R, Ornith-1.0, Nanbeige4.2 같은 이름이 한 화면에 섞여 있어요. 아이폰 17 프로 화면 기준으로는 27개 모델이 한 축에 놓였고요.

첫 공개분에 담긴 것

항목	첫 공개분
모델 클래스	약 35종, 여러 제공사
양자화	llama.cpp 기준 7단계
런타임	llama.cpp 계열(macOS·iOS·Android)
기기	MacBook Pro(M5 Max), iPhone 17 Pro, Galaxy S26 Ultra, AMD Ryzen AI Max+ 395 + Radeon 8060S(곧 반영)
컨텍스트	256~8,192 토큰, 기기 메모리 허용 범위 내
결과 수	검증된 결과 1만 건 이상, 성능 설정 조합 1,000개 이상

함께 풀린 물건은 여섯 가지예요. 결과를 탐색·비교하는 인터랙티브 대시보드, 1만 건이 넘는 공개 데이터셋, macOS·Windows·iOS·Android용 벤치마크 클라이언트, 아티피셜 애널리시스 쪽에서 종합 점수를 보여주는 짝 대시보드, Apache 2.0으로 푼 벤치마크 관리·실행·제출·채점 인프라, 그리고 기기에서 바로 돌리는 iOS·안드로이드 네이티브 앱이에요. 노트북·데스크톱과 폰이 각각 어느 양자화 수준까지 도는지는 원문 설명이 서로 조금 어긋나서, 여기서는 '7단계 중 기기별로 커버 범위가 다르다'는 선까지만 옮겨요.

속도는 기기에서, 점수는 H100에서 재요

측정 구조가 둘로 갈려 있는 점이 눈에 띄어요. 속도와 메모리는 제출한 사람의 실제 기기에서 재고, 품질 평가는 H100 서버에서 돌려 채점해요. 폰마다 다른 발열·전력 조건이 정답률까지 흔들지 않게 분리한 설계죠.

공개된 제출 현황을 보면 속도·메모리 쪽은 제출 ID 4,284개, 품질 평가 쪽은 303개예요. 런타임별 분포는 이렇고요.

런타임	레코드	점유율	제출 ID
llama.cpp:macos-arm64	2,430	45.4%	1,944
llama.cpp:ios	1,475	27.5%	1,180
llama.cpp:android-arm64-v8a	1,450	27.1%	1,160

품질 평가는 llama.cpp 기준 3개 벤치마크에서 303개 레코드가 쌓여 있어요. 속도 데이터가 품질 데이터보다 열 배 넘게 많다는 뜻인데, 기기에서 초를 재는 일이 서버에서 시험지를 채점하는 일보다 훨씬 가볍다는 점을 생각하면 자연스러운 비율이에요.

모바일 종합 점수는 다섯 시험의 단순 평균이에요

아티피셜 애널리시스 쪽 대시보드가 보여주는 아이폰 17 프로 종합 점수는 다섯 개 평가의 단순 평균으로 나와요. BFCL 일부, IFBench, AA-Omniscience, GPQA Diamond, MATH-500이고, 컨텍스트는 16K 토큰으로 제한했어요. 가로축에 쓰이는 E2E 시간은 1,024 토큰 프롬프트를 처리하고 256 토큰을 생성하기까지 걸린 초를 뜻하고요. 이 화면에는 38개 모델 중 22개가 올라와 있어요.

차트에는 파레토 경계선이 그어져 있어요. 같은 속도에서 더 정확하거나 같은 정확도에서 더 빠른 모델들을 이은 선이라, 실제로 기기에 넣을 후보를 좁힐 때 이 선 위의 점부터 보면 돼요. 대시보드 캡션에 적힌 조건도 함께 읽어야 하는데, 앞서 본 화면은 q4_k_m·llama.cpp/ios·입력 1,024 토큰·사고 과정 끄기 상태를 걸어둔 결과예요. 조건을 바꾸면 줄 순서도 바뀌죠.

어떻게 써보나

어디서 시작하나 — Pipette 대시보드, 아티피셜 애널리시스의 짝 대시보드, iOS·안드로이드 앱, 그리고 macOS·Windows용 클라이언트 네 갈래예요. 각 주소는 Liquid AI의 발표 글타래 2번 트윗에 항목별로 정리돼 있어요.

1. 대시보드에 들어가 상단 기기 선택에서 자신이 배포할 하드웨어를 골라요. 아이폰 17 프로를 고르면 그 기기에서 돌린 결과만 남아요.
2. 모델 필터로 후보군을 좁혀요. 전체를 켜두면 27개 모델이 한 번에 뿌려지는데, 처음에는 파라미터 규모가 비슷한 것끼리 보는 편이 읽기 쉬워요.
3. 축을 바꿔가며 봐요. 세로축은 IFBench 같은 정확도, 가로축은 E2E 지연이나 메모리로 놓을 수 있어요.
4. Constraints 버튼으로 조건을 걸어요. 양자화 수준과 입력 토큰 길이를 실제 배포 조건에 맞춰야 숫자가 의미를 가져요.
5. 파레토 경계선 위에 놓인 점부터 후보로 추려요. 그 아래 점들은 같은 값을 더 느리게 내는 조합이에요.
6. 원하는 조합이 데이터셋에 없으면 iOS·안드로이드 앱이나 데스크톱 클라이언트를 자기 기기에 돌려 직접 재고, 결과를 제출해요. 승인된 제출은 그대로 공개 데이터셋에 더해져요.
7. 재보고 싶은 조합이 있는데 클라이언트가 지원하지 않으면 이슈를 올리라고 Liquid AI가 안내했어요.

누가 쓸 수 있나 — 인프라가 Apache 2.0이라 상업적 이용에도 제약이 적어요. 클라이언트는 macOS·Windows·iOS·안드로이드를 지원하고, 새 기기·런타임·모델 계열·양자화 수준을 첫날부터 추가할 수 있는 구조로 만들었다고 밝혔어요.

무엇을 해볼 수 있나 — 예를 들어 사내 앱에 3B급 모델을 넣으려는 팀이라면, 갤럭시 S26 울트라 기준으로 4비트 조합의 E2E 초와 메모리를 먼저 보고 후보를 두세 개로 줄일 수 있어요. 노트북용 도구를 만든다면 MacBook Pro(M5 Max) 결과를, 그리고 곧 반영될 AMD Ryzen AI Max+ 395 결과까지 비교해 윈도우 쪽 체감을 가늠해볼 수 있고요. 아직 아무도 재지 않은 조합이라면 직접 돌려 첫 데이터를 만드는 쪽이 빠르죠.

에디터의 시선

온디바이스 모델을 실제로 골라 본 사람이면 이 발표의 가치가 어디 있는지 바로 알아요. 지금까지 작은 모델을 폰이나 노트북에 얹으려면 남이 올린 블로그 글, 깃허브 이슈에 달린 댓글, 커뮤니티 표를 그러모아 추정해야 했어요. 문제는 그 숫자들의 조건이 제각각이라는 점이었죠. 누구는 8비트로 재고 누구는 4비트로 쟀고, 누구는 M2에서 누구는 M4에서 쟀어요. 조건이 다르면 비교가 아니라 인상 평가예요. Pipette가 조합을 하나의 단위로 못박은 건 그래서 방법론의 문제를 건드린 선택이에요.

측정 위치를 쪼갠 것도 실무 감각에 맞아요. 폰에서 GPQA Diamond를 다 돌리면 하루가 가고 발열 때문에 뒤로 갈수록 느려져요. 정답률은 기기와 무관하게 결정되는 값이니 H100에서 한 번 채점하고, 기기에서는 초와 메모리만 재는 게 맞죠. 대신 이 구조는 '기기에서 오래 돌렸을 때의 성능 저하'를 못 잡아요. 실제 배포에서 가장 아픈 대목이 그건데, 앞으로 지속 부하 항목이 붙을지가 이 플랫폼의 다음 시험대예요.

자사 모델이 자사 벤치마크의 차트에 올라 있다는 점을 두고 색안경을 쓸 필요는 없어요. 대신 이 구조를 어떻게 읽어야 하는지는 분명해요. 데이터셋이 공개돼 있고, 제3자 제출이 열려 있고, 채점 쪽에 모델을 만들지 않는 독립 분석사가 붙어 있는 세 가지가 이 표의 신뢰를 지탱해요. 셋 중 하나라도 흐려지면 표의 값어치도 같이 떨어져요. 읽는 쪽에서 할 일은 화면 캡션의 조건을 반드시 같이 보는 것 하나예요. q4_k_m, 입력 1,024 토큰, 사고 과정 끄기 — 이 조건이 자기 배포 조건과 다르면 그 줄 순서는 내 얘기가 아니에요.

국내 팀에는 특히 갤럭시 S26 울트라가 초기 기기에 들어간 게 실질적이에요. 안드로이드 플래그십에서 어느 크기까지 현실적으로 돌아가는지 남의 추정 없이 확인할 수 있으니까요. 온디바이스 기능을 검토 중인 서비스라면 기획서에 '3B급 사용'이라고 쓰기 전에, 대상 기기 한 대를 정해 놓고 파레토 선 위의 두세 조합을 실제로 돌려 보는 순서를 권해요. 앞으로 몇 주 안에 제출 데이터가 붙으면서 런타임 목록이 llama.cpp 밖으로 넓어질 텐데, 그때부터가 이 표를 제품 결정에 쓸 수 있는 시점이에요.