Reddit

RTX 3080 20GB got reBAR and P2P unlock! +70% prompt processing speed

RTX 3080 20GB에서 reBAR와 P2P 잠금 해제, 프롬프트 처리 속도 최대 10% 향상

메모리를 20GB로 개조한 RTX 3080 두 장이 호스트 메모리를 거치지 않고 PCIe로 직접 데이터를 주고받도록 NVIDIA 오픈 커널 모듈을 패치한 프로젝트입니다. 테스트 환경에서 P2P 대역폭과 vLLM 프롬프트 처리 속도가 올랐지만, 지원 조합이 제한되고 생성 속도 향상은 작거나 일관되지 않습니다.

에디터 노트

큰 프롬프트를 반복해서 처리하는 tensor parallel 작업에서는 성능 개선이 뚜렷하지만, 일반적인 생성 속도까지 같은 폭으로 빨라지지는 않습니다. 저장소 측정에서 P2P 쓰기 지연은 크게 줄었고 NCCL 처리량도 올랐지만 all-reduce의 짧은 메시지 지연은 오히려 늘었습니다. Reddit 사용자의 별도 vLLM 0.32 테스트는 프롬프트 처리량이 70~115% 늘었다고 보고했으나 gpu-unlock과 P2P를 함께 적용한 결과이며 P2P만의 효과로 읽을 수 없습니다. 생성 단계의 수치는 대부분 기본 구성과 비슷했고 장문 테스트에서도 결과가 설정에 따라 달랐습니다. 적용 범위도 좁습니다. 저장소 검증은 RTX 3080 20GB 두 장을 X99 시스템의 별도 CPU root port에 연결한 구성에 한정되며 다른 카드와 보드, 스위치, 드라이버는 시험하지 않았습니다. 따라서 높은 프리필 수치와 무오류 부하 시험은 해당 환경의 결과로 보는 편이 정확합니다. 댓글에서도 작업 중 새로 입력하는 토큰 비율에 따라 체감 효과가 달라진다는 점이 제기됐습니다. 프롬프트 처리가 병목인 사용자에게는 의미 있는 패치지만, 범용적인 생성 성능 개선이나 다른 시스템의 호환성까지 뒷받침하는 자료는 아직 없습니다.

AI 요약

메모리를 20GB로 개조한 RTX 3080 두 장의 P2P(peer-to-peer) 통신을 켜는 NVIDIA 오픈 GPU 커널 모듈 패치입니다. 기본 드라이버는 이 카드 조합에서 peer access를 허용하지 않아 CUDA, NCCL, vLLM의 GPU 간 복사가 호스트 메모리를 거칩니다. 패치는 GPU끼리 PCIe로 직접 복사하도록 경로를 바꿉니다. 프로젝트는 실험용이며 시스템 정지, 메모리 손상, 하드웨어 고장과 보증 무효화 위험을 명시합니다.

구현 방식과 적용 조건

이 패치는 기존 정적 BAR1 방식 대신 동적 BAR1을 사용합니다. peer가 접근하는 메모리 할당마다 BAR1에 창(window)을 매핑하고 사용 후 해제합니다. 전체 VRAM을 한꺼번에 BAR1에 올리지 않으므로 20GB 전체를 호스트에 노출할 수 있다고 설명합니다. 테스트 구성은 32GiB BAR1, NVIDIA 드라이버 615.71.09, Linux 커널 7.0.14, X99 메인보드와 Xeon E5-2696 v4, 각 카드가 CPU의 별도 root port에 연결된 환경입니다. IOMMU는 끄거나 passthrough 모드로 설정해야 하며 Secure Boot도 꺼져 있거나 모듈 서명 키를 신뢰해야 합니다.

P2P는 GA102 GPU 쌍에서 기본 활성화됩니다. 다만 정적 BAR1 사용, VRAM보다 작은 BAR1, 특정 보정값, 지원하지 않는 P2P 유형 등 조건에 걸리면 접근을 거부하고 커널 로그에 이유를 남깁니다. UVM과 HMM 메모리는 BAR1 peer 경로를 사용하지 않습니다. 프로젝트는 두 RTX 3080 20GB와 한 가지 플랫폼에서만 시험했으며 다른 GA102 카드도 미검증 상태입니다. 설치 스크립트는 모듈 해시를 확인하고 dry-run과 롤백 절차를 제공합니다.

