Kimi K2.6: 과거 Gonka에서 서비스했던 모델

Kimi K2.6는 베이징 기업 Moonshot AI가 개발한 Kimi 시리즈의 대규모 언어 모델(LLM)입니다. Moonshot AI는 중국을 대표하는 AI 연구소 중 하나로, 2023년 Yang Zhilin이 이끄는 연구진 팀에 의해 설립되었습니다. Alibaba, Tencent 등 대형 투자자로부터 자금을 유치했으며, 아시아의 AI 발전을 주도하는 '중국 AI 호랑이' 기업 목록에 이름을 올렸습니다.

Kimi 시리즈가 알려지기 시작한 것은 2024년부터입니다. 초기 버전(K1, K1.5)은 단일 요청당 최대 200,000 토큰에 달하는 압도적으로 긴 컨텍스트 윈도우로 즉시 주목을 받았는데, 이는 출시 당시 공개적으로 이용 가능한 모델 중 최고 기록이었습니다. 긴 컨텍스트란 한 번의 요청으로 책 한 권, 중간 규모의 코드베이스, 또는 법률 문서 모음을 통째로 분석할 수 있는 실질적 가능성을 뜻합니다. Kimi가 등장할 당시 이 특성은 강력한 경쟁 우위였습니다.

K2 버전은 2025년에 등장하며 근본적인 아키텍처 도약을 가져왔습니다 — MoE(Mixture of Experts)로의 전환입니다. 이 아키텍처는 Qwen3-235B와 DeepSeek-R1의 기반이기도 하며, 2025~2026년 최대 규모 모델의 사실상 표준이 되었습니다. MoE는 '전체'로는 수천억 개의 파라미터를 보유하면서도 요청마다 일부(보통 5~10%)만 활성화하므로, 동등한 품질을 유지하면서 추론(inference)의 연산 비용을 획기적으로 낮춥니다.

K2.6은 이 글을 쓰는 시점에서 K2 시리즈의 최신 이터레이션입니다. Moonshot AI의 공개 발언에 따르면 이 버전에서는 reasoning(논리적 추론), 코드 생성, 네이티브 도구 호출(tool calling) 능력이 향상되었습니다. 한때 Gonka 네트워크에서 서비스되던 시절 이 모델은 식별자 moonshotai/Kimi-K2.6로 이용 가능했습니다. 현재 게이트웨이는 이 식별자를 받지 않습니다 — 최신 모델 목록은 항상 GET /v1/models가 반환합니다.

두 모델 모두 중국 주요 AI 연구소의 플래그십 개발 성과입니다. 네트워크를 통해 서비스되던 당시에는 통합된 OpenAI 호환 인터페이스인 JoinGonka Gateway를 통해 접근할 수 있었으나, 현재 게이트웨이를 통해 이용 가능한 것은 MiniMax M2.7뿐입니다. 하지만 두 모델은 강점과 배경이 다르므로, 어느 것이 더 나은지보다는 어떤 작업에 적합한지를 기준으로 선택하는 것이 중요합니다.

추론 벤치마크(MATH-500, GSM8K, AIME)에서 Kimi K2 시리즈는 역사적으로 open-weights 모델 상위 그룹에 위치하며, DeepSeek-R1 및 o1 스타일 모델들과 경쟁해 왔습니다. 코드 생성 작업(HumanEval, MBPP)에서 두 모델은 비슷한 수준을 유지합니다. MiniMax M2.7의 강점은 초장문 시퀀스를 위한 효율적인(선형) Attention이며, Kimi 시리즈는 강력한 추론 능력과 긴 컨텍스트로 잘 알려져 있습니다.

2026년 벤치마크에 대한 중요한 주의 사항: 공개 테스트에서 최고 모델 간의 격차는 수 퍼센트 이내로 좁혀졌으며, 이 차이는 벤치마크 자체의 통계적 오차 범위 내인 경우가 많습니다. 실용적인 측면에서 중요한 것은 "MMLU에서 어느 모델이 2% 더 높은가"가 아니라, 모델에 전달하는 컨텍스트의 성격, 논리적 연결의 복잡성, 대화 이력의 필요 여부, 사용 언어 등 작업의 성격입니다. 따라서 위의 표는 모델 순위가 아니라 각 모델이 어떤 작업 프로필에 최적화되어 있는지 빠르게 파악하기 위한 것입니다.

