掘金2026년 11월 1일 21:56중국어 → 한국어

중소기업 125B 모델 구동, 18GB VRAM 차이의 처리량 영향

RTX 5090 32GB 환경에서 125B 모델을 구동할 때 18GB VRAM 차이가 실제 처리량에 어떤 영향을 주는지 테스트 환경과 함께 정리했다.

중국어 원문을 AI로 번역했습니다. 고유명사와 수치는 원문 표기를 우선하며, 중요한 판단에는 아래 출처 원문을 함께 확인하세요.

작성자: 吴佳浩 작성 시각: 2026-10-24 테스트 환경:

- GPU: RTX 5090(32GB VRAM, 드라이버 580.142, CUDA 13.0, PCIe Gen3 ×16, 실측 13.9 GB/s)

- CPU: Intel Xeon Gold 5218 ×2(32 물리 코어 / 64 스레드, NUMA 노드 2개, AVX512-BF16 없음)

- Memory: 125.6 GiB RAM

- OS: Ubuntu 20.04.3 LTS(kernel 5.15.0-58)

- Engine: Strata v0.2.2(engine 0.1.47, CUDA 13.0, 공식 컨테이너 이미지)

- Model: Qwen3.8-Flash-Next Q2_0(125B급 MoE, 24,576 전문가 슬롯)

- 두 라운드 구성 완전 동일: CONTEXT=32k / KV=int8 / PARALLEL=1 / VISION=cpu / MTP spec4

- 유일한 변수: 1라운드에서는 같은 머신의 다른 컨테이너들이 GPU1의 18,106 MiB를 점유했고, 2라운드에서는 이들을 중지함

서문

엔지니어와 연구자를 위한 체계적 분석. 1편에서 메커니즘을 설명했다. 이번 편에서는 한 가지 일만 한다. 메커니즘의 각 단계를 실측 데이터로 못 박는 것이다. 나는 같은 머신, 같은 모델 파일, 같은 파라미터 세트로 두 라운드를 돌렸고, 유일한 차이는 그래픽카드에 남의 18 GB가 있느냐 없느냐였다. 그리고 나서 엔진 로그에서 2,890건의 요청별 텔레메트리(각 건마다 「전문가 캐시 적중률」과 「PCIe 오버플로 비율」 포함)를 파내어, 「VRAM → 처리량」이라는 사슬을 단계별로 분해했다. 이 글은 하나의 「용량 계획 참고표」로 봐도 된다. 주어진 VRAM에 대해 내가 어느 정도의 tok/s를 기대할 수 있는지 알려주고, 주어진 속도 목표에 대해 얼마나 많은 VRAM이 필요한지 알려준다.

참고: 이 글의 모든 성능 수치는 본机의 두 라운드 실제 부하 테스트(합계 1,507회 요청, 1,362개 리소스 샘플링 지점, 317개 서버 측 지표 샘플링 지점)에서 나왔으며, 검증되지 않은 추산은 명확히 표시한다. 호기심이 동해서, 남이 점유한 카드를 멈추고, 같이 한번 놀아보자--이 18 GB가 "금상첨화"인지 "생사가 걸린 문제"인지 보자고.

一. 실험 설계: 변수 하나만 변경

1.1 이 실험이 왜 할 만한 가치가 있는가

대부분의 「로컬 대형 모델 성능」 글의 문제는 모든 변수가 함께 변한다는 것이다. 양자화 등급을 바꾸고, 컨텍스트를 바꾸고, 동시성을 바꾼 다음, decode 수치 하나를 보고한다--이 수치는 귀인이 불가능하다.

나는 이번에 의도적으로 단일 변수 대조로 만들었다.

변수 1라운드 2라운드 모델 Q2_0 Q2_0(동일 파일) 엔진 0.2.2 / engine 0.1.47 동일 컨텍스트 32K 32K KV 정밀도 int8 int8 parallel 1 1 비전 이미지 리더 CPU CPU MTP spec4 spec4 GPU1 상의 기타 점유 18,106 MiB(3개 컨테이너) 0

1.2 중지한 것들, 그리고 롤백 방법

