이 글에서 가장 먼저 확인할 것은 무엇인가요?

Qwen3.8-Flash-Next는 프롬프트와 긴 문맥을 받아 텍스트를 생성하는 모델이에요. 단일 DGX Spark에서 이 레시피를 재현하려면 전용 NVFP4 체크포인트, PLE 테이블의 NVMe 오프로드 패치, SGLang 설정, MTP 값이 함께 맞아야 해요. 다운로드·준비·실행을 거친 뒤 로그에서 각 경로가 적용됐는지 확인해요.

모델별 실행 레시피

최종 업데이트 2026-10-31

Qwen3.8 Flash-Next DGX Spark 설정: SGLang·PLE·MTP 레시피

DGX Spark 한 대에서 Qwen3.8 Flash-Next를 실행해요

Qwen3.8-Flash-Next는 프롬프트¹와 긴 문맥을 받아 텍스트를 생성하는 모델이에요. 단일 DGX Spark에서 이 레시피를 재현하려면 전용 NVFP4² 체크포인트³, PLE⁴ 테이블의 NVMe⁵ 오프로드 패치, SGLang 설정, MTP⁶ 값이 함께 맞아야 해요. 다운로드·준비·실행을 거친 뒤 로그에서 각 경로가 적용됐는지 확인해요.

먼저 어느 구성을 재현하는지 정해요. 공개 스크립트의 32K 단일 요청 프로필과 긴 문맥 시험은 메모리 비율과 프리필⁷ 청크가 달라요. 모델 이름이 같아도 실행 조건은 달라요. 이 안내는 특수한 PLE 오프로드 경로를 설치하고 적용 여부를 확인하는 순서예요.

실행 조건과 핵심 내용

공개 실행 스크립트는 메모리 비율 0.85, 프리필 청크 2,048, 32K 문맥에서 시작해요.
262K 단일 요청 구성은 메모리 비율 0.79와 프리필 청크 1,024를 사용해요.
MTP steps 3과 draft tokens 4는 다른 설정이고, NVFP4 가중치와 BF16 KV 캐시도 구분해요.

장비별 실행 설정으로 이동

체크포인트와 PLE 오프로드 경로를 함께 준비해요

이 레시피는 Qwen3.8-Flash-Next의 특정 NVFP4 체크포인트를 사용해요. 모든 텐서를 똑같이 4비트로 줄인 파일이라는 뜻은 아니에요. 어텐션⁸과 MTP처럼 더 높은 정밀도로 유지하는 부분도 있으므로 전체 파일과 실제 적재를 확인해요.

Spark의 통합 메모리⁹는 CPU¹⁰와 GPU¹¹가 공유해요. 큰 PLE 테이블을 NVMe에 두고 필요한 항목을 조회하는 전용 mmap 패치가 이 구성의 핵심이에요. stock SGLang에 옵션만 추가하면 같은 메모리 배치가 되지 않아요. 테이블 전체를 매번 메모리에 올리지 않아도 되지만, 요청마다 필요한 항목을 찾고 이동하는 시간이 생겨요.

저장소와 패치 파일은 버전과 내용을 살펴보고 운영 환경과 분리해 준비해요. 다운로드와 변환용 임시 공간도 필요해요. 스크립트의 약 140GB 이상 NVMe 여유 공간 안내를 출발점으로 삼되, 현재 내려받는 파일의 크기를 다시 확인해요. NVMe의 저장 공간과 실행 중 페이지 캐시·다른 프로세스가 사용할 메모리는 별도로 살펴야 해요.

손의 초록색 블록이 여러 블록 조합과 설정 카드로 갈라지는 도식 — 체크포인트와 패치, 실행 설정을 함께 맞춰 같은 구성을 만들어요.

32K 단일 요청 프로필로 먼저 서버를 실행해요

