DeepSeek-V4.1-Flash-1017 속도·품질, GB10 4대 측정

DeepSeek-V4.1-Flash-1017을 엔비디아 GB10 칩을 쓴 워크스테이션 네 대에 나눠 실행했다. 사고(모델이 답하기 전에 추론 과정을 쓰는 기능)를 끄면 한국어 요청 한 건이 초당 73.9토큰이었고, 사고를 끈 한국어 질문 19개에서 깨진 답은 없었다. 반면 CUDA 그래프 생성이 실패해 요청이 한꺼번에 실패한 날이 두 번 있었다. 실패한 요청은 모두 측정용이었고 직원 채팅 요청은 실패하지 않았다.

이 모델은 10월 17일 공개된 V4.1 Flash 개선판이다. 실행 방법은 Mia-AiLab이 GitHub에 공개한 레시피↗를 따랐다. 측정한 추론 엔진(모델을 실행하는 프로그램)은 직원들이 쓰는 업무용 AI 채팅 서비스가 실제로 쓰는 것이다. 레시피 저자(Mia-AiLab)의 수치는 레시피 문서 원문을 열어 확인했고, 측정하는 동안 다른 요청이 섞이지 않았는지 엔진의 연결 수로 확인했다.

측정은 2026년 11월 7일~11일에 했다. Dell Pro Max with GB10 네 대를 ConnectX-7 케이블로 고리 모양으로 연결했다. 이 기기는 Dell의 워크스테이션 라인 Pro Max에 속하고 NVIDIA DGX Spark와 같은 GB10 플랫폼(통합 메모리 128GB)을 쓴다. 이 글은 읽기 쉽게 GB10이라고 부른다. 각 표 근처에 조건을 적었다.

측정한 모델과 실행 구성

DeepSeek-V4.1-Flash-1017은 이미지 입력을 받고 문맥 길이가 100만 토큰인 MoE(전문가 혼합) 모델이다. 가중치는 FP8과 MXFP4 원본 그대로 약 510GB이며, 레시피는 이를 다시 quantization(양자화)하지 않는다고 밝힌다. 통합 메모리 128GB인 한 대에는 올라가지 않아 네 대에 나눠 올린다.

원본 약 510GB 가운데 약 203GB는 Engram이라는 큰 조회 표로, 엔진이 메모리에 올리지 않고 필요한 줄만 디스크에서 읽는다고 레시피가 설명한다. 나머지 가중치는 장비마다 약 80GiB를 메모리에 올린다. tensor parallelism(텐서 병렬)은 모델 한 벌을 여러 장비에 나눠 올리고 함께 계산하는 방식이다. 초안은 속도만 바꾸고 답은 바뀌지 않는다고 레시피 문서에 적혀 있다.

장비는 스위치 없이 케이블로 고리 모양으로 이었다. 이웃한 장비끼리만 케이블이 있어서 맞은편 장비 사이는 직결 케이블이 없고, 그 사이 통신은 중간 장비를 한 번 거친다. 장비 한 대에는 케이블이 두 개씩 꽂힌다(대표 이미지 오른쪽 사진). 텐서 병렬 4(TP=4)로 실행하려고 장비를 잇는 데 쓴 케이블은 ConnectX-7(장비의 네트워크 카드) 포트에 꽂는 QSFP DAC(구리 직결) 케이블이고, 케이블 규격의 최대 대역폭은 400Gbps다. 다만 장비 뒷면의 ConnectX-7 포트는 200Gbps급 QSFP 포트 2개다. 실제 통신 속도는 '긴 프롬프트를 읽는 속도' 절에 적었다.

CUDA graph(CUDA 그래프)는 GPU 작업 순서를 미리 기록해 두었다가 반복 실행해 실행 준비 시간을 줄이는 기능이다. 현재 운영은 그래프를 켠 상태이고, 이 기능이 실패한 일은 뒤에서 다룬다. 설정은 서비스에 쓰는 값이라 레시피 기본값과 다른 곳이 있고, 바꾼 변수와 이유는 '같은 조건으로 다시 측정하는 방법'에 적었다.

