2026년 7월 31일에 공개된 DeepSeek-V4-Flash-0731 (Hugging Face 공식 모델 카드)를 AMD Instinct MI300X '1장'으로 본番 운영하기 위한 구성과 패치를 정리한 실증 리포지토리 deepseek-v4-flash-mi300x (GitHub)가 HackerNews에서 화제가 되었다.

이 리포지토리는 단순한 '구동해 보았다' 수준이 아니다. 프론티어 클래스(Frontier class)에 손이 닿는 MoE 모델이, 80GB의 H100에는 올라가지 않지만 192GB의 MI300X라면 양자화(Quantization) 없이 1장에 담길 수 있다는, 온프레미스(On-premise) 추론의 전제가 바뀌었음을 보여주고 있다. 동시에, NVIDIA를 전제로 작성된 추론 스택을 AMD로 이식하면 벤치마크는 통과하지만 실제 운영 시 툴 호출이 이상해지는 등, 사이런트(Silent)한 품질 저하가 발생할 수 있다는 점도 생생하게 기록하고 있다.

본 기사에서는 이 사례를 일본 인프라 담당자의 시점에서 세 가지로 재구성한다. 첫째, 304B라는 숫자의 오독, 둘째, '저렴함의 정체는 비용이 아니라 데이터 주권'이라는 운영 판단, 셋째, FP8 포맷과 MoE 라우팅(Routing)이라는 이식의 함정이다.

일본 기업이 LLM을 본番 투입할 때, 많은 현장이 두 가지 선택지에서 멈춰 있다. 해외 프론티어 API에 의존할 것인가, 아니면 사내에 둘 수 있는 소형 모델로 타협할 것인가이다. 전자는 빠르고 똑똑하지만, 프롬프트와 생성물 모두 국외 데이터 센터를 통한다. 금융, 의료, 지자체, 방위 관련 분야처럼 애초에 데이터를 외부로 내보낼 수 없는 영역에서는 선택지에 들어가지 못하는 경우가 많다. 후자는 안전하지만 능력이 한 단계 떨어진다.

이 두 선택지 사이를 메우는 제3의 길은, 프론티어급 모델을 자사의 GPU 서버 1대로 구동한다는 선택지이다. 지금까지 이것은 '수백 B 규모의 모델이 GPU 1장에 올라갈 리가 없다'는 상식으로 치부되어 왔다. DeepSeek V4 Flash의 등장과 이를 MI300X 1기로 구동한 이번 실증은, 그 상식이 무너지고 있음을 구체적인 숫자로 보여주고 있다.

지난 기사에서는 초저가 AI API의 정체가 토큰 전매 릴레이이며, 익명의 종량제 액세스를 사내에 만들지 않는 것이 방어가 된다고 논했다. 이번에는 그 반대로, 외부로 내보낼 수 없는 데이터를 다루는 조직이 자체적인 추론 기반을 어떻게 평가해야 하는지에 대한 이야기이다.

먼저 숫자를 정확히 해두고 싶다. 많은 소개 기사가 '304B(3040억 파라미터) 모델을 1장으로 구동했다'고 쓰지만, 이는 절반은 맞고 절반은 오도(Mislead)하는 것이다.

Simon Willison의 해설이나 공식 정보를 대조해 보면, DeepSeek V4 Flash의 실체는 다음과 같다.

• 베이스는 총 파라미터 약 284B의 MoE (Mixture of Experts) 모델
• 1 토큰당 실제로 작동하는 활성 파라미터(Active Parameters)는 약 13B
• Hugging Face가 표시하는 304B는 투기적 디코딩(Speculative Decoding)용 드래프트 모듈(DSpark)을 포함한 숫자
• 컨텍스트 길이(Context Length)는 최대 1M, 라이선스는 MIT

여기서 핵심이 되는 것이 활성 파라미터 13B라는 값이다. MoE는 모든 전문가(Expert)를 매번 구동하는 것이 아니라, 라우터(Router)가 선택한 일부만을 사용한다. 즉, 속도와 전력을 결정하는 것은 총 파라미터가 아니라 활성 파라미터이다. 총 파라미터는 메모리 용량의 문제, 활성 파라미터는 계산 속도의 문제라는 별개의 제약으로 나누어 생각해야 한다.

