DeepSeek DeepInfer, 직접 운영하려면? 하드웨어 요건과 API 선택 기준

DeepInfer는 DeepSeek가 공개한 오픈 소스 추론 프레임워크입니다. 모델을 실행하는 엔진이지, 새로운 모델이나 즉시 호출할 수 있는 호스팅 API가 아닙니다. DeepSeek 이용 방식을 고르는 개발자라면 먼저 추론 백엔드 운영까지 맡아야 하는지 판단해야 합니다. 애플리케이션을 출시하는 것이 목적이라면 호스팅 API를 직접 구축하고 유지해야 할 서비스 전체와 비교하세요.

이 글은 2026년 10월 22일에 확인한 공식 문서를 바탕으로 작성했습니다. 지원 가속기에 DeepInfer를 배포하거나 공식 성능 그래프를 재현하지는 않았습니다. 아래 점검표와 비용 계산은 의사결정 도구이며, 수치 예시는 모두 가정입니다. Ofox는 API 서비스를 제공하는 이 글의 발행 주체입니다. 모든 독자에게 호스팅 서비스를 권하는 대신 두 방식의 조건과 한계를 설명합니다.

DeepInfer, 모델, deepseek-recipe는 각각 무엇을 담당하나

모델을 서비스하려면 여러 역할이 필요합니다. 구성 요소의 이름을 같은 뜻으로 취급하면 비용 추정과 오류 진단 모두 어려워집니다.

DeepInfer README는 지원 모델로 DeepSeek-V4.1-Flash를 명시하며, 기본 체크포인트는 deepseek-ai/DeepSeek-V4.1-Flash-1017입니다. 모델 버전의 변경은 1017 업데이트 해설에서 다룹니다. 이 글의 주제는 엔진과 배포 방식의 선택입니다.

별도 저장소인 deepseek-recipe는 Chat Completions, Responses, Messages 형식을 변환합니다. 호출하는 쪽에서 모델 추론, 도구 실행, HTTP 통신을 제공해야 합니다. 포함된 Python·Rust 서버 예제는 모의 추론을 사용합니다. 데모에서 JSON을 받았다는 사실만으로 실제 모델이 응답을 생성했다고 볼 수 없습니다.

개발자가 구분할 검증 지점은 세 가지입니다. HTTP 응답이 오는지, 프롬프트가 올바르게 구성되는지, 실제 모델이 생성에 성공하는지 따로 확인해야 합니다. 하나가 통과했다고 나머지 두 가지까지 검증된 것은 아닙니다.

설치 계획보다 먼저 지원 하드웨어를 확인한다

현재 README에는 NVIDIA SM100 GPU와 Huawei Ascend 950 NPU가 나열되어 있습니다. 기본 환경은 Linux, GCC 13 이상, Python 3.12입니다. NVIDIA 경로에는 CUDA 13, Ascend 경로에는 CANN 9.2가 필요합니다. 이는 확인 시점에 문서가 명시한 대상이지, 향후 이식 버전에 대한 약속이 아닙니다.

RTX 4090이나 H100은 이 지원 목록에 없습니다. 그렇다고 “DeepSeek 모델은 해당 카드에서 절대 실행할 수 없다”는 뜻은 아닙니다. 다른 엔진으로 모델을 실행할 수 있는지는 별도의 호환성 문제입니다. 마찬가지로 커뮤니티의 이식 제안 PR이 있다고 해서 현재 공개 버전이 이미 지원하는 것도 아닙니다.

구축 공수를 산정하기 전에 장치 아키텍처, 드라이버와 도구 체인 버전, 체크포인트, 엔진 리비전을 기록하세요. 전제 조건이 맞지 않으면 호환성 평가부터 해야 합니다. 지원되지 않는 구성이 혹시 컴파일되는지 알아보기 위해 비싼 장비부터 임대하는 것은 적절한 첫 실험이 아닙니다.

다음 세 질문을 구분해야 합니다.

1. 지원되는가: 이 엔진 버전의 문서에 해당 플랫폼이 명시되어 있는가?
2. 실행 가능한가: 선택한 구성에 모델을 적재하고 추론을 올바르게 완료할 수 있는가?
3. 효율적인가: 예상 부하에서 처리량과 지연 시간 목표를 충족하는가?

공식 배포 Q&A는 권장 프로덕션 설계에서 prefill GPU 64개와 decode GPU 64개를 가장 작은 효율적인 배포 단위로 설명합니다. 모든 오프라인 시험에 필요한 절대적인 최소 GPU 수가 아닙니다. README의 벤치마크 구성도 prefill과 decode가 다릅니다. 어느 숫자든 그대로 범용 “최소 하드웨어 구매 목록”에 옮겨서는 안 됩니다.

오프라인 추론을 온라인 API로 만들려면 무엇이 더 필요한가