장비 네 대는 4,500만 원이 넘고, 온도 문제로 장소를 옮겼다

장비 구입 가격은 첫 한 대가 900만 원대, 나머지 세 대가 1,200만 원대이고 모두 저장공간 4TB 모델에 3년 AS를 추가한 값이다. 첫 한 대는 올해 초 가격이 오르기 전에 구입했고, 나머지 세 대는 오른 뒤에 구입했다. 장비 값만 4,500만 원이 넘는다. 장비끼리 잇는 케이블은 개당 10만 원이고 네 개를 썼다.

네 대의 온도를 관리하려고 다른 장소로 옮긴 뒤 엔진을 다시 띄웠고, 그때 ConnectX-7 펌웨어도 올렸다.

한국어 요청 한 건은 초당 73.9토큰, 동시 16건 합계는 초당 357.0토큰

사고를 끄고 보고서 문체로 설명해 달라는 한 문장짜리 요청을 보내 답을 600토큰으로 쓰게 했다. 엔진에 직접 요청했고 동시 요청 수마다 세 번씩 실행해 중앙값을 냈다.

건당은 요청 한 건의 첫 토큰 이후 생성 속도이고, 합계는 모든 요청의 토큰을 실행 전체 시간으로 나눈 값이다. 1건 행에서 건당이 합계보다 큰 것은 합계를 계산하는 시간에 첫 토큰이 나오기까지의 시간이 들어 있기 때문이다. 사용자 한 명이 느끼는 속도는 건당이며, 16명이 동시에 쓰면 초당 23토큰 안팎이 된다.

CUDA 그래프를 켜면 끈 때보다 건당 속도가 약 4~5% 빨랐다. GLM-5.3-Flash 2대 리뷰의 같은 방식 측정과 비교하면 요청 한 건의 속도는 약 1.8배, 동시 8건 합계는 약 2.8배다. 모델과 장비 수, 초안이 달라 같은 조건의 비교는 아니다.

영어 산문과 코드(답 800토큰)도 레시피 저자가 문서에 적은 조건으로 측정했다. 영어 산문은 사고를 켜고 온도 0.7, 코드는 사고를 끄고 그리디로 실행했다. 건당 속도는 레시피 저자 값의 90~103%였다(1·4·8건). 온도(temperature)는 답의 무작위성을 정하는 설정이고, 그리디는 매번 확률이 가장 높은 토큰만 고르는 방식이다.

초안이 모델의 답과 얼마나 맞는지에 따라 속도가 달라질 수 있어, 정형 코드나 번역처럼 초안이 잘 맞는 글이 빠르다. 번역 요청 3건과 채팅 요청 1건이 함께 실행된 6분 동안에는 채팅 한 건의 속도가 초당 18.5~21토큰이었다. 표의 값은 다른 요청이 없을 때의 값이다.

긴 시스템 프롬프트가 붙은 업무 채팅은 동시에 보내면 첫 토큰까지 4.5~6.5초

직원들이 쓰는 업무용 채팅의 실제 요청 모양으로 측정했다. 시스템 프롬프트(모든 요청 앞에 붙는 공통 지시문)는 약 10,037토큰이고, 이 부분은 계산 결과가 저장돼 있어 다시 읽지 않아도 되는 상태다. 요청마다 다른 메모 약 1,500토큰과 업무 질문이 붙고, 사고는 끄고 답은 700토큰이며 서비스 중계 프로그램을 거쳐 보냈다.

표의 값은 모든 요청을 같은 순간에 보낸 가장 나쁜 조건이다. 같은 시스템 프롬프트의 저장된 계산 결과를 여러 요청에서 동시에 다시 쓰는 일이 겹치면 일부 요청은 저장된 결과를 쓰지 못해 엔진이 1만 1천 토큰을 처음부터 읽는다. 이 요청도 오류 없이 끝난다. 원인은 뒤의 '일부 요청은 저장된 시스템 프롬프트를 쓰지 못하고 처음부터 다시 읽었다' 절에 있다.

