llama.cpp CUDA Fusion, 프롬프트 처리 최대 10.7% 향상과 함께 병합
llama.cpp는 10월 25일 CUDA 최적화를 병합했으며, 기여자 벤치마크에서는 DGX Spark에서 프롬프트 처리 성능이 최대 10.7% 향상된 것으로 보고됐다. llama.cpp CUDA fusion 변경은 모델의 피드포워드 네트워크 내부 연산을 결합한다. 이 구성 요소는 어텐션 단계 사이에서 토큰 표현을 변환한다. 이 최적화의 이점은 이후의 각 응답 토큰을 생성하는 과정이 아니라 프롬프트를 읽는 과정에 적용된다.
기여자 anujj의 측정값은 NVIDIA RTX 5090에서도 성능 향상을 보여주지만, 보고된 백분율 향상폭은 더 작다. 이는 작성자가 보고한 비교 결과이며, 독립적으로 재현된 결과는 아니다. 기반 변경 사항은 병합된 코드에서 확인할 수 있지만, 실제 가치는 여전히 모델 형식, 하드웨어, 워크로드에 따라 달라진다.
핵심 비교 대상은 관련 연산을 결합하는 fusion 실행과 해당 연산들을 각각 별도로 스케줄링하는 기존 실행 경로다. 이전 제안도 같은 기회를 다른 방식으로 추구했다. 병합된 접근 방식은 값이 GPU 스레드에 전달되는 방식을 재구성해 저장된 모델 가중치를 바꾸지 않고 중간 작업을 줄인다. 긴 프롬프트를 로컬에서 실행하는 개발자에게 이는 기존 배포 환경과 비교해 측정할 가치가 있는 구체적인 소프트웨어 개선이다.
llama.cpp CUDA fusion 병합이 바꾸는 점
병합된 변경 사항은 지원되는 NVIDIA 하드웨어에서 더 큰 프롬프트 처리 워크로드까지 기존 최적화를 확장한다.
NVIDIA의 GPU 컴퓨팅 플랫폼인 CUDA는 이 구현의 실행 환경을 제공한다. llama.cpp의 양자화 행렬 곱셈 경로인 MMQ는 압축된 모델 가중치가 포함된 계산을 처리한다. 양자화는 저장 공간과 메모리 요구량을 낮추기 위해 해당 가중치를 낮은 수치 정밀도로 표현하는 방식이다.
병합된 fusion 변경 사항은 지원되는 밀집 피드포워드 레이어 내부에서 반복되는 연산 순서를 겨냥한다. 별도의 gate 및 up 프로젝션은 동일한 입력을 변환한다. 이어서 GLU(Gated Linear Unit)는 활성화 함수와 요소별 곱셈을 통해 두 결과를 결합한다.
이전에는 이 경로에서 더 큰 워크로드가 프로젝션과 그 결합을 별도 연산으로 처리했다. anujj에 따르면 새 구현은 단일 행렬 곱셈 커널을 통해 이 순서를 실행한다. 커널은 GPU 스레드 전반에서 실행되는 함수다.
이 통합이 중요한 이유는 주변 작업 역시 리소스를 소비하기 때문이다. 입력 준비, 연산 실행, 중간 결과 기록 및 재읽기는 모두 오버헤드를 더할 수 있다. 연산을 결합하면 의도한 수학적 변환을 유지하면서 일부 데이터 이동을 제거할 기회가 생긴다.
이 변경은 모든 실행 경로에 동시에 이 아이디어를 도입하는 것은 아니다. 기여자에 따르면 작은 배치용 fusion은 다른 행렬-벡터 구현을 통해 이미 존재했다. 행렬-벡터 계산은 일반적으로 여기서 강조하는 행렬-행렬 계산보다 더 작은 워크로드에 사용된다.
이 구분은 발표가 프롬프트 처리에 초점을 맞춘 이유를 설명한다. 응답 생성 전 입력 프롬프트를 처리하는 단계인 prefill은 더 큰 작업 배치를 드러낼 수 있다. 새로 지원되는 실행 경로는 추론의 이 부분을 대상으로 한다.
시점도 중요하다. 풀 리퀘스트의 최초 설명은 10월 4일에 작성됐으며, 프로젝트는 10월 25일 이를 병합했다. 병합은 구현을 프로젝트의 master 브랜치에 포함한다. 그렇다고 모든 패키지형 애플리케이션이 이미 이 변경을 포함한다는 뜻은 아니다.
데스크톱 애플리케이션, 컨테이너 또는 다운스트림 프로젝트는 자체 일정에 따라 llama.cpp를 통합할 수 있다. 따라서 사용자는 인터페이스 뒤에서 실제로 실행되는 런타임 버전을 확인해야 한다. 애플리케이션 업데이트와 업스트림 소스 병합은 별개의 사건이다.
기존 모델 파일의 경우 호환성 측면은 비교적 간단하다. 기여자는 저장된 가중치 레이아웃이 변하지 않는다고 밝혔다. 사용자는 제목에서 언급된 interleaved rows가 특별히 재배열된 모델 파일을 내려받아야 한다는 뜻으로 해석해서는 안 된다.
따라서 즉각적인 소식은 범위가 좁고 구체적이다. 지원되는 실행 순서에 업스트림에서 추가 최적화가 제공된다. 특정 요청에서 이를 사용할지는 런타임의 적격성 검사에 따라 달라진다.
벤치마크 성능 향상은 Spark에 더 유리하며 RTX 5090에서는 상승폭이 작다
보고된 결과는 나열된 구성 전반에서 일관된 방향성을 보이지만, 그 규모는 하드웨어와 양자화 방식에 따라 달라진다.
작성자는 GB10 프로세서를 탑재한 DGX Spark를 테스트했고, RTX 5090도 별도로 테스트했다. 두 벤치마크 표는 master로 표기된 기준선과 풀 리퀘스트를 비교한다. 나열된 모든 행에서 수정된 구현의 프롬프트 처리 처리량이 더 높게 보고됐다.
DGX Spark에서 가장 큰 백분율 향상은 압축 가중치 형식인 IQ4_XS를 사용한 Llama-3.1-8B에서 나타났다. 처리량은 초당 2,933.9토큰에서 3,249.0토큰으로 증가했다. 작성자는 이 구성에서 10.7%의 성능 향상을 보고했다.
Spark에서의 다른 Llama-3.1-8B 결과는 최고치보다 낮지만 상당한 수준의 향상이 보고됐다. Q4_K_M 구성은 초당 2,749.3토큰에서 3,000.6토큰으로 증가했다. Q5_K_M 구성은 초당 2,699.4토큰에서 2,960.3토큰으로 늘었다.
이 레이블은 동일한 바이너리에 대한 서로 대체 가능한 측정값이 아니라 서로 다른 양자화 모델 구성을 나타낸다. 결과는 최적화를 평가할 때 정확한 파일 형식을 맞춰야 하는 이유를 보여준다. 모델 계열 이름만으로는 중요한 변수를 빠뜨리게 된다.
Spark 표에는 Qwen3.8-27B와 Qwen3.6-27B로 표기된 모델도 포함된다. 이 명칭은 기여자 보고서의 벤치마크 레이블로서 여기에서 재현한 것이다. 성능 표 자체는 이들의 학습 세부 사항, 기능 또는 더 폭넓은 가용성을 독립적으로 입증하지 않는다.
Qwen3.8-27B로 표기된 항목에서 Spark 성능 향상폭은 4.6%에서 7.4%까지다. Q4_K_M 행은 초당 840.1토큰에서 899.9토큰으로 상승했다. IQ4_XS 행은 초당 882.4토큰에서 948.0토큰으로 증가했다.
RTX 5090 결과는 다른 규모의 성능 향상을 보여준다. 나열된 구성 전체에서 작성자는 1.9%에서 4.7% 범위의 향상을 보고했다. 이처럼 더 작은 백분율 범위는 하드웨어별 해석이 필수적임을 뜻한다.
IQ4_XS의 Llama-3.1-8B에서 RTX 5090 결과는 초당 12,997.6토큰에서 13,603.3토큰으로 증가했다. 보고된 향상폭은 4.7%다. Qwen3.8-27B Q6_K 항목의 처리량은 초당 3,220.5토큰에서 3,281.0토큰으로 상승했으며, 이는 1.9%에 해당한다.
따라서 llama.cpp fusion 벤치마크는 제한적인 결론을 뒷받침한다. 작성자가 선택한 긴 프롬프트 테스트에서 이 최적화는 보고된 매트릭스 전반에 걸쳐 측정된 입력 처리량을 높인다. 모든 지원 GPU에서 동일한 향상폭을 입증하는 것은 아니다.
또한 백분율 비교만으로 Spark가 더 큰 이점을 얻는 이유를 알 수는 없다. 서로 다른 메모리 동작, 실행 특성, 기존 병목 현상이 최적화 결과에 영향을 줄 수 있다. 이들의 상대적 기여도를 확인하려면 추가 프로파일링이 필요하며, 이러한 핵심 측정값만으로는 제공되지 않는다.
구매자에게 유용한 시사점은 평가의 엄격성에 관한 것이다. 이 결과만으로 백분율 향상폭을 근거로 하드웨어를 선택해서는 안 된다. 절대 처리량, 모델 적합성, 메모리 용량, 실제 애플리케이션 지연 시간은 여전히 별도로 고려해야 한다.
Interleaved rows는 계산 사이의 작업을 줄인다
이 구현의 핵심은 gate 연산을 적용하기 전에 관련 결과를 함께 배치하는 것이다.
Anujj는 gate와 up 행을 8개 단위로 번갈아 로드한다고 설명한다. 이 배치는 대응하는 값을 동일한 스레드의 작업 결과 안에 배치한다. 이후 스레드는 최종 출력을 기록할 때 이 값들을 결합할 수 있다.
실행 중인 스레드에 할당되는 GPU의 작은 저장 위치인 레지스터는 이러한 중간 결과를 보관한다. 그 위치에서 결합을 적용하면 계산의 해당 부분에서 중간 출력 버퍼를 거치는 별도의 왕복 과정을 피할 수 있다. 의도된 절감 효과는 실행 구성 방식에서 나온다.
이 구현은 gate 프로젝션용 두 번째 accumulator tile을 도입하는 대신 하나의 accumulator 구성을 유지한다. accumulator는 곱셈 중 부분 합계를 보관한다. tile은 함께 처리되는 행렬 요소의 블록이다.
이 설계 선택은 이 구현을 이전 fusion 제안과 구별한다. 기여자 설명에 따르면 새 접근 방식은 am17an의 제안을 따른다. 두 제안 모두 관련 연산을 겨냥하지만, 계산을 구성하는 방식은 다르다.
이 차이는 외형적인 문제가 아니라 실질적인 문제다. 더 많은 중간 상태를 보관하면 GPU의 제한된 실행 리소스에 대한 부담이 커질 수 있다. 연산 결합은 절감 효과가 추가 스케줄링 또는 저장 비용을 넘을 때만 도움이 된다.
이 때문에 “커널 수가 적다”는 것이 자동으로 “추론 속도가 빠르다”를 의미하지는 않는다. 더 큰 결합 연산은 일부 조건에서 하드웨어를 덜 효율적으로 사용할 수 있다. 최적화는 이점을 상쇄하는 새로운 제약을 피하면서 충분한 병렬 작업을 유지해야 한다.
병합된 코드는 적격성 검사를 통해 이러한 우려를 반영한다. 워크로드가 이 fusion 경로에 적합한지 평가한다. 지원되는 수학 연산만으로 fusion 실행이 보장되지는 않는다.
이 구현은 행렬 곱셈 작업을 축소 차원을 따라 나누는 스케줄링 방식인 stream-k와도 경쟁한다. fusion 경로는 해당 분할 방식을 사용할 수 없다. 따라서 타일 구성이 충분한 효율성을 제공하는지 판단할 다른 방법이 필요하다.
Johannes Gaessler는 검토 과정에서 이 문제를 제기하며, 예상 타일링 효율성과 stream-k 간의 사전 비교를 요청했다. 병합된 코드에는 fusion 경로를 선택하기 전 효율성을 판단하는 절차가 포함됐다. 이는 조건부 실행이 설계의 일부임을 뜻한다.
fusion 스케줄링 검토는 이 최적화에 관한 가장 유용한 회의적 관점을 제공한다. 매력적인 단순화가 성능을 잃을 수 있는 상황에 초점을 맞춘다. 이는 벤치마크 존재 여부에 대한 이견이 아니라 기술적 한계다.
따라서 여기서의 주된 경쟁은 런타임 내부에서 이뤄진다. fusion 실행은 적격한 연산 형태에서 기존 스케줄링 접근 방식을 능가해야 한다. 이 결과에서 다른 추론 프레임워크를 상대로 한 더 광범위한 승리를 보여주는 근거는 없다.
이 메커니즘은 사용자가 llama.cpp CUDA fusion에 대해 무엇을 기대해야 하는지도 분명히 한다. 이는 기존 계산을 위한 작업 구성을 재정비한다. 모델의 추론 능력을 높이거나, 학습된 지식을 확장하거나, 관련 없는 메모리 한계를 제거하지는 않는다.
동일한 모델은 여전히 동일한 일반 작업을 수행한다. 엔지니어링상의 기회는 특정 연산 순서의 출력을 얻는 데 걸리는 시간을 줄이는 데 있다.
더 빠른 프롬프트 처리는 대기 시간의 한 부분을 바꾼다
벤치마크는 입력 처리를 측정하므로, 실제 가치는 입력 처리가 실제 요청에 얼마나 기여하는지에 따라 달라진다.
보고된 명령은 16,384토큰으로 구성된 프롬프트를 처리하고 생성 토큰은 0개로 요청한다. 토큰은 모델이 소비하고 생성하는 텍스트 단위다. 이 설정은 완성된 대화형 응답을 측정하는 대신 프롬프트 처리량을 분리해 측정한다.
명령은 배치 및 마이크로배치 크기로 2,048을 사용합니다. 마이크로배치는 더 큰 배치에서 분할된 작은 실행 단위입니다. 또한 어텐션 계산 중 메모리 트래픽을 줄이도록 설계된 어텐션 구현인 Flash Attention도 활성화합니다.
작성자는 이전에 처리한 토큰의 어텐션 정보를 보관하는 키-값 캐시에 대해 반정밀도 저장을 지정합니다. 이 설정은 명령에 다섯 번 반복되어 나타납니다. 이러한 설정은 테스트 조건을 정의하므로, 인용되는 모든 결과와 함께 제공되어야 합니다.
프로젝트의 벤치마크 방법론은 프롬프트 처리와 토큰 생성을 구분합니다. 이 수치를 해석할 때 이 구분은 매우 중요합니다. 초당 입력 토큰 수와 초당 출력 토큰 수는 서로 다른 성능 질문에 답합니다.
개발자가 로컬 모델에 큰 소스 파일을 검사해 달라고 요청하는 상황을 생각해 보겠습니다. 해당 입력을 처리하는 일은 답변이 시작되기 전 지연에 상당히 기여할 수 있습니다. 더 빠른 지원 대상 프리필 경로는 상호작용의 이 부분을 개선합니다.
짧은 대화형 교환은 또 다른 워크로드를 제시합니다. 긴 답변을 생성하는 시간과 비교하면 프롬프트 처리에 필요한 시간은 상대적으로 적을 수 있습니다. 이 경우 동일한 입력 처리량 개선은 전체 대기 시간에서 더 작은 비중에만 영향을 줍니다.
캐시된 프롬프트는 또 다른 차이를 만듭니다. 프롬프트 캐싱은 시스템이 이미 처리한 입력의 계산 결과를 재사용합니다. 애플리케이션이 이 작업을 성공적으로 재사용하면, 이 최적화가 가속할 새로운 입력은 더 적게 남습니다.
문서 분석에는 추론 이외의 작업도 포함됩니다. 애플리케이션은 모델에 무엇인가를 보내기 전에 파일을 검색하고, 텍스트를 추출하고, 문단의 순위를 매기거나 지시문을 준비할 수 있습니다. 모델의 입력 처리 속도가 빨라졌다고 해서 이러한 주변 단계까지 더 빨리 끝난다는 의미는 아닙니다.
검색 가능한 지식 베이스를 유지하는 팀에게 이 구분은 더 나은 성능 판단을 뒷받침합니다. 검색 품질과 컨텍스트 선택은 무엇이 모델에 도달하는지를 결정합니다. 런타임 처리량은 지원 대상 계산이 이를 얼마나 빠르게 처리하는지를 결정합니다.
이 구분은 애플리케이션 유지보수자에게도 부담을 줍니다. 제품이 어떤 런타임을 제공하는지, 그리고 일반적인 워크로드가 최적화 경로에 도달하는지를 알아야 합니다. 로컬 AI가 더 빨라졌다는 일반적인 릴리스 노트만으로는 이러한 질문에 답할 수 없습니다.
유용한 대응은 애플리케이션 경계에서의 측정입니다. 첫 토큰까지의 시간은 출력이 시작되기 전 지연을 측정합니다. 총 응답 시간은 전체 상호작용을 측정하며, 생성 처리량은 출력이 시작된 뒤의 속도를 측정합니다.
런타임 업데이트 이후 각 지표는 서로 다르게 변할 수 있습니다. 프리필 개선은 이후 텍스트의 생성 속도를 바꾸지 않으면서 초기 대기 시간을 줄일 수 있습니다. 이러한 결과를 분리해 보고하면 사용자에게 업그레이드를 더 정확하게 설명할 수 있습니다.
llama.cpp 프롬프트 처리에서 가장 강력한 활용 사례는 지원 대상 구성에서 새롭고 상당한 양의 입력을 처리하는 경우입니다. 작성자의 벤치마크는 의도적으로 이 워크로드를 강조합니다. 그 결과를 모든 채팅 세션으로 확장하는 것은 증거의 범위를 넘어섭니다.
지원 형식과 정확성 검증이 경계를 정합니다
병합된 코드에는 의미 있는 제한이 포함되어 있으며, 작성자의 정확성 보고서는 명시된 테스트 범위 안에서 읽어야 합니다.
풀 리퀘스트는 NVIDIA Turing 이상 아키텍처에서 Q4_K, Q5_K, Q6_K, Q8_0 및 IQ4_XS 가중치 유형을 지원한다고 설명합니다. 이는 지원되는 가중치 계열입니다. 모델 파일은 유형을 혼합할 수 있으므로, 파일의 전체 레이블만으로는 내부의 모든 텐서를 설명할 수 없습니다.
구현은 관련 게이트 및 업 가중치가 퓨전에 필요한 조건을 충족하는지도 확인합니다. 결합 연산은 대응하는 계산을 전제하므로 형태, 유형 및 레이아웃이 중요합니다. 지원되지 않는 구성은 다른 실행 경로를 유지해야 합니다.
병합된 코드는 행 경계 폴백이 필요한 경우를 제외합니다. 폴백은 형태가 일반 처리 타일을 깔끔하게 채우지 못할 때 이를 처리합니다. 원래 설명에서 개발 중 경계 사례를 다루는 테스트를 언급하기 때문에 이 제한은 중요합니다.
따라서 독자는 초기 테스트 요약과 최종 코드의 선택 규칙을 구분해야 합니다. 더 넓은 개발 구현을 테스트했다고 해서, 테스트된 모든 형태가 병합 버전에서도 계속 지원 대상이라는 뜻은 아닙니다. 실제 실행은 최종 가드가 결정합니다.
연산 매개변수에도 제한이 있습니다. 코드는 퓨전을 선택하기 전에 특정 활성화 설정을 확인합니다. 이러한 검사는 필요한 동작이 다를 때 런타임이 겉보기에 비슷한 연산을 상호 교환 가능한 것으로 취급하지 않도록 합니다.
범위는 고밀도 피드포워드 연산에도 집중됩니다. 선택된 서브네트워크를 통해 토큰을 라우팅하는 전문가 혼합 모델은 서로 다른 실행 요구 사항을 제시합니다. 리뷰는 이러한 모델에 대한 보편적 지원을 확립하기보다 추가 지원 작업을 명시적으로 지적합니다.
다른 하드웨어 백엔드는 llama.cpp를 지원한다는 이유만으로 이 최적화를 받지 않습니다. 기여자는 이 변경 사항을 다른 백엔드와 명확히 구분합니다. 따라서 NVIDIA 하드웨어의 결과만으로 Apple GPU나 AMD 구성에서 동등한 이점을 입증할 수는 없습니다.
정확성 근거는 고무적이지만 여전히 작성자 보고에 기반합니다. Anujj는 GB10에서 전체 백엔드 연산 테스트 스위트가 통과했다고 말합니다. 보고서는 RTX 5090에서 행렬 곱셈 스위트도 통과했다고 밝힙니다.
기여자는 퓨전 활성화 여부에 따라 지정된 테스트 전반에서 퍼플렉서티 결과가 동일했다고도 보고합니다. 퍼플렉서티는 모델이 평가 텍스트를 얼마나 잘 예측하는지 측정합니다. 이는 유용한 수치 검증을 제공하지만, 가능한 모든 애플리케이션 동작을 대변하지는 않습니다.
이 결과는 보편적인 출력 동일성보다 더 제한적인 주장을 뒷받침합니다. 명시된 평가에서 동일한 점수가 나왔다고 해서 모든 프롬프트, 설정 또는 플랫폼에서 생성 답변이 동일하다는 증거는 아닙니다. 더 폭넓은 검증에는 더 폭넓은 근거가 필요합니다.
llama.cpp 퓨전 벤치마크 역시 이 보고서에서 검토한 출처에서 독립적으로 재현되지는 않았습니다. 업스트림 리뷰와 병합은 프로젝트가 코드를 수용했음을 보여 줍니다. 그러나 기여자의 측정치를 외부 성능 감사로 바꾸지는 않습니다.
이러한 경계가 보고된 향상을 없애는 것은 아닙니다. 오히려 주장이 유용해지는 범위를 정의합니다. 일치하는 하드웨어와 모델 유형을 보유한 독자에게는 테스트할 구체적인 이유가 생기지만, 다른 구성에는 별도의 근거가 필요합니다.
가장 강력한 해석은 양쪽을 함께 고려합니다. 이 변경에는 명확한 메커니즘과 공개된 측정치가 있으며, 동시에 언제 실행되는지를 규정하는 명시적 조건도 존재합니다.
개선 효과가 얼마나 널리 적용되는지를 보여 줄 세 가지 신호
다음 근거는 업스트림 코드, 재현 가능한 측정치, 그리고 사용자가 체감하는 지연 시간을 연결해야 합니다.
첫 번째 신호는 다운스트림 도입입니다. 향후 몇 달 동안 애플리케이션 릴리스와 패키지 빌드는 어떤 제품이 병합된 구현을 포함하는지 보여 줄 것입니다. 사용자는 흔히 다른 애플리케이션을 통해 llama.cpp와 상호작용하기 때문에 이는 중요합니다.
프로젝트의 CUDA 빌드 지침은 업스트림 컴파일 경로를 설명합니다. 패키지 배포판은 다른 릴리스 일정을 따를 수 있습니다. 포함된 소스와 연결된 버전 식별자는 최신 백엔드를 사용한다는 일반적인 주장보다 더 많은 정보를 제공합니다.
널리 사용되는 애플리케이션이 이 변경을 통합한다면 즉각적인 도입 사례는 강화됩니다. 이전 리비전에 머문다면 병합의 실질적 영향 범위는 제한적입니다. 이는 기본 최적화를 무효화하기보다 배포 시점에 관한 문제입니다.
두 번째 신호는 명시적 설정을 갖춘 독립 재현입니다. 유용한 보고서는 하드웨어, 모델 파일, 런타임 리비전 및 벤치마크 인수를 식별해야 합니다. 또한 새 프롬프트 처리와 캐시된 입력, 생성된 출력을 구분해야 합니다.
서로 다른 프롬프트 길이에서의 재현은 향상 폭이 워크로드 크기에 얼마나 민감한지 명확히 할 것입니다. 지원되는 여러 GPU 세대의 보고서는 나열된 장비를 넘어 개선 방향이 유지되는지 검증할 것입니다. 성능 저하를 보여 주는 결과는 선택 로직의 한계를 식별하는 데 도움이 됩니다.
관련 질문은 모든 실행이 헤드라인의 최대치와 일치하는지가 아닙니다. 비교 가능한 워크로드가 허용 가능한 편차 안에서 반복 가능한 개선을 보이는지가 질문입니다. 더 작지만 일관된 향상도 운영상 유용할 수 있습니다.
세 번째 신호는 애플리케이션 지연 시간입니다. 팀은 업데이트된 런타임이 대표적인 요청에서 답변 시작 전 대기 시간을 줄이는지 측정해야 합니다. 생성 처리량과 총 응답 시간은 별도 측정값으로 유지해야 합니다.
이 근거는 커널 변경을 사용자 경험과 연결합니다. 길고 캐시되지 않은 프롬프트에서 초기 지연이 줄어든다면 구현의 실질적 가능성을 뒷받침합니다. 총 응답 시간이 변하지 않는다면 다른 단계가 측정된 워크플로를 지배한다는 뜻입니다.
형식 또는 아키텍처 지원 확대는 이 병합으로 확립된 사항이 아니라 추가 개발에 해당합니다. 향후 주장은 자체 구현과 측정치를 식별해야 합니다. 현재 결과는 이러한 확장을 미리 확증하는 것이 아니라 비교를 위한 기준선을 제공합니다.
현재로서는 llama.cpp CUDA 퓨전이 로컬 추론 성능을 재검토할 구체적인 이유를 제공합니다. 이는 지원 대상 피드포워드 계산 내부의 반복 작업을 겨냥하며, 공개된 프롬프트 처리 조건에서 측정 가능한 향상을 보고합니다. 전반적인 속도 향상을 약속하지 않으면서도 평가를 정당화하기에는 충분합니다.
운영 중인 배포 환경을 업데이트하기 전에 현재 런타임 식별자와 대표적인 요청 집합을 보존하십시오. 업데이트 후 동일한 모델 파일, 프롬프트 길이, 캐시 조건 및 출력 설정을 비교하십시오. 초기 대기 시간을 답변 생성과 분리해 기록하고, 각 결과와 함께 벤치마크 인수도 보관하십시오. 긴 문서 워크플로에서는 합성 처리량에만 전적으로 의존하지 말고 일상적인 사용과 유사한 새 입력을 포함하십시오. 대화형 워크로드에서는 더 짧아진 입력 처리 지연이 경험에 의미 있는 변화를 주는지 확인하십시오. 그런 다음 자체 측정치를 사용해 업스트림 개선을 릴리스 일정의 어디에 반영할지 결정하십시오. 업데이트된 런타임은 사용자가 실제로 기다리는 요청의 부분을 단축합니까?