P2P 통신 성능

작성자의 장비에서 단방향 대역폭은 5.78GB/s에서 10.27GB/s로, 양방향은 8.66GB/s에서 19.33GB/s로 증가했습니다. P2P 쓰기 지연은 13.6마이크로초에서 0.99마이크로초로 줄었습니다. NCCL 1GiB all-reduce 대역폭은 7.33GB/s에서 9.33GB/s가 됐고 all-gather와 reduce-scatter도 각각 약 1.45배로 늘었습니다. 반면 8바이트에서 32KiB 구간의 all-reduce 지연은 기존 13~15마이크로초에서 15~17마이크로초로 조금 늘었습니다. P2P 읽기는 쓰기보다 약 10배 느렸다고 보고합니다.

vLLM 결과와 검증

vLLM 0.31의 tensor parallel 2 구성에서 작성자가 측정한 프롬프트 처리량은 8k 입력 기준 2062에서 2273토큰/초, 32k에서는 1927에서 2113토큰/초로 늘었습니다. NCCL P2P와 커스텀 all-reduce를 함께 쓴 결과입니다. 128k에서는 1478에서 1575토큰/초로 증가했습니다. 생성 속도는 입력 길이와 설정에 따라 달랐습니다. 일부 설정에서 8k와 32k 구간이 12~32% 올랐지만 128k에서는 변화가 작거나 감소했고, 두 스트림을 합산하면 decode가 5~7% 증가했다고 적었습니다. 바이트 단위 정확성 검사 29건과 51분 vLLM 부하 시험 3365건에서는 실패나 커널 오류가 없었다고 보고하지만, 장시간 안정성이나 다른 시스템 호환성을 보장하지는 않습니다.

Reddit 반응

  • @No-Refrigerator-1672 — 별도 테스트에서 gpu-unlock과 P2P를 함께 켜자 8k~261.9k 프롬프트 처리량이 기본 구성보다 70~115% 늘었습니다. 생성 속도는 대체로 비슷했으며, 261.9k에서만 안정적인 개선이 보였습니다.
  • @fallingdowndizzyvr — 표에는 최대 29% 향상만 보이는데 70%는 어디서 나온 수치인지 물었습니다.
    • @No-Refrigerator-1672 — 표 오른쪽 끝의 두 열에 70~115% 수치가 있으며 모바일이나 old.reddit에서는 표가 잘릴 수 있다고 답했습니다.
  • @atzenn — 긴 프롬프트를 처음 넣을 때는 처리 속도 향상이 크게 느껴져도 이후 생성 단계가 세션 대부분을 차지하면 체감 효과가 줄 수 있다고 짚었습니다.
    • @No-Refrigerator-1672 — 문서를 한 턴에 2만~5만 토큰씩 넣는 자신의 작업에서는 개선이 크며, 프롬프트 캐시 적중률과 새 입력 토큰 비율에 따라 달라진다고 답했습니다.
  • @jayfraud — 개조한 RTX 3080 20GB 두 장에서 Qwen 3.8 Flash Next 프리필 속도가 522에서 770토큰/초로 늘었다고 공유했습니다.
  • @No-Refrigerator-1672 — 3060에서는 잘 작동한다는 댓글이 있지만, 이 프로젝트의 호환성은 제한적이라고 설명합니다. Windows용 P2P 패치는 없고 PCIe 연결이 제한된 시스템에서는 향상이 더 작을 수 있다고 답했습니다.
  • @enternoescape — 3060에서 잘 작동했다고 말하며 PCIe 속도와 지연이 성능에 영향을 주고, 보유한 장비로 시험할 가치는 있어도 구매 기대치를 걸지는 않겠다고 했습니다.

원문: GitHub 저장소 / 커뮤니티 반응: Reddit / 번역·요약: Trawling

원문 보기 ↗토론 보기 ↗