단일 MI300X에서 대형 모델을 서빙하는 용량 적합 설계
MI300X 한 장에 대형 모델을 상주시킬 때 KV 캐시 예산, 컨텍스트·동시성 제한, 패치와 장애 대응을 설계하는 방법
2026-09-02 · 최초 발행 2026-08-05
한 장에 들어가는 모델도 용량 경계는 남는다
DeepSeek-V4-Flash-0731을 추가 양자화나 오프로드 없이 AMD MI300X 한 장에서 프로덕션으로 구동한 구성과 패치 묶음이 공개됐다. Docker Compose 스택, SHA-256으로 고정한 파일 오버레이, 업스트림 참조 디프, 튜닝 표가 함께 제공됐다. 이 과정에서는 FP8 형식 처리, 고동시성 구간의 MoE 라우팅, 인과적 추측 검증, CPU KV 동기화, 미튜닝 커널 형상에 대한 수정이 필요했다고 기록돼 있다.
대형 모델을 서비스하려면 다중 노드를 구성해야 한다는 전제는 이 사례에서 약해진다. 모델이 단일 가속기 용량 안에 들어가면 노드 간 통신 지연과 장애 조합을 줄일 수 있다. 대신 남은 메모리가 많지 않은 환경에서 컨텍스트 길이와 동시 요청 수를 다뤄야 한다. 단일 장치에 맞춘 설계의 핵심은 가중치 상주, KV 캐시 예산, 요청 제한, 단편화 관리, 계측을 하나의 용량 적합 체계로 묶는 데 있다.
MI300X는 192GB HBM3와 5.3TB/s 메모리 대역을 제공하며, H100 SXM5와 비교하면 HBM 용량은 약 2.4배다. 이 구성에는 gfx942 계열 MI300X 1장(304 CU, 약 192GiB HBM), 동작하는 AMD 커널 드라이버, 최근 Docker Compose가 요구된다. CPU KV 티어에는 RAM 약 235GiB, 모델 캐시를 포함한 저장 공간에는 디스크 약 500GB가 필요하며 모델 캐시만 약 156GB다.
가중치와 KV 캐시가 공유하는 메모리 경계
가중치는 HBM에 고정 상주하고, 남은 메모리를 KV 캐시와 활성값 버퍼에 나눠 쓴다. 이 배분이 서비스가 감당할 수 있는 부하를 결정한다. 가중치와 활성값을 제외하고 남은 HBM이 KV 캐시 예산이며, 이 예산은 최대 컨텍스트 길이와 동시 요청 수의 곱을 제한한다.
예산을 넘는 요청은 대기시키거나 거부해야 한다. 초과를 허용하면 메모리 부족 실패로 이어진다. 모델이 지원하는 최대 컨텍스트와 현재 하드웨어에서 안정적으로 수용할 수 있는 컨텍스트도 구분해야 한다. 후자는 실측으로 정한 뒤 요청 계층에서 상한으로 강제하는 편이 낫다. 모델 계층에서만 제한하면 실패가 사용자 오류로 드러날 수 있다.
동시성 역시 KV 예산에서 역산한다. 고동시성 환경에서 MoE 라우팅 문제가 확인된 사례는 이 제한이 필요한 이유를 보여준다. 긴 컨텍스트 요청과 짧은 요청을 다른 대기열에 넣으면 긴 요청이 예산을 독점하는 상황을 줄일 수 있다.
페이지 단위 KV 관리도 필요하다. 연속 할당 요구가 커지면 총 여유 메모리가 남아 있어도 할당에 실패할 수 있기 때문이다. 장기 운영에서는 단편화가 누적되는지 관찰하고, 필요하면 정기 재기동을 운영 계획에 포함한다.
기동 경로와 패치를 재현 가능하게 남긴다
약 156GB인 모델 캐시는 로컬 디스크에 두고, 기동 때 네트워크 전송을 피하는 구성이 필요하다. 이 규모에서는 전송 시간이 기동 지연을 좌우한다.
파일 오버레이를 SHA-256으로 고정하고 업스트림과의 디프를 보관하면 어떤 수정이 적용됐는지 추적할 수 있다. 업스트림이 갱신될 때는 패치를 다시 적용해야 하는지 판단하는 절차도 필요하다. 적용 내용을 알 수 없는 상태에서는 업그레이드를 관리할 수 없다.
나이틀리 계열 vLLM ROCm과 AITER 조합을 프로덕션 스택으로 쓴 경우라면, 나이틀리 스택 사용과 그 위험 수용을 명시적으로 기록해야 한다.
상한은 실측한 실패 지점에서 정한다
문서에 적힌 요구사항이 아니라, 실제 기동 뒤 남는 HBM을 측정해 KV 캐시 예산을 확정한다. 이론 계산과 실측은 차이가 클 수 있다. 최대 컨텍스트와 최대 동시성을 각각 극단으로 올려 실패 지점을 확인해야 운영 상한을 정할 수 있다.
컨텍스트 정책은 업무별 실제 필요 분포를 기준으로 잡는다. 모델의 최대 컨텍스트를 그대로 열어 두면 일부 요청이 예산을 독점할 수 있다. 상한을 넘는 요청을 거부할지, 절단할지, 요약 후 재투입할지도 미리 결정해야 한다. 어느 방식도 무비용은 아니다.
동시성 상한을 넘는 요청은 대기열로 보낸다. 대기열 최대 길이와 대기 타임아웃도 함께 정한다. 무한 대기는 장애와 구분되지 않는다.
부하 시험은 짧은 요청 다수, 긴 요청 소수, 두 유형이 섞인 요청으로 나눠 수행한다. 혼합 부하만 시험하면 실패 원인을 분리하기 어렵다. 단편화는 단시간 시험에 드러나지 않을 수 있으므로 지속 부하 시험으로 누적 여부를 확인한다.
단일 가속기 장애는 곧 서비스 중단이다. 이중화 비용과 장애 영향을 비교해 이중화 여부를 결정하고 근거를 남겨야 한다. 다른 모델이나 외부 API를 대체 경로로 두는 방식도 가능하지만, 성능 차이는 사전에 검증해야 한다.
컨텍스트 상한과 동시성 상한 변경은 용량 재산정을 전제로 하는 승인 대상으로 다룬다. HBM 점유, KV 적중, 대기열 길이, 거부율을 상시 계측해야 한계선 가까이에서 운영하는 구성을 유지할 수 있다.
분산 구성과 비교할 때 달라지는 운영 조건
| 구분 | 단일 가속기 서빙 | 다중 노드 분산 서빙 |
|---|---|---|
| 노드 간 통신 | 없음 | 매 레이어 발생 |
| 운영 복잡도 | 낮음 | 높음 |
| 장애 조합 | 단순 | 복잡 |
| 확장 여력 | 제한적 | 큼 |
| 메모리 여유 | 거의 없음 | 확보 가능 |
| 이중화 비용 | 장치 단위 | 노드 세트 단위 |
단일 가속기 구성은 노드 간 통신이 없으므로 지연이 짧고 예측 가능하다. 장애 조합과 배포 단위도 단순해 구성 관리 부담이 줄어든다. 반면 메모리 여유가 거의 없어 컨텍스트와 동시성 상한은 하드웨어 제약을 직접 받으며, 부하가 늘면 수직 확장 외에는 대응 수단이 없다.
다중 노드 분산 구성은 메모리를 합쳐 더 큰 모델과 더 긴 컨텍스트를 수용하고, 노드 추가로 부하 증가에 대응할 수 있다. 일부 노드 장애를 흡수할 여지도 있다. 다만 레이어마다 노드 간 통신이 생겨 지연이 늘고, 노드 수가 증가할수록 장애 조합과 구성 불일치 같은 운영 사고 유형도 많아진다. 요구 컨텍스트와 동시성이 단일 장치 용량 안에 들어오는지 먼저 검증하는 순서가 필요하다.
원본 정밀도를 유지하면 배포된 체크포인트를 그대로 사용하므로 품질 저하 가능성이 없고, 별도의 품질 검증 부담도 없다. 공급자가 보고한 성능을 기준선으로 삼을 수 있다. 대신 가중치가 메모리를 크게 차지해 KV 캐시 예산이 줄고, 수용 가능한 컨텍스트와 동시성도 낮아진다.
양자화는 가중치 메모리를 줄여 KV 캐시 예산과 동시성을 늘리고 처리량을 개선할 수 있다. 그러나 자체 평가셋으로 품질 저하를 검증해야 하며, 저하가 특정 작업에서만 나타나는 경우 발견이 늦을 수 있다. 양자화 구현의 정확성도 검증 대상이다. 이 사례에서는 MI300X의 192GB HBM이 원본 정밀도 상주를 허용하는 전제이므로, 용량이 허용된다면 양자화를 피하는 선택은 검증 부담 측면에서 타당하다.
전용 장비 상주는 기동 시간이 서비스 지연에 영향을 주지 않으며, 지속 부하 환경에서는 단가를 낮출 수 있다. 커널 튜닝과 패치 적용도 자유롭다. 대신 유휴 구간 비용, 장치 장애 대응, 하드웨어 세대 교체 위험을 직접 감당해야 한다.
온디맨드 임차는 필요한 만큼만 비용을 지불하고 장치 장애를 공급자가 처리하며 최신 세대에 빠르게 접근할 수 있다. 하지만 약 156GB 모델 캐시를 매 기동 때 로딩해야 하고, 나이틀리 스택과 커널 패치도 임차 환경마다 다시 구성해야 한다. 모델 로딩 비용이 큰 대형 모델이라면 상주 구성의 이점이 커지므로, 임차는 검증과 실험 단계에 한정하는 선택이 실무적이다.
자원 제약을 운영 통제로 바꾸는 방식
가중치, KV 캐시, 활성값의 메모리 배분이 컨텍스트와 동시성의 상한을 결정하는 구조는 자원 제약 아래의 용량 계획 문제다. 실측으로 한계선을 확정하고 그 안에서 요청 상한을 선언하는 방식은 과부하 방지 통제가 된다.
해시로 고정한 파일 오버레이와 업스트림 디프 보존은 구성 관리와 변경 추적의 최소 조건이다. 단편화 누적 관측과 정기 재기동 계획은 장기 운영 성능 저하를 예방하기 위한 통제이며, 긴 요청과 짧은 요청을 나눈 대기열은 자원 독점을 막기 위한 스케줄링 방식이다.
대형 모델의 사양 발표에서는 단일 가속기 수용 가능성이 명시 항목으로 포함되는 흐름이 나타날 수 있다. 고용량 HBM 가속기가 다중 노드 구성을 대체하면서 서빙의 기본 단위가 작아지고, 해시 고정 오버레이와 디프로 설정을 배포하는 재현 가능한 구성 방식도 확산될 수 있다. 컨텍스트와 동시성 상한을 하드웨어 실측으로 선언하는 운영 규범 역시 이러한 구성에서 정착할 수 있다.
DeepSeek-V4-Flash-0731 사례는 192GB HBM이 원본 정밀도 상주를 허용할 때 다중 노드가 필수라는 전제가 달라질 수 있음을 보여준다. 다만 단일 가속기 구성의 성패는 가속기만으로 판단할 수 없다. CPU KV 티어용 RAM 약 235GiB, 디스크 약 500GB, 그리고 KV 예산에서 역산해 요청 계층에 강제하는 컨텍스트·동시성 상한까지 함께 설계해야 한다.
Sources
- ryanzhou/deepseek-v4-flash-mi300x | GitHub
- Bringing up DeepSeek-V4-Flash on AMD MI300X | Fergus Finn
- DeepSeek V4 Flash on a Single AMD MI300X | Hacker News
- deepseek-ai/DeepSeek-V4-Flash | vLLM Recipes
- Run DeepSeek V4-Flash Locally: Hardware Requirements 2026 | Modem Guides
- DeepSeek V4 Flash — Hardware Requirements & Compatibility | llmrun
- DeepSeek-V4-Flash on MI300x store_dtype assertion | sglang issue #25118