코히어, H100 한 장으로 돌리는 오픈소스 코딩 에이전트 ‘노스 미니 코드’ 공개

코히어가 노리는 건 ‘로컬에서 굴리는 코딩 에이전트’임

• 코히어가 오픈소스 에이전트 코딩 모델 ‘노스 미니 코드(North Mini Code)’를 공개함

  • 단일 엔비디아 H100 GPU에서도 실행 가능하다고 밝힘
  • 허깅페이스를 통해 아파치 2.0 라이선스로 공개돼 기업이 자체 데이터센터나 로컬 환경에서 운영할 수 있음
  • 깃허브 코파일럿, 커서, 클로드 코드처럼 구독형이나 사용량 기반 상용 모델에만 기대지 않는 선택지를 내세운 셈임

• 모델은 300억 매개변수 규모의 전문가 혼합(MoE) 구조임

  • 다만 토큰 생성 시 실제로 활성화되는 매개변수는 30억개 수준임
  • 전체 모델 용량은 키우되, 매번 일부 전문가 네트워크만 쓰는 방식으로 성능과 추론 비용 사이를 타협함
  • 전체 128개 전문가 네트워크 중 토큰마다 8개만 활성화하는 희소(Sparse) MoE 구조를 썼음

• 코히어는 이 모델을 단순 코드 생성기가 아니라 ‘에이전트형 소프트웨어 엔지니어링’용으로 설계했다고 설명함

  • 하위 에이전트 조율, 시스템 아키텍처 분석, 코드 리뷰, 터미널 기반 작업을 수행하도록 학습함
  • 셸 명령어 실행, 패키지 스크립트 관리, 명령행 도구 활용 같은 터미널 작업 능력도 강조함
  • 실제 터미널 환경에서 에이전트 성능을 평가하는 터미널-벤치 v2 기반 검증도 진행됨

긴 컨텍스트와 학습 방식도 꽤 공격적임

• 컨텍스트 창은 최대 25만6000 토큰, 출력 길이는 최대 6만4000 토큰을 지원함

  • 대규모 프로젝트 전체를 한 번에 분석하는 사용 사례를 노림
  • 코딩 에이전트는 파일 하나만 보는 게 아니라 저장소 구조, 의존성, 테스트, 빌드 스크립트를 같이 봐야 해서 긴 컨텍스트가 중요함

• 학습 데이터도 일반 코드 말뭉치만 긁은 쪽이 아님

  • 약 5000개 소프트웨어 저장소에서 뽑은 7만개 이상의 검증 가능한 과제를 활용함
  • 이후 두 단계의 지도학습(SFT)과 검증 가능한 보상 체계를 활용한 강화학습(RL)을 거쳐 성능을 끌어올림
  • 특정 에이전트 프레임워크 하나에 과적합하지 않도록 SWE-에이전트, 미니-SWE-에이전트, 오픈코드 환경을 함께 사용함

• 이 다중 환경 학습은 꽤 중요한 포인트임

  • 각 환경은 도구 호출 방식과 인터페이스가 다름
  • 코히어는 이 접근으로 오픈코드 평가에서 약 10%포인트 성능 향상을 얻으면서 기존 SWE-에이전트 성능을 유지했다고 설명함
  • 특정 IDE나 에이전트 런타임에 묶이지 않는 범용성을 노린 전략임

성능은 좋아 보이지만, 토큰을 많이 쓰는 약점도 보임

• 내부 테스트 기준 성능 주장은 꽤 세게 나옴

  • 데브스트랄 스몰 2 대비 출력 처리량이 2.8배 높았다고 함
  • 토큰 간 지연 시간은 약 30% 낮았다고 주장함
  • 일부 벤치마크에서는 최대 1200억 매개변수 규모의 오픈소스 모델보다 좋은 성능을 보였다고 밝힘

• 독립 평가기관 아티피셜 애널리시스(AA) 결과에서도 상위권에 들어감

  • 127개 오픈웨이트 모델 가운데 지능 지수 9위, 코딩 지수 4위를 기록함
  • 코딩 모델로는 꽤 강한 위치에 있다는 뜻임

• 하지만 비용 관점에서 찝찝한 숫자도 있음

  • AA 평가를 완료하는 동안 노스 미니 코드는 약 7500만개 출력 토큰을 생성함
  • 비교 모델들의 중앙값은 2500만개라서 약 3배 수준임
  • 모델이 장황하게 답하는 경향이 있다는 뜻이고, 대규모 에이전트 파이프라인에서는 추론 비용과 응답 지연이 커질 수 있음

상용 코딩 모델과는 다른 경제성을 제안함

• 코히어가 던지는 메시지는 “토큰이 실제 경제적 가치를 만들고 있나?”에 가까움

  • 최고 수준 상용 코딩 모델로 평가되는 클로드 페이블 5는 출력 토큰 100만개당 50달러 비용이 든다고 기사에서 언급됨
  • 반면 노스 미니 코드는 단일 H100 GPU나 자체 서버에서 운영할 수 있음
  • 사용량 기반 과금이 부담스러운 기업에는 꽤 매력적인 제안임

• 로컬 실행 가능성도 데모로 보여줌

  • 코히어 공동 창립자 닉 프로스트는 애플 실리콘 기반 맥 스튜디오에서 MLX 프레임워크로 모델을 구동하는 모습을 공개함
  • 메모리 약 20GB 환경에서 실행되는 모습이었다고 함
  • 고성능 데이터센터뿐 아니라 개인 개발 환경에서도 활용 가능성이 있다는 신호임

---

기술 맥락

• 노스 미니 코드가 MoE를 택한 이유는 “큰 모델처럼 똑똑하되, 매번 큰 모델 전체를 돌리지는 말자”는 계산 때문이에요. 300억 매개변수 전체를 항상 쓰면 비용이 커지지만, 토큰마다 8개 전문가만 활성화하면 추론 부담을 줄일 수 있거든요.

• 긴 컨텍스트가 중요한 이유는 코딩 에이전트가 함수 하나만 보고 끝나는 도구가 아니기 때문이에요. 실제 저장소에서는 설정 파일, 테스트, 패키지 스크립트, 모듈 관계를 같이 봐야 하고, 그래서 25만6000 토큰 컨텍스트가 제품 포인트가 돼요.

• 세 가지 에이전트 환경에서 학습한 것도 꽤 실무적인 선택이에요. 특정 프레임워크의 도구 호출 방식에만 맞춰 학습하면 다른 런타임에서 성능이 흔들릴 수 있거든요. 코히어는 SWE-에이전트, 미니-SWE-에이전트, 오픈코드를 같이 써서 범용성을 노렸어요.

• 다만 출력 토큰이 많다는 건 에이전트 운영에서 진짜 비용 문제가 될 수 있어요. 로컬 배포라도 GPU 시간은 공짜가 아니고, 응답이 길어질수록 대기 시간과 병렬 처리 여유가 줄어들어요.

• 결국 이 모델의 가치는 “상용 모델보다 무조건 좋다”가 아니라 “데이터를 밖으로 보내기 어렵거나, 사용량 과금이 부담스러운 팀이 자체 인프라에서 코딩 에이전트를 굴릴 수 있느냐”에 달려 있어요.