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

하드웨어별 속도 튜닝 및 서빙 레시피 요약

가중치, KV 캐시, 프리필 배치, 동시 요청과 가속 기능을 분리하고 균형·속도·긴 문맥 프로필로 제공합니다.

상세 페이지에서 프로필별 실행 명령, 적용값, 멈춰야 할 조건과 측정 순서를 확인할 수 있습니다. 실행 명령은 모델 파일과 실행 프로그램가 확인된 조합에만 표시합니다.

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

장비 선택기에서 현재 장비를 고르면 사용할 경로와 명령을 볼 수 있습니다. 데스크톱에서는 호환되는 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 serve Qwen/Qwen3.8-27B   --host 127.0.0.1   --port 8000   --max-model-len 8192   --gpu-memory-utilization 0.90

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

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

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

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

# 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
  }'

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

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

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

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

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

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

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