공개 스크립트는 TP 1, 메모리 비율 0.85, 프리필 청크 2,048에서 시작해요. 프리필 백엔드는 Triton, 디코드¹² 백엔드는 trtllm_mha예요. MTP는 NEXTN 3단계, top-k 1, draft token¹³ 4개로 설정돼요. 이 값은 재현할 프로필이지 공개 측정 당시 모든 조건이 확인됐다는 뜻은 아니에요.

첫 명령 묶음은 저장소와 가중치를 받고, 패치된 환경을 준비한 뒤 서버 포트를 로컬 주소에만 게시해요. Docker와 약 140GB 이상의 NVMe 여유가 필요해요. 준비가 끝나면 verify.py로 서버 응답을 확인해요. 실행 시 scripts/serve.sh 파일은 저장소가 제공하는 설정을 읽어 실행하므로, 다른 지점의 파일과 섞지 않도록 경로를 확인해요.

다운로드와 준비는 첫 터미널에서 진행하세요. 서버를 시작한 뒤에는 로그가 나오는 터미널을 그대로 두고, 저장소 폴더에서 새 터미널을 열어 python3 verify.py를 실행해요. 아래 명령 끝의 검증 요청도 이 두 번째 터미널에서 보내면 돼요.

단일 DGX Spark 32K 실행 준비와 서버 확인

git clone https://github.com/hashd1ve/qwen38-flash-next-one-dgx-spark.git
cd qwen38-flash-next-one-dgx-spark

./scripts/download.sh
./scripts/prepare.sh
sed -i.bak 's/-p "$PORT":30000/-p "127.0.0.1:$PORT:30000"/' scripts/serve.sh
MEMFRAC=0.85 PREFILL=2048 CTX=32768 ./scripts/serve.sh
# In a second terminal opened in this repository folder:
python3 verify.py

다운로드와 준비 뒤 포트를 로컬에만 게시하고, 32K 서버에 검증 요청을 보내요.

공개 스크립트의 SGLang 핵심 설정

# Publish the Docker port only on 127.0.0.1:30000
--tp-size 1
--prefill-attention-backend triton
--decode-attention-backend trtllm_mha
--quantization modelopt_fp4
--ple-offload-embedding
--mamba-radix-cache-strategy extra_buffer
--mem-fraction-static 0.85
--chunked-prefill-size 2048
--max-running-requests 4
--speculative-algorithm NEXTN
--speculative-num-steps 3
--speculative-eagle-topk 1
--speculative-num-draft-tokens 4
--speculative-draft-model-quantization unquant

PLE mmap 패치가 없는 stock SGLang에는 이 옵션만으로 같은 메모리 배치가 적용되지 않아요.

긴 문맥에서는 문맥 상한과 프리필 청크를 함께 조정해요

긴 문맥용 프로필은 메모리 비율 0.79와 프리필 청크 1,024를 사용해 메모리 정점에 여유를 두는 출발점이에요. 공개된 긴 문맥 측정은 메모리 비율 0.85와 요청 한 개 조건이므로 아래 실행 묶음은 그 측정의 정확한 재현 명령이 아니에요. 문맥 상한을 262,144로 설정할 수 있어도 모든 장비와 문서에서 그 길이를 안정적으로 처리한다는 뜻은 아니에요.

짧은 입력부터 정상 작동을 보고 8K·32K·128K처럼 단계적으로 늘려요. 각 길이에서 답을 아는 문장을 문서 중간에도 넣어 실제로 찾는지 확인해요. 프리필 청크를 줄이면 메모리 정점을 낮출 수 있지만 짧은 입력 처리량¹⁴이 낮아질 수 있어요. 청크 크기는 한 번에 처리하는 묶음을 조정할 뿐 전체 입력 토큰을 없애지는 않으므로, 뒤쪽 근거까지 답에 반영되는지도 살펴요.

단일 요청 프로필은 여러 요청의 동시 처리량을 측정한 결과가 아니에요. 동시 요청을 늘리면 각 요청의 프리필과 KV 캐시¹⁵가 장치 자원을 나눠 써요. 먼저 요청 하나로 문맥 길이별 메모리와 첫 토큰 대기를 확인하고, 실제 운영에 동시성이 필요할 때 별도로 시험해요. CTX=262144는 서버의 허용 상한이며 실제 전송한 입력 길이와 분리해 기록해요.