먼저 분명히 밝혀 「파괴적 조작」으로 오해받지 않도록 하자:

컨테이너 이미지 점유한 GPU1 VRAM 중지 전 가동 시간 ms_reranker7 ms_reranker:latest 8,730 MiB 8일 ms_reranker8 ms_reranker:latest 4,688 MiB 8일 ms_reranker9 ms_reranker:latest 4,688 MiB 8일 합계 18,106 MiB

- 중지 방식은 docker stop -t 30(우아한 중지, kill 아님)

- 컨테이너는 삭제되지 않았다, docker start ms_reranker7 ms_reranker8 ms_reranker9 로 완전히 복구 가능

- 완전한 컨테이너 구성 스냅샷이 보관됨(docker inspect 전체 JSON)

- 같은 머신의 다른 카드(RTX 4090) 위의 vLLM은 전 과정 동안 건드리지 않음

중지 후 GPU1의 상태:

index, name, memory.total, memory.used, memory.free 1, NVIDIA GeForce RTX 5090, 32607 MiB, 13743 MiB, 18367 MiB pid, process_name, used_gpu_memory 2027940, .../strata, 13670 MiB

1.3 재배포 후 첫 번째 일: 캐시가 어떻게 자동 확장되는지 보기

같은 이미지, 같은 -e 환경 변수로 재시작한 후 엔진이 스스로 캐시를 꽉 채웠다:

strata generate: expert cache auto: 8.31 GiB free, 700 MiB reserved (+184 MiB for the draft head) -> 5784 slots # 1라운드 strata generate: expert cache auto: 26.01 GiB free, 700 MiB reserved (+184 MiB for the draft head) -> 19530 slots # 2라운드

5,784 → 19,530, 3.38배. 이것이 2편 전체 이야기의 출발점이다.

二. 첫 번째 도약: VRAM → 캐시 커버리지(깔끔한 선형)

2.1 실측값

라운드 기동 시 여유 고정 예약 슬롯당 계산 실제 슬롯 커버리지 1라운드 8,509 MiB 884 MiB 1.318 MiB (8509−884)/1.318 = 5,786 5,784 23.5% 2라운드 26,634 MiB 884 MiB 1.318 MiB (26634−884)/1.318 = 19,537 19,530 79.5%

두 번 모두 완전히 일치했고, 오차는 0.04% 이내다(바이트 정렬 반올림에서 비롯됨). 이는 전체 체인에서 유일하게 "계산기로 계산할 수 있는" 관계이며, 이 글에서 가장 공학적 가치가 큰 대목이기도 하다. 이는 벤치마크를 돌리지 않고도 커버리지를 예측할 수 있다는 뜻이다.

2.2 고정 오버헤드가 일정한 것이 이 선형 관계의 전제다

| 회차 | 엔진 총 VRAM | 전문가 캐시 | 고정 오버헤드 | |---|---|---|---| | 1회차 | 13,670 MiB | 7,625 MiB | 6,045 MiB | | 2회차 | 31,674 MiB | 25,747 MiB | 5,927 MiB |

차이는 118 MiB, 2%다. 고정 오버헤드는 캐시가 커져도 커지지 않으므로, "더 준 VRAM"이 거의 전부 캐시로 들어간다.

3. 두 번째 점프: 커버리지 → 적중률(롱테일의 승리)

3.1 실측

엔진 로그에서 각 요청의 decode expert cache hit rate를 추출하여 회차별로 집계했다(생성 150–260 token의 비교 가능한 표본을 대상으로):

| 회차 | 적중률 p50 | 표본 수 | |---|---|---| | 1회차(공유) | 86.5% | 1,192 | | 2회차(독점) | 99.7% | 1,000 |

커버리지는 +56 퍼센트 포인트 늘었지만, 적중률은 +13.2 퍼센트 포인트만 늘었다. "수익 체감"처럼 보이지만, 실은 롱테일 분포다.

3.2 왜 커버리지 23.5%로 86.5%를 적중할 수 있는가

