vLLM에서 LFM3-1.7B: 9일이 지난 지금도 네이티브 지원은 여전히 열린 PR 두 개뿐

Liquid AI의 LFM3-1.7B은 2026년 10월 27일에 출시되었으며, 모델 카드에는 vllm serve "LiquidAI/LFM3-1.7B"가 마치 평범한 명령인 것처럼 적혀 있습니다. 9일이 지난 지금, 업스트림 vLLM에는 이를 실행할 Lfm3ForCausalLM 아키텍처가 없습니다. 대신 존재하는 것은 10월 30일에 열린 기능 요청, 다른 모든 것이 그 위에 쌓여 있는 커널 PR 하나, 그리고 열려 있는 모델 PR 여섯 개입니다. 그중 두 개는 동일한 LFM3-1.7B 텍스트 모델을 서로 다른 두 가지 방식으로 구현하고 있으며, 어느 것도 병합되지 않았습니다.

그 격차가 여기서 핵심이며, 그 폭은 좁습니다. 모델은 실재하고 다운로드할 수 있지만, 런타임 지원은 대기열에 있습니다. 이 글은 그 대기열에 관한 현황 정리입니다. 무엇이 진행 중인지, 오늘 실제로 무엇이 돌아가는지, 그리고 모델 카드의 "vLLM과 함께 작동"이 배포 계획이 요구하는 의미에서 사실이 되려면 무엇이 먼저 갖춰져야 하는지를 다룹니다.

카드에는 vLLM이라고 적혀 있습니다. 지원 모델 표에는 LFM2라고 나와 있습니다.

vLLM 자체 지원 모델 문서에는 Liquid AI 아키텍처 세 가지가 나열되어 있습니다: Lfm2ForCausalLM, Lfm2MoeForCausalLM, Lfm2VlForConditionalGeneration. LFM3 항목은 없습니다. 한편 LFM3-1.7B 카드에는 체크포인트가 "vLLM, SGLang 및 LFM3 호환 llama.cpp 빌드에서 작동한다"고 명시되어 있으며, 플래그가 전혀 붙지 않은 서빙 명령을 제시합니다.

체크포인트 자체의 구성에 해결의 실마리가 있습니다. LFM3-1.7B에는 번들로 포함된 modeling_lfm3.py를 가리키는 auto_map이 있어서 Hugging Face 측 코드가 존재하며, 원격 코드를 허용하는 로더에 스스로 복제됩니다. 이식 작업을 위한 vLLM의 추적 이슈 #64645 — "[Feature]: Support LiquidAI LFM3 models", 10월 30일 abhijithneilabraham이 개설 — 는 그 결과를 직설적으로 말합니다: "vLLM에는 Lfm3ForCausalLM이 없습니다." 여기에 나열된 대안은 이번 달 대부분의 사람들이 결국 사용하게 될 탈출구입니다: "Transformers 백엔드와 함께 체크포인트의 원격 코드를 통해 LFM3를 실행하세요. 그러면 paged attention과 conv 상태 캐시를 포기하게 됩니다."

그 맞교환은 분명히 짚고 넘어갈 가치가 있다. "vLLM에서 실행된다"와 "vLLM의 transformers 백엔드에서 실행된다"는 서로 다른 제품이기 때문이다. Paged attention은 vLLM이 KV 메모리를 낭비하지 않으면서 길이가 크게 다른 요청들을 배치할 수 있게 하는 메커니즘이고, conv state cache는 같은 아이디어를 이 아키텍처의 short-convolution 계층에 적용한 것이다. 둘 다 없애면, vLLM이 존재하는 두 가지 이유를 포기한 채 동작하는 엔드포인트만 남는다. 낮은 동시성으로 서빙되는 1.7B 모델이라면 그것은 허용 가능한 주말 작업일 수는 있어도 허용 가능한 프로덕션 형태는 아니다.

1.7B 모델에 왜 커널 작업이 필요할까

LFM3-1.7B는 vLLM이 이미 지원하는 LFM2 패밀리를 단순히 재조정한 모델이 아니다. 이는 두 가지가 아닌 세 가지 레이어 유형을 가진 24층 하이브리드다: 13개의 게이트형 단축 합성곱 레이어, 256토큰 윈도우를 가진 5개의 슬라이딩 윈도우 어텐션 레이어, 6개의 전체 어텐션 레이어. 체크포인트의 config는 이 구조를 명시한다 — conv_L_cache: 7, sliding_window: 256, 128K 어휘 — 그리고 vLLM 이슈 자체의 차이점 목록에는 QK RMSNorm, 헤드별 시그모이드 어텐션 출력 게이트, 샌드위치 정규화, 그리고 전체 어텐션 레이어에 부분 RoPE(partial_rotary_factor: 0.5)가 추가되며, Gemma 4가 사용하는 것과 동일한 제로 테일 형태로 배치된다.