오늘날 실용적인 선택으로, Kimi K2.6의 영역이었던 '긴 컨텍스트(대규모 문서 분석, 방대한 코드 베이스 읽기, 이력이 유지되는 긴 대화)' 및 '복잡한 추론 작업'은 현재 네트워크의 다른 두 모델이 담당합니다. 추론은 GLM-5.3 Flash가 담당합니다. 이 모델은 답변 전 추론 과정을 거치므로 복잡한 논리가 필요할 때 권장되며, 네트워크 내에서 가장 긴 컨텍스트(390K)를 보유하고 있습니다. 추론이 필요 없는 대규모 프롬프트와 긴 에이전트 세션에는 DeepSeek V4 Flash(380K, 두 번째로 긴 컨텍스트)가 적합합니다. 매우 긴 입력 시퀀스와 스트리밍 데이터의 빠른 처리가 우선이라면 효율적인 Attention을 갖춘 MiniMax M2.7이 적합합니다. 프로덕션에서의 우수한 전략은 여전히 변함없습니다. 즉, 코드 내에 여러 모델을 유지하는 것입니다. model 파라미터를 통한 신속한 변경으로 애플리케이션 아키텍처를 수정하지 않고도 작업에 따라 모델을 자유롭게 전환할 수 있습니다.

2026년 봄까지 Gonka 네트워크 전체는 단 하나의 모델, Qwen3-235B만을 운영했습니다. 아키텍처 관점에서 이는 합리적인 결정이었습니다. DiLoCo를 통한 분산 추론은 네트워크의 모든 참여자가 동일한 모델을 VRAM에 올려두어야 하며, 그렇지 않으면 어떤 노드든 임의의 요청을 처리할 수 있다고 보장할 수 없습니다. FP8 형식의 풀 Qwen3-235B는 약 640GB의 VRAM를 차지하는데, 이는 그 자체로 모든 ML 노드에 막대한 부담이었습니다.

멀티 모델 네트워크로 전환하려면 여러 모델을 동시에 유지하면서도 각 호스트가 모든 모델을 실행할 필요는 없는 구조가 필요했습니다. 그 역할을 한 것이 DevShards입니다. 각각 하나의 모델에 특화된 별도의 샤드로, 같은 샤드 내의 노드는 동일한 모델을 다루고 네트워크 라우터가 요청을 해당 모델의 샤드로 보냅니다.

이 아이디어는 갑자기 나온 것이 아니라, 2026년 봄 커뮤니티 투표에 부쳐진 Gonka Improvement Proposal #800 "Multi-Model PoC"에서 공식화되었습니다. 제안은 네트워크 참여자와 검증자의 지지를 얻어 2026년 4~5월에 구현되었습니다. Kimi K2.6은 별도 DevShard에서 운영된 첫 모델, 즉 사실상 새로운 접근법의 테스트 구현이었습니다. 실험은 성공적이었고, 이어서 MiniMax M2.7, DeepSeek V4 Flash, GLM-5.3 Flash가 각자의 샤드에 등장했으며, 각기 고유한 호스트 집합과 고유한 경제 구조를 가졌습니다. 같은 메커니즘은 반대 방향으로도 작동합니다. 호스트가 지원을 중단한 모델은 투표로 네트워크에서 제외됩니다. 2026년 9월에 Kimi K2.6 자신이 떠난 방식도 바로 이것이었습니다.

사용자와 개발자에게 이것이 의미하는 바:

• 하나의 API, 여러 모델. JoinGonka Gateway를 통하면 엔드포인트나 키를 바꿀 필요가 없습니다. 요청 본문의 model만 다른 값으로 지정하면 됩니다. OpenAI 호환 형식은 완전히 유지됩니다.
• 가격은 동일합니다. Kimi K2.6은 운영되는 동안 MiniMax M2.7과 같은 요율로 과금되었습니다. 네트워크의 통합 요금은 현재 모델에도 유지되며, Gateway를 통한 100만 토큰당 $0.0069입니다. 통합 프라이싱은 사용자가 모델 간을 쉽게 이동할 수 있도록 한 의도적 결정입니다.
• 안정성은 샤드 부하에 달려 있습니다. 초기 단계의 새 모델 샤드는 호스트 수가 적기 때문에 요청이 몰리면 일시적으로 429 too many concurrent requests가 반환될 수 있습니다. 이는 새 모델의 정상적인 단계입니다. 관심이 커지면 호스트가 해당 샤드에 합류하고 한도도 늘어납니다. 반대도 마찬가지로, 호스트가 샤드를 떠나면 모델은 용량을 잃습니다. Kimi K2.6이 네트워크에서 막을 내린 방식도 이와 같았습니다.
• 도구 호출은 모델마다 다릅니다. Gonka 네트워크의 Kimi K2.6에서는 초기에 도구 자동 선택(tool_choice: "auto") 관련 소소한 문제가 보고되었고, 이후 노드 업데이트로 해소되었습니다. 교훈은 네트워크의 모든 모델에 적용됩니다. 도구 호출 형식은 특정 노드에서의 특정 모델의 속성이므로, 프로덕션에 중요한 시나리오라면 선택한 모델의 동작을 자신의 요청으로 미리 테스트하세요.

