▲

DeepSeek가 대규모에선 저렴하지만 로컬에서는 비싼 이유

 (seangoedecke.com)
4P by GN⁺ 4일전 | ★ favorite | 댓글 1개
  • DeepSeek-V3와 같은 일부 AI 모델은 대규모 제공 시 저렴하고 빠르지만 로컬 실행 시에는 느리고 비쌈
  • 그 이유는 GPU 활용 효율과 관련된 throughput(처리량)과 latency(지연시간) 의 근본적 트레이드오프에 있음
  • 배치 크기를 키우면 GPU가 효율적으로 동작하지만, 사용자는 토큰이 모일 때까지 대기해야 해 지연시간 증가 현상 발생
  • Mixture-of-Experts 구조와 딥 파이프라인을 가진 모델은 높은 배치와 지연시간을 필요로 함
  • 로컬 단일 사용자 환경에서는 충분히 큰 배치 형성이 어려워 성능 저하 및 비용 증가 문제 발생
  • OpenAI, Anthropic 등은 아키텍처 자체의 효율화, 고도의 배치 전략, 또는 과도한 GPU 투입 등으로 빠른 응답을 구현

배치 인퍼런스와 GPU 효율

  • GPU는 대규모 행렬 곱셈(GEMM) 에 최적화된 하드웨어임
  • 여러 사용자의 토큰을 한 번에 묶어 큰 행렬로 배치 실행 시, 낮은 왕복 오버헤드와 메모리 효율로 인해 처리량이 급격히 향상됨
  • 인퍼런스 서버는 여러 요청의 토큰을 큐에 쌓고, 적당한 크기의 배치를 선정해 대규모 GEMM 연산을 수행함
  • 이 과정에서 서버는 배치 크기(throughput 증가) 와 대기 시간(latency 증가) 간의 트레이드오프를 선택하게 됨

왜 일부 모델은 대형 배치에 최적화되어 있는가

Mixture of Experts (MoE)와 배치

  • MoE 구조(DeepSeek-V3, GPT-4 추정)가 GPU 효율이 낮은 주요 원인임
  • 수백 개의 ‘전문가’ 블록들이 각각 분리된 행렬 곱셈을 요구하므로, 소규모 배치에서는 각 전문가가 할 일이 적어 효율이 떨어짐
  • 많은 동시 요청이 있어야 모든 전문가를 충분히 활용 가능하므로, 서비스 수준에서는 대형 배치가 필수임
  • 짧은 대기(윈도우 5ms) 에는 전문가들이 빈번히 유휴 상태, 긴 대기(윈도우 200ms) 에서는 고효율 최대화 가능

딥 파이프라인 모델의 배치 이슈

  • 수백 계층의 대형 트랜스포머는 여러 GPU에 레이어별로 분할(파이프라이닝)해 실행함
  • 하나의 배치 내 토큰 수가 파이프라인 스텝보다 적을 경우 ‘파이프라인 버블’ 현상 발생, 이는 처리량 감소로 이어짐
  • 이를 방지하려면 큰 배치(긴 대기)가 필수적이며, 이로 인해 모델 응답 시간이 길어짐

왜 큐를 항상 가득 채울 수 없는가

  • 이론상 많은 동시 트래픽으로 항상 큐를 채운다면 버블을 피할 것으로 보임
  • 하지만, 트랜스포머 Attention 단계에서 행렬 크기(길이)가 모두 같아야 배치화 가능하므로, 실무상 단일 큐로 완벽 동작 어려움
  • 또한, FFN과 attention 단계를 분리할 경우 메모리 오버헤드 급증 및 데이터 이동 비효율 이슈 발생

요약 및 결론

  • 대형 배치 처리는 GPU 비용 절감 및 처리량 향상에 필수지만, 사용자는 대기시간이 길어짐
  • Mixture-of-Experts, 대형 파이프라인 구조 모델은 본질적으로 대기 기반 고효율 배치 환경에 최적화됨
  • 로컬처럼 트래픽이 적은 환경에서는 최적화된 대형 배치 구성이 불가하므로 GPU 효율 급감 및 실행 비용 상승 문제 발생
  • OpenAI, Anthropic 등은 빠른 응답성을 보여주는데, 그 이유는
    • (1) MoE가 아닌 더 효율적인 구조일 수 있음
    • (2) 배치/파이프라인 최적화, 고도의 추론 트릭 적용
    • (3) 필요한 것 이상으로 많은 GPU를 투입해 속도를 사는 구조일 수 있음

