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

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

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

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

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

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

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

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

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

먼저 장비 선택기에서 실제로 쓸 컴퓨터를 고릅니다. 이 가이드는 Mac에서는 oMLX, RTX에서는 llama.cpp로 경로를 나누며 데스크톱 쪽 출발점은 호환되는 Q4 GGUF³ 또는 MLX⁴ 변환본입니다. 모델 이름이 같아도 파일 형식과 앱이 다르면 선택기가 내놓는 명령도 달라집니다. 다른 사람의 설정을 복사하기 전에 내 장비와 형식부터 맞추는 이유입니다.

약 17GB대라는 안내는 Q4 파일을 찾을 때의 대략적인 기준이지, 실행 중 필요한 메모리 총량은 아닙니다. 파일을 내려받은 뒤 정확한 크기를 보고, 실행할 때 운영체제와 앱, 캐시를 위한 공간이 남는지도 확인합니다. 모델 파일이 디스크에 있다는 사실과 모델이 메모리에 올라 질문에 답할 준비가 됐다는 사실은 다릅니다.

공식 BF16⁵ 모델 ID를 서버에 전달하는 경로도 별개입니다. 27B 가중치만 단순 계산해도 약 54GB 규모이고, 런타임⁶ 작업 공간은 그 밖에 필요합니다. 그래서 아래 vLLM 예시는 공식 서버 가중치를 실행할 수 있는 NVIDIA 환경을 전제로 하며, 24GB GPU⁷의 Q4 실행 명령으로 옮겨 쓸 수 없습니다. 같은 모델 이름 아래라도 배포 파일과 정밀도가 달라지면 필요한 환경이 바뀝니다.

텍스트 질문을 기준으로 먼저 실행해 두면 나중에 이미지를 넣거나 MTP⁸를 추가할 때 결과를 비교하기 쉽습니다. 첫 시도에서 Q4 파일, 비전 입력, MTP를 한꺼번에 바꾸면 실패 지점이 세 곳 중 어디인지 알기 어렵죠. 이번 예시에서는 텍스트 답변이 끝나는 상태를 먼저 만들고, 선택한 런타임이 지원하는 추가 기능만 그 뒤에 붙입니다.

선택기가 만든 Mac oMLX 또는 RTX llama.cpp 명령을 그대로 적용하고, 한 번에 요청 하나만 보냅니다. 표시된 문맥에서 짧은 코딩 질문을 먼저 끝까지 받아 보세요. 여기서 확인하려는 것은 빠른 점수가 아니라 모델 적재와 답변까지 기본 경로가 작동하는지입니다. 시작부터 문맥을 크게 늘리면 캐시 점유가 바뀌어 기준 상태를 얻기 어렵습니다.

정상 답변이 나오면 그 설정을 기록해 둡니다. 준비 실행 뒤 세 번의 프리필⁹, 첫 토큰 시간, 디코드¹⁰, 피크 메모리를 적으면 우연한 한 번의 빠른 실행만 보고 판단하는 일을 줄일 수 있습니다. 첫 요청과 같은 입력을 다시 보낸 결과는 나누어 기록합니다. 두 번째에는 입력 캐시가 남아 있을 수 있어, 이 차이를 모델이나 장비의 고정 속도 차이로 읽으면 안 됩니다.

예를 들어 빈 입력을 처리하지 못하는 함수와 그 호출부를 함께 넣었다면, 요청에 쓴 파일 범위와 답변이 지적한 조건도 메모합니다. 이 기록은 성능 숫자를 만드는 것보다 먼저 같은 일을 두 설정에 맡겼는지 확인하는 데 쓰입니다. 다른 사람이 더 짧은 질문이나 이미 열린 파일로 비교했다면, 그 사람의 tok/s를 그대로 내 작업의 완료 시간으로 가져올 수 없습니다.

