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

Mac의 oMLX는 MLX 변환 체크포인트를 실행하고, RTX의 llama.cpp는 GGUF를 읽어요. 같은 Qwen3.8-27B 이름이 붙어도 파일 형식은 서로 바꿔 쓸 수 없어요. 기준 파일로 Mac에는 mlx-community/Qwen3.8-27B-4bit, RTX에는 ggml-org/Qwen3.8-27B-GGUF의 Q4_K_M을 사용해요. Q4_K_M 파일은 약 17.6GB급이지만 실제 메모리는 실행 중 KV 캐시⁶와 작업 버퍼만큼 더 필요해요.

RTX 24GB에서는 문맥 4,096토큰으로 시작하고 브라우저나 편집기를 함께 쓸 메모리도 남겨요. Mac은 통합 메모리⁷ 총량과 메모리 압력을 확인해요. 두 장비에서 같은 요청을 사용해야 실행 차이를 비교할 수 있어요.

Apple Silicon 맥에서 oMLX를 열고 모델 폴더를 지정해 서버를 시작해요. 모델 검색에서 MLX 체크포인트 mlx-community/Qwen3.8-27B-4bit를 내려받은 뒤 브라우저에서 http://localhost:8000/admin/chat을 열어요. 모델을 선택하고 다음 요청을 그대로 보내요: Python에서 경로 문자열을 받아, 파일이 없으면 None을 반환하고 파일이 있으면 UTF-8 텍스트를 읽는 함수를 작성해 주세요. 입력과 반환 형식도 설명해 주세요.

정상이라면 작성한 Python 코드와 입력·반환 형식 설명이 대화 화면에 나타나요. 실패하면 관리 화면에서 모델 상태와 다운로드 완료 여부를 보고, 메모리 압력과 서버 로그의 첫 오류를 확인해요. 모델 목록에 없다면 MLX 체크포인트 형식과 지정한 모델 폴더를 살펴봐요.

CUDA⁸ Toolkit이 준비된 RTX PC에서 아래 명령으로 CUDA 지원 llama.cpp를 빌드하고 서버를 시작해요. 마지막 줄의 -hf는 GGUF 저장소와 Q4_K_M을 지정하고, -ngl all은 가능한 모델 층을 GPU⁹에 올려요. -c 4096은 문맥을 4,096토큰으로 설정해요. 아래 경로 ./build/bin/llama-server는 Linux 셸 기준이에요.

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -t llama-server
./build/bin/llama-server -hf ggml-org/Qwen3.8-27B-GGUF:Q4_K_M -c 4096 -ngl all --host 127.0.0.1 --port 8080

서버가 준비되면 브라우저에서 http://localhost:8080을 열고 모델을 선택해요. Mac 절에서 사용한 것과 같은 Python 요청을 붙여 넣어 보내요.

정상 응답으로 코드와 설명이 표시되면 모델 적재와 요청 흐름을 확인한 거예요. 빌드가 실패하면 CMake가 CUDA Toolkit을 찾는지 확인해요. 서버는 열렸지만 모델이 시작되지 않으면 다운로드 진행, 저장소명, VRAM¹⁰ 여유를 살피고 문맥을 2,048토큰으로 낮춰 다시 요청해요.

Windows에서 빌드하려면 Visual Studio 2022의 C++ 개발 도구와 CUDA Toolkit을 준비하고, Visual Studio Developer PowerShell에서 llama.cpp 저장소 폴더로 이동해요. 공식 빌드 문서는 CUDA 구성에 Linux와 같은 CMake 옵션을 사용하고, 서버 문서는 llama-server 타깃을 별도로 빌드해요. 아래 순서로 빌드한 다음 생성된 실행 파일을 찾아 모델 서버를 시작해요.

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -t llama-server
$server = Get-ChildItem -Path .\build -Filter llama-server.exe -Recurse | Select-Object -First 1 -ExpandProperty FullName
& $server -hf ggml-org/Qwen3.8-27B-GGUF:Q4_K_M -c 4096 -ngl all --host 127.0.0.1 --port 8080

서버가 뜨면 http://localhost:8080을 열고 모델을 선택해요. Mac 절의 Python 요청을 그대로 보내요.

정상 응답에 코드와 입력·반환 설명이 표시되면 모델 적재와 요청 흐름이 작동해요. 실행 파일이 없으면 빌드 출력의 첫 오류와 CUDA Toolkit 인식을 확인해요. 서버는 시작하지만 모델 적재가 실패하면 로그의 첫 모델 오류와 VRAM 여유를 살펴봐요.