추가: 프리필 배치와 본문 배치의 차이

  • 트랜스포머는 한 사용자 프롬프트의 프리필(긴 입력)도 배치 실행해 빠른 초기 인퍼런스가 가능함
  • 그러나 본문에서 논의한 배치는 여러 사용자 요청의 본격 토큰 생성 단계에서 발생하는 처리량-지연 트레이드오프 배치임
  • 프리필 배치는 본문에서 언급된 동시 대형 배치와 직접적 관련 없음

참고 사항

  • 실제 인퍼런스 시스템은 지속적 배치(continuous batching) 방식을 병행해 배치가 차면 즉시 실행함
  • 그러나 근본적인 throughput-latency 트레이드오프 구조는 동일하게 적용됨
▲
GN⁺ 4일전  [-]
Hacker News 의견
  • 나는 Deepseek V3를 집에서 직접 돌리고 있는데, 가격 부담이 적고 속도와 성능이 만족스럽다는 생각. 많은 사람들이 GPU 없이는 큰 모델을 못 돌린다고 생각하지만, 내 경험상 오히려 CPU 서버가 전력 소모도 적고 실용적이라는 판단. 집 서버는 중급 EPYC 9004 시리즈 기반에 384GB 램 장착 슈퍼마이크로 보드 사용, 전체 비용은 약 4000달러 수준. GPU 없이 램만 풍부하게 쓰면 전력은 게이밍 데스크톱보다 낮은 경우도 많음. Unsloth Dynamic GGUF 모델을 활용해서 램 270GB 정도 사용, 실제로는 원본과 거의 비슷한 품질로 다양한 작업 지원 가능. 평소에 16k 컨텍스트로 돌리고 필요하면 24k까지 확장해 사용. 토큰 생성 속도는 초당 9~10, 컨텍스트 크게 하면 7까지. 2CPU 이용하는 환경에서는 이보다 더 빠른 토큰 속도로 전체 모델도 수행하는 사례 존재
    • Unsloth Dynamic GGUF가 실제로 원본과 얼마나 가까운 성능을 보여주는지 궁금증. 내 경험상 간단한 작업에서는 차이가 크지 않지만, 복잡한 과제나 긴 컨텍스트에서는 차이가 분명하게 나타나는 경우 있음. Unsloth가 뛰어난 작업을 하고 있는 건 사실이나, 원본 미양자화 모델과 직접적인 비교 평가 자료가 부족한 점이 아쉬움. 많은 사람들과 기업이 원본 모델을 직접 돌릴 여력이 없는 것도 현실적 한계
    • Ollama 같은 툴로 Deepseek을 코드 생성 용도로 40코어 CPU와 256GB RAM에서 돌리는 게 가능한지 궁금증. 모델에 약 200GB 정도 메모리 할당을 염두
    • 개인 사이트가 접속되지 않는다는 언급. 내가 디지털오션 공동창업자 Jeff Carr임을 소개하며 연락이 닿길 바라는 마음
    • 고속 메모리를 갖춘 GPU가 필수일 거라고 생각했는데, 정말로 GPU 없이 대용량 메모리만으로 추론이 가능한지 질문. 비통합 메모리만으로 어떻게 이게 가능한지 궁금증
    • Deepseek V3가 오픈웨이트 모델 중 실제로 실용성이 뛰어나다는 점에 동감. 많은 작업은 생각보다 높은 수준의 reasoning 토큰이 필요하지 않고, 기다릴 필요가 없다는 점이 장점. 필요하면 언제든지 더 높은 reasoning 옵션을 선택할 수 있다는 것도 매력. 직접 돌리지 않는다면, 몇몇 제공자가 전체 컨텍스트(16k)와 80tps 제공, 데이터 미활용을 약속하는 서비스도 있음. 9004 홈 서버 활용 예시, 멋진 구성이라는 감상
  • 이 블로그글 내용이 인상적이라는 평. 결론(“배칭이 필요하다”)은 동의하지만 MoE 모델 추론에 관한 논의는 좀 더 입체적이어야 한다는 의견. 큰 배치가 중요한 이유는 LLM 추론이 연산량 부족이 아니라, 모든 웨이트를 VRAM에서 로딩하는 것이 병목이라는 점 때문. H100의 TFLOPS와 메모리 대역폭을 비교하면, 사실 1바이트 당 300 FLOP를 처리할 여지가 있다는 계산. 배치가 클 수록 로딩한 파라미터별로 더 많은 연산을 할 수 있으니 배치 사이즈 극대화 필요. 이때문에 “roofline model”이라는 용어 사용. 모델이 점점 커지면서 VRAM에 모델 전체가 들어가지 않으니 GPU나 노드 여러 대로 분산 필요. NVLink나 Infiniband로도 VRAM 직접 로딩만큼 빠르지 않아 병목 발생. MoE의 강점은 expert parallelism, 즉 다른 노드에 서로 다른 expert를 메모리에 올려놓고 노드 간 통신을 최소화할 수 있다는 점. 단, 모든 expert가 VRAM에 들어가고 KV 캐시 등 오버헤드를 감당할 수 있을 만큼 노드가 충분할 때 가능. 결국 batch 사이즈가 자연스럽게 커질 수밖에 없고, 그렇게 만들어야만 각 GPU가 효율적으로 동작 가능
    • 서로 다른 "expert"들을 한 노드에 라운드로빈 방식으로 할당하고, 여러 요청이 동일 expert를 쓸 때만 기회적으로 batch로 묶는 방식 제안. 배치 대신 큐를 두는 셈이라 지연 시간은 증가하지만, 심층 연구 워크플로우 같은 환경에서는 충분히 감당 가능한 수준
    • 모델이 한 개의 GPU에 들어갈 수 없을 때, 레이어별로 나눠서 다음 레이어를 책임지는 GPU로 작은 벡터를 전송하여 연산하는 방식으로 추론 가능하다는 실제 적용 사례. Cerebras에서 이런 방식으로 Llama 4 Maverick에서 초당 2500조 토큰 생성. fabric 상에서 벡터 전달은 매우 빨라서 idle time 거의 없음
    • 모든 노드와 웨이트가 아날로그 회로에 배치되면 훨씬 빠른 동작이 가능한지에 대한 가능성을 상상
    • AMD에 투자하는 논리 중 하나가, 모델 전체가 단일 섀시에 들어가서 맵/리듀스 방식의 장점과 네트워크 장비 비용 절감이 있다는 점. 반대 의견 시 insight 제공 요청
  • 시간을 아끼고 싶은 사람을 위한 한 줄 요약: 답은 배치 추론. 여러 사람의 프롬프트를 모델 인스턴스에 동시에 투입시키는 방식으로, 촘촘하게 시분할만 하는 것보다 실질적으로 훨씬 효율적. 이로인해 온도와 seed 값을 고정해도 서비스 응답이 매번 다를 수 있는데, 그 이유는 각자의 프롬프트가 무엇과 함께 배치되는지 제어할 수 없기 때문. 이 현상이 데이터 탈취 공격 벡터가 될 가능성도 상상
    • 배치의 장점 중 하나는 동일 콘텐츠의 평가를 반복해 보고 실제로 "hallucination"이 있는지 확인할 때 편리하게 batch-size만큼 던져볼 수 있다는 것. 사실 배치라는 개념은 LLM에 처음부터 있었으나, 시간이 지나야 그 진가를 체감하는 경향
    • 나는 서비스 제공자가 모든 모델에서 항상 배치를 한다고 단순하게 추정했는데, 특정 모델 패밀리에서만 적용되는지 궁금증
    • 다른 프롬프트와 함께 배치된다고 왜 모델 응답에 변동이 생기는지 궁금증
    • 프롬프트가 다른 사람과 함께 묶일 수 있다면, 매우 효과적인 공격 벡터가 될 수 있다는 우려
  • 간결하게 정리하면:<br>- 높은 sparsity 모델은 하나의 행렬 곱 연산을 충분히 연산 집약적으로 만들려면 대형 배치(동시 요청 건수)가 필요<br>- 이 정도 큰 배치를 소화하려면 8~16개 정도 GPU가 있어야 모델 웨이트와 MLA/KV 캐시를 HBM에 맞출 수 있음. 그런데 GPU 8~16대로는 전체 처리량이 낮아서 유저 개개인 응답 속도가 정말 느려짐. 좋아질려면 256개 정도 GPU가 있어야 쾌적한 사용 경험 기대
    • 나는 16대 H100(2노드) 환경에서 Deepseek 서비스 중. 요청당 50~80 토큰/초, 전체적으로 수천 토큰까지 안정적인 처리량 확인. 최초 토큰 생성 시간도 안정적이고, 우리가 쓸 수 있는 어떤 클라우드 서비스보다 빠른 경험
    • sparsity가 높다 = 대용량 배치 필요 라고 말하는데, 그 연결고리가 이해가 잘 안 된다는 의견. sparse matmul이 사실상 0많은 matmul이라고 생각하는 조소
  • LLM 관점에서 훌륭한 해설이라는 감상. 하이퍼스케일 LLM 회사들은 실제 계산 trace를 면밀히 분석해 병목 구간을 찾아내고, 로드 밸런서, 파이프라인 아키텍처, 스케줄러 등으로 워크로드 최적화에 진심일 거라는 예측. 효율성 확보를 위한 "배치 선행조건"은 보안성 높은 어플리케이션에선 불리할 수 있는데, 쿼리 고립화가 극도로 비싸지는 구조. nVidia의 vGPU 가상화는 GPU 메모리를 시분할로 나누지만, context switch 때마다 언로드/리로드 필요, 중복 제거 없음이 의심. MIG도 메모리를 사용자에 따라 고정 분할하는데, 재조정하려면 GPU 재부팅 필요, 96GB GPU를 4x24GB로 쪼개기 싫은 심정 공감. GPU보드에 2차 메모리(DRAM)를 추가하면 PCIe보다 빠르게 다양한 행렬 데이터를 올릴 수 있을지 상상(HBM을 캐시로).<br>Software Engineering 생존형 실전 가이드북의 솔직한 서술도 호평
  • Deepseek용 소프트웨어 최적화 여지가 아직 많다는 의견. 실제로 소형 GPU와 대용량 RAM 시스템(ktransformers) 또는 엄청난 VRAM을 가진 시스템, 이 두 가지 유형만 접근성 중심 최적화. 192GB VRAM+나머지 일반 메모리가 있는 구조(DGX station, 2xRTX Pro 6000 등)는 MoE의 파워로 Deepseek 4bit도 꽤 빠르게 가능할 것. Deepseek에 중국어 프롬프트가 아니면 대부분의 expert가 활성화되지 않음. 프루닝도 더 쉬운 환경. 앞으로 enthusiast 시스템 방향성이 이런 소프트웨어적 최적화에 어울리는 흐름. Reddit에는 16x3090(Pcie 3.0 x4) 시스템으로 llama.cpp에서 토큰 7개/초 정도 구현 예시도 있고, 3090 한대로도 VRAM 전체를 초당 39번 스캔 가능하니 다른 성능 병목 원인이 있을 듯
    • 16x3090 시스템의 전력 소모는 무려 5KW. 이 정도면 전기세 생각하면 API 사용하는 게 더 저렴. Deepseek에서 중국어 프롬프트 사용 안 하면 활성화 안 되는 expert가 많다는 점에서, 모델 경량화 및 토큰을 더 근접 expert에 라우팅하는 방식 상상
    • MI300x 한 대가 192GB VRAM 제공 가능
  • 나는 ML 연구자도, 엔지니어도 아니라서 감안하고 들어 달라는 단서. Deepseek V3/R1은 기존 로컬 모델보다 워낙 커서 로컬 구동 자체가 비싼게 사실. 활성 파라미터는 전체 사이즈보다 적지만, 이건 연산요건만 줄일 뿐 메모리 요건은 그대로여서, 대부분은 거대한 GPU 없으면 사실상 실사용은 불가능 수준. 주요 프런티어(proprietary) 모델과 직접 비교도 불가, 사이즈 등 정보가 공개되어 있질 않음. 그 모델들이 로컬에서 더 싸게 돌아갈 거란 기대 근거도 없음. 오히려 MoE는 로컬/싱글유저 환경에서 배치의 비효율성이 크지 않으니 더 적합한 트레이드오프 제공. 배치를 키우면 각 토큰 대기지연이 200ms까지 늘지만, 대신 feed-forward 연산(GEMM)이 더 커지니 더 효율적으로 계산 진행. 배치가 커진다고 행렬 자체가 커지는 건지 궁금증. 내 머릿속 모델은, 배치는 “입력 행렬 크기 증가”가 목적이 아니라 “메모리 대역폭 제약을 연산 병목으로 옮기는게 목적”이랄까. 이미 웨이트는 레이어별로 조각내서 HBM → SRAM으로 불러오고, 조각별로 행렬 곱하고 마지막에 결과 합치는 구조. 배칭하면, 같은 웨이트로 여러 연산을 동시에 처리하는게 장점FLOPS를 효율적으로 최대화. OpenAI, Anthropic 등 대규모 모델이 빠르게 응답하는 것 자체가 사실인지, 블로그글에 time to first token별 수치가 없어 근거 약하다고 생각
    • 나는 원 글 작성자. ML 연구자는 아니고 관심 많은 엔지니어 입장. MoE의 로컬 싱글유저 시나리오는, 멀티유저 배치 이점이 없으니 GPU당 처리량이 극적으로 떨어진다는 뜻. 엄청난 병렬 인퍼런스 요청을 하지 않는 이상 그렇다는 설명. 배치를 통해 입력 행렬 크기를 키우면, 배치가 1이면 연산이 1xdim 행렬이고, 배치가 늘면 batch-size x dim이라 GPU 활용률 급상승, 즉 연산 병목 전환 가능. 마지막, 실제 Deepseek이 다른 모델 대비 느린 것도 많이 써보면 체감
  • mixture of experts는 고배치가 필요한데, 애플 실리콘을 쓰면 배치 사이즈 1일 때도 쓸 만한 것으로 염두. unified memory 덕분에 큰 모델도 로컬 실행 가능하지만 대역폭, FLOPS가 낮아 동작이 상대적으로 느림. MoE는 매번 처리해야 하는 파라미터 개수가 적어서 연산 부담이 낮다는 특성. 실제로 Deepseek을 맥에서 싱글 배치 인퍼런스로 쓸만한 속도로 돌린 사람 경험 다수. 물론 메모리를 충분히 장착하려면 구매 비용이 비싸다는 점은 여전. 맥이나 비슷한 구조의 머신이 앞으로 더 등장하면 MoE 모델과 환상의 궁합이라는 평. 큰 램 업그레이드한 맥에서 dense 모델 돌리는 건 훨씬 고통이라는 비교
  • 동료와 얘기하다가, 프로그래밍 지원용으로 LLM을 쓸 때 모델이 오히려 본질적인 최적화에서 벗어난 방향으로 발전 중이라는 결론. 나는 내부 규정상 거의 모든 작업을 로컬 4~30B 모델과 여러 GPT 시리즈 비교하는데, 특히 GPT-4o는 평균적으로 뛰어난 결과를 내지만, “응답 일부를 허구로 만드는” 성향도 있어 검증과 반복에 상당한 시간 투자 필요. 결과적으로 “저파라미터 로컬 모델과 노력 대비 차이가 생각보다 크지 않다”는 판단. 문제는 둘 다 정말 느려서 빠른 반복이 불가하다는 것. 난 품질 낮아도 응답이 번개처럼 즉각 오는 큰 컨텍스트 모델이 훨씬 편하다고 느낌. 실제 품질 평가 수치 향상 그 이상으로 “체감 반복 속도”가 중요하다는 바람
  • "느리고 비싸다"는 주장에 반대. DDR4 메모리 기반 구형 워크스테이션에서도 llama.cpp 활용하면 1000달러 내외 시스템으로도 초당 3토큰 뽑을 수 있다는 사례
    • 너가 실제 Deepseek 모델이 아니라 distill된 버전을 혼동하고 쓰는 것일수도 있다는 지적. 192GB RAM 이상이 없으면 진짜 모델 구동은 불가
답변달기