LFM3-1.7B vs Gemma 4 26B A4B: 저렴한 토큰을 위한 두 가지 레시피, 그리고 휴대폰에서 돌아가는 것은 단 하나

표면상 이 두 모델은 같은 문제에 같은 접근 방식을 취합니다. LFM3-1.7B는 2026년 10월 27일 Liquid AI가 발표했고, Gemma 4 26B A4B는 2026년 4월 2일 Google DeepMind가 공개했으며, 둘 다 한 가지 질문에 답하기 위해 존재합니다: 어떻게 하면 적은 메모리 예산 안에 유능한 모델을 넣을 수 있을까? 그런데 두 모델은 상반된 답을 내놓습니다. Liquid는 모델을 줄였습니다. Google은 모델을 크게 유지하고 토큰당 일부에 대해서만 비용을 지불합니다. 가중치는 무료이므로, 청구서는 가장 저렴한 유능한 호스트가 부과하는 금액입니다. 저희는 제공업체의 정가를 0% 마크업.

이 차이는 배포 비용을 산정하기 전까지는 아키텍처에 관한 사소한 이야기처럼 들리지만, 비용을 산정하는 순간 그것이 유일하게 중요한 것이 된다. Gemma 4 26B A4B는 토큰당 38억 개의 파라미터를 활성화하지만, 그 252억 개 전부를 어딘가에 저장해 두어야 한다. LFM3-1.7B는 17.3억 개의 파라미터를 전부 활성화하고 정확히 그만큼만 저장한다. 하나는 연산이 저렴하다. 다른 하나는 보유.

저렴한 토큰을 위한 두 가지 레시피

Gemma 4 26B A4B는 전문가 혼합(mixture-of-experts) 모델입니다. 128개의 라우팅된 전문가와 1개의 공유 전문가, 30개 레이어로 구성되며, 토큰당 대략 8개의 전문가가 활성화됩니다. 이를 통해 25.2B 밀집 모델에 맞먹는 지식 용량과 4B에 더 가까운 연산 비용을 갖습니다. 구글의 자체 설명에 따르면, 이 모델은 약 12%의 FLOPs로 밀집 Gemma 4 31B의 MMLU-Pro 점수의 약 97%를 달성합니다.

LFM3-1.7B는 다른 길을 택한다. 완전한 dense 구조로, 모든 매개변수가 모든 토큰에서 실행되며, 절감 효과는 희소성보다는 재설계된 아키텍처에서 나온다. Liquid의 tri-hybrid 스택은 24개 레이어로 구성된다. 13개의 gated short convolution, 5개의 sliding-window attention 레이어, 6개의 full-attention 레이어다. 시퀀스 모델링의 대부분은 비용이 저렴한 convolution이 수행하고, full attention은 단 여섯 번만 등장한다. 이것이 1.73B 모델이 KV 캐시가 머신을 잡아먹지 않으면서도 262,144토큰 컨텍스트와 128,000토큰 어휘를 운용하는 방식이다.

• 총 매개변수 — LFM3-1.7B의 경우 1.73B, Gemma 4 26B A4B의 경우 25.2B입니다.

• 토큰당 활성 — 1.73B 대 약 3.8B. 두 수치가 같은 급에 속하는 유일한 행입니다.

• 4비트 메모리 — 약 1GB 대 약 18GB. 배포 여부를 결정짓는 항목입니다.

• 컨텍스트 — 양쪽 모두 262,144 토큰으로, 다시 한 번 진정한 동점입니다.

• 모달리티 — 텍스트 및 이미지 입력에 대해 텍스트만 출력하며, 네이티브 함수 호출과 설정 가능한 사고 모드를 지원합니다.

• 라이선스 — LFM Open License v1.0, 연간 매출 1,000만 달러 미만이면 무료; Gemma 4 26B A4B의 경우 임계값 없이 Apache 2.0.

왜 3.8B active가 3.8B의 메모리를 의미하지 않는가?

