모델별 실행 레시피

Qwen3.8-27B 장비별 설정: Mac oMLX·RTX llama.cpp

Qwen3.8-27B를 띄웠는데 다른 사람의 기록보다 느립니다. 같은 모델 이름이어도 파일과 문맥, 실행 앱이 다르면 출발점이 다를 수 있습니다. 여기서는 Mac의 oMLX와 RTX의 llama.cpp 설정을 먼저 구분하고, 어디서 기다리는지 확인하며 하나씩 조정합니다.

실행 레시피

장비별 설정

한 사람이 사용할 때

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

가용 메모리: 56GB / 대역폭: 307GB/s

운용 프로필

Apple MacBook Pro M5 Pro (64GB)

메모리 적정

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

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

선택 프로필 문맥

16,384 토큰

런타임 문서 기반MBP M5 Pro 64GB · Q4 · 요청 1개

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

계산기 예상 디코드

13.9 ~ 15.4 tok/s

단일 사용자 예상치

계산기 예상 TTFT

36.0 ~ 41.9초

프리필: 392 ~ 456 tok/s

예상 메모리 점유

21.21GB / 56GB

남은 여유: 약 34.8GB

서버 주소

http://127.0.0.1:8000

로컬 전용 127.0.0.1

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

이 프로필의 실제 설정

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