긴 프롬프트를 읽는 속도는 32k 기준 초당 3,004토큰으로 레시피 저자 값보다 27% 낮았다

prefill(프리필)은 모델이 프롬프트를 읽어 첫 토큰을 내기 전까지 계산하는 단계다. 캐시에 없는 새 프롬프트(코드 묶음)를 보내고 답은 1토큰만 받아 프리필 시간을 측정했다. 4k~16k는 세 번, 그 위는 한 번 실행했다. 표에는 일부 구간만 싣는다.

이 표는 장비를 옮기고 엔진을 다시 띄운 뒤, ConnectX-7 펌웨어를 28.45에서 28.50으로 올린 상태에서 측정한 값이다. 올리기 전보다 8k 이상 구간에서 1~3% 올랐고, 32k는 2,945에서 3,004가 됐다. 레시피 저장소의 이슈 #55↗는 펌웨어 28.45인 장비 두 대에서 프리필이 약 1,300토큰으로 떨어졌다가, 28.50으로 올리자 3,060~3,315토큰이 됐다고 보고했다. 우리 장비는 28.45에서도 이미 2,945토큰이어서 같은 경우가 아니었다.

장비 사이 통신은 펌웨어를 올리기 전후 모두 연결 하나당 최고 111.86Gbps였다. 포트 표시 속도(200Gbps)에는 못 미치지만, NVIDIA 개발자 포럼↗에 인용된 ServeTheHome 설명도 포트 하나의 RDMA 쓰기 시험은 92~98Gbps, 두 포트를 함께 쓰면 185~190Gbps가 기대값이라고 하므로 같은 수준이다. 레시피 저자 값과 차이가 나는 원인은 찾지 못했다.

128k 프롬프트 16건을 동시에 보내면 가장 늦은 요청은 첫 토큰까지 12분이 넘게 걸렸다

세션마다 다른 128k 프롬프트를 한꺼번에 보내고, 모든 요청의 생성이 시작된 뒤 30초 구간의 속도를 측정했다. 사고를 켜고 온도 0.7이며 한 번씩만 실행했다.

첫 토큰까지의 시간에는 앞선 세션들의 프리필이 끝나기까지의 시간이 들어 있다. 레시피 저자는 미리 채운 문맥에서 측정했으므로 첫 토큰 시간은 비교하지 않는다. 건당 속도는 레시피 저자의 58.6·31.0·19.2토큰(1·4·8건)과 비슷했다.

사고를 끈 한국어 질문 19개에서 깨진 답은 없었다

GLM-5.3-Flash 리뷰와 같은 19문항, 같은 시스템 프롬프트(11,489자)를 온도 0, 사고 끔으로 보냈다. 지식·전략·이어 묻기·작성·함정 질문 등이 섞여 있고 답은 최대 4,096토큰까지 받았다. 한국어 10문항을 8번씩 온도 0.7로 320토큰까지 쓰게 해 다른 언어가 섞인 횟수도 세었다. 깨진 답은 본문에 깨진 글자(�)나 추론이 끝났음을 알리는 표시(</think>)가 들어 있는 경우로, GLM 리뷰와 같은 자동 검사로 셌다. 19문항 모두 정상 종료했고 본문에 사고 과정을 쓴 글은 없었다.

GLM 값은 레시피 11월 5일판 기준이고 최신판은 다시 측정하지 않았다. 두 모델의 장비 수와 양자화 방식이 달라 모델만의 차이는 아니다. 질문 19개는 빈도를 말하기에는 작은 표본이다.

사고를 켠 답에서는 한자·표 합계·반말 문제가 나왔다

사고를 켠 답도 따로 봤다. 사고 강도(low·high·max)는 사고 과정을 얼마나 길게 쓰게 할지 정하는 요청 설정이며 max가 가장 높다. 19문항을 high로 한 번, max로 두 번 실행했고, 다른 LLM 한 개가 어느 강도의 답인지 모르는 채 판정했다. max 두 번의 본문은 글자까지 같았다. 이 엔진은 seed(무작위 시작값)를 주지 않으면 같은 입력에 같은 응답이 나오기 때문이다. 판정에서 max는 한자 혼입 2곳, 표의 합계가 맞지 않는다는 지적 1건, 말투 2건을 받았고 high는 말투 2건을 지적받았다.

