DeepSeek V4 Flash API가 이렇게 싼데, 왜 DGX Spark 2대를 돌릴까?

왜 이 비교를 했나

DGX Spark 두 대에 DeepSeek V4 Flash 0731을 올린 뒤 가장 먼저 생긴 질문은 단순했다. 공식 API가 이미 저렴하고 편하다면, 굳이 두 대의 장비를 묶어 로컬로 운영할 이유가 있을까?

모델이 낸 답의 품질만 비교해서는 충분하지 않다. 로컬 모델은 네트워크 왕복이 없어 짧은 요청에 유리할 수 있고, 공식 API는 대규모 서버와 batching 덕분에 긴 입력과 동시 요청에서 유리할 수 있다. 데이터 통제와 커스터마이징도 로컬에만 있는 장점이다.

그래서 비교를 네 단계로 나눴다.

  1. 일본어·영어·중국어 기술 제목 30개의 한국어 번역 품질
  2. 다의어와 인터넷 은어 36개의 문맥 이해
  3. 299~131,116 token 입력의 첫 응답 시간과 출력 속도
  4. 파일을 읽고 코드를 고치고 테스트하는 최소 코딩 에이전트 5개 과제

번역과 순수 속도 측정에서는 불필요한 추론을 끄고, 코딩 에이전트에서는 양쪽 모두 최대 thinking 설정을 사용했다.

결론부터

이번 결과에서 가장 큰 차이는 번역 품질이 아니라 serving 성능이었다.

1. 실제 번역은 얼마나 달랐나

번역에는 기술 뉴스·커뮤니티 제목 30개를 사용했다. 일본어·영어·중국어 각각 10개다. 모델 이름을 숨긴 블라인드 비교에서 서로 다른 9개를 평가했다.

숫자만 보면 API 평균이 조금 높고 로컬 승수가 하나 많다. 하지만 각 차이의 크기는 같지 않았다. 취향에 가까운 차이도 있었고, 의미를 바꾸는 오류도 있었다. 대표적인 차이 두 개만 추리면 다음과 같다.

대표 사례 두 개

원문 표현 2×DGX Spark 로컬 공식 API 판단
お化けローカルLLM 유령 로컬 LLM 괴물 로컬 LLM 비유를 살린 API가 자연스러움
各位大佬 각 고수님들께 각종 대형 분들께 인터넷 호칭을 이해한 로컬이 정확함

お化け는 이 문맥에서 “괴물 같은 성능”이라는 비유에 가깝고, 중국 인터넷의 大佬는 “고수”나 “전문가”를 부르는 표현이다. 다만 한 사례에서 이겼다고 해당 언어나 은어 전반에 강하다고 일반화할 수는 없다. 21개는 완전히 같았고, 서로 다른 9개에도 취향 수준의 차이와 양쪽이 함께 틀린 항목이 섞여 있었다.

2. 단어만 번역할 때와 문맥이 있을 때

영어·일본어·중국어의 다의어와 기술 은어 18개를 문맥 없음·문맥 있음으로 나눠 총 36개를 비교했다.

일반적인 다의어는 양쪽 모두 대체로 문맥에 맞게 처리했고, 차이는 커뮤니티 호칭과 은어에서 주로 나타났다. 자동 채점은 뜻이 통하는 의역도 실패로 잡을 수 있어 실제 출력도 함께 검토했다. 개별 사례를 길게 나열하기보다는 앞의 대표 사례 두 개와 집계 결과만 남겼다.

3. 짧은 질문은 로컬, 긴 문서는 API

여기서 첫 응답 시간은 요청을 보낸 뒤 답변이 화면에 나타나기 시작할 때까지 걸린 시간이다. 각 요청은 이후 160 tokens까지 답변을 생성했다.

실제 입력 크기 2×DGX Spark 로컬 공식 API 해석
299 tokens 0.294초 0.671초 짧은 입력은 로컬이 2.28배 빠르게 시작
2,092 tokens 1.077초 0.683초 이 구간부터 API가 역전
8,236 tokens 4.169초 1.057초 API가 3.94배 빠르게 시작
32,812 tokens 16.966초 1.759초 API가 9.65배 빠르게 시작
131,116 tokens 80.238초 5.749초 API가 13.96배 빠르게 시작

짧은 질문에서는 네트워크를 거치지 않는 로컬이 즉각적이었다. 하지만 읽어야 할 입력이 길어질수록 공식 API가 빠르게 역전했다. 131K-token 입력에서는 로컬이 답을 시작하기까지 80초가 걸렸지만 API는 6초가 채 걸리지 않았다.

