로컬 AI 가이드

사기 전에 속도와 비용부터

모델별 실행 레시피

최종 업데이트

DeepSeek-V4-Flash 서빙 가이드: 304B 분산 레시피

DeepSeek-V4-Flash를 4×GB300 서버에서 서빙해요

DeepSeek-V4-Flash-0731은 질문과 코드를 입력받아 텍스트 답변과 코드를 생성하는 전문가 혼합1형 모델이에요. 공식 vLLM 예시는 전체 304B 체크포인트2를 GB300 4개로 구성한 단일 노드에서 전문가 병렬로 실행해요. 팀의 코드 검토 서버를 열고 질문을 보내는 순서예요.

이 레시피는 팀 저장소의 변경된 함수와 호출부, 관련 테스트를 보내 영향과 확인할 파일을 묻는 내부 도구를 기준으로 설명해요. 먼저 공식 서버 환경과 체크포인트를 준비하고, 16K 문맥으로 한 요청을 확인한 뒤 로컬 API3의 스트리밍과 실제 테스트 답변을 살펴봐요.

목차
실행 조건과 핵심 내용
  • 13B 활성은 토큰당 계산 경로이고, 공식 체크포인트 전체는 304B예요.
  • 공식 vLLM 명령은 4×GB300 노드, 전문가 병렬, DSpark 구성을 함께 사용해요.
  • 127.0.0.1 로컬 바인딩과 16K 시작 문맥으로 먼저 한 요청을 점검해요.
장비별 실행 설정으로 이동

13B 활성과 304B 전체가 가리키는 일을 나눠요

DeepSeek-V4-Flash-0731은 전문가 혼합형 모델이라 토큰4마다 선택된 전문가 경로가 계산에 참여해요. 약 13B 활성은 토큰당 계산에 쓰이는 규모이고, 공식 체크포인트 전체는 약 304B예요. 실행 환경은 질문에 따라 선택될 수 있는 전체 가중치에 접근할 수 있어야 하므로, 서버 적재 조건은 13B만으로 계산하지 않아요.

공식 vLLM 예시는 단일 4×GB300 노드와 전문가 병렬을 사용해요. GPU5 네 장이라는 숫자만 맞춰 다른 카드로 바꾸면 같은 실행 환경이 되지 않아요. 장치별 메모리와 연결, 필요한 커널, 런타임6 지원까지 해당 예시와 맞는지 확인해야 해요.

작은 블록과 서류가 깔때기를 거쳐 큰 격자 블록으로 이어지고, 아래에 노트북 네 대가 연결된 그림
토큰마다 쓰는 약 13B 경로와 준비해야 할 전체 304B 체크포인트를 구분해요.

공식 서버 환경을 준비하고 16K 문맥으로 시작해요

명령은 데이터 병렬 크기 4, 전문가 병렬, DSpark 추측 디코딩7을 함께 설정해요. 데이터 병렬은 요청 처리 그룹을 만들고, 전문가 병렬은 전문가 가중치의 계산 경로를 나눠요.

이 조합은 가중치 전체를 네 번 복제하는 설정이 아니에요. 아래 옵션은 이 모델과 지원되는 서버 소프트웨어에 맞춘 예시이므로, 다른 엔진에서는 해당 엔진의 지원 설정을 사용하세요.

문맥 길이는 16K부터 확인해요. 짧은 연결 요청이 성공한 다음 업무 입력을 넣어야, 서버 적재 문제와 긴 입력의 처리 문제를 구분할 수 있어요. 모델 저장소 코드를 실행하도록 허용하는 옵션이 있으므로, 시작하기 전에 저장소와 사용할 버전을 검토하고 조직에서 승인한 코드 경로인지 확인해요.

vLLM 공식 분산 서빙 (Multi-GPU 서버 노드)
vllm serve deepseek-ai/DeepSeek-V4-Flash-0731   --host 127.0.0.1   --port 8000   --trust-remote-code   --data-parallel-size 4   --enable-expert-parallel   --kv-cache-dtype fp8   --block-size 256   --moe-backend deep_gemm_mega_moe   --attention-config '{"use_fp4_indexer_cache": true}'   --speculative-config '{"method":"dspark","num_speculative_tokens":7,"draft_sample_method":"greedy"}'   --max-model-len 16384   --gpu-memory-utilization 0.90
공식 4×GB300 vLLM·DSpark 예시를 16K 문맥과 127.0.0.1 로컬 바인딩으로 실행해요.

로컬 API 연결과 실제 코드 질문을 순서대로 확인해요

서버가 준비되면 짧은 스트리밍 요청부터 보내요. 응답 조각이 도착하고 요청이 정상 종료되는지 확인하세요. 아래 테스트는 127.0.0.1:8000의 챗 완성 API에 최대 512개 토큰을 요청해요.

