LFM3-VL-2B vs MiniCPM-V 4.7 35B-A3B: 모델이 아닌 칼럼

벤치마크 표를 열어 LFM3-VL-2B를 찾아보면 MiniCPM 열이 있습니다. 그 열에는 MiniCPM-V 4.7 1B라고 표시되어 있습니다. 그것은 작은 형제 모델입니다. 사람들이 MiniCPM-V 4.7이라고 말할 때 대개 의미하는 모델 — OpenBMB의 MiniCPM-V 4.7 35B-A3B, MiniCPM-V 라인 최초의 mixture-of-experts 체크포인트 — 는 Liquid AI의 표에 전혀 없고, 두 연구소가 공개한 벤치마크에서도 1B에 근접하지 않습니다. 따라서 사람들이 실제로 저울질하는 맞대결인 LFM3-VL-2B 대 MiniCPM-V 4.7 35B-A3B는 벤치마크 이름은 공유하지만 평가 하네스는 공유하지 않는 두 공급업체의 표에서 손수 조립해야 합니다. 이어지는 내용은 바로 그 조립이며, 이음새는 그대로 드러나 있습니다.

크기 불일치는 두 번째 놀라움이다. 한 모델은 19억 2천만 개의 밀집 파라미터를 갖고 있으며 몇 기가바이트 안에 들어간다. 다른 모델은 352억 1천만 개의 파라미터를 저장하고 토큰당 그중 약 30억 개를 건드린다. 스펙표로 읽으면 그것은 전혀 맞대결이 아니다. 같은 질문 — 통제할 수 없는 기기에서 무엇을 실행할 수 있는가 — 에 대한 두 가지 답으로 읽으면, 거기에 이르는 방법에 관한 정말 흥미로운 견해 차이다.

두 모델, 하나의 이름

이름 충돌은 이 비교가 읽히는 방식에 실질적인 악영향을 주고 있다. Liquid AI의 모델 카드는 이 점에 대해 꼼꼼하다. 해당 열에는 1B라고 적혀 있고, 그 1B는 1.92B 모델과 견줄 만한 정당한 비교 대상이다. 그러나 검색 결과, 집계 사이트, 일상적인 언급은 모두 "MiniCPM-V 4.7"을 하나로 뭉뚱그리며, 사용자층을 확보한 변형은 35B-A3B다. 2026년 10월 28일 기준 Hugging Face에서 35B-A3B는 다운로드 289,535회와 좋아요 1,095개를 기록한 반면, 1B 형제 모델은 155,428회와 수백 개에 그친다.

날짜는 그 격차의 일부를 설명하지만 나머지는 설명하지 못한다. OpenBMB의 35B-A3B 저장소는 2026년 10월 7일에 생성되었고, 프로젝트 자체 자료에는 출시일이 10월 12일로 되어 있다. Liquid AI의 LFM3-VL-2B 저장소는 10월 19일에 올라왔고 LFM3 제품군은 10월 27일에 발표되었다. LFM3-VL-2B는 공개된 지 9일밖에 되지 않았으므로, 255회 다운로드는 달력상의 사실일 뿐 평가가 아니다. 더 흥미로운 항목은 좋아요 비율이다: LFM3-VL-2B는 45, MiniCPM은 1,095이다. 후자를 다운로드한 사람들은 좋아요를 누를 만큼 마음에 들었다.

각각이 실제로 무엇인지

• 매개변수 — LFM3-VL-2B는 1.92B 덴스 모델입니다. 1.73B 언어 백본, 164M 자체 개발 비전 인코더, 25M 프로젝터로 구성됩니다. MiniCPM-V 4.7 35B-A3B는 256개 전문가에 걸쳐 35.21B를 저장하고 토큰당 그중 8개를 라우팅하며, 활성 매개변수는 약 3B입니다.

• {{1}}백본{{/1}} — 24개 LFM3 레이어로, {{2}}13개 게이티드 짧은 컨볼루션{{/2}}, {{3}}5개 슬라이딩 윈도우 어텐션 레이어{{/3}}, {{4}}6개 글로벌 어텐션 레이어{{/4}}로 나뉘며, 히든 크기 2,048의 {{5}}40개 트랜스포머 레이어{{/5}}와 대비됩니다.

