소식 · · 읽는 시간 13분
Recursive Flint 공개: 활성 2.5B 로컬 코딩 모델의 벤더 점수와 실제 에이전트 테스트, 메모리 계산
이 글의 차례
Recursive가 2026년 10월 21일 코딩 에이전트용 오픈 웨이트 모델 Flint를 Apache 2.0 라이선스로 공개했습니다. 전체 매개변수는 398억 개이고, 토큰마다 약 25억 개만 쓰는 전문가 혼합(MoE) 구조입니다. Recursive가 고른 비교군 안에서는 비슷한 크기의 MoE 모델보다 앞서지만, 같은 표의 dense 계열 Qwen 3.8에는 코딩 벤치마크 네 항목 모두 뒤처집니다. 공개 다음 날 나온 제3자 에이전트 테스트에서는 비슷한 크기의 MoE 모델 Ornith 1.5보다 전체 작업을 4.7배 빨리 끝냈고, 통과한 실행은 18번 중 12번으로 2번 적었습니다. 지금까지 나온 자료로는 Flint의 장점이 정답률보다 속도로 보입니다. NVFP4·MLX 4비트 판은 파일만 23GB 안팎이고, 문맥을 최대로 열면 KV 캐시가 7.55GB 더 붙는다는 계산이 나옵니다. 그래서 24GB 그래픽카드 한 장으로는 공식 권장 구성을 맞추기 어렵습니다.
이 글에서는 Flint가 무엇이고 어디서 받을 수 있는지, 벤더 점수와 제3자 테스트가 갈린 지점, 체크포인트와 문맥 길이별 메모리를 직접 계산한 결과, 공개 직후 개발자 반응, 한국 개발자가 쓸 만한 자리를 다룹니다.
Flint의 구조와 배포 형태
모델 카드는 코드베이스 조사, 버그 수정, 기능 구현, 테스트 작성을 용도로 적고, 입력과 출력은 텍스트뿐입니다. Recursive는 사전학습부터 강화학습까지 처음부터 직접 학습했고, 사람과 에이전트로 이뤄진 작은 팀이 넉 달이 안 되는 기간에 만들었다고 밝혔습니다. 회사는 자동 연구 시스템 Eureka Machine이 데이터, 학습 방식, 양자화, 커널 최적화 대부분에 관여했다고 설명합니다. 그 기여가 실제로 얼마나 컸는지는 외부에서 확인할 방법이 없습니다.
구조는 모델 카드 기준으로 다음과 같습니다.
| 항목 | 값 |
|---|---|
| 매개변수 | 전체 398억 개, 토큰당 활성 약 25억 개(출력층 포함) |
| 층 | 49층: dense 2층 + MoE 47층 |
| 어텐션 | 슬라이딩 윈도(513토큰) 35층, 전체 어텐션 14층 |
| 어텐션 헤드 | 쿼리 32개, 키/값 4개, 헤드 차원 128 |
| 전문가 | 층마다 256개 중 6개 선택 + 공유 전문가 1개 |
| 문맥 | 262,144토큰(입력과 출력 합산) |
| 지식 기준일 | 2026년 6월 |
전체 어텐션 층이 49층 중 14층뿐이라는 점이 메모리 계산에서 중요합니다. 긴 문맥을 열면 KV 캐시가 커지는데, 그 대부분이 이 14층에서 나오기 때문입니다. 문맥 길이는 출처마다 다릅니다. 공식 블로그는 최대 512,000토큰을 지원하되 256,000토큰 안에서 쓰기를 권하고, 모델 카드는 262,144토큰으로 적습니다. 실제 설정은 모델 카드 값을 기준으로 잡는 편이 안전합니다.
가중치는 Hugging Face에 네 가지 형태로 올라와 있습니다. 파일 크기는 Hugging Face 저장소의 파일 목록을 합산해 직접 정리했습니다.
| 체크포인트 | 파일 크기 | 대상 실행 환경 | 공식 권장 메모리 |
|---|---|---|---|
| BF16 원본 | 79.6GB | SGLang, B300 또는 H200 1장 | 별도 표기 없음 |
| NVFP4 GGUF | 22.9GB | NVIDIA GPU용 llama.cpp | GPU 메모리 48GB 이상(Spark는 통합 메모리) |
| INT4(MLX) | 22.6GB | Apple Silicon, rec 엔진 | 별도 표기 없음 |
| INT4 GGUF(Q4_1) | 26.0GB | Mac용 llama.cpp(Metal) | 통합 메모리 48GB 이상 |
NVFP4는 NVIDIA의 4비트 형식입니다. Recursive는 NVFP4 판이 16비트 원본과 비교해 자사 벤치마크 전체에서 0.7점 이내라고 밝혔습니다. 같은 형식을 다른 모델에서 따져 본 내용은 Nemotron 3.5 Super VL NVFP4 판 글에 있습니다. 실행 도구로는 llama.cpp, Ollama, Unsloth, LM Studio, vLLM, SGLang이 공식 블로그에 적혀 있고, M4 Pro와 M5 Pro/Max용 자체 추론 엔진 rec도 함께 나왔습니다. NVIDIA는 같은 날 GTC Berlin 발표에서 Flint를 RTX Spark, DGX Spark, GeForce RTX, RTX PRO GPU에서 돌릴 수 있다고 소개했습니다.
벤더 점수에서 앞선 곳과 뒤진 곳
Recursive는 모델 카드에 Flint와 비슷한 장비에서 도는 로컬 모델을 같은 축에 놓은 그림을 실었습니다. 그림 1은 그 가운데 에이전트 코딩 세 항목과 LiveCodeBench v6를, Recursive가 MoE 계열과 dense 계열로 나눈 비교 모델 하나씩과 함께 옮긴 것입니다.
MoE 계열과 비교하면 Flint가 앞섭니다. Terminal-Bench 2.1은 Qwen 3.6의 44.9보다 10.0점 높은 54.9이고, SWE-bench Pro v2는 73.8보다 15.9점 높은 89.7입니다. SWE-bench Verified(74.2 대 73.4)와 LiveCodeBench v6(80.3 대 80.4)은 사실상 같습니다. Recursive가 공식 블로그에서 전체 매개변수 500억 개 미만 MoE 가운데 에이전트 코딩 벤치마크 1위라고 밝힌 근거가 이 비교입니다. 다만 그림에 없는 MoE 모델과 견주면 결론이 달라질 수 있습니다. 8월에 MIT 라이선스로 나온 Ornith 1.5 35B-A3B는 공식 모델 카드에 SWE-bench Verified 79, Terminal-Bench 2.1 67.8(Terminus-2 하네스 기준)을 적어 두 항목 모두 Flint보다 높습니다. 측정 하네스가 서로 달라 정확한 차이로 읽을 수는 없습니다.
dense 계열과 비교하면 순서가 바뀝니다. Qwen 3.8은 Terminal-Bench 2.1에서 73.0으로 Flint보다 18.1점 높고, LiveCodeBench v6에서도 90.3으로 10.0점 높습니다. Recursive는 이 차이를 속도로 설명합니다. 공식 블로그는 Flint가 비슷한 코딩 점수를 내는 250억~400억 매개변수 dense 모델보다 5배 넘게 빠르다고 주장합니다. 같은 블로그가 제시한 속도는 자체 엔진 기준으로 M4 Pro MacBook Pro에서 초당 125토큰 이상, 64GB RTX Spark에서 초당 150토큰 이상이며, 둘 다 짧은 문맥 조건입니다.
이 점수는 모두 벤더 발표값입니다. Flint 점수는 Recursive가 쟀고, 비교 모델 점수는 대부분 각 개발사 발표값입니다. 원본 그림은 SWE-bench Pro v2 항목 제목에도 Recursive 자체 측정 표시(†)를 붙였습니다. 모델 카드도 평가 설정이 출처마다 다르다고 적었습니다. 예를 들어 Flint의 Terminal-Bench 점수는 웹 검색으로 얻은 답을 실패로 쳤지만, 다른 개발사 점수에는 같은 기준이 적용되지 않았을 수 있습니다. 이 글을 쓰는 시점에 같은 벤치마크를 제3자가 다시 잰 결과는 찾지 못했습니다.
제3자 에이전트 테스트에서 드러난 차이
벤치마크 대신 실제 작업으로 잰 결과는 하나 있습니다. 로컬 에이전트 도구를 만드는 Atomic Agent 팀이 공개 다음 날인 10월 22일 RTX 5090(32GB) 한 장에서 Flint와 Ornith 1.5 35B-A3B를 같은 작업 6개에 각각 3번씩 돌렸습니다. 두 모델 모두 4비트 GGUF를 llama.cpp로 띄웠고, 문맥은 131,072토큰이었습니다.
| 항목 | Flint | Ornith 1.5 35B-A3B |
|---|---|---|
| 통과한 실행(6작업 × 3회) | 12/18 | 14/18 |
| 18회 전체 소요 시간 | 375초 | 1,749초(20분 시간 초과 1회 포함) |
| 18회 생성 토큰 | 약 41,000개 | 약 173,000개 |
| 디코딩 속도 | 초당 145.7토큰 | 초당 149.4토큰 |
| VRAM 사용량 | 27.4GB | 22.8GB |
Flint가 빨랐던 이유는 토큰을 빨리 만들어서가 아닙니다. 디코딩 속도는 두 모델이 거의 같았고, Flint는 생성한 토큰이 4분의 1 수준이었습니다. 단계를 적게 밟고 일찍 멈춘 것입니다. 일찍 멈춘 대가도 결과에 남았습니다. 로그 파일 세 개에서 ERROR 줄을 세는 작업(정답 43)에서 Flint는 세 번 모두 세는 명령을 돌리지 않고 12, 14, 17이라고 적었습니다. 본 측정 전 예비 실행에서는 결과 파일에 PLACEHOLDER라는 단어를 써 놓고 성공했다고 보고한 일도 있었습니다. 테스트한 팀은 Flint가 끝냈다고 말하는 작업을 직접 확인하라고 결론 내렸습니다.
4.7배라는 차이는 Ornith가 20분 제한에 걸린 실행 1회가 키운 값입니다. 테스트한 팀이 그 실행과 Flint의 같은 회차를 빼고 다시 합산하자 548초 대 351초, 약 1.6배로 줄었습니다. 이 테스트의 조건은 Recursive 벤치마크와 다릅니다. 표본이 작업당 3회이고, 샘플링은 Recursive 권장값(temperature 1.0)이 아니라 에이전트 기본값(temperature 0.2)이었습니다. llama.cpp의 Flint 지원 코드에는 속도를 10~30% 깎는 임시 처리가 들어 있다고 해당 PR 작성자가 밝혔으므로, llama.cpp 속도는 이후 빌드에서 오를 수 있습니다. 그래서 이 결과는 방향 신호로 읽는 편이 맞습니다.
문맥 길이별 메모리 직접 계산
공식 권장 메모리가 48GB인데 4비트 파일은 23GB 안팎입니다. 그 차이의 대부분은 KV 캐시로 보입니다. 모델 카드의 구조값으로 KV 캐시 크기를 직접 계산했습니다. 공식 실행 예시가 키와 값을 f16(2바이트)으로 저장하므로 그 조건을 따랐습니다.
- 전체 어텐션 14층 × 키/값 헤드 4개 × 헤드 차원 128 × (키+값) 2 × 2바이트 = 토큰당 28,672바이트
- 슬라이딩 윈도 35층은 513토큰분만 보관: 35 × 513 × 2,048바이트 = 약 0.04GB(문맥 길이와 무관)
| 문맥 길이 | KV 캐시(추정) | NVFP4 파일(22.86GB)과 합계 | 연산 버퍼 0.57GB 포함 |
|---|---|---|---|
| 32,768토큰 | 0.98GB | 23.84GB | 24.41GB |
| 131,072토큰 | 3.79GB | 26.66GB | 27.23GB |
| 262,144토큰 | 7.55GB | 30.42GB | 30.99GB |
마지막 열의 연산 버퍼 0.57GB는 제3자 측정에 대 보고 얻은 값입니다. Atomic Agent 팀이 쓴 UD-Q4_K_XL 파일(25.05GB)에 131,072토큰 KV 캐시 3.79GB를 더하면 28.84GB인데, 실제 측정값 28,044MiB는 29.41GB였습니다. 차이 0.57GB는 llama.cpp의 연산 버퍼 몫으로 보입니다. 측정이 1건뿐이라 이 값은 근사치입니다. 이 버퍼가 문맥 길이와 무관하다고 가정해 다른 행에도 같은 값을 더했습니다.
그래픽카드 용량은 이진 단위라서 24GB 카드는 약 25.8GB, 32GB 카드는 약 34.4GB입니다. 이렇게 맞춰 보면 24GB 카드에는 32,768토큰(24.41GB)은 들어가지만 131,072토큰(27.23GB)은 넘칩니다. 32GB 카드는 262,144토큰을 다 열어도 30.99GB라 3GB 남짓 남습니다. 운영체제와 화면 출력이 같은 카드를 쓰면 이 여유는 더 줄어듭니다. Recursive가 48GB를 권장한 것은 이런 몫까지 넉넉히 잡은 값으로 보입니다.
공개 직후 개발자 반응
Hacker News의 Recursive 공식 발표 글(29점, 댓글 6개)에서는 반응이 갈렸습니다. 긍정 쪽에서 kamranjon은 "처음부터 학습했는데 Qwen 3.8 27B에 가까운 품질에 초당 토큰이 크게 늘었다는 게 놀랍다(Pretty amazing for being trained from scratch, to have ~Qwen 3.8 27b quality with such an increase in tok/s performance)"고 썼습니다(댓글).
회의적인 쪽에서 aistripes는 "숫자는 좋아 보이지만 실제 테스트에서는 감흥이 없다(Numbers seem good but can't really be impressed on real world test)"고 썼고(댓글), nittanymount는 "차트 숫자는 좋지만 아직 qwen3.8만큼은 아니다(not as good as qwen3.8 yet, even the chart says good numbers)"라고 남겼습니다(댓글). Reddit의 반응은 접속이 막혀 확인하지 못했습니다.
한국 개발자가 쓸 자리
Flint가 바꾸는 것은 "코드를 밖으로 보내지 않는 코딩 에이전트"의 문턱입니다. Apache 2.0이라 상업적으로 써도 되고, 가중치를 받아 사내 장비에서만 돌릴 수 있습니다. 외부 AI 서비스에 코드를 올리지 못하는 금융·공공 쪽 개발 환경에서 먼저 검토할 만한 후보로 보입니다. 공식 블로그도 데이터를 원격 서버로 보내지 않고 로컬에서 돌릴 작업에 Flint를 쓰라고 안내합니다.
장비 기준은 분명합니다. 앞의 계산대로라면 24GB 그래픽카드 한 장에서는 일부 층을 CPU로 넘기지 않는 한 공식 NVFP4 판을 32,768토큰 안팎의 짧은 문맥으로만 띄울 수 있고, 32GB 그래픽카드는 전체 문맥까지 들어가지만 여유가 3GB 남짓입니다. Mac은 Q4_1 GGUF 기준으로 통합 메모리 48GB 이상이 공식 요구 조건입니다. 10월 23일부터 파트너사를 통해 출시되기 시작한 DGX Spark 64GB는 48GB 권장치를 넘으므로 전체 문맥까지 쓸 수 있는 구성으로 보입니다.
작업은 작게 쪼개 맡기는 편이 맞습니다. 공식 블로그도 Flint가 대형 비공개 코딩 모델보다 더 많은 안내가 필요할 수 있으니 복잡한 작업은 작은 하위 작업으로 나누라고 권합니다. 제3자 테스트에서 드러난 "세지 않고 숫자를 적는" 실패를 고려하면, 테스트가 정답을 가려 주는 수정이나 이름 바꾸기 같은 작업에 먼저 붙이고 결과를 반드시 검증하는 방식이 맞아 보입니다. 클라우드 최상위 모델을 대신하기보다는 빠른 1차 작업자로 두는 자리가 현실적입니다.
한계
| 항목 | 내용 |
|---|---|
| 벤치마크 | 모든 점수가 벤더 발표값. 같은 벤치마크를 제3자가 재현한 결과는 아직 없음 |
| 제3자 테스트 | Atomic Agent 1건, RTX 5090 1장, 작업 6개 × 3회. 샘플링이 Recursive 권장값과 다름 |
| 메모리 계산 | 모델 카드 구조값과 f16 KV 가정으로 낸 추정. 연산 버퍼는 측정값 1건과의 차이로만 추정 |
| 한국어 | 모델 카드와 공식 블로그에 언어별 평가가 없음. 한국어 주석·요구사항 처리 능력은 확인되지 않음 |
| 직접 실행 | 이 글은 Flint를 직접 돌려 보지 않았고, 공개 자료와 제3자 측정을 정리·계산한 것 |
출처
- Recursive 공식 블로그, Introducing Flint
- Hugging Face, RecursiveSI/flint 모델 카드 · NVFP4 GGUF · INT4 · INT4 GGUF
- NVIDIA 블로그, Bringing the Spark to Europe: Local Intelligence Powers Next Wave of Agents
- Atomic Agent, Recursive Flint: Specs, VRAM, Local Agent Test · Flint vs Ornith 1.5
- Hugging Face, ornith-ai/Ornith-1.5-35B-A3B 모델 카드
- Hacker News, Recursive Introduces Flint Model
