Flint v1.0 vs North Mini Code: 당신의 노트북을 두고 격돌하는 두 오픈 코딩 MoE

이 사이트의 대부분 "대결" 페이지는 애초에 진정한 경쟁 관계가 아니었던 것들을 짝지어 놓는다. 이 페이지는 다르다. Recursive Flint v1.0과 Cohere North Mini Code는 같은 종류의 객체다. 희소 전문가 혼합(mixture-of-experts) 코딩 모델이며, Apache 2.0으로 공개되었고, 개발자가 이미 보유한 하드웨어에서 실행할 수 있을 만큼 작으며, 둘 다 최전선 모델이 아닌 로컬 옵션으로 자리매김한다. Flint는 2026년 10월 21일 총 파라미터 398억 개, 토큰당 활성 파라미터 약 25억 개로 등장했다. North Mini Code는 2026년 6월 9일 총 300억 개, 활성 30억 개로 등장했다. 차이가 이처럼 작으니 선택은 결국 파일 안에 무엇이 들어 있는지, 그리고 실제로 무엇이 측정되었는지에 달려 있다. 그런데 두 가지 모두에서 답은 출시 보도가 시사하는 것과 다르다.

두 파일을 차원별로

상자 안에 무엇이 들어 있는지부터 시작하십시오. 두 개의 자체 호스팅 모델의 경우, 현실과 맞닥뜨려도 살아남는 비교는 바로 이것이기 때문입니다.

• 총 파라미터 — Flint: 39.8B. North Mini Code: 30B.

• 토큰당 활성 파라미터 — Flint: 약 2.5B, {{1}}본체에 2.2B, 나머지는 출력 헤드에{{/1}}. North Mini Code: 3B. 거의 동일하며, 이것이 추론 비용을 좌우하는 숫자입니다.

• 전문가 라우팅 — Flint: 47개 MoE 레이어와 2개 dense 레이어에 걸쳐 256개의 라우팅된 전문가, 토큰당 6개 선택 + 공유 1개. North Mini Code: 128개 전문가, 토큰당 8개 활성.

• 어텐션 — Flint: 어텐션 싱크가 있는 슬라이딩 윈도우 레이어와 전역 레이어의 혼합. North Mini Code: 슬라이딩 윈도우 대 전역 비율 3:1. 둘 다 같은 가정을 하고 있다. 즉, 대부분의 토큰은 로컬 어텐션만 필요로 하고 일부만 전체 윈도우가 필요하다는 것이다.

• 컨텍스트 — Flint: 모델 카드에 262,144 토큰이 문서화되어 있고, 발표 자료에서는 최대 512K를 언급하며 256K를 권장합니다. North Mini Code: 입력 256K, 최대 출력 64K.

• 모달리티 — Flint: 텍스트 입력, 텍스트 출력. North Mini Code: 텍스트 입력, 텍스트 출력. 둘 다 이미지를 받지 않으므로, 작업에 스크린샷이 포함된다면 이 점이 중요합니다.

• 라이선스 — 둘 다 Apache 2.0이며 가중치 포함, 매출 기준 없음.

• 공개된 형식 — Flint: BF16, int4 safetensors, int4 GGUF, NVFP4 GGUF. North Mini Code: BF16, FP8 및 W4A16.

• 디스크 및 메모리 — Flint: BF16에서 79.59GB, NVFP4로 22.86GB, 실행에는 약 24GB의 메모리가 필요합니다. North Mini Code: 양자화 시 약 20~24GB이며, Cohere 자체 데모는 Mac Studio에서 약 20GB로 실행됩니다.

메모리는 첫 번째 삭감 대상이며, 파라미터 수가 암시하는 것보다 더 가깝다.

39.8B 대 30B를 단순하게 해석하면 Flint가 메모리를 3분의 1 더 필요로 한다는 뜻입니다. 그렇지 않습니다. 둘 다 희소 모델이고 둘 다 공격적으로 양자화된 빌드를 공개하기 때문입니다. 실제로 선택하는 대상은 22.86 GB NVFP4 파일과 대략 20 GB의 양자화 빌드입니다 — 같은 24 GB 카드로 둘 다 실행할 수 있을 만큼, 그리고 차지하는 용량만 놓고 보면 어느 쪽도 명백한 선택이 아닐 만큼 가깝습니다.

차이는 여유분에 있습니다. North Mini Code는 32GB DDR4를 갖춘 Ryzen 7에서 4비트 GGUF를 실행했다고 보고되었는데, 이는 워크스테이션이 아닌 정말로 평범한 데스크톱입니다. Flint의 노트북 관련 주장은 더 구체적입니다. Recursive의 처리량 수치는 M4 Pro MacBook Pro와 64GB RTX Spark에서 측정되었으며, 둘 다 프리미엄 기기입니다. 22.86GB 파일은 24GB 카드에 로드될 것입니다. 받아들일 만한 속도로 실행되는지는 별개의 문제이며, 이는 엔진에 크게 좌우됩니다.