전문가 혼합(MoE) 사양서를 읽을 때 가장 흔히 하는 실수이므로, 분명히 말할 가치가 있습니다. 활성 파라미터는 연산을, 느슨하게 말하면 속도를 좌우합니다. 다운로드하는 파일의 크기나 예약하는 VRAM의 크기를 좌우하지는 않습니다. Gemma 4 26B A4B는 전문가 간 라우팅을 위해 전체 252억 개 파라미터가 상주해야 하며, 4비트에서는 약 18GB에 해당합니다. 단일 24GB 카드에서 서빙할 수 있고, Google은 이를 실용적으로 만들기 위해 FP8 및 NVFP4 빌드를 제공하지만, 휴대폰에 넣을 수는 없습니다.

LFM3-1.7B은 4비트에서 약 1GB입니다. Liquid의 카드에는 휴대폰이나 노트북에 들어간다고 되어 있는데, 그 정도 크기라면 이 주장은 마케팅이 아니라 신뢰할 만합니다. 또한 128K 토큰에서 1.6GB의 KV 캐시를 유지하는데, 이 수치가 바로 동시에 몇 개의 긴 컨텍스트 요청을 감당할 수 있는지를 실제로 결정합니다.

실질적인 결과: 26B-A4B 배포는 추론 서버에 관한 결정이고, 1.7B 배포는 애플리케이션 출시에 관한 결정이다. 이 둘은 서로 다른 팀과 서로 다른 비용 구조를 가진 서로 다른 프로젝트이며, 어떤 벤치마크도 그 사이의 격차를 메우지 못한다.

각 공급업체가 게시한 내용과 그것이 알려주는 것

Google은 Gemma 4 26B A4B에 대한 광범위한 표를 공개했습니다: MMLU-Pro에서 82.6, GPQA Diamond에서 82.3, 도구 없이 AIME 2026에서 88.3, LiveCodeBench v6에서 77.1, Codeforces Elo 1718, MMMU-Pro에서 73.8, 그리고 128K에서 8개의 needle을 사용한 MRCR v2에서 44.1입니다. 모두 공급업체가 보고한 수치이며, 독립적으로 재현된 것은 없습니다. 제3자 추적에 따르면 LMArena Elo는 1438에 가깝습니다.

Liquid는 LFM3-1.7B에 대해 더 좁은 범위의 표를 공개했으며, 이는 에이전틱 작업 쪽으로 치우쳐 있습니다: BFCL V4에서 71.39, ToolSandbox에서 80.36, τ³-bench에서 68.01, LiveClaw에서 45.60, WebArena-Verified에서 38.42입니다. 또한 IFEval에서 96.66, IFBench에서 73.03, GPQA Diamond에서 63.37, LiveCodeBench v6에서 73.46, 128K에서 RULER 65.56을 보고합니다. Liquid는 LFM3-1.7B에 대한 MMLU-Pro 수치를 공개하지 않았으며, 그 부재는 0이 아닙니다 — 단순히 측정되지 않았을 뿐입니다.

LiveCodeBench v6와 GPQA Diamond만 깔끔하게 겹칩니다. Gemma 4 26B A4B가 각각 3.6점, 18.9점 차로 둘 다 이깁니다. Liquid의 스위트가 에이전틱으로 바뀌는 부분에서는 비교할 Gemma 수치가 없습니다 — Google은 τ²-bench를 68.2로 보고하는데, τ²는 τ³가 아니므로 68.01을 그 옆에 놓는 것은 신중한 비교인 척 꾸민 조작된 비교가 될 것입니다.

1.7B가 대화에서 머무는 곳

3.6포인트의 LiveCodeBench 격차는 14대 1의 파라미터 비율이 예측할 것보다 작으며, 그 이유는 아키텍처에 있습니다. 경쟁 프로그래밍은 패턴을 유지하고 올바른 함수를 내놓는 능력을 보상합니다 — 이 능력은 원시 용량보다 깔끔한 학습 신호에서 더 많은 이점을 얻습니다. 코딩 문제가 전체 작업이었다면 26B가 이겼을 것이고 이 섹션은 짧았을 것입니다.

LFM3-1.7B가 실제로 경쟁력을 유지하게 하는 것은 262,144토큰 컨텍스트와 1GB 풋프린트의 조합이다. 큰 문서를 담고 그것을 읽는 기기에서 실행할 수 있는 모델은, 같은 문서를 서버에서 담을 수 있는 모델과는 다른 제품이다. Liquid는 128K에서 RULER 65.56을 보고하는데, 이는 대단한 장문맥 점수는 아니다 — Gemma 4 26B A4B는 같은 벤치마크 계열에서 81.4를 보고한다 — 하지만 적어도 온디바이스에서, 1GB로 측정되기는 한다.