흔한 오해: "304B니까 GPU 1장으로는 무리, 하물며 가속화는 꿈"
실제 구조: 메모리 제약 … 총 284B (+드래프트)를 수용할 수 있는 HBM 용량이 필요
속도 제약 … 실제로 계산하는 것은 활성 13B이므로 단발 연산은 빠름

이 분리를 이해하지 못하면 온프레미스 도입 여부 판단을 근본적으로 그르치게 된다. '총 파라미터가 크다 = 무겁다 = 불가능하다'라는 직관은 MoE 시대에는 통용되지 않는다.

여기서 하드웨어 이야기로 넘어간다. AMD Instinct MI300X의 공식 페이지가 공표하는 스펙의 핵심은 192GB의 HBM3 메모리와 약 5.3TB/s의 대역폭이다. 비교 대상인 NVIDIA H100 SXM은 80GB이므로, 용량에서 2.4배의 차이가 난다.

실증 리포지토리의 메모리 내역을 보면, 이 용량 차이가 결정적으로 작용하고 있음을 알 수 있다.

MI300X 1기 (HBM 약 192GB / 실효 205.8GB 상당)에서의 배분 예시
──────────────────────────────────────────────
모델 가중치 (HBM 상주) 156.67 GB ← 양자화 없이 통째로 탑재 가능
...

중요한 점은 모델 가중치를 PCIe를 통해 스트리밍하거나 레이어를 오프로드(offload)하지 않고, 통째로 HBM에 상주시키고 있다는 점이다. 80GB GPU라면 가중치만으로도 다 담지 못해 레이어를 넘길 때마다 외부 메모리와 왕복하며 속도가 저하된다. 192GB라는 용량이 이러한 왕복 과정을 제거해 버린다.

성능 면에서는 단일 디코딩(decoding) 시 중앙값 168토큰/초, 8개 스트림 동시 실행 시 합계 542토큰/초, 64개 스트림 버스트(burst) 시 최대 830토큰/초까지 나오고 있다. 프리필(prefill)은 튜닝된 커널을 통해 초당 7.9~8.5K 토큰이며, 검증된 컨텍스트(context) 길이는 256K이다.

즉, 프론티어급 모델을 온프레미스(on-premise)에서 구동할 수 있는지 여부는 앞으로 GPU의 '연산 성능'이 아니라 '메모리 용량'에 의해 결정되는 상황이 늘어날 것이다. 그리고 메모리 용량이라는 전장에서는 NVIDIA가 유일한 선택지가 아니다. 이는 일본의 인프라 조달 측면에서 놓쳐서는 안 될 변화다.

이 부분이 본 기사에서 가장 전달하고 싶은 내용이다. 동일한 FP8이라도 NVIDIA와 AMD는 비트(bit)의 의미가 다르다.

vLLM 등의 추론 스택(inference stack)은 오랫동안 NVIDIA를 전제로 작성되어 왔다. 여기에 MI300X를 도입하면 수치 포맷의 미묘한 차이가 독이 되어 돌아온다. vLLM의 FP8 문서와 ROCm 상의 FP8 양자화 튜토리얼(AMD 공식)을 대조해 보면 다음과 같은 사실이 드러난다.

• MI300X(gfx942)가 사용하는 FP8은 AMD 고유의 float8_e4m3fnuz이며, 표현 범위는 약 ±224이다. 일반적인 OCP 표준 FP8은 float8_e4m3fn이며, 표현 범위는 약 ±240이다. 이름은 같은 "E4M3"이지만, 지수 바이어스(exponent bias)나 무한대·NaN 처리 방식(FNUZ = Finite, NaN-only, Unsigned zero)이 다르다.

동일한 8비트라고 생각하여 스케일 상수(scale constant)를 그대로 사용하면, 최악의 경우 2배의 스케일 오차가 발생한다. 이는 '작동하지 않는 것'이 아니라 '작동은 하는데 답이 틀리는 것'이기 때문에 발견하기가 매우 어렵다.

# 개념 코드. 동일한 "FP8 E4M3"라도 플랫폼마다 의미가 다름
# NVIDIA (OCP) : torch.float8_e4m3fn ≈ ±240
# AMD MI300X (gfx) : torch.float8_e4m3fnuz ≈ ±224
...