연결이 되면 변경한 함수와 호출부, 관련 테스트를 입력해 영향 범위와 확인할 파일을 물어봐요. 답변에 실제 테스트 파일이 포함되는지도 살펴봐요.

첫 토큰이 도착한 시각과 답변이 끝난 시각을 기록하고, 실제 출력 토큰 수와 함께 봐요. 같은 요청을 세 번 반복할 때는 준비 실행을 먼저 하고, 첫 입력과 캐시를 재사용한 입력을 구분해요. 요청이 끝났는데 답변이 빠졌다면 변경 함수와 테스트가 입력에 포함됐는지, 모델이 적은 경로와 파일 내용이 실제로 맞는지 확인해요.

DSpark 실행에서는 제안된 후보 수보다 본 모델의 검증을 통과해 실제 출력에 포함된 토큰 수와 완료 시간을 비교해요. 팀 요청을 겹쳐 보내는 시험은 한 건씩 보낸 기록과 따로 남겨야 해요. 여러 요청을 동시에 처리해 전체 처리량8이 늘어도 각 사용자의 첫 응답이나 완료 대기는 길어질 수 있어요.

로컬 챗 완성 스트리밍 테스트
curl -N http://127.0.0.1:8000/v1/chat/completions   -H "Content-Type: application/json"   -d '{
    "model": "deepseek-ai/DeepSeek-V4-Flash-0731",
    "messages": [
      {"role": "user", "content": "DeepSeek-V4-Flash 분산 서빙 테스트."}
    ],
    "max_tokens": 512,
    "stream": true
  }'
127.0.0.1:8000 API에서 스트리밍 응답 조각이 오는지 확인해요.
색 표시가 된 긴 종이가 서버 칸으로 이어지고, 출력 블록 줄을 돋보기로 살펴보는 그림
스트리밍 조각과 실제 출력 토큰 수, 응답 완료 시각을 함께 기록해요.

실패 단계에 따라 처음 확인할 곳을 바꿔요

짧은 요청도 시작하지 않으면 서버 로그에서 체크포인트 적재, 분산 설정, 커널 호환성 오류를 확인해요. 짧은 질문은 되지만 긴 입력에서만 실패하면 요청에 포함된 토큰 수와 피크 메모리, 입력 길이를 나란히 기록해요. 16K 문맥으로 되돌아간 뒤 입력을 조금씩 늘리면 어느 지점부터 막히는지 알 수 있어요.

메모리는 전체 합계만 보지 말고 장치별 사용량과 오류가 난 노드를 같은 시점에 살펴요. 다른 프로세스가 가속기를 사용했는지도 기록하면 적재 부족과 실행 중 부하를 구분하는 데 도움이 돼요. 전문가 병렬 분할이 한 장치에 치우치거나 KV 캐시9가 특정 노드에서 먼저 한계에 닿을 수도 있어요.

요청은 끝났는데 테스트 위치를 잘못 짚었다면 GPU 구성을 먼저 바꾸지 말고 입력한 파일 범위와 답변 근거를 확인해요. 반대로 적재 단계에서 멈춘다면 마지막 정상 체크포인트와 분산 설정으로 돌아가요. 한 번에 한 조건만 바꾸고 같은 기준 질문을 다시 보내면 원인을 좁히기 쉬워요.

NVFP4 경로는 검증된 가속기와 커널을 따로 확인해요

공식 검증 기준은 B200이에요. RTX와 Spark에서는 별도 호환 커널이 필요하고, DSpark 헤드는 별도 정밀도를 유지해요. 이 조건을 공식 실행 명령과 섞지 말고 NVFP410 실행을 선택할 때 사용할 런타임과 커널 조합에서 지원되는지 확인해요.

직접 운영에 필요한 문제와 책임이 있는지 판단해요

도입 이유는 모델이 크다는 점보다 현재 도구가 실제로 놓치는 업무 조건에서 찾아요. 작은 모델이 변경 영향을 반복해서 놓치는지, 팀의 동시 요청이 대기열을 만드는지 같은 기준 질문으로 기록해요. 작은 후보가 한 사람의 작업에 충분하다면 4×GB300 서버를 마련할 필요는 없어요.

서버를 운영하기로 했다면 체크포인트와 런타임 버전, GPU별 사용량, 요청별 첫 응답과 완료 시각, 오류 뒤 되돌릴 설정을 함께 기록해요. 기능 확인을 통과한 뒤 같은 유형의 질문을 동시에 보내 처리량과 개인별 대기를 따로 측정하면, 필요한 장비 규모와 관리 부담을 실제 운영 요구에 맞출 수 있어요.