먼저 각 서버에서 위 Python 요청에 정상 답변이 오는지 확인해요. 속도를 비교할 때는 모델을 처음 적재한 시간을 따로 적고, 한 번 워밍업한 뒤 같은 요청을 세 차례 보내요. 입력 문맥과 답변 한도를 고정한 채 요청 시작부터 첫 토큰, 답변 완료까지의 시간을 기록해요. RTX는 VRAM, Mac은 통합 메모리 압력도 함께 살펴봐요.

입력 길이를 늘릴 때는 같은 Python 요청에 실제 작업 코드 일부를 덧붙여 두 환경에 똑같이 보내요. 요청이 길어지면 프리필 시간과 KV 캐시 사용량이 달라질 수 있어요. Mac의 MLX Q4와 RTX의 GGUF Q4_K_M은 형식과 양자화¹¹가 다르므로, 기록할 때 실행한 모델 파일도 적어야 장비 차이와 체크포인트 차이를 구분할 수 있어요.

2026년 10월 9일 공개된 oMLX 0.7.1.dev1에는 Qwen3.8-27B oQ8e의 INT8 activation prefill 개선이 들어 있어요. 모델 설정의 Experimental Features에서 이 경로를 켜요. 릴리스 측정은 M5 Max와 oQ8e 체크포인트에서 이뤄졌고, Mac 실행 절의 Q4 모델 mlx-community/Qwen3.8-27B-4bit와는 다른 파일이에요. 입력 길이별 측정 조건과 수치는 아래 표에서 확인해요.

INT8 prefill을 시험하려면 oQ8e 지원 파일과 0.7.1.dev1을 준비하고, 짧은 입력으로 기본 답변이 정상인지 먼저 확인해요. 설정에서 해당 모델의 INT8 activation prefill을 켠 뒤 같은 토큰 수의 입력을 세 번 처리하고 프리필 속도 또는 TTFT¹²의 중앙값을 비교해요. M5 Max에서 공개된 개선은 생성 구간의 속도를 뜻하지 않으므로 디코드¹³ tok/s도 별도로 기록해요.

메모리에 오류가 나거나 첫 토큰이 늦어지면 문맥 길이를 낮추고 모델별 설정과 서버 로그의 선택 경로를 확인해요. INT8 activation은 계산 입력 표현을 바꾸므로 응답 수치와 답변 품질도 확인해요. 옵션을 끄고 같은 요청을 다시 보내면 변경 영향을 비교할 수 있어요.

Qwen3.8-27B 지원 MTP¹⁴ 체크포인트에서는 모델별 Lightning MTP를 비교할 수 있어요. MTP는 토큰 생성 경로에, KV 캐시 정밀도는 대화 상태를 저장하는 데 쓰는 메모리와 계산량에 영향을 줘요. 먼저 둘 다 기본 상태로 답변과 메모리를 기록하고, MTP만 켠 비교를 끝낸 다음 KV 캐시 설정만 바꿔요. 매 단계에서 같은 체크포인트와 질문을 사용해요.

0.7.1.dev1은 개발판이에요. 안정성이 우선이면 0.7.0을 유지하고, 새 기능은 별도 시험 환경에서 확인해요. 요청이 자주 실패하면 MTP나 KV 캐시를 조절하기 전에 서버 로그, 문맥 길이, VRAM 또는 통합 메모리 상태를 살펴봐요.

27B 파라미터에 BF16¹⁵의 2바이트를 곱하면 가중치만 약 54GB예요. 실행 버퍼와 캐시 공간은 이 계산에 들어 있지 않아요. 아래 명령은 Q4_K_M을 실행하는 앞의 RTX 24GB 레시피와 다른, BF16 가중치를 수용할 수 있는 별도 NVIDIA 서버용이에요. 주 레시피를 따라 한다면 이 부록은 건너뛰고 앞의 llama.cpp 명령을 사용해요.

vllm serve Qwen/Qwen3.8-27B --host 127.0.0.1 --port 8000 --max-model-len 8192 --gpu-memory-utilization 0.90

첫 명령을 실행한 뒤 서버 프로세스가 계속 실행 중인지 확인해요. 응답이 없거나 프로세스가 종료되면 터미널에 나온 첫 오류와 GPU 메모리 상태부터 봐요. 서버가 실행되면 두 번째 명령으로 실제 등록된 모델 ID를 확인해 요청에 사용해요.

curl -N http://127.0.0.1:8000/v1/models