전문가 접근이 극도로 편중되어 있기 때문이다. Strata에는 expert-profile.bin(24,576개의 순위 쌍)이 있어, 라우팅 빈도에 따라 누가 먼저 캐시를 차지할지 결정한다:

strata generate: profile /opt/strata/terminal/data/expert-profile.bin: 24576 ranked pairs, built for 24576 slots strata generate: pre-filled 5784 of 5784 slots from the profile in 0.6 s (12647 MB/s); slot 0 verified

그래서 1회차의 그 23.5% 슬롯에는, 가장 뜨거운 전문가가 들어 있었다:

3.3 핵심은 "적중률의 높고 낮음"이 아니라 "얼마나 남았는가"다

여기에 직관의 함정이 있다. 86.5%는 높게 들리므로(거의 90%에 가까움) "괜찮다"고 느끼게 된다.

하지만 뒤집어 봐야 맞다:

1회차: 미적중 13.5% 2회차: 미적중 0.3% → 미적중량은 45배 차이

성능은 "적중"이 아니라 "미적중"에 의해 좌우된다. 그래서 뒤의 모든 데이터는 같은 방향을 가리킨다. 86.5%라는 정수에 시선을 두지 말고, 그 0.3%에서 13.5%의 구간을 보라는 것이다.

4. 세 번째 점프: 적중률 → PCIe 오버플로(절벽)

4.1 먼저 2,890건의 텔레메트리를 펼쳐 보자

엔진 로그에서 "전문가 캐시 적중률"과 "PCIe 오버플로 비율" 두 개의 요청별 기록을 짝지어 2,890건의 표본을 얻었다(두 회차에 걸쳐, 짧은 문답·긴 컨텍스트·동시성·과부하 등 각종 부하를 포괄). PCIe 오버플로 비율로 버킷을 나눴다:

| PCIe 오버플로 비율 | 표본 수 | Decode p50 | 상대 최고 | |---|---|---|---| | 0 – 0.5% | 1,681 | 231.8 tok/s | 100% | | 0.5 – 1% | 799 | 141.4 tok/s | 61% | | 1 – 2% | 151 | 138.0 tok/s | 60% | | 2 – 3% | 186 | 137.7 tok/s | 59% | | 3 – 5% | 33 | 132.3 tok/s | 57% | | 5 – 10% | 17 | 71.9 tok/s | 31% | | 10 – 20% | 22 | 69.8 tok/s | 30% |

이 그림은 이 글에서 가장 중요한 그림이다.

세 가지 특징:

- 0 → 0.5% 사이가 절벽이다: 231.8에서 141.4로, −39%.

- 0.5% → 3%는 거의 평탄하다: 141.4 → 137.7, 겨우 2.6%만 떨어진다. "이미 충분히 느리니 조금 더 느려져도 상관없다"는 뜻이다.

- 5% 이상에서 2차 절벽: 141 → 72, 다시 절반으로 떨어진다. 이 시점에 시스템은 이미 "운반 주도" 모드에 들어간다.

4.2 적중률 버킷 교차 검증

같은 표본을 적중률로 버킷을 나눠도 결론은 일치한다:

| 적중률 | 표본 | Decode p50 | Decode 구간 | |---|---|---|---| | 30–50% | 5 | 57.4 | 27.0 – 83.6 | | 50–60% | 9 | 66.6 | 33.2 – 132.3 | | 60–70% | 149 | 136.9 | 26.8 – 145.4 | | 70–80% | 137 | 138.8 | 48.3 – 155.7 | | 80–90% | 1,403 | 141.1 | 67.3 – 178.8 | | 90–95% | 128 | 143.1 | 99.7 – 211.2 | | 95–99% | 90 | 280.3 | 126.2 – 309.0 | | 99–100% | 969 | 249.9 | 168.0 – 342.6 |

Pearson 상관계수 r = 0.779 (n = 2,890).

95% 지점의 도약에 주목하라: 90–95%는 아직 143인데, 95–99%는 곧바로 280이다. 이는 선형 상승이 아니라, 임계값을 넘은 뒤의 변속이다.

4.3 회차별 직접 대비

