OpenRouter의 이용 랭킹에서 약 2개월 동안, 정체불명의 「Owl Alpha」라는 모델이 상위권을 계속 유지하고 있었다. 에이전트 계열의 코딩 용도로 묘하게 평판이 좋았으나, 누가 내놓은 것인지는 숨겨진 상태였다. 그 정체가 6월 말에 밝혀졌다. 중국의 생활 서비스 대기업 Meituan이 공개한 LongCat-2.0이다.

음식 배달 회사가 왜 1.6조 파라미터의 거대 언어 모델(LLM)을 만들었나 싶겠지만, 핵심은 그곳에 있지 않다. 내가 이번 릴리스에서 주목한 것은 벤치마크 수치나 회사의 의외성도 아닌, 이 모델이 Nvidia의 칩을 단 한 장도 사용하지 않고 훈련되었다는 점 하나였다.

🐈 우선 무엇이 공개되었는가

LongCat-2.0은 Mixture-of-Experts (MoE, 입력마다 일부의 「전문가」 네트워크만 구동하는 방식) 언어 모델이다. 총 파라미터는 1.6조 개이지만, 1토큰당 실제로 계산에 사용되는 것은 약 48B로 압축된다. 컨텍스트 길이(Context Length)는 100만 토큰이며, 가중치(Weights)는 MIT 라이선스로 상업적 이용에도 제약이 없다. GitHub과 Hugging Face를 통해 배포되고 있다.

• GitHub: https://github.com/meituan-longcat/LongCat-2.0
• Hugging Face: https://huggingface.co/meituan-longcat

공식 테크 블로그는 모델명으로 바로 검색 가능하다.

코딩 성능을 살펴보면, 리포지토리의 README에 기재된 자체 측정 비교 결과는 다음과 같다.

해석 시 주의가 필요하다. GPT-5.5나 Gemini 3.1 Pro의 스코어는 README에서 「각 사의 공식 리포트로부터 인용」한 것이며, LongCat 측은 자체적인 통합 하네스(Harness)로 측정했다. 즉, 완전히 동일한 조건에서의 비교는 아니다. 그럼에도 불구하고 SWE-bench Pro에서 이전 세대인 GPT-5.5나 Gemini 3.1 Pro를 앞선다는 것은 사실로서 무게감이 있다. 반면 표에 나열된 Claude Opus 4.8에는 확실히 미치지 못한다. 「오픈 웨이트(Open Weight) 중 최강」이 아니라 「오픈 웨이트로서, 조금 전 세대의 프론티어(Frontier) 모델들과 어깨를 나란히 했다」는 것이 정직한 요약이다.

🔧 진짜 뉴스는 훈련에 사용한 하드웨어

README의 기술을 그대로 인용하면, 훈련과 대규모 배포 모두 「AI ASIC 슈퍼포드(Superpod)」 위에서만 완결된다.

Both the full training run and the large-scale deployment are built entirely on AI ASIC superpods. Pretraining spans millions of accelerator-days across more than 35 trillion tokens, with no rollbacks or irrecoverable loss spikes.

35조 토큰 이상, 수백만 액셀러레이터 데이(Accelerator-days) 규모의 사전 학습(Pretraining)을 롤백(Rollback)이나 회복 불가능한 손실 스파이크(Loss Spike) 없이 완수했다고 적혀 있다. 사용한 칩의 정확한 모델명은 README에 없지만, VentureBeat의 보도에 따르면 5만 대 규모의 중국제 ASIC 클러스터라고 전해진다.

이것이 왜 중요한가. 최근의 프론티어급 훈련은 사실상 Nvidia GPU와 CUDA 에코시스템을 사용하는 것을 전제로 한다. 수출 규제로 인해 최신 GPU를 구하기 어려운 환경에서, 대체 하드웨어만으로 1.6조 파라미터를 안정적으로 훈련해냈다는 실증은 「Nvidia 없이는 최전선 훈련을 할 수 없다」는 암묵적인 전제에 균열을 낸다. 숫자의 승패보다 이 재현 가능성에 대한 주장이 업계에는 더 큰 파급력을 갖는다.

LSA: DeepSeek의 DSA가 파고든 지점을 공략하다

100만 토큰의 문맥을 다룰 때, 단순한 어텐션(Attention)은 계산량이 토큰 수의 제곱으로 늘어난다. 이를 줄이는 것이 「희소 어텐션 (Sparse Attention)」이며, LongCat-2.0은 독자적인 **LongCat Sparse Attention (LSA)**를 탑재하고 있다.