포트를 망가뜨린 숫자는 7이다. LFM2의 짧은 합성곱은 탭 폭이 3이고, LFM3는 이를 7로 넓혔다. vLLM의 Triton causal_conv1d 커널은 고정된 너비 집합을 언롤하며, 추적 이슈는 이렇게 표현한다. "Triton causal_conv1d prefill 커널은 너비 2부터 4까지를, decode 커널은 2부터 6까지를 언롤하므로, 너비 7 모델은 현재 CUDA에서 실행할 수 없습니다."

그래서 스택의 첫 번째 PR은 모델이 전혀 아닙니다. abhijithneilabraham이 10월 30일에 연 #64647, "[Kernel] Support width-7 causal conv1d"는 두 파일을 수정하고 186줄을 추가합니다. 이 PR은 prefill 커널을 폭 2–4에서 2–7로, decode 커널을 2–6에서 2–7로 확장하며, 두 래퍼 모두 해당 범위를 벗어나는 값에 대해 ValueError를 발생시키도록 합니다. PR 설명 자체가 확장만큼이나 거부가 중요한 이유를 설명합니다. 변경 전에는 "더 넓은 가중치가 일치하는 분기 없이 실행되어 잘못된 값을 반환했습니다." 조용한 수치 손상은 거부보다 더 나쁜 실패이며, 이는 마침 시도해 본 모델에서만 드러나는 종류의 문제입니다.

그 PR과 함께 따라다녀야 할 유의점이 하나 있습니다. 작성자는 자신에게 CUDA 머신이 없다고 분명히 밝힙니다. CPU 참조 경로는 96개 테스트를 통과했고, Triton 커널은 커널 AST에 대한 정적 분석으로 검증되었으며, GPU 검증은 CI에 맡겨졌습니다. 그것은 결함이라기보다 정직한 공개이지만, 다른 모든 LFM3 PR이 의존하는 단 하나의 변경 사항이 대부분의 독자가 그것을 실행할 하드웨어에서 아직 실행 검증되지 않았다는 뜻입니다.

동일한 텍스트 모델의 두 가지 구현

6일 만에 두 개의 별도 그룹이 vLLM용 네이티브 LFM3 지원을 작성했습니다. 이들은 하나의 패치의 변형이 아니라, 우연히 동일한 아키텍처 이름으로 설치되는 독립적인 설계입니다.

PR #64959, "[Model] Add LiquidAI LFM3 (Lfm3ForCausalLM)"은 11월 1일 atmikshetty가 열었으며, 보수적인 쪽입니다: 파일 일곱 개로, 설명에 따르면 너비 7의 ShortConv, Lfm2MLP, LFM2 가중치 매퍼, 기존의 비례 RoPE를 재사용하고 핵심 구성 요소는 변경하지 않습니다. 모델을 레지스트리에 등록하고, 하이브리드 모델 테스트 세트와 지원 모델 표에 추가하며, — 실행해 보는 사람에게 유용하게도 — 검증에 사용한 서빙 플래그를 문서화합니다: --reasoning-parser qwen3 --tool-call-parser qwen3_coder --enable-auto-tool-choice. 검증 섹션에서는 A100-SXM4-40GB에서 BF16으로 324개의 커널 테스트 통과, 레지스트리 및 초기화 테스트 통과, Hugging Face 원격 코드 참조와의 로그 확률 비교를 보고합니다.

PR #65826, "[Model] Add LFM3-Text"는 11월 5일 Liquid AI 소속 paulpak58이 열었으며, 벤더 자체 버전입니다: 파일 10개와 829줄 추가, transformers_utils/configs/lfm3.py 아래의 자체 구성 클래스와 자체 테스트 모듈을 포함합니다. 이 PR은 "[Model] Add LFM3"로 열렸고, 같은 날 모델 제품군이 네 개의 스택형 PR로 분리되면서 제목이 변경되었습니다: 텍스트용 #65826, 비전-언어용 #65827, 오디오용 #65828, 옴니용 #65829이며, 각각은 바로 앞의 PR 위에 구축됩니다.