• 비전 경로 — 16×16 패치에 2D 로터리 임베딩을 사용하는 8개의 게이트형 depthwise 2D 컨볼루션과 6개의 양방향 어텐션 레이어로 구성된 14층 인코더로, 텍스트 스택의 6번째 레이어에 삽입되는 hidden size 1,152의 27층 타워와 대비되며, 인코더 내부의 early token compression과 전환 가능한 4× 또는 16× 시각적 다운샘플링을 갖춥니다.

• 컨텍스트 — LFM3-VL-2B에서는 128K 토큰, MiniCPM에서는 256K 토큰이며, 둘 다 입력과 출력을 합한 값입니다.

• 입력 — Liquid 모델의 경우 텍스트, 이미지, 초당 2프레임의 비디오, OpenBMB 모델의 경우 텍스트, 이미지, 비디오. 두 모델 모두 오디오 입력도, 오디오 출력도 하지 않습니다.

• 디스크상의 가중치 — BF16에서 약 3.8GB 대 BF16에서 약 65.6GiB.

• 라이선스 — LFM Open License v1.0은 Liquid가 연간 매출 1,000만 달러 미만의 상업적 사용은 무료라고 설명하는 라이선스인 반면, Apache 2.0은 매출 조건이 없습니다.

아키텍처상의 이견이 이 이야기의 전부다. Liquid는 소형 밀집 모델에 목적 맞춤형 비전 인코더를 더한 방식이 이미지당 연산량에서 SigLIP 스타일 타워를 능가한다고 베팅했고, 이를 입증하는 카테고리 표를 공개했다. OpenBMB는 값비싼 부분을 상주시키지 않고 스트리밍하게 하면 35B 모델의 역량을 유지하면서도 휴대폰에서 실행할 수 있다고 베팅했다. 둘 다 메모리에 관한 베팅이지만, 방향은 정반대다.

그 격차는 실재하며, 그것은 그 프레이밍이 시사하는 것보다 좁습니다.

다음은 두 공급업체 표에서 올바른 행을 나란히 놓았을 때 나오는 내용입니다. 이는 모두 각 연구소가 자체 보고한 것이며, 하네스 관련 주의사항은 그 뒤에 이어집니다.

• MMMU — LFM3-VL-2B는 thinking 켜면 55.7, 끄면 48.6; MiniCPM-V 4.7 35B-A3B는 4× 시각 압축에서 80.22, 16×에서 80.00.

• MMStar — 4×의 80.67, 16×의 80.13에 비해 74.4.

• OCRBench v1 — 4×에서 91.20, 16×에서 90.40과 비교해 86.3.

• MathVista — 사고 사용 시 84.2, 미사용 시 68.5, 4×에서 88.00 및 16×에서 87.30 대비.

• CharXiv 추론 — 4×에서 75.60 대비 70.2, 16×에서 69.20.

MMMU는 35B가 그 크기에 걸맞은 진가를 입증하는 지점입니다. 사고 구성보다 24.5포인트, 비사고 구성보다 31.6포인트 앞섭니다. 이는 대학 수준의 멀티모달 추론 벤치마크이며, 그 격차는 하네스 차이에 관한 어떤 합리적인 이의 제기도 견딜 만큼 충분히 큽니다.

나머지 모든 항목은 프레이밍이 시사하는 것보다 더 가깝다. OCRBench는 4.9점 차이다. MathVista는 LFM3-VL-2B가 사고할 때 3.8점 차이다. CharXiv 추론에서 Liquid 모델은 사고 모드에서 5.4점 차로 뒤지며 — 35B의 16× 수치를 1점 앞선다. 문서 OCR과 차트에서 2B 모델이 35B와 5점 이내 차이를 보인다는 점이 MMMU 헤드라인보다 더 주목받아야 할 발견이다.

이제 주의할 점입니다. 이것들은 중요합니다. Liquid의 수치는 vLLM 0.27.1에서 62개 벤치마크를 한 번 실행한 결과에서 나온 것이며, 달리 표시된 구성을 제외한 모든 모델에 추론 모드를 활성화한 상태로 0–100으로 정규화되었습니다. OpenBMB의 다섯 수치는 숫자 표가 아니라 차트 이미지로 공개되었고, 여기서는 제3자 집계자가 그 차트를 읽은 내용을 바탕으로 옮겨 적었으므로 소수점 값은 근사치로 보아야 합니다. 두 연구소는 시각 토큰 예산, 프롬프트 방식, 디코딩 설정에 대해 서로 합의하지 않았으며, OpenBMB 쪽의 4× 대 16× 구분은 그 자체로 점수를 최대 6점까지 바꿉니다. 이것은 통제된 실험이 아니라 두 가지 주장 묶음을 나란히 놓은 것입니다.