MBP M5 Pro 64GB 실행 명령어 (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
먼저 이 설정으로 기준 속도를 기록한 뒤 아래 튜닝 순서를 따라 한 항목씩 바꿉니다.

실행 후 확인

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

바뀌는 점

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

한 항목씩 조정

속도를 올리는 순서

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

  1. STEP 1

    기준값 저장

    첫 입력과 캐시 재사용을 구분하고 각각 세 번 기록합니다. 프리필·디코드·피크 메모리를 함께 비교합니다.

    멈출 때: 오류가 있거나 메모리 여유가 2GB보다 작으면 다음 단계로 넘어가지 않습니다.

  2. STEP 2

    프리필 청크 조정

    1,024 → 2,048 → 4,096 순서로 올리며 긴 입력의 TTFT와 피크 메모리를 비교합니다.

    멈출 때: TTFT가 줄지 않거나 메모리 정점이 급증하면 직전 값으로 돌아갑니다.

  3. STEP 3

    KV 캐시 조정

    문맥이 부족할 때만 F16/BF16 기준값과 Q8 캐시를 같은 질문으로 비교합니다.

    멈출 때: 출력 차이가 생기거나 필요한 문맥이 이미 확보됐다면 기본 정밀도를 유지합니다.

  4. STEP 4

    MTP·투기 디코딩

    지원 모델에서만 켠 뒤 코드와 일반 문장을 나눠 수락률과 실제 디코드 tok/s를 측정합니다.

    멈출 때: 세 번의 중앙값이 기준보다 좋아지지 않으면 끕니다.

  5. STEP 5

    문맥 확장

    실제로 필요한 길이까지 두 배씩 늘리고 중간 정보 검색과 스왑 여부를 확인합니다.

    멈출 때: 검색 정확도가 떨어지거나 스왑·메모리 압축이 시작되면 한 단계 줄입니다.

내 장비 측정 기록 보내기

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

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

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

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

설정 오류 제보

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

전송할 설정 · MBP M5 Pro 64GB · Qwen3.8 27B · 균형 설정

Qwen3.8 27B · 4K

Qwen3.8 27B · 4,096토큰 입력 · 한 명이 사용하는 조건의 예상 결과입니다. 실측 기록이 아니라 속도 체험과 같은 계산값입니다.

첫 토큰은 답변이 시작되기까지의 기다림이고, 토큰 생성 속도는 그 뒤 글이 이어지는 속도입니다. 긴 문서를 넣는다면 두 수치를 함께 보세요.

Qwen3.8 27B · 4K
Qwen3.8 27B · 4K

Mac mini M4 32GB · Qwen3.8 27B

양자화: Q4_K_M · 가속: none · 토큰 생성: 5.1 ~ 5.7 tok/s · 첫 토큰: 16.4 ~ 35.5초

입력 처리: 116 ~ 252 tok/s · 필요한 메모리: 17.6GB · 사용 가능 메모리: 27GB

Mac mini M4 Pro 48GB · Qwen3.8 27B

양자화: Q4_K_M · 가속: none · 토큰 생성: 12.3 ~ 13.7 tok/s · 첫 토큰: 7.8 ~ 14.3초

입력 처리: 289 ~ 530 tok/s · 필요한 메모리: 17.6GB · 사용 가능 메모리: 41GB

RTX 4090 24GB · Qwen3.8 27B

양자화: Q4_K_M · 가속: none · 토큰 생성: 38.3 ~ 51.9 tok/s · 첫 토큰: 2.6 ~ 3.6초

입력 처리: 1,141 ~ 1,591 tok/s · 필요한 메모리: 17.6GB · 사용 가능 메모리: 22.5GB

내 파일과 실행 앱부터 맞춥니다

장비 선택기에서 현재 장비를 고르면 사용할 경로와 명령을 볼 수 있습니다. 데스크톱에서는 호환되는 Q4 GGUF 또는 MLX 변환본을 기준으로 확인합니다. 약 17GB대라는 파일 크기 안내는 출발점일 뿐 실제 다운로드와 실행 점유를 확인해야 합니다.

공식 BF16 모델 ID를 서버에 넘기는 경로는 같은 Q4 파일을 여는 것이 아닙니다. 27B 가중치만 단순 계산해도 약 54GB 규모이며 작업 공간이 더 필요합니다. 아래 공식 서버 예시를 24GB GPU의 Q4 명령처럼 복사하지 마세요.

텍스트 질문부터 정상 실행한 뒤 이미지 입력과 추가 가속을 확인합니다. 첫 로드에서 모델 파일과 비전·MTP 지원을 동시에 바꾸면 어느 부분 때문에 실패했는지 찾기 어렵습니다.

내 파일과 실행 앱부터 맞춥니다
내 파일과 실행 앱부터 맞춥니다

잘 되는 설정을 하나 남깁니다

Mac oMLX와 RTX llama.cpp의 명령은 위 장비 선택기에 맞춰 사용합니다. 요청은 한 개로 두고 표시된 문맥에서 시작하세요. 더 큰 문맥이나 공격적인 메모리 설정으로 바로 넘어가기보다 정상 답변을 남기는 것이 먼저입니다.

준비 실행 뒤 프리필, 첫 토큰 시간, 디코드와 피크 메모리를 세 번 기록합니다. 처음 읽는 문서는 입력 캐시가 재사용되지 않았는지 확인하고, 같은 입력의 반복 결과는 따로 남깁니다. 이후 청크나 캐시 정밀도를 바꿀 때 이 기록으로 돌아와 실제 이득을 판단합니다.

아래 vLLM 명령은 공식 가중치를 담을 수 있는 별도 NVIDIA 서버 경로입니다. 선택기의 데스크톱 명령과 혼합하지 마세요. 서버는 우선 127.0.0.1에만 두고 다른 기기에서 접근시킬 계획이면 인증과 접근 제한을 별도로 준비합니다.

공식 vLLM 서버 구동 (BF16 가중치)
vllm serve Qwen/Qwen3.8-27B   --host 127.0.0.1   --port 8000   --max-model-len 8192   --gpu-memory-utilization 0.90
공식 BF16 가중치와 런타임 여유가 확보된 NVIDIA 서버에서 127.0.0.1로 실행합니다.

서버가 켜진 것과 답변이 되는 것은 다릅니다

모델 목록을 확인해 실제로 로드된 식별자를 요청에 넣습니다. oMLX는 이 가이드의 8000, llama.cpp는 8080처럼 선택한 명령의 주소를 사용해야 합니다. 아래 예시 주소와 다르면 그 부분을 맞춘 뒤 짧은 질문을 보내세요.

답변이 조각으로 도착하는지, 생각 과정과 최종 답이 앱에서 구분되는지 확인합니다. 생각 토큰을 오래 생성하는 경우 화면에 최종 문장이 늦게 보일 수 있습니다. 이 시간을 순수 프리필로 잘못 기록하지 않도록 서버 로그도 함께 봅니다.

기본 질문이 완료되면 평소 문서를 보내보세요. 짧은 인사말에서 나온 최고 tok/s보다 그 문서의 첫 답변과 완료 시간이 실제 사용에 더 가깝습니다.

API 엔드포인트 헬스체크 및 챗 요청 검증
# 1. 로드된 모델 목록 확인
curl -N http://127.0.0.1:8000/v1/models

# 2. OpenAI 호환 챗 완성 API 호출
curl -N http://127.0.0.1:8000/v1/chat/completions   -H "Content-Type: application/json"   -d '{
    "model": "<local-model-identifier>",
    "messages": [
      {"role": "user", "content": "로컬 LLM 서빙의 장점을 세 가지로 요약해줘."}
    ],
    "temperature": 0.6,
    "max_tokens": 1024,
    "stream": true
  }'
