Qwen3.8-Flash-Next 공개: 활성 6B인데 왜 180B를 담아야 하나

MoE 모델은 입력에 맞춰 일부 전문가 경로를 선택해 다음 토큰을 계산해요. 약 6B 활성 파라미터는 이때 토큰당 계산에 참여하는 규모를 나타내요. 하지만 다음 토큰에는 다른 전문가가 필요할 수 있으므로 실행기는 선택 가능한 전체 가중치에 접근해야 해요.

공개된 전체 구성은 코어 LM 약 125B, PLE 계열 테이블 약 51B, MTP 약 4B예요. 이 세 부분을 합친 규모가 약 180B이며, PLE와 MTP는 그 전체에 더해지는 별도 모델이 아니라 구성 요소예요. 따라서 6B로 적재 크기를 계산하면 실제로 준비할 가중치를 크게 놓칠 수 있어요.

전체 자료를 GPU⁶ 메모리에 담기 어렵다면, 지원되는 실행 경로에서 PLE 테이블을 RAM⁷이나 SSD에 두고 필요한 부분을 읽는 방식을 검토할 수 있어요. 고속 메모리에 항상 올려둘 양은 줄지만, 자료를 찾아 옮기는 단계가 추가되므로 실행 가능성과 응답 대기 시간을 따로 확인해야 해요.

MTP는 저장 위치가 아니라 토큰 생성에 관한 기능이에요. 다음 토큰 후보를 제안하고 본 모델이 확인하는 경로를 사용해요. 따라서 PLE를 SSD로 오프로드하는 설정과 MTP 지원 여부는 각각 런타임⁸에서 확인해야 해요.

SSD에서 필요한 내용을 처음 읽는 요청과 이미 읽은 자료가 캐시에 남아 있는 요청은 대기 시간이 다를 수 있어요. 첫 요청과 반복 요청을 나누어 실행 로그와 캐시 상태를 기록하면 팀의 평소 사용 조건에 가까운 판단을 할 수 있어요.

단일 Spark 실행 사례는 128GB 장비에 특정 NVFP4⁹ 체크포인트¹⁰와 PLE SSD 오프로드용 mmap 패치를 적용했어요. 이 경로를 재현할 때는 체크포인트와 패치, 실행기를 함께 준비해요. 구체적인 명령은 서빙 레시피에서 확인할 수 있어요.

DGX Spark의 128GB 통합 메모리¹¹는 CPU¹²와 GPU가 나누어 써요. GPU 쪽 자료를 호스트 RAM으로 옮겨도 물리 메모리가 늘어나지 않으며, SSD에서 읽은 페이지가 캐시에 남으면 그 캐시도 같은 메모리를 사용해요. 가중치, KV 캐시¹³, 실행기와 운영체제가 함께 쓸 공간을 따져야 해요.

재현을 확인할 때는 실행 설정과 로그에서 의도한 NVFP4 파일을 열었는지, PLE 조회가 패치를 거쳐 NVMe¹⁴ mmap 경로를 사용하는지 살펴봐요. 파일을 준비했거나 명령을 실행했다는 사실만으로는 해당 경로가 적용됐다고 볼 수 없어요. 서버를 재시작한 뒤 같은 요청이 처리되는지와 설정을 복구할 수 있는지도 확인해야 일상 운영 가능성을 판단할 수 있어요.

모델을 두 노드에 나누면 한 대에 담기 어려운 전체 구성을 배치할 여지가 생겨요. 다만 분할된 실행은 노드 간 통신을 더하므로 한 답변이 장비 수만큼 빨라지지는 않아요. 여러 요청을 동시에 처리하는 처리량¹⁵과 한 요청의 완료 시간은 별도로 재야 해요.

비교할 때 모델 파일과 양자화¹⁶, MTP 설정, 입력 길이, 동시 요청 수를 가능한 한 맞춰요. 단일 요청 완료 시간과 같은 시간 안에 끝난 요청 수를 함께 기록하면, 두 노드가 용량 문제를 해결했는지 처리량을 바꿨는지 구분하기 쉬워요.

NVFP4 체크포인트와 PLE mmap 패치를 시험하는 것이 목표라면 단일 Spark 경로가 연구 대상이 될 수 있어요. 매일 팀 질문을 처리하려면 업데이트 뒤 패치가 유지되는지, 캐시를 비우거나 프로세스를 다시 시작한 뒤 복구되는지, SSD를 쓸 때 첫 요청을 기다릴 수 있는지도 살펴야 해요.

256GB급 장비도 총용량만 보지 말고, 선택한 실행기가 전체 가중치와 동시 요청 캐시를 어디에 배치하는지 확인해요. 그런 다음 팀에서 자주 묻는 같은 코드 질문을 기존 모델과 나란히 실행해 수정안의 테스트 통과 여부, 첫 응답, 완료 시각을 비교해요. 필요한 파일을 접근 가능한 메모리에 둘 수 있고 대기와 관리 부담이 팀에 맞을 때 운영 후보로 볼 수 있어요.