파라미터 1.73B, 4비트 가중치 약 1GB인 모델이 BFCL V4에서 71.39를 받았습니다. 같은 카드에서 Qwen3.5-9B는 62.83, Qwen3.5-4B는 55.12입니다. Liquid AI가 LFM3 계열을 내놓으면서 공개한 텍스트 모델 LFM3-1.7B의 이야기입니다.

숫자만 보면 "작은 모델이 큰 모델을 이긴다"로 끝나지만, 같은 카드의 다른 줄을 보면 그렇지 않습니다. 이 글은 모델 카드의 벤치마크 표를 직접 세어 보고, 어떤 업무에 붙일 만하고 어떤 업무에는 붙이면 안 되는지를 정리합니다. 브리핑 기준 발표일은 10월 27일이고 확인은 10월 28일입니다. 모델 카드 자체에는 날짜가 적혀 있지 않습니다.

71.39가 측정된 조건

카드에 적힌 BFCL V4 조건은 다음과 같습니다.

항목 값
서빙 vLLM, BF16, 전체 컨텍스트
디코딩 greedy, 최대 출력 32,768 토큰
비교 모델 Qwen3.5-4B (55.12), Qwen3.5-9B (62.83)
평가 주체 Liquid AI 자체 평가
독립 재현 확인하지 못함

주의할 점이 둘 있습니다. 첫째, 카드의 일반 권장 샘플링은 temperature 0.1, top_k 50, repetition_penalty 1.1인데 BFCL은 greedy로 돌렸습니다. 내 서비스에서 권장 설정으로 돌리면 같은 점수가 나온다는 보장이 없습니다. 둘째, 4비트로 양자화한 1GB 버전의 점수는 카드에 없습니다. BF16에서 잰 점수를 1GB 양자화 모델의 점수처럼 읽으면 안 됩니다.

표 26줄을 세어 보면

카드에는 LFM3-1.7B, Qwen3.5-4B, Qwen3.5-9B를 비교한 26개 벤치마크가 있습니다. 카드 값을 옮겨 적어 승패를 센 결과입니다(재집계 스크립트와 출력은 저장소의 docs/editorial-evidence/2026-10-28-lfm3/에 있습니다. 숫자는 Liquid AI 값을 그대로 옮긴 것이고 제가 다시 측정한 것이 아닙니다).

묶음 줄 수 9B 상회 4B 상회
에이전트(LiveClaw, WebArena, AutomationBench 등) 7 4 7
도구 호출(BFCL, ToolSandbox, MCP-Atlas, τ³) 4 3 3
코딩(SWE-bench, Terminal-Bench, LiveCodeBench 등) 6 1 4
지시 따르기(IFEval, IFBench, IFStruct, Multi-IF) 4 4 4
지식·추론(GPQA, HLE, AA-LCR, RULER) 5 0 2
합계 26 12 20

9B보다 앞선 곳은 지시 따르기 전부와 도구 호출 대부분입니다. 반대로 지식·추론은 5줄 모두 9B에 집니다. GPQA Diamond는 63.37 대 80.40, RULER 128K는 65.56 대 87.11입니다. 컨텍스트 창이 256K라고 해서 긴 문서에서 정보를 잘 찾는다는 뜻은 아닙니다. 128K 지점의 RULER가 4B(84.63)보다도 낮습니다.

도구 호출 안에서도 갈립니다. MCP-Atlas는 32.57로 4B(41.37)와 9B(42.67) 모두에 집니다. 이 벤치마크는 최대 256턴까지 긴 도구 사용을 보기 때문에, 짧은 단발 호출에 강하다는 사실과 긴 도구 체인을 견딘다는 사실은 따로 봐야 합니다. 카드도 에이전트 코딩과 복잡한 다단계 추론에는 작은 크기 때문에 권장하지 않는다고 적었습니다.

도구 호출 형식

LFM3는 ChatML 템플릿을 쓰고, 도구 호출을 JSON이 아닌 XML 형태로 내놓습니다. 카드의 예시는 이렇습니다.

<tool_call>
<function=get_weather>
<parameter=city>
Paris
</parameter>
</function>
</tool_call>

카드에는 apply_chat_template()에 tools=를 넘기고, 인자는 JSON 문자열이 아니라 매핑으로 전달해야 한다는 안내가 있습니다. 추론(<think>)은 기본으로 켜져 있고 enable_thinking=False로 끌 수 있지만 카드 스스로 이 설정이 일관되지 않을 수 있다고 적었습니다. 지연시간을 재려면 추론 켬/끔을 나눠서 재야 합니다.