예를 들어 긴 회의 기록에서 중간에 나온 결정 날짜를 찾아야 한다면, 입력을 늘릴 때마다 그 날짜를 원문과 대조해요. 앞부분만 맞고 중간이나 뒤쪽 조건을 놓친다면, 서버 설정값뿐 아니라 해당 근거가 입력에 포함됐는지도 확인해요. 설정 가능한 최대 문맥과 실제 문서 작업 성공을 같은 기준으로 보지 않아요.

긴 문맥 설정으로 바꿀 때는 먼저 서버 터미널에서 Ctrl+C로 이전 서버를 종료하고, 컨테이너도 종료됐는지 확인하세요. 아래 블록은 저장소의 상위 폴더에서 연 새 터미널 기준이에요. 이미 저장소 안에 있다면 cd 줄을 건너뛰세요. 새 서버가 준비된 뒤 검증 요청은 저장소 폴더의 다른 터미널에서 실행해요.

단일 DGX Spark 262K 문맥 시험

# Run after completing the download, preparation, and local port setup above
# Server address: http://127.0.0.1:30000
cd qwen38-flash-next-one-dgx-spark
sed -i.bak 's/--max-running-requests 4/--max-running-requests 1/' scripts/serve.sh
MEMFRAC=0.79 PREFILL=1024 CTX=262144 ./scripts/serve.sh
# In a second terminal opened in this repository folder:
python3 verify.py

프리필 청크를 줄이는 대신 짧은 입력의 처리량은 낮아질 수 있어요.

색 블록이 담긴 용기에서 큰 수납장과 나뉜 블록으로 화살표가 이어지는 장면 — 문맥 상한뿐 아니라 프리필 청크와 요청 수를 함께 설정해요.

실행 경로와 답변 결과를 확인한 뒤 속도를 비교해요

준비가 끝나면 실행 로그에서 의도한 NVFP4 체크포인트와 PLE 파일이 열렸는지, 프리필·디코드 백엔드가 선택됐는지 확인해요. 설정 화면의 값과 실제 경로가 다르면 런타임¹⁶이 기본 경로를 사용했을 수 있어요. 적용 로그를 먼저 확인하면 패치가 적용되지 않은 문제와 올바른 경로에서 성능이 기대와 다른 문제를 구분할 수 있어요.

공개 스크립트의 허용 동시 요청 수는 실제로 겹쳐 보낸 요청 수와 같지 않아요. 먼저 요청 하나로 서버가 의도한 문서를 처리하는지 확인해요. Docker 포트가 127.0.0.1에만 게시됐는지도 점검해요. 공유 서버로 바꾸려면 접근 통제와 방화벽을 별도로 준비해요.

공개 실행 기록에서는 영어 코드 약 41.5 tok/s, 스페인어 일반 문장 약 22.8 tok/s가 보고됐어요. 언어와 답변 유형이 다른 기록이라 서로 직접 빼거나 나눠 비교하지 않아요. 프리필 1,910 tok/s 기록은 원문이 입력 캐시 재사용에 따른 측정 오염을 알렸고 캐시를 비운 반복 시험이 끝나지 않아 비교 기준에서 제외해요. tok/s는 해당 조건에서의 생성 구간 기록이지 한국어 PDF 요청의 전체 완료 시간은 아니에요.

다음 표는 별도의 oMLX 0.7.0 보고서에서 Qwen3.8-Flash-Next oQ4e, temperature 0, Lightning MTP, TurboQuant KV 8비트, aggressive 메모리 가드로 측정한 결과예요. 각 지점은 한 번 실행한 단일 Mac 결과이므로 DGX Spark의 SGLang 실험과 같은 설정으로 비교하지 않아요.

좌우로 밀어 표 전체를 비교하세요.

