답변 속도와 가속
최종 업데이트
Qwen3.8-Flash-Next PLE 오프로드: RAM·SSD 조건과 실행 흐름
Flash-Next의 PLE 테이블을 SSD나 RAM에 두면 고속 메모리 압력을 줄일 수 있어요
PLE1 오프로드는 Qwen3.8-Flash-Next의 층별 임베딩(per-layer embeddings)을 RAM2이나 NVMe3 SSD4에 두고 필요한 값을 조회하는 경로예요. oMLX의 MLX5 경로와 단일 DGX Spark의 NVFP46·SGLang 구성은 서로 다른 실행 조합이에요. 모델 파일과 저장 여유를 확인하고, 적재·첫 요청·반복 요청의 시간과 메모리를 나눠 기록해요.
Flash-Next를 실행하려는데 GPU7 메모리가 부족하다면 가중치 중 무엇을 다른 저장 위치에 둘 수 있는지 살펴봐야 해요. PLE는 이 모델의 구성 요소라 전용 경로에서 따로 배치할 수 있어요. 적재가 가능해진 다음에는 테이블을 읽는 시간과 답변 생성 속도를 확인해요.
Flash-Next 모델의 PLE 테이블은 어떤 일을 하나요?
Qwen3.8-Flash-Next는 질문에 답할 때 코어 언어 모델과 PLE(per-layer embeddings, 층별 임베딩)를 함께 사용해요. 공개 구성은 약 180B 파라미터이며, 이 가운데 코어 LM 약 125B, PLE 약 51B, MTP8 관련 약 4B로 나뉘어요.
층별 임베딩은 각 모델 층이 토큰9 ID에 대응하는 임베딩 값을 조회하는 테이블이에요. 오프로드를 지원하는 실행기는 이 데이터를 고속 GPU 메모리에 모두 올리지 않고 시스템 RAM 또는 SSD에 둔 뒤 필요한 값을 읽어요. 코어 가중치의 형식을 바꾸는 양자화10와 임베딩 데이터의 배치는 별개 설정이에요. 먼저 코어 가중치가 어느 메모리에 올라가고 임베딩 파일이 어디에서 읽히는지 확인해요.
Prompt Lookup11도 n-gram12 후보 검색을 사용하지만 PLE와는 다른 기능이에요. Prompt Lookup은 앞선 입력과 출력에서 반복되는 토큰 패턴을 찾아 다음 토큰 후보로 제안해요. Flash-Next의 PLE는 모델 층에 연결된 임베딩 테이블을 실행 중 조회해요. 메모리가 부족한 환경에서 실행하려면 런타임13이 제공하는 PLE 오프로드 경로를 확인해요.
장비와 런타임에 따라 오프로드 위치를 골라요
전용 GPU PC에서는 PLE 테이블을 시스템 RAM에 두고 필요한 값을 GPU로 전달하는 지원 경로를 사용할 수 있어요. 이때 VRAM14과 시스템 RAM은 별도 용량으로 계획해요. Apple Silicon 맥은 CPU15와 GPU가 통합 메모리16를 공유하므로 시스템 전체 메모리에서 macOS와 실행기 사용량을 제외한 여유를 확인해요.
Qwen3.8-Flash-Next는 공개 모델명이고, 설정 파일의 model_type: qwen4_exp는 oMLX가 이 모델을 인식하는 내부 분류예요. oMLX 0.7.1.dev1에서는 Jundot/Qwen3.8-Flash-Next-oQ4e-mtp처럼 호환 MLX 체크포인트17를 받은 뒤 모델 설정의 qwen4_ple_ssd_offload를 켜요. 이 설정은 PLE를 SSD mmap 경로로 읽게 해요. 상주 적재가 모델 메모리 한도를 넘고 mmap 적재는 한도 안에 들면 자동으로 이 경로를 고를 수도 있어요.
설정 뒤 모델을 다시 불러오고 짧은 첫 요청을 보내요. 모델 로그에서 Qwen4-Exp와 PLE의 mmap/SSD 경로를 가리키는 항목을 찾아 선택된 실행 모드를 확인해요. 로그에 해당 경로가 나타나지 않거나 모델 로드가 실패하면 설정 저장 여부, 체크포인트 유형, 로그의 첫 오류를 살펴봐요. 처음 읽을 때와 같은 요청을 다시 보낼 때의 시간도 따로 기록해요.
| 환경 | PLE 배치 | 필요한 조합 |
|---|---|---|
| 전용 GPU PC | 지원되는 시스템 RAM | PLE RAM 기능을 제공하는 런타임과 체크포인트 |
| Apple Silicon Mac | oMLX SSD mmap | Flash-Next MLX 로더와 지원 배포본 |
| 단일 DGX Spark | SGLang file-backed PLE | nvidia/Qwen3.8-Flash-Next-NVFP4와 병합된 패치 |
SSD 여유와 페이지 캐시를 확인해요
SSD mmap은 큰 파일을 프로세스의 주소 공간에 연결하고 실제로 참조한 페이지를 읽는 방식이에요. 처음 테이블 페이지를 가져오는 동안 SSD 읽기 지연이 생길 수 있어요. 운영체제가 읽은 페이지를 RAM의 파일 캐시에 남기면 다음 접근은 빨라질 수 있지만, 다른 앱이 RAM을 더 쓰면 페이지가 밀려나 다시 저장장치에서 읽게 돼요.
처음 실행에서는 모델 적재 시간, 첫 요청 완료, 같은 요청을 반복했을 때 완료를 구분해 적어요. Mac에서는 활성 상태 보기의 메모리 압력과 SSD 활동을, GPU PC에서는 VRAM·RAM 사용량과 저장장치 읽기를 함께 확인해요. 첫 요청만 느리고 반복 요청은 빨라지는지, 매 요청마다 읽기가 반복되는지에 따라 메모리 여유나 파일 캐시의 영향을 짐작할 수 있어요.
참고: expert offload의 32K prefill 결과
2026년 10월 9일 공개된 oMLX 0.7.1.dev1 릴리스는 Qwen3.8-Flash-Next expert offload18의 32K prefill19 처리량20을 M3 Ultra에서 변경 전 396, 변경 후 636 tok/s로 기록해요. 이 수치는 expert 가중치 오프로드 변경의 비교이며, PLE 테이블을 SSD·RAM에 배치한 효과를 측정한 값은 아니에요.
내 장비에서 확인하려면 같은 Flash-Next 체크포인트, 32K 입력, 엔진 설정, 캐시 상태를 고정하고 첫 실행과 warm 반복 실행을 각각 재요. 프리필 처리량, 첫 토큰 대기, 답변 생성 속도는 항목별로 기록해요. SSD 캐시가 준비된 상태인지도 실행 기록에 함께 남겨요.
oMLX 릴리스에는 M3 Ultra의 Flash-Next group size 32 디코드21 비교도 있어요. MTP off는 39→91 tok/s, MTP on은 98→134 tok/s예요. 각각의 전후 조건을 구분해 해당 체크포인트와 MTP 조합을 시험할 때 비교 기준으로 활용해요.
| 작업·설정 | 장비 | 변경 전 → 후 |
|---|---|---|
| 32K prefill · expert offload | M3 Ultra | 396 → 636 tok/s (+61%) |
| group size 32 · 디코드, MTP off | M3 Ultra | 39 → 91 tok/s (+133%) |
| group size 32 · 디코드, MTP on | M3 Ultra | 98 → 134 tok/s (+37%) |
지원되는 경우 PLE와 MTP를 순서대로 시험해요
oMLX에서는 먼저 Flash-Next 호환 MLX 체크포인트의 qwen4_ple_ssd_offload 설정을 적용하고 모델 로그에서 mmap 경로를 확인해요. DGX Spark는 다른 실행 경로예요. SGLang에 병합된 패치는 nvidia/Qwen3.8-Flash-Next-NVFP4와 --ple-offload-embedding --ple-offload-backend file로 파일 기반 PLE를 사용해요. NEXTN을 추가할 때는 같은 패치의 --speculative-algorithm NEXTN 설정과 체크포인트를 따라요. oMLX 옵션을 Spark에 옮겨 쓰지 않아요.
PLE 경로를 확인한 뒤 첫 요청과 반복 요청을 기록하고, 같은 체크포인트에서 MTP를 지원할 때만 별도로 추가해요. oMLX는 모델 설정의 Lightning MTP를 켜고, DGX Spark는 해당 SGLang 패치의 NEXTN 구성에 따라요. 각 실행에서 모델 로드 성공, 첫 요청 완료, 반복 요청 완료를 확인한 다음 첫 토큰 대기와 생성 속도를 나눠 적어요.
모델이 적재되지 않으면 SSD 여유, 체크포인트 파일 구성, 실행 로그의 첫 오류를 확인해요. 적재는 되었지만 첫 접근에서 요청이 실패하면 메모리 여유와 파일 경로, 읽기 권한을 확인해요. 반복 요청이 느려지면 RAM 캐시가 밀렸는지와 다른 앱이 메모리를 얼마나 쓰는지 관찰하고, 우선 입력 길이와 동시 요청 수를 낮춰 다시 실행해요.
실제 요청이 끝나는 시간으로 확장 여부를 결정해요
평소 쓰는 모델이 필요한 질문에 답하고 다른 앱을 닫지 않아도 된다면, 이 모델을 실행하려고 RAM이나 SSD를 더 늘릴 필요는 없어요. Flash-Next가 필요한 구체적인 작업을 정하고, 짧은 질문과 긴 문서 요청을 같은 체크포인트에서 시험해요. 요청이 끝까지 완료되는지, 첫 토큰과 이후 생성에 얼마나 걸리는지 확인해요.
브라우저와 편집기를 평소처럼 켜 둔 상태에서도 반복해서 실행해요. 저장장치 여유뿐 아니라 테이블을 읽은 페이지가 RAM에 남는 상황과 밀려나는 상황을 각각 기록하면 SSD만 보고 성능을 예상하는 일을 줄일 수 있어요. 선택한 Flash-Next 체크포인트와 엔진 패치를 계속 관리해야 하는 비용까지 감당할 수 있을 때 오프로드 구성을 유지해요.
용어 각주
PLE 임베딩 테이블 — Per-Layer Embedding의 약자로, 모델의 특정 층에 임베딩 정보를 더하는 구조입니다. Qwen Flash-Next 계열은 n-그램 테이블을 사용하며, 지원되는 실행 경로에서는 이 테이블을 RAM이나 SSD로 오프로딩할 수 있습니다.
본문으로 돌아가기시스템 RAM — 프로그램이 실행되는 동안 데이터를 임시로 보관하는 시스템 메모리입니다.
본문으로 돌아가기NVMe — SSD가 PCI Express를 통해 통신할 때 사용하는 저장 장치용 프로토콜입니다.
본문으로 돌아가기SSD — 플래시 메모리를 사용하는 데이터 저장 장치입니다. 전원이 꺼져도 데이터가 보존됩니다.
본문으로 돌아가기MLX — Apple이 개발하는 머신러닝 프레임워크로, Apple Silicon의 CPU와 GPU가 공유하는 메모리를 활용해 모델을 실행합니다.
본문으로 돌아가기NVFP4 — NVIDIA가 정의한 4비트 부동소수점 데이터 형식입니다. 지원 여부는 GPU 세대, 모델과 소프트웨어 구현에 따라 다릅니다.
본문으로 돌아가기GPU — 많은 계산을 병렬로 처리하는 프로세서입니다. AI 모델 실행에서는 모델 계산을 맡습니다.
본문으로 돌아가기MTP — 한 번에 여러 미래 토큰을 예측하도록 학습하는 목표 또는 이를 수행하는 모델 구성입니다. 추측 디코딩에서는 이 예측을 후보 토큰으로 제안할 수 있습니다.
본문으로 돌아가기토큰 — 모델이 입력이나 출력을 나누어 처리하는 단위입니다.
본문으로 돌아가기양자화 — 모델의 가중치나 계산값을 더 적은 비트로 표현해 저장 공간과 메모리 사용량을 줄이는 방법입니다. 표현 단계가 거칠어져 정확도에도 영향을 줄 수 있습니다.
본문으로 돌아가기n-그램 조회 추측 — 입력 프롬프트나 생성 기록에서 반복되는 토큰 구간을 찾아 다음 토큰 후보로 제안하는 방식입니다. 문맥 조회로 후보를 만들어 별도 초안 모델 없이 사용할 수 있습니다.
본문으로 돌아가기n-그램 — 연속된 n개의 토큰 또는 항목으로 이루어진 구간입니다. 문맥 조회·추측 생성에 쓰일 수도 있고, 일부 모델에서는 임베딩 테이블의 구성 단위로도 쓰입니다.
본문으로 돌아가기런타임 — 프로그램이 실행될 때 필요한 기능을 제공하는 소프트웨어 환경입니다. 로컬 AI에서는 모델을 실행하는 엔진을 가리키기도 합니다.
본문으로 돌아가기VRAM — 그래픽카드의 GPU가 사용하는 메모리입니다. 모델 가중치와 계산 중간값을 저장합니다.
본문으로 돌아가기CPU — 운영체제와 일반 프로그램 명령을 실행하고, AI에서는 전처리·데이터 이동 등 범용 연산을 맡는 중앙 처리 장치입니다.
본문으로 돌아가기통합 메모리 — CPU와 GPU가 같은 물리 메모리 풀을 공유하는 구조입니다.
본문으로 돌아가기체크포인트 — 학습된 모델의 가중치 등을 저장한 파일입니다. 같은 모델 계열도 버전이나 용도에 따라 다른 체크포인트를 쓸 수 있습니다.
본문으로 돌아가기오프로딩 — 메모리가 부족할 때 모델 데이터 일부를 GPU 메모리에서 시스템 RAM이나 저장장치로 옮겨 처리하는 방식입니다. 데이터 이동이 추가됩니다.
본문으로 돌아가기프리필 — LLM이 입력 프롬프트를 읽고 각 토큰의 내부 표현을 계산하는 단계입니다. 입력이 길수록 처리할 토큰이 많아집니다.
본문으로 돌아가기처리량 — 일정 시간 동안 처리하거나 생성한 작업량입니다. 토큰/초, 요청/초처럼 단위를 함께 확인해야 비교할 수 있습니다.
본문으로 돌아가기토큰 디코드 — 입력과 앞서 만든 답변을 바탕으로 다음 출력 토큰을 차례로 생성하는 단계입니다.
본문으로 돌아가기
자주 묻는 질문
- 이 글에서 가장 먼저 확인할 것은 무엇인가요?
- PLE 오프로드는 Qwen3.8-Flash-Next의 층별 임베딩(per-layer embeddings)을 RAM이나 NVMe SSD에 두고 필요한 값을 조회하는 경로예요. oMLX의 MLX 경로와 단일 DGX Spark의 NVFP4·SGLang 구성은 서로 다른 실행 조합이에요. 모델 파일과 저장 여유를 확인하고, 적재·첫 요청·반복 요청의 시간과 메모리를 나눠 기록해요.
- 필요한 메모리는 어느 정도인가요?
- 층별 임베딩은 각 모델 층이 토큰 ID에 대응하는 임베딩 값을 조회하는 테이블이에요. 오프로드를 지원하는 실행기는 이 데이터를 고속 GPU 메모리에 모두 올리지 않고 시스템 RAM 또는 SSD에 둔 뒤 필요한 값을 읽어요. 코어 가중치의 형식을 바꾸는 양자화와 임베딩 데이터의 배치는 별개 설정이에요. 먼저 코어 가중치가 어느 메모리에 올라가고 임베딩 파일이 어디에서 읽히는지 확인해요.