64GB CMP 170HX에 긴 문서를 얼마나 넣을 수 있을까?

GPU³ 메모리에는 모델 가중치와 KV 캐시가 함께 들어가요. KV 캐시는 앞서 읽은 토큰의 계산 정보를 저장해서 다음 토큰을 만들 때 다시 사용해요. 문서와 대화가 길어질수록 이 저장 공간도 커져요. 입력과 답변은 설정한 문맥 안에서 공간을 나눠 쓰므로, 긴 답변을 요청할수록 입력에 남는 여유는 줄어들어요.

문서 페이지 수를 토큰 수로 바로 바꿀 수는 없어요. 그림과 표의 양, 글자 밀도, PDF 앱이 문서 전체를 보내는지 관련 부분만 보내는지에 따라 모델에 전달되는 양이 달라집니다. 레시피와 측정표의 토큰 수는 입력 길이를 나타내며 페이지 수를 추정하는 값이 아니에요.

open-jet은 3,158·9,472·18,976토큰 입력을 모두 완료했어요. vLLM은 3,163토큰 채팅 요청을 완료했지만 9,472토큰 채팅 요청에서는 오류로 종료됐어요. 먼저 표에서 사용할 입력 길이와 엔진을 찾아보세요.

먼저 사용할 모델 파일과 실행 엔진을 정하고, 실제 작업에서 함께 보낼 지시문과 대화 이력을 고정하세요. 짧은 입력으로 응답을 확인한 다음 내용을 늘려 요청이 끝까지 완료되는지 봅니다. 각 길이에서 입력 토큰 수, TTFT⁴, 답변 생성 속도, 완료·오류 상태를 따로 기록하면 문서가 커질 때 무엇이 달라졌는지 알기 쉬워요.

open-jet 측정은 같은 GPU 설정에서 3,158→9,472→18,976토큰으로 길이를 늘렸고, MTP⁵ d=4의 TTFT는 2.066→6.358→13.550초로 늘었어요. decode⁶ 평균은 각각 약 77.20, 76.74, 75.39 tok/s였습니다. 이 세 입력은 한 장비·한 엔진의 기록이므로 다른 카드나 모델 양자화⁷에 그대로 적용하지 말고, 자신의 문서와 응답 길이로 재확인하세요.

입력 길이를 늘렸을 때 엔진이 중단되면 그 요청의 context 설정값을 최대 지원 길이라고 부르지 않습니다. 실패한 토큰 수와 오류를 기록하고 한 단계 낮은 입력에서 다시 확인하세요. 문서를 나눠 보내거나 검색으로 관련 부분을 좁히는 방식도 선택할 수 있지만, 그때는 모델에 전달된 실제 문맥이 달라지므로 전체 문서를 한 번에 넣은 결과와 구분해야 합니다.

vLLM의 /v1/completions 시험에서는 6,603토큰 입력이 완료됐어요. 위 표의 채팅 요청과는 API⁸와 입력이 다른 기록이에요. 서버의 65,536 설정값보다, 실제로 쓸 요청 방식에서 완료한 길이를 기준으로 문서를 준비하세요.

문서 전체를 한 번에 넣기 어렵다면 장이나 절 단위로 나눠 요약하고, 마지막에 요약들을 합쳐 정리할 수 있어요. 특정 질문에 답하는 작업이라면 검색으로 관련 부분만 찾아 보내는 RAG⁹도 방법이에요. 전체 내용을 이해해야 하는 작업인지, 필요한 부분만 찾으면 되는 작업인지에 따라 보내는 문서를 정하세요.