LFM3-1.7B vs Granite 4.2 30B: 축에 따라 평가가 갈리는 두 에이전트 모델

같은 페이지에 놓으면 LFM3-1.7B와 Granite 4.2 30B의 종합 평균은 어느 행을 읽느냐에 따라 서로 반대 방향을 가리킵니다. Berkeley Function Calling Leaderboard V4에서 Liquid AI의 17억 3천만 개 매개변수 모델은 IBM의 61.39점 대비 71.39점을 기록했습니다 — 약 17배 더 작은 모델이 10점 앞선 것입니다. SWE-bench Verified에서는 Granite가 LFM3-1.7B의 43.40점 대비 57.00점을 기록하며 반대 방향으로 13.6점 우위를 보였습니다.라우팅은 공급자의 정가에 마진을 추가하지 않습니다. 공급자의 정가는 0% 마크업으로 전달됩니다.

두 모델 모두 에이전트용으로 만들어졌고, 둘 다 2026년에 서로 두 달 이내로 출시되었으며, 두 벤더 모두 겹치는 벤치마크를 충분히 공개해 콜라주식 나열이 아닌 실제 비교가 가능하다. 그래서 이번 맞대결은 어느 모델이 더 나은지가 아니라 여러분의 워크로드가 실제로 어느 축에 놓여 있는지가 흥미로운 질문이 되는 드문 사례다. BFCL 71점과 SWE-bench 57점을 동시에 요구하는 작업은 거의 없으며, 그런 작업은 어느 한 모델만으로는 제대로 처리되지 않는다.

교차하는 두 숫자

Granite 4.2 30B는 2026년 8월 25일 Apache 2.0 라이선스로 출시되었으며, Granite 4.1 30B 기반 위에 구축되어 약 15조 토큰으로 학습된 약 300억 파라미터 규모의 dense 모델입니다. IBM의 포지셔닝은 엔터프라이즈로, 구성 가능한 세 가지 사고 모드, OpenAI 스키마 기반의 네이티브 도구 호출, 12개 테스트 언어, 그리고 다단계 GRPO 강화학습으로 마무리되는 3단계 학습 파이프라인을 갖추고 있습니다.

LFM3-1.7B는 두 달 후인 2026년 10월 27일 발표되며 등장했으며, 에이전틱 하네스에 특화해 포스트트레이닝되었다. Liquid는 모델 카드에서 Hermes Agent, PI, OpenClaw를 언급한다. 이 모델은 256K 컨텍스트를 갖춘 1.73B 덴스 모델이며, 일반 추론보다는 로컬 에이전트와 도구 호출용으로 명시적으로 포지셔닝되었다.

벤치마크에서의 교차는 약한 수치 하나 때문에 생긴 우연이 아니다. LFM3-1.7B의 공개된 전체 표는 에이전트 중심에 치우쳐 있다: 71.39 BFCL V4, 80.36 ToolSandbox, 68.01 τ³-bench, 45.60 LiveClaw, 38.42 WebArena-Verified. Granite의 표는 엔지니어링에 치우쳐 있다: 57.00 SWE-bench Verified, 33.29 SWE-bench Pro, 41.89 SWE-bench Multilingual, 38.76 SciCode, TerminalBench 2.1에서 29.24. 각 벤더는 "에이전트"에 대한 서로 다른 정의에 맞춰 최적화했고, 벤치마크 표는 그것이 무엇인지에 대해 정직하게 보여준다.

68.01 대 68.05에서의 τ³가 진짜 헤드라인이다

두 극적인 격차 아래에는 막상막하의 접전이 숨어 있습니다. 사용자 시뮬레이터와 도메인 정책으로 다중 턴 작업 완료를 측정하는 도구 사용 평가인 τ³-bench에서 LFM3-1.7B는 68.01점, Granite 4.2 30B는 68.05점을 기록했습니다. 이는 0.04점 차이로, 잡음과 구분할 수 없는 수준입니다.

그것은 두 큰 격차보다 더 흥미로운 결과입니다. 왜냐하면 τ³는 대부분의 에이전트 배포가 실제로 하는 일에 가장 가까운 벤치마크이기 때문입니다: 대화를 이어가고, 정책을 따르고, 올바른 함수를 호출하고, 실수에서 복구하는 것입니다. 1.73B 모델이 그 지점에서 30B dense 모델과 동등한 성적을 낸다면, 파라미터 수가 사고 있는 것은 유능한 멀티턴 도구 사용이 아닌 다른 무언가입니다.