별도 Mac·oMLX 실행 기록의 측정 조건
문맥	프리필	디코드	기록
4K	4,949 tok/s	143.8 tok/s	oMLX code_python, 최대 출력 128토큰
16K	5,701 tok/s	보고되지 않음: 모델이 16토큰 전에 멈춤	한 지점에서 한 번 실행
32K	5,672 tok/s	114.6 tok/s	M5 Ultra 256GB, 80코어 GPU

M5 Ultra oMLX 0.7.0 벤치마크와 조건

긴 문서를 넣으면 속도는 어떻게 바뀔까요? — M5 Ultra 256GB · Flash-Next oQ4e · oMLX 0.7.0.dev2 · MTP 3 — 모델이 메모리에 올라간 뒤의 공개 기록입니다. SSD 로딩 시간은 포함하지 않았습니다.

문서 입력과 블록 처리가 서버 기계와 점검표로 이어지는 작업 흐름 — 의도한 PLE·프리필·디코드 경로가 적용됐는지 확인한 뒤 작업을 비교해요.

이 레시피가 필요한지 실제 작업으로 정해요

특수 패치로 큰 모델을 Spark 한 대에 올리는 일과 매일 편하게 쓰는 일은 목표가 달라요. 원하는 문서나 코드를 실제로 처리하고, 끝까지 걸린 시간과 메모리 상태를 확인해요. 이미 안정된 단일 Spark 구성으로 업무가 끝난다면 두 번째 장비를 추가할 이유는 줄어들어요. 더 긴 문맥이나 여러 동시 요청이 꼭 필요하다면 그 조건을 별도 시험해요.

마지막으로 NVFP4 파일, PLE 적재 방식, 실행 엔진이 같은 조합인지 기록해요. 다른 모델 파일로 바꾸면 PLE가 메모리에 올라가는 방식과 필요한 공간이 달라질 수 있어요. vLLM·SGLang에서 NVFP4 배포본을 고를 때도 체크포인트와 엔진이 지원하는 형식을 맞춰 확인해요.

PLE SSD 오프로드와 M5 Ultra 메모리 판단

NVFP4 배포본을 실행할 때 확인해요

NVFP4에서 PLE 테이블이 어떤 방식으로 적재되는지는 실행 엔진과 패치에 따라 달라요. Spark 단일 노드에서는 전용 오프로드 경로가 적용됐는지 로그를 확인해요. vLLM과 SGLang용 배포본을 선택할 때는 다운로드한 nvidia/Qwen3.8-Flash-Next-NVFP4 체크포인트가 해당 엔진과 맞는지 먼저 살펴요.

용어 각주