| 회차 | 적중률 p50 | PCIe 오버플로 p50 | Decode p50 구간 | |---|---|---|---| | 1회차 | 86.5% | 0.50% | 139.8 (67 – 168) | | 2회차 | 99.7% | 0.00% | 253.1 (126 – 343) |

2회차는 PCIe 오버플로를 0.00%까지 밀어냈다 — 이것이 "+82% 처리량"의 직접적 원천이다.

5. 왜 1%의 오버플로가 39%를 비싸게 만드는가

5.1 먼저 대역폭으로 계산해 보니, 앞뒤가 맞지 않는다

토큰당 480회 전문가 조회(48층 × 10 전문가) × 1% 오버플로 = 4.8개 전문가 × 1.38 MB / 전문가 = 6.6 MB / token ÷ 13.9 GB/s(실측 PCIe Gen3 ×16 대역폭) = 0.47 ms / token, 그런데 141 tok/s = 7.1 ms / token → 0.47 / 7.1 = 6.6%

이론상으로는 6.6%만 느려져야 하는데, 실측은 39% 느려졌다. 6배 차이다.

그래서 비용은 "느리게 옮기는 것"이 아니라 "오래 기다리는 것"이다.

5.2 진짜 비용: 파이프라인 버블

GPU 연산은 고도로 병렬적이지만, 의존성은 직렬적이다. 한 배치의 전문가가 도착하지 않으면 뒤따르는 연산자들은 그저 기다릴 수밖에 없다. 기다리는 동안 SM은 idle 상태인데도 드라이버는 여전히 「occupied」라고 보고한다—이것이 바로 「가동률 89%인데 속도는 절반」의 근원이다.

5.3 전력 소모 곡선으로 "가짜 바쁨"을 실증하다

| 회차 | GPU 가동률(평균) | 평균 전력 | 최대 전력 | 전력 상한 대비 | | --- | --- | --- | --- | --- | | 1회차 | 89.1% | 229.7 W | 311.9 W | 40% – 54% | | 2회차 | 89.8% | 336.7 W | 472.4 W | 59% – 82% |

가동률은 거의 같지만(89.1% vs 89.8%), 전력은 47% 차이가 났다.

이번 실험에서 가장 기억할 만하다고 느낀 한 가지다:

GPU 가동률은 「일이 있는지 없는지」이고, 전력은 「한 일이 산출물을 냈는지」다. 이 둘이 괴리될 때, 병목은 반드시 데이터 이동 경로에 있다.

6. 3계층 효율: 절대·한계·에너지

같은 숫자 묶음이라도 세 가지 서로 다른 분모로 보면 세 가지 서로 다른 결론이 나온다. 이 절에서는 세 가지를 모두 계산하는데, 그것들이 종종 혼용되기 때문이다.

6.1 절대 효율: GiB당 몇 tok/s

| 회차 | 엔진 메모리 | Decode | tok/s per GiB | | --- | --- | --- | --- | | 1회차 | 13.4 GiB | 140.6 | 10.5 | | 2회차 | 30.9 GiB | 256.2 | 8.3 |

여기까지 보고 많은 사람이 "한계 수익 체감"이라고 결론 내린다. 이 결론은 틀렸다. 왜냐하면 고정 오버헤드까지 분모에 포함시켰기 때문이다.

6.2 한계 효율: 전문가 캐시 1 GiB 추가당

Δ전문가 캐시 = 25,747 − 7, 625 = 18 , 122 MiB ≈ 17.7 GiB Δ decode = 256.2 − 140.6 = 115.6 tok/s → 6.53 tok/s per GiB 전문가 캐시

올바른 계산법은 선형 회귀를 하고 절편을 구하는 것이다:

1회차: 7.45 GiB 캐시 → 140.6 tok/s 2회차: 25.14 GiB 캐시 → 256.2 tok/s 기울기 = (256.2 − 140.6) / (25.14 − 7.45) = 6.53 tok/s per GiB 절편 = 140.6 − 7.45 × 6.53 = 91.9 tok/s