그것으로 얻는 것은 서로 다른 것을 측정하는 BFCL과 SWE-bench에서 드러난다. BFCL V4는 스키마에 대한 단일 턴 함수 호출 정확성을 테스트하는데, LFM3-1.7B의 71.39는 실제 에이전트 하네스에 대한 Liquid의 포스트트레이닝이 직접적인 성과를 냈음을 시사한다. SWE-bench Verified는 실제 GitHub 이슈를 엔드투엔드로 수정하는 능력을 테스트하며, 이는 저장소를 컨텍스트에 유지하고, 여러 파일에 걸쳐 계획을 세우고, 테스트를 통과하는 패치를 생성하는 것을 요구한다. Granite의 57.00은 그렇게 할 수 있는 역량을 갖춘 모델과 이를 위해 구축된 훈련 세트를 반영한다.

그래서 구분이 명확하다. 도구 스키마에 잘 훈련된 소형 모델은 함수 호출 테스트에서 이긴다. 코드 수리에 훈련된 대형 모델은 저장소 테스트에서 이긴다. 둘 다 특별히 훈련된 멀티턴 중간 영역에서는 동점이다.

컨텍스트는 사양이 가장 크게 갈리는 지점이다.

• 컨텍스트 — LFM3-1.7B의 경우 262,144 토큰; Granite 4.2 30B는 128K 네이티브이며 512K까지 확장 가능. 확장은 무료가 아니며, IBM은 이것이 네이티브 윈도가 아닌 확장임을 솔직히 인정한다.

• 긴 문맥 유지 — 동일 벤치마크 계열에서 LFM3-1.7B는 128K에서 RULER 65.56인 반면 Granite 4.2 30B는 81.4입니다. 더 큰 모델이 긴 문서를 더 많이 유지하는데, 이는 대표 문맥 수치가 시사하는 것과 반대입니다.

• 풋프린트 — 약 30B의 BF16 가중치 대비 4비트에서 약 1GB이며, 공식 FP8, NVFP4, MXFP4 빌드를 제공합니다. 이는 단일 GPU 모델이며 노트북 모델이 아닙니다.

• 언어 — LFM3-1.7B는 16개, Granite는 테스트된 12개로, 서로 겹치는 언어가 다릅니다. Granite의 12개에는 체코어와 네덜란드어가 포함되고, Liquid의 12개에는 태국어, 베트남어, 인도네시아어가 포함됩니다.

• 사고 모드 — Granite 4.2 30B는 전체 사고, 저노력 사고, 사고 없음 모드를 제공합니다. LFM3-1.7B에는 그런 기능이 없으며, 해당 모델 카드에는 애초에 복잡한 다단계 추론용으로 의도된 것이 아니라고 명시되어 있습니다.

• 라이선스 — Granite의 경우 Apache 2.0이며, LFM Open License v1.0은 연매출 1,000만 달러 미만에서는 무료이고 그 이상에서는 상용 라이선스가 필요합니다.

30B dense는 어떤 비용을 치르지만 1.73B는 치르지 않는가?

Granite 4.2 30B는 dense 모델이므로, 300억 개의 파라미터 전부가 토큰마다 실행됩니다. 여기에는 활성 파라미터 할인 같은 것이 없습니다. 토큰당 연산 비용은 소형 모델의 약 17배이고, 메모리 비용은 전체 가중치 파일 분량입니다. IBM은 이를 감당 가능하게 만들기 위해 양자화 버전을 제공하지만, 휴대폰에서 실행되는 구성은 존재하지 않습니다.

LFM3-1.7B의 장점은 주로 속도가 아닙니다. 모델이 애플리케이션의 나머지 부분과 동일한 메모리 예산에 들어간다는 점입니다. 1GB 모델은 같은 기기에서 문서 저장소, 캐시, 두 번째 모델을 위한 공간을 남겨 두는데, 이것이 로컬 에이전트를 단지 이론적으로 로컬인 존재가 아니라 실제로 가능하게 만듭니다. Liquid는 테스트된 하드웨어에서 이전 제품보다 1.8~2.8배 빠른 디코딩과 128K에서 1.6GB KV 캐시를 보고했으며, 둘 다 긴 대화를 유지하는 온디바이스 에이전트에 중요합니다.

이에 대한 반론은 Granite의 30B 용량이 SWE-bench 수치에서 실제로 중요한 역할을 하고 있다는 점이다. 에이전트의 작업이 저장소 전반의 코드를 변경하는 것이라면, 13.6점 차이는 더 작은 모델이 프롬프팅으로 만회할 수 있는 격차가 아니며, 연산 비용 절감은 더 나쁜 결과를 사는 셈이다.

라이선싱, 서명, 그리고 조달 문제