oMLX는 8000, llama.cpp는 8080 포트를 사용합니다. 실행한 런타임에 맞춰 주소를 바꿉니다.

느리다면 먼저 어느 구간인지 봅니다

입력을 넣은 뒤 오래 기다리면 프리필 청크와 입력 길이, 캐시 상태를 확인합니다. 답변이 시작된 뒤 느리다면 CPU로 넘어간 가중치가 있는지, 메모리 압박이나 스왑이 생겼는지 봅니다. 두 문제를 MTP 단계 수 하나로 해결하려고 하면 원인을 놓칠 수 있습니다.

지원되는 파일과 런타임에서 MTP를 켠 뒤에는 같은 질문으로 기본값과 비교합니다. 평균 승인 길이가 낮거나 검증 비용이 크면 켜도 이득이 없을 수 있습니다. 캐시 정밀도와 MTP를 한 번에 바꾸지 마세요.

원하는 긴 문맥에서 메모리가 부족하다면 우선 요청 수와 길이를 줄여 돌아갈 기준을 확보합니다. 계속 필요한 작업에서만 한계가 반복되는지 확인한 뒤 상위 메모리 구성을 검토합니다.

좋은 기록보다 계속 쓸 설정을 남깁니다

코드 수정과 문서 요약을 모두 한다면 두 종류의 질문을 남겨보세요. 한쪽에서만 빨라지는 설정도 있습니다. 속도뿐 아니라 실제 결과의 오류와 실행 실패 여부를 함께 확인해야 합니다.

마지막으로 모델 파일·앱 버전·문맥·가속 옵션을 저장합니다. 업데이트 뒤 문제가 생겨도 정상 구성을 되찾을 수 있습니다. 처음부터 가장 빠른 숫자를 찾기보다 내 작업이 끝까지 되는 설정을 만든 뒤 속도를 올리는 편이 유지하기 쉽습니다.

좋은 기록보다 계속 쓸 설정을 남깁니다
좋은 기록보다 계속 쓸 설정을 남깁니다

NVFP4로 실행하려면

호환 NVFP4 커널이 필요합니다. Spark 실측과 RTX 추정은 구분합니다.

vLLM / SGLang · Inferact/Qwen3.8-27B-NVFP4

수정 내역

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

  1. Mac의 모델 형식과 실행 설정 정정

    Mac의 MLX 실행 경로를 GGUF Q4_K_M과 구분하고, 엔진 이름·모델 형식·명령의 표기를 맞췄습니다. 명령에서 지정하지 않는 KV 캐시 정밀도와 프리필 배치는 모델·런타임 설정에서 확인하도록 바꿨습니다.

    명령이 그대로인데 배치만 커진 것처럼 보이던 MLX 속도 프로필도 제거했습니다.

  2. Qwen 27B Spark 설정에서 다른 엔진의 옵션 제거

    단일·이중 Spark의 SGLang 설정에 llama.cpp 전용 투기 디코딩 옵션이 붙지 않도록 수정했습니다. DFlash2·DSpark 구성은 각 전용 모델과 실행 경로를 유지합니다.

  3. 첫 입력과 캐시 재사용의 기록 분리

    검증 순서에서 처음 읽는 입력과 같은 입력을 반복한 결과를 따로 기록하도록 바꿨습니다. 캐시 효과를 프리필 처리량이나 장비 차이로 합산하지 않습니다.

  4. 장비·프로필 저장과 다시 열기 추가

    실행 가능한 프로필은 장비와 함께 이 브라우저에 최대 5개까지 저장하고, 가이드 목록에서 다시 열 수 있게 했습니다. 저장한 뒤 공개 설정이 바뀌거나 프로필이 없어지면 실행 전에 다시 확인하도록 안내합니다.

  5. 실행 엔진 설명으로 이어지는 링크 추가

    설정에 표시된 엔진 이름에서 해당 실행 프로그램의 설명으로 이어지도록 했습니다. 엔진이 확인되지 않은 경로에는 임의의 프로그램을 연결하지 않습니다.