프롬프트 — 모델에 보내는 입력문입니다. 생성 모델에서는 만들 결과를 설명하는 문장이 되어 출력의 구성과 내용을 크게 좌우합니다.
본문으로 돌아가기
NVFP4 — NVIDIA가 정의한 4비트 부동소수점 데이터 형식입니다. 지원 여부는 GPU 세대, 모델과 소프트웨어 구현에 따라 다릅니다.
본문으로 돌아가기
체크포인트 — 학습된 모델의 가중치 등을 저장한 파일입니다. 같은 모델 계열도 버전이나 용도에 따라 다른 체크포인트를 쓸 수 있습니다.
본문으로 돌아가기
PLE 임베딩 테이블 — Per-Layer Embedding의 약자로, 모델의 특정 층에 임베딩 정보를 더하는 구조입니다. Qwen Flash-Next 계열은 n-그램 테이블을 사용하며, 지원되는 실행 경로에서는 이 테이블을 RAM이나 SSD로 오프로딩할 수 있습니다.
본문으로 돌아가기
NVMe — SSD가 PCI Express를 통해 통신할 때 사용하는 저장 장치용 프로토콜입니다.
본문으로 돌아가기
MTP — 한 번에 여러 미래 토큰을 예측하도록 학습하는 목표 또는 이를 수행하는 모델 구성입니다. 추측 디코딩에서는 이 예측을 후보 토큰으로 제안할 수 있습니다.
본문으로 돌아가기
프리필 — LLM이 입력 프롬프트를 읽고 각 토큰의 내부 표현을 계산하는 단계입니다. 입력이 길수록 처리할 토큰이 많아집니다.
본문으로 돌아가기
어텐션 — 입력 토큰 사이의 관련도를 계산해 각 위치의 정보를 현재 표현에 반영하는 신경망 연산입니다.
본문으로 돌아가기
통합 메모리 — CPU와 GPU가 같은 물리 메모리 풀을 공유하는 구조입니다.
본문으로 돌아가기
CPU — 운영체제와 일반 프로그램 명령을 실행하고, AI에서는 전처리·데이터 이동 등 범용 연산을 맡는 중앙 처리 장치입니다.
본문으로 돌아가기
GPU — 많은 계산을 병렬로 처리하는 프로세서입니다. AI 모델 실행에서는 모델 계산을 맡습니다.
본문으로 돌아가기
토큰 디코드 — 입력과 앞서 만든 답변을 바탕으로 다음 출력 토큰을 차례로 생성하는 단계입니다.
본문으로 돌아가기
토큰 — 모델이 입력이나 출력을 나누어 처리하는 단위입니다.
본문으로 돌아가기
처리량 — 일정 시간 동안 처리하거나 생성한 작업량입니다. 토큰/초, 요청/초처럼 단위를 함께 확인해야 비교할 수 있습니다.
본문으로 돌아가기
KV 캐시 — 어텐션에서 이전 토큰의 키·값을 저장해 다음 토큰 생성 때 재사용하는 메모리입니다. 문맥 길이와 배치 크기에 따라 용량이 달라집니다.
본문으로 돌아가기
런타임 — 프로그램이 실행될 때 필요한 기능을 제공하는 소프트웨어 환경입니다. 로컬 AI에서는 모델을 실행하는 엔진을 가리키기도 합니다.
본문으로 돌아가기

자주 묻는 질문

이 글에서 가장 먼저 확인할 것은 무엇인가요?: Qwen3.8-Flash-Next는 프롬프트와 긴 문맥을 받아 텍스트를 생성하는 모델이에요. 단일 DGX Spark에서 이 레시피를 재현하려면 전용 NVFP4 체크포인트, PLE 테이블의 NVMe 오프로드 패치, SGLang 설정, MTP 값이 함께 맞아야 해요. 다운로드·준비·실행을 거친 뒤 로그에서 각 경로가 적용됐는지 확인해요.
필요한 메모리는 어느 정도인가요?: Spark의 통합 메모리는 CPU와 GPU가 공유해요. 큰 PLE 테이블을 NVMe에 두고 필요한 항목을 조회하는 전용 mmap 패치가 이 구성의 핵심이에요. stock SGLang에 옵션만 추가하면 같은 메모리 배치가 되지 않아요. 테이블 전체를 매번 메모리에 올리지 않아도 되지만, 요청마다 필요한 항목을 찾고 이동하는 시간이 생겨요.

실행 레시피

장비별 설정

한 사람이 사용할 때

사용할 장비를 고르면 실행 명령과 조정할 옵션이 나옵니다.

튜닝 대상 장비 선택

가용 메모리: 114GB / 대역폭: 546GB/s

운용 프로필

Apple Mac Studio M4 Max (128GB)

메모리 적정

권장 런타임: oMLX (MLX 4비트 (GGUF Q4_K_M과 별도 형식)) · 문서화된 런타임 설정

설치 직후 처음 실행하거나 매일 안정적으로 사용할 때

선택 프로필 문맥

8,192 토큰

런타임 문서 기반Studio M4 Max 128GB · Q4 · 요청 1개

런타임 문서에 따른 시작 설정입니다. 아래 순서로 조정하며 속도를 비교하세요.

계산기 예상 디코드

34.2 ~ 48.1 tok/s

단일 사용자 예상치

계산기 예상 TTFT

8.8 ~ 17.1초