Apache 2.0 덕분에 대규모 조직이 법무 검토 없이 Granite 4.2 30B를 도입할 수 있습니다. 매출 임계값도, 상업적 트리거도, 협상도 없습니다. IBM은 또한 2026년 4월부터 출시된 Granite 모델에 암호학적 서명을 적용해 왔는데, 이는 사소한 세부 사항처럼 들리지만 프로덕션의 가중치가 검증된 가중치임을 입증해야 하는 사람이 되면 이야기가 달라집니다.

Liquid의 LFM Open License v1.0은 스타트업 규모에서는 진정으로 관대합니다 — 연 매출 1,000만 달러 미만이면 상업적 사용이 무료입니다 — 하지만 그 기준을 넘으면 유상 상업 라이선스가 필요합니다. 개인 개발자나 소규모 팀에게는 문제가 되지 않습니다. 더 큰 회사 내부의 사업부라면 첫 배포 전부터 시작되는 논의이며 빠르게 끝나지 않을 수 있습니다. 이러한 비대칭성은 어떤 벤치마크에도 반영되지 않으며, 종종 그것만으로 결정을 좌우합니다.

둘 중 어느 쪽에도 걸지 않고 둘 다 실행하기

두 모델을 평가하는 팀을 위한 실용적인 패턴은 먼저 하나를 고르는 것이 아닙니다. 둘 다 오픈 웨이트이고 둘 다 독립 평가자에 의해 검증되지 않았으므로, 중요한 유일한 벤치마크는 여러분 자신의 것입니다. 후보 모델들을 단일 엔드포인트로 라우팅하고, 동일한 에이전트 트레이스를 두 모델 모두에 실행한 뒤, BFCL이나 SWE-bench가 아니라 여러분의 과제에서 비교하세요.

OrcaRouter는 여기서 호스트라기보다 제어 표면으로 유용합니다: 200개가 넘는 모델 전반에 걸친 하나의 키와 하나의 청구, 공급자 목록 가격은 0% 마크업으로 그대로 전달되며, 자동 페일오버가 있어 한 공급자가 잠깐 문제를 겪었다고 평가 실행이 중단되지 않습니다. LFM3-1.7B도 Granite 4.2 30B도 현재 저희 카탈로그에 없습니다 — 둘 다 오픈 웨이트 다운로드이며, 각각 셀프 호스팅이 경로입니다. 라우팅이 제 역할을 하는 지점은 주변 스택입니다: 에이전트가 상위로 전환하는 프런티어 모델, 또는 로컬 모델의 패치가 테스트를 통과하지 못할 때 비교해 보는 제2의 의견입니다.

누가 무엇을 수강해야

LFM3-1.7B를 선택하세요 에이전트가 사용자 기기에서 실행되고, 작업이 API에 대한 도구 호출 및 구조화된 추출이며, 1GB 풋프린트의 256K 컨텍스트가 제품을 가능하게 하는 요소라면 선택하세요. 에이전트형 코딩에는 적합하지 않다는 벤더의 경고를 받아들이고, 필요한 경우를 위해 그 뒤에 더 큰 모델을 유지하세요.

Granite 4.2 30B를 선택하세요: 에이전트가 코드베이스를 다루는 경우, 조달을 위해 Apache 2.0 및 서명된 가중치가 필요한 경우, 워크로드가 구성 가능한 사고 노력의 이점을 누리는 경우, 그리고 이를 서비스할 GPU가 있는 경우입니다. BFCL 격차는 실재하지만 좁습니다. 이는 단일 호출에서 스키마 정확성을 측정하며, 잘 설계된 도구 스키마를 갖춘 30B 모델은 실제로 그 격차의 상당 부분을 메웁니다.

분할 방식을 택하세요 두 벤더가 모두 겨냥하는 것을 구축 중이라면 — 1GB 환경에서 일상적인 도구 호출을 처리하고 저장소 규모 작업은 서버로 에스컬레이션하는 로컬 에이전트를. 그 아키텍처는 각 모델이 자체 벤치마크 표에서 강점이라고 말하는 부분에 해당 모델을 사용하며, 교차된 축이 더 이상 문제가 되지 않는 유일한 구성입니다.

주목할 만한 질문은 Liquid의 에이전트형 포스트 트레이닝 레시피가 더 큰 체크포인트로 전이되는지 여부다. 미래의 LFM 모델이 71.39급 BFCL 동작을 유지하면서 저장소 작업을 위한 용량을 더한다면, 축 분할은 무너지고 이 비교는 단순한 크기 결정이 된다. 그때까지 두 모델은 같은 작업을 두고 경쟁하는 것이 아니라, 하나의 두 반쪽이다.