• 한자: LLM 서빙 최적화 설정 이야기 뒤에 「그럼 26b 모델을 31b 만큼의 성능으로 끌어올리는 방안은 없을까 ?」라고 묻자 답 본문에 「설명되는部分이」와 「추론 예算 예산 배분」처럼 한자가 섞였다.
• 표 합계: AI 전환 방향을 묻는 질문에 모델이 5개 축의 점수표를 만들었다. 숫자가 든 세 칸의 합은 12·15·10·8인데 합계 칸에는 18·22·15·10이 적혀 있었다. 나머지 두 축은 「낮음」「전사」 같은 말이라 합계가 맞는지는 표만으로 확인할 수 없다.
• 말투: 「AI-Native 로 가기위한 단계적 전략은 ?」이라는 질문의 답 전체가 「~다」체였고, 끝에서 「더 구체화하려면 다음 중 무엇을 알려주면 된다.」라며 사용자에게 반말을 했다.

사고를 끄면 셈 문제를 틀렸고, 사고를 켜면 토큰을 4~7배 썼다

사고를 끈 답이 틀린 셈 문제는 세 개였고 그중 두 개를 싣는다. 첫 번째는 「1부터 1000까지의 정수 중 3 또는 7의 배수이지만 21의 배수는 아닌 수는 몇 개인가? 답만 숫자로.」이고 정답은 381이다. 사고를 끄면 429를 답했고 사고를 켜면(high) 381을 답했다. 같은 문제에 「풀이는 짧게 하고, 마지막 줄에 정답: <값> 형식으로 답만 쓰세요.」를 붙이면 사고를 꺼도 맞혔다.

두 번째는 「1부터 2026까지의 정수 중 각 자리 숫자의 합이 7의 배수인 수는 몇 개인가?」이고 정답은 282다. 파이썬으로 검산한 값이다. 어려운 셈 문제 14개 가운데 사고를 끈 쪽이 틀린 것은 이 한 문항이다. 사고를 끈 답은 경우의 수를 실제로 세지 않고 어림해 넣었다.

사고를 켜면 이런 계산을 사고 단계에서 검산하는 대신 토큰을 4~7배 쓴다.

이미지 이해는 정답 단어 26개 중 24개를 맞혔고 도구 호출은 정상이었다

표, 차트, 스캔한 문서 이미지를 각각 두 번씩 보여 주고 정답 단어가 답에 들어 있는지 세었다. 26개 중 24개가 맞았다. 빠진 2개는 같은 차트의 정답 「25.8」로, 모델이 두 번 모두 「25.78%」라고 써서 글자가 달랐다. 값은 맞다(33/128 = 25.78%).

tool call(도구 호출)은 모델이 직접 실행하지 않고, 어떤 도구를 어떤 값으로 불러 달라는 내용을 응답으로 돌려주는 기능이다. 도구 두 개(현재 날씨를 조회하는 get_weather, 웹 검색 search_web)를 주고 「서울과 부산 날씨를 섭씨로 알려줘.」라고 요청하자 사고를 끈 상태에서 응답 한 개에 호출 두 건(서울, 부산)이 함께 나왔다. 서울 14도, 부산 18도라는 도구 결과를 돌려주자 「서울: 14°C, 맑음」「부산: 18°C, 맑음」으로 정리한 답이 나왔다.

엔진 내부 기능(CUDA 그래프) 생성이 실패하자 처리 중이던 요청이 모두 실패했다

엔진은 처리 중인 요청을 묶어 한 번에 계산하며 이 한 번을 라운드라고 한다. 계산 크기마다 그래프를 따로 만들고, 처음 나온 크기가 들어오면 그 크기의 그래프를 새로 만든다. 이 생성이 실패하면 그 라운드에 함께 있던 요청이 전부 실패한다. 이런 실패가 두 번 났다.