두 가지는 충돌이라기보다는 병행 관계에 가깝고, 이 논의는 의존성 그물망을 명확히 보여준다. 커널 PR에서 paulpak58은 11월 4일 이렇게 썼다. "LFM3 모델용 내부 PR은 따로 있지만, 이것은 우리가 지지할 수 있는 깔끔한 추가 사항입니다." 커뮤니티 텍스트 PR에서 abhijithneilabraham은 병합을 위해서는 Liquid의 transformers 작업이 먼저 병합되어야 할 수도 있다고 언급했다. "이 PR의 병합에는 @paulpak58의 transformers PR이 필요하다고 봅니다." 이에 atmikshetty는 Lfm3Config가 아직 transformers 릴리스에 포함되지 않았기 때문에 해당 브랜치는 "체크포인트에서 trust_remote_code를 통해 config를 로드하고, 실행은 네이티브 vLLM 모델을 사용한다"고 답했다. 이것이 대부분의 독자가 미처 생각하지 못한 두 번째 관문이다. 즉, vLLM PR이 병합되더라도 어딘가에서 함께 배포되는 config 클래스가 필요하다.

transformers 쪽에서 해당하는 PR은 11월 3일에 열렸고 아직 열려 있는 #50322, "[Model] LFM3 Family: LFM3-Text"이며, 더 큰 family PR에서 분리된 것입니다. 컨볼루션에 관한 해당 PR 자체의 노트는 vLLM 이슈와 일치합니다: short conv는 "LFM3에서 torch-only입니다(Hub causal_conv1d 커널은 너비 2-4를 지원하고, LFM3은 7을 사용합니다)"입니다.

비전-언어 쪽도 중복 작업이 진행되고 있습니다. Liquid의 #65827 외에도, 독립적인 LFM3-VL PR(#65450, 11월 3일 개설)이 여전히 열려 있으며 커뮤니티 텍스트 PR에 의존하고 있습니다. 따라서 오늘 기준으로 두 진영에 걸쳐 열린 LFM3 PR은 6개이고, 병합된 PR은 하나도 없습니다.

오늘 실제로 운영되는 것은 무엇인가

추측을 걷어내면 11월 5일의 실제 상황은 이렇습니다.

• vLLM, 네이티브 — 기본 빌드에서는 불가능합니다. 레지스트리에 Lfm3ForCausalLM이 없고, 지원 모델 표에 LFM3 행도 없으며, 이를 추가하는 PR은 아직 병합되지 않았습니다.

• vLLM, transformers 백엔드 — 문서화된 우회 방법으로, 체크포인트에 번들로 포함된 원격 코드와 trust_remote_code를 사용합니다. 페이지드 어텐션과 conv 상태 캐시는 잃지만, OpenAI 호환 서버는 유지합니다.

• SGLang — 벤더 자체의 서버 경로입니다. Liquid의 출시 게시물은 SGLang을 사용해 단일 NVIDIA B300에서 BF16으로 처리량 수치를 측정하며, 1,024개의 동시 요청에서 하루 36억 토큰을 처리하는 수치도 포함합니다. vLLM은 해당 게시물에서 경쟁 모델들을 서비스하던 런타임으로만 등장합니다.

• llama.cpp — 이 카드가 "LFM3 호환 llama.cpp 빌드"를 언급하는 것은 상투적인 문구가 아니라 실제 한정 조건입니다. Liquid의 온디바이스 수치는 32K 컨텍스트에서 Q4_0로 실행한 llama.cpp 기준입니다.

• MLX — 별도의 vLLM-Metal 프로젝트의 0.33.0 릴리스 노트에는 --trust-remote-code를 활성화해야 하는 LFM3 텍스트 MLX 체크포인트가 나열되어 있습니다. 이는 업스트림 vLLM과 다른 코드베이스이며 CUDA 지원을 의미하지 않습니다.

• Hosted — Liquid 자체 API와 플레이그라운드입니다. 카드에는 요금표가 없어서, 공개 자료만으로는 토큰당 비용을 예산에 반영할 수 없습니다.

두 숫자를 보면 셀프 호스팅의 상황이 분명해집니다. 가중치는 메모리가 제약이 되지 않을 만큼 작고—Liquid는 4비트에서 약 1GB라고 주장합니다—벤더에 따르면 128K 토큰 컨텍스트에는 약 1.6GB의 KV 캐시가 듭니다. 제약은 GPU가 아니라 서빙 스택입니다.

이것을 바꾸려면 무엇이, 어떤 순서로 바뀌어야 할까요?

의존성 체인은 유난히 깔끔해서, 지켜볼 만한 대상이 유난히 구체적이 된다. 먼저 #64647이 병합되어야 한다. 다른 모든 LFM3 PR이 해당 커밋을 포함하거나 그 위에 쌓여 있기 때문이다. 그다음 두 텍스트 PR 중 하나가 리뷰에서 이겨야 한다 — 커뮤니티 쪽은 검증 기록이 더 완전하고, Liquid 쪽은 transformers 쪽도 맡고 있는 작성자가 있다. 그다음 Lfm3Config가 transformers 릴리스에 포함되어야 한다. 그렇지 않으면 모든 배포가 계속 trust_remote_code를 넘겨야 한다. 그 후에야 LFM3-VL-2B, LFM3-Audio-2B, LFM3-Omni-2B가 현실성을 갖게 되며, 이들은 텍스트 모델이 이미 들어와 있다고 가정하는 추가 PR들 뒤에 있다.

