거대 언어 모델(LLM) 추론이 개인, 기업 및 규제 환경 전반에 걸쳐 민감한 정보와 독자적인 모델 컨텍스트를 처리하는 사례가 늘어남에 따라, 신뢰할 수 있는 실행 환경 내부에서 데이터를 처리하는 과정이 필수 요구사항으로 자리 잡았습니다. NVIDIA 컨피덴셜 컴퓨팅(Confidential Computing, CC)은 메모리가 암호화된 기밀 가상 머신(CVM), 기밀 GPU 및 암호화된 NVIDIA NVLink를 활용하여 이러한 워크로드를 안전하게 실행할 수 있는 경로를 제공합니다. 이를 통해 신뢰할 수 있는 하드웨어 위에서 프로덕션 AI 추론을 안전하게 구동할 수 있습니다.
NVIDIA TensorRT LLM과 같은 추론 프레임워크는 프레임워크 레벨의 최적화와 NVIDIA 가속 컴퓨팅을 결합하여 최고 수준의 AI 추론 성능을 제공합니다. 그러나 이러한 프레임워크가 CC가 활성화된 환경에서 실행될 때는 보안 실행 메커니즘으로 인해 메모리 이동, 타이밍, 스케줄링 및 다중 GPU 통신에 대한 기존의 전제 조건들이 달라지게 됩니다. 런타임이 이러한 변화에 맞춰 적응하지 못하면 성능 오버헤드가 발생하게 됩니다. 따라서 고성능을 유지하려면 추론 프레임워크와 컨피덴셜 컴퓨팅 환경을 함께 최적화해야 합니다.
NVIDIA Blackwell GPU 기반에서 기밀 추론 성능을 검토하는 AI 플랫폼 엔지니어들을 위해, 본 게시물에서는 TensorRT LLM과 같은 AI 추론 프레임워크가 추론 성능을 유지하면서 보안 실행을 반영하기 위해 적용하는 CC 인식형(CC-aware) 적응 구조를 살피고자 합니다. 아울러 엔지니어링 팀이 자체 워크로드에서 CC 오버헤드를 정량화하는 데 적용할 수 있는 통제된 평가 방법론을 제시합니다.
CC 오버헤드를 명확히 확인하기 위한 워크로드 선정
워크로드의 특성에 따라 CC 오버헤드가 드러나는 정도가 달라집니다. 요청 건수(Concurrency)가 많은 고부하 환경에서는 지연 현상이 다른 작업과 오버랩되면서 고정된 암호화 비용이 분산되어, CC가 직접 미치는 영향을 관찰하기가 더 어려워집니다.
이러한 성능 영향을 명확히 포착하기 위해서는 긴 입력 컨텍스트, 확장된 출력 생성, 그리고 낮은 동시 요청 수를 가진 워크로드를 선정해야 합니다. 긴 컨텍스트는 프리필(Prefill) 단계의 데이터 이동 부하를 극대화하고, 길어진 출력 생성 과정은 디코드(Decode) 단계에서 토큰당 발생하는 미세한 CC 오버헤드를 누적 및 증폭시키며, 낮은 동시 요청 수는 연산 오버헤드가 다른 동시 요청 처리 과정 뒤에 감춰질 기회를 제한합니다.
NVIDIA 성능 엔지니어링 팀은 본 평가 대상 워크로드에 이러한 특성을 반영했습니다.
| 파라미터 | 구성 내용 |
| 모델 | nvidia/DeepSeek-R1-0528-NVFP4 |
| 추론 프레임워크 | TensorRT LLM, PyTorch 백엔드 |
| 입출력 시퀀스 길이 | 32K 입력 / 1K 출력 |
| 동시 요청 수 | 1, 2, 4, 8, 16개 |
| 병렬 처리 구성 | TP=8, EP=1, PP=1 |
| KV 캐시 | FP8 |
통제된 CC 활성화 및 비활성화 비교를 통한 CC 오버헤드 측정
CC가 성능에 미치는 영향을 순수하게 격리하여 평가하려면, 두 가지 조건 하에서 동일한 워크로드를 실행해야 합니다. 모델, 하드웨어, 프레임워크 버전, 시퀀스 길이, 병렬 처리 구조, 동시 요청 수를 동일하게 고정한 상태에서 컨피덴셜 컴퓨팅을 비활성화한 환경(CC 비활성화)과 컨피덴셜 컴퓨팅을 활성화한 환경(CC 활성화)을 대조하여, CC 활성화 여부만이 유일하게 변하는 변수가 되도록 제어해야 합니다.
각 동시 실행 수준에서의 측정 방식은 다음과 같습니다:
- 출력 처리량 유지율: $100 \times (\text{CC 활성화 시 출력 토큰/초} \div \text{CC 비활성화 시 출력 토큰/초})$
- 지연 시간 오버헤드(토큰당 출력 시간, TPOT): $100 \times (\text{CC 활성화 시 TPOT} \div \text{CC 비활성화 시 TPOT} – 1)$
성능 분석 팀은 이러한 측정 항목을 활용하여 대상 워크로드에서 CC를 활성화했을 때 기존 기준 성능(CC 비활성화 상태)을 얼마나 유지하는지 정량화할 수 있습니다. NVIDIA 성능 엔지니어링 팀은 표 2에 요약된 하드웨어 및 소프트웨어 구성을 바탕으로 이 비교 검증을 진행했습니다.
| 구성 요소 | 버전 및 상세 사양 |
| 하드웨어 | NVIDIA DGX B200 시스템 1대 (NVIDIA B200 GPU 8대) |
| 플랫폼 | Intel TDX |
| 호스트 OS | Ubuntu 25.10 |
| 호스트 커널 | 6.17.0-20-generic |
| 게스트 OS | Ubuntu 24.04.4 LTS |
| 게스트 커널 | 6.8.0-124-generic |
| 게스트 vCPU | 256개 |
| 게스트 NUMA | 2개 노드 |
| NVIDIA 드라이버 | 595.71.05 |
| VBIOS | FW 1.4.x [97.10.64.00.0C] |
| GPU 전력 제한 | 1,000W |
| CUDA | 13.2 |
| TensorRT LLM | nvcr.io/nvidia/tensorrt-llm/release:1.3.0rc2 |
| NCCL | v2.30 |
| OpenSSL | 3.6.0 |
| 오케스트레이션 | Docker Container + NVIDIA Container Toolkit |
성능 평가 결과
그림 1과 그림 2에 나타난 바와 같이, 동시 요청 수 1~16 구간 전체에서 CC 활성화 환경은 비활성화 기준 대비 96.1%~98.2% 수준의 출력 토큰 처리량을 유지했습니다. 또한 평균 TPOT 지연 시간 오버헤드는 기준 대비 1.2%~4.3% 이내 수준으로 억제되었습니다.


CC 오버헤드의 원인 식별 및 절감 방안
NVIDIA Blackwell 컨피덴셜 컴퓨팅 아키텍처는 사용 중인 데이터와 워크로드를 보호하기 위해 하드웨어 기반의 보안 경로를 제공합니다. 아키텍처에 대한 자세한 개요는 하드웨어 기반 AI 보안: 성능 저하 없는 안전한 구현(Hardware-Rooted AI Security That Won’t Slow You Down) 문서를 참고하시기 바랍니다.
TensorRT LLM 사용자 및 프레임워크 개발자를 위해, 아래 내용에서는 이러한 보안 경로가 기존 런타임의 기본 전제 조건을 어떻게 바꾸는지, 그리고 TensorRT LLM이 그로 인한 성능 오버헤드를 줄이기 위해 어떻게 적응하는지 설명합니다.
호스트-디바이스 간 데이터 이동 최적화
B200 CC 환경에서는 GPU가 보호된 CVM 메모리에 직접 접근할 수 없으므로, 호스트에서 디바이스로의 전송이 소프트웨어 암호화 바운스 버퍼(Bounce buffer)를 거쳐 이뤄집니다. 이는 추론 프레임워크가 전제로 삼던 기존 동작 방식을 변화시킵니다. 즉, 고정 메모리(Pinned memory)가 더 이상 기존과 같은 비동기 전송 이점을 제공하지 못하며, 일부 복사 작업이 호출 스레드를 블로킹할 수 있습니다.
- 호스트-디바이스 전송 완화책: TensorRT LLM은 CC 인식형 메모리 선택 기법을 적용하여, 해당 경로에서 무조건 고정 메모리를 사용하는 대신 페이지 가능 메모리(Pageable memory)를 선택적으로 활용합니다.
- 디바이스-호스트 전송 완화책: TensorRT LLM은 반복적인 토큰 및 샘플링 데이터 읽기 작업을 비동기 워커 스레드로 전환하여, 디코드(Decode) 실행 과정에서 보호된 복사 작업이 메인 스케줄러를 블로킹하지 않도록 방지합니다. 자세한 내용은 TensorRT LLM PR #11573을 참고하시기 바랍니다.
커널 자동 튜너 타임아웃 측정의 안정화
커널 자동 튜너(Kernel autotuner)는 일반적으로 후보 기법들을 비교할 때 CUDA 이벤트를 사용합니다. 그러나 테스트된 CC 환경에서는 CUDA 이벤트 타임스탬프가 불안정한 타이밍 신호를 생성하여, 튜너가 상대적으로 느린 기법을 선택하는 원인이 될 수 있습니다.
- 완화책: TensorRT LLM은 CC 환경에서 기법을 측정할 때 CUDA 이벤트 대신 GPU
%globaltimer를 활용하고, CC가 아닌 환경에서는 기존 CUDA 이벤트를 유지합니다. 자세한 내용은 TensorRT LLM PR #11657을 참고하시기 바랍니다.
CC 인식형 다중 GPU 통신 알고리즘 선택
B200 CC 구성에서는 NVLS(NVLink SHARP) 멀티캐스트 기능을 사용할 수 없습니다. NVLS가 지원되지 않으면 NCCL_SYMMETRIC은 의도한 멀티캐스트 이점을 제공하지 못하며, 비멀티캐스트 집합 통신 경로로 전환되기 전에 메모리 등록 및 랭크 간 동시성 동기화 비용만 추가로 발생시킬 수 있습니다.
- 완화책: CC 환경을 타깃으로 하는 프레임워크는 NVLS 가용 여부를 감지하고, 주어진 메시지 크기, 토폴로지, 워크로드 특성에 맞춰 지연 시간을 최소화할 수 있는 통신 알고리즘을 선택해야 합니다.
NVIDIA 컨피덴셜 컴퓨팅 시작하기
NVIDIA 컨피덴셜 컴퓨팅은 기밀 VM, NVIDIA Blackwell GPU, 암호화된 NVLink 전반에 걸쳐 하드웨어 기반 보안을 확장하여 독자적인 모델, 기업 컨텍스트, 민감한 프롬프트를 처리 과정 전반에서 보호합니다.
컨피덴셜 컴퓨팅 환경에서도 성능 엔지니어링의 필요성이 사라지는 것은 아니며, 오히려 프레임워크 레벨의 인식 및 최적화가 더욱 중요해집니다. 안전한 데이터 이동, 자동 튜닝, 다중 GPU 통신을 처리하는 TensorRT LLM의 CC 인식형 최적화 기법을 적용함으로써, 8대의 NVIDIA B200 GPU 기반에서 기밀 DeepSeek-R1 추론 시 기존 CC 비활성화 처리량의 96% 이상을 유지하는 동시에 토큰당 지연 시간 오버헤드를 5% 미만으로 축소할 수 있었습니다.
기업이 프라이빗 추론 환경을 실제 프로덕션으로 전환할 때, 보안 설정과 추론 최적화는 단일 배포 과제로 통합 접근해야 합니다. 컨피덴셜 컴퓨팅을 활성화하고, 실행 환경의 무결성을 검증한 뒤, 실제 서비스할 동일한 워크로드를 바탕으로 CC 활성화 및 비활성화 성능을 벤치마킹하시기 바랍니다. 프라이빗 추론을 프로덕션으로 구축하는 AI 플랫폼 엔지니어 및 TensorRT LLM 사용자라면 보안 구성과 추론 최적화를 풀스택 엔지니어링 관점에서 종합적으로 다루어야 합니다.
기밀 추론 배포 계획을 세우시려면 NVIDIA Trusted Computing 기술 문서를 참고하시고, 최신 TensorRT LLM 기능 및 릴리스 노트를 확인해 보시기 바랍니다. 최신 소식을 지속적으로 확인하려면 NVIDIA Confidential Compute 뉴스를 팔로우하시기 바랍니다.
감사의 글
이 작업 전반에 걸쳐 공학적 기여, 기술적 지도, 분석 및 세심한 검토를 제공해 준 Dan Hansen, Sheel Pethe, Samuel Mendoza-Jonas, Moein Ghaniyoun, Vidhya Krishnan, Avinash Ahuja, Laikh Tewari, Laura Martinez, Matheen Raza에게 감사의 뜻을 전합니다.