답이 시작된 뒤 글을 생성하는 속도도 API가 대략 두 배였다.

30개 제목 번역에서는 항목별 중앙값이 로컬 0.746초, API 0.843초로 비슷했다. API 전체 시간이 더 짧았던 것은 로컬 첫 두 요청에 cold/JIT 지연이 포함됐기 때문이다.

왜 100만 토큰까지 측정하지 않았나

DeepSeek 공식 문서는 deepseek-v4-flash의 context length를 1M으로 명시한다. 당시 로컬 서버도 max_model_len=1,048,576으로 구성돼 있어 두 환경 모두 설정상 100만 토큰 context를 받을 수 있었다.

이번 속도 측정 코드의 입력 크기 목록은 처음부터 256, 2K, 8K, 32K, 131K로 정했다. 1M 입력은 테스트 목록에 넣지 않았고 공식 API와 로컬 어느 쪽에도 요청하지 않았다. 따라서 표의 최대 입력이 131K인 것은 이번 비교의 측정 범위일 뿐, 로컬이 그 이상에서 실패했다거나 context 한도가 131K라는 뜻이 아니다. 1M은 지원 사양이지만 이번 글에는 실제로 측정한 성능 수치가 없다.

4. 여러 에이전트를 동시에 돌리면 격차가 커졌다

32K-token 입력을 1개, 2개, 4개, 6개 동시에 보냈다. 아래 전체 처리량은 입력 읽기, queue 대기, 출력 생성을 모두 포함한다.

동시 요청 로컬 전체 처리량 API 전체 처리량 API/로컬
1 8.35 tok/s 55.72 tok/s 6.67배
2 8.74 tok/s 103.76 tok/s 11.87배
4 8.94 tok/s 187.17 tok/s 20.94배
6 8.98 tok/s 271.19 tok/s 30.20배

현재 로컬 구성은 요청을 늘려도 전체 처리량이 약 9 tok/s에 머물렀다. 긴 입력을 먼저 읽는 prefill과 queue가 병목이었다. 반면 공식 API는 동시 요청 수에 따라 전체 처리량이 계속 증가했다.

단일 챗봇이라면 로컬 지연도 받아들일 수 있다. 하지만 여러 에이전트가 긴 코드나 문서를 동시에 읽는 워크로드에서는 차이가 매우 크게 체감된다.

5. 코딩 에이전트는 실제로 무슨 일을 했나

에이전트 비교에서는 대형 프레임워크를 사용하지 않았다. 모델에는 작업 설명과 임시 작업 폴더를 주고 다음 도구만 제공했다.

각 실행은 깨끗한 새 작업 폴더에서 시작했다. 모델은 공개 테스트를 보며 코드를 고칠 수 있었지만, 최종 hidden tests와 정답 코드는 볼 수 없었다. 공개 테스트와 hidden tests를 모두 통과해야 성공으로 판정했다.

과제 한눈에 보기

과제 현실에서 하는 일 공식 API 2×DGX Spark 로컬
CSV 집계 매출 CSV를 그룹별로 묶고 금액을 오차 없이 합산 통과, hidden 15/15 실패, 14/15
의존성 그래프 패키지 실행 순서와 순환 의존성 탐지 통과, 10/10 통과, 10/10
설정 병합 기본·환경·사용자 설정을 안전하게 합치기 통과, 4/4 통과, 4/4
Retry-After API 제한 시 서버 지시에 맞춰 재시도 실패, 13/21 실패, 16/21
안전한 ZIP 해제 악성 ZIP의 경로 탈출과 링크 공격 차단 실패, 11/16 실패, 11/16

최종 pass@1은 공식 API 3/5, 로컬 2/5였다.

CSV 집계: 평범한 데이터보다 경계 조건이 어려웠다

이 과제는 CSV를 읽어 그룹별 금액을 합산하는 작업이다. 하지만 실제 요구사항에는 BOM, 중복 헤더, 빈 행, 잘못된 열 수, 정확한 Decimal 계산, 문자열과 text stream 구분 등이 포함됐다.

API는 hidden 15개를 모두 통과했다. 로컬은 14개를 통과했지만, text stream만 받아야 하는 API 경계에서 binary stream 관련 예외 처리를 놓쳤다. 정상적인 CSV는 처리했지만 잘못된 입력을 정확히 거부하는 마지막 조건에서 실패한 셈이다.

의존성 그래프: 둘 다 통과

