보내는 글자를 줄였으니 모델 사용량도 같은 비율로 줄 것이라고 기대하기 쉽다. 하지만 실제 북극성 비교에서는 지침 바이트와 도구 스키마, 입력 토큰의 감소율이 달랐다. 어느 경계에서 센 숫자인지 표시하지 않으면 모두 같은 전송량처럼 보인다는 점부터 정리했다.
실행 요청 한 장과 내부 왕복은 다른 크기다
compact 실행 기록에는 입력 1,003바이트와 최종 출력 579바이트가 남아 있다. 이것은 실행기에 건넨 작은 입력과 마지막에 돌려준 출력이다. 내부에서 상태를 여러 번 조회한 요청·응답을 모두 합한 통신량이라는 뜻은 아니다. 짧은 요약은 내부 작업이 사라졌다는 증거도 아니다.
실행기는 client.call을 감싸 요청 이름과 인자, 반환값의 JSON 바이트를 별도로 더한다. wire-metrics의 calls·requestBytes·responseBytes·statusPolls는 그 경계의 계수다. 전송 계층 헤더나 모든 프로토콜 비용을 포함한 실제 네트워크 패킷 측정이라고 부르지는 않는다. 먼저 무엇을 직렬화해 센 값인지 알아야 비교할 수 있다.
지침과 스키마를 줄인 과거 비교를 따로 읽었다
0.1.118 당시 같은 공개 페이지 읽기 비교에서 첫 호출 지침은 16,673에서 4,990바이트, 도구 스키마는 22,392에서 7,485바이트로 줄었다. 반면 입력 토큰은 63,992에서 55,809였다. 같은 퍼센트가 아니다. 전체 관찰 문맥 합계는 양쪽 모두 69,255바이트로 유지한 비교였다.
그 회차는 양쪽 모델 호출이 두 번씩이고 추출 결과도 확인했다. 바이트 절감만 보고 실제 요청을 실행하지 않은 감사와 구별한 것이다. 다만 이는 과거 내부 CLI를 사용하던 버전의 기록이며 현재 제거된 경로를 다시 활성화한 기능 소개가 아니다. 지금 제품의 모든 실행에 같은 수치를 붙일 수는 없다.
토큰에는 애플리케이션이 직접 세지 않은 문맥도 있다
앱이 만든 promptBytes와 schemaBytes만으로 바깥 호스트가 모델에 전달한 모든 토큰을 알 수는 없다. 고정 지침과 누적 대화, 도구 정의와 캐시 상태가 함께 영향을 줄 수 있다. 나는 바이트를 임의의 계수로 나눠 실제 토큰이라고 표시하지 않았다. 실제 반환 사용량은 별도의 기록이다.
compact 실행기는 현재 Codex 대화 자체를 자르는 프로그램도 아니다. 내부 플러그인의 모델 호출 0과 바깥 실행의 큰 입력 토큰이 동시에 성립하는 이유가 여기에 있다. 고정 문맥의 정확한 토큰 비중을 별도로 측정하지 않았다면 그 비중까지 단정하지 않는다. 관찰한 경계 밖의 숫자를 추정으로 채우지 않았다.
축소해도 필요한 사실과 실행 참조는 남아야 한다
전달량 감소는 정답이나 기능 보존을 자동으로 증명하지 않는다. 과거 관찰 요약은 최신 관찰을 한 번 남기고 오래된 본문과 조작 참조를 줄이는 방식이었다. 도구 정의를 줄이는 경로에는 필요한 기능을 다시 찾을 수 있는 발견 절차가 있었다. 작은 크기와 필요한 정보의 보존을 각각 검사해야 한다.
작업 결과는 같은 원본 페이지의 제목과 링크를 실제 추출해 비교했고 호출 수와 토큰도 따로 기록했다. 이 글에서는 그 문서와 선택 코드를 읽었으며 원래 실사이트 비교를 다시 실행하지 않았다. 전송량 최적화가 모든 사이트의 성공률을 높였다는 결론으로 확대하지 않는다. 읽기 한 종류에서 확인한 범위를 유지한다.
단위가 다른 열을 같은 그래프로 합치지 않는다
공유 원장에서는 request_bytes와 response_bytes를 토큰 지표와 별도로 집계한다. 바이트를 크게 바꿔도 토큰 합계는 자동으로 변하지 않는 시험이 있다. 같은 입력의 캐시 포함 전체와 비캐시 입력+출력도 각자의 이름으로 남는다. 단위를 섞지 않는 것이 복잡한 환산보다 먼저다.
독자가 자기 서비스에 적용한다면 입력 캡슐, 내부 도구 통신, 모델 사용량, 업무 완료를 각각 어떤 자료로 확인할지 정하면 된다. 이번 예제는 자동 계측기나 가격 계산기가 아니다. 어떤 숫자가 줄었는지 정확히 말할 수 있어야 다음 개선도 어디에 적용할지 판단할 수 있다는 기준을 제작 기록으로 남겼다.