소형 모델에는 수치가 있지만 대형 모델은 공개하지 않는 경우

Liquid는 62개 행을 공개했다. OpenBMB는 다섯 개를 공개했다. 이 비대칭성은 이 비교에서 가장 덜 보도된 사실이며, 더 작은 모델을 돋보이게 하는 방향으로 작용한다.

• 시각적 그라운딩 — LFM3-VL-2B의 경우 RefCOCO-avg 90.5, RefCOCO-M 95.2, Point-Bench 73.8, RefSpatial-Bench 49.8. MiniCPM-V 4.7 35B-A3B의 공개 평가에는 이에 해당하는 항목이 없습니다.

• GUI 이해 — ScreenSpot-Pro 55.5, ScreenSpot-v2는 데스크톱 94.6, 모바일 92.2, 웹 89.9. 다시 말해, OpenBMB 측에서는 공개된 것이 없습니다.

• 구현화 추론 — EmbSpatial-Bench 82.9, RoboSpatial-Home 63.4, Where2Place 44.9. 마찬가지로 부재.

• 비디오 — 자막 없는 Video-MME 62.8, MVBench 69.4, MLVU 71.3, ActivityNet-QA 71.2. MiniCPM-V 4.7은 비디오를 지원하며 모델 카드에서 이에 대해 자세히 다루지만, 수치 표에는 검증할 수 있는 비디오 행이 없습니다.

이것은 증거의 부재이지, 기본값으로 승리하는 것이 아닙니다. 로보틱스나 화면 에이전트 파이프라인을 구축하고 있다면, 정직한 입장은 35B의 해당 작업 역량이 약한 것이 아니라 알려지지 않았다는 것입니다. 하지만 "알려지지 않음" 자체가 조달 문제입니다: 아무도 공개하지 않은 수치를 기준으로 배포를 계획할 수는 없으며, LFM3-VL-2B는 둘 중 다운로드 전에 그라운딩과 GUI 성능을 확인할 수 있는 유일한 모델입니다.

기억에 관한 논거는 양날의 검이다

2B를 35B보다 선택하는 흔한 이유는 2B가 메모리에 들어가기 때문입니다. LFM3-VL-2B는 완전하고 예측 가능하게 들어갑니다. BF16에서 약 3.8GB로 상주하며, 페이징이 없고, 기기에 부하가 걸려도 예상 밖의 일이 없습니다. 이는 통제할 수 없는 하드웨어에 제품을 출시할 때 진정으로 강력한 특성입니다.

MiniCPM-V 4.7 35B-A3B는 65.6 GiB라서 휴대폰에는 전혀 들어가지 않으며, OpenBMB의 설계 전체는 바로 그 때문에 존재한다. Lookahead Expert Scheduling은 다음 레이어의 라우팅을 예측하고 예상되는 전문가들을 프리페치한다. 세밀한 계층별 양자화는 해당 전문가들을 줄여 더 빠르게 이동하게 하고, DSpark 추측 샘플링은 디코딩 정체를 메운다. 제조사 주장은 약 3 GB 메모리를 사용하는 iPhone 17 Pro Max에서 초당 13개 이상의 토큰, 16 GB의 iPad Pro M4에서 17개 이상이다.

그래서 온디바이스 주장은 “35B가 작다”가 아니다. “35B가 스트리밍되고, 그 스트리밍이 사용할 수 있을 만큼 매끄럽다”이다. 이 둘은 서로 다른 실패 모드를 가진 서로 다른 베팅이다. 상주형 3.8GB 모델은 완만하게 성능이 저하된다. 즉 로드되어 있거나 그렇지 않을 뿐이다. 스트리밍형 65.6GiB 모델은 플래시 대역폭, 열 스로틀링, 콜드 스타트 지연에 따라 성능이 저하되며, 이 모든 것은 한 대의 iPhone에서 수행한 벤치마크로는 포착하지 못하는 방식으로 기기마다 달라진다.