공개 README는 완전한 서비스를 위해 추가로 필요한 세 부분을 명시합니다. KV 캐시 시스템, VE/Prefill/Decode 분리, 데이터 병렬 복제본 사이의 부하 분산입니다. VE는 시각 인코더, prefill은 입력 프롬프트 처리, decode는 이후 토큰 생성 단계를 뜻합니다. 동시에 분리에 필요한 엔진 기능의 상당 부분이 이미 구현되어 있다고 설명합니다. 기반 기능이 있다는 것과 전체 서비스가 조립되어 운영된다는 것은 다릅니다.

계획 단계에서 서비스 역할마다 담당자와 인수 검증 방법을 지정하세요.

이 표는 제안하는 운영 인수 기준입니다. DeepInfer가 왼쪽의 모든 기능을 제공한다는 뜻이 아닙니다. 특히 하드웨어를 직접 운영한다고 개인정보 보호가 자동으로 해결되지는 않습니다. 장비, 로그, 백업, 캐시된 프롬프트에 누가 접근할 수 있는지 여전히 관리해야 합니다.

호스팅 서비스를 비교할 때도 공급자에게 같은 질문을 하세요. 호환되는 엔드포인트 이름만으로 도구 동작, 캐시 과금, 보존 조건이 같다고 판단할 수 없습니다. 코딩 클라이언트 연결이 목적이라면 Codex 설정 가이드나 Claude Code 설정 가이드부터 보고, 선택한 경로의 현재 지원 여부를 확인한 뒤 인프라 추가를 검토하세요.

같은 부하와 서비스 목표를 기준으로 비용을 비교한다

초당 토큰 수의 최고치만으로 월 비용을 알 수는 없습니다. 입력 길이 분포, 출력 길이, 반복 접두부 비율, 해당하는 경우 이미지 사용, 동시 요청 수, 일별 피크를 포함한 대표 부하부터 준비하세요. 완료 요청 수, 출력 품질, 첫 토큰까지 걸리는 시간, 스트리밍 속도에 목표를 정합니다. 저렴하더라도 그 목표를 못 채우는 서비스는 동등한 대안이 아닙니다.

API 견적에는 비캐시 입력, 캐시 입력, 출력 가격을 따로 적용합니다. 캐시 쓰기, 저장 공간, 플랫폼 등 추가 요금은 선택한 공급자가 실제로 부과할 때만 포함하세요. 모르는 비용은 미확인 항목이지 0이 아닙니다. 토큰 수는 공급자의 과금 정의에 맞추고, 해당한다면 추론 토큰도 포함해야 합니다. DeepSeek API 요금 가이드(영문)에서 가격 구조를 확인하되, 구매 전에는 정확한 경로의 최신 견적을 받아야 합니다.

과금 토큰 수를 백만 단위로 계산하는 기본 틀은 다음과 같습니다.

월 API 비용 =
  비캐시 입력 토큰 수(백만 단위) × 해당 단가
  + 캐시 입력 토큰 수(백만 단위) × 해당 단가
  + 과금 출력 토큰 수(백만 단위) × 출력 단가
  + 적용되는 기타 월 요금

월 자체 운영 비용 =
  가속기 임대료 또는 배분된 하드웨어 감가상각비
  + 호스트·네트워크·저장 공간 비용
  + 임대료에 포함되지 않은 전력비
  + 운영·지원 인건비
  + 이중화·복구 용량
  + 부하에 따라 달라지는 비용

같은 가속기에 임대료와 감가상각비를 동시에 넣지 마세요. 임대료에 전력이 포함되어 있다면 전력비를 다시 더하지 않습니다. 공용 인력의 업무 시간도 명시적으로 배분하세요. 미확인 값은 견적이나 측정으로 보완하고 범위로 제시해야 하며, 겉으로 정밀한 합계 속에 숨겨서는 안 됩니다.

재계산 가능한 예시이며 실제 DeepInfer 견적은 아니다

부하 한 단위를 입력 1억 토큰과 과금 출력 2,000만 토큰으로 가정하고, 입력의 60%가 캐시 적중으로 과금된다고 합시다. 설명을 위해서만 비캐시 입력 백만 토큰당 0.80달러, 캐시 입력 0.20달러, 출력 2.00달러를 사용합니다. 모두 계산을 위한 가상 값이며 DeepSeek나 Ofox의 현재 요금이 아닙니다. 이 절의 금액은 전부 미국 달러 기준입니다.

단위당 API 변동비는 40 × 0.80 + 60 × 0.20 + 20 × 2.00 = 84달러입니다. 월 플랫폼 요금 16달러도 가정합니다. 자체 운영은 월 고정비 50,000달러에 단위당 추가 변동비 20달러가 든다고 합시다. 이 역시 DeepInfer용 하드웨어의 실제 견적이 아닙니다.

이 가정에서 비용이 같아지는 식은 84x + 16 = 50,000 + 20x, 즉 월 781단위입니다. 하지만 이 계산은 배포 권고가 아닙니다. 고정 구성으로 해당 물량을 목표 지연 시간과 신뢰성에 맞게 처리할 수 있어야 합니다. 781단위에 추가 클러스터가 필요하다면 고정비를 다시 계산해야 하며, 계산상 손익분기점이 사라질 수도 있습니다.