첫 번째는 11월 7일이다. 한 장비에서 그래프 생성이 실패한 뒤 새 그래프가 크기와 상관없이 전부 실패해, 3분 동안 요청 66건이 「안녕」 한 줄까지 오류(GraphCaptureFailed)로 끝났다. 재기동하자 정상이 됐다. 입력 길이와 동시 요청 수를 바꾼 32가지 조합으로 부하를 주고 시험했지만 재현되지 않았다. 그 장비의 커널 로그에는 GPU나 메모리 이벤트가 없었다.

두 번째는 11월 11일이다. 대화가 커져 65,536토큰을 넘어서자 다음 크기 구간(131,072)의 그래프를 한 장비가 처음 만들다 실패했고, 그 라운드에 생성 중이던 요청이 모두 실패했다. 실패한 장비에는 다른 용도의 모델 프로그램도 실행 중이어서 가용 메모리가 약 6GB였고, 메모리 부족이 원인일 수 있다.

실패한 요청은 두 번 모두 측정용이었다. 두 번째의 20건은 직원 채팅이 첨부 문서를 어떻게 처리할지 알아보는 시험 18건과, 긴 프리필 요청을 추가해 프리필 속도를 재던 중 함께 보낸 짧은 요청 2건이다. 직원 채팅 요청은 실패하지 않았고, 같은 시간대에 서비스에서 이 엔진으로 간 호출 3건은 모두 성공했다.

첫 실패 뒤에는 그래프를 끄고 이틀 동안 운영했다가, 잃은 속도 약 4~5%를 되찾으려고 다시 켜서 지금은 켠 상태로 운영한다. 끈 동안의 엔진 로그는 재기동하면서 지워져 효과를 로그로 확인하지는 못했다. 그래프를 끄면 같은 실패가 날 경로가 없을 것으로 보고, 끈 동안 서비스가 기록한 오류 가운데 답변을 만들지 못한 것은 없었다. 생각해 둔 대책은 두 가지다. 기동할 때 큰 구간의 그래프를 미리 만들어 두는 방법과, 그래프 생성에 실패하면 그래프 없이 실행하는 방법이다. 둘 다 시험하지 않았다.

일부 요청은 저장된 시스템 프롬프트를 쓰지 못하고 처음부터 다시 읽었다

엔진은 같은 앞부분(시스템 프롬프트와 이전 대화)의 계산 결과를 저장해 두고, 다음 요청은 그 뒤부터만 읽으면 되게 한다. 업무 채팅 측정에서 첫 토큰 시간이 회차마다 크게 달라져(동시 4건에서 1.7초부터 6초 넘는 값까지) 원인을 추적했다. 처음에는 저장 공간이 꽉 차서 결과가 지워진다고 보고 프롬프트 캐시를 0.5GiB에서 4GiB로 늘렸지만, 저장된 결과를 몇 번째 토큰부터 다시 썼는지의 분포가 0.5GiB와 4GiB에서 같아서 이 원인 추정은 맞지 않았다. 4GiB는 번역 같은 대량 요청이 대화 결과를 지우는 일을 막으려고 남겨 뒀다.

엔진 코드(TensorFold native)를 읽고 로그와 맞춰 보니 원인은 이렇게 보인다. 같은 저장 칸에 시스템 프롬프트의 결과를 다시 쓰면 그 칸을 함께 쓰던 더 긴 저장 결과가 무효로 표시되는데, 이 표시가 프롬프트 캐시 목록에 전달되지 않아 무효가 된 결과가 계속 선택된다. 그 결과를 다시 쓰는 데 실패하면 엔진은 더 짧은 유효한 결과를 쓰지 않고 처음부터 전체를 읽는다. 패치를 만들어 증상이 사라지는지는 확인하지 않았다.

한국어 업무 채팅에는 맞았고, 요청이 한꺼번에 실패하는 일을 점검해야 한다

