ProsGrow가 AMD에서 Kimi K3 전체 요청 처리량을 50% 높인 방법

답변 전에 상당한 컨텍스트를 읽는 AI 애플리케이션에서는 입력 처리 시간이 생성 속도만큼 중요할 수 있습니다. 따라서 요청 전체를 최적화하면 어떤 서빙 구성이 더 나은 경험을 제공하는지가 달라질 수 있습니다.

Kimi K3 연구에서 ProsGrow는 동일한 AMD 하드웨어의 기존 ATOM 구성 대비 전체 요청 출력 처리량을 50.1% 높였습니다. 원본 모델 체크포인트를 유지하고 요청 크기를 통제한 상태에서 서빙 스택을 변경한 결과입니다. 실험 구성은 런타임 일부의 수치 정밀도를 바꾸며, 더 광범위한 품질 검증이 필요합니다.

결과: 전체 응답을 기다리는 시간 단축

9월 22일 측정에서는 AMD MI325X GPU 8개에서 Kimi K3를 사용했습니다. 각 요청은 정확히 8,192개의 입력 토큰을 포함하고 256개의 출력 토큰을 생성했으며, 요청은 한 번에 1개씩 실행했습니다.

전체 요청 처리량은 출력 토큰 수를 입력 처리와 전송을 포함한 전체 응답 수신 시간으로 나눈 값입니다. GPU당 속도가 아닌 시스템 전체 측정값입니다. 두 백분율은 동일한 개선을 서로 다른 관점에서 나타내므로 합산해서는 안 됩니다.

프라이빗 AI 팀에게 이 결과는 하드웨어 사양과 함께 서빙 구성도 평가할 가치가 있다는 근거입니다. 고정된 응답의 대기 시간이 짧아지는 것은 큰 입력 컨텍스트와 간결한 생성 출력을 결합하는 애플리케이션에서 중요할 수 있습니다.

워크로드의 중요성을 보여 주는 4.41배 결과

동일한 호스트, 원본 체크포인트, 요청 테스트 데이터, 클라이언트를 사용해 실험 구성과 Microsoft의 Tutel 런타임을 감싼 로컬 어댑터도 비교했습니다.

입력 8K토큰·출력 256토큰 워크로드에서 Tutel 어댑터의 전체 요청 출력 속도는 9.10 토큰/초였으며, 조정한 ATOM의 40.17과 비교하면 전체 요청 속도가 4.41배였습니다. 요청 시간 중앙값은 어댑터가 28.13초, 조정한 ATOM이 6.37초였습니다.

디코딩이 시작된 뒤에는 Tutel이 여전히 더 빠르게 토큰을 생성했습니다. 속도는 78.33 대비 47.67 토큰/초였습니다. 입력 512토큰의 더 짧은 요청도 Tutel이 더 빨리 완료했습니다. 테스트한 어댑터에서 긴 프롬프트 처리 시간이 입력 8K의 결과를 바꿨습니다.

비즈니스 측면의 교훈은 구체적입니다. 애플리케이션이 실제로 사용하는 요청 길이와 응답 크기를 기준으로 서빙 구성을 선택해야 합니다. 이는 로컬 런타임 비교이며, 한 런타임이 모든 워크로드에서 더 빠르다는 일반적인 주장이 아닙니다.

개선이 이루어진 부분

ProsGrow는 입력 처리와 생성 전반에서 서빙 스택이 AMD 하드웨어를 활용하는 방식을 살펴본 뒤, 여러 변경을 결합한 런타임 구성을 테스트했습니다. 이 작업은 ATOM과 AMD AITER 생태계를 기반으로 합니다.

이 접근은 최적화를 요청 전체와 연결합니다. 또한 정밀도와 품질의 절충을 명확히 드러냅니다. 같은 원본 체크포인트를 사용해도 서로 다른 서빙 구성이 동일한 수치 연산을 수행하는 것은 아닙니다. 이 비교에서는 런타임과 캐시 정밀도 정책이 다릅니다.

검증한 항목

각 구성은 입력 길이별로 워밍업 요청 2개와 측정 요청 5개를 사용했습니다. 추측 디코딩은 비활성화했습니다. 저장한 응답 스트림을 감사해 토큰 수와 시간을 확인했고, 세 구성 모두 산술 및 마커 회상 검사를 통과했습니다.

이 기능 검사로 모델 정확성이 동등하다고 할 수는 없습니다. 실험 구성은 일반 서비스를 대체하지 않고 선택 가능한 상태로 유지했습니다. 이 측정값은 개발 결과이며, 신뢰 구간이나 프로덕션 서비스 수준 보장은 없습니다.

프라이빗 Kimi 호스팅을 검토하는 팀의 다음 단계는 대표적인 프롬프트, 응답 길이, 동시성, 작업 품질 기준으로 평가하는 것입니다. ProsGrow는 그런 요구 사항을 측정 가능한 배포 구성과 연결하도록 도울 수 있습니다.

프라이빗 추론 파일럿을 상담하려면 contact@prosgrow.ai로 이메일을 보내세요.