이는 탁상공론이 아니다. 실제로 vLLM에는 MI300X에서 FP8 KV 캐시의 정밀도가 이상해지는 결함(Issue #45562)이 보고되어 있으며, 이는 FP8을 vLLM에 도입하는 초기 설계 논의(Discussion #2461)부터 이어져 온 뿌리 깊은 테마다. 이번 리포지토리(repository) 역시 fused_compress_quant_cache의 FNUZ 변환을 보정하는 패치를 MI300X용으로 적용했다.

또 다른 함정은 MoE의 라우팅(routing)이다. 리포지토리 기록에 따르면, MXFP4 전문가(expert)를 다루는 bitmatrix 커널의 패딩(padding)이 잘못된 텐서 경계에서 마스킹되어, 긴 프롬프트에서 "유사한 도구 이름의 혼동"이나 "스키마(schema) 망각"이 발생하고 있었다. 이를 한 줄의 마스크 수정으로 해결했다.

이 부분이 실무상 가장 무서운 지점이다. 문법 오류나 크래시(crash)라면 알아챌 수 있지만, 이러한 종류의 성능 저하는 다음과 같이 나타난다.

증상 양상
짧은 프롬프트 … 겉보기에는 정상이며 벤치마크도 통과함
긴 프롬프트 + 도구(tool) … 유사한 이름의 도구를 혼동함 / 스키마를 일부 망각함
...

"모델이 똑똑해졌을 텐데 에이전트(agent)의 정밀도가 떨어졌다"라고 느낄 때, 범인은 프롬프트도 모델도 아닌 양자화 포맷과 커널의 이식 문제였다는 상황이 현실에서 발생한다. 온프레미스 추론을 평가하는 담당자는 도구 호출과 긴 문장 스키마를 포함하는 회귀 테스트(regression test)를 반드시 갖추어야 한다.

여기서 냉정하게 비용을 살펴보고 싶다. HackerNews의 토론에서는 솔직한 경제 분석이 오가고 있다.

• MI300X는 단품으로 판매되지 않으며, 8개가 들어있는 박스(약 25만 유로) 단위로 조달해야 한다.
• 클라우드라면 시간당 약 1.99달러에 빌릴 수 있다.
• 하지만 DeepSeek 공식 API는 입력 100만 토큰당 0.14달러, 출력 0.27달러로 극단적으로 저렴하다.
• 830토큰/초로 1시간 동안 돌리면 생성량은 약 300만 토큰이며, API 환산 시 약 0.5달러 전후다.

즉, 순수한 비용 싸움에서는 자사에서 GPU를 돌리는 것보다 공식 API를 호출하는 것이 더 저렴한 경우가 많다. 이 점을 오해하여 "온프레미스가 저렴하다"라고 품의를 올렸다가는 나중에 큰 낭패를 볼 수 있다.

자사 운영이 정당화되는 것은 비용 때문이 아니라, 데이터를 외부로 내보낼 수 없는 사정 때문이다. HN(Hacker News) 참가자들도 셀프 호스팅(Self-hosting)이 의미를 갖는 것은 프라이버시, 지적 재산 보호, 규제 산업이라는 세 가지 측면이라고 정리했다. 이를 일본의 맥락에 대입하면 다음과 같다.

• 금융·의료·지자체에서 요배려 개인정보나 민감 정보를 프롬프트에 포함할 수밖에 없는 경우
• 설계 데이터나 소스 코드 등 경쟁력의 원천을 추론할 때마다 국외로 보내고 싶지 않은 경우
• 디지털청의 거버넌스 클라우드(Government Cloud)나 경제 안보의 맥락에서 데이터 관할권(어느 나라의 법률이 적용되는가)이 문제되는 경우

IPA의 '정보 보안 10대 위협 2026'이 보여주듯, 공급망 공격이나 정보 유출은 조직에 있어 계속해서 상위 위협으로 남아 있다. 추론 기반을 자사로 끌어들인다는 판단은 이러한 데이터 주권(Data Sovereignty)의 요구에 부응하기 위한 것이라고 보는 것이 타당하다. 저렴함은 부차적인 이점에 불과하다.

판단의 프레임은 다음과 같이 단순화할 수 있다.

온프레미스 추론 선택 판단 플로우
──────────────────────────────
프롬프트/생성물을 국외 API로 보낼 수 있는가?
...

공급 측면에서도 선택지가 넓어지고 있다. HN에서는 향후 등장할 PCIe 버전의 MI350P(144GB)에서도 MXFP4 네이티브 양자화(Native Quantization) 덕분에 V4 Flash를 올릴 수 있다는 지적이 있었다. 8개들이 노드(Box)를 구매할 수 없는 중소 규모의 현장에서도, 1~2장을 장착한 서버로 프론티어급 모델을 구동할 수 있는 시대가 머지않았다.

DeepSeek V4 Flash를 MI300X 1기로 구동한 이번 실증은 세 가지 실무적인 교훈을 남겼다.

첫째, MoE(Mixture of Experts)의 평가는 총 파라미터(Total Parameters)가 아니라, 메모리는 총 파라미터로, 속도는 활성 파라미터(Active Parameters)로 나누어 산정할 것. 304B라는 헤드라인 숫자에 현혹되지 마라.

둘째, 온프레미스 추론의 여부는 저렴함이 아니라 데이터 주권으로 결정할 것. 외부로 보낼 수 있는 데이터라면 공식 API를 사용하는 것이 더 저렴하다. 자사에서 돌리는 이유는 금융·의료·지자체처럼 애초에 외부로 내보낼 수 없는 데이터를 다루기 때문이다.

셋째, NVIDIA 전제의 추론 스택을 AMD로 옮길 때는 FP8의 FNUZ와 OCP의 차이, MoE 라우팅(Routing)의 커널 버그라는 두 가지 함정을 의심할 것. 크래시(Crash)가 발생하지 않는 '사일런트한 품질 저하(Silent Quality Degradation)'야말로 가장 위험하며, 툴 호출(Tool Calling)과 긴 문장 스키마(Long Schema)를 포함한 회귀 테스트(Regression Test)가 이를 잡아낼 수 있는 유일한 그물이다.

구체적인 첫걸음으로서 다음을 권장한다.

① 자사가 다루는 데이터 중 국외 API로 보낼 수 없는 것을 목록화한다.

② 보낼 수 없는 데이터가 있다면, MI300X나 MI350P를 클라우드에서 1~2시간 대여하여 자사의 대표적인 프롬프트와 툴 세트로 회귀 테스트를 실행하고, 정확도와 처리량(Throughput)을 실측한다.

이 한 번의 수고가 프론티어 모델 의존과 온프레미스 자립 사이에서, 자사에게 맞는 올바른 선을 그어줄 것이다.

• DeepSeek-V4-Flash-0731 공식 모델 카드 (Hugging Face) ― 총 파라미터·투기적 디코딩(Speculative Decoding) 모듈·MIT 라이선스·FP8(E4M3)·벤치마크의 1차 정보
• deepseek-v4-flash-mi300x (GitHub 실증 리포지토리) ― MI300X 1기 기반의 실제 구성·메모리 내역·vLLM 실행 플래그·FNUZ/MoE 보정 패치의 1차 기록
• HackerNews 토론 스레드 (id=49166386) ― 공급 형태(8기 노드/클라우드 $1.99h)·처리량과 채산성·MI350P 등 대안에 관한 논의
• Simon Willison의 해설 ― 총/활성 파라미터·가격($0.14/$0.27 per M)·비용 대비 성능의 위치 선정
• AMD Instinct MI300X 공식 페이지 ― 192GB HBM3·약 5.3TB/s 대역폭·CDNA3의 1차 스펙
• vLLM FP8 양자화 문서 ― FP8(W8A8/E4M3)의 1차 사양
• ROCm 기반 FP8 양자화 튜토리얼 (AMD 공식) ― AMD Quark/vLLM에서의 FP8 양자화 1차 절차
• vLLM Issue #45562 (MI300X의 FP8 KV 캐시 정밀도 결함) ― FNUZ 변형의 취급이 정밀도에 영향을 미치는 실제 버그
• vLLM Discussion #2461 (RFC: FP8 in vLLM) ― FP8 대응 설계 경위
• 디지털청 거버넌스 클라우드 ― 국내 데이터 주권·클라우드 조달 맥락
• IPA 정보 보안 10대 위협 2026 ― 국내 위협 동향
• DeepSeek V4 Flash 0731 (Ollama 라이브러리) ― 모델 공개 상황의 근거