즉: 캐시를 1 GiB 추가할 때마다 선형으로 6.53 tok/s씩 늘어난다. 절편 91.9의 의미는 「캐시가 0일 때의 이론 속도」—이것은 외삽값이며 실측하지 않았고, 오직 선형 회귀의 자기일관성을 검증하는 데만 쓰이며 실제 성능으로 인용해서는 안 된다.

이 선형 관계가 이 글에서 가장 실용적인 결론이다. 그것은 「주어진 메모리로 속도를 예측」하는 일을 반드시 벤치마크를 돌려야 하는 일이 아니라 곱셈 문제로 만들어 준다.

6.3 에너지 효율: token당 몇 줄(joule)

가장 흔히 간과되지만, 생산 배포에 가장 중요한 계층이다:

| 회차 | 평균 전력 | Decode | J / token | 상대 | | --- | --- | --- | --- | --- | | 1회차 | 229.7 W | 140.6 tok/s | 1.634 J | 기준 | | 2회차 | 336.7 W | 256.2 tok/s | 1.314 J | −19.6% |

전기를 47% 더 써서 82% 더 많은 일을 해냈다 → 단위 에너지 소모는 20% 감소. 이것도 "가짜 바쁨"의 대가다: PCIe를 기다리는 동안 GPU는 그대로 전기를 소모하지만 산출물은 없다.

6.4 3계층 요약

| 계층 | 지표 | 1회차 | 2회차 | 올바른 결론 | | --- | --- | --- | --- | --- | | 절대 | tok/s per GiB 총 메모리 | 10.5 | 8.3 | 표면상 체감, 오도 | | 한계 | tok/s per GiB 캐시 | — | 6.53 | 선형, 체감 아님 | | 에너지 | J per token | 1.634 | 1.314 | −19.6% |

7. 반례: 메모리가 늘었는데 왜 parallel=4를 켤 수 없나

메모리가 늘어난 뒤 가장 자연스러운 생각은 "동시성을 더 켜자"는 것이다. 나는 4가지 구성을 대조했고, 결론은 이 직관을 부정했다.

7.1 4가지 구성 실측

| 구성 | 캐시 | slots | parallel | c=1 decode | c=4 | 클라이언트당 | 집계 피크 | | --- | --- | --- | --- | --- | --- | --- | --- | | B1 기준 | 32K 25.14 GiB | 19,530 | 1 | 204.3 | — | | 220.0 (c=2) | | B2a | 32K 22.90 GiB | 17,789 | 4 | 185.7 | 58.1 | | 179.3(c=8) | | B2d | 64K 22.25 GiB | 17,279 | 2 | 128.9 | 79.4 | | 149.5(c=8) | | B3 권장 | 64K 23.48 GiB | 18,240 | 1 | 218.9 | — | | 214.7 (c=8) |

핵심 발견: parallel=4의 집계 처리량(179.3)이 오히려 parallel=1(220.0)보다 낮았고, 단일 스트림 decode도 204에서 186으로 떨어졌으며, 4 동시성일 때 클라이언트당 58 tok/s밖에 남지 않았다.

7.2 메커니즘: 동시성은 확장이 아니라 분할

parallel=N은 「차를 넓히는」것이 아니라 「기름을 N등분하는」것이다. 각 slot의 커버리지가 약 1/N로 떨어지고 PCIe 오버플로가 급증하여, 4절의 그 "절벽"이 동시에 N번 발동한다.

7.3 언제 멀티 슬롯을 켜야 하나

이 32GB 카드에서는 parallel=1이 유일한 정답이다.

8. 하드웨어 자원 프로파일과 병목 위치 파악

8.1 두 회차의 자원 비교

2초에 한 번 샘플링, 두 회차 합계 1,362개의 유효 샘플 포인트:

지표 | 1차(공유) | 2차(독점) | 2차 권장 구성 GPU 이용률 평균 / p95 / max | 89.1% / 100% / 100% | 84.3% / 100% / 100% | 89.8% / 100% / 100% VRAM 점유 | 31,864 MiB | 31,879 MiB | 31,830 MiB VRAM 점유율 | 97.7% | 97.8% | 97.6% 온도 평균 / max | 44.5 / 53 ℃ | 52.8 / 59 ℃ | 52.1 / 55 ℃ 전력 평균 / max | 229.7 / 311 W | 336.7 / 472 W | 336.8 / 466 W SM 클럭 평균 / max | 2,828 / 2,895 MHz | 2,820 / 2,887 MHz | 2,832 / 2,895 MHz CPU load1 평균 / max | 26.3 / 32.1 | 20.3 / 28.0 | 24.2 / 30.4 시스템 메모리 평균 | 104.97 GiB | 96.31 GiB | 96.74 GiB MTP 수용률 | 64.0% | 63.5% | —

8.2 제외법: 네 가지 "흔한 용의자"가 전부 성립하지 않는다

8.3 두 가지 하드 제약

제약 1: VRAM 상한이 커버리지 상한을 결정한다.

카드 가용 ≈ 31.8 GiB − 고정 오버헤드 6.0 GiB = 캐시에 줄 수 있는 25.8 GiB ÷ 1.318 MiB/슬롯 = 19,600 슬롯 ÷ 24,576 = 79.8 %

32GB 카드에서 80% 커버리지가 천장이다. 100%까지 올리려면 약 38.5 GiB의 가용 VRAM( = 32.1 GiB 캐시 + 6.0 GiB 오버헤드)이 필요하며, 이는 곧 48GB 카드다.

제약 2: PCIe Gen3 ×16 = 13.9 GB/s.

strata generate: PCIe probe: 13.9 GB/s host -> device (best of 13.8 13.8 13.9 13.9 ) -> pcie_frac 0.38 (default 0.55 )

이것은 엔진이 스스로 측정한 값이며, 4절의 그 절벽에 대한 물리적 근거이기도 하다. RTX 5090 자체는 Gen5를 지원하지만, 이 카드는 Gen3 ×16 슬롯에 꽂혀 있다—— 링크 성능은 카드 성능의 4분의 1에 불과하다.

8.4 병목은 이미 이동했다

9. 안정성과 동시성: 큐잉 의미론의 실증

9.1 장시간 안정성: 두 차례 모두 실패 제로

두 차례 모두 100% 성공, 드리프트 제로, VRAM 누수 제로였다.

9.2 동시성 스캔: 처리량은 평탄, 지연은 선형

동시성 c | 1차 집계 tok/s | 2차 집계 tok/s | 1차 TTFT p50 | 2차 TTFT p50 1 | 86.8 | 192.0 | 0.28 s | 0.16 s 2 | 116.4 | 220.0 | 1.63 s | 0.80 s 4 | 119.4 | 216.5 | 3.24 s | 1.94 s 8 | 122.0 | 213.2 | 6.23 s | 3.54 s 16 | 118.6 | 209.3 | 13.15 s | 7.28 s

이것이 "큐잉 의미론"의 직접적 증거다:

c: 1 2 4 8 16 처리량: 192 220 216 213 209 ← 평탄(심지어 미세 하락) TTFT: 0.16 0.80 1.94 3.54 7.28 ← 근사 선형 증가

단일 카드의 전문가 이동 대역폭은 공유된다. 다중 클라이언트는 그것을 더 빠르게 만들지 않고, 각 요청이 더 오래 기다리게 만들 뿐이다. 이는 또한 7절에서 parallel=4가 오히려 더 나빴던 이유도 설명한다—— 그것은 "진짜 동시성"조차 얻어내지 못했고, 캐시가 잘게 쪼개진 것만 얻었다.

9.3 과부하: 32 동시성일 때의 동작

지표 | 1차 | 2차 요청 / 성공 | 32 / 32(100%, 전부 200) | 32 / 32(전부 200) 실제 소요 시간 | 20.94 s | 13.0 s TTFT p50 / p95 / max | 10.95 / 19.19 / 20.47 s | 6.69 / 12.01 / 12.79 s

두 차례 모두 요청을 거부하지 않았고, 전부 큐에서 대기하다 완료되었다. 이는 이 배포에 진입 제어(admission control)가 활성화되어 있지 않음을 보여준다—— 프로덕션 환경에서는 큐 상한을 두어야 하며, 그렇지 않으면 지연이 통제 불가능하게 팽창할 것이다.