실용적인 구분: 저장 속도와 열적 한계를 모두 통제하지 못한다면 상주형 방식이 위험이 더 낮은 경로입니다. 최근 플래그십 하드웨어에 출하하면서 정확도를 원한다면, OpenBMB의 접근 방식은 더 이상 이론에 그치지 않습니다 — 이미 출시된 모델이며 그 뒤에는 작동하는 포크가 있습니다.

데이원 툴링은 동점이 아니다

LFM3-VL-2B는 transformers 5.21 이상이 필요한 BF16 가중치를 제공하며, GGUF에는 양자화 인식 증류 Q4_0 체크포인트, MLX 4비트 빌드, ONNX 내보내기가 포함됩니다. 서버 지원은 아직 완료되지 않았습니다. vLLM은 진행 중으로 설명되어 있고, SGLang은 풀 리퀘스트 46858에서 검토 중이며, llama.cpp는 비디오 입력이 아직 지원되지 않는다는 명시적 설명과 함께 풀 리퀘스트 31252에서 검토 중입니다. 모델 카드는 또한 vLLM 및 SGLang용 qwen3 추론 파서와 qwen3_coder 도구 호출 파서를 권장하는데, 이는 이것이 얼마나 최근에 연결되었는지 알려주는 세부 사항입니다.

MiniCPM-V 4.7 35B-A3B는 SGLang, vLLM, llama.cpp, Ollama를 지원하고, 미세 조정을 위한 SWIFT 및 LLaMA-Factory와 GGUF, BitsAndBytes, AWQ, GPTQ, FP8, int4 빌드를 지원하며, iOS, Android, HarmonyOS 전반에서 Rockchip, Houmo, Intel, AMD, Arm의 칩 플랫폼을 출시 당일 지원합니다. 온디바이스 경로는 업스트림 llama.cpp가 아니라 OpenBMB 자체의 llama.cpp-omni 포크를 통해 실행됩니다.

이번 달 프로덕션 배포라면 그것은 애매한 선택이 아닙니다. 연구용 스파이크, 노트북 데모, 또는 직접 소유하려는 파인튜닝이라면 LFM3-VL-2B는 오늘 transformers를 통해 바로 작동하며 빌드 플래그에 일주일을 쓸 필요가 없습니다.

더 많은 팀이 걸려 넘어질 라이선스 조항

Apache 2.0과 LFM Open License v1.0의 대비는 MMMU 격차보다 실무적으로 더 큰 차이입니다. 왜냐하면 이는 어려운 사례에만 적용되는 것이 아니라 모든 배포에 적용되기 때문입니다. Apache 2.0에는 매출 조건도, 사용 분야 제한도, 양자화되거나 증류된 파생물이 해당 조건을 상속하는지에 대한 모호함도 없습니다. LFM Open License v1.0은 Liquid의 자체 설명에 따르면 연간 매출 1,000만 달러 미만이면 상업적 사용이 무료이며, 이는 그 기준을 넘는 기업이 출시한 뒤가 아니라 출시하기 전에 라이선스 논의를 하게 된다는 뜻입니다.

그 단 하나의 조항이 많은 구매자에게 비교 구도를 뒤바꿔 놓습니다. 임계값 미만의 스타트업은 그라운딩 관련 문서화가 더 잘 된, 더 작고 더 빠른 모델을 무료로 얻습니다. 임계값을 넘는 기업은 서명이 필요한 모델을 얻게 되는데, 바로 그 시점에서 35B의 Apache 2.0은 주목하게 되는 기능이 됩니다.

어느 공급업체도 말해 주지 않는 것

독립적인 직접 비교는 존재하지 않습니다. 어떤 제3자 연구소도 두 모델을 동일한 하네스에서 실행한 적이 없으며, 중립적인 스코어보드에 가장 가까운 것 — Liquid 자체 표 — 은 LFM3-VL-2B를 35B가 아니라 1B와 비교합니다. 이 글의 모든 수치는 설명 대상 모델을 만든 연구소에서 나온 것입니다.