아래 vLLM 명령은 이 데스크톱 선택기와 또 다른 구성입니다. 공식 BF16 가중치를 담을 수 있는 NVIDIA 서버에서 쓰는 예이므로 Mac이나 24GB RTX용 Q4 명령과 혼합하지 않습니다. 요청을 보내는 클라이언트가 127.0.0.1을 쓰더라도 서버가 외부 네트워크에 열려 있지 않다는 뜻은 아닙니다. 실제 바인딩과 방화벽을 확인하고, 다른 기기에 접근을 허용하려면 인증과 접근 제한을 준비해야 합니다.

API¹¹ 테스트에서는 모델 목록에 실제 표시된 식별자를 요청에 넣습니다. 포트도 실행한 런타임에 맞춰야 합니다. 이 가이드의 명령은 oMLX 8000, llama.cpp 8080을 쓰므로 8000에 서버가 없는데 예시 curl만 반복해도 답은 오지 않습니다. 먼저 주소에 응답이 있는지 보고, 그다음 짧은 채팅 요청이 끝까지 도착하는지 확인합니다.

응답이 스트리밍으로 조각조각 도착하는지도 보고, 앱이 생각 과정과 최종 답을 구분하는 설정이라면 두 구간의 표시를 확인합니다. 생각 토큰을 길게 내보내도록 설정된 경우 최종 문장이 화면에 늦게 보여도 입력 처리가 느리다고 단정할 수 없습니다. 첫 토큰부터 최종 답까지의 화면 표시와 서버 로그를 함께 보면 어느 단계에서 시간이 쓰였는지 더 잘 나뉩니다.

모델 목록에 이름이 나타나는 것은 서버가 어떤 식별자를 알고 있다는 확인이지, 내 앱이 올바른 모델을 요청했고 문맥 설정도 적용됐다는 검증은 아닙니다. 잘못된 이름이면 요청이 거절되거나 다른 경로에서 답이 올 수 있습니다. 짧은 테스트 응답에서 실제 모델 식별자와 서버 로그를 확인한 뒤 문서 입력으로 넘어가면, 나중에 느린 답이 모델 적재 문제인지 요청 대상이 다른 문제인지 혼동할 가능성이 줄어듭니다.

텍스트 질문이 완료된 뒤에는 실제로 맡길 코드나 문서를 보내 봅니다. 예를 들어 수정할 함수와 그 주변 호출부를 함께 넣고, 답이 요청한 파일 범위를 다루는지 확인합니다. 짧은 인사말의 높은 tok/s는 긴 코드 입력 후 첫 답변과 완료 시점을 대신하지 않으므로, 비교의 기준은 내 질문으로 바꿔야 합니다.

코드나 문서를 보낸 뒤 첫 답이 늦다면 입력 토큰 수와 프리필 청크, 캐시 상태를 살핍니다. 이미 답이 시작된 다음 느리다면 메모리 사용량과 스왑, 가중치 일부가 CPU¹²로 넘어갔는지 확인합니다. 전자는 입력 처리 구간, 후자는 토큰 생성 구간의 병목일 수 있으므로 MTP 단계 수만 올려 둘 다 해결하려고 하면 원인을 놓칩니다.

oMLX 0.7.0 릴리스에는 Qwen3.8-27B용 Lightning MTP와 DFlash2 경로가 포함됐습니다. 서로 다른 speculative decoding¹³ 방식이므로 UI에서 둘을 동시에 켜는 대신 한 번에 하나만 선택하고, 해당 체크포인트¹⁴와 draft 모델이 그 경로에 맞는지 확인합니다. 기본 디코드와 선택한 가속 경로를 같은 질문으로 비교하면 어떤 설정이 실제로 달라졌는지 알 수 있습니다.

