GPU가 너무 많은 변호사, 파트 4: 2018년산 V100 8개에서 구동하는 DeepSeek-V4.1-Flash. 코드 작업 시 200+
요약
본 기사는 DeepSeek-V4.1-Flash 모델을 8개의 V100 GPU에 분할 파이프라인으로 구성하여 구동한 기술적 성과를 다룹니다. 대용량 컨텍스트(최대 524,288 토큰) 처리 능력을 입증하며, 코드 작업 등 특정 유형에서 높은 속도와 안정성을 보여줍니다. 이는 LLM의 실제적인 고성능 배포 및 최적화 방법을 제시합니다.
핵심 포인트
- DeepSeek-V4.1-Flash를 8x V100 GPU에 분할 파이프라인으로 구성하여 구동함.
- 대용량 컨텍스트(최대 524,288 토큰) 처리가 가능하며 메모리 오버플로우가 없음.
- 코드 작업 시 32K 컨텍스트에서 200+ tok/s의 높은 속도를 기록함.
- RAG 데이터베이스 및 도구 호출 등 복합 워크플로우에 연결하여 사용 가능함.
샘 알트만에게 욕을 한다. 나는 내 여분의 용량을 지킬 것이다. V100 서버를 가진 변호사로부터의 업데이트 내용이다. 사흘 전, 나는 흥분해서 DeepSeek-V4.1-Flash를 V100 4개에서 3638 tok/s로 게시했다. 이는 내가 커스텀 커널 작업과 프리필 최적화를 수행하기 전이었다. 또한 8개에 걸쳐 시도해 볼 것이라고 말했었다. 실제로 그렇게 했다. 솔직히 결과는 정말 좋고 나에게 유용하다. 나는 이 모델을 블렌더에서 3D 섬을 그리거나, 웹 브라우저에서 게임보이 게임을 재창조하는 데 사용하지 않았다. 어설프게 애니메이션된 비디오를 만들게 하지도 않았고, 아무도 방문하지 않을 웹사이트의 버전 10개를 만들게 하지도 않았다. 나는 이 모델을 에이전트가 다른 에이전트를 위해 워크플로우를 실행하는, 또 그 결과물이 무언가를 만드는 구조물(build something that builds something else)을 구축하는 데 사용하고 있지 않다. 나만의 커스텀 하네스가 있지만, 당신은 그것에 관심 없을 것이라는 것을 안다. 숫자는 아래에 있으며, 내가 이 모델을 사용하는 작업의 유형과 함께 제시한다. 기본적으로, 나는 마침내 이전에는 프론티어 모델(frontier models)이 필요했던 작업량과 토큰들을 분리할 수 있게 되었다. 기존 LLM 워크플로우 중 5060%가 이 모델로 실행될 수 있으며, 속도는 채팅 창에서 Claude 코드가 보여주는 것과 일치한다. 나는 또 다른 DeepSeek 서버를 2개의 DGX Sparks에 가지고 있어 동시성과 핸드오프(handoff)가 가능하다. 나의 모든 RAG 데이터베이스, 도구 호출 등은 연결되어 작동한다. 내 Windows PC의 SSH를 통해 디스코드 스타일 인터페이스로 자연어 명령을 내릴 수 있다. 해냈다, 여러분. 실제로 존재하는 것이 진짜 일을 한다. 나에게 트로피를 줘라.
레포: https://github.com/ProprietaryLegal/Volta-sPLIt-DeepSeek-V4.1-Flash-1017-8xV100-SXM2-PP2xTP4
트위터: nicothegreco
Claude Code가 벤치마크를 실행하고 수치를 계산했으며, 이는 실제적이고 심층적인 내용이다. 아래를 참고하라. TL;DR: DeepSeek-V4.1-Flash-1017 (ISTA-DASLab의 2비트 GSQ-RCO IQ2_XXS GGUF)를 8개의 V100-SXM2-32GB에, 두 개의 NVLink 보드를 가로질러 텐서 4를 분할 파이프라인(split pipeline)으로 구성했다. 모든 248.8 GB의 가중치가 VRAM에 자리 잡고 있어: 디코딩 과정 중 어떤 전문가도 시스템 RAM에서 페이지 아웃되지 않는다.
요청당 524,288 토큰의 컨텍스트를 처리합니다. KV Cache 크기는 제 GPU에 남은 여유 공간을 고려할 때 3천만 개가 될 수 있지만, 실제 작업 실행에서는 일반적으로 총 컨텍스트가 200k를 넘지 않기 때문에 그 점을 자랑할 필요는 없었습니다. 코드: 프롬프트 1K 토큰 이후 215 tok/s, 32K에서 200, 128K에서 183, 256K에서 160입니다. JSON / 구조화된 데이터: 1K에서 203, 32K에서 207, 128K에서 197, 256K에서 180입니다. 법률 작성: 1K에서 118, 32K에서 117, 128K에서 111, 256K에서 103입니다. 산문(Prose): 길이에 따라 약 85-98, 채팅은 80-110 정도입니다. 프리필(Prefill): 1K에서 약 900 tok/s, 32K에서 1,900, 128K에서 2,200, 그리고 256K에서 측정되었습니다. 첫 토큰 생성 시간은 32K에서 17초, 128K에서 59초, 256K에서는 약 2분이 소요됩니다. 하드웨어는 두 개의 4카드 NVLink 보드에 장착된 8x Tesla V100-SXM2-32GB입니다. 이 두 보드는 NVLink가 아닌 PCIe를 통해 통신합니다. Threadripper PRO 3945WX, DDR4 256 GB, 카드당 NUMA 노드별 전력 제한은 150W이며 그래픽 클럭은 1522 MHz로 제한되었습니다. 네 개의 PLX PCIe 스위치가 사용되었으며, 각 GPU는 Gen3 x8에 연결되어 있고, 모든 스위치는 자체 CPU 루트 복합체(root complex)를 통해 Gen3 x16으로 연결됩니다. 저의 매우 전문적인 설정입니다. 소프트웨어 1Cat-vLLM의 DeepSeek-V4.1 패키지(#1277, 어려운 Volta 작업을 수행하는 부분)가 파이프라인 병렬 처리(pipeline parallel) 및 텐서 병렬 처리(tensor parallel) 2 x 4로 포팅되었습니다. 레이어 0-19와 Engram 테이블은 한 보드에 위치하고, 레이어 20-39, 헤드(head), 그리고 드래프터(drafter)는 다른 보드에 있습니다. Model Runner V2를 사용하며, 전체 CUDA 그래프를 활용합니다. 내장된 DSpark 드래프터가 라운드당 5개의 토큰을 추측합니다. 이후 약 사흘 동안 한 스위치를씩 조정했습니다. 모든 변경 사항은 이 장비에서 쌍으로 A/B 테스트(A/B)를 통과해야 했고, 비트 단위로 또는 근접한 동점 처리 범위 내에서 동일한 출력을 생성해야 했습니다. 발생했지만 언급하지 않으려는 것이 아니므로, 약 30가지의 아이디어가 실패했고 그 이유와 함께 리포지토리에 기록되어 있습니다. 이 수치들은 (2026-11-05 측정, 생각(thinking) 모드, greedy 방식, 출력 1,024 토큰, 무작위 캐시 솔트 적용으로 프리픽스 캐시에서 가져오는 것이 없도록 설정되었으며, 2회 실행의 평균값입니다.
두 실행의 Greedy 출력은 45개 중 45개 셀에서 바이트 단위로 동일했습니다.) 프롬프트 첫 토큰 프리필(prefill) tok/s | 코드 | JSON | 법률 | 산문 | 채팅
1K | 1.2 s | 820-948 | 215 | 203 | 118 | 89 | 95
8K | 6.9 s | ~1,180 | 208 | 209 | 109 | 92 | 108
32K | 17.2 s | ~1,900 | 200 | 207 | 117 | 90 | 107
64K | 30.9 s | 2,120 | 194 | 196 | 108 | 92 | 952.6개의 토큰을 제공합니다. 어느 쪽이든 엔진 속도는 동일하며, 텍스트가 결정합니다.
128K | 59.2 s | 2,200 | 183 | 197 | 111 | 91 | 963.8개가 수락되며, 라운드당 약 4.7개의 토큰이 생성됩니다. 제가 하는 글쓰기는 파이썬보다 예측 가능성이 낮은 것 같습니다. 법률은 약 1.6개, 산문은 약 1.2개가 수락되어, 라운드당 2.1
256K | 118.7 s | 2,200 | 160 | 180 | 103 | 84 | 81180 tok/s에 도달하며, 법률, 산문, 채팅은 'thinking' 비활성화 상태와 몇 tok/s 차이만 납니다. 코드가 법률 작성보다 두 배 빠른 이유: 초안 작성이 한 라운드마다 다섯 개의 토큰을 제안하고, 대규모 모델(big model)은 이 다섯 개를 한 번에 확인하기 때문입니다. 라운드당 비용은 몇 개가 수락되든 거의 동일합니다. 짧은 프롬프트 후 약 23ms, 256K 이후 약 27ms입니다. 코드와 JSON은 예측 가능하기 때문에 다섯 가지 추측 중 3.6
'thinking' 활성화 시, 코드와 JSON은 약 125
[성능 비교]
빌드 디코드 tok/s | 4x V100 | 스톡 1Cat 패키지(제 마지막 게시물) | 36-38 | 8x V100, 제 이전 EXL3 빌드 | 42-46 | 8x V100, PP2 x TP4 포트, 튜닝 없음 | 99 | 8x V100, 오늘 빌드 | ~135
이 수치들은 하나의 고정된 혼합 테스트 세트를 기반으로 합니다. 위 종류별 표는 다른 프롬프트를 사용합니다. 프리필(Prefill) 속도는 같은 3일 동안 약 두 배로 증가하여, 150K에서 약 1,350 tok/s에서 128K에서 2,200 tok/s에 도달했습니다.
품질 측면에서는 실제 작업에 사용하기 때문에(모두 서비스 빌드, thinking off, greedy 상태에서 측정): LegalBench: 22개 태스크에 걸친 0.716의 균형 정확도(1,292 항목, 공식 프롬프트 및 채점). MMLU-Pro: 79.9 % ±1.5 (700 항목: 14개 과목 각각에서 처음 50개, 5샷 Chain of Thought). HumanEval+: 플러스 테스트에서 89.6% (147/164), 기본 테스트에서 94.5%. 원본 모델과의 충실도: sudoingX의 KLD 패널을 사용하여 전체 정밀도(full-precision) 출시 버전의 참조 로짓(reference logits)과 비교.
서비스된 빌드는 일반 패널에서는 원본의 최상위 다음 토큰을 89.0%의 확률로, 법률 패널에서는 92.5%의 확률로 선택합니다 (KL 하한값은 각각 0.132와 0.156). 코드, 수학, 도구 호출 및 추출 작업에서 가장 근접하며(89-99%), 채팅, 창의적 글쓰기 및 다국어 작업에서는 가장 거리가 있습니다(81-86%). 이 격차는 속도 문제가 아니라 2비트 양자화(2-bit quant) 때문입니다. 저는 현재 제가 작성하는 프롬프트에 의해 어떤 전문가 모델(experts)이 활성화되는지 적극적으로 측정하고 있으며, 향후 해당 비트 가중치를 확장하기 위해 모델을 재보정할 계획입니다. 긴 컨텍스트 처리: 약 450K 토큰과 약 498K 토큰에서 총 6개의 니들 중 6개를 찾았으며, 4번의 시도 중 4번 모두 성공했습니다.
실제 사용 용도: 사무실을 벗어나지 않는 저의 개인 사건 파일에 대한 초기 검토 작업입니다. 저는 Claude Code 자체를 이 서버에 연결합니다 (Claude Code는 Anthropic's API를 사용하는 모든 서버와 통신할 수 있습니다). 이 시스템은 기록 폴더 전체를 읽고, 사실(facts), 날짜 및 숫자를 추출하며, 요약하고, 루틴한 초안 작성 작업을 시도할 수 있으며 도구 호출 기능이 작동합니다. 여기에 작성된 어떤 내용도 실제 검토 없이 외부로 나가지 않습니다. 오늘 파서에서 스트리밍 도구 호출 버그를 발견하고 수정했습니다 (인수가 두 번 전송되는 문제가 있었습니다). Claude Code의 도구 호출 테스트 스위트(tool-call test suite)는 이제 네 가지 모든 스트리밍/사고 모드에서 144개 중 144개를 통과합니다.
추가 작업: 한 번에 하나의 요청만 처리할 수 있습니다. 현재는 단일 사용자 서버입니다. 배치형 다중 요청 디코드(Batched multi-request decode) 기능은 테스트 박스에서 구축 및 확인되었으며, 각 요청은 단독으로 실행했을 때와 바이트 단위로 동일한 출력을 얻고 커널은 개별 호출보다 1.3~2.7배 빠르게 작동합니다. 하지만 실제 서버에 적용해야 합니다. 저의 예측으로는 네 개의 스트림에서 총 처리량(total throughput)이 약 1.8배가 될 것으로 보입니다. 이는 측정값이 아닌 예측이며, 실제 수치를 게시하겠습니다.
산문 및 법률 작성은 위에서 언급한 초안 작성자의 이유 때문에 코드 작업 속도의 절반 수준입니다. 256K 프롬프트는 첫 토큰이 나오기까지 약 2분이 걸립니다. '이 파일 전체를 읽어라'라는 요청에는 괜찮지만, 채팅에는 불편합니다. 마지막으로: 성공적인 부분들을 담은 19개의 풀 리퀘스트(pull requests)가 1Cat-vLLM에 열려 있으며, 각 새로운 속도 스위치는 기본적으로 비활성화되어 있습니다.
모든 것이 공개되었습니다: 런칭 설정(launch configs), 모든 A/B 테스트 및 각 셀의 원시 JSON(raw JSON) 파일, 그리고 작동하지 않은 목록까지 포함합니다. 저장소(Repo): https://github.com/ProprietaryLegal/Volta-sPLIt-DeepSeek-V4.1-Flash-1017-8xV100-SXM2-PP2xTP4 / 허깅 페이스 카드(Hugging Face card): https://huggingface.co/ProprietaryLegal/Volta-sPLIt-DeepSeek-V4.1-Flash-1017-8xV100-GGUF
공로 인정: yangzhuxinyzx와 1Cat-vLLM 팀원들: #1277 및 전체 Volta DeepSeek 경로, ISTA-DASLab의 양자화(quant) 수딩X(sudoingX): KLD 방법 및 일반 패널, Peuqui: #1263 및 일련의 패치, squibloads: #1341 Phil Tompkins (philbert440): V100 엔진 및 SM70 희소 프리필 어텐션(sparse prefill attention), Dennis Vertzyas (v100-skinny), TensorFold 및 DeepSeek
다음 목표: 한 번에 두세 개의 긴 요청 처리(제가 실제로 원하는 것, 이를 통해 Claude Code가 서브 에이전트(subagents)를 실행할 수 있음), 더 빠른 프리필(prefill), 그리고 전문가(experts)를 위한 고정밀 가중치. 제가 가장 많이 사용하는 법률 프롬프트에서 필요합니다. (PLI Labs는 회사의 자체 작업 결과물(work product)을 기반으로 구축된 사설, 온프레미스 AI를 위한 제 부업입니다. proprietarylegal.ai)
제출자: /u/TumbleweedNew6515 [링크] [댓글]
AI 자동 생성 콘텐츠
본 콘텐츠는 Reddit AI Engineering의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기