당신의 제약이 "이미 가지고 있는 기계"라면, North Mini Code가 평범한 하드웨어에서 실행된다는 보고가 더 많습니다. 제약이 "내가 가진 최고의 기계"라면, Flint가 더 새로운 아키텍처이며 짧은 컨텍스트에서 더 빠릅니다.

이 중 하나에는 독립적인 스코어보드가 있습니다.

비교에서 대부분의 기사가 건너뛰는 부분이며, 바로 이 부분이 조달을 결정해야 하는 부분입니다.

North Mini Code는 Artificial Analysis에서 측정되었습니다. AA Coding Index에서 33.4점, AA Intelligence Index에서 27.6점을 기록했으며, SWE-bench Verified는 pass@1 67.6, pass@10 80.2, mini-SWE-Agent는 61.0입니다. 이는 일관된 프로토콜로 산출된 제3자 측정치이므로, 하네스에 관한 각주 없이 동일 지수에서 다른 모델과 비교할 수 있습니다.

Flint는 Artificial Analysis 항목이 없습니다. 공개된 점수인 SWE-bench Verified 74.2점, SWE-bench Pro v2 89.7점, Terminal-Bench 2.1 54.9점은 Recursive 자체 하네스에서 나온 것이며, 아무도 이를 다시 실행해 보지 않았습니다. 방법론이 공개되어 있다는 점은 Recursive의 미덕입니다. SWE-bench 실행에는 인터넷 없이 mini-swe-agent를 사용했고, Terminal-Bench에는 인터넷을 사용하는 Terminus 2를 사용했지만 웹에서 가져온 해법은 실패로 간주했으며, pass@1은 최소 다섯 번의 시도에 걸쳐 평균을 냈습니다. 공개된 방법론은 검증된 방법론이 아닙니다.

그럼 67.6과 74.2를 비교할 수 있을까요? 책임 있게 말하자면 아닙니다. 이 둘은 서로 다른 조직이 서로 다른 규칙을 가진 서로 다른 하네스에서 산출한 것이며, 6.6점이라는 격차는 하네스 선택만으로도 점수가 움직일 수 있는 범위 안에 충분히 들어갑니다. 그래도 말할 수 있는 것은 더 좁지만 여전히 유용합니다. North Mini Code의 수치는 모델을 만들지 않은 사람이 검증했지만, Flint의 수치는 그렇지 않습니다. 사양이 아니라 증거를 기준으로 선택한다면, 바로 그 비대칭이 중요한 것입니다.

North Mini Code의 항목에는 불리하지만 알아둘 가치가 있는 데이터 포인트가 하나 더 있습니다. Artificial Analysis는 이를 유난히 장황하다고 표시했는데, 테스트에서 약 7,500만 개의 출력 토큰을 소비했으며 이는 동급 중앙값 약 2,500만 개에 맞먹습니다. 장황함은 에이전트 루프에서 비용 배수입니다. 세 배나 더 생각을 소리 내어 하는 모델은 토큰당 비용은 더 저렴할 수 있지만 작업당 비용은 더 비쌀 수 있습니다.

긴 컨텍스트에서는 속도에 관한 이야기가 완전히 달라집니다

두 모델 모두 짧은 프롬프트에서는 빠르고, 컨텍스트가 가득 차면 둘 다 느려집니다. 차이는 그 정도가 얼마나 되느냐입니다.

• Flint — Recursive는 M4 Pro MacBook Pro에서 초당 125개 이상의 토큰을, 64GB RTX Spark에서 150개 이상의 토큰을 짧은 컨텍스트에서 프리필을 제외하고 측정했다고 주장합니다. 독립 테스트에서는 짧은 프롬프트에서 초당 약 110개 토큰이었고, 컨텍스트가 115,000토큰에 가까워지면 초당 약 9개 토큰으로 떨어졌다고 보고했습니다. 바로 이 수치를 기준으로 에이전트를 설계해야 합니다. 에이전트형 코딩은 대부분의 시간을 긴 컨텍스트 영역에서 보내기 때문입니다.

• North Mini Code — Cohere의 API에서 초당 약 199~210개의 출력 토큰, 첫 토큰까지 약 0.25초, 동일 테스트에서 비교 가능한 소형 모델 대비 약 2.8배 처리량. 로컬 하드웨어에서는 수치가 전적으로 엔진과 양자화에 따라 달라지지만 패턴은 같습니다: 짧은 컨텍스트에서는 빠르고, 윈도가 채워질수록 느려집니다.