이 중 어느 것도 속도에 대한 비판으로 읽혀서는 안 됩니다. 출시부터 완전하고 테스트를 마친 커널+모델 PR 스택까지 9일은 빠른 편이며, 두 개의 독립 팀이 일주일 안에 작동하는 구현을 만들어냈다는 사실은 어떤 지연에 대한 것이라기보다 LFM3가 LFM2에 얼마나 가까이 있는지를 더 잘 말해 줍니다. 하지만 모델 카드는 호환성 주장이며, LFM3-1.7B의 현재를 정직하게 읽으면 "transformers 백엔드를 통해 vLLM과 호환됨"이지 "vLLM에서 지원됨"이 아닙니다.

이번 주에 작은 도구 호출 모델이 필요하다면

LFM3-1.7B는 갖고 싶어지는 매력적인 모델이다. 공급업체가 보고한 수치는 소형 모델이 보통 실패하는 바로 그 지점에서 강하다 — BFCL V4에서 71.39, ToolSandbox에서 80.36, IFEval에서 96.66, SWE-bench Verified에서 43.40 — 이는 Liquid가 자사 LFM2.5-2.6B의 31.55보다 앞선다고 평가하는 전체 평균 49.37과 비교된다. 이는 모델을 만든 회사가 직접 실행한 공급업체 자체 평가이며, 독립적 재현도, 오늘 기준으로 우리가 찾을 수 있는 Artificial Analysis 등재 항목도 없다. 따라서 순위는 가설로, 개별 수치는 주장으로 다뤄야 한다. 함께 제공되는 주의사항도 같은 출처에서 나온다. 모델 카드는 에이전트형 코딩과 복잡한 다단계 추론을 권장하지 않으며, 지식 벤치마크도 이 조언에 동의한다 — GPQA Diamond에서 63.37, 128K에서 RULER 65.56은 범용 모델의 수치가 아니다.

그래서 결정은 사실 모델에 관한 게 아닙니다. 문제는 현재 열려 있는 풀 리퀘스트인 서빙 경로 위에 구축할 여유가 있느냐입니다. SGLang이나 llama.cpp를 실행할 수 있다면 오늘 LFM3-1.7B를 사용할 수 있고, vLLM 문제는 논외가 됩니다. 정책상 스택이 vLLM이라면, transformers 백엔드의 빠진 페이지드 어텐션과 기다림 중에서 선택해야 합니다.

기다릴 수 없는 워크로드에 대해 언급할 가치가 있는 세 번째 선택지가 있습니다: 다른 무언가를 라우팅하는 것입니다. OrcaRouter는 LFM3-1.7B를 제공하지 않습니다 — 오늘 저희 카탈로그를 확인해 보면 200개가 넘는 모델 ID가 반환되며 그중 Liquid의 것은 없습니다 — 따라서 이것은 저희를 통해 호출하라는 영업 제안이 아닙니다. 더 단순한 요점은 병합되지 않은 커널 PR이 프로덕션 경로에 있어 나쁜 단일 장애점이라는 것입니다. 하나의 API와 자동 장애 조치로 호스팅 모델을 앞단에 두는 것은 설정 변경 하나만 들며, LFM3-1.7B의 네이티브 지원이 병합되는 날에, 그것에 대한 베팅을 마치는 날이 아니라, LFM3-1.7B로 교체해 넣을 수 있게 해줍니다. 모델을 단순히 호출하는 것이 아니라 수정하고 있다면, 저희 자체 LFM3-1.7B-abliterated 릴리스는 동일한 체크포인트의 거부 방향 절제(ablation)이며, 정확히 이 서빙 상황을 그대로 물려받습니다.

짧은 버전

LFM3-1.7B가 출시되었고, 작으며, 훈련된 단일 턴 도구 호출 작업에 잘 맞습니다. 이 모델의 vLLM 지원은 현재 두 팀에 의해 작성 중이며, 작성자 본인이 아직 CUDA에서 실행해 본 적 없는 커널 확장 위에 구현되고 있습니다. 먼저 #64647을 지켜보세요 — width-7 convolution이 병합되면 나머지 스택은 빠르게 진행되고, 모델 카드의 "works with vLLM"은 원격 코드에 대한 진술이기를 그치고 paged attention과 batching에 대한 진술이 되기 시작합니다. 그때까지 이 모델에 대해 "day-one vLLM support"를 인용하는 사람은 저장소에 아직 없는 내용을 인용하는 것입니다.