프리필: 479 ~ 936 tok/s

예상 메모리 점유

약 107.55GB / 114GB

남은 여유: 약 6.5GB

서버 주소

http://127.0.0.1:8000

로컬 전용 127.0.0.1

예상치는 계산기의 추천 양자화·가속과 8,192토큰 기준입니다. 위 실행 설정의 실측값은 아닙니다.

이 프로필의 실제 설정

적용값	왜 이렇게 잡았나
가중치MLX 4비트 (GGUF Q4_K_M과 별도 형식)	MLX 모델 디렉터리를 사용합니다. GGUF의 Q4_K_M과 같은 파일 형식이 아닙니다.
입력 길이 확인8,192	요청 전 모델 설정의 입력 제한을 확인합니다. 이 실행 명령은 문맥 길이를 지정하지 않습니다.
KV 캐시모델 설정에서 확인	이 실행 명령은 KV 캐시 정밀도를 지정하지 않습니다.
프리필 배치런타임 설정에서 확인	llama.cpp의 batch-size와 ubatch-size를 MLX 설정값으로 대신 쓰지 않습니다.
동시 요청1	한 요청의 속도를 확인합니다. 여러 요청의 합산 처리량과 구분합니다.
메모리 여유2GB 이상	모델을 불러온 뒤 실제 메모리와 스왑 여부를 확인합니다.

Studio M4 Max 128GB 실행 명령어 (oMLX)

Apple Silicon · MLX 모델 · 메모리 가드

MODEL_DIR="$HOME/.omlx/models"
omlx serve \
  --model-dir "$MODEL_DIR" \
  --host 127.0.0.1 \
  --port 8000 \
  --max-concurrent-requests 1 \
  --memory-guard balanced

먼저 이 설정으로 기준 속도를 기록한 뒤 아래 튜닝 순서를 따라 한 항목씩 바꿉니다.

실행 후 확인

01서버 시작 로그에서 모델 적재 완료와 실제 컨텍스트 길이를 확인합니다.
02준비 실행 뒤 요청은 하나씩 보냅니다. 길이가 같은 서로 다른 입력 세 개로 첫 입력 처리 시간을 기록합니다.
03같은 입력을 반복한 결과는 캐시 재사용으로 따로 기록합니다. 첫 입력 결과와 합치지 않습니다.
04프리필 tok/s, 디코드 tok/s, 피크 메모리를 함께 기록한 뒤 한 항목씩만 바꿉니다.

바뀌는 점

문맥과 동시 요청을 보수적으로 잡아 장비의 최대 처리량보다 낮게 나올 수 있습니다.

운용 시 유의사항

PLE n-gram 테이블의 RAM·SSD 배치에 따라 적재 메모리가 달라집니다. 속도 화면에 표시된 배치와 메모리 여유를 기준으로 문맥을 잡습니다.

한 항목씩 조정

속도를 올리는 순서

여러 값을 한꺼번에 바꾸면 원인을 찾기 어렵습니다.

STEP 1
기준값 저장
첫 입력과 캐시 재사용을 구분하고 각각 세 번 기록합니다. 프리필·디코드·피크 메모리를 함께 비교합니다.
멈출 때: 오류가 있거나 메모리 여유가 2GB보다 작으면 다음 단계로 넘어가지 않습니다.
STEP 2
프리필 청크 조정
1,024 → 2,048 → 4,096 순서로 올리며 긴 입력의 TTFT와 피크 메모리를 비교합니다.
멈출 때: TTFT가 줄지 않거나 메모리 정점이 급증하면 직전 값으로 돌아갑니다.
STEP 3
KV 캐시 조정
문맥이 부족할 때만 F16/BF16 기준값과 Q8 캐시를 같은 질문으로 비교합니다.
멈출 때: 출력 차이가 생기거나 필요한 문맥이 이미 확보됐다면 기본 정밀도를 유지합니다.
STEP 4
MTP·투기 디코딩
지원 모델에서만 켠 뒤 코드와 일반 문장을 나눠 수락률과 실제 디코드 tok/s를 측정합니다.
멈출 때: 세 번의 중앙값이 기준보다 좋아지지 않으면 끕니다.
STEP 5
문맥 확장
실제로 필요한 길이까지 두 배씩 늘리고 중간 정보 검색과 스왑 여부를 확인합니다.
멈출 때: 검색 정확도가 떨어지거나 스왑·메모리 압축이 시작되면 한 단계 줄입니다.