결론부터 말하자면, Gonka 네트워크를 통해서는 더 이상 Kimi K2.6을 사용할 수 없습니다. 호스트들은 2026년 9월 초에 서비스 제공을 중단했고, 거버넌스 제안 #101로 이 모델은 네트워크 모델 목록에서 완전히 제외되었습니다 — model: "moonshotai/Kimi-K2.6"이 포함된 요청은 게이트웨이가 거부합니다. 모델 가중치는 공개되어 있으므로, 서드파티 open-weights 모델 호스팅(예: OpenRouter)을 통해 여전히 받거나 직접 배포할 수도 있습니다.

반면 Gonka를 찾는 이유인 그 저렴한 탈중앙화 inference가 필요하다면, 그것은 사라지지 않았습니다. 단지 현재 네트워크의 운용 모델 위에서 작동할 뿐입니다. JoinGonka API Gateway에서는 OpenAI 및 Anthropic 호환 API를 통해 세 가지 모델을 사용할 수 있으며, 각각이 Kimi에서 높이 평가되던 요소의 일부를 담당합니다:

• GLM-5.3 Flash (zai-org/GLM-5.3-Flash) — Z.ai의 reasoning 모델: 답변 전에 추론하기 때문에 복잡한 로직, 코드 분석, "생각하는" 작업에 적합합니다. 네트워크에서 가장 긴 컨텍스트(390K)도 갖추고 있습니다. 추론은 응답 한도에 포함되므로 max_tokens을 여유 있게 설정하고 stream을 켜세요.
• DeepSeek V4 Flash (deepseek-ai/DeepSeek-V4-Flash-0731) — 네트워크에서 가장 긴 축에 속하는 컨텍스트(380K), 가장 긴 출력, 강력한 에이전트형 코딩: 대형 리포지토리, 긴 도구 호출 체인에 적합합니다.
• MiniMax M2.7 (MiniMaxAI/MiniMax-M2.7) — 게이트웨이의 기본 모델: 일상적인 작업, 긴 문서, 스트리밍 처리에서 빠르고 안정적인 응답을 제공합니다.

Kimi K2.6에서의 이전은 한 줄 교체입니다. OpenAI를 위해 작성된 코드는 그대로 작동합니다: URL, API 키, 모델 이름만 바꾸면 됩니다.

curl https://gate.joingonka.ai/v1/chat/completions \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "MiniMaxAI/MiniMax-M2.7",
    "messages": [{"role": "user", "content": "Explain the difference between MoE and dense models"}]
  }'

개발 도구에서도 규칙은 같습니다: 설정에 moonshotai/Kimi-K2.6이 있던 모든 곳에 운용 모델 중 하나의 식별자를 넣으세요. Cursor에서는 Custom Model 필드, Claude Code에서는 환경 변수 ANTHROPIC_MODEL 또는 --model 플래그, OpenClaw, Cline, Continue.dev에서는 프로바이더 설정의 모델 이름, LangChain과 n8n에서는 클라이언트 초기화 시의 model 파라미터입니다. 설치 프로그램 npx @joingonka/setup을 쓰면 게이트웨이와 최신 모델을 도구 설정에 명령 한 번으로 기록할 수 있습니다. 사용 가능한 모델 목록은 항상 GET /v1/models 엔드포인트에서 최신 상태로 확인할 수 있습니다 — 여기서 앱 UI로 동적으로 가져오면 모델의 종료나 추가가 제품을 망가뜨리지 않습니다.

등록 없이 시험해보려면 /try 페이지의 무료 채팅을 이용하세요 — 거기서 네트워크의 운용 모델을 사용할 수 있습니다. JoinGonka Gateway에 등록하면 네트워크의 모든 모델을 테스트할 수 있는 무료 3M 토큰을 받습니다 — 세 모델 각각에 자신의 작업을 돌려보고 대안을 충분히 검토해 선택하기에 넉넉한 양입니다.

Kimi K2.6 사건이 Gonka 네트워크에 보여준 것: DevShards 메커니즘은 양방향으로 작동했습니다. 네트워크를 멈추지 않고 모델을 추가할 수 있었고 — Kimi에 이어 MiniMax M2.7, DeepSeek V4 Flash, GLM-5.3 Flash가 들어왔습니다 — 호스트가 지원을 중단한 모델도 문제없이 제외할 수 있었습니다. 단일 모델에 묶인 네트워크는 근본적으로 취약하고, 투표로 구성을 바꿀 수 있는 네트워크는 부드럽고 지속적으로 진화합니다. 개발자에게 남는 교훈은 간단합니다: "모델을 영원히 선택"하는 것이 아니라, 모델 이름을 설정에 두고 살아 있는 목록을 계속 확인하는 것입니다.