Liquid LFM3: 이 작업에는 어떤 소형 모델이 맞을까?

영수증을 읽는 로컬 어시스턴트에 음성 질문에 답하는 것과 같은 모델이 꼭 필요한 것은 아닙니다. 허용된 세 행동 중 하나를 고르는 프로그램은 또 다른 일을 합니다. 이를 한 작업으로 취급하면 작은 애플리케이션도 불필요하게 복잡해질 수 있습니다.

Liquid AI는 2026년 10월 27일 LFM3를 발표했습니다. 공유하는 17억 매개변수(1.7B) 기반에서 분기한 약 20억 매개변수(2B)급 모델 6종으로, 텍스트·시각·오디오·옴니와 두 의사결정 변형을 아우릅니다. 회사는 공개 가중치, Playground, API 접근을 제공합니다. LFM3 공지.

핵심은 애플리케이션에 어떤 역할이 필요한지 결정하는 것입니다. 이 글에서는 실제 선택 기준으로 제품군을 살펴보고, 작은 가중치 파일과 실행 시 메모리 예산을 구분하며, 전문 모델이 내 하드웨어에서 쓸 만한지 알아볼 첫 평가 방법을 제안합니다.

Raspberry Pi 5 하드웨어입니다. 엣지 컴퓨팅의 참고 이미지이며 LFM3 시험 사진이 아닙니다. 이미지: RetroEditor, CC BY 4.0. 여백을 추가하고 크기를 조정했습니다. 이미지 출처 · 라이선스·이미지 설명. 공식 제품 참고 자료.

전문 모델 선택은 필요한 출력에서 시작한다

지원 입력이 가장 많은 모델부터 고르면 선택을 그르치기 쉽습니다. 애플리케이션이 내놓아야 할 출력에서 출발하세요. 같은 원자료를 활용하더라도 문단 작성, 음성 전사, 구조화된 필드 추출, 허용된 행동 중 선택은 서로 다른 입출력 요건입니다.

Liquid의 10월 27일 발표는 네 모달리티 계열과 두 결정 모델을 소개합니다. LFM3-1.7B, LFM3-VL-2B, LFM3-Audio-2B, LFM3-Omni-2B, d1-2B, d1-Omni-2B입니다. 다음 표는 역할을 애플리케이션 선택 질문으로 바꿔 정리한 것으로, 독립적인 품질 순위가 아닙니다. 제품군 설명.

저희가 생각하는 로컬 AI의 유용한 단위는 완결된 최소 작업입니다. 모델은 명확한 애플리케이션 요건을 충족할 능력과 불확실성을 다룰 방법을 갖춰야 합니다. 그 이상에는 실행·테스트·연동 비용이 들므로 그만한 가치가 있어야 합니다.

제품군을 휴대용 공구 묶음처럼 생각해 보세요. 어떤 작업에는 모든 공구가 필요하지만, 반복되는 조정에는 알맞은 공구 하나를 고르는 편이 간단할 수 있습니다. 애플리케이션 설계에 관한 비유이며 한 모델이 언제나 다른 모델보다 우수하다는 뜻은 아닙니다.

Liquid AI의 LFM3 발표에 나온 역할을 묶은 자체 제작 설명 도표입니다. 앱의 선택지를 정리한 것이며 내부 구현 세부는 생략했습니다.

공개 가중치는 배포 선택지를 주지만 라이선스를 읽어야 한다

다운로드한 가중치는 개발자가 패키징하고 평가하고 적용할 구체적인 산출물입니다. 앱의 데이터 경로를 통제하는 로컬 배포에 활용할 수 있습니다. 유용한 선택지이지만 다운로드 파일이 있다고 상업 조건까지 정해지는 것은 아닙니다.

11월 2일 확인한 Liquid의 모델 카탈로그는 회사의 연매출이 1천만 달러를 넘기 전까지 상업적으로 무료 이용할 수 있다고 설명합니다. LFM3-1.7B 모델 카드에는 LFM Open License v1.0가 명시돼 있습니다. 사용할 정확한 체크포인트의 라이선스와 현재 라이선스 페이지를 읽고, 실행 환경과 재배포 방식, 매출 조건에 맞는지 확인하세요.

실제 도입·구매 때 확인할 단계입니다. 작은 내부 시제품, 다운로드하는 소비자 앱, 다른 기업에 제공하는 서비스는 배포와 의무의 질문이 다를 수 있습니다. 프로젝트가 커져도 판단을 추적하도록 앱과 모델 식별자·리비전·라이선스를 함께 기록하세요.