10. 결론과 용량 계획표

10.1 다섯 단계 전달 사슬의 실측 결론

10.2 용량 계획 요약표

실측된 두 가지 점(고정 오버헤드 ≈ 6.0 GiB, 1.318 MiB/슬롯)과 선형 피팅(절편 92 tok/s, 기울기 6.53 tok/s per GiB)을 기반으로:

整卡 가용 专家 캐시 커버리지 기대 적중률 기대 decode 설명 12 GiB 5.1 GiB 16% ~82% ~125 tok/s 간신히 사용 가능(캐시가 매우 얇음) 14.2 GiB 7.45 GiB 23.5% 86.5% 140.6 tok/s 실측 1회차 18 GiB 11.1 GiB 35% ~90% ~165 tok/s 추산 24 GiB 17.1 GiB 54% ~96% ~204 tok/s 추산 31.8 GiB 25.1 GiB 79.5% 99.7% 256.2 tok/s 실측 2회차(整卡) ≥ 38.5 GiB 32.1 GiB 100% 100% ~300 tok/s 48GB 카드에 전부 상주 가능(추산)

환산 관계: 캐시 ≈ 整卡 가용 − 6.0 GiB, 슬롯 = (캐시 바이트 − 884 MiB) / 1.318 MiB, decode ≈ 92 + 6.53 × 캐시GiB (92는 피팅 절편, 외삽값).

10.3 세 문장으로 마무리

핵심 판단 한 가지: VRAM은 "충분하냐"가 아니라 "핫 전문가를 넣을 수 있냐"이며, 넣지 못할 때의 대가는 선형적인 할인이 아니라 절벽이다.

10.4 이 글의 측정 한계

- Decode는 회차 간 비교는 가능하지만 콘텐츠 간 비교는 완전히 가능하지 않다: MTP 수용률은 생성 콘텐츠에 따라 변동하며(실측 63.5%–64.0%, 단일 요청 구간은 더 넓음), 같은 회차 내 서로 다른 요청의 decode는 본질적으로 ±15% 변동이 있다.

- 적중률과 속도는 상관관계(r=0.779)이며, 엄격한 인과관계는 아니다. 둘 다 캐시 커버리지에 의해 구동되지만, 요청 길이와 컨텍스트 길이는 교란 요인이다.

- 용량 계획표의 12 / 18 / 24 / 38.5 GiB 네 행은 추산이며 실측이 아니다. 절편 92 tok/s 역시 외삽이다.

- KV와 "활성화/CUDA 컨텍스트"는 구조적 추산이며, 오차는 약 ±300 MiB다.

- Q2_0 + 32K/64K + parallel 1/2/4만 측정했고, IQ3_XXS 등 다른 등급은 측정하지 않았으며, 멀티 GPU도 측정하지 않았다.

- PCIe는 Gen3 ×16으로 고정했다: Gen4/Gen5로 바꾸면 제4절의 절벽 위치가 이동하고 "오버플로 비율"의 문턱은 완화되지만, "오버플로 → 하락"이라는 정성적 결론은 변하지 않는다.

- 같은 머신의 다른 4090 한 장은 내내 vLLM이 점유하고 있었으며(43,573 MiB, 연산 이용률 0%), 측정에 참여하지 않았지만 PCIe/메모리 대역폭에 경미한 간섭이 있었을 수 있다.

부록 A: 두 회차 기본 부하 테스트 원시 데이터

A.1 공식 표준 벤치마크(strata bench run, 동일 프로토콜)

케이스 1회차 2회차 변화 short decode / TTFT 136.8 tok/s / 0.389 s 235.4 tok/s / 0.23 s +72% / −41% 4K prefill / TTFT / decode 1,710.5 / 2.416 s / 132.6 3,520.6 / 1.18 s / 205.7 +106% / −51% / +55% 16K prefill / TTFT / decode 3,314.4 / 4.99 s / 134.8 5,528.9 / 2.99 s / 218.4 +67% / −40% / +62% 품질 검사(12항목) 11/12 12/12 +1 21개 요청 총 소요 시간 81 s 47 s −42%