사고를 끈 한국어 질문 19개에서 깨진 답이 없었고 요청 한 건이 초당 73.9토큰이어서, 직원들이 쓰는 한국어 업무 채팅에는 맞았다. 직원용 업무 채팅 서비스는 사고를 끈 모드를 기본으로 하고 필요할 때 사고를 켠 모드를 쓴다. 시험에서는 사고를 켠 max 답에 한자가 섞였고, 말투 문제는 max와 high 답에서 나왔다. 우리는 Gemma 4 26B부터 이 모델까지 여섯 모델을 차례로 써 왔다. 그동안 실제 사용 중에는 한자·반말이 섞인 답이나 셈 오류를 본 적이 없고, 이 모델도 만족하며 쓰고 있다. 이 관찰은 기록한 수치가 아니라 사용 경험이다.

GLM-5.3-Flash는 2대에서 한국어 질문 19개 중 4개에서 답이 깨졌고 한 건 속도는 초당 40.8토큰이었다. 두 모델은 장비 수와 양자화 방식이 달라 모델만의 차이는 아니며, GLM은 장비가 두 대이고 2,000만 원이 넘는 가격이어서 비용은 절반 수준이었다.

이 측정은 동시 16건까지만 다뤘다. 16명이 동시에 짧은 질문을 쓰면 한 명이 초당 23토큰을 받고, 긴 시스템 프롬프트가 붙은 업무 채팅 모양이면 초당 12.4토큰까지 내려가며, 그보다 많은 인원이 동시에 쓰는 경우는 측정하지 않았다. 숫자를 다루는 용도는 풀이를 쓰게 하거나 검산 단계를 둔다. 긴 프롬프트가 겹치는 용도도 맞지 않다(128k 프롬프트 16건은 첫 토큰까지 중앙값 6분 이상).

서비스 안정성에서는 CUDA 그래프 생성 실패가 가장 큰 위험이다. 두 번 모두 측정용 요청이었지만, 서비스 요청이 있을 때 같은 일이 나면 그 요청도 실패한다. 한 장비에서 한 번 실패하면 그 라운드의 요청이 모두 실패했고, 복구는 재기동뿐이었다. 지금은 그래프를 켜서 운영하므로 이 위험이 남아 있다. 그래프를 끄면 속도가 약 4~5% 내려가고, 실패가 나지 않을 것으로 보지만 실제 효과는 확인하지 못했다. 끈 이틀에도 실패가 없었고, 다시 켠 뒤 두 번째 실패까지 약 44시간에도 없었기 때문이다. 같은 엔진을 서비스에 쓰려면 실패한 요청을 다시 보내는 처리와 재기동을 알리는 감시를 갖추는 편이 안전하다.

같은 조건으로 다시 측정하는 방법

레시피 MiaAI-Lab/DeepSeek-V4.1-Flash-1017-4x-DGX-Sparks-TensorFold main 8ffa67d(11월 4일)를 사용했다. 레시피 기본값에서 바꾼 것은 아래와 같다.

나머지 변수는 레시피 기본이다. PARALLEL=16, CONTEXT=1048576, CUDA 그래프 켬(GRAPHS=1)이다. PARALLEL은 동시에 처리하는 요청 수다.

속도는 보고서 문체로 설명해 달라는 한 문장짜리 요청(답 600토큰, 사고 끔)을 엔진에 직접 보내 동시 요청 수마다 3회 중앙값을 냈고, 나머지 측정 조건은 각 표 근처에 적었다.

측정마다 엔진의 연결 수를 0.5초 간격으로 보고 다른 요청이 섞이지 않았는지 확인했다. 본문을 저장하지 않은 항목은 같은 요청을 다시 보내 기록을 복원했다. 이 엔진은 seed를 주지 않으면 같은 입력에 같은 응답이 나오므로 복원할 수 있었고, 복원한 답의 토큰 수와 정답이 처음 기록과 같은지 대조했다. 같은 장비에서 여러 엔진을 비교하는 방법은 Qwen3.8-Flash-Next 엔진 비교 리뷰에 있다.