내 장비 측정 기록 보내기

같은 조건으로 3회 이상 측정한 JSON을 가져오세요. 전송 버튼을 누르기 전에는 이 브라우저에서만 확인합니다.

장비·모델·실행 조건과 측정값만 받습니다. 질문·답변·원본 로그·파일 경로는 넣지 마세요.

기록 파일이 없다면, 실행 중인 로컬 서버에서 측정 도구로 만들 수 있습니다. Node.js 20 이상이 필요하며 결과를 자동 전송하지 않습니다.

측정 방법 읽기 측정 도구 받기 장비·설정 양식 받기

측정 JSON 가져오기 (최대 32KB)

검토한 이용자 제출 기록입니다. 이 사이트의 직접 측정과는 구분합니다.

설정 오류 제보

선택한 설정에서 막힌 부분을 알려주세요. 제보는 관리자만 확인합니다.

전송할 설정 · Studio M4 Max 128GB · Qwen3.8-Flash-Next · 균형 설정

수정 내역

사이트의 안내가 바뀐 기록입니다. 설치된 엔진·모델 버전을 자동으로 확인한 결과는 아닙니다.

2026-09-06
Flash-Next 본문과 실행 프로필의 설정값 통일
본문의 프리필 청크를 공개 스크립트와 같은 2,048로 고치고 긴 문맥 명령에도 요청 상한 1개를 반영했습니다. 공개 측정의 언어 조건과 안전한 시작값을 구분했습니다.
2026-09-06
Flash-Next 단일 Spark의 프리필 수치 정정
캐시 재사용이 섞인 1,910 tok/s를 첫 입력의 프리필 속도로 제시하던 문구를 제거했습니다. 캐시를 쓰지 않은 조건의 재측정이 필요한 상태로 바꿨습니다.
2026-09-06
Flash-Next 긴 문맥의 요청 상한 조정
단일 Spark의 262K 문맥 명령에서 실행 요청 상한을 4개에서 1개로 낮췄습니다. 오래된 QSA 패치의 출력 오류를 확인하도록 검증 순서도 보완했습니다.
2026-09-06
Mac의 모델 형식과 실행 설정 정정
Mac의 MLX 실행 경로를 GGUF Q4_K_M과 구분하고, 엔진 이름·모델 형식·명령의 표기를 맞췄습니다. 명령에서 지정하지 않는 KV 캐시 정밀도와 프리필 배치는 모델·런타임 설정에서 확인하도록 바꿨습니다.
명령이 그대로인데 배치만 커진 것처럼 보이던 MLX 속도 프로필도 제거했습니다.
2026-09-06
첫 입력과 캐시 재사용의 기록 분리
검증 순서에서 처음 읽는 입력과 같은 입력을 반복한 결과를 따로 기록하도록 바꿨습니다. 캐시 효과를 프리필 처리량이나 장비 차이로 합산하지 않습니다.
2026-09-06
장비·프로필 저장과 다시 열기 추가
실행 가능한 프로필은 장비와 함께 이 브라우저에 최대 5개까지 저장하고, 가이드 목록에서 다시 열 수 있게 했습니다. 저장한 뒤 공개 설정이 바뀌거나 프로필이 없어지면 실행 전에 다시 확인하도록 안내합니다.
2026-09-06
실행 엔진 설명으로 이어지는 링크 추가
설정에 표시된 엔진 이름에서 해당 실행 프로그램의 설명으로 이어지도록 했습니다. 엔진이 확인되지 않은 경로에는 임의의 프로그램을 연결하지 않습니다.