그리고 명령 수행 측면에서 이 소형 모델은 부끄럽지 않다. IFEval에서 96.66, IFBench에서 73.03은 이 크기 등급에서 강력한 수치이며, 둘 다 벤더가 보고한 값이다. 도구 호출이나 구조화된 출력 워크로드의 경우, 그 지표가 GPQA Diamond보다 실제로 중요한 지표에 더 가깝다.

라우팅 계층이 실제로 바꾸는 것

Gemma 4 26B A4B가 OrcaRouter 카탈로그에 올라왔습니다 — 하나의 API 키로 이 모델과 200개 이상의 다른 모델에 접근할 수 있으며, 공급자 정가가 0% 마크업으로 그대로 적용되므로 공급업체의 가격 변경이 재가격 책정 주기를 기다리지 않고 당일 반영됩니다. 이 점은 여기서 평소보다 더 중요합니다. 이 모델의 경제성은 전적으로 공급자 가격 책정에 달려 있기 때문입니다. 가중치는 무료이므로 청구서는 가장 저렴한 역량 있는 호스트가 부과하는 금액이며, 그 금액은 변합니다.

자동 페일오버는 나머지 절반입니다. 256K 컨텍스트를 갖춘 26B 전문가 혼합(mixture-of-experts) 모델은 피크 시 용량 한계에 부딪히는 바로 그런 워크로드이며, 제공자 전반에 걸친 라우팅은 단일 호스트의 안 좋은 오후가 곧 당신의 서비스 중단이 되지 않음을 의미합니다. LFM3-1.7B에는 이런 것이 전혀 필요하지 않습니다. 당신이 통제하는 하드웨어에서 실행되며 장애 조치해 나올 제공자가 없기 때문입니다. 이는 그것에 유리한 점도 불리한 점도 아닙니다 — 다른 레시피를 선택한 결과일 뿐입니다.

우리 역할을 솔직하게 말하면: 우리는 큰 희소 모델을 라우팅하며, 작은 밀집 모델을 서빙하지 않습니다. 그리고 둘 사이의 선택은 라우터가 대신 내려줄 수 있는 결정이 아닙니다.

한 번에 결정하기

배포 대상의 메모리가 20GB 미만이라면 — 휴대폰, 노트북, Jetson, AI PC — Gemma 4 26B A4B는 후보가 아니며 비교는 끝이다. LFM3-1.7B를 선택하고, Liquid 자체가 지적하는 지식 격차를 중심으로 검색을 계획하라. 그리고 수치가 실제로 경쟁력 있는 도구 호출과 구조화 추출에 사용하라.

GPU에서 서빙하고 있고 워크로드가 지식 집약적이거나 멀티모달이거나 82.3 GPQA Diamond와 82.6 MMLU-Pro 수준의 추론을 필요로 한다면, Gemma 4 26B A4B가 더 나은 모델이며 18 GB는 입장료입니다. Apache 2.0은 라이선스 논의를 완전히 없애주는데, 대규모 조직에서는 이것이 벤치마크 몇 점보다 더 가치 있습니다.

양쪽 모두에 제품을 출시한다면 — 다시 말해 온디바이스 어시스턴트가 어려운 쿼리를 서버로 에스컬레이션하는 구조라면 — 이 둘은 전혀 경쟁 관계가 아닙니다. 이들은 하나의 아키텍처를 이루는 두 계층이며, 흥미로운 엔지니어링 질문은 어느 모델이 표에서 이기느냐가 아니라 에스컬레이션 경계선을 어디에 그을 것이냐입니다.

미해결 질문은 역량이 아니다. 역량은 구글 쪽으로 결론이 났다. 문제는 1GB 모델이 256K 컨텍스트를 갖고 대부분의 온디바이스 제품이 실제로 필요로 하는 좁은 에이전트 작업에 충분히 좋은가이다. Liquid 자체의 모델 카드는 이것이 추론 모델이 아니라는 점을 이례적으로 솔직하게 밝힌다. 그 솔직함은 LiveCodeBench 격차보다 더 가치 있다. 왜냐하면 워크로드의 어느 절반을 어디로 보내야 하는지 알려주기 때문이다.