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에 기재된 자체 측정 비교 결과는 다음과 같다.

벤치마크	LongCat-2.0	GPT-5.5	Gemini 3.1 Pro	Claude Opus 4.8
SWE-bench Pro	59.5	58.6	54.2	69.2
...

해석 시 주의가 필요하다. 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 Weights) 중 최강」이 아니라 「오픈 웨이트로서, 조금 전의 프론티어(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 없이는 최전선의 훈련을 할 수 없다」는 암묵적인 전제에 균열을 낸다. 숫자의 승패보다 이 재현 가능성에 대한 주장이 업계에는 더 큰 영향을 미친다.

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과의 차이가 허용 범위 내인지 실제 태스크를 통해 측정해 보는 것이 좋다. 수치는 자사에서 측정하고, 진가는 당신의 리포지토리에서 증명될 것이다.