이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.
TL;DR
Kimi K3는 2.8T 파라미터 Mixture-of-Experts 구조와 최대 1,048,576토큰 Context Window를 제공하지만, 기사에서 가장 중요한 변화는 모델 크기보다 API 사용 방식을 조절하는 기능들입니다. reasoning_effort를 low·high·max로 나누고 max_completion_tokens를 제한하면 작업 난이도에 맞춰 추론 비용을 관리할 수 있으며, 안정적인 프롬프트를 앞에 배치하면 Prefix Caching으로 입력 비용을 90% 낮출 수 있습니다. Partial Mode는 assistant 응답의 시작을 미리 넣어 JSON 형식을 고정하고, tool_choice="required"는 첫 turn의 실제 도구 호출을 강제하며, Native Vision은 base64 또는 ms:// 입력으로 별도 이미지 모델 없이 동작합니다. 다만 Open Weights는 약 1.27 TiB 저장 공간과 64개 이상의 GPU가 필요하고 hallucination rate가 이전 세대의 39.3%에서 약 50.9%로 높아졌다고 제시되어, 전체 저장소를 직접 넣는 편의성과 사실 검증 부담을 함께 고려해야 합니다.
섹션별 상세
Kimi K3는 2.8T 파라미터와 약 896개의 routed expert 중 입력마다 16개만 활성화하는 Mixture-of-Experts 구조를 사용하며, MXFP4 양자화 가중치와 최대 1,048,576토큰 Context Window를 결합합니다. 입력 가격은 100만 토큰당 $3.00, 출력은 $15.00이며 캐시 입력은 $0.30으로 제시됩니다. 따라서 모델의 성능만 보는 대신 추론 강도, 출력 상한, 캐시 상태를 함께 조절해야 실제 사용 비용을 관리할 수 있습니다.
근거
- Kimi K3는 2.8T 파라미터와 약 896개 routed expert 중 입력마다 16개를 활성화하는 Mixture-of-Experts 모델이다. — 본문의 기술 사양 단락과 이미지 1 하단의 2.8T Parameters, MoE with 16/896 experts active 표기
Kimi K3의 reasoning_effort는 사고 모드를 끄는 스위치가 아니라 low, high, max 가운데 계산 강도를 고르는 필드이며 기본값은 max입니다. 단순한 변수명 변경에는 low, 일반적인 개발 작업에는 high, 복잡한 디버깅에는 max를 쓰고 max_completion_tokens도 명시적으로 제한해야 불필요한 추론 토큰 증가를 막을 수 있습니다. 원문의 API 비교에서는 변수명 변경처럼 기계적인 작업에도 설정에 따라 thought chars와 출력량, 비용이 달라지는 흐름이 나타납니다.
python
import os
from openai import OpenAI
client = OpenAI(api_key=os.environ["MOONSHOT_API_KEY"], base_url="https://api.moonshot.ai/v1")
def call(messages, **kw):
r = client.chat.completions.create(model="kimi-k3", messages=messages, **kw)
u = r.usage
cached = (u.prompt_tokens_details or {}).get("cached_tokens", 0)
fresh = u.prompt_tokens - cached
cost = fresh/1e6*3 + cached/1e6*0.3 + u.completion_tokens/1e6*15
print(f"[fresh {fresh} | cached {cached} | out {u.completion_tokens} | ${cost:.4f}]")
return r.choices[0].messageKimi K3 API 응답의 fresh·cached·output 토큰을 분리해 요청별 비용을 계산하는 호출 래퍼입니다.
Prefix Caching은 별도 cache ID, TTL, 초기 준비 호출 없이 256토큰을 넘는 공통 프롬프트 prefix를 반복 요청에서 재사용합니다. 질문을 저장소 내용보다 앞에 놓으면 매번 prefix가 달라져 캐시가 깨지지만, 시스템 지침과 repo_blob을 먼저 두고 질문을 마지막에 놓으면 두 번째 호출부터 동일한 입력 부분을 재사용할 수 있습니다. 원문은 이 배열 방식으로 호출 두 번째부터 입력 비용이 90% 낮아진다고 제시하며, 이미지 비교에서도 질문 우선 배열은 cache hit 0%로 기록됩니다.
python
prompt = [{"role": "user", "content": "Rename `d` to something readable: d = {}"}]
for effort in ("low", "high", "max"):
print(effort, "->", end=" ")
call(prompt, reasoning_effort=effort, max_completion_tokens=256)같은 변수명 변경 요청을 세 가지 reasoning_effort 수준으로 실행해 추론 강도별 비용과 응답 차이를 비교합니다.
근거
- Prefix Caching은 안정적인 내용을 질문보다 앞에 배치할 때 호출 두 번째부터 입력 비용을 90% 낮출 수 있다. — Feature 2의 BAD·GOOD 코드 비교와 이미지 3의 question-first·repo-first 비용 비교
- reasoning_effort는 low, high, max로 추론 강도를 조절하며 기본값은 max이다. — Feature 1 본문과 이미지 1의 Reasoning Effort 패널, 이미지 2의 세 수준별 API 실행 결과
1,048,576토큰 Context Window는 애플리케이션 코드, 테스트, 문서, migration을 한 요청에 넣는 용도로 제시되며 약 40,000줄의 코드에 해당합니다. Kimi Delta Attention은 대부분의 layer에서 선형 attention 방식으로 동작하고, LatentMoE는 routing 비용을 낮추며, NoPE는 rotary position embedding을 대체하는 구조로 설명됩니다. 이 조합을 통해 약 900K토큰 프롬프트를 처리할 수 있으므로 단일 저장소에서는 파일을 잘라 별도 vector store에서 검색하고 다시 조립하는 절차가 줄어들 수 있습니다.
python
# GOOD: stable content first, question last
base = [
{"role": "system", "content": "You review backend code."},
{"role": "user", "content": f"
{repo_blob}
"},
]
for q in questions:
call(base + [{"role": "user", "content": q}], reasoning_effort="high", max_completion_tokens=2048)변하지 않는 시스템 지침과 저장소 내용을 prefix 앞쪽에 두고 질문을 마지막에 배치해 반복 요청에서 캐시 적중을 유도합니다.
근거
- Kimi K3의 Context Window는 최대 1,048,576토큰이며 약 40,000줄의 코드와 문서, 테스트, migration을 담을 수 있다. — Feature 3 본문과 이미지 1·4의 1,048,576 TOKENS 및 ~40K+ Lines of code 표기
Partial Mode는 assistant 메시지에 응답 시작 부분을 미리 넣고 Kimi K3가 그 뒤를 이어 생성하도록 하는 방식입니다. JSON 배열의 시작을 '[{"risk":'로 고정하면 모델이 'Definitely! This is the JSON.' 같은 서문을 추가할 여지를 줄일 수 있으며, 원문은 schema 처리보다 이 방식을 더 자주 사용한다고 밝힙니다. 저장소 코드 검토 예시에서는 prefix cache, 난이도별 reasoning_effort, 부분 JSON 출력을 하나의 반복 작업에 결합합니다.
python
msgs = [
{"role": "user", "content": "List 3 risks in this migration. JSON array only."},
{"role": "assistant", "content": '[{"risk":', "partial": True},
]
print(call(msgs, reasoning_effort="low", max_completion_tokens=512).content)assistant 메시지에 JSON 배열의 시작 부분을 미리 제공해 모델이 지정된 구조를 이어서 생성하게 합니다.
Tool Calling에서는 tool_choice="required"가 첫 번째 turn에서 실제 도구 사용을 요구하므로 모델이 도구를 실행하는 대신 실행 계획만 말하는 실패를 줄입니다. 도구 정의를 system message에 두고 필요할 때 로드하면 매번 전체 도구 목록과 이전 메시지를 다시 보내지 않아도 되며, agent cycle마다 assistant의 reasoning을 포함한 완전한 메시지를 history에 보존해야 다음 결정에 앞선 계획이 이어집니다. 원문의 예시는 run_tests 함수에 path 인자를 요구하고 ./src에서 깨진 부분을 찾도록 구성합니다.
python
tools = [{"type": "function", "function": {
"name": "run_tests",
"description": "Run pytest and return failing test names.",
"parameters": {"type": "object", "properties": {"path": {"type": "string"}}, "required": ["path"]}}}]
msg = call([{"role": "user", "content": "Find what's broken in ./src"}], tools=tools, tool_choice="required", reasoning_effort="high", max_completion_tokens=2048)
print(msg.tool_calls)tool_choice를 required로 지정해 첫 번째 응답에서 실제 도구 호출이 발생하도록 강제하고 pytest 실행 결과를 받습니다.
Kimi K3는 별도 image 모델 없이 같은 endpoint에서 시각 입력을 처리하지만, 공개 이미지 URL은 허용하지 않고 base64 또는 ms:// 파일 참조를 요구합니다. 이미지 입력은 JSON 문자열이 아니라 content 배열 안에 text와 image_url 항목을 함께 넣어야 하며, 예시는 trace.png를 base64로 변환해 실제 실패 프레임을 묻습니다. Open Weights 측면에서는 약 1.27 TiB의 가중치와 64개 이상의 장치가 필요해 자체 배포 선택권은 생기지만 대부분의 팀이 직접 호스팅하기에는 인프라 부담이 큽니다.
근거
- Open Weights의 가중치 규모는 약 1.27 TiB이고 자체 추론에 64개 이상의 GPU가 필요하다. — Feature 7 본문과 이미지 5의 THE REALITY CHECK 및 WHAT IT TAKES 패널
- Kimi K3의 hallucination rate가 이전 세대의 39.3%에서 약 50.9%로 증가했다. — Common Mistakes and Gotchas 단락의 hallucination rate 비교 문장
용어 해설
- Mixture-of-Experts
- — 여러 전문가 네트워크를 두고 입력마다 일부 전문가만 선택해 계산하는 모델 구조입니다. Kimi K3는 약 896개 라우팅 전문가 가운데 입력별로 16개를 활성화해 전체 파라미터 규모와 실제 추론 비용 사이의 균형을 맞춥니다. 모든 전문가를 동시에 계산하지 않는 점이 핵심입니다.
- Prefix Caching
- — 반복되는 프롬프트 앞부분을 저장해 다음 요청에서 다시 계산하지 않는 비용 최적화 방식입니다. Kimi K3는 256토큰을 넘는 공통 prefix를 별도 cache ID나 TTL 없이 인식하며, 캐시된 입력 토큰 가격을 일반 입력보다 낮게 적용합니다. 안정적인 내용을 앞에 배치해야 효과가 유지됩니다.
- reasoning_effort
- — 모델의 추론 강도를 low, high, max로 조절하는 API 설정입니다. Kimi K3는 사고 모드를 끌 수 없지만 이 필드로 계산량과 응답 길이를 작업 난이도에 맞출 수 있습니다. 기본값이 max이므로 단순한 편집에도 높은 비용이 발생할 수 있습니다.
- Context Window
- — 모델이 한 요청에서 처리할 수 있는 입력과 출력의 토큰 범위입니다. Kimi K3는 최대 1,048,576토큰을 지원해 약 40,000줄의 코드와 문서, 테스트, migration을 한 요청에 포함할 수 있다고 제시됩니다. 긴 입력을 직접 처리하면 단일 저장소에서 검색 분할 절차의 필요성이 줄어듭니다.
- Partial Mode
- — 애플리케이션이 assistant 응답의 시작 부분을 미리 넣고 모델이 그 뒤를 이어 생성하게 하는 방식입니다. 예시에서는 JSON 배열의 시작 문자열을 assistant 메시지로 제공해 자연어 서문이 끼어드는 문제를 막습니다. schema 설정 대신 출력 형식을 직접 고정하는 용도로 활용됩니다.
- Open Weights
- — 모델의 학습 가중치를 외부에 공개해 사용자가 직접 보관하거나 자체 인프라에 배포할 수 있게 하는 형태입니다. Kimi K3의 가중치 규모는 약 1.27 TiB이며, 단일 H100·H200·B200으로는 메모리가 부족하고 64개 이상의 장치가 필요하다고 원문은 설명합니다. 접근성은 높아지지만 실제 운영에는 대규모 인프라가 요구됩니다.
기술
- Kimi K3
- Moonshot API
- OpenAI Python library
- Python
- MXFP4
- Kimi Delta Attention
- LatentMoE
- NoPE
- RAG
- Prefix Caching
- Tool Calling
- base64
- pytest
활용 사례
- 저장소 전체를 활용한 AI 코드 리뷰
- 난이도별 코드 분석과 디버깅
- 반복 요청의 입력 비용 절감
- JSON 형식의 구조화된 결과 생성
- pytest 기반 도구 호출형 agent
- 스크린샷에서 실패 프레임 찾기
- 자체 하드웨어를 활용한 Open Weights 배포
AI 분석 전체 내용 보기
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
원문 발행 2026. 08. 18.수집 2026. 08. 18.출처 타입 RSS
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