PR #3958의 Qwen3.8-27B oQ4e 비교는 M3 Ultra 80코어 GPU·512GB 통합 메모리¹⁵에서 긴 code_python 프롬프트로 512토큰을 생성했습니다. temperature 1, top_p 0.95, top_k 20 조건에서 Lightning MTP는 8K·16K·64K 문맥에서 74.1·64.9·49.6 tok/s, DFlash2는 79.4·84.7·59.9 tok/s였습니다. ANE prefill은 꺼져 있었고 각 행은 PR 브랜치와 main의 비교입니다. 이는 PR의 검증 자료이지 안정판 oMLX 0.7.0을 같은 조건에서 새로 반복 측정한 결과는 아니므로, 내 Mac에서는 같은 모델·입력·문맥으로 다시 재야 합니다.

PR #3958의 표에는 메모리 가드 단계와 KV 캐시¹⁶ 정밀도가 적혀 있지 않습니다. oMLX 0.7.0에서는 balanced가 다른 앱을 위해 메모리 약 8%(3~8GB)를 남기고, aggressive는 약 2%(1.5~4GB)만 남깁니다. 평소에는 balanced부터 쓰고 aggressive는 다른 앱을 닫은 시험에서 안정성을 확인할 때만 고려하세요. KV 캐시 정밀도와 MTP도 각각 별도 조건으로 기록해야 어떤 설정이 결과를 바꿨는지 구분할 수 있습니다.

속도 외에는 코드 결과를 검증합니다. 가령 같은 함수 수정 요청을 기본 설정과 MTP 설정에 각각 보내 함수 이름이 요구대로 바뀌었는지, 빈 입력 처리 분기가 남았는지, 기존 반환 형식이 유지됐는지 확인합니다. 테스트가 실패하면 그 차이를 기록해 두면 빠르게 끝난 답이 작업을 제대로 마쳤는지 알 수 있습니다. 이는 코드 요구사항을 점검하는 일이고, 후보 토큰 검증의 작동 여부와 같은 시험은 아닙니다.

문맥을 늘렸을 때만 메모리가 모자라면 요청 수와 입력 길이를 낮춰 안정적으로 답하는 범위를 먼저 잡습니다. 매일 쓰는 문서 길이에서 한계가 반복되는지 보고, 필요할 때만 더 큰 메모리 구성을 검토합니다. 한 번 실패한 긴 질문만으로 장비가 부족하다고 정하기보다, 텍스트 기준선과 실제 작업의 차이가 무엇인지 확인하는 편이 정확합니다.

코드 수정과 문서 요약을 모두 맡길 예정이라면 각각 대표 질문 하나를 남겨 둡니다. 프리필 배치나 캐시 설정이 한 작업에는 도움이 되더라도 다른 입력 길이에서는 메모리 부담이나 대기가 달라질 수 있습니다. 답변 속도만 기록하지 말고 코드가 실행 가능한지, 문서의 중요한 조건이 요약에 남았는지도 기준 답과 비교합니다.

최종 기록에는 모델 파일 이름과 앱 버전, 문맥 길이, 요청 수, 사용한 가속 옵션을 함께 적습니다. 업데이트 뒤 실행이 바뀌면 이 상태를 기준으로 돌아가 어느 설정이 달라졌는지 확인할 수 있습니다. 평소 작업에서 답을 끝까지 받고 필요한 내용을 정확히 얻는 설정이 먼저입니다. 그 기준이 안정된 뒤에야 한 항목을 조정해 기다림이 실제로 줄었는지 비교할 수 있습니다.

가령 평소 질문이 Q4 파일에서 안정적으로 끝나지만 긴 입력만 실패한다면, 새 장비를 사기 전에 먼저 해당 문맥과 프리필 설정이 선택기에 어떻게 잡혔는지 봅니다. 반대로 입력이 짧아도 모델을 적재하지 못한다면 캐시 정밀도나 MTP 단계보다 파일·런타임 조합과 가용 메모리를 먼저 확인할 일입니다. 문제의 위치를 구분하면 무엇을 바꿔야 할지 선택하기 쉬워집니다.

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

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