NEW코딩일지 · 11.05코퍼스 메인에 주장 연구실을 세웠다: 사유고2 주장 29만 개를 자동 등록하고 스파크 두 대가 반증 조건까지 검토한다
← 학습
·4분

스파크 활용 · 8화

스파크 한 대당 동시 24개가 스윗스팟이었다: 짧은 일감 분당 32.4건, 32개부터는 처리량은 그대로고 실패만 늘었다

언내츄럴의 실제 합성 일감 두 종류로 동시 요청 1~32개를 쟀다. 짧은 일감은 동시 24개에서 분당 32.4건, 긴 일감은 7.85건으로 가장 많이 처리했고, 32개에서는 대기만 길어지고 긴 일감 64건 중 8건이 실패했다. 이 설정이면 상위 1,000개 회사의 사이클 설명은 6.1시간, 시대별 역사는 8.5시간이다.

#dgx-spark#qwen#vllm#throughput#concurrency

7화까지는 스파크 두 대가 사유고 책 지도를 만든 이야기였다. 지도를 다 만든 뒤 두 대는 미국 상장 종목 아카이브 ‘언내츄럴’의 합성 일을 받는다. 회사마다 주가 사이클을 설명하고 시대별 역사를 쓰는 일이다. 일을 넣기 전에 한 대에 요청을 몇 개씩 동시에 넣어야 가장 많이 처리하는지 쟀다. 모델은 Qwen3.8 Flash Next, 서버는 vLLM이다.

실제 합성 일감 두 종류로 동시 요청 1~32개를 쟀다

시험용 일감이 아니라 실제로 돌릴 일감을 그대로 썼다.

일감 입력 출력 개수
짧은 일감: 사이클 설명 근거 묶음 약 3천 자 JSON 약 300토큰 대형주 네 곳의 근거 묶음 141개
긴 일감: 시대별 역사 자료 약 1.6만 자 글 약 2천 토큰 한 회사 역사 자료를 잘라 만든 40개

단계마다 정해진 수만큼 처리할 때까지 동시 요청 수를 유지했고, 두 스파크를 동시에 따로 쟀다. 스윗스팟은 ‘최고 처리량의 95%에 닿는 가장 작은 동시 수’로 정했다.

처음에는 두 대 모두 vLLM의 동시 처리 상한(--max-num-seqs)이 16이었다. 그런데 16에서도 처리량이 계속 오르고 있었다. 그래서 2번 스파크를 상한 32로 다시 띄워 24와 32를 더 쟀다. 1~16에서 두 대의 차이는 2% 이내여서, 1번의 24·32는 2번 값과 같다고 봤다.

짧은 일감은 동시 24개에서 분당 32.4건으로 가장 많이 처리했다

2번 스파크 기준이다.

동시 분당 처리 초당 토큰(합계) 평균 대기 95% 대기 요청 하나 속도 오류
1 7.74건 36.1 7.7초 9.2초 36.3토큰/초 0
4 16.33건 75.7 14.1초 18.3초 20.0토큰/초 0
8 20.74건 101.5 22.0초 27.7초 13.5토큰/초 0
16 28.69건 132.4 31.2초 48.0초 9.3토큰/초 0
24 32.42건 147.0 41.0초 61.5초 6.9토큰/초 0
32 32.13건 147.1 55.9초 85.1초 5.1토큰/초 0

동시 1개에서 24개로 늘리자 처리량은 4.2배가 됐다. 대신 요청 하나가 받는 속도는 초당 36.3토큰에서 6.9토큰으로 떨어졌다. 24에서 32로 더 늘리면 처리량은 그대로인데 평균 대기만 41초에서 56초로 길어졌다.

긴 일감도 24개가 가장 많았고, 32개에서는 64건 중 8건이 실패했다

동시 분당 처리 초당 토큰(합계) 평균 대기 95% 대기 요청 하나 속도 오류
1 1.79건 36.8 33.6초 38.5초 36.8토큰/초 0
4 3.62건 83.1 61.9초 93.6초 22.5토큰/초 0
8 5.23건 112.6 83.3초 98.2초 15.5토큰/초 0
16 7.40건 150.8 117.3초 182.2초 10.6토큰/초 0
24 7.85건 163.2 160.3초 234.0초 8.0토큰/초 0
32 7.32건 149.7 191.0초 246.7초 6.4토큰/초 8

긴 일감은 32개에서 처리량이 오히려 줄었다. 64건 중 8건이 실패했는데, 긴 입력이 한꺼번에 몰려 처리 공간이 모자란 것으로 보인다. 24개에서는 실패가 없었다.

상위 1,000개 회사를 돌리면 사이클 설명 6.1시간, 시대별 역사 8.5시간이 걸린다

한 대당 동시 24개로 두 대를 함께 돌리면 짧은 일감은 분당 64.8건, 긴 일감은 분당 15.7건이다. 시가총액 상위 1,000개 회사에 적용하면 스파크 두 대가 순수하게 일하는 시간으로 사이클 설명 약 6.1시간, 시대별 역사 약 8.5시간이다. 이렇게 쓰려면 두 대 모두 동시 처리 상한을 32로 올려야 한다. 2번은 올렸고, 1번도 올린다.

27B 모델은 이번에 재지 않았다. 품질을 비교해야 하면 같은 일감으로 따로 잰다.

배운 것: 처리량이 멈추는 지점부터는 대기와 실패만 늘었다

동시 요청을 늘리면 한 요청이 받는 속도는 계속 떨어지지만, 서버 전체가 처리하는 양은 어느 지점까지 오른다. 이번에는 그 지점이 24였다. 그 뒤로는 처리량이 늘지 않고 대기와 실패만 늘었다.

서버 설정이 측정 범위를 가렸다. 상한이 16이었다면 16을 최적으로 착각했을 것이다. 처리량이 아직 오르고 있으면 상한부터 의심해야 한다.

스파크 활용 · 전 10화

  1. 1화DGX Spark의 Qwen3.8이 하루 딥리서치 31건을 썼다: 10월 1일 시황 뉴스를 한 건씩 조사한 보고서
  2. 2화DGX Spark는 한 건씩보다 다섯 건을 동시에 돌릴 때 빨랐다: 딥리서치 17건을 48분에 끝냈다
  3. 3화DGX Spark 2번을 한 시간 반 만에 1번과 똑같이 세웠다: 같은 시드 영상 313초 대 319초
  4. 4화DGX Spark 두 대가 책 704권을 나눠 정리한다: 속도가 달라 보인 건 원문을 읽던 순간이었다
  5. 5화DGX Spark를 두 대로 늘리자마자 엔비디아가 두 대를 묶으면 대역폭이 두 배라고 발표했다
  6. 6화DGX Spark 두 대가 24.6시간 만에 책 404권을 끝냈다: 글자로는 34.6%, 그 뒤 78권은 다시 돌린다
  7. 7화DGX Spark 두 대가 70시간 동안 책 지도 760권을 만들었다: 토큰 3억 5,800만 개, 함께 돌 때 초당 306토큰
  8. 8화스파크 한 대당 동시 24개가 스윗스팟이었다: 짧은 일감 분당 32.4건, 32개부터는 처리량은 그대로고 실패만 늘었다
  9. 9화맥스튜디오는 요청 하나에, 스파크는 일괄 작업에 강했다: 단독 51~66 대 37토큰, 최고 처리량 117 대 163토큰
  10. 10화맥·스파크·5090에서 돌려본 Qwen3.8 Flash Next