런타임 소프트웨어와 모델 가중치는 버전이 따로 있습니다. 모델이 공개됐어도 기기의 런타임에는 호환 지원이 없을 수 있습니다. 이전 제품군을 불러올 수 있는 앱이면 새 모델도 올바르게 불러올 것이라고 가정하지 말고, 문서에 나온 조합을 확인하세요.

팀에서 남기는 기록에는 체크포인트가 요구하는 프롬프트나 템플릿도 포함해야 합니다. 호환 로더를 써도 입력 형식이 틀리면 결과가 나빠질 수 있습니다. 무엇을 불러왔고 애플리케이션이 어떤 형식으로 모델에 입력했는지 알아야 재현할 수 있습니다.

약 1 GB의 가중치는 메모리 예산의 출발점이다

Liquid는 10월 27일 출시 자료에서 4비트 텍스트 모델의 크기를 약 1 GB라고 설명합니다. 텍스트 모델 카드는 1.73B 매개변수와 입력·출력 합계 256K 토큰의 컨텍스트를 명시합니다. 이는 모델 사양이며, 애플리케이션의 최대 메모리 사용량은 작업 부하와 런타임에도 영향을 받습니다.

가중치 파일은 실행 중인 프로세스의 일부일 뿐입니다. 런타임에는 작업 메모리가, 컨텍스트 처리에는 상태 저장 공간이 필요합니다. 멀티미디어 입력에는 추가 버퍼와 인코더가 필요할 수 있고, 다른 프로그램도 같은 기기 자원을 사용합니다. 가중치 크기만으로는 부하가 걸렸을 때 전체 애플리케이션이 여유롭게 동작할지 알 수 없습니다.

따라서 예시 메모리 예산도 측정한 프로세스 사용량에서 시작해야 합니다. 유휴 상태, 대표 요청을 처리할 때의 최대치, 반복 요청 이후 상태를 기록하세요. 단지 쉽게 들어맞는 작은 프롬프트보다 사용자가 실제 제공할 컨텍스트 길이와 입력 크기를 시험해야 합니다.

시간도 같은 원칙으로 측정해야 합니다. 시작, 프롬프트 처리, 응답 생성은 별도의 대기입니다. 오래 기다린 뒤 토큰을 빨리 내는 모델도 대화형 앱에서는 느리게 느껴질 수 있습니다. 일괄 처리라면 시간당 완료 건수가 더 중요할 수 있습니다. 상호작용에 맞는 지표를 고르세요.

오디오라면 입력부터 사용 가능한 결과까지 전체 경로를 포함하세요. 이미지에는 이미지 처리를, 판단에는 유효성 검사와 조치 전달을 포함합니다. 출시 자료의 성능 수치가 아니라 독자가 정할 평가 요건입니다.

자체 제작한 메모리 예산 설명 도표입니다. 구간 너비는 설명용이며 측정 비율이 아닙니다. 약 1 GB는 전체 앱 메모리가 아니라 Liquid가 공개한 4비트 텍스트 모델의 가중치 용량입니다. 출처.

세 가지 활용 예시는 서로 다른 절충점을 드러낸다

문서 도우미는 읽기와 판단을 구분할 수 있다

촬영한 영수증을 받는 소규모 업무 애플리케이션을 상상해 보세요. 판매자와 날짜, 금액을 읽는 일과 사람이 검토할 만큼 문서가 완전한지 판단하는 일은 다릅니다. 한 모델이 둘 다 돕더라도 두 출력은 각각 검증할 필요가 있습니다.

시각·언어 모델은 이미지에 관한 질문을 지원할 수 있고, 판단 모델은 범위를 정한 완전성 검사에 평가할 수 있습니다. 앱은 원본 이미지를 보존하고 추출한 필드와 승인된 회계 데이터를 구분해야 합니다. 날짜가 빠졌다면 누군가 해결할 때까지 누락 상태로 남겨야 합니다.

선명한 사진, 흐릿한 사진, 특이한 배치, 실제 업무 언어의 영수증을 포함한 평가 세트를 구성해 보세요. 필드별 오류와 검토 작업량을 측정합니다. 전체 성공률이 높아도 업무에서 가장 중요한 필드에 반복되는 오류가 숨어 있을 수 있습니다.