패키지 A가 B를 필요로 하고 B가 C를 필요로 할 때 C → B → A 순서를 찾아야 한다. 중복 의존성을 제거하고, 결과 순서를 항상 동일하게 만들고, 실제 순환 경로까지 찾아야 했다.

양쪽 모두 통과했다. API 192.4초, 로컬 263.0초가 걸렸다.

설정 병합: 로컬이 더 짧고 빠르게 해결

기본 설정 위에 배포 환경과 사용자 override를 순서대로 적용하되, 입력을 수정하지 않고 특정 키 삭제까지 지원하는 과제다.

양쪽 모두 통과했다. 이 과제에서는 로컬이 5턴·66.6초에 끝냈고 API는 16턴·77.5초가 걸렸다. API가 모든 과제에서 더 빠르거나 더 효율적이었던 것은 아니다.

Retry-After: 공개 테스트는 통과했지만 계약을 완성하지 못함

외부 API가 “지금은 요청이 많으니 몇 초 뒤 다시 시도하라”고 응답했을 때 exponential backoff와 서버의 Retry-After를 함께 적용하는 코드다. 초 단위와 HTTP 날짜, 최대 대기시간, 재시도 가능 예외, 잘못된 설정값을 모두 처리해야 했다.

양쪽 모두 공개 테스트는 통과했다. hidden에서는 로컬 16/21, API 13/21로 오히려 로컬이 더 가까웠다. 하지만 잘못된 설정값을 operation 호출 전에 정확한 예외 타입으로 거부하는 계약을 완성하지 못해 둘 다 실패다.

안전한 ZIP 해제: 둘 다 보안 edge case에서 멈춤

일반 ZIP 파일을 푸는 문제가 아니다. ../ 경로 탈출, 절대경로, Windows drive path, 심볼릭 링크, 중복 파일, 파일·디렉터리 충돌, 기존 파일 덮어쓰기, 압축 해제 크기 제한을 모두 막아야 했다.

양쪽 모두 hidden 11/16에서 20턴 한도를 소진했다.

둘 다 정상적인 구현은 만들었지만 공격자가 의도적으로 만든 입력까지 모두 방어하는 수준에는 도달하지 못했다. 보안 코드는 공개 테스트를 통과했다는 이유만으로 신뢰하면 안 된다는 사례다.

Agent 결과를 어떻게 해석해야 하나

API가 한 문제 더 풀고 전체 wall time도 짧았다. 그러나 과제가 5개뿐이고 endpoint별 단일 실행이다. 결과에는 모델의 reasoning 길이, 도구 호출 횟수, 샘플링 변동도 포함된다. 이 결과만으로 API endpoint의 모델이 더 똑똑하다고 일반화하기보다는, 이번 실행에서 API가 CSV의 마지막 경계 조건 하나를 더 해결했다고 읽는 편이 정확하다.

6. 비용은 얼마나 들었나

환율은 비교 편의를 위해 1달러 = 1,500원으로 고정했다.

측정 공식 API 비용 원화 환산
제목 30개 번역 $0.000924 약 ₩1.39
단어·문맥 36개 $0.000620 약 ₩0.93
긴 문맥·동시성 속도 grid $0.320619 약 ₩480.93
코딩 에이전트 최종 5개 $0.028828 약 ₩43.24
보존된 최종 run 합계 $0.350991 약 ₩526.49

일반적인 제목 번역 비용은 사실상 무시할 수준이었다. 전체 비용 대부분은 131K-token 입력을 여러 개 동시에 보내는 의도적인 stress test에서 발생했다.

이 금액은 저장된 최종 response usage를 기준으로 재구성한 값이다. harness를 수정하면서 중단되거나 결과가 덮어써진 API 요청은 포함하지 못했으므로 실제 계정 차감액은 더 많을 수 있다.

DGX Spark 두 대의 전기료를 넣으면

NVIDIA 공식 사용자 가이드에 따르면 DGX Spark 한 대는 240W 외부 전원공급장치를 사용한다. GB10 SoC TDP는 140W이고 나머지 100W는 ConnectX-7, SSD, Wi-Fi, USB-C 등 다른 구성요소에 배정된다. 여기서는 실제 벽면 소비전력을 측정하지 못했으므로 한 대 240W, 두 대 합계 480W를 실행 내내 사용하는 보수적인 용량 기준 추정치로 계산했다. 전원공급장치 용량이 항상 실제 소비전력과 같다는 뜻은 아니다.

