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