유용한 제품 결과는 더 짧고 명확한 검토 대기열입니다. 모델이 우아하게 설명하는지보다 검토자가 원자료를 살피고 필드를 고칠 수 있는지가 중요합니다. 이 우선순위가 자유로운 언어 출력과 제한된 판단 인터페이스 중 선택하는 데 도움이 됩니다.

음성 인터페이스는 허용할 행동을 좁혀서 시작할 수 있다

로컬 앱의 핸즈프리 도우미를 예로 들어 보겠습니다. 사용자는 항목 찾기, 상태 읽기, 초안 조치 준비를 요청할 수 있습니다. 타이핑보다 말하기 편할 때 오디오는 유용하지만 앱은 여전히 요청이 무엇을 바꿀 수 있는지 알아야 합니다.

허용할 행동의 종류를 적게 정하고 확인 과정을 눈에 보이게 만드세요. 예를 들어 기록을 찾는 요청은 권한이 있는 데이터 안에서 즉시 실행하되, 기록을 바꾸는 요청은 제안된 작업을 먼저 검토하게 할 수 있습니다. 정책은 모델이 만들어내는 표현이 아니라 애플리케이션이 책임져야 합니다.

실제 음향 조건으로 시험하세요. 배경 대화, 짧은 발화, 비슷한 이름은 깨끗한 녹음 문장과 다른 실패 유형을 만들 수 있습니다. 사용자에게 되묻는 것이 정답인 사례도 넣으세요. 유창한 말보다 정확하고 복구 가능한 상호작용이 더 유용합니다.

말한 내용뿐 아니라 보이는 내용에 따라서도 요청이 달라지면 옴니 모델을 검토할 이유가 생깁니다. 모든 작업이 음성만 사용한다면 시각 처리를 추가할 근거가 필요합니다. 제품군에서 필요한 모델을 고르는 방식은 기능을 작업 규모에 맞추는 데 도움이 됩니다.

로컬 지원 도구는 검토 경로를 남긴 채 업무를 분류할 수 있다

지원 앱의 예에서는 문의와 첨부 화면을 보고 세 대기열 중 하나를 고를 수 있습니다. 제한된 판단 출력이 긴 답변을 해석하는 것보다 과제에 직접 맞을 수 있습니다. 선택 경로를 감당할 수 있는 검토 비율로 충분히 신뢰할 수 있는지가 핵심입니다.

명시적인 ‘검토 필요’ 결과를 유지하세요. 어느 대기열에도 맞지 않는 문의, 모순된 화면, 맥락이 부족한 사례를 시험합니다. 스키마가 경로를 요구한다는 이유만으로 모델이 유효한 경로를 꾸며 내게 해서는 안 됩니다.

기존 규칙이나 사람의 배정 같은 단순한 기준선과 비교하세요. 기준선이 이미 분류를 안정적으로 처리한다면 모델은 업무의 다른 부분을 개선해야 합니다. 새롭다는 사실은 합격 기준이 아닙니다.

각 오류가 왜 생겼는지 이해할 수 있도록 이용 권한이 있는 맥락을 충분히 남겨두세요. 입력 문제와 모호한 분류 기준, 모델 오류를 구분합니다. 그래야 모델을 개선할지, 대기열 정의를 바꿀지, 더 나은 원자료를 요청할지 정할 수 있습니다.

벤치마크 표는 실제 작업 평가의 출발점이다

11월 2일 확인한 공식 LFM3-1.7B 모델 카드는 지식 의존도가 높은 작업에 검색이나 자료 조회를 권장하며, 이 크기의 모델을 에이전트 코딩이나 복잡한 다단계 추론에 쓰는 데 주의를 당부합니다. 공급사 벤치마크에서 개선이 보이더라도 더 큰 시스템 안에 모델을 배치할 때 참고할 지침입니다.

벤치마크는 특정 설정에서 특정 질문에 답한 결과입니다. 실제 애플리케이션에는 자체 데이터와 도구, 언어 분포, 실패 비용이 추가됩니다. 공개 종합 점수가 좋아져도 사용자가 매일 접하는 몇몇 범주에는 여전히 세심한 개선이 필요할 수 있습니다.

파일럿에서는 비교 세 가지를 나눕니다. 먼저 현재 업무와 과제 품질을 비교하세요. 다음으로 대상 기기의 전체 자원 비용을 비교합니다. 마지막으로 실패 복구에 드는 노력을 비교합니다. 각 비교에서 나은 선택은 다를 수 있습니다.

