# Kimi K2.7-Code: 토큰 효율이 개선된 오픈소스 코딩 모델 > Clean Markdown view of GeekNews topic #30441. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=30441](https://news.hada.io/topic?id=30441) - GeekNews Markdown: [https://news.hada.io/topic/30441.md](https://news.hada.io/topic/30441.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-06-13T09:52:31+09:00 - Updated: 2026-06-13T09:52:31+09:00 - Original source: [huggingface.co](https://huggingface.co/moonshotai/Kimi-K2.7-Code) - Points: 1 - Comments: 1 ## Topic Body - 장기 코딩 작업과 복잡한 소프트웨어 엔지니어링 워크플로를 다루는 **에이전트형 코딩 모델**로, Kimi K2.6 기반에서 엔드투엔드 작업 완료 능력과 토큰 사용 효율을 높였음 - **Kimi K2.6 대비** 사고 토큰 사용량을 약 30% 줄였고, Kimi Code Bench v2는 50.9에서 62.0, MCP Mark Verified는 72.8에서 81.1로 상승함 - 모델 구조는 **MoE** 기반이며 총 1T 파라미터, 활성 32B 파라미터, 256K 컨텍스트 길이, MoonViT 비전 인코더를 갖춤 - 배포는 공식 API와 vLLM, SGLang, KTransformers를 대상으로 하며, **Kimi-K2.5/Kimi-K2.6**과 같은 아키텍처라 기존 배포 방식을 재사용할 수 있음 - 사용 시 Thinking 모드와 **preserve_thinking**이 강제되며, 이미지 입력을 지원하고 비디오 입력은 현재 공식 API에서만 실험적으로 지원됨 --- ### 모델 개요 - [Kimi K2.7-Code](https://huggingface.co/moonshotai/Kimi-K2.7-Code)는 Kimi K2.6 기반의 코딩 중심 에이전트 모델이며, 현실적인 장기 코딩 작업에서 개선됐음 - 복잡한 소프트웨어 엔지니어링 워크플로 전반에서 **엔드투엔드 작업 완료** 능력을 강화함 - Kimi K2.6과 비교해 사고 토큰 사용량을 약 **30%** 줄여 토큰 효율을 높였음 - 이미지-텍스트 입력, Transformers, Safetensors, conversational, custom_code 등의 태그와 함께 제공됨 ### 모델 요약 - 아키텍처는 **Mixture-of-Experts(MoE)** 이며 총 파라미터는 1T, 활성 파라미터는 32B임 - 레이어 수는 Dense 레이어 포함 61개이며, Dense 레이어는 1개임 - Attention Hidden Dimension은 7168, MoE Hidden Dimension은 전문가당 2048임 - Attention Head는 64개, Expert는 384개, 토큰당 선택 Expert는 8개, Shared Expert는 1개임 - 어휘 크기는 160K이고 컨텍스트 길이는 **256K**임 - Attention 메커니즘은 MLA, 활성화 함수는 SwiGLU임 - 비전 인코더는 MoonViT이며, 비전 인코더 파라미터는 400M임 ### 평가 결과 - ## 코딩 벤치마크 - **Kimi Code Bench v2**에서 Kimi K2.6은 50.9, Kimi K2.7 Code는 62.0, GPT-5.5는 69.0, Claude Opus 4.8은 67.4를 기록함 - **Program Bench**에서 Kimi K2.6은 48.3, Kimi K2.7 Code는 53.6, GPT-5.5는 69.1, Claude Opus 4.8은 63.8을 기록함 - **MLS Bench Lite**에서 Kimi K2.6은 26.7, Kimi K2.7 Code는 35.1, GPT-5.5는 35.5, Claude Opus 4.8은 42.8을 기록함 - ## 에이전트 벤치마크 - **Kimi Claw 24/7 Bench**에서 Kimi K2.6은 42.9, Kimi K2.7 Code는 46.9, GPT-5.5는 52.8, Claude Opus 4.8은 50.4를 기록함 - **MCP Atlas**에서 Kimi K2.6은 69.4, Kimi K2.7 Code는 76.0, GPT-5.5는 79.4, Claude Opus 4.8은 81.3을 기록함 - **MCP Mark Verified**에서 Kimi K2.6은 72.8, Kimi K2.7 Code는 81.1, GPT-5.5는 92.9, Claude Opus 4.8은 76.4를 기록함 - ## 평가 조건 - 별도 명시가 없으면 Kimi K2.7 Code와 K2.6은 Kimi Code CLI에서 Thinking 모드를 켜고 temperature 1.0, top-p 0.95, 262,144 토큰 컨텍스트 길이로 테스트됨 - GPT-5.5는 Codex의 xhigh 모드에서 실행됐고, Opus 4.8은 Claude Code의 xhigh 모드에서 실행됨 - 그 외 차이를 제외하면 모든 벤치마크는 같은 조건에서 평가됨 - ## 벤치마크 구성 - Kimi Code Bench V2는 현실적인 작업에서 코딩 에이전트를 평가하는 내부 벤치마크이며, 10개 이상 주요 프로그래밍 언어와 전체 프로덕션 기술 스택을 다룸 - Kimi Code Bench V2는 내부 엔지니어링 사용 사례, 프로덕션 장애, 실제 오픈소스 프로젝트의 작업을 포함함 - [Program Bench](https://programbench.com/)는 컴파일된 바이너리와 문서만으로 프로그램 동작을 재현하도록 요구하며, 200개 작업과 248,000개 이상의 퍼즈 생성 동작 테스트를 사용함 - [MLS-Bench](https://mls-bench.com)는 AI 시스템이 일반화 가능하고 확장 가능한 ML 방법을 만들 수 있는지 평가하며, MLS-Bench-Lite는 공식 30개 작업 하위 집합임 - Kimi Claw 24/7 Bench는 지속적인 다일 공동 작업에서 장기 에이전트 성능을 평가하는 내부 벤치마크이며, 17개 전문 시나리오와 610개 평가 지점을 다룸 - [MCP-Atlas](https://labs.scale.com/leaderboard/mcp_atlas)는 확장 가능한 MCP를 통해 현실적인 도구 사용 작업에서 LLM 성능을 평가함 - MCPMark-Verified는 [MCPMark](https://mcpmark.ai/)의 사람 검증판이며 Notion, GitHub, Filesystem, Postgres, Playwright 등 5개 실제 서버 환경에서 MCP 도구 사용을 평가함 ### Native INT4 양자화 - Kimi-K2.7-Code는 [Kimi-K2-Thinking](https://huggingface.co/moonshotai/Kimi-K2-Thinking#4-native-int4-quantization)과 같은 **native int4 양자화** 방식을 채택함 ### 배포 - Kimi-K2.7-Code API는 https://platform.moonshot.ai 에서 접근할 수 있음 - 공식 API는 **OpenAI/Anthropic 호환 API**를 제공함 - 권장 추론 엔진은 vLLM, SGLang, KTransformers임 - Kimi-K2.7-Code는 Kimi-K2.5/Kimi-K2.6과 같은 아키텍처라 배포 방식을 직접 재사용할 수 있음 - `transformers` 버전 요구사항은 `>=4.57.1, <5.0.0`임 - 배포 예시는 [Model Deployment Guide](https://huggingface.co/moonshotai/Kimi-K2.7-Code/blob/main/docs/deploy_guidance.md)에서 확인할 수 있음 ### 사용 방법 - ## API 호출 기본 조건 - 사용 데모는 공식 API 호출 방식을 기준으로 함 - Kimi-K2.7-Code는 Thinking과 `preserve_thinking`을 True로 강제함 - vLLM 또는 SGLang으로 배포한 서드파티 API에서는 비디오 콘텐츠 채팅이 현재 공식 API에서만 지원되는 실험 기능임 - Thinking 모드의 권장 `temperature`는 `1.0`이고 권장 `top_p`는 `0.95`임 - Instant 모드는 지원되지 않음 - ## Chat Completion - Chat Completion 예시는 K2.7-Code API를 Thinking 모드로 호출함 - 예시 코드는 `openai` 클라이언트로 `client.chat.completions.create`를 호출하고 `max_tokens=4096`을 설정함 - 응답에서는 `response.choices[0].message.reasoning`과 `response.choices[0].message.content`를 출력함 - ## 시각 콘텐츠 입력 - K2.7-Code는 **이미지와 비디오 입력**을 지원함 - 이미지 입력 예시는 이미지를 base64로 인코딩해 `image_url`에 전달하고 `max_tokens=8192`로 응답을 생성함 - 비디오 입력 예시는 mp4 파일을 base64로 인코딩해 `video_url`에 전달함 - 비디오 채팅은 현재 공식 API에서만 지원되는 실험 기능임 - ## Preserve Thinking - Kimi K2.7 Code는 `preserve_thinking` 모드를 강제하며, 멀티턴 상호작용에서 전체 reasoning 콘텐츠를 유지함 - `preserve_thinking`은 코딩 에이전트 시나리오의 성능을 높임 - 이 기능은 기본으로 활성화되며 비활성화할 수 없음 - 일부 API는 `reasoning_content`를 지원하지 않을 수 있어 `reasoning`을 시도할 수 있음 - ## Interleaved Thinking과 다단계 도구 호출 - K2.7-Code는 K2 Thinking과 같은 **Interleaved Thinking** 및 Multi-Step Tool Call 설계를 공유함 - 사용 예시는 [K2 Thinking documentation](https://platform.moonshot.ai/docs/guide/use-kimi-k2-thinking-model#complete-example)를 참조함 - ## 코딩 에이전트 프레임워크 - Kimi K2.7-Code는 에이전트 프레임워크로 Kimi Code CLI와 함께 사용할 때 가장 잘 작동함 - Kimi Code CLI는 https://www.kimi.com/code 에서 제공됨 ### 로컬 실행 예시 - ## Transformers - Transformers에서는 `pipeline("image-text-to-text", model="moonshotai/Kimi-K2.7-Code", trust_remote_code=True)` 방식으로 고수준 파이프라인을 만들 수 있음 - 모델 직접 로드는 `AutoModel.from_pretrained("moonshotai/Kimi-K2.7-Code", trust_remote_code=True, dtype="auto")` 방식으로 가능함 - ## vLLM - vLLM은 `pip install vllm`로 설치하고 `vllm serve "moonshotai/Kimi-K2.7-Code"`로 서버를 시작함 - 호출 예시는 OpenAI 호환 API 엔드포인트인 `http://localhost:8000/v1/chat/completions`를 사용함 - Docker Model Runner에서는 `docker model run hf.co/moonshotai/Kimi-K2.7-Code`로 실행함 - ## SGLang - SGLang은 `pip install sglang`으로 설치하고 `python3 -m sglang.launch_server --model-path "moonshotai/Kimi-K2.7-Code"`로 서버를 시작함 - 호출 예시는 OpenAI 호환 API 엔드포인트인 `http://localhost:30000/v1/chat/completions`를 사용함 - Docker 실행 예시는 GPU, 공유 메모리, Hugging Face 캐시, `HF_TOKEN` 환경변수를 설정함 ### 라이선스 - 코드 저장소와 모델 가중치는 [Modified MIT License](https://huggingface.co/moonshotai/Kimi-K2.7-Code/blob/main/LICENSE)로 배포됨 ## Comments ### Comment 59517 - Author: neo - Created: 2026-06-13T09:52:31+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48502347) - 수정된 라이선스 조항을 읽어보니 웃겼음. 사실상 **MIT 라이선스**에 예전 BSD에 있던 광고 조항 하나를 붙인 형태이고, 월간 활성 사용자나 매출과 무관하게 제품에 쓰면 자기들을 “광고”해 달라는 요구에 가까움 솔직히 합리적인 요청으로 보임 - 이게 **Cursor 저격 조항**처럼 보임. 공개하라고 망신 주게 만들지 말라는 뜻임 - 여기서 “광고” 조항은 제품 어딘가에 사용 사실을 밝히라는 정도임. 예를 들어 “About” 섹션의 크레딧에 넣는 식임 - 급하게 덧붙인 느낌이 있음. “사용자 인터페이스”에 무엇이 포함되는지에 대해 법률 문구를 좀 더 다듬었을 줄 알았음 - Kimi K2.7-code에 꽤 단순한 지시만 줘서 **Fil-C OpenSSL 패치**를 3.3.1에서 3.5.7로 리베이스했는데, 잘 된 것처럼 보임 패치 크기는 177KB라 작은 변경은 아니었고, 처음에는 깔끔하게 적용되지 않아 에이전트가 꽤 실질적인 작업을 해야 했음 3.3.1 대상 패치, 빌드 명령, 3.5.7 경로, 변경 문서 링크([https://fil-c.org/constant_time_crypto]())만 줬음 다만 자체 코딩 에이전트인 T800을 썼고, 공개된 것은 아니며 이전에 K2.5용으로 충분히 테스트하고 튜닝해 둔 상태였음 API 사용료는 **$5~$10** 사이였던 것 같음. 수정: OpenSSH가 아니라 OpenSSL임 - 개인적으로 오픈 코드나 라우터를 쓸 때는 일정 수준을 넘으면 모델 차이가 크게 느껴지지 않음. 비싸고 애매한 Gemini 같은 모델은 예외임 그런 의미에서 중국 모델들은 꽤 괜찮음. 보통 함수나 메서드 단위로 코드를 작성하게 한 뒤 설계하고 조립하는 방식으로 씀 GPT 계열이 더 꼼꼼하고 낫긴 하지만 차이가 엄청난지는 잘 모르겠음. 작업 흐름에 따라 다르겠지만, 충분히 엄격하게 다루면 큰 차이가 정말 있는지 의문임 - “무료” 추론 라우터는 어느 정도 포기했음. 예상대로 추론을 최대한 아끼려 하다 보니 사고 품질이 떨어지는 경우가 많음 MacBook M1 Pro를 난방 패드로 만들면서 **Qwen 3.6 35B A3B MTP**를 돌려본 것은 어느 정도 성공적이었음 Gemini 모델을 “로컬”처럼 쓰려 하니 노력량을 짧게 끊어 실수가 많고 턴이 늘어나는 비슷한 문제가 있었음 반대로 Fable이 끈질기게 “선제적”이라는 얘기를 보면, 강한 브랜딩과 효과적인 과금이 있으면 정반대 방향도 가능해 보임 - 내 경험상 개별 함수 구현에서는 **최전선 모델**과 최신 30B급 모델 사이 차이가 거의 없음 일관된 설계가 이미 있으면, 그게 어려운 부분인데, 꽤 작은 모델에 넣어도 거의 같은 품질을 얻을 수 있음 한 번에 완성하지는 못하지만 더 빠르고 저렴해서 결국 유리하게 작동함. 게다가 로컬에서도 가능함 - 결과 차이는 크지 않지만, 더 엄격하게 다뤄야 하는 건 맞음. 예를 들어 **Kimi K2.5/K2.6**은 자신이 방금 만든 문제를 고치기보다 실패하는 테스트를 “기존 실패”로 착각하고 주석 처리하는 경우가 있었음 그래서 주석 처리된 테스트가 빌드를 깨도록 명시적으로 만들어야 함. Anthropic이나 OpenAI 모델에서는 개인적으로 그런 문제를 겪지 않았음 - “중국 모델”이라는 표현은 그만 쓰면 좋겠음. 부정적인 뉘앙스가 있음 예전에 자동차를 “일본차”라고 부르던 것과 비슷한데, 이제는 거의 의미가 없어졌고 그냥 Toyota, Honda, Lexus라고 부르는 식임 - opencode + **Kimi K2.6/2.7**을 Claude Code와 비교해서 써본 사람이 있다면 정말 궁금함. 무엇이 낫고 나쁜지, 비용 비교가 어떤지 알고 싶음 지금은 5x Max 플랜에 $100을 내고 있는데 Fable이 사용 한도를 꽤 빠르게 소모하고, Opus와 비교해 밤낮처럼 차이 난다고도 말하기 어려움 주로 사이드 프로젝트에 쓰기 때문에 $100 청구서도 꽤 크게 느껴지고, 더 내고 싶지는 않음 - Claude Code를 주로 Opus와 함께 쓰다가 개인 프로젝트에서 **opencode + Kimi 2.6**으로 옮겨 몇 달 써봤음 Claude Code가 더 낫긴 함. 하지만 opencode + Kimi 2.6도 쓸 만하다는 점이 큼 원하는 것을 정확히 알고 단순 코드 작성만 시키면 DeepSeek, Kimi 같은 인기 모델들도 대부분 괜찮고 Anthropic 모델과 크게 다르지 않게 느껴짐 반면 Opus는 DeepSeek보다 의도를 훨씬 잘 이해함. DeepSeek을 쓸 때는 프롬프트를 훨씬 더 정확히 써야 하고, 대충 쓰면 자주 엉뚱한 방향으로 감 Kimi는 그 중간임. “느슨한 프롬프트” 흐름을 어느 정도 되살려 주고, DeepSeek보다 계획을 더 신뢰할 수 있음 Claude Code와 비슷한 작업 흐름은 가능하지만, 전반적으로 조금씩 나쁨. 문맥 길이, 오류 수, 의사결정, 추천, 디버깅 능력이 모두 약간씩 떨어짐 사용량 측면에서는 $100 Claude 플랜이 실제로 가성비가 좋음. 토큰 단가로는 Kimi가 훨씬 싸지만 Claude 구독은 많이 보조되는 듯해서 $100로 API에서 살 수 있는 것보다 훨씬 많은 토큰을 받음 결국 비슷한 사용 패턴에서는 opencode + Kimi와 Claude Code 비용이 비슷해질 수 있음 DeepSeek은 더 싸고 캐시 토큰이 말도 안 되게 저렴하지만, Claude Code에서 넘어오면 습관에 따라 작업 방식을 조정해야 할 수 있음 사이드 프로젝트라면 **$10 Opencode Go 플랜**에 OpenRouter 같은 곳에서 **DeepSeek v4 크레딧 $10**을 더하는 구성이 꽤 실용적이라고 봄 - 업무에서는 Claude를, 사이드 프로젝트에서는 Kimi를 씀. 조직에는 LiteLLM과 Kimi 2.5가 활성화돼 있지만 거의 잘 안 돌아가서 Claude와 GPT가 주 도구임 Kimi는 면접 보는 개발자 같은 느낌이라 더 재미있음. 문제를 추론하는 과정을 보는 게 화이트보드 세션에서 내가 설명하는 방식과 비슷함. “wait”를 너무 자주 말해서 웃김 Claude는 이미 채용된 직원이나 직원 팀에 더 가까움. 처음부터 긴 설명을 많이 하지 않고, 필요할 때만 질문한 다음 종합적인 보고서나 계획을 내놓음 OpenCode는 더 나은 하네스라고 봄. 비용은 같은 프롬프트를 양쪽에 정확히 돌려본 적이 없어 직접 비교는 못 함 최근 Kimi로 ZenC 프로그래밍 언어용 libpq 래퍼를 만들게 했고([https://github.com/nobleach/zenc-postgres]()), 약 한 시간 걸렸으며 비용은 **약 $4**였음 - ohmypi에 매우 만족하지만 OpenCode를 쓰거나 Claude Code를 계속 써도 됨 DeepSeek-V4-Pro는 충분히 괜찮고, Haiku나 Sonnet에 맡길 법한 작업이나 작은 활동에는 DS4-Flash를 쓰면 됨. $10 선불로 가입하면 됨 OpenCode Go는 한 달 $5로 가입해서 **Qwen-3.7-Max**를 설계, 계획, 아키텍처, 어려운 문제 해결에 쓰면 됨. DeepSeek보다 Opus 3.6이나 3.7에 더 가까운 느낌이고, 찾은 것 중 가장 비슷했음 OpenAI Codex는 월 $20 플랜으로 GPT-5.5를 API로 설계, 계획, 아키텍처, 문제 해결, 커밋 작성에 쓸 수 있음. 정말 어려운 문제는 $100을 내고 GPT-5.5-Pro 채팅에 복사해 넣을 수도 있음 Xiaomi MiMo-2.5-Pro는 친구에게 $2 추천 코드를 받아 72센트 무료 크레딧을 받을 수 있음. 가격은 DeepSeek과 같고, Sonnet과 Opus 사이 어딘가로 꽤 유능함. UltraSpeed 베타도 신청해 볼 만함 OpenCode나 ohmypi에서 이 모델들을 즉석으로 바꿔 가며 자신에게 가장 잘 맞는 것을 찾으면 됨. CodexBar로 거의 실시간 사용량을 확인함 가벼운 사용자나 프로그래밍 초보자에게는 Cursor의 $20 플랜이 Composer-2.5와 Composer-2.5-Fast로 시작하기 좋음. API 할당량도 있어서 Cursor 자체 외에 OpenCode나 ohmypi에서 Opus-4.x 또는 GPT-5.5-Pro에 접근할 수 있음 Grok이나 Twitter를 쓴다면 월 $30 SuperGrok에 좋은 비전 모델이 있고, 프런트엔드 자동 테스트에 썼음. 다만 지금은 일반 Mac에서 로컬 Qwen-3-VL로 옮기는 중임. 기술에 덜 익숙하다면 unreach가 Mac에서 로컬 모델 호스팅을 쉽게 해 줌 RTX 5090 같은 강력한 GPU가 있으면 Qwen-3.6도 로컬에서 시도해 볼 만함. ollama나 llama-swap을 쓰면 비교적 쉬움 새 Kimi는 아직 안 써봤지만, 전문 개발자 3명, Midjourney와 Grok Imagine을 많이 쓰는 그래픽 디자이너 1명, 요구사항 수집과 구현 추적에 ohmypi를 쓰는 비기술 사용자 1명으로 팀을 운영하면서 직원 1인당 월 **$200 이하**로 비용을 유지하고 있음 조금만 더 노력하면 직원당 월 $75에 더 가까워질 수 있음 - Claude Code에 패치한 litellm 프록시, openrouter, **Qwen 3.7 max/Kimi K2.6/DeepSeek v4 pro**를 붙여 쓰고 있음 동작하지 않는 유일한 기능은 webfetch와 웹 검색인데, ddg MCP와 웹 가져오기/검색 pre-hook으로 에이전트를 우회시켜 대체했음 메모리, 캐싱 등 나머지는 잘 작동함 Qwen은 계획 수립에서 Opus에 가까운데 Fable이 분명히 더 뛰어남 코딩은 Opus가 계획을 작성해 주면 Kimi와 DeepSeek 결과가 Opus와 거의 구분되지 않음 가장 큰 차이는 출력 리듬임. 예를 들어 Kimi는 오래 생각한 뒤 많은 텍스트를 빠르게 출력함 지금은 연구와 계획에 Fable, 코딩에 DeepSeek v4 flash를 테스트 중임. 결과는 Opus + DeepSeek v4 pro와 비슷하고 전체 비용은 더 낮을 것 같음 - GLM 5.1만 말할 수 있는데, 내 기준으로는 **Sonnet 4 수준**에 가깝다고 봄 좋고, 던지는 대부분의 작업을 잘 처리하지만 인지적으로 복잡한 작업은 실패함. 자주 막힘. 그래도 월 약 $6임 - “최고” 모델이 중요하지 않게 되는 임계점이 있고, 거기서 멀지 않다고 봄. Fable은 지금 정말 좋지만, 1년쯤 뒤 Kimi가 따라잡으면 Fable6가 훨씬 좋아도 가격이 1/10이면 Kimi를 쓸 것 같음 예전에 Opus 4.5를 보며 “이 정도로 좋으면 6~12개월 안에 중국 모델들이 이만큼 좋고 싸질 테니 그걸 쓰겠다”고 생각했지만 틀렸음. 지금도 Opus 4.7/8과 Fable에 프리미엄을 내고 있음 그래도 언젠가는 그냥 원하는 일을 해내는 수준이 되고, 그때부터는 **가격 하락 경쟁**이 시작될 것임 이제 중국 회사들이 아주 좋은 Fable 토큰에 접근할 수 있으니 그 경쟁이 빨라지길 바람 - 누구인지, 모델을 어떻게 쓰는지에 따라 이미 그 지점에 도달한 경우도 있음 - 다음 경쟁 전선은 **속도**라고 봄. 여러 에이전트가 각자 작업하는 것을 오가며 문맥 전환하기보다, 단일 에이전트가 몇 초 안에 어떤 프롬프트든 밀어붙여 한 작업의 흐름을 유지하게 해 주면 좋겠음 - 토큰당 가격만 중요한 건 아님. AI에게 다시 물어봐야 한다면 처음부터 맞히는 모델보다 더 비쌀 수 있음 그래서 토큰 단가가 높아도 더 나은 모델이 실제로는 더 저렴할 수 있음 - Opus가 Kimi K2.6이나 다른 중국 모델보다 **5배 비싼데** 겨우 조금 더 나은 정도라면, Anthropic 같은 회사들이 어떻게 경쟁력을 유지하는지 궁금했음 내 가설은 미국 기업들이 데이터를 중국 쪽으로 보낼 수 없다는 것이고, 그건 이해됨. 그런데 그게 정말 “해자”일까? - 지금의 해자는 **모델 성능**과 그로 인해 추가로 쓰는 토큰 수와 시간임 Kimi 모델을 꽤 자주 쓰고 대체로 좋아하는 입장에서 하는 말임 아직 게임화되지 않은 DeepSWE 같은 벤치마크에서 Kimi K2.6은 Claude Sonnet 4.6($3/$15)에 크게 밀리고, GPT 5.4 Mini($0.75/$4.50)에도 약간 밀림 Kimi 모델이 많은 코딩 작업에서 매우 좋은 건 분명하고, 오픈 가중치 모델 중 품질이 가장 좋음 하지만 Sonnet/Opus와 비슷한 전체 결과를 얻으려면 평균적으로 훨씬 더 많은 토큰을 쓰고 모델을 더 많이 관리해야 함 토큰당 가격이 아니라 전체 과정에 얼마를 내는지를 봐야 함 - “겨우 조금 더 낫다”가 아니라는 인식이 있다고 봄. 그 인식된 품질 격차 덕분에 가격 차별화가 가능함 또 돈을 많이 쓰는 경우에는 평가를 돌리는 합리적인 주체들이 충분히 있어서, “조금 더 나음”이 순전한 느낌만은 아닐 가능성이 큼 다만 내가 직접 볼 수 있는 평가 스위트는 일부뿐임. 모두가 비합리적이고 Anthropic이 그걸 이용하는 것일 수도 있긴 함 - 둘 다 써본 사람 대부분은 Anthropic 모델이 Kimi보다 **조금 이상으로 낫다**고 말할 것 같음 Kimi와 다른 오픈소스 모델들이 SWE-bench 같은 데서는 점수가 잘 나올 수 있지만, 실제로 써보면 격차가 체감됨 - API 토큰 가격은 한 가지 요소일 뿐이고, **Claude 구독**은 가성비가 좋음 이상하게도 모두가 API 가격을 근거로 Claude 구독이 보조금 받는다고 말하지만, 실제 Claude 추론 비용을 아는 사람은 없고 중국 제공자들도 저렴한 추론을 제공할 수 있음. 그렇다면 Claude는 왜 못 한다고 생각하는지 의문임 기업 고객에게는 공개되지 않은 다른 API 가격 계약이 있을 수도 있음. 우리가 보는 건 높은 표시 가격뿐일 수 있음 - 비교 가능한 영역에서만 “조금 더 낫다”에 가깝고, 그 외 많은 영역에서는 A\ 모델들이 훨씬 더 좋음. 예를 들어 Kimi 등이 증류하지 않은 종류의 작업임 그런 작업에서는 차이가 절벽처럼 큼 - 제대로 테스트해 보니 꽤 괜찮은 개선으로 보임. 같은 작업에 **토큰을 덜 쓰는 것**만으로도 오픈 모델이 필요할 때 K2.6 대신 쓸 충분한 이유가 됨 - DeepSeek v4보다 20~30%쯤 확실히 뛰어나지 않은 새 모델이 DeepSeek보다 토큰당 가격이 높다면, 거의 자동으로 **저사용 모델**로 밀려난다고 봄. 계획 수립용 정도는 가능하겠지만 - DeepSeek v4 Pro는 GLM 5.1이나 Kimi K2.6과 비교하면 실제로 그렇게 좋은 모델은 아님. 가격 대비 괜찮은 코더/추론기 정도임 - DeepSeek은 비용을 감수하고 있는 건지, 아니면 사람들이 오픈 모델을 비슷한 비용으로 호스팅할 수 있는 건지 궁금함 - 아직 **오픈 가중치/오픈소스 모델**에 매우 익숙하지 않음. 전업으로 쓰는 사람이 있다면 설정과 성능을 듣고 싶음. 조직을 Anthropic 제품에서 옮기는 것을 고려 중임 - 개인적인 경험을 말하면, 개인 작업에는 forgecode와 openrouter를 씀. 먼저 forgecode는 Claude Code보다 훨씬 나은 하네스라고 봄 모델 품질 면에서는 큰 차이가 없지만 비용 차이는 말도 안 되게 큼. 적어도 내가 에이전트를 쓰는 방식에서는 그렇음 어제 예로, 복잡한 기술 문서를 검색하기 위한 작은 DSL을 개발 중이었고 작은 연산자를 추가하려고 Fable을 시험해 봤음 Fable은 $13를 태웠고 해결책은 냈지만, 동일한 작업을 DeepSeek v4가 **$1.7**에 한 것보다 객관적으로 더 낫지는 않았음 다만 나는 에이전트에 조각난 작업을 맡김. DSL의 경우 연산자는 내가 설계하고 에이전트에게 하나씩 구현하게 했음 복잡한 문서에서 시작해 전체를 설계하라고 했다면 Fable이 빛났을 수도 있음 하지만 에이전트에 더 넓은 범위의 작업을 줄 때마다 수백만 토큰을 태우고 의심스러운 코드를 생성해서, 결국 내가 시간을 들여 익혀야 했음 - [https://github.com/gitsense/gsc-cli]()를 만들었고, 코드의 80% 정도는 **glm-4.7**이 차지한다고 봄 예를 들어 [https://github.com/gitsense/gsc-cli/blob/main/internal/cli/r...]() 같은 파일을 보면 사용한 모델을 명시해 두었음 4.7은 `go` 코드에 그다지 좋지 않았고, 그래서 attribution에 `Gemini 3 Flash`가 보이기 시작했음 4.7은 Cerebras가 제공하는 모델이고, 내게는 반복 속도가 훨씬 중요함 MiMo v2.5.0-Pro를 써본 결과 Gemini 3 Flash가 한 일을 100% 해낼 수 있었을 거라고 확신함 몇 번 막혔을 때는 Sonnet에게 설명을 받아야 했지만, Anthropic과 OpenAI가 말하지 않을 더러운 비밀은 코딩을 할 줄 안다면 모델들이 솔직히 충분히 좋다는 것임 MiMo 경험과 GLM 5.1에 대한 다른 사람들 평가를 보면 이제는 **하드웨어 경쟁**에 들어섰다고 봄 프로그래밍을 할 줄 알고 AI로 아는 것을 증폭시키려는 사람에게 중국 모델들은 Claude의 100% 대체재가 됨 이제는 어떤 제공자가 가장 빠른 추론을 제공하느냐를 볼 것임 MiMo-v2.5.0-Pro-Ultraspeed는 좋은 결과를 빠르게 생성하고 돈도 빠르게 태움 - 이 모델들은 오픈 가중치이지만, 현재 대부분의 플래그십 모델은 실질적으로 **서드파티 모델 제공자**를 통해서만 접근 가능함 주요 예외는 30B 매개변수 안팎의 모델로, 아직 소비자용 GPU에서 돌릴 수 있음 다만 소비자용 GPU도 최근 몇 년 사이 점점 비싸져서 정당화하기 어려워졌음 - 계속 중국 모델로 전환하려고 하지만, 결국 그 출력물을 Claude에게 고쳐 달라고 하게 됨. 기능과 스타일 모두에서 그렇고, 결국 항상 돌아오게 됨 GPT도 계속 시도하는데 꽤 탄탄함. 매우 빠르고 디버깅도 훌륭함. 하지만 코드는 종종 지나치게 영리해서 머리가 아픔 프롬프트로 고칠 수 있을지도 모름. 중국 모델에는 조금 도움이 됐음. 예전 이미지 AI 시절의 “+good -bad”처럼 우아하게 하라고 말하면 됨 지금은 여전히 사람이 코드를 이해할 수 있어야 하고, 그 요구를 꾸준히 만족시키는 건 Claude뿐임 그래도 언젠가 중국 연구소 중 하나가 특별한 비법을 찾아내길 바람 작은 수정에는 **DeepSeek Flash**가 아주 좋음. 사실상 무제한 AI가 바로 붙어 있는 느낌이라 멋짐 - dwarf star가 나온 이후로 **DeepSeek v4 flash**를 거의 모든 작업의 주 모델로 쓰고 있음 128GB 메모리의 M4 Max MacBook Pro에서 돌림 보통 서버로 실행하고, 코딩 머신에서는 Tailscale로 접속해 Pi 코딩 에이전트를 씀 Qwen 모델을 쓰던 것보다 큰 도약이지만 비전 기능은 없어서, 비전이 필요할 때는 여전히 그쪽 모델을 돌림 이전에는 GLM 4.7 flash를 코딩 주력으로 썼지만, 비전이 아닌 모든 작업은 완전히 DeepSeek으로 옮겼음 - 중국산 오픈 가중치 모델에서 **CCP 요소**를 제거해 본 사람이 있는지 궁금함. 비꼬는 뜻이 아니라, 가중치 내성 검사나 개념 활성화 같은 기법으로 철저히 검토했는지를 묻는 것임 예를 들어 CCP가 실제로 문맥별 행동을 심으려 했다면 기만적이거나 악의적인 행동을 유발할 만한 입력에 어떻게 반응하는지 보는 식임 미국 정부 애플리케이션에 쓰일 때 취약한 코드를 생성한다는 의혹 같은 것이 실제로 입증됐는지는 모르겠음 지정학적 경쟁이 심한 시기에는 이런 질문이 불합리하지 않음. 어느 나라에 살든 적용되는 질문임 - Hugging Face의 **TNG**를 확인해 볼 만함 독일 컨설팅 회사인데, DeepSeek 모델을 튜닝하고 편향을 제거하는 발표를 본 적이 있음. 꽤 흥미로웠음 [https://www.tngtech.com/en/about-us/news/release-of-deepseek...]() 걱정해야 할 것은 코드만이 아니라, 잠재적 메시징 같은 다른 것도 있음 - heretic 같은 도구가 유용할 수 있는 작업처럼 들림 [https://github.com/p-e-w/heretic]() - 기업이 만든 LLM도 기업 편향이 의심될 수 있음. 안전한 것은 없음