DeepSeek V4.1 Flash의 552B·16B와 가중치 파일 크기는 어떻게 다를까

DeepSeek V4.1 Flash의 백본 파라미터, 활성 파라미터, 다운로드 가중치 크기는 서로 다른 값입니다. 공식 모델 카드는 백본 552B, prefill 단계 활성 8B, decode 단계 활성 16B와 별도의 196B Engram 조건부 메모리 구성요소를 설명합니다. 어느 하나만으로 전체 GPU 메모리 요구량을 알 수는 없습니다.

이 글은 숫자를 읽고 가중치 파일 목록을 확인하는 방법을 설명합니다. 2026년 9월 14일 공식 저장소와 메타데이터를 확인했습니다. 약 510 GB의 가중치를 내려받거나 로컬 추론을 실행하지 않았습니다. 아래에서는 실제 파일 메타데이터와 가상의 저장량 계산을 구분합니다.

숫자마다 집계 범위 확인하기

공식 DeepSeek 모델 카드는 백본과 활성 파라미터로 아키텍처를 설명합니다. 저장소 카운터나 외부 차트와 비교할 때 이 명칭을 숫자와 함께 유지해야 합니다.

반올림한 아키텍처 숫자를 더해 직렬화된 텐서에 포함된 파라미터의 정확한 총수라고 제시하지 마세요. 반올림과 구성요소 경계가 중요합니다. 저장소의 정밀 카운터와 모델 카드의 대표 숫자가 달라도 반드시 오타는 아닙니다.

활성 파라미터로 다운로드 크기를 구할 수 없는 이유

희소 모델은 토큰마다 계산의 일부를 선택합니다. 해당 경로의 작업을 줄이는 것이지, 나머지 학습된 가중치를 배포 파일에서 없애도 된다는 뜻은 아닙니다. 다른 토큰이나 단계는 다른 구성요소를 사용할 수 있습니다.

추론 시스템은 구성요소를 여러 장치에 배치하거나 오프로딩할 수 있습니다. 메모리 위치, 대역폭과 성능이 바뀌지만 활성 숫자만으로 소비자용 GPU에서 작동하는 구성을 도출할 수는 없습니다. 프레임워크의 배치와 양자화 지원도 확인해야 합니다.

같은 이유로 160억에 가중치당 바이트를 곱해도 저장소 전체 다운로드 추정치가 되지 않습니다. 특정 정밀도의 가상 부분집합 저장량일 뿐입니다. 이를 전체 모델의 VRAM 요구량이라고 부르면 다른 질문에 답하는 셈입니다.

확인한 저장소 파일의 내용

리비전 dba1be0a40aa45a94ad051997016db3960a90277의 공식 저장소 메타데이터는 safetensors 샤드 48개, 총 510,296,708,312바이트를 보고했습니다. 약 510.297 GB(십진)입니다. 이 값은 해당 샤드의 합계이며 모든 부속 파일이나 실측 런타임 메모리가 아닙니다.

Hugging Face 메타데이터의 safetensors.total은 763,205,315,794이며 BF16, F32, F8_E4M3, I8 항목을 포함합니다. 이를 독립적으로 검증한 아키텍처 파라미터 수가 아니라 호스팅 서비스가 보고한 목록 카운터로 취급하세요. 범위가 모델 카드의 백본 552B와 다릅니다. 텐서 형식이 섞여 있다는 점도 단일 대표 파라미터 수에 하나의 바이트 폭을 곱한 값이 파일 합계와 다를 수 있는 이유입니다.

파일이나 리비전이 바뀌면 메타데이터도 바뀔 수 있습니다. 숫자와 함께 리비전을 기록하세요. 하드웨어 제안서에 인용한다면 파일 목록을 첨부하고 십진 GB와 이진 GiB를 구분해 계산을 재현할 수 있게 해야 합니다.

가중치 다운로드 없이 용량 확인하기

다음 명령은 공개 메타데이터만 가져옵니다. Python 코드는 리비전을 출력하고 이름이 .safetensors로 끝나는 파일의 용량을 더합니다. API가 크기를 생략하면 0으로 간주하지 않고 명시적으로 실패합니다.

curl --fail --silent --show-error \
  'https://huggingface.co/api/models/deepseek-ai/DeepSeek-V4.1-Flash?blobs=true' \
  -o model-metadata.json

import json
from pathlib import Path

metadata = json.loads(Path("model-metadata.json").read_text())
shards = [f for f in metadata["siblings"] if f["rfilename"].endswith(".safetensors")]
if not shards or any(type(f.get("size")) is not int or f["size"] < 0 for f in shards):
    raise ValueError("Complete safetensors file sizes are required")
size_bytes = sum(f["size"] for f in shards)
print(metadata["sha"], len(shards), size_bytes, size_bytes / 1_000_000_000)

이 코드는 파일 목록 확인 방법이지 추론 벤치마크가 아닙니다. 시간에 따른 비교 전에 반환 리비전을 기록하거나 고정하세요. 나중의 결과를 과거 스냅샷의 아키텍처 정보나 파일 수와 섞으면 안 됩니다.

런타임 메모리 예산은 별도로 계산하기

지원 가중치 표현, 로드 중 변환, 선택한 문맥의 KV 캐시, 임시 텐서, 프레임워크 할당과 동시 요청을 포함해야 합니다. 로드 시 최고 메모리와 안정적인 생성 중 최고 메모리도 다를 수 있습니다.

GPU 수를 정하기 전에 런타임의 아키텍처 지원과 배포 레시피를 확인하세요. 저장 형식만으로 특정 가속기가 모든 연산을 직접 실행할 수 있다고 결론 낼 수는 없습니다. 오프로딩은 메모리 부담을 호스트 RAM과 대역폭으로 옮길 수 있지만 없애지는 않습니다.

로컬 추론 대신 앱 연결이 목적이라면 DeepSeek V4.1 API 안내를 보세요. API 비용은 저장 파라미터 개당 비용이 아닌 제공업체 청구 규칙을 따릅니다. 510 GB 파일 용량으로 요청당 API 요금을 계산하지 마세요.

파라미터 수는 품질 점수가 아닙니다

숫자만으로 어떤 모델이 작업에 더 적합한지 정할 수 없습니다. 과제 품질, 유효 추론 설정, 문맥 처리와 도구 동작도 필요합니다. 같은 모델이 두 코딩 앱에서 다르게 보인다면 클라이언트 간 진단 안내를 참고하세요.

배포에서 중요한 질문은 검증한 런타임과 전체 작업량이 허용 가능한 성능으로 하드웨어에 들어가는지입니다. 더 작은 희소 모델 사례인 K2 Horizon 안내도 활성 파라미터와 실제 파일을 구분합니다.

자주 묻는 질문

552B는 저장된 모든 텐서에 포함된 파라미터의 정확한 총수인가요?

아닙니다. 공식 표현은 백본 파라미터 수입니다. 저장소 카운터는 추가 구성요소를 포함하고 집계 범위도 다를 수 있습니다.

활성 16B로 전체 VRAM을 계산할 수 있나요?

아닙니다. 활성 계산은 저장된 전체 가중치가 아니며 실행 메모리에는 캐시와 작업용 할당도 포함됩니다.

GPU 메모리가 정확히 510.297 GB면 충분한가요?

확인된 내용이 아닙니다. 특정 리비전의 가중치 파일 48개 크기 합계이며 로드나 추론 메모리 실측 요구량이 아닙니다.