흥미로운 점은 그들이 개선 대상으로 지목한 것이 DeepSeek-V3.2의 DSA(Lightning Indexer)라는 점이다. DSA는 「어떤 토큰에 주목할 것인가」를 선택하는 인덱서(Indexer) 부분에서 출력의 불연속성과 스코어링(Scoring)의 제곱 비용이라는 약점을 안고 있었다. LSA는 이 문제를 세 가지 측면에서 공략한다. 메모리를 연속 읽기(Continuous Read)에 가깝게 가져가 대역폭(Bandwidth)을 확보하는 기법, 인접 레이어(Layer)에서 주목 경향이 안정되는 성질을 이용해 인덱스 계산을 여러 레이어에서 재사용하는 기법, 그리고 거칠게 후보를 좁힌 뒤 세밀하게 선택하는 2단계 필터링 방식이다. 요컨대 「모든 토큰을 매번 성실하게 살펴보는 것을 그만두고, 어디를 볼 것인지에 대한 계산 자체를 저렴하게 만드는 것」이다. 긴 문맥(Long Context)의 비용은 주목하는 내용 자체보다 주목할 대상을 결정하는 처리 과정에서 팽창하는 경향이 있으므로, 이 전략은 핵심을 꿰뚫고 있다.

또 다른 하나는, MoE(Mixture of Experts)와는 직교하는 축으로 파라미터를 늘리는 N-gram Embedding(135B)을 이전 세대인 LongCat-Flash-Lite로부터 계승했다. MoE의 희소성(Sparsity)을 높이는 것만으로는 한계에 부딪히는 영역을 임베딩(Embedding) 측면의 확장을 통해 보완하는 설계 사상이다.

「오픈」이지만, 직접 구동하기 위한 문턱은 높다

가중치(Weights)를 얻을 수 있다고 해서, 과연 부담 없이 돌릴 수 있을까? README가 권장하는 구성은 다음과 같다.

python -m sglang.launch_server \
--model meituan-longcat/LongCat-2.0-FP8 \
--trust-remote-code \
...

권장 사양은 H20 16장이며, 텐서 병렬화(Tensor Parallelism)와 전문가 병렬화(Expert Parallelism)를 병용하는 것이다. SGLang 측의 대응 PR(Pull Request)도 이미 머지(Merge)되었으며, NPU를 위한 별도의 브랜치도 마련되어 있다. 도구 호출을 위한 채팅 템플릿(Chat Template)도 동봉되어 있어, Claude Code나 Hermes와 같은 기존의 에이전트 하네스(Agent Harness)에 통합하는 것을 전제로 만들어졌다. 뒤집어 말하면, MIT 라이선스로 「공개」되어 있다 하더라도 개인이 컴퓨터 한 대로 가볍게 돌릴 수 있는 물건은 아니다. 여기서의 「오픈 소스」는 소스 코드를 읽을 수 있고 자체 추론 스택(Inference Stack)에 올릴 수 있다는 것을 의미하는 것이지, 로컬에서 간편하게 실행할 수 있다는 뜻은 아니다. API나 OpenRouter를 통해 접하는 것이 현실적인 첫걸음이 될 것이다.

배포 상황에 대해서는 한 가지 덧붙여 두겠다. GitHub의 README는 MIT 라이선스의 가중치와 FP8 버전 리포지토리를 전제로 절차를 작성하고 있지만, 공개 직후에는 미러(Mirror) 사이트에 의해 가중치 파일이 아직 「coming soon」으로 표시되는 경우도 있었다. 자체 배포 환경을 구축하기 전에, Hugging Face 또는 ModelScope에 실제 파일이 모두 갖춰져 있는지 확인한 후 구동하는 것이 좋다.

얻어갈 수 있는 점

이 릴리스의 가치는 리더보드의 한 줄에 있지 않다. 에이전트 용도로 실운용을 견딜 수 있는 1.6조 파라미터급 모델이 Nvidia 이외의 하드웨어만으로 안정적으로 훈련되어 MIT 라이선스로 세상에 나왔다는 점이다. 이 조합이 새롭다. 코딩 에이전트를 자사의 추론 기반에 올리고 싶은 팀에게, 선택지가 「프런티어의 바로 뒤편」까지 열린 가중치로 제공되게 되었다는 의미는 결코 작지 않다. 우선 OpenRouter에서 Owl Alpha가 바뀐 LongCat-2.0을 사용해 보고, 자신의 워크플로우에서 Opus 4.8과의 차이가 허용 범위 내인지 실제 태스크에서 측정해 보는 것이 좋다. 숫자는 자사 측정으로, 진가는 당신의 리포지토리에서 증명될 것이다.

Discussion