여러 색 블록이 수납장으로 들어가고 반대편의 선들이 사람이 든 노란 다면체로 모이는 그림
서버를 직접 운영할 필요는 반복되는 업무 문제와 팀의 관리 책임으로 판단해요.

용어 각주

  1. MoE — 여러 전문가 하위망 중 일부를 입력에 따라 선택해 사용하는 모델 구조입니다. 총 파라미터 수와 한 토큰 처리에 활성화되는 파라미터 수는 다를 수 있습니다.

    본문으로 돌아가기

  2. 체크포인트 — 학습된 모델의 가중치 등을 저장한 파일입니다. 같은 모델 계열도 버전이나 용도에 따라 다른 체크포인트를 쓸 수 있습니다.

    본문으로 돌아가기

  3. API — 프로그램의 기능을 다른 코드에서 호출하기 위한 약속된 인터페이스입니다.

    본문으로 돌아가기

  4. 토큰 — 모델이 입력이나 출력을 나누어 처리하는 단위입니다.

    본문으로 돌아가기

  5. GPU — 많은 계산을 병렬로 처리하는 프로세서입니다. AI 모델 실행에서는 모델 계산을 맡습니다.

    본문으로 돌아가기

  6. 런타임 — 프로그램이 실행될 때 필요한 기능을 제공하는 소프트웨어 환경입니다. 로컬 AI에서는 모델을 실행하는 엔진을 가리키기도 합니다.

    본문으로 돌아가기

  7. 추측 디코딩 — 초안 모델·MTP 헤드·반복 문맥 조회가 출력 후보를 먼저 만들고, 본 모델이 후보를 검증해 확정하는 생성 기법입니다.

    본문으로 돌아가기

  8. 처리량 — 일정 시간 동안 처리하거나 생성한 작업량입니다. 토큰/초, 요청/초처럼 단위를 함께 확인해야 비교할 수 있습니다.

    본문으로 돌아가기

  9. KV 캐시 — 어텐션에서 이전 토큰의 키·값을 저장해 다음 토큰 생성 때 재사용하는 메모리입니다. 문맥 길이와 배치 크기에 따라 용량이 달라집니다.

    본문으로 돌아가기

  10. NVFP4 — NVIDIA가 정의한 4비트 부동소수점 데이터 형식입니다. 지원 여부는 GPU 세대, 모델과 소프트웨어 구현에 따라 다릅니다.

    본문으로 돌아가기

자주 묻는 질문

이 글에서 가장 먼저 확인할 것은 무엇인가요?
DeepSeek-V4-Flash-0731은 질문과 코드를 입력받아 텍스트 답변과 코드를 생성하는 전문가 혼합형 모델이에요. 공식 vLLM 예시는 전체 304B 체크포인트를 GB300 4개로 구성한 단일 노드에서 전문가 병렬로 실행해요. 팀의 코드 검토 서버를 열고 질문을 보내는 순서예요.
필요한 메모리는 어느 정도인가요?
공식 vLLM 예시는 단일 4×GB300 노드와 전문가 병렬을 사용해요. GPU 네 장이라는 숫자만 맞춰 다른 카드로 바꾸면 같은 실행 환경이 되지 않아요. 장치별 메모리와 연결, 필요한 커널, 런타임 지원까지 해당 예시와 맞는지 확인해야 해요.

실행 레시피

장비별 설정

한 사람이 사용할 때

사용할 장비를 고르면 실행 명령과 조정할 옵션이 나옵니다.

가용 메모리: 236GB / 대역폭: 1200GB/s

Apple Mac Studio M5 Ultra (256GB)

실험적 구동

권장 런타임: 압축 런타임 검증 필요 (Q4 압축 가중치 (아티팩트·런타임 검증 필요)) · 실험적 경로 (검증 필요)

선택 프로필 문맥

4,096 토큰

계산기 예상 디코드

112.5 ~ 125 tok/s

단일 사용자 예상치

계산기 예상 TTFT

10.8 ~ 18.8초

프리필: 218 ~ 378 tok/s

예상 메모리 점유

약 180.53GB / 236GB

남은 여유: 약 55.5GB

서버 주소

http://127.0.0.1:1234

로컬 전용 127.0.0.1

예상치는 계산기의 추천 양자화·가속과 4,096토큰 기준입니다. 위 실행 설정의 실측값은 아닙니다.

이 프로필의 실제 설정