예시에서 캐시 적중률을 60%에서 20%로 낮추면 API 변동비는 단위당 84달러에서 108달러로 늘어납니다. 재사용되는 작업이 줄면 자체 운영의 비용과 용량도 달라질 수 있습니다. 한쪽을 억지로 고정해 놓고 정확한 절감액을 주장하지 마세요. 한산한 달, 예상 수준의 달, 피크가 있는 달을 각각 평가해야 합니다.

어느 쪽이든 탈락시킬 수 있는 파일럿을 진행한다

자체 운영을 고려하는 팀이라면 프로덕션 도입을 약속하기 전에 다음 순서를 따르세요.

1. 부하와 합격 기준을 정의합니다. 민감 정보를 적절히 제거한 대표 샘플을 보관합니다. 방식을 선택하기 전에 품질, 지연 시간, 실패율, 데이터 처리 요구를 정합니다.
2. 플랫폼 호환성을 확인합니다. 지원 가속기, 소프트웨어 환경, 체크포인트, 코드 리비전을 기록합니다. 버전 정보가 없는 블로그 설치 명령 대신 저장소의 최신 예제를 참조합니다.
3. 오프라인 정확성을 검증합니다. 해당 환경에서 적절한 공식 예제와 평가를 실행하고 결과와 실패를 기록합니다. 빌드 성공은 생성 품질이나 프로토콜 호환성을 입증하지 않습니다.
4. 실제 서비스 경로를 시험합니다. 모의 백엔드를 교체한 뒤 일반 요청과 스트리밍 요청을 검증합니다. 도구가 필요하면 생성 인수와 앱의 실행을 따로 확인합니다. 잘못된 입력, 타임아웃, 클라이언트 취소, 과부하도 시험합니다.
5. 현실적인 부하를 측정합니다. 짧고 긴 프롬프트, 준비된 캐시와 비어 있는 캐시, 한산한 시간, 동시 요청 급증을 포함합니다. 완료 작업량, 지연 분포, 실패, 모든 과금 자원을 기록합니다.
6. 호스팅 경로와 비교합니다. 모델 버전과 요청 동작을 최대한 맞춥니다. 양자화, 추론 설정, 빠진 기능처럼 공정한 비교를 어렵게 하는 차이는 명시합니다.
7. 비용을 다시 계산하고 결정합니다. 되돌릴 경로를 확보하고 운영 담당자를 지정합니다. 필수 조건을 못 채우는 선택지를 유리한 평균 비용만으로 통과시키지 마세요.

파일럿이 실패하면 돈을 더 쓰기 전에 문제를 분류하세요. 컴파일러 오류는 빌드 환경, 메모리 부족은 모델과 런타임 용량 분석의 대상입니다. 정상적인 모의 응답은 테스트 장치가 동작한 결과일 뿐이며, 잘못된 도구 인수는 프로토콜과 모델 경로를 조사해야 합니다. 어떤 경우든 API 키를 바꾸거나 더 큰 장비를 쓰면 모두 해결된다는 증거는 아닙니다.

팀이 실제로 운영할 수 있는 방식을 선택한다

수요가 불확실하거나 사용이 간헐적이고, 빠르게 출시해야 하거나 가속기 운영 담당자가 없다면 호스팅 API가 우선 검토할 만한 선택지입니다. 모든 호스팅 경로를 같은 것으로 보지 말고 공급자의 제한과 조건을 확인하세요.

호환 인프라와 서비스 전체를 운영할 팀이 있고, 지속적인 수요 또는 이용 가능한 호스팅 서비스로는 충족할 수 없는 구체적 요구가 있다면 자체 운영 파일럿을 검토할 가치가 있습니다. 이미 장비가 있어도 무료인 프로젝트는 아닙니다. 다른 용도로 쓰지 못하는 기회비용과 지원 인력을 계산해야 합니다.

결정 전에 다음 기록을 작성하세요.

작업과 정확한 모델 버전:
필수 품질·지연 시간·데이터 요구:
예상 / 저부하 / 피크 월간 부하:
측정한 캐시 동작과 과금 토큰 분류:
자체 운영 플랫폼과 담당자:
호스팅 경로와 미확인 계약·기능 항목:
선택지별 월 총비용 범위:
견적을 뒷받침하는 처리 용량 증거:
파일럿 결과, 복귀 경로, 결정 날짜:

DeepInfer는 상당한 추론 엔지니어링을 공개한다는 점에서 의미가 있습니다. 그래도 채택 결정은 운영 가능한 서비스와 실제 부하에 맞는 견적으로 이어져야 합니다. 오픈 소스 공개만으로 API 청구액이 줄어드는 것도, 정상 동작하는 앱을 새 백엔드에 맞춰 다시 만들어야 하는 것도 아닙니다.