공유 기억을 지식 그래프에서 원문 저장소로 바꾼 이유 가운데 하나는 토큰이었다. 다만 「토큰이 줄었다」는 말은 어디서, 얼마나를 함께 말하지 않으면 근거가 되지 못한다. 그래서 토큰이 쓰이는 자리를 쓰기와 읽기 둘로 나누고, 각 자리에서 실측으로 확인되는 것만 모았다. 끝내 잴 수 없었던 숫자도 하나 있어서, 그것도 이유와 함께 적는다.
Table of contents
Open Table of contents
배경 — 토큰이 쓰이는 두 자리
공유 기억에서 토큰이 드는 자리는 둘이다.
- 쓰기. 기록을 저장할 때 LLM 을 부르는가. 그래프에서는 대화 한 턴을 넣을 때마다 엔티티·사실을 뽑는 LLM 호출이 여러 번 일어났다
- 읽기. 세션이 기억을 꺼낼 때 그 내용이 세션의 맥락으로 들어간다. 묻지 않아도 훅이 넣는 주입은 프롬프트마다 맥락을 차지한다
두 자리는 성격이 다르다. 쓰기는 기록 수에 비례하고, 읽기는 프롬프트 수에 비례한다. 하나만 재고 「줄었다」고 하면 다른 쪽이 늘어난 것을 놓칠 수 있다.
측정 — 쓰기: 에피소드당 호출 9.58회에서 0회로
그래프 시절 기록 하나(에피소드)를 넣는 데 든 LLM 호출은 평균 9.58회였다. 그래프 라이브러리의 판을 올리자 호출 종류가 7종으로 늘며 평균 10.63회가 됐다. 그 가운데 사실 추출 호출은 앞선 에피소드들을 문맥으로 함께 넣는데, 앞선 에피소드 하나가 약 1,144자, 토큰으로 약 515개였다. 문맥을 앞선 에피소드 10개로 잡으면 사실 추출 프롬프트 하나가 약 6.9k 토큰, 20개로 잡으면 약 12.1k 토큰으로 환산됐다. 프록시의 토큰 계산기로 세면 8.1k 와 14.2k 로 더 컸다.
그래프에는 에피소드가 11,167건 있었고, 에피소드마다 사실 추출 말고도 다른 종류의 호출이 여덟 번 넘게 더 있었다. 호출별 토큰은 기록되지 않아 그 총량은 재지 못했다.
반면 아틀라스의 쓰기 경로에는 LLM 호출이 없다. 기록을 정해진 크기로 자르고 조각마다 임베딩을 한 번 만든다. 임베딩 모델(568M, 1024차원)은 사내 GPU 서버에서 돌고, 프록시는 LLM 호출 그룹을 끄고 임베딩 배포만 남겼다. 쓰기에서 LLM 토큰은 0 이 됐다.
측정 — 읽기: 주입 3.00줄에서 1.22줄로
읽기 쪽은 훅이 프롬프트마다 넣는 줄 수로 쟀다. 순위식을 시험한 실제 프롬프트 155개에서, 상한 없이 상위 3개를 늘 넣으면 질의당 3.00줄이 들어가고 그중 쓸모 있는 줄은 32% 였다. 거리 상한 0.48 을 걸면 질의당 1.22줄로 59% 줄고, 쓸모 있는 줄의 비율은 46% 로 오른다. 도움이 될 기록이 없는 질의 54개 중 36개에서는 아무것도 넣지 않는다.
운영 기록으로도 쟀다. 최근 7일 동안 프롬프트 1,377개에 기록 조각 9,014개가 세션에 보였고, 보인 조각의 평균 길이는 527자였다. 이 수에는 훅의 자동 주입과 세션이 검색 도구로 직접 꺼낸 것이 섞여 있어서, 훅만의 주입량은 아니다.
영향 범위 — 못 잰 것과 그 이유
전환 전후의 월 토큰 총량, 즉 「그래프 시절 한 달에 몇 토큰이었고 지금은 몇 토큰인가」는 내지 못했다. 그래프가 LLM 을 부르던 클라이언트가 호출마다 토큰을 기록하지 않았기 때문이다. 호출별 토큰 로그는 모델 시험을 위해 따로 만든 시험 구간에만 있었고, 운영 기간 전체의 기록은 없다. 여기서 고를 수 있는 길은 두 가지 방법이었다. 호출 수와 프롬프트 크기로 월 총량을 추정해 한 줄짜리 절감률을 내거나, 잰 범위로만 말하는 것이다. 잰 범위로 좁힌 이유는 없는 기록을 추정으로 채우면 이 글의 다른 숫자까지 믿을 수 없게 되기 때문이다. 이 선택의 대가는 「한 달에 몇 % 줄었다」는 한 줄 결론을 내지 못한다는 점이다.
정리하면 확인된 것은 셋이다.
| 자리 | 그래프 | 아틀라스 |
|---|---|---|
| 쓰기 — 기록당 LLM 호출 | 평균 9.58회(판 올린 뒤 10.63회) | 0회(임베딩 1회, 사내 GPU) |
| 쓰기 — 사실 추출 프롬프트 1개 | 약 6.9k~12.1k 토큰(환산) | 해당 없음 |
| 읽기 — 질의당 주입 | 시험 기준 3.00줄(상한 없음) | 1.22줄(상한 0.48) |
정리
- 토큰 절감은 쓰기와 읽기로 나눠 잰다. 한쪽만 재면 다른 쪽의 증가를 놓친다
- 가장 큰 절감은 기록마다 돌던 LLM 호출을 없앤 데서 왔다. 기록 수에 비례하는 비용을 0 으로 만들었다
- 읽기 쪽은 줄 수를 줄이면서 쓸모 비율을 올렸다. 주입량과 품질을 함께 봐야 절감이 손해가 아니다
- 기록하지 않은 기간의 총량은 추정하지 않는다. 다음 전환부터는 호출별 토큰을 처음부터 남겨야 전후를 비교할 수 있다