자체 호스팅된 Kimi K3에 메모리가 없는 이유
오픈 가중치가 실제로 제공하는 것
여러분은 모델, 즉 가중치, 추론 서버(vLLM, SGLang 등) 및 엔드포인트를 얻게 됩니다. 이것은 토큰이 들어가고 토큰이 나오는 하나의 함수에 불과합니다. 사람들이 비교하는 소비자용 제품(ChatGPT, Claude)은 모델을 계정, 대화 저장소, 메모리 기능, 검색(retrieval) 등 전체 제품 레이어로 감싸고 있습니다. 가중치만 제공될 때는 이러한 기능이 전혀 포함되어 있지 않습니다. 자체 호스팅을 한다는 것은 자동차가 아니라 엔진만 인도받는 것과 같습니다.
상태 비저장(Stateless)인 기술적 이유
추론은 설계상 상태 비저장입니다. 모델은 바로 앞의 요청에 대해서만 컨텍스트를 유지하며, 이것이 바로 컨텍스트 창(context window)입니다. K3의 1M 토큰 창은 엄청나게 크기 때문에 오해하기 쉽습니다. 전체 코드베이스나 1년 치 노트를 단일 요청에 넣을 수 있어 마치 메모리가 있는 것처럼 느껴집니다. 하지만 그렇지 않습니다. 요청이 끝나면 상태는 사라지며, 다음 호출은 아무것도 알지 못합니다. 큰 창은 단일 작업을 위한 작업 기억(working memory)일 뿐, 작업 간의 영속성(persistence)을 의미하지 않습니다.
이로 인해 발생하는 비용
매번 모든 것을 다시 전송해야 합니다. '대화'를 계속 유지하려면 매 턴마다 전체 기록을 다시 입력해야 하므로, 대화가 길어질수록 비용과 지연 시간(latency)이 증가하고 결국 컨텍스트 창의 한계에 도달해 내용을 잘라내야(truncating) 합니다. 다중 사용자 배포의 경우 사용자별 프로필이 없으므로 직접 구축하지 않으면 개인화가 불가능합니다. 또한 아무것도 축적되지 않습니다. 자체 호스팅된 에이전트는 세션 간에 프로젝트를 학습할 수 없습니다. 학습 내용을 저장할 곳이 없기 때문입니다.
메모리 직접 구축하기 (그리고 그 비용)
DIY 스택
표준적인 접근 방식은 꽤 많은 작업이 필요하며, 실제로 많은 팀이 이 방식을 선택합니다. 벡터 데이터베이스를 구축하고, 임베딩 파이프라인을 만들고, 청킹(chunking) 로직을 작성하고, 기억할 가치가 있는 것을 결정하는 추출(extraction) 기능을 추가한 다음, 관련성 순위 지정을 통한 검색(retrieval)을 구현하는 것입니다. 이는 잘 알려진 경로이며 완전한 제어 권한을 제공합니다. 사람들이 애초에 자체 호스팅을 선택하는 이유와 같죠.
솔직한 비용을 따져보자면, 제대로 작동하기까지 수 주간의 엔지니어링이 필요하며 지속적인 유지보수 책임이 따릅니다. 추출 품질, 중복 제거, 두 세션이 충돌할 때의 처리, 관련성 튜닝 등 각각이 고유한 튜닝 문제이며, 방치하면 서서히 성능이 저하됩니다.
데이터베이스의 대화 로그
벡터 스택보다 저렴한 방법은 대화 기록을 Postgres에 저장하고 이를 다시 재생하는 것입니다. 이는 데이터양이 늘어나기 전까지만 유효합니다. 데이터가 늘어나면 너무 많은 내용을 다시 전송해야 하거나 직접 요약(summarization) 로직을 작성해야 하는데, 요약본은 정작 유지해야 할 구체적인 세부 정보를 잃어버리기 쉽습니다.
1M 토큰 창 채우기
특히 K3의 경우 프롬프트에 모든 것을 집어넣고 싶은 유혹이 생깁니다. 하지만 모든 요청마다 모든 토큰에 대한 비용을 지불해야 하고, 입력 크기에 비례해 지연 시간이 늘어나며, 가득 찬 창 내부에서의 검색 품질은 떨어집니다. 모델이 이해를 더 잘하는 것이 아니라 걸러내야 할 정보만 많아지기 때문입니다. 또한 요청이 끝나면 여전히 리셋됩니다.
공통적인 한계: 세 가지 방법 모두 인프라를 직접 구축해야 한다는 점입니다. 메모리 자체가 여러분이 만드는 제품이라면 그것이 올바른 선택입니다. 하지만 메모리가 실제 제품으로 가는 길목의 배관 작업에 불과하다면 이는 우회로입니다. 이는 상태 비저장 MCP 서버를 위한 메모리의 트레이드오프와 동일합니다.
해결책: 자체 호스팅 스택에 영구 메모리 부여하기
더 빠른 방법은 모델을 그대로 두고 그 옆에 메모리 레이어를 두는 것입니다. MemoryLake는 추출, 충돌 감지, 버전 관리, 검색을 대신 처리해 줍니다. 문서와 대화가 입력되면 구조화되고 검색 가능한 메모리가 출력되며, 자체 호스팅된 K3는 요청마다 이를 쿼리합니다. 가중치는 여러분의 하드웨어에 그대로 유지되며, 메모리 레이어는 종단간 암호화(end-to-end encrypted)되므로 콘텐츠를 읽을 수 없습니다.
1단계: API 키 생성
MemoryLake에 로그인하고 키를 생성한 후 첫 번째 요청을 보내세요. 약 30초 정도 걸립니다.
2단계: 첫 번째 메모리 업로드
배포 환경이 영구적으로 알고 있어야 하는 정보(프로젝트 문서, 사양서, 제품 지식, 사용자별 사실 등)를 입력하세요. 문서, 이미지 및 기타 파일 모두 지원됩니다. 매 요청마다 다시 전송하는 대신 한 번 파싱 및 인덱싱되어 저장됩니다.
3단계: AI 및 에이전트 연결
추론 엔드포인트 앞에서 API를 호출하세요. 요청에 대한 관련 메모리를 검색하여 시스템 메시지나 프롬프트에 포함하면, 각 K3 호출이 빈 상태가 아닌 정보를 갖춘 상태로 시작됩니다. 에이전트 프레임워크가 MCP를 지원한다면 그곳에 연결하세요. 동일한 메모리를 Claude, Codex, OpenClaw 및 기타 에이전트에서도 사용할 수 있으므로, 자체 호스팅 모델과 상용 도구가 하나의 컨텍스트를 공유하게 됩니다.
상태 비저장 추론의 실제 비용
재생 세금(Replay Tax)
메모리 레이어가 없으면 연속성을 유지하기 위해 매 호출마다 대화 기록을 다시 재생해야 합니다. 자체 호스팅 하드웨어에서는 API 요금 대신 GPU 시간과 지연 시간으로 비용을 지불하게 되지만, 낭비되는 것은 마찬가지입니다. 이미 모델에 말한 내용을 다시 읽는 데 연산 자원이 소모되며, 매 턴마다 누적되다가 결국 컨텍스트 창의 한계로 인해 잘려 나가게 됩니다.
재생 대신 검색 사용
모델 옆에 메모리가 있으면 각 요청은 전체 기록 대신 관련 조각(사실, 결정, 구절)만 전달합니다. 입력이 짧아지고 응답이 빨라지며, 실제 작업을 위한 컨텍스트 창의 여유 공간이 늘어납니다. 자체 배포 환경과 함께 상용 API를 실행 중인 경우 MemoryLake의 Token Saving Calculator를 통해 그 효과를 예측해 볼 수 있습니다.
자체 호스팅 메모리를 위한 모범 사례
창은 작업을 위해, 레이어는 지식을 위해 유지하기
K3의 1M 토큰은 현재 작업에 진정으로 필요한 용도로 사용하세요. 영구적인 지식은 메모리 레이어에 두고 필요할 때 검색해야 프롬프트가 무한정 커지는 것을 방지할 수 있습니다.
원본 대화록이 아닌 사실과 결정 사항 저장하기
전체 로그는 보관 비용은 저렴하지만 사용 비용은 비쌉니다. 요약된 사실, 결정 사항, 문서는 방대한 대화 기록보다 훨씬 더 효과적으로 검색됩니다.
사용자별 또는 프로젝트별로 메모리 범위 지정하기
다중 테넌트 배포에서는 첫날부터 격리가 필요합니다. 사용자 또는 프로젝트별로 범위를 지정하면 검색 관련성이 유지되고 컨텍스트가 서로 유출되는 것을 방지할 수 있습니다.
결론
Kimi K3의 오픈 가중치는 진정한 변화를 의미합니다. 직접 실행할 수 있는 프론티어급 성능과 컨텍스트 문제가 해결된 것처럼 느끼게 만드는 거대한 창을 제공합니다. 하지만 실제로는 그렇지 않습니다. 가중치는 상태 비저장 엔진일 뿐이며, 메모리는 직접 추가해야 하는 레이어입니다. 메모리 자체가 여러분의 제품이라면 직접 구축하시고, 그렇지 않다면 엔드포인트 옆에 준비된 메모리 레이어를 두고 실제 출시할 제품에 엔지니어링 역량을 집중하세요. 모델은 여러분의 하드웨어에서 실행됩니다. 메모리는 그저 존재하기만 하면 됩니다.