아래는 이 XML을 파싱하고 스키마로 검사하는 최소 예제입니다. 입력은 제가 손으로 쓴 문자열 5개이고, LFM3는 실행하지 않았습니다. 파서와 검사 로직만 실제로 실행했습니다.

import re
SCHEMA = {"get_weather": {"required": {"city"}, "allowed": {"city", "unit"}}}

def parse(text):
    m = re.search(r"<tool_call>\s*<function=([\w.-]+)>(.*?)</function>\s*</tool_call>", text, re.S)
    if not m: return None
    args = dict(re.findall(r"<parameter=([\w.-]+)>\s*(.*?)\s*</parameter>", m.group(2), re.S))
    return m.group(1), args

def check(text):
    p = parse(text)
    if p is None: return "unparseable"
    name, args = p
    s = SCHEMA.get(name)
    if s is None: return "unknown_tool"
    if not s["required"] <= args.keys(): return "missing_required"
    if not args.keys() <= s["allowed"]: return "unexpected_key"
    return "ok"

ok ('get_weather', {'city': 'Paris'})
missing_required ('get_weather', {'location': 'Paris'})
unknown_tool ('search_web', {'q': 'x'})
unparseable None
ok ('get_weather', {'city': 'Busan'})

마지막 줄을 보세요. 파리를 물어야 하는 자리에 부산이 들어가도 검사는 ok입니다. 형식 검증은 값의 정확성을 보장하지 않습니다. vLLM 제약 디코딩 사례에서 다룬 것처럼 스키마 준수율, 도구 선택, 인자 값 정확도는 따로 재야 합니다.

붙여 볼 만한 업무, 피할 업무

카드의 표와 권장 사항을 함께 읽으면 판단 기준이 나옵니다.

  • 맞는 업무: 고객 문의 분류, 정해진 몇 개 도구 중 하나 고르기, 출력 형식이 엄격한 구조화 추출. 지시 따르기 4개 벤치마크를 모두 9B 이상으로 통과한 영역입니다.
  • 조건부: 짧은 에이전트 루프. LiveClaw, AutomationBench는 강하지만 BrowseComp-Plus, EnterpriseOps-Gym은 9B에 근소하게 집니다. 내 업무 길이에서 직접 재야 합니다.
  • 피할 업무: 저장소 단위 코딩(SWE-bench Verified 43.40 대 51.20, Terminal-Bench 2.1 12.92 대 17.98), 박식함이 필요한 질의응답, 긴 문서 검색. 카드가 지식 업무에는 검색을 붙이라고 권하는 것과 같은 방향입니다.

도입 전 측정 항목은 네 가지면 충분합니다. 내 도구 정의로 만든 100건 안팎의 라벨 데이터에서 (1) 파싱 성공률, (2) 도구 선택 정확도, (3) 인자 값 정확도, (4) 양자화 버전과 BF16의 점수 차이입니다. 여기에 추론 켬/끔 지연시간을 기기별로 붙입니다.

읽을 때 남는 한계

  • 모든 수치는 Liquid AI의 자체 평가이고, 제가 모델을 내려받아 돌려 본 것은 없습니다.
  • 카드의 속도 주장(llama.cpp Q4_0, 32K 컨텍스트에서 비교 모델보다 프리필 2.5배·디코딩 1.8배 이상)은 세 기기에서의 값이며 기기 이름과 원자료는 이 글에서 확인하지 않았습니다.
  • 브리핑에는 텍스트·비전·오디오·Omni·Decision 모델이 나왔다고 되어 있는데, 저는 모델 목록에서 텍스트, VL, Audio, Omni(GGUF)를 확인했고 Decision 모델은 확인하지 못했습니다.
  • 라이선스는 LFM Open License v1.0이라 상용 조건을 도입 전에 직접 읽어야 합니다.

정리

LFM3-1.7B는 "지시를 정확히 따르고 도구를 고르는" 좁은 업무에 1GB급 모델을 쓰려는 팀에게 후보가 됩니다. 반대로 지식·코딩·긴 컨텍스트 검색에서는 9B 모델에 일관되게 집니다. 71.39라는 숫자는 BF16, vLLM, greedy 조건의 값이므로, 내 데이터와 내 양자화 설정에서 다시 재는 데서 도입 검토가 시작됩니다.

글 끝의 유료 홍보 링크는 에이전트를 하네스·루프·그래프로 설계하는 강의입니다. LFM3나 온디바이스 모델을 다루는 강의가 아닙니다.

함께 읽으면 좋은 글

참고 자료