로컬·엣지에 작은 모델을 붙이려는 사람은 성능표부터 연다.
성능표부터 여는 순서는 LFM2.5 에이전트를 검토할 때 오히려 걸림돌이 된다.
Liquid AI가 공개한 LFM2.5-2.6B 모델 카드에는 '에이전트용'이라는 표시가 있다.
그 표시가 가리키는 범위부터 짚어야 한다.
이름에 LFM2.5 에이전트라는 표현이 붙었다고 모델 혼자 함수를 실행하는 건 아니다.
모델이 맡는 일은 호출 형식을 만드는 데서 끝난다.
호출을 실제로 돌리고 결과를 붙이는 일은 호스트 쪽 몫이다.
이 분리가 LFM2.5 에이전트 연결에서 가장 먼저 걸리는 지점이다.
배포 형식은 트랜스포머·vLLM·SGLang용 네이티브 체크포인트, llama.cpp용 GGUF, ONNX, MLX로 나온다.
도구 사용과 데이터 추출, RAG, 긴 문맥 작업에는 이 모델을 권장한다.
공식 모델 카드 기준으로 에이전트 코딩과 지식 집약 과제에는 권장하지 않는다고 적혀 있다.
공식 모델 카드는 총 파라미터를 2.69B로, 컨텍스트 윈도를 131,072토큰으로 적는다.
LFM2.5 에이전트 표시는 이 권장 범위를 뜻하는 것이지, 실행 주체가 바뀐다는 뜻은 아니다.
공식 도구 사용 문서는 절차를 생성·정의·실행·반환 네 단계로 정리해 둔다.
문서는 모델과 호스트의 역할을 분리해 적었다.
모델이 특수 토큰 사이에 함수 호출을 생성한다.
도구를 시스템 프롬프트나 apply_chat_template로 JSON 정의한다.
그 호출을 실제로 실행하고 결과를 tool 역할 메시지로 되돌린다.
모델이 그 결과를 해석해 사용자에게 다시 답한다.
호출 형식도 확인 대상이다.
공식 문서에 따르면 기본 호출 형식은 파이썬 방식이다.
JSON 형식으로 받으려면 시스템 프롬프트에 따로 지시해야 나온다.
런타임이 파이썬 방식 출력을 처리하지 못하면, 호출은 파싱 단계에서부터 어긋난다.
이미지의 흐름은 이 분담을 요약했다.
눈여겨볼 지점은 여기다.
2.6B라는 크기와 LFM2.5 에이전트라는 표기만으로는 무엇이 실제로 이어져 있는지 드러나지 않는다.
런타임을 무엇으로 고르든 아래 지점이 실제로 연결돼 있는지가 먼저 온다.
런타임 확인이 먼저 필요하다.
| 확인 항목 | 확인할 지점 |
|---|---|
| 외부 실행 | 함수를 실제로 실행하는 코드가 호스트 쪽에 있는가 |
| 결과 반환 | 실행 결과가 tool 역할 메시지로 다시 들어가는 경로가 있는가 |
| 도구 정의 | 시스템 프롬프트나 apply_chat_template로 도구 목록을 넘기고 있는가 |
| 호출 형식 | 런타임이 기본값인 파이썬 방식을 처리하는가, JSON 전환 지시가 필요한가 |
| 특수 토큰 | tool_call_start·tool_call_end 토큰을 런타임이 인식하는가 |
이 항목들은 모델 카드 밖에 있다.
런타임과 프레임워크 설정에 걸려 있어서다.
공식 모델 카드와 도구 사용 문서가 확인해 주는 건 여기까지다.
문서 안의 절차와 권장·비권장 용도는 확인된 사실이다.
그 절차를 실제 호스트에서, 실제 도구 스키마로 돌렸을 때 호출이 얼마나 성공하고 지연이 얼마나 걸리고 비용이 얼마인지는 이 문서만으로 확정되지 않는다.
따로 붙여서 재봐야 하는 영역이다.
성능표를 살펴보기 전에, LFM2.5 에이전트 연결 계약이 내 런타임에서 실제로 닫히는지부터 보는 게 순서다.
댓글
댓글 쓰기