정직한 비교는 "어느 것이 더 빠른가"가 아니라 "에이전트가 실제로 작동하는 방식에서 어느 것이 더 빠른가"입니다. 4K 컨텍스트에서는 8밀리초, 115K에서는 110밀리초에 토큰을 쓰는 모델은 성능이 더 완만하게 저하되는 모델과는 다른 제품입니다. 어느 벤더도 곡선을 공개하지 않습니다. 롱컨텍스트 에이전트 작업이 유스케이스라면, 도입하기 전에 자체 저장소에서 측정하세요 — 한나절이면 되는 작업이며, 어느 출시 글보다 더 많은 것을 알려줄 것입니다.

모멘텀 대 신선도

North Mini Code는 출시 두 달 후인 2026년 8월 중순까지 다운로드 15만 건을 돌파했다. 이는 실질적인 신호다. 그 정도로 널리 채택된 모델이라면 제작자들이 테스트해 보지 않은 하드웨어에서도 실행되었고, 커뮤니티에서 수정 사항이 누적되었으며, 호의적일 이유가 없는 사람들에 의해 거친 부분들이 문서화되었음을 의미한다. 이 수치는 Cohere가 보고한 것이므로 공급업체 제공 데이터로 취급해야 하지만, 유통 중인 파생 양자화 버전의 규모를 보면 그 방향성은 뒷받침된다.

Flint는 출시된 지 나흘 된 모델입니다. 더 뛰어난 대표 사양, 더 빠른 단문맥 디코딩, 더 길게 문서화된 콘텍스트 윈도, 그리고 더 흥미로운 개발 스토리를 갖추고 있습니다. 동시에 llama.cpp의 GGUF 경로에 알려진 채팅 템플릿 버그가 있고, 장문맥에서 아무도 설명하지 못한 처리량 급락이 있으며, 커뮤니티 이력은 사실상 전무합니다. 나흘 된 모델을 이른 시기에 도입하는 것은 결과물에 대한 평가라기보다 그 궤적에 거는 베팅입니다.

월요일에 다운로드할 항목

• 독립적인 점수가 부여된 모델을 원한다면, 하드웨어가 넉넉하지 않다면, 작업이 컨텍스트에 무리 없이 들어가는 저장소에서의 평범한 소프트웨어 엔지니어링이라면, 그리고 더 새로운 아키텍처보다 두 달 치 커뮤니티 버그 리포트를 더 중시한다면 North Mini Code를 선택하세요. 이 모델의 장황한 출력을 감안해 비용을 계획하세요.

• 프리미엄 노트북이나 24GB 카드를 갖고 있다면, 더 긴 컨텍스트 창을 원한다면, 짧은 컨텍스트에서의 속도가 실제 워크플로에서 중요한 부분이라면, 그리고 한 달 뒤에는 더 나은 모델이 될 가능성이 있는 모델을 위해 얼리 어답터가 될 의향이 있다면 Flint를 선택하세요.

• 둘 중 어느 것도 유일한 선택지로 삼지 마세요. 둘 다 2.5~3B 활성 모델입니다. 범위가 정해진 작업에는 뛰어나지만 프런티어 코딩 어시스턴트는 아니며, Recursive도 자사 모델에 대해 그렇게 말합니다. 둘 중 어느 것도 잘하지 못하는 작업은 호스팅된 프런티어 모델이 필요한 작업이며, 현명한 아키텍처는 하나의 모델에 모든 역할을 맡기는 것이 아니라 로컬 기본값과 에스컬레이션 경로를 두는 것입니다.

그 에스컬레이션 경로야말로 라우팅이 진가를 발휘하는 지점입니다. OrcaRouter는 이 두 모델 중 어느 것도 제공하지 않으므로, 여기서 해당 모델로 가는 경로를 홍보하는 내용은 아닙니다. 로컬 우선 환경에서 라우팅 계층이 하는 일은 다른 방향입니다. 즉, 더 큰 호스팅 모델이 필요한 작업을 동일한 호출 경로로 구성할 수 있게 해 주고,폴백 체인을 로컬 모델이 멈추거나 컨텍스트가 넘치는 요청에 제공합니다. 잘 구성하면 로컬 모델이 일상적인 작업을 처리하고 값비싼 모델은 실제로 필요할 때만 사용되므로, 이것이 이 아키텍처에서 비용을 절감하는 유일한 방식입니다.

지루한 답이 정답입니다. 두 파일 모두 무료이고, 둘 다 당신이 아마 가지고 있을 하드웨어에서 실행되며, 어느 쪽이 당신의 저장소에 맞는지 아는 유일한 방법은 둘 다 그것에 적용해 보는 것입니다. 둘 사이의 벤치마크 격차는 둘 중 어느 하나와 당신의 실제 워크로드 사이의 격차보다 작습니다.