또 다른 두 가지 격차도 언급할 가치가 있습니다. 두 모델 모두 검증할 수 있는 토큰당 가격이 없으므로 여기서 비용을 비교한다면 이는 지어낸 것이 될 것입니다. 그리고 2026년 10월 28일 기준으로 둘 다 OrcaRouter 카탈로그에 없습니다. minicpm을 검색해도 일치하는 모델이 나오지 않으며 LFM3-VL-2B도 목록에 없습니다. 따라서 현재 이는 라우팅 결정이 아니라 자체 호스팅 또는 벤더 API 결정입니다.

어느 걸 고를까?

• 문서, 차트, 빽빽한 텍스트, 어려운 멀티모달 추론을 직접 제어하는 서빙 스택과 함께 — MiniCPM-V 4.7 35B-A3B. MMMU 격차는 하네스의 주의 사항을 견뎌낼 만큼 충분히 큰 유일한 결과이며, Apache 2.0은 라이선스 문제를 완전히 해소합니다.

• 통제할 수 없는 기기, 고정된 메모리 예산에 스트리밍 지연을 허용할 여유도 없는 환경 — LFM3-VL-2B. 3.8GB에 상주하며, 둘 중 grounding, GUI, 임바디드 수치가 공개되어 계획 수립에 활용할 수 있는 유일한 모델입니다.

• 화면 에이전트, 로보틱스, 공간 작업 — 기본적으로 LFM3-VL-2B를 사용합니다. 공개된 근거가 있는 쪽은 이쪽뿐이기 때문입니다. 35B는 해당 영역에서 성능이 약한 것이 아니라 아직 입증되지 않은 것으로 취급하십시오.

• 이번 달 최소한의 통합 작업으로 프로덕션 제공 — MiniCPM-V 4.7 35B-A3B. SGLang, vLLM, llama.cpp 및 Ollama 지원은 세 가지 "검토 중" 또는 "진행 중" 비고에 대응합니다.

• 연매출 1,000만 달러 초과 기업 — 단, 온디바이스 제약이 라이선스 논의를 정당화할 만큼 충분히 심각하지 않다면 MiniCPM-V 4.7 35B-A3B.

OrcaRouter가 어떻게 맞아떨어지는지, 솔직하게

아직은 맞지 않으며, 그렇지 않다고 말하는 것은 블로그 글이 무시당하게 만드는 전형적인 일이 될 것입니다. 현재 두 모델 모두 OrcaRouter 카탈로그에 없으므로, 건네드릴 키도 제시할 가격도 없습니다.

진실은 비전 모델이 실제로 그곳에 자리 잡을 때 벌어지는 일에 있습니다. 200개가 넘는 모델에 걸친 하나의 OpenAI 호환 엔드포인트, 공급자 정가를 0% 마크업으로 그대로 전달해 벤더 가격 변경이 같은 날 바로 반영되게 하는 것, 그리고 단일 공급자의 장애가 당신의 경로를 중단시키지 않도록 하는 자동 페일오버입니다. 이번과 같은 비교 — 메모리에 대해 서로 다른 주장을 하는 두 모델이 있고 이를 판정할 독립적인 벤치마크가 없는 경우 — 에 유용한 패턴은 어느 쪽 차트가 맞는지 논쟁하기보다 두 모델을 하나의 엔드포인트 뒤에서 실행하고 자신의 이미지로 측정하는 것입니다.

무엇을 볼까요?

이 글을 바꿀 네 가지가 있습니다. 비디오 지원과 함께 병합되는 풀 리퀘스트 31252는 LFM3-VL-2B의 비디오 경로를 표준 llama.cpp에 올리게 됩니다. vLLM 지원이 "진행 중" 상태를 벗어나는 것은 이를 데모가 아닌 진지한 서빙 옵션으로 만들어 줄 것입니다. 두 모델을 하나의 하네스에서 실행하는 독립 평가 — 이 비교에서 가장 가치 있는 누락 산출물입니다. 그리고 Liquid AI가 자체 비교표에 35B를 추가하는 것 — 이는 해당 랩이 35B를 진정한 동급 모델로 본다는 뜻입니다.

그중 어느 하나라도 실제로 실현되기 전까지, 방어 가능한 요약은 두 벤더 모두의 프레이밍보다 더 좁다: 35B는 중요한 추론 벤치마크에서 이기고 OCR에서는 아무것도 잃지 않으며, 2B는 그라운딩 근거와 예측 가능성에서 이기고, 라이선스는 벤치마크보다 더 많은 배포를 결정한다.