예를 들어 로컬 전문 모델이 답변을 거절할 때 클라우드 범용 모델로 넘기는 경로가 유용할 수 있습니다. 이런 구성에는 명확한 데이터 정책과 사용자 경험이 필요합니다. 로컬 동작은 로깅과 대체 요청을 포함한 전체 애플리케이션에서 확인해야 하는 배포 방식입니다.

파인튜닝은 실제로 드러난 부족함을 해결해야 합니다. 원자료 누락이나 불분명한 출력 정의가 실패의 원인이라면 학습을 늘려도 잘못된 과제를 강화할 수 있습니다. 요건과 오류를 먼저 살펴본 뒤 맞춤 학습이 다음 단계인지 결정하세요.

첫 파일럿의 결정은 한 페이지에 담을 수 있어야 한다

공식 텍스트 모델 카드에는 체크포인트 형식과 런타임 지침이 연결돼 있습니다. 정확한 모델·런타임 조합은 여기서 확인하고, 데이터 정책에 맞는다면 공식 Playground로 초기 상호작용을 살펴보세요. 어느 경로도 실제 제공할 배포 환경의 시험을 대신하지는 않습니다.

1. 입출력 요건을 적으세요. 허용할 자료, 기대 결과, 명시적인 검토 필요 결과를 정합니다. 범용 어시스턴트의 성격보다 작업 하나를 선택하세요.
2. 후보와 리비전을 고르세요. 모달리티와 출력 역할을 맞추고 체크포인트, 라이선스, 호환 런타임을 기록합니다. 모델별 한계도 읽어보세요.
3. 대표성 있는 평가 세트를 만드세요. 평범한 사례와 어려운 사례, 지원하지 않는 요청, 실제 사용자 언어의 예시를 넣습니다. 평가용 자료는 맞춤 학습 데이터와 분리하세요.
4. 격리된 환경에서 공식 빠른 시작을 실행하세요. 모델 카드의 현재 의존성과 형식 지침을 따릅니다. 출력을 비교하기 전에 반환된 모델 식별자를 확인하세요.
5. 애플리케이션 전체 경로를 측정하세요. 실제 입력 크기에서 정확성, 검토 비율, 지연 시간, 최대 메모리 사용량을 측정하고 하드웨어·런타임 설정도 기록합니다.
6. 불확실성을 처리하는 경로를 시험하세요. 정보 누락, 잘못된 출력, 런타임 실패가 이해할 수 있는 검토·재시도 상태로 이어지는지 확인합니다.
7. 다음으로 전문화할 부분을 정하세요. 반복되는 오류 범주를 보고 입력 개선, 규칙 명확화, 검색, 파인튜닝, 다른 모델 가운데 선택합니다.

첫 평가의 결론은 간단해도 됩니다. 이 후보가 이 기기에서 이 작업에 유용하며 어떤 검토 조건이 필요한지를 적는 것입니다. 범위가 좁아도 재현 가능한 결론이 로컬 AI가 모든 일에 준비됐다는 일반론보다 가치 있습니다.

작은 모델은 정의된 작업을 완수할 때 제자리를 얻는다

LFM3는 앱 가까이에서 텍스트·시각·소리·한정된 판단을 처리하려는 개발자의 선택지를 넓힙니다. 역할을 고르고 제품 일부로 평가할 수 있다는 데 실무 의미가 있습니다.

다음 단계는 품질과 메모리, 복구 가능성을 모두 측정할 수 있도록 작업 하나를 명확히 정의하는 것입니다. 전체 애플리케이션이 그 요건에 의존할 수 있고 모델이 답하지 못할 때의 처리 방법도 알 때, 전문 모델이 유용해집니다.

출처

• Liquid AI: LFM3 소개, 2026년 10월 27일; 2026년 11월 2일 확인.
• Liquid AI 모델 카탈로그 및 가격 및 라이선스, 2026년 11월 2일 확인.
• 공식 LFM3-1.7B 모델 카드, 2026년 11월 2일 확인.
• 공식 d1-2B 모델 카드, 2026년 11월 2일 확인.

결정의 근거 자료를 보관한다

Telli.sh는 검토한 메모와 이용 권한이 있는 원자료를 함께 보관할 수 있는 선택지입니다. 노트 작업 공간 만들기.