적용값왜 이렇게 잡았나
양자화·아티팩트Q4 압축 가중치 (아티팩트·런타임 검증 필요)·$MODEL_PATH단일 사용자 디코드에서 가중치 이동량과 적재 메모리를 먼저 줄이는 시작값
시작 문맥 길이4,096토큰네이티브 1024K를 바로 할당하지 않고 가중치·KV 캐시·런타임 여유를 남기는 값
바인딩 주소127.0.0.1:1234인증 없는 로컬 서버가 외부 네트워크에 노출되지 않도록 루프백에만 바인딩
GPU 오프로드·분할단일 통합 메모리 전체 적재 검증가중치를 고속 메모리에 상주시켜 CPU-RAM 오프로딩 병목을 피함
Flash Attention선택 런타임에서 모델 호환성 확인 후 활성화프리필과 긴 문맥에서 어텐션 메모리 사용량을 줄이는 설정
KV 캐시기본 정밀도로 적재 후 q8_0 별도 검증메모리 사용량을 줄이되 런타임에서 지원하는 정밀도만 사용
프리필 배치·마이크로 배치런타임 설정에서 확인llama.cpp의 batch-size와 ubatch-size를 MLX 설정값으로 대신 쓰지 않습니다.
동시 요청 수1개서버 총 처리량보다 1인 사용의 첫 토큰과 디코드 지연시간을 우선

메모리 상 적재 가능성과 실제 서빙 지원은 다른 문제입니다. 압축 아티팩트와 런타임 호환성을 확인하기 전에는 복사할 실행 명령을 표시하지 않습니다.

운용 시 유의사항

  • 공식 vLLM 예시는 4×GB300 노드의 DP=4·EP 구성입니다. 현재 카탈로그 장비를 동일한 경로로 보지 않습니다.
추천 설정으로 속도 보기 Studio M5 Ultra 256GB 가격·전력·판매 구성 보기

한 항목씩 조정

속도를 올리는 순서

여러 값을 한꺼번에 바꾸면 원인을 찾기 어렵습니다.

  1. STEP 1

    기준값 저장

    첫 입력과 캐시 재사용을 구분하고 각각 세 번 기록합니다. 프리필·디코드·피크 메모리를 함께 비교합니다.

    멈출 때: 오류가 있거나 메모리 여유가 2GB보다 작으면 다음 단계로 넘어가지 않습니다.

  2. STEP 2

    프리필 청크 조정

    1,024 → 2,048 → 4,096 순서로 올리며 긴 입력의 TTFT와 피크 메모리를 비교합니다.

    멈출 때: TTFT가 줄지 않거나 메모리 정점이 급증하면 직전 값으로 돌아갑니다.

  3. STEP 3

    KV 캐시 조정

    문맥이 부족할 때만 F16/BF16 기준값과 Q8 캐시를 같은 질문으로 비교합니다.

    멈출 때: 출력 차이가 생기거나 필요한 문맥이 이미 확보됐다면 기본 정밀도를 유지합니다.

  4. STEP 4

    MTP·투기 디코딩

    지원 모델에서만 켠 뒤 코드와 일반 문장을 나눠 수락률과 실제 디코드 tok/s를 측정합니다.

    멈출 때: 세 번의 중앙값이 기준보다 좋아지지 않으면 끕니다.

  5. STEP 5

    문맥 확장

    실제로 필요한 길이까지 두 배씩 늘리고 중간 정보 검색과 스왑 여부를 확인합니다.

    멈출 때: 검색 정확도가 떨어지거나 스왑·메모리 압축이 시작되면 한 단계 줄입니다.

내 장비 측정 기록 보내기

같은 조건으로 3회 이상 측정한 JSON을 가져오세요. 전송 버튼을 누르기 전에는 이 브라우저에서만 확인합니다.

장비·모델·실행 조건과 측정값만 받습니다. 질문·답변·원본 로그·파일 경로는 넣지 마세요.

기록 파일이 없다면, 실행 중인 로컬 서버에서 측정 도구로 만들 수 있습니다. Node.js 20 이상이 필요하며 결과를 자동 전송하지 않습니다.

측정 방법 읽기측정 도구 받기장비·설정 양식 받기

검토한 이용자 제출 기록입니다. 이 사이트의 직접 측정과는 구분합니다.

수정 내역

사이트의 안내가 바뀐 기록입니다. 설치된 엔진·모델 버전을 자동으로 확인한 결과는 아닙니다.

  1. 장비·프로필 저장과 다시 열기 추가

    실행 가능한 프로필은 장비와 함께 이 브라우저에 최대 5개까지 저장하고, 가이드 목록에서 다시 열 수 있게 했습니다. 저장한 뒤 공개 설정이 바뀌거나 프로필이 없어지면 실행 전에 다시 확인하도록 안내합니다.

  2. 실행 엔진 설명으로 이어지는 링크 추가

    설정에 표시된 엔진 이름에서 해당 실행 프로그램의 설명으로 이어지도록 했습니다. 엔진이 확인되지 않은 경로에는 임의의 프로그램을 연결하지 않습니다.