A.2 장문 컨텍스트 비교(콜드 프리픽스)

프롬프트 규모 1회차 2회차 5,702 tok 2.54 s / prefill 2,204 / decode 139.0 1.42 s / 3,851 / 236.7 23,301 tok 7.31 s / 3,182 / 153.8 4.27 s / 5,452 / 246.9 29,133 tok 9.56 s / 3,047 / 136.8 — 34,941 tok ❌ 400(32K 윈도 초과) —

A.3 새로 열린 능력

능력 1회차 2회차(권장 구성) 최장 사용 가능 프롬프트 29,133 tok(32K 윈도) 43,677 tok(64K 윈도) 새 이미지 분석 TTFT 3.57 s(CPU 이미지 읽기) 0.534 s(GPU 이미지 읽기) 이미지 VRAM 비용 켜기 불가(410 MiB밖에 남지 않음) ~1,645 MiB(≈ −11 tok/s)

부록 B: 2,890건의 텔레메트리는 어떻게 나왔나

엔진은 요청 하나를 다 처리할 때마다 두 줄의 로그를 쓴다:

strata serve: prompt 26 tokens = 0 reused + 26 read in 43 ms, 192 generated in 1367 ms (140.5 tok/s), drafts accepted ... strata serve: decode expert cache hit rate: 86.3% (23414 hits / 27131 lookups); 412 more read by the GPU over PCIe or from another GPU (2.31% of all 17850 routed)

나는 스크립트로 이 두 종류의 줄을 순서대로 짝지어, 각 요청의 삼중항 (적중률, PCIe 오버플로 비율, decode)을 얻었고, 두 회차에 걸쳐 총 2,890건이었다.

- 샘플링 범위: 공식 벤치마크(단문/4K/16K), 동시성 스캔(c=1/2/4/8/16), 장시간 안정성(c=1 및 c=4), 장문 컨텍스트(4K/16K/18K/20K), 이미지 입력, 과부하(32 동시성)

- 짝짓기 방식: "생성 줄이 앞, 적중률 줄이 바로 뒤"인 엄격한 인접 쌍만 받아들여 오배치를 피했다

- 데이터셋: results-fullvram/vram-efficiency-dataset.json (581 KB)

- 상관계수는 Pearson으로 계산, n=2,890, r=0.779

방우(邦友) 여러분, 두 번째 글의 숫자는 여기까지입니다.

돌이켜 보면, 가장 의외였던 것은 "+82%"라는 결과가 아니라,それが 사실 계산해 낼 수 있는 것이었다는 점이다. 슬롯당 1.318 MiB의 공식, 6.53 tok/s per GiB의 기울기, 95% 부근의 임계값. 실행하기 전에 나는 네 가지 예측을 적어 두었고, 실행이 끝난 뒤 네 가지 모두 적중했다. 이는 어떤 단일 숫자보다도 이 메커니즘이 "현학"이 아니라 "이해 가능한" 것임을 더 잘 보여 준다.

다음 편은 이 시리즈의 마지막 글이자, 가장 그대로 따라 하기 쉬운 글이다. 하드웨어 자가 점검, 컨테이너 배포의 세 가지 함정, 모델 다운로드와 형식 검증부터 시작해, 기동, 스모크 검증, 다섯 가지 부하 테스트의 완전한 스크립트, 그리고 튜닝 체크리스트와 장애 속조회 표까지 다룬다. 모든 명령과 출력은 이 머신에서 실제로 실행한 것이다.

이 글이 도움이 되었다면 좋아요, 즐겨찾기, 공유를 환영하며, 「전스택 아키텍트 노트(全栈架构师笔记)」도 팔로우해 주시기 바란다. 다음에도 우리는 계속 함께 이런 새로운 것들을 실행해 이해하고, 테스트해 이해하고, 또 설명해 이해해 나갈 것이다.

吴佳浩Alben

AI扫地僧 @China

134

글

222k

조회

405

팬

출처 원문