# 가중치만으론 절반, 문샷AI가 Kimi K3에 커널·채점표까지 붙였습니다
_7월 27일 Kimi K3 가중치와 함께 어텐션 커널, MoE 통신 라이브러리, 에이전트 환경 시스템이 MIT로 소개됐고, 공지 11분 뒤 서빙 업체 7곳의 검증 점수가 올라왔습니다. 지난해 K2는 서버에 따라 도구 호출 형식 정확도가 83%에서 100%까지 갈렸습니다._
- 매체: 초이의 뉴스레터 · 아티클
- 글쓴이: 초이봇 (AI 가 쓴 글, 사람이 검토하지 않음)
- 날짜: 2026-07-27T14:00
- 링크: https://choi-newsletter.com/post/review-moonshot-k3-full-stack-open
- 답하는 질문: Kimi K3 가중치와 함께 공개된 도구
- 직답: 문샷AI는 K3 가중치와 함께 어텐션 커널 FlashKDA, MoE 통신 라이브러리 MoonEP, 에이전트 환경 AgentENV를 MIT 라이선스로 공개했습니다.
- 출처: Moonshot AI X, Kimi K3 가중치·기술 보고서 공개 (7월 27일) (https://x.com/Kimi_Moonshot/status/2081760186235289764), Moonshot AI, Kimi K3 기술 블로그 (https://www.kimi.com/blog/kimi-k3), Kimi K3 모델 카드 (Hugging Face) (https://huggingface.co/moonshotai/Kimi-K3), Kimi K3 라이선스 (https://huggingface.co/moonshotai/Kimi-K3/blob/main/LICENSE), MoonshotAI/FlashKDA, H20 벤치마크 (https://github.com/MoonshotAI/FlashKDA/blob/master/BENCHMARK_H20.md), MoonshotAI/MoonEP (https://github.com/MoonshotAI/MoonEP), kvcache-ai/AgentENV (https://github.com/kvcache-ai/AgentENV), MoonshotAI/Kimi-Vendor-Verifier, K3 업체별 점수 (https://github.com/MoonshotAI/Kimi-Vendor-Verifier), Moonshot AI, Kimi Vendor Verifier 소개 글 (https://www.kimi.com/blog/kimi-vendor-verifier), MoonshotAI/K2-Vendor-Verifier, 업체별 도구 호출 정확도 (https://github.com/MoonshotAI/K2-Vendor-Verifier), vLLM, Kimi K2 도구 호출 정확도 디버깅 (2025년 10월) (https://vllm.ai/blog/Kimi-K2-Accuracy), vLLM, Kimi K3 지원 예고 (7월 22일) (https://vllm.ai/blog/2026-07-22-kimi-k3-preview), vLLM, Kimi K3 첫날 지원 (7월 27일) (https://vllm.ai/blog/2026-07-27-k3), Kimi Team, Kimi Linear 논문 (arXiv 2510.26692) (https://arxiv.org/abs/2510.26692), DeepSeek, Open Infra Index (오픈소스 주간·추론 엔진 공개 방침) (https://github.com/deepseek-ai/open-infra-index), DeepSeek X, 오픈소스 주간 2일 차 DeepEP (2025년 2월) (https://x.com/deepseek_ai/status/1894211757604049133), kvcache-ai/Mooncake (https://github.com/kvcache-ai/Mooncake)
> 문샷AI가 7월 27일 Kimi K3 가중치를 공개하며 FlashKDA·MoonEP·AgentENV를 함께 풀었고, 11분 뒤 서빙 업체 7곳의 검증 점수가 올라왔습니다. 지난해 K2는 vLLM에서 도구 호출 1,200여 건 중 218건만 제대로 처리될 만큼 흔들렸습니다.

문샷AI가 7월 27일(미국 시각) Kimi K3의 가중치와 기술 보고서를 공개하면서, 이 모델을 만들고 돌리는 데 쓴 도구 세 가지도 함께 연다고 밝혔습니다. 어텐션 커널 FlashKDA, MoE 통신 라이브러리 MoonEP, 에이전트 환경 실행 시스템 AgentENV이고, 셋 다 누구나 고쳐 쓸 수 있는 MIT 라이선스입니다. 공지가 올라오고 11분 뒤에는 K3를 자기 서버에 올려 파는 업체 7곳의 검증 점수가 문샷 공식 API 점수와 함께 올라왔습니다.

공지는 한국 시각 28일 0시 14분 Kimi 공식 X 계정에 올라왔습니다. K3는 2조 8,000억 파라미터의 MoE(입력마다 일부 전문가 모듈만 골라 계산하는 구조) 모델로 시각 이해와 100만 토큰 컨텍스트를 갖췄고, 문샷은 새 구조 덕분에 연산 단위당 지능이 K2의 약 2.5배라고 적었습니다. 이어서 K3 뒤에 있는 스택을 더 열겠다며 고성능 어텐션 커널(GPU가 실제로 돌리는 계산 프로그램), MoE 통신 라이브러리, 에이전트 환경을 대규모로 돌리는 인프라를 꼽았습니다.

같은 밤 올라온 기술 보고서 초록은 2조 8,000억 규모를 받친 인프라로 KDA에 맞춘 알고리즘·시스템 공동 설계, 메모리를 아끼면서 완전히 균형을 맞춘 전문가 병렬 학습, 실행 기록과 샌드박스 상태를 보존하는 100만 토큰 에이전트 강화학습, 배포 기술을 들었습니다. 앞의 셋은 이번에 연 세 도구와 짝이 맞습니다.

## 그날 새로 나온 것과 이미 나와 있던 것

문샷은 7월 16일 [K3를 발표하면서](/post/news-kimi-k3-open-weight-frontier) 가중치를 27일까지 풀겠다고 약속했습니다. 약속한 날 공개된 것과 저장소 기록은 이렇습니다.

| 공개물 | 하는 일 | 저장소 기록 | 라이선스 |
| --- | --- | --- | --- |
| Kimi K3 | 2조 8,000억 파라미터 모델 가중치와 기술 보고서 | 7월 27일 첫 커밋 | Kimi K3 라이선스 |
| FlashKDA | K3의 어텐션(KDA)을 계산하는 GPU 커널 | 4월 21일 첫 커밋 | MIT |
| MoonEP | 전문가 모듈을 나눠 가진 GPU끼리 토큰을 주고받는 통신 라이브러리 | 7월 27일 첫 커밋 | MIT |
| AgentENV | 강화학습용 에이전트 샌드박스를 대량으로 띄우는 시스템 | 7월 25일 첫 공개 커밋 | MIT |
| Kimi Vendor Verifier | 서빙 업체가 모델을 제대로 돌리는지 채점하는 도구 | 1월 27일 첫 커밋, 7월 27일 K3 시험 추가 | MIT |

모두가 그날 처음 나온 것은 아닙니다. FlashKDA는 4월 21일 첫 커밋이 올라오고 다음 날 설계 설명 글까지 붙은 3개월 된 저장소이고, AgentENV에는 7월 25일 「첫 오픈소스 공개」라는 커밋이 먼저 올라와 있었습니다. 27일 밤 새로 나온 것은 가중치와 MoonEP, 그리고 K3 시험을 더한 검증 도구였고, 문샷은 이것들을 공지 하나에 묶어 소개했습니다. 모델 파일 옆에 도구와 채점표까지 붙인 이유는 1년 전 Kimi K2에서 겪은 일에 있습니다.

## 남의 서버에서 흔들린 K2

문샷은 2025년 7월 1조 파라미터 모델 Kimi K2의 가중치를 풀었습니다. 가중치가 공개되면 누구나 자기 서버에 모델을 올려 API로 팔 수 있고(서빙), 실제로 여러 클라우드와 추론 업체가 K2를 올렸습니다. 문제는 도구 호출에서 나왔습니다. 에이전트는 검색이나 코드 실행 같은 도구를 정해진 JSON 형식으로 부르는데, 어느 서버에서 돌리느냐에 따라 이 형식이 깨지는 비율이 달랐습니다.

가장 극단적인 기록은 오픈소스 추론 엔진(모델을 서버에서 돌려 주는 소프트웨어) vLLM의 블로그에 남아 있습니다. 지난해 10월 올라온 글을 보면, 베이징대 연구자가 K2-Instruct-0905를 vLLM 0.11.0에 올려 문샷의 검증 도구로 재 보니 도구를 불렀어야 할 1,200여 건 가운데 제대로 해석된 호출이 218건으로 20%에 못 미쳤습니다. 같은 시험에서 문샷 공식 API는 도구 호출 1,286건을 형식 오류 없이 처리했습니다.

원인은 가중치 바깥에 있었습니다. vLLM이 보안상 이유로 채팅 템플릿에 넘기는 인자를 걸러 내면서 어시스턴트 차례를 알리는 신호가 빠졌고, 빈 문자열을 목록으로 바꾸는 내부 변환 때문에 프롬프트에 엉뚱한 글자가 끼었으며, 도구 호출 ID를 읽는 파서는 형식에서 조금만 벗어나도 호출을 버렸습니다. 문샷이 템플릿을 고치자 성공한 호출은 971건으로 4.4배가 됐습니다. 그래도 공식 API에는 요청에 없는 도구를 부르지 못하게 막는 「인포서(Enforcer)」가 따로 있어서, vLLM으로는 그 차이까지 메우지 못했습니다.

문샷은 지난해 9월 업체별 K2 도구 호출 정확도를 재는 K2 Vendor Verifier를 공개했습니다. 11월 15일 K2 Thinking으로 잰 결과를 보면, 모델이 부른 도구 호출이 요구한 형식을 지킨 비율이 업체마다 크게 갈렸습니다.

| 서빙 주체 | 도구 호출 형식 정확도 (2025년 11월 15일) |
| --- | --- |
| 문샷 공식 API | 100.00% |
| Fireworks | 100.00% |
| SiliconFlow | 98.96% |
| SGLang (오픈소스 엔진) | 95.52% |
| vLLM (오픈소스 엔진) | 87.22% |
| 구글 버텍스 | 85.76% |
| Together | 84.63% |
| Chutes | 83.05% |

같은 가중치를 받아서 한 업체는 100번 중 100번, 다른 업체는 100번 중 83번만 형식을 지켰습니다. 에이전트는 도구 호출이 수십 번 이어지는 작업이라, 문샷 표현대로 도구 오류가 단계마다 쌓여 커집니다. 문샷은 이런 차이가 사용자 경험은 물론 여러 벤치마크의 K2 점수까지 흔들었다고 적었습니다.

올해 1월 K2.5를 내놓으면서 문샷은 이 도구를 Kimi Vendor Verifier(KVV)로 넓혀 공개했습니다. 소개 글에는 K2 Thinking 이후 벤치마크 점수가 이상하다는 제보가 잦았고, 조사해 보니 제3자 API와 공식 API의 차이가 곳곳에서 나타났다고 적었습니다. 가중치가 열리고 배포 경로가 다양해질수록 품질은 통제하기 어려워진다는 진단도 붙였습니다.

> 모델을 오픈소스로 푸는 일은 절반에 불과하다는 걸 어렵게 배웠습니다. 나머지 절반은 그 모델이 다른 모든 곳에서도 제대로 돌게 하는 일입니다.
> — 문샷AI, Kimi Vendor Verifier 소개 글

## KDA가 추론 엔진에 요구한 것

vLLM은 K3 예고 글에서 이 모델이 서빙 문제를 여러 방향에서 한꺼번에 바꿨다고 적었습니다. 93개 층 가운데 69개가 Kimi Delta Attention(KDA)이고 24개만 전역 어텐션(MLA)입니다. 전역 어텐션은 지나간 토큰마다 계산 결과를 저장해 두고 새 토큰이 올 때마다 전부 다시 훑습니다. KDA는 토큰이 들어올 때마다 크기가 정해진 상태 하나를 고쳐 쓰기 때문에, 문맥이 길어져도 저장할 양이 늘지 않습니다.

![KDA 층과 전역 어텐션(MLA) 층의 캐시를 비교한 도식. KDA 층은 요청 하나에 층마다 약 6MB의 상태를 문맥 길이와 상관없이 유지하고, MLA 층은 토큰마다 1.125KB를 쌓아 100만 토큰이면 층당 약 1.18GB가 됩니다.](https://vllm.ai/blog-assets/figures/2026-07-27-k3/hybrid-cache.png)

vLLM이 공개 당일 올린 그림에 두 방식의 차이가 숫자로 나와 있습니다. KDA 층은 요청 하나에 층마다 약 6MB의 상태를 들고 가고, 이 크기는 문맥 길이와 상관이 없습니다. 전역 어텐션 층은 토큰 하나에 1.125KB씩 쌓아서 100만 토큰이면 층 하나에 약 1.18GB가 됩니다. 100만 토큰 컨텍스트를 감당하는 것도 층 대부분을 KDA로 채운 이 구조 덕분입니다.

어려움은 기존 추론 엔진이 토큰별 저장을 전제로 짜여 있다는 데서 생겼습니다. 앞부분이 같은 요청이 다시 들어오면 계산해 둔 결과를 재사용하는 프리픽스 캐시가 대표적입니다. 토큰별로 저장하는 층은 겹치는 앞부분의 블록만 가져오면 되지만, KDA 층은 겹치는 앞부분이 끝나는 바로 그 지점의 상태가 있어야 이어서 계산할 수 있습니다. vLLM은 K3를 위해 물리적 저장 단위와 프리픽스를 맞춰 보는 단위를 떼어 내는 식으로 캐시 관리자의 기본 설계를 고쳤다고 밝혔습니다.

이 캐시는 가격과 바로 이어집니다. 문샷은 K3 API 가격을 100만 토큰당 입력 3달러, 출력 15달러로 매기면서 캐시에서 읽는 입력은 0.3달러만 받습니다. 자사 서빙 시스템 Mooncake로 코딩 작업의 캐시 적중률이 90%를 넘는다고 했고, 블로그에는 KDA 프리픽스 캐시 덕분에 이 규모와 문맥 길이에도 경쟁력 있는 토큰 가격을 낼 수 있다고 적었습니다. 남의 서버에서 이 캐시가 돌지 않으면 같은 모델을 올리고도 문샷만큼 싸게 팔기 어렵습니다.

KDA를 엔진에 들이는 작업은 9개월 전부터 이어졌습니다. 2025년 10월 KDA를 처음 쓴 모델 Kimi Linear(전체 480억, 활성 30억 파라미터)를 내면서 KDA 커널과 vLLM 구현을 함께 공개했고, 100만 토큰 문맥에서 KV 캐시를 최대 75% 줄이고 디코딩 처리량을 최대 6배로 높였다고 밝혔습니다. 올해 4월에는 엔비디아의 GPU 연산 라이브러리 CUTLASS로 다시 짠 FlashKDA를 냈습니다. 중국용 엔비디아 칩 H20에서 같은 계산을 하는 기존 오픈소스 구현(선형 어텐션 커널 모음 FLA의 Triton 커널)보다 1.85~2.31배 빨랐고, FLA는 FlashKDA가 설치돼 있으면 자동으로 이 커널을 쓰도록 연결했습니다.

27일 vLLM이 올린 K3 첫날 지원 글에는 이 커널이 실제로 어떻게 쓰였는지 나옵니다. vLLM은 FlashKDA를 곧바로 통합해 지원 GPU와 데이터 형식을 넓혔고, 외부 개발자 시카르 미슈라(Shikhar Mishra)가 H100에 맞춰 다시 다듬은 Flash-Flash-KDA를 내놓자 하루 만에 GB300 NVL72에서 검증해 합쳤습니다.

> 열린 커널을 서빙 커뮤니티가 넓히고, 독립 기여자가 개선하고, 그 결과가 곧바로 실제 서비스로 들어간 순환이었습니다.
> — vLLM 팀, Kimi K3 첫날 지원 발표

## 공지 11분 뒤 올라온 점수표

공개 전 검증도 따로 돌았습니다. vLLM이 22일 올린 예고 글에 따르면 문샷과 vLLM·인퍼랙트(Inferact) 팀이 함께 승인한 파트너들이 공개용과 같은 코드로 미리 배포를 시험했습니다. 발표와 가중치 공개 사이에 11일을 둔 것도 vLLM의 제안이었습니다. 가중치 공지 11분 뒤에는 KVV 저장소에 업체별 점수표가 올라왔고, 최대 사고량 설정에서 잰 문샷과 업체 7곳의 점수가 실렸습니다.

| 업체 | OCRBench | MMMU Pro Vision | BEAM (100만 토큰) | DeepSWE |
| --- | --- | --- | --- | --- |
| 문샷 | 0.89 | 0.82 | 0.31 | 0.675 |
| Fireworks | 0.89 | 0.82 | 0.3037 | 0.664 |
| Baseten | 0.889 | 0.804 | 0.2975 | 측정 중 |
| Together | 0.892 | 0.817 | 측정 중 | 측정 중 |
| DigitalOcean | 0.89 | 0.816 | 측정 중 | 측정 중 |
| Inferact | 0.893 | 측정 중 | 측정 중 | 측정 중 |
| Nebius | 0.878 | 0.814 | 측정 중 | 측정 중 |
| Modal | 0.887 | 0.817 | 0.322 | 측정 중 |

문자 인식(OCRBench)과 이미지 문제 풀이(MMMU Pro Vision)에서는 8곳이 거의 같은 점수를 냈습니다. 100만 토큰짜리 대화를 기억하는 BEAM과 에이전트 코딩 시험 DeepSWE는 아직 비어 있는 곳이 많았고, DeepSWE를 마친 곳은 문샷(0.675)과 Fireworks(0.664) 두 곳이었습니다. 공지 2시간 14분 전 처음 올라온 표에는 Baseten과 Together의 DeepSWE 점수가 0.574와 0.54로 적혀 있었는데, 공지 11분 뒤 갱신된 표에서는 두 점수가 빠지고 측정 중으로 표시됐습니다. 문샷은 이유를 따로 적지 않았습니다.

K3 라이선스에는 「인증 추론 파트너」라는 말이 나옵니다. 모델을 API로 파는 사업(모델을 서비스로 파는 MaaS)에서 연속 12개월 매출이 2,000만 달러를 넘으면 문샷과 별도 계약을 맺는 조건이 붙는데, 문샷 공식 제품이나 인증 추론 파트너를 거쳐 쓰는 경우는 이 조건에서 뺐습니다. 라이선스 문서에 인증 파트너 명단이나 인증 기준은 없고, 도구 저장소 셋은 이런 조건 없이 MIT로 풀렸습니다.

## 딥시크가 먼저 푼 목록

자사 모델 구조에 맞춘 커널과 통신 라이브러리를 묶어 푸는 방식은 딥시크가 먼저 썼습니다. 딥시크는 2025년 2월 24일부터 5일 동안 하루에 하나씩 저장소를 여는 「오픈소스 주간」을 열었고, 1일 차가 자사 어텐션(MLA)용 커널 FlashMLA, 2일 차가 전문가 병렬 통신 라이브러리 DeepEP였습니다.

전문가 병렬은 MoE 모델의 전문가 모듈을 여러 GPU에 나눠 두고, 토큰을 담당 전문가가 있는 GPU로 보냈다가 계산이 끝나면 다시 모으는 방식입니다. 토큰이 GPU 사이를 오가는 통신이 느리면 계산을 마친 GPU도 쉬게 됩니다. 딥시크는 DeepEP를 MoE 학습과 추론을 위한 첫 오픈소스 전문가 병렬 통신 라이브러리라고 소개했고, 이어서 FP8 행렬 곱 라이브러리 DeepGEMM, 파이프라인 병렬 알고리즘 DualPipe와 부하 분산기 EPLB, 병렬 파일 시스템 3FS를 차례로 공개했습니다.

그해 4월 딥시크는 학습은 파이토치, 추론 엔진은 vLLM을 바탕으로 만들었다고 밝히면서, 사내 추론 엔진 전체는 공개하지 않는 이유를 들었습니다. 1년도 더 된 vLLM 초기 버전에서 갈라져 나와 자사 모델에 맞춰 너무 많이 고쳤고, 사내 클러스터 관리 도구와 얽혀 있으며, 큰 오픈소스 프로젝트를 관리할 인력이 없다는 설명이었습니다. 대신 쓸모 있는 부품을 떼어 기존 오픈소스 프로젝트에 넣고, 새 모델을 내기 전에 추론 관련 작업을 미리 맞춰 공개 첫날부터 최고 수준으로 지원되게 하겠다고 약속했습니다.

| 부품 | 딥시크 (2025년 2월 오픈소스 주간) | 문샷 |
| --- | --- | --- |
| 자사 어텐션 커널 | FlashMLA (MLA용) | FlashKDA (KDA용), 2026년 4월 |
| 전문가 병렬 통신 | DeepEP | MoonEP, 2026년 7월 |
| 저장·전송 인프라 | 3FS (병렬 파일 시스템) | Mooncake (KV 캐시 전송·저장), 2024년부터 |
| 에이전트 강화학습 환경 | 공개 목록에 없음 | AgentENV, 2026년 7월 |
| 서빙 업체 검증 | 공개 목록에 없음 | K2 Vendor Verifier 2025년 9월, KVV 2026년 1월 |

MoonEP 저장소 첫 화면의 성능 비교 상대는 DeepEP v2이고, 영감을 준 작업을 적은 감사의 글 첫 줄에도 DeepEP를 올렸습니다. MoonEP가 푼 문제는 쏠림입니다. 라우터가 특정 전문가에 토큰을 몰아 주면 그 전문가를 가진 GPU가 가장 늦게 끝나고 나머지 GPU는 기다립니다. MoonEP는 라우터 출력을 보고 붐비는 전문가의 복제본을 그때그때 다른 GPU에 미리 옮겨, 쏠림이 얼마나 심하든 모든 GPU가 정확히 같은 수의 토큰을 받게 만듭니다.

![MoonEP와 DeepEP의 학습 반복 시간을 라우팅 쏠림 정도별로 비교한 선 그래프. MoonEP는 쏠림이 커져도 1.0 근처에서 평평하고, DeepEP는 쏠림이 작을 때 1.9%와 0.5% 빠르다가 3.9%, 7.6%, 11.1% 느려지고 가장 심한 조건에서 메모리 부족으로 멈춥니다.](https://raw.githubusercontent.com/MoonshotAI/MoonEP/51e64aa55310f6c6b464deabd80de2e8b5426d3f/figure/e2e_vs_deepep.png)

문샷이 올린 그래프에는 MoonEP가 지는 구간도 찍혀 있습니다. 가장 붐비는 전문가가 평균의 1.2배, 2배를 받는 비교적 고른 조건에서는 DeepEP가 1.9%, 0.5% 빨랐습니다. 평균의 6배를 받는 조건부터 DeepEP가 3.9% 느려지기 시작해 16배에서 11.1% 느려졌고, 21배에서는 GPU 메모리가 모자라 학습이 멈췄습니다. MoonEP는 모든 조건에서 반복 시간이 거의 그대로였습니다.

부품은 회사 경계를 넘어 얽혀 있습니다. vLLM은 K3 예고 글에서 K3의 활성 함수를 엔비디아 TRT-LLM과 딥시크 DeepGEMM의 MoE 계산 경로에 연결했다고 적었고, 첫날 글에서는 전문가 병렬 배포의 MoE 백엔드로 deep_gemm_mega_moe를 권했습니다. vLLM에서는 문샷 모델의 MoE를 딥시크 라이브러리로 계산하고, 문샷의 통신 라이브러리는 딥시크 라이브러리를 기준으로 성능을 잽니다.

## Mooncake의 2년

서빙 인프라를 푼 시점만 보면 문샷이 딥시크의 오픈소스 주간보다 8개월 빨랐습니다. 허깅페이스에 모델을 하나도 올리기 전인 2024년 6월, 문샷은 칭화대 MADSys 연구실과 업계 협력사들이 꾸린 오픈소스 조직 kvcache.ai와 함께 Kimi 서빙 플랫폼 Mooncake의 기술 보고서를 냈습니다. 대화마다 쌓이는 KV 캐시(모델이 앞 토큰을 처리하며 만든 중간 계산값)를 GPU 밖의 메모리와 저장 장치에 모아 여러 서버가 나눠 쓰는 구조로, 실제 트래픽에서 응답 시간 목표를 지키면서 요청을 75% 더 처리했다고 밝혔습니다.

| 시점 | 있었던 일 |
| --- | --- |
| 2024년 6월 | Mooncake 기술 보고서 공개 |
| 2024년 11월 | 중심 부품인 전송 엔진(Transfer Engine) 오픈소스 공개 |
| 2024년 12월 | vLLM이 Mooncake 전송 엔진 공식 지원 |
| 2025년 2월 | 파일·스토리지 학회 FAST 2025 최우수 논문상 |
| 2025년 7월 | H200 128장 규모 Kimi K2 배포에 사용 (LMSYS) |
| 2025년 12월 | 엔비디아 TensorRT-LLM과 vLLM v1에 통합 |
| 2026년 2월 | 파이토치 생태계 프로젝트로 합류 |
| 2026년 4월 | SGLang, 강화학습 중 1조 파라미터 K2 가중치 갱신을 53초에서 7.2초로 단축 |

Mooncake가 지원하는 하드웨어도 엔비디아에 그치지 않습니다. 7월 기준 저장소의 지원 목록에는 엔비디아와 AMD, AWS 옆에 화웨이, 캄브리콘, 무어스레드, 메타X, 티헤드, 하이곤 같은 중국 가속기 회사와 알리바바 클라우드가 올라 있습니다. 2년 전 Kimi 한 곳의 서빙 시스템으로 출발한 코드가 지금은 엔비디아 TensorRT-LLM 안에서도, 중국 가속기 위에서도 돌아갑니다.

AgentENV도 같은 kvcache.ai에서 나왔습니다. 에이전트 강화학습에서는 모델이 코드를 실행하고 파일을 고치는 격리된 가상 컴퓨터(샌드박스)를 수천 개씩 띄우고 멈추는 일이 반복됩니다. AgentENV는 가벼운 가상머신 기술 파이어크래커 위에서 스냅샷(실행 중인 상태를 통째로 저장한 사본)으로 샌드박스를 50밀리초 안에 띄우거나 되살리고 100밀리초 안에 멈추며, 돌던 샌드박스를 여러 갈래로 복제해 다른 시도를 이어 갈 수 있게 했습니다.

저장소에는 E2B 호환 API도 들어 있습니다. E2B는 에이전트용 샌드박스를 클라우드로 빌려주는 서비스인데, 기존 E2B 코드를 고치지 않고 접속 주소만 자기 AgentENV 서버로 바꾸면 그대로 돈다고 적었습니다. 다만 첫날 문서에는 아직 인증 기능이 없으니 공용 네트워크에 API를 노출하지 말라는 경고가 붙어 있었습니다.

## 누가 바로 쓸 수 있나

도구는 MIT로 풀렸어도 돌릴 장비는 따로 듭니다. FlashKDA는 엔비디아 호퍼(SM90) 이후 GPU와 CUDA 12.9 이상을 요구하고, MoonEP 시험은 NVLink로 묶인 여러 GPU에서 돌아갑니다. 모델 자체는 vLLM 기준으로 B300 8장이나 AMD MI355X 8장이 가장 쉬운 구성이고, B200 세대로는 최소 16장이 듭니다. AgentENV는 리눅스 커널 6.8 이상과 KVM 가상화가 켜진 서버에서 돌아갑니다.

첫날 vLLM 설정에서는 K3의 프리픽스 캐시가 기본으로 꺼져 있었습니다. vLLM은 하이브리드 캐시 설계가 아직 다듬어지는 중이라 기본값에서 뺐다며, 쓰려면 옵션을 직접 켜라고 안내했습니다. 캐시를 끈 채 K3를 돌리는 업체는 캐시 입력 0.3달러라는 문샷 가격을 따라가기 어렵습니다.

성능표는 모두 문샷이 잰 값이고, 잰 장비도 한 가지입니다. FlashKDA와 MoonEP의 비교표는 전부 H20에서 나왔고, K3 블로그의 SWE-Marathon 점수는 GPU 과제를 H20에 맞춰 다시 보정한 버전으로, PostTrainBench는 공식 설정의 H100 대신 H20으로 쟀습니다. H20은 엔비디아가 미국 수출 규제에 맞춰 성능을 낮춘 중국용 칩입니다. 문샷이 가진 장비에서 나온 숫자라, H100이나 B200에서 같은 차이가 나는지는 외부 재현이 나와야 알 수 있습니다.

## 한국에서 달라지는 것

국내에서 K3를 쓰는 방법은 문샷 API, 해외 추론 업체 API, 직접 올리기 세 가지입니다. 해외 업체를 고를 때는 이제 가격과 속도 옆에 KVV 점수를 놓고 볼 수 있습니다. 지난해 K2 Thinking의 도구 호출 형식 정확도가 업체에 따라 83%에서 100%까지 갈렸던 만큼, 에이전트 업무에 쓸 업체라면 DeepSWE 같은 에이전트 시험 점수가 채워졌는지가 먼저 걸립니다.

모델을 직접 만드는 팀에는 MoonEP가 가까운 도구입니다. 국내에서도 [업스테이지가 7월 22일 공개한 Solar Open 2](/post/news-upstage-solar-open2-onprem)가 전체 2,500억 개 중 토큰마다 150억 개만 쓰는 MoE 모델이고, MoE를 여러 GPU에 나눠 학습하면 쏠림 문제는 따라옵니다. MIT 라이선스라 고쳐 쓰거나 제품에 넣는 데 조건이 붙지 않습니다. AgentENV는 샌드박스를 빌려 쓰던 에이전트 스타트업이 같은 코드로 자기 서버에 옮겨 볼 수 있는 선택지이고, 첫날 코드는 내부망에서 쓰는 것을 전제로 합니다.

저는 이번 공개에서 가장 오래 쓰일 것으로 KVV를 꼽습니다. 모델은 다음 세대가 나오면 교체되지만, 서빙 업체를 같은 시험으로 채점하는 틀은 다음 모델에도 그대로 쓰이기 때문입니다. 공개 첫날 표에 오른 8곳 중 6곳의 DeepSWE가 측정 중이었고, MoonEP 지원 장비 목록에는 알리바바 계열 칩 진우(Zhenwu) PPU가 심사 중으로 올라 있습니다. 표가 채워지면 다시 전하겠습니다.

읽어 주셔서 고맙습니다.

초이 드림