2026년 7월 기준 한국 주택용 저압 전력량요금은 누진구간별 120.0원, 214.6원, 307.3원/kWh다. 여기에 기후환경요금 9원/kWh, 2026년 3분기 연료비조정단가 +5원/kWh, 부가가치세 10%, 전력산업기반기금 2.7%를 적용하면 기본요금 구간 상승과 원 단위 반올림을 제외한 증분 실효단가는 다음과 같다.

가정용 누진구간 증분 실효단가
1단계 약 $0.1007/kWh · ₩151.02/kWh
2단계 약 $0.1718/kWh · ₩257.63/kWh
3단계 약 $0.2414/kWh · ₩362.11/kWh

이 단가로 실제 로컬 wall time에만 480W를 적용하면 다음과 같다.

측정 로컬 시간 2×Spark 전력량 로컬 전기료 범위 공식 API 비용
제목 30개 번역 38.6초 0.00514kWh $0.00052~$0.00124 · ₩0.78~₩1.86 $0.000924 · ₩1.39
단어·문맥 36개 20.5초 0.00273kWh $0.00028~$0.00066 · ₩0.41~₩0.99 $0.000620 · ₩0.93
긴 문맥·동시성 속도 grid 429.7초 0.05730kWh $0.00577~$0.01383 · ₩8.65~₩20.75 $0.320619 · ₩480.93
코딩 에이전트 5개 1,416.5초 0.18886kWh $0.01901~$0.04559 · ₩28.52~₩68.39 $0.028828 · ₩43.24
합계 1,905.3초 0.25404kWh $0.02558~$0.06133 · ₩38.36~₩91.99 $0.350991 · ₩526.49

전기료만 보면 이번 전체 로컬 run은 공식 API보다 약 5.72~13.72배 저렴했다. 일반적인 2단계 증분단가를 대입하면 로컬은 약 $0.04363(₩65.45)로 API $0.350991(₩526.49)의 약 8분의 1이다. 그러나 차이의 대부분은 속도 stress test에서 생겼다. 131K 입력과 동시 요청 grid는 로컬 전기료가 $0.00577~$0.01383(₩8.65~₩20.75)인 반면 API는 $0.320619(₩480.93)이었다.

반대로 코딩 에이전트 5개만 보면 결론이 달라진다. 로컬은 23분 36초 동안 실행돼 2단계 기준 약 $0.03244(₩48.66)가 들었다. API 비용 $0.028828(₩43.24)보다 약 12.5% 비싸다. 호출당 API 가격이 낮고 로컬이 두 배 이상 오래 걸리면 전기료만으로도 API가 이길 수 있다.

24시간 계속 켜두면

480W를 계속 사용한다는 상한 가정에서 1시간은 0.48kWh로 약 $0.048~$0.116(₩72~₩174), 24시간은 11.52kWh로 약 $1.16~$2.78(₩1,740~₩4,171)다. 30일이면 345.6kWh가 추가된다.

한국 가정용 전기는 기존 가정 사용량 위에 누진 적용되므로 월 비용은 크게 달라진다. 기존 사용량이 0kWh라고 놓으면 Spark 두 대의 증분은 7~8월 약 $38.55(₩57,831), 그 외 계절 약 $45.66(₩68,492)다. 이미 월 300kWh를 사용하는 가정이라면 각각 약 $77.78(₩116,674)와 $80.75(₩121,120)까지 올라간다. 7~8월에는 1·2단계 경계가 300kWh와 450kWh로 완화되고, 그 외 달에는 200kWh와 400kWh가 적용된다.

이 비교는 이미 DGX Spark 두 대를 보유했다는 전제의 증분 전기료다. 장비 구매비와 감가상각, 냉방, 외부 네트워크 장비, 벤치 외 유휴전력, 운영 인건비는 포함하지 않았다. 따라서 전기료가 API보다 싸다는 결과를 총소유비용 우위로 해석하면 안 된다.

측정 방법

참고

마지막으로

이번 비교를 시작한 직접적인 계기는 로컬에서 실행한 DeepSeek V4 Flash를 Hermes에 연결해 간단한 작업을 시켜 본 경험이었다. 생각보다 잘 동작했고, “이 정도면 괜찮은데?”라는 생각이 들었다. 기존에 로컬로 실행해 본 다른 모델보다 확실히 사용할 만하다는 느낌이 있었다. 동시에 이 모델은 DGX Spark 두 대가 필요하고 공식 API 가격도 저렴했다. 그래서 로컬로 어느 정도까지 실용적인지 확인하다가 이번 테스트까지 오게 됐다. 모델이 별로였다면 여기까지 테스트하지도 않았을 것이다.

Wed, 05 Aug 2026 00:00:00 +0900