15 PFLOPS라는 숫자, 베이스라인은 뭔가요?
엔비디아가 NVFP4를 공식 발표하면서 내세운 헤드라인은 명확합니다. "블랙웰 울트라 GPU에서 FP8 대비 최대 3배 처리량." elec4와 뉴스프리존 보도에 따르면 블랙웰 울트라는 NVFP4 기준 최대 15 PFLOPS를 제공하고, 동일 GPU의 FP8 대비 3배라는 겁니다. 여기서 제가 가장 먼저 던지는 질문은 이겁니다—이건 이론 피크(theoretical peak) FLOPS인가요, 실측 워크로드 throughput인가요?
4비트 연산이 8비트 대비 단위 시간당 처리할 수 있는 연산 수가 2배라는 건 산술적으로 당연합니다. 비트 폭이 절반이니까요. 그런데 엔비디아는 '최대 3배'라고 합니다. 나머지 1배분의 성능 향상이 어디서 오는지—텐서 코어 마이크로아키텍처 개선인지, 메모리 대역폭 절감 효과인지, 아니면 배치 사이즈 확대에 따른 GPU utilization 향상인지—이 부분의 ablation이 공개 자료에서는 보이지 않습니다.
MLPerf 결과는 있지만, 조건을 읽어야 합니다
실측 근거가 아예 없는 건 아닙니다. MLPerf Training 벤치마크에서 512개 블랙웰 울트라 GPU(GB300 NVL72 구성)로 Llama 3.1 405B 사전훈련을 64.6분에 완료했고, 이것이 FP8 기반 블랙웰 시스템 대비 1.9배 빠르다고 보고했습니다. 여기서 주목해야 할 지점이 두 가지입니다.
첫째, 헤드라인의 '3배'와 실측의 '1.9배' 사이에 갭이 1.1배나 존재합니다. 이론 피크와 실측 throughput 사이의 괴리는 GPU 벤치마크에서 항상 발생하지만, 마케팅 숫자와 MLPerf 숫자를 같은 맥락으로 소비하면 안 됩니다. 둘째, 비교 대상인 'FP8 기반 블랙웰 GPU 시스템'이 블랙웰 울트라인지, 일반 블랙웰인지에 따라 해석이 완전히 달라집니다. 만약 NVFP4 + 블랙웰 울트라 vs FP8 + 블랙웰(비울트라)이라면, 이건 정밀도 포맷의 차이가 아니라 하드웨어 세대 차이까지 포함된 비교입니다.
추론 영역에서 DeepSeek-R1(671B MoE)의 토큰 처리량 향상도 언급되지만, 구체적인 tokens/sec 수치나 latency 분포는 '엔비디아 기술 블로그 참조'로 넘깁니다. 정확도는 MLPerf 비공개 부문 기준을 통과했다고 하는데, 비공개 부문(closed division)의 정확도 threshold 자체가 어떤 수준인지, MMLU나 HumanEval 같은 downstream 태스크에서의 품질 열화(quality degradation)가 어느 정도인지를 별도로 검증해야 합니다.
블랙 포레스트 랩스의 6.3배, 이건 뭘 쌓은 건가요?
생태계 사례 중 가장 눈에 띄는 건 블랙 포레스트 랩스의 FLUX.2 이미지 생성 모델에서 단일 B200 GPU 기준 최대 6.3배 속도 향상이라는 수치입니다. 그런데 CEO 로빈 롬바흐의 발언을 정확히 읽으면, 이 6.3배는 NVFP4 단독 효과가 아닙니다. CUDA Graphs + torch.compile + NVFP4 + TeaCache를 계층적으로 적용한 누적 효과입니다. 각 기법의 개별 기여도(ablation)가 없으면, NVFP4 자체의 순수 효과가 2배인지 4배인지 알 수 없습니다. 이건 correlation이지 causation이 아닙니다.
성능 숫자보다 중요한 건 '분포 설계'입니다
흥미롭게도, 이번 주 Velog에 올라온 IT-DA의 Match Score 변별력 개선기가 정확히 같은 문제를 다른 각도에서 보여줍니다. LightGBM 기반 추천 시스템에서 추천 점수가 49~54% 사이에 밀집되어 사용자가 1등과 5등을 구분할 수 없었던 사례입니다.
근본 원인은 모델 성능이 아니라 Feature 분포에 있었습니다. distance_weight가 0.87~0.93, vibe_similarity가 0.55~0.62—입력 피처 자체의 분산이 극도로 작아서 어떤 가중치를 줘도 출력 스코어의 표준편차가 8.3에 불과했습니다. 연속 거리 함수를 이산 구간(bucket)으로 변환하고, Min-Max 정규화를 percentile 기반 정규화로 교체한 후 표준편차가 18.7로 2.3배 증가했습니다.
데이터 분석가로서 이 사례가 강력한 이유는, 모델의 NDCG나 RMSE를 아무리 올려도 최종 스코어 분포가 밀집되면 사용자 체감 품질은 개선되지 않는다는 점을 실증적으로 보여주기 때문입니다. 다만 한 가지 짚고 싶은 건, percentile 정규화 + dynamic ceiling이라는 후처리가 모델의 원래 ranking order를 보존하는지 여부입니다. 후보가 1개일 때 상한을 73%로 제한하는 건 UX적으로는 합리적이지만, 이런 수동 규칙이 많아지면 결국 모델 출력과 사용자 노출 점수 사이의 monotonicity가 깨질 리스크가 있습니다.
Text-to-SQL 파이프라인: 데이터 품질의 '이중 안전장치'
세 번째 소스인 Text-to-SQL 파이프라인 설계 문서는, 운영 SQL 로그에서 중복을 제거하고 신규 템플릿에만 LLM 메타데이터를 생성하는 구조를 다룹니다. 여기서 데이터 품질 관점의 핵심 설계는 2단계 Dedup입니다. 일일 증분 내에서 MinHash(n-gram shingle=3, num_perm=256) 기반 1차 제거 후, Milvus LSH로 전체 히스토리 대비 후보 검색 + SequenceMatcher로 절 단위 정밀 비교하는 2차 제거.
이 설계에서 제가 묻고 싶은 건, MinHash의 Jaccard 유사도 threshold를 얼마로 설정했느냐입니다. threshold가 0.8이냐 0.9이냐에 따라 '유사하지만 비즈니스 의미가 다른 SQL'이 제거될 수도 있고, 중복이 통과할 수도 있습니다. 또한 LLM이 생성한 table_rel_info가 '추정 관계'일 수 있다는 문서 자체의 경고는 매우 적절합니다—이건 LLM hallucination이 메타데이터 품질을 오염시키는 전형적인 경로이고, 스키마 기반 검증 게이트(Quality Gate)가 없으면 downstream의 Text-to-SQL 정확도가 직접 타격을 받습니다.
시사점: 숫자를 읽는 프레임워크
세 사례를 관통하는 교훈은 하나입니다. AI 성능 주장을 소비할 때 '조건부 분포'를 읽어야 한다는 것. NVFP4의 3배는 이론 피크 조건에서, 1.9배는 MLPerf 특정 구성에서, 6.3배는 4가지 최적화 기법의 누적 효과에서 나온 숫자입니다. Match Score의 변별력 문제는 모델 성능이 아니라 피처 분포 조건에서 발생했고, Text-to-SQL의 메타데이터 품질은 Dedup threshold 조건에 의존합니다.
실제 운영 환경에서 이 성능이 나올까요? 그 답은 항상 같습니다—벤치마크 조건과 프로덕션 조건의 거리를 측정하세요. 배치 사이즈, 시퀀스 길이, 동시 요청 수, 메모리 제약, 그리고 정확도 열화 허용 범위. 이 변수들을 고정하지 않은 성능 숫자는 p-value 없는 가설 검정과 같습니다.