Kimi K2.7-Code 공개, 긴 코딩 작업에서 생각 토큰을 30% 줄인 오픈 모델

무엇이 나왔나

• Moonshot AI가 코딩 특화 오픈 모델 Kimi K2.7-Code를 공개함

  • Kimi K2.6을 기반으로 만든 에이전트형 코딩 모델임
  • 목표는 단발성 코드 생성보다, 복잡한 소프트웨어 엔지니어링 작업을 끝까지 수행하는 쪽에 가까움
  • 모델 저장소와 가중치는 수정 MIT 라이선스로 공개됨

• 가장 눈에 띄는 숫자는 ‘생각 토큰 약 30% 감소’임

  • Moonshot은 K2.7-Code가 K2.6 대비 생각 토큰 사용량을 약 30% 줄였다고 설명함
  • 코딩 에이전트에서는 추론 토큰이 곧 비용과 지연시간이라, 이 숫자는 그냥 홍보 문구로 넘기기 애매함
  • 긴 작업을 많이 돌리는 팀이라면 모델 성능만큼이나 토큰 효율이 바로 운영비로 이어짐

벤치마크와 사용 조건

• 벤치마크는 꽤 에이전트 지향으로 구성됨

  • 자체 벤치마크인 Kimi Code Bench V2는 백엔드, 인프라, 성능 엔지니어링, 시스템 프로그래밍, 보안, 프런트엔드, 머신러닝·데이터 엔지니어링 등을 포함한다고 밝힘
  • Program Bench는 컴파일된 바이너리와 문서만 보고 프로그램 동작을 재현하는 200개 과제로 구성됨
  • 제출물은 248,000개 이상의 퍼즈 생성 행동 테스트로 원본 바이너리와 비교됨

• 장기 작업 평가도 들어감

  • Kimi Claw 24/7 Bench는 여러 날 지속되는 동료 작업 시나리오를 평가하는 자체 벤치마크임
  • 17개 전문 시나리오와 610개 평가 포인트를 포함하고, 소프트웨어 엔지니어링뿐 아니라 머신러닝 연구, 리크루팅, 트레이딩, 마케팅까지 다룸
  • 결과는 OpenClaw 하네스에서 3회 실행 평균으로 계산됨

• 도구 사용 벤치마크도 빠지지 않음

  • MCP-Atlas는 현실적인 도구 사용 작업을 평가하고, 설정은 100회 도구 호출 예산과 단계당 최대 32,000토큰임
  • MCPMark-Verified는 Notion, GitHub, 파일시스템, Postgres, Playwright 같은 실제 서버 환경에서 MCP 도구 사용을 평가함
  • 이것도 100단계 도구 호출 예산과 단계당 32,000토큰 설정으로 3회 평균을 냄

배포와 실행 방식

• 배포 경로는 실무자가 바로 알아볼 만한 조합임

  • vLLM, SGLang, KTransformers를 권장 추론 엔진으로 제시함
  • Kimi K2.5, K2.6과 같은 아키텍처라 기존 배포 방식을 재사용할 수 있다고 밝힘
  • Transformers 버전 요구사항은 4.57.1 이상, 5.0.0 미만임

• 자체 API도 OpenAI·Anthropic 호환 형태로 제공됨

  • 공식 API는 platform.moonshot.ai에서 접근 가능하다고 안내함
  • vLLM이나 SGLang으로 띄우면 OpenAI 호환 채팅 완성 API처럼 호출하는 예제가 제공됨
  • Docker Model Runner로는 hf.co/moonshotai/Kimi-K2.7-Code 형태 실행도 안내됨

• 네이티브 int4 양자화를 채택함

  • Kimi-K2-Thinking과 같은 native int4 quantization 방식을 쓴다고 설명함
  • 대형 코딩 모델을 직접 올릴 때 GPU 메모리 부담을 낮추는 쪽의 선택임

에이전트 기능 쪽 디테일

• K2.7-Code는 생각 모드를 강제하는 설계임

  • 권장 temperature는 1.0, top_p는 0.95로 제시됨
  • 즉시 모드는 지원하지 않는다고 밝힘
  • preserve_thinking이 기본 활성화되어 있고 끌 수 없음

• preserve_thinking은 멀티턴 코딩 에이전트에서 중요한 기능임

  • 이전 턴의 추론 내용을 보존해 다음 턴에서 이어갈 수 있게 하는 방식임
  • 예제로는 모델이 내부 추론에서 떠올린 숫자를 다음 사용자 질문에서 기억해 답하는 흐름을 보여줌
  • 실제 개발 작업에서는 ‘왜 이렇게 고쳤는지’의 맥락을 다음 단계로 넘기는 데 영향을 줄 수 있음

• 이미지와 비디오 입력도 지원함

  • 이미지 입력 예제는 공식 API와 OpenAI 호환 메시지 포맷을 사용함
  • 비디오 입력은 현재 공식 API에서만 실험적으로 지원된다고 적혀 있음
  • 제3자 API로 vLLM이나 SGLang을 쓸 때는 비디오 지원 범위가 제한됨

• Kimi Code CLI와 함께 쓸 때 가장 잘 맞는다고 안내함

  • Moonshot은 Kimi K2.7-Code가 Kimi Code CLI를 코딩 에이전트 프레임워크로 사용할 때 가장 잘 작동한다고 설명함
  • Interleaved Thinking과 Multi-Step Tool Call 설계는 K2 Thinking과 같은 방향이라고 밝힘

---

기술 맥락

• Kimi K2.7-Code의 핵심 선택은 모델을 ‘코드 생성기’가 아니라 ‘코딩 에이전트용 실행 엔진’으로 잡은 거예요. 그래서 평가도 단순 문제풀이보다 긴 작업, 도구 호출, 실제 프로젝트형 과제 쪽으로 많이 기울어져 있어요.

• 생각 토큰 30% 절감이 중요한 이유는 에이전트가 한 번 답하고 끝나지 않기 때문이에요. 파일 읽기, 수정, 테스트, 재시도, 도구 호출을 반복하면 추론 토큰이 계속 쌓이고, 그게 곧 비용과 응답 지연으로 돌아오거든요.

• vLLM, SGLang, KTransformers를 배포 경로로 둔 것도 실무적인 선택이에요. 연구용 데모가 아니라 사내 개발 도구나 자동화 파이프라인에 붙이려면 OpenAI 호환 API, 컨텍스트 길이, GPU 메모리 효율이 같이 맞아야 해요.

• preserve_thinking을 끌 수 없게 한 건 성능 쪽에는 유리할 수 있지만 운영 정책상 검토할 부분도 생겨요. 멀티턴 작업 맥락을 강하게 유지하는 대신, 추론 내용 보존이 로깅·프라이버시·비용 관리와 어떻게 맞물리는지 봐야 하거든요.

• 결국 이 모델은 “벤치마크 점수가 몇 점이냐”보다 “우리 팀의 장기 코딩 작업에서 비용 대비 완료율이 좋아지냐”로 평가하는 게 맞아요. 특히 자체 호스팅을 고려한다면 int4 양자화와 추론 엔진 지원이 실제 도입 난이도를 크게 좌우해요.