veloGB10에서 Swift 1.5 구동 결과: 2× DGX Spark 환경에서 Flash-Next 대비 성능 분석

제 두 대의 DGX Sparks에서, veloGB10(https://github.com/sf-stav/veloGB10, sf-stav가 GB10 전용으로 만든 Rust/CUDA 엔진) 위에서 구동되는 Swift 1.5 (UkisAI가 Qwen3.8-Flash-Next를 추론 효율적으로 파인튜닝한 모델)를 사용하여 코딩 에이전트를 xhigh 노력 수준으로 실행했지만, 이전 vLLM NVFP4 환경에서 base Flash-Next를 medium 노력 수준으로 구동했을 때보다 더 빨리 완료되었습니다.

먼저 찾아봤는데, Velo에 대해 발표된 모든 자료는 하나의 패키지, 즉 공식 doth4580 EXL3를 사용하고 있었습니다. 그리고 NVIDIA 포럼이나 리포지토리의 이슈에서도 Swift나 다른 파인튜닝 모델을 그것으로 구동하는 사람을 찾을 수 없었습니다. 제가 시도해 본 첫 번째 커뮤니티 패키지(alesha-pro/Huihui-Qwen3.8-Flash-Next-abliterated-exl3-4bit-hq_h6_ng6)는 'ple shard 0 not in index' 오류와 함께 부팅에 실패했습니다. Swift 1.5의 EXL3 빌드는 동일한 레이아웃을 사용합니다: 현재 exllamav3 (1.5.x)는 모델의 51B 파라미터 n-gram 테이블을 ngram_embedding.safetensors 파일 내의 128개 샤드 텐서로 작성하는데, 이는 인덱스에 나열되어 있지 않습니다. velo는 하나의 큰 텐서(doth4580 레이아웃) 또는 인덱싱된 5-bit (K5) 샤드만 읽을 수 있으며, 4.05 패키지는 6-bit (K6)를 사용합니다. 이 문제에 영향을 받는 패키지를 확인하기 위해 제가 찾을 수 있는 모든 Flash-Next EXL3 패키지의 n-gram 헤더를 읽어봤습니다(헤더에 대한 HTTP 범위 요청만 했고, 데이터는 다운로드하지 않았습니다):
패키지 | n-gram 레이아웃 | velo v0.7.2 doth4580 4.05 / turboderp 4.05 | 하나의 텐서로 로드됨 (as shipped)
Swift 1.5 : SharkWipf 4.05 | 128개의 연속 샤드가 수정이 필요함 — 테스트 완료, 작동함
Swift 1.5: KatterMobile 4.05, SharkWipf 5.52, scorpoon 3.25, thelastspark 4.00 / 6.05 | 128개의 연속 샤드가 수정이 필요함
Huihui abliterated (alesha-pro 4.05) | 128개의 연속 샤드가 수정이 필요함 — 테스트 완료, 작동함
heretic 3.05 (andrevp, jeffpeng3), Uncensored 4.0 (Lygodactylus), groxaxo 3.50, turboderp 3.05 | 128개의 연속 샤드가 수정이 필요함

총 14개 빌드 중 12개가 이 수정이 필요하며, 여기에는 모든 Swift 1.5 빌드가 포함됩니다.

수정 방법: 제가 확인한 모든 패키지에서 128개의 샤드는 순서대로 나란히 배치되어 있습니다. 따라서 safetensors 헤더만 다시 작성하여 이를 하나의 텐서로 설명하는 것만으로도 velo의 단일 텐서 경로가 이들을 로드할 수 있게 만듭니다. 데이터는 복사되지 않으며, 헤더 길이는 동일하게 유지되고, 원래 헤더는 롤백을 위해 저장됩니다.

스크립트 및 세부 정보: https://github.com/sf-stav/veloGB10/issues/9 결과 (TP=2, 두 Sparks 모두 적용 후 수정 사항 반영) 지표 공식 doth4580 4.05 Huihui abliterated 4.05 Swift 1.5 (SharkWipf 4.05)
단일 스트림 디코드 110.6 tok/s 113.6 tok/s 110.2 tok/s
정상성 테스트 세트 (채팅, 코드, JSON, 도구 호출, 38.9K 회상) 5/5 5/5 5/5 MTP 초안 수락률 62–86% 44–84% 33–77%
세 모델 모두 동일한 속도로 실행됩니다. 수정 사항은 헤더 변경에 불과하므로 가중치나 커널에는 아무 차이가 없습니다. Swift가 velo에서 실제로 생각이 적게 할까요? doth4580 패키지에 포함된 22개 테스트 프롬프트에 대해 각각 3회 실행(중간 노력도, 동일한 샘플러 사용)했을 때, Swift 1.5는 공식 모델보다 8.2% 적은 토큰을 생성했습니다: 22개 중 16개 프롬프트에서 더 적었으며, 평균적으로 프롬프트당 −8.6% 감소했습니다. 출력 중 '사고'의 비중은 48%에서 42%로 떨어졌고, 총 시간은 11% 감소했습니다. 이는 실제 수치이지만 UkisAI가 주장한 63%와는 거리가 멀며, 후자는 제거해야 할 과도한 사고가 많은 높은 노력도(high effort)에서 측정된 것입니다. 중간 노력도에서는 기본 모델이 이미 생각을 짧게 유지합니다. 여전히 코딩을 할까요? 저는 사설 에이전트식 코딩 배터리 테스트를 실행했습니다: Claude Code가 실제 저장소 복사본에서 실질적인 도구 사용을 통해 모델을 구동하고, 테스트 오라클(test oracles)에 의해 평가되었습니다. 각 지표는 3회 실행되었습니다:
지표 공식 4.05 Huihui abliterated Swift 1.5
Swift 1.5 @ xhigh 노력도 중간 중간 중간 xhigh
일상 업무 (5개 작업 × 3) 15/15 15/15 15/15 15/15
어려운 함정 작업 (4개 작업 × 3) 10/12 7/12 7/12 11/12
일상 업무당 경과 시간 —* 232 s 199 s 371 s
어려운 작업당 경과 시간 —* 381 s 375 s 689 s
출력 토큰, 일상 업무 ×3 —* 56K 49K 100K
*공식 패키지의 실행 결과는 제 프록시 설정에서 스트리밍 버그에 걸려 경과 시간이 대략 두 배가 되었으므로, 해당 시간과 토큰은 제외했습니다. 성공/실패 결과에는 영향을 미치지 않습니다.
중간 노력도에서는 세 모델 모두 일상적인 코딩 성능이 동일합니다.

까다로운 세트(실제 실패 사례에서 구축된 작업: 거짓 정보를 담은 요약문, 잘못된 발견 사항이 포함된 코드 리뷰 등)에서는 두 파인튜닝 모델 모두 공식 팩에 대해 12개 중 7점/10점을 기록했으며, 놓친 과제도 동일했습니다. 저는 양쪽 실행에서 모델이 바이트 단위로 동일한 요청 매개변수를 받았는지 확인했으므로, 문제는 하네스(harness)가 아닙니다. Swift at xhigh는 7/12점에서 11/12점으로 향상하여, 이 배터리 테스트에서 어떤 모델을 사용하든 제가 얻은 최고의 결과입니다. 출력 토큰 수는 medium 대비 약 2배, 벽시계 시간(wall time)은 1.8배 걸렸습니다. 개선된 실패 사례는 실제 환경에서 비용이 많이 드는 유형들입니다: 단순히 언급하지 않고 형제 테스트 스위트(sibling test suite)를 깨뜨리는 것, 심어 놓은 잘못된 리뷰 발견 사항에 따라 행동하는 것과 그 범위를 벗어나서까지 수행하는 것, 날짜 범위에서의 오프-바이-원(off-by-one) 오류 등이 있습니다. 실패 사례는 '미러' 함정이었습니다: 기존 리그를 따라 새로운 리그를 추가하라는 요청을 받았는데, 이 과정에서 새 리그가 데이터를 가지고 있지 않은 튜닝 값을 복사해 버린 것입니다. 이것이 가장 어려운 시연된 작업이었으며, Swift at xhigh는 3번 중 2번 통과한 반면, 표에 있는 다른 어떤 설정도 한 번 이상 통과하지 못했습니다. velo에서는 이러한 추가적인 사고 과정 전체가 vLLM에서 Flash-Next가 medium으로 사용했을 때의 시간 범위 내에 들어왔습니다 (상단의 표 참조). 각 구성별로 12회 실행은 앞서 언급했듯이 작은 샘플이므로(Fisher p ≈ 0.4 for 10 vs 7, ≈ 0.15 for Swift xhigh vs Swift medium), '시사적'일 뿐 증명된 것은 아닙니다. 아직 xhigh에서 공식 또는 abliterated 팩을 실행해 보지 않았기 때문에, 이 점프 중 얼마나 많은 부분이 Swift 덕분이고 얼마나 많은 부분이 단순히 높은 노력(higher effort) 때문인지 아직 말씀드릴 수 없습니다. velo의 루프 감지기(loop detector)는 모든 배터리 실행에서 작동하지 않았습니다. 기준선 수치(공식 팩, TP=2) 단일 스트림 디코드: 110.6 tok/s (제가 vLLM NVFP4 설정으로 측정했던 9월의 약 52 tok/s와 비교). 첫 토큰까지 걸리는 시간 at 4K / 16K / 64K: 2.0 / 7.4 / 25.7초. 동시성이 문제입니다: 요청이 23개일 때는 번갈아 가며 처리합니다(합계 91 → 95 → 98 tok/s); 약 4개부터는 배치로 처리합니다(8개에서 157, 16개에서 181) 하지만 저자는 이번 주에 작업하고 있다고 말했습니다.

Gotchas TP=2와 f0 포트에 케이블을 연결했을 때: --rdma-dev rocep1s0f0,roceP2p1s0f0 (velo는 기본적으로 f1을 사용합니다). llama-benchy의 prefill t/s는 velo에 대해 잘못되었습니다(첫 번째 SSE 이벤트가 prefill 이전에 도착함); e2e TTFT를 사용하세요. OpenAI chat/completions만 사용하며, /v1/responses는 사용하지 마세요: litellm hosted_vllm/을 사용하고, openai/은 사용하지 마세요. --model-name은 EXL3 경로에서는 무시됩니다; 모델 ID는 패키지의 폴더 이름입니다. 크레딧: sf-stav (veloGB10), turboderp (exllamav3), doth4580, UkisAI (Swift), huihui-ai 그리고 표에 있는 모든 양자화 업로더들. 저는 로더 문제를 상위(upstream)에 제출했습니다 (https://github.com/sf-stav/veloGB10/issues/9) 따라서 패키지들이 결국 배포된 것처럼 로드될 수 있을 것입니다. /u/MushroomMan234가 제출함 [링크] [댓글]