상태: 초안 (2026-10-07). 암호화·복호화 속도, 무결성 검사, 그리고 복호화한 가중치를 메모리 볼륨에 놓고 vLLM 서버를 띄우는 경로(0.6B 모델)는 필자가 직접 잰 값입니다. 기밀 컴퓨팅은 하드웨어가 없어 직접 시험하지 못했고, 논문과 벤더 문서의 서술을 열어 확인해 인용했습니다. 큰 모델과 여러 GPU 에서의 적재는 재지 않았습니다(미실측). 작성 규칙: 실측 데이터가 기본이고, 못 잰 것은 「미실측」으로 표시합니다.
1. 질문을 먼저 정한다: 무엇으로부터 가중치를 지키는가
「모델을 암호화한다」는 말은 위협을 정하지 않으면 의미가 없습니다. 가중치가 노출되는 길은 여러 곳이고, 암호화가 막는 곳은 그중 일부입니다.
| 위협 | 예 | 저장 시 암호화 | 그 밖에 필요한 것 |
|---|---|---|---|
| 저장소·백업·이미지 레지스트리에서의 유출 | 버킷 권한 오류, 백업 테이프 분실, 이미지 레이어 유출 | 막음(키가 따로 있다면) | 키를 저장소와 다른 곳에 둠 |
| 전송 중 도청 | 노드와 저장소 사이 | TLS 가 막음, 저장 시 암호화는 이중 방어 | mTLS |
| 파일 변조·바꿔치기(공급망) | 악성 가중치로 교체, 순서 바꾸기 | 인증 암호(GCM)가 탐지(4절에서 확인) | 서명과 출처 검증 |
| 실행 중인 서버의 메모리 덤프 | 노드 root, 같은 노드의 악성 파드, 디버거 | 막지 못함(복호화된 가중치가 메모리에 있음) | 접근 통제, 기밀 컴퓨팅 |
| 서빙 API 로의 기능 복제 | 대량 질의로 출력을 모아 모방 모델 학습 | 무관 | 속도 제한, 이상 탐지, 계약 |
| 서빙 API 로의 파라미터 추출 | 로짓과 로그 확률을 노출하는 API 에서 마지막 층의 실제 파라미터를 복원(Carlini 외, ICML 2024) | 무관 | 노출하는 필드 제한(logprobs, logit bias 조합 금지) |
이 글은 첫 줄, 셋째 줄(저장 시 암호화와 무결성)의 비용과 효과를 재고, 넷째 줄이 왜 남는지를 정리합니다.
2. 방법
| 항목 | 값 |
|---|---|
| 대상 | Qwen3-1.7B 의 safetensors 두 조각 중 큰 조각(3.44GB) |
| 암호 | AES-256-GCM(cryptography 라이브러리), 64MiB 청크마다 12바이트 무작위 nonce, 16바이트 태그 |
| 추가 인증 데이터(AAD) | 청크 번호(8바이트). 청크 순서를 바꿔치기해도 탐지하기 위함 |
| 저장 형식 | 청크마다 (길이 4바이트, nonce 12바이트, 암호문, 태그 16바이트) |
| 환경 | 컨테이너(CPU 한도 6코어, 임시 디스크), 계산은 CPU 만 사용 |
| 측정 | 파일 암호화·복호화 처리량(디스크 쓰기·읽기 포함), 메모리 안의 순수 계산 처리량(디스크 없이 64MiB 버퍼 반복) |
3. 비용: 얼마나 느려지고 얼마나 커지는가
| 항목 | 값 |
|---|---|
| 평문 파일 읽기(페이지 캐시 포함이라 상한에 가까움) | 2.15 GB/s |
| 암호화, 파일에서 파일로 | 0.56 GB/s(스레드 1개와 4개가 같음) |
| 복호화, 파일에서 메모리로 | 스레드 1개 0.78, 2개 0.92, 4개 0.95 GB/s |
| 순수 계산, AES-256-GCM 암호화 | 스레드 1개 1.81, 2개 2.10, 4개 2.21 GB/s |
| 순수 계산, AES-256-GCM 복호화 | 스레드 1개 1.77, 2개 2.10, 4개 2.20 GB/s |
| 파일 크기 증가 | 3.441GB 가 3.441GB(청크 64MiB 마다 32바이트, 약 0.00005%) |
- 파일 크기는 사실상 늘지 않습니다. 청크마다 nonce 12바이트와 태그 16바이트, 길이 4바이트만 붙습니다.
- 복호화는 평문 읽기의 36~44% 속도입니다(0.78~0.95 대 2.15 GB/s). 다만 순수 계산은 1.8~2.2 GB/s 이므로 이 시험의 파일 경로는 계산이 아니라 입출력과 파이썬 쪽 처리에서 느려졌습니다. 이 구분을 분해하지는 않았습니다(추정).
- 스레드를 늘려도 이득이 작습니다. 계산은 1개에서 4개로 22% 만 늘었고(1.81에서 2.21) 파일 경로는 22%(0.78에서 0.95)였습니다. 처음에는 스레드가 같은 메모리 대역폭을 나눠 쓰기 때문이라고 추정했지만, 아래 「CPU 보강 시험」에서 이 추정이 틀린 것으로 드러났습니다.
- 하드웨어 가속(AES 명령어)이 있는 CPU 였습니다. 가속이 없을 때의 속도는 아래 「CPU 보강 시험」에서 환경 변수로 가속을 꺼서 쟀습니다.
콜드 스타트에 더해지는 시간
복호화 처리량 약 0.9 GB/s 를 그대로 쓰면 가중치 크기별 추가 시간은 이렇습니다(계산, 이 시험의 파일 경로 값 기준).
| 모델 크기 | 복호화 추가 시간(0.9 GB/s) | 순수 계산 속도(2 GB/s)였다면 |
|---|---|---|
| 3.4GB(1.7B bf16) | 약 3.8초 | 약 1.7초 |
| 7GB(12B 4비트) | 약 7.8초 | 약 3.5초 |
| 140GB(70B bf16) | 약 156초 | 약 70초 |
140GB 는 외삽한 계산이며 직접 재지 않았습니다. 70B 모델은 보통 여러 GPU 에 나눠 올리므로 복호화를 GPU 마다 병렬로 하면 시간이 나뉩니다(프로세스를 나눈 병렬 시험은 아래 「CPU 보강 시험」). 14편의 서버 준비 시간(재기동 35~55초, 이 중 가중치 적재가 4~6초)과 비교하면 작은 모델에서는 복호화 몇 초가 눈에 띄는 비율이고, 큰 모델에서는 모델 내려받기와 적재 시간에 묻힙니다.
4. 무결성: 변조와 바꿔치기를 탐지한다
GCM 은 암호화와 함께 태그로 변조를 검사합니다(NIST SP 800-38D). 두 가지를 직접 시도했습니다.
| 시도 | 결과 |
|---|---|
| 암호문 청크의 1바이트를 뒤집기 | InvalidTag 로 복호화 거부 |
| 1번 청크를 0번 자리에 넣기(순서 바꿔치기) | InvalidTag 로 복호화 거부(청크 번호를 AAD 에 넣었기 때문) |
| 정상 복호화 결과의 SHA-256 | 원본과 일치 |
- 청크 번호를 AAD 에 넣지 않으면 순서 바꿔치기는 탐지되지 않습니다. 각 청크는 자기 태그로는 올바르므로, 위치를 묶는 정보가 인증 대상에 들어가야 합니다. 직접 확인했습니다. 네 청크를 암호화해 두 청크의 자리를 바꿨을 때, AAD 가 없으면 복호화가 오류 없이 성공했고(원문과는 다른 내용), 청크 번호를 AAD 에 넣으면
InvalidTag였습니다. - 파일 끝을 잘라 청크를 통째로 빼는 공격은 이 시험에서 다루지 않았습니다. 직접 확인했습니다. 마지막 청크를 뺀 파일은, AAD 가 청크 번호뿐이면 3개 청크가 오류 없이 복호화되어 잘린 사실을 태그가 알려 주지 못했습니다. 총 청크 수를 AAD 에 넣으면 헤더의 총 개수를 고쳐 쓴 경우 모든 청크가
InvalidTag였고, 헤더를 그대로 두면 읽은 개수와 총 개수를 비교하는 단계(코드의assert)가 잘림을 잡았습니다. 즉 총 개수를 AAD 에 묶는 것과 개수 확인이 둘 다 필요합니다. - nonce 는 청크마다 무작위 12바이트입니다. NIST SP 800-38D 8.2.2절은 무작위 방식 IV 의 무작위 필드를 96비트 이상으로 요구하고, 8.3절은 같은 키로 하는 인증 암호화 호출의 총수를 2의 32제곱 이하로 제한합니다. 64MiB 청크로 나누면 이 한도는 같은 키로 약 256PiB 입니다(2의 32제곱 × 64MiB, 필자 계산). 140GB 모델은 약 2,100개 청크이므로 같은 키로 이런 모델을 약 200만 번 암호화할 때까지 한도 안이고, 한 파일 안에서 nonce 가 겹칠 확률은 생일 역설 근사로 약 2의 -75제곱입니다(필자 계산). 한도는 암호화 호출을 세므로, 같은 키로 재암호화를 반복하는 키 교체 절차에서는 호출이 누적됩니다. 복호화는 세지 않습니다.
- AAD 에 파일 식별자도 넣어야 합니다(필자의 추론이며 NIST 의 요구가 아닙니다). 이 글의 AAD 는 청크 번호와 총 청크 수만 담습니다. 같은 키로 여러 파일을 암호화하면 서로 다른 파일의 같은 번호 청크를 바꿔 넣어도 태그 검증이 통과합니다. 파일마다 따로 감싼 키(DEK)를 쓰거나 파일 식별자를 AAD 에 넣어야 하며, 6절의 DEK 권고와 맞물리는 지점입니다. 직접 확인했습니다. 같은 키로 만든 두 파일에서 파일 A 의 1번 청크를 파일 B 의 1번 자리에 넣었을 때, AAD 가 (청크 번호, 총 개수)뿐이면 복호화가 성공했고 1번 청크가 파일 A 의 내용이었습니다. AAD 에 파일 식별자를 더하면
InvalidTag였습니다.
암호문은 평문과 구별되지 않는다
첫 1MiB(헤더 포함)의 바이트 엔트로피는 평문(safetensors, bf16 가중치) 6.34 비트/바이트, 암호문 8.00 비트/바이트였습니다. 가중치 파일은 통계적 구조가 남아 있어 압축이나 패턴 분석으로 단서를 줄 수 있지만, 암호문은 무작위와 같습니다. 암호화한 파일은 압축도 되지 않으므로, 압축은 암호화 전에 해야 합니다.
서빙 엔진 적재 경로에 끼우면 얼마나 늘어나는가
복호화한 가중치를 메모리 볼륨(/dev/shm)에 놓고 그 경로로 vLLM 서버를 띄워 보았습니다. 모델은 Qwen3-0.6B(safetensors 1.50GB)이고 8GB급 GPU 한 장, 청크 64MiB, 청크 번호와 총 청크 수를 AAD 에 넣은 구성입니다. 서버 준비 시간은 서버 프로세스를 시작한 시점부터 상태 확인 응답이 오기까지이며, 복호화에 걸린 시간은 이 값에 포함되지 않습니다.
| 구분 | 측정값 |
|---|---|
| 암호화 (1.50GB) | 2.43초, 0.62 GB/s |
| 복호화 3회 (메모리 볼륨으로) | 2.02, 2.10, 2.18초(0.69~0.75 GB/s). 파이썬 시작과 임포트를 포함한 호출 전체는 2.3~2.4초 |
| 평문 디렉터리에서 서버 준비 | 68.0초(첫 기동), 29.4초, 28.3초 |
| 복호화 경로에서 서버 준비 | 49.4초(첫 기동), 28.3초, 27.3초 |
| 변조(암호문 1바이트 반전) | 복호화 단계에서 InvalidTag 로 중단. 가중치 파일은 만들어지지 않았고(설정 파일만 복사됨) 서버 시작 단계에 도달하지 않음 |
해석은 다음과 같습니다.
- 정상 상태의 추가 비용은 복호화 시간 그대로입니다. 두 번째 기동부터 서버 준비 시간은 평문과 복호화 경로가 같은 수준(28초 안팎)이었고, 여기에 복호화 약 2.3초가 앞에 붙습니다. 이 모델에서 콜드 스타트는 약 8% 늘었습니다.
- 첫 기동은 둘 다 길었습니다. 평문 첫 기동 68.0초는 컴파일 결과가 캐시에 없었기 때문으로 보이고, 복호화 경로의 첫 기동 49.4초는 모델 경로가 처음이라 캐시를 다시 만든 것으로 추정합니다(로그로 원인을 확인하지는 않았습니다). 경로나 설정이 바뀔 때마다 한 번씩 길어질 수 있으므로, 복호화 비용보다 이 효과가 더 클 수 있습니다.
- 변조는 서버가 뜨기 전에 거부됩니다. 복호화 단계가 실패하면 서버를 시작하지 않는 구성(시작 스크립트가 복호화의 종료 코드를 확인)이 전제입니다.
- 이 시험은 0.6B 한 모델과 GPU 한 장에서만 했습니다. 140GB 모델이나 여러 GPU 에서의 값은 재지 않았습니다(미실측).
CPU 보강 시험: 가속 끄기, 병렬화
위 시험의 남은 의문을 CPU 만으로 다시 재 보았습니다(일회용 파드, 22코어 서버 CPU 의 한 노드, cryptography 50.0.2, 64MiB 청크, 메모리만 사용). 이 노드에서는 다른 워크로드가 함께 돌고 있어 같은 시험의 절대값이 약 40% 흔들렸습니다(프로세스 1개의 복호화가 1.20 GB/s 로 나왔고, 스레드 시험의 1개는 2.00 GB/s). 그래서 비율만 의미를 둡니다.
| 시험 | 결과 |
|---|---|
| 기본 (AES-NI, PCLMULQDQ 사용) | 복호화 2.01 GB/s, 암호화 2.08 GB/s (단일 스레드) |
OPENSSL_ia32cap=~0x200000000000000 로 AES-NI 끔 |
0.47 GB/s (약 4.3배 느림) |
| AES-NI 와 PCLMULQDQ 모두 끔 | 0.29 GB/s (약 6.9배 느림) |
| 스레드 1, 2, 4, 8개로 복호화(한 프로세스) | 2.00, 2.52, 2.41, 2.44 GB/s |
| 프로세스 1, 2, 4, 8개로 복호화 | 1.20, 2.30, 4.24, 6.07 GB/s (1개 대비 1.9, 3.5, 5.1배) |
- AES 명령어가 없으면 복호화가 4~7배 느려집니다. 140GB 모델이면 위 외삽(약 70초)이 5분 안팎이 됩니다(계산). 클라우드의 일반 인스턴스는 대부분 가속이 있지만, 가상화 설정으로 CPU 플래그가 가려진 환경이라면 확인해야 합니다(
grep -m1 -o aes /proc/cpuinfo). - 스레드는 2개에서 멈췄지만 프로세스는 늘리는 대로 늘었습니다. 처음의 메모리 대역폭 추정은 틀렸습니다. 이 노드의 메모리 대역폭에 비해 2.5 GB/s 는 매우 작은 값이고, 프로세스로 나누자 8개에서 6 GB/s 까지 올랐습니다. 파이썬 한 프로세스 안에서 스레드 병렬이 막히는 이유를 이 시험이 분해하지는 않았습니다(원인은 미확인, 인터프리터 쪽 제약일 가능성). 실용적으로는 청크를 프로세스(또는 GPU 마다 별도 로더 프로세스)에 나눠 복호화하는 구성이 맞습니다.
- 한계: 한 노드의 단일 시험이고 파일 입출력은 뺐습니다. 여러 GPU 에 실제로 나눠 올리는 시간은 재지 않았습니다(미실측).
5. 막지 못하는 것: 실행 중의 가중치는 평문이다
서버가 모델을 쓰려면 복호화한 가중치를 메모리(GPU 메모리 포함)에 올려야 합니다. 그 순간부터는 노드의 root 나 같은 노드의 침해된 프로세스가 메모리를 읽을 수 있습니다. 일반 GPU 는 메모리를 암호화하지 않으므로 이 위협은 저장 시 암호화만으로 막히지 않습니다.
NVIDIA 의 기술 블로그(2023-05-31)는 H100 GPU 가 CPU 의 신뢰 실행 환경(AMD SEV-SNP, Intel TDX)과 함께 동작하는 기밀 컴퓨팅 기능을 제공한다고 설명합니다. 이 글은 이 기능을 직접 시험하지 못했습니다(데이터센터 GPU 가 없음). 같은 회사의 2023-08-03 블로그는 보호 방식을 이렇게 서술합니다. CPU TEE 가 가상 머신의 메모리를 암호화하고, GPU 는 하드웨어로 격리되며, CPU 와 GPU 사이의 데이터는 암호화된 바운스 버퍼를 거쳐 오갑니다. 반면 GPU 패키지 위의 HBM 은 일상적인 물리 공격 도구에는 안전하다고 간주되어 암호화하지 않는다고 적습니다. 따라서 기밀 컴퓨팅을 「GPU 메모리 암호화」라고 부르면 부정확하고, 막는 대상은 호스트 쪽 평문 노출과 호스트 관리자의 접근입니다. 또 같은 글은 CPU 와 GPU 사이 대역폭이 CPU 암호화 성능에 막혀 약 4GB/초라고 서술하는데, 시작할 때 가중치를 올리는 이 글의 경로에서는 이 값이 적재 시간을 좌우할 수 있습니다(벤더 서술이며 직접 재지 못했습니다). 키를 어떻게 안전하게 전달하는지(증명, attestation 후 키 공개)도 별개의 설계 문제입니다.
따라서 실무의 층은 이렇게 쌓입니다.
- 저장소 쪽: 가중치를 암호화해 두고 키는 KMS 나 Secret 관리 도구에 둡니다. 버킷 권한 오류가 곧 유출이 되지 않습니다.
- 적재 쪽: 시작할 때 키를 받아 복호화합니다. 복호화한 평문을 디스크에 남기지 않도록 메모리 기반 볼륨(
emptyDir의medium: Memory)을 쓰면 노드 디스크에는 평문이 남지 않습니다. 이 볼륨은 RAM 을 모델 크기만큼 차지하므로 노드 메모리와 파드의 메모리 한도에 포함해 계산해야 합니다(계산, 직접 시험하지 않음). - 실행 쪽: 노드 접근 통제(SSH, 디버그 파드 금지), 파드 보안 설정, 필요하면 기밀 컴퓨팅 노드.
- 출력 쪽: 속도 제한과 이상 질의 탐지. 가중치를 훔치지 않아도 출력을 모아 모방 모델을 만들 수 있습니다.
6. 키를 어디에 두는가
- 이미지나 가중치 저장소와 같은 곳에 두지 않습니다. 그러면 한 번의 유출이 둘 다 노출합니다.
- 키는 파드가 시작할 때 외부 KMS 에서 받고(파드의 신원으로 인증), 환경 변수에 평문으로 오래 두지 않습니다.
- 키를 바꾸는 절차(재암호화)가 필요합니다. 3.4GB 파일을 0.56 GB/s 로 다시 암호화하면 약 6초(계산)이지만 큰 모델은 오래 걸리므로, 파일을 감싸는 키(DEK)를 따로 두고 그 키를 마스터 키로 감싸는 방식이 키 교체 비용을 줄입니다.
7. 면접에서 나올 만한 질문
- 모델 가중치를 암호화하면 무엇이 보호되는가? 저장소·백업·레지스트리 유출과 변조(GCM 이면). 실행 중 메모리 덤프는 막지 못한다.
- GCM 을 쓰는 이유는? 암호화와 변조 탐지를 한 번에 한다. 1바이트를 뒤집으면 복호화가 거부되었다.
- 청크로 나눠 암호화할 때 주의할 점은? 청크 번호를 추가 인증 데이터에 넣어 순서 바꿔치기를 막고, 청크 수를 인증 대상에 넣고 읽은 개수를 확인해 잘라내기를 막고, 파일 식별자도 넣어 다른 파일의 청크가 섞이는 것을 막고(셋 다 직접 확인), nonce 를 겹치지 않게 한다.
- 복호화가 콜드 스타트를 얼마나 늘리는가? 이 시험에서 약 0.7~0.9 GB/s 였으므로 7GB 모델이 약 8~10초이고(외삽), 0.6B 모델은 실제로 서버 준비 약 28초에 복호화 약 2.3초가 더해졌다. 계산 자체는 2 GB/s 수준이다.
- 실행 중인 모델은 어떻게 지키는가? 노드 접근 통제와 기밀 컴퓨팅(CPU TEE 와 GPU 격리, PCIe 구간 암호화. HBM 자체는 암호화되지 않음). 이 글에서는 논문과 벤더 문서만 확인했다.
외부 근거
직접 재지 못했거나 재는 것으로 충분하지 않은 주장은 아래 자료를 열어 확인했습니다. 「초록만」은 본문이 아니라 초록까지만 읽었다는 뜻입니다.
| 주장 | 자료 | 확인한 내용 |
|---|---|---|
| nonce 와 호출 횟수 한도 | NIST SP 800-38D(2007) 8.2.2절, 8.3절 | 무작위 필드 96비트 이상, 같은 키의 인증 암호화 호출 총수 2의 32제곱 이하. 2026년 현재 개정 작업 중이나 효력 있는 문서는 2007년 판 |
| 기밀 컴퓨팅의 보호 범위 | NVIDIA 기술 블로그(2023-08-03) | HBM 은 암호화하지 않고, CPU TEE 와 격리와 암호화된 바운스 버퍼로 보호. CPU와 GPU 사이 약 4GB/초(벤더 서술) |
| H100 기밀 컴퓨팅의 추론 오버헤드 | Zhu 외, arXiv 2409.03992(Confidential Computing on NVIDIA Hopper GPUs: A Performance Benchmark Study) | 대부분의 일반 질의에서 7% 미만, 큰 모델과 긴 시퀀스에서는 거의 0. 70B 는 4비트 양자화로 한 장에 적재 |
| 같은 주제의 다른 측정 | Chrapek 외, arXiv 2509.18886(초록만) / Ibarra 외, arXiv 2505.16501(초록만) | 처리량 감소 4~8%(Llama2 7B~70B) / 모델을 교체하는 구성에서 비기밀 쪽이 처리량 45~70% 높음. 차이를 모델을 GPU 로 올릴 때의 암호화와 복호화 비용으로 돌림 |
| API 로의 파라미터 추출 | Carlini 외, ICML 2024(arXiv 2403.06634) | 로그 확률과 로짓 편향을 노출하는 API 에서 마지막 층을 복원. 대응은 속도 제한보다 노출 필드 제한이 실제 조치였음 |
| API 로의 기능 복제 | Tramèr 외, USENIX Security 2016(arXiv 1609.02943, 초록만) | 신뢰도 점수를 숨겨도 추출되는 경우가 있음 |
| 추론 서버가 장악된 경우의 탈취 | Rinberg 외, arXiv 2511.02620(초록만) | 정상 응답에 가중치를 숨겨 빼내는 위협을 정식화하고 검증 기반 탐지를 제안 |
열어 보지 못한 자료도 있습니다. RAND 의 모델 가중치 보호 보고서(2024)는 원문 접근이 막혀 열지 못했고, 그래서 유출 사례의 빈도에 관한 수치는 이 글에 적지 않았습니다.
확인하지 못한 것
- 기밀 컴퓨팅의 성능 비용과 실제 보호 범위. 하드웨어가 없어 재지 못했고, 아래 외부 근거의 범위(추론은 대체로 한 자릿수 퍼센트, 조건에 따라 약 20%까지, 모델을 교체하는 구성에서는 45~70% 차이)로만 짐작할 수 있습니다.
- 큰 모델과 여러 GPU 에서의 적재 시간. 0.6B 모델 한 개의 값만 쟀고, 병렬 복호화나 텐서 병렬 구성은 재지 않았습니다.
- GPU 로 복호화하는 방식, 큰 모델을 여러 GPU 에 실제로 나눠 올릴 때의 병렬 복호화 시간(CPU 보강 시험은 프로세스 병렬까지만 쟀습니다).
- 키 관리 시스템(KMS)의 호출 지연과 장애 시 동작.
참고 자료
- NIST SP 800-38D, GCM 과 GMAC 권고: https://csrc.nist.gov/pubs/sp/800/38/d/final
cryptography라이브러리의 AEAD 문서: https://cryptography.io/en/latest/hazmat/primitives/aead/- NVIDIA 기술 블로그, 기밀 컴퓨팅으로 민감 데이터와 AI 모델 보호하기(2023-05-31): https://developer.nvidia.com/blog/protecting-sensitive-data-and-ai-models-with-confidential-computing/
- NVIDIA 기술 블로그, Confidential Computing on NVIDIA H100 GPUs for Secure and Trustworthy AI(2023-08-03)
- Zhu 외, Confidential Computing on NVIDIA Hopper GPUs: A Performance Benchmark Study: https://arxiv.org/abs/2409.03992
- Carlini 외, Stealing Part of a Production Language Model: https://arxiv.org/abs/2403.06634
- 이 시리즈의 14편(서버 준비 시간), 8편(safetensors 형식과 모델 적재)
확인한 버전과 날짜
2026-10-07 기준. cryptography 라이브러리(AESGCM), 컨테이너 안의 파이썬 3.12, Qwen3-1.7B safetensors(속도 시험)와 Qwen3-0.6B(서버 적재 경로 시험, vLLM 0.31.0).