모델별 실행 레시피
DGX Spark에서 llama.cpp MTP 서버 열기: Qwen3.6 에이전트 요청
모델을 켜는 데서 그치지 않고, 이전 thinking 기록이 다음 요청에 이어지는지 확인합니다.
DGX Spark에서 로컬 에이전트가 쓸 Qwen3.6-35B-A3B MTP1 서버를 만들려면 GB10에 맞춰 llama.cpp CUDA2 빌드를 준비하고, MTP가 포함된 Q4_K_XL GGUF3를 선택해야 합니다. `preserve_thinking`은 Qwen의 interleaved thinking 기록을 후속 대화에 유지합니다. 모델이 한 번 답하는지와 MTP draft가 초기화됐는지, 멀티턴 API4가 정상인지 순서대로 확인합니다.
모델 선택은 35B가 아니라 Spark에서 확인된 파일부터
코드 에이전트가 같은 저장소에서 한 번 수정안을 내고, 이어서 실행한 테스트 로그를 받아 고치게 하고 싶다고 해보죠. 채팅 앱의 기본 URL만 입력하면 끝나는 일처럼 보여도, 서버의 모델이 MTP head를 포함했는지와 요청 형식이 thinking 기록을 이어 보내는지가 먼저 맞아야 합니다. 이 예시는 DGX Spark 한 대에서 Qwen3.6-35B-A3B를 OpenAI 호환 endpoint로 제공하는 구성입니다.
NVIDIA의 llama.cpp playbook은 DGX Spark, DGX OS, 128GB unified memory5, CUDA architecture `121a-real`을 안내합니다. 저장 공간은 모델 예시 다운로드가 약 35GB 규모이고 llama.cpp 빌드 자료도 별도로 필요하므로, 여유 공간을 확인합니다. 모델 가중치와 KV cache6를 위한 사용 가능 메모리는 약 30GB라고 playbook이 제시하지만, 동시 앱과 context 길이에 따라 필요한 양은 달라집니다.
선택할 모델은 `unsloth/Qwen3.6-35B-A3B-MTP-GGUF:UD-Q4_K_XL`입니다. 이름에 MTP가 있어도 다른 양자화7 저장소나 보통 Q4 파일이 MTP를 포함한다는 뜻은 아닙니다. 큰 파일이므로 Hugging Face 계정 접근과 네트워크, 다운로드 재개가 가능한지 준비합니다.
Spark용 CUDA 빌드를 따로 준비합니다
DGX Spark에서 리눅스 터미널을 열고 Git, CMake, CUDA Toolkit이 준비됐는지 확인합니다. 아래는 NVIDIA 문서에 있는 의존성 설치 및 소스 빌드 순서입니다. `-DGGML_CUDA=ON`은 CUDA backend를 빌드하고, `121a-real`은 Spark의 GB10 GPU8 architecture입니다. 같은 clone에서 빌드를 다시 하려면 실행 파일 버전과 소스 revision을 기록해 둡니다.
빌드가 끝나면 `build/bin/llama-server --version`으로 실행 파일이 생성됐는지 확인합니다. CUDA가 없다는 오류면 `nvcc --version`과 PATH를 확인합니다. 다른 GPU architecture로 빌드하면 설치가 성공해도 Spark GPU가 인식되지 않을 수 있으므로 RTX 빌드 자료를 복사하지 않습니다.
sudo apt update
sudo apt install -y git clang cmake libcurl4-openssl-dev libssl-dev
git clone https://github.com/ggml-org/llama.cpp ~/llama.cpp
cd ~/llama.cpp
cmake -B build -DGGML_NATIVE=ON -DGGML_CUDA=ON -DGGML_CURL=ON -DGGML_RPC=ON -DCMAKE_CUDA_ARCHITECTURES=121a-real
cmake --build build --config Release --target llama-server -j
./build/bin/llama-server --version먼저 로컬 전용 endpoint를 시작합니다
이번 서버는 같은 Spark의 에이전트 앱만 접속할 것이므로 `--host 127.0.0.1`로 loopback에 묶습니다. NVIDIA 예제의 `0.0.0.0`은 다른 기기에서도 접속 가능한 주소이므로, 네트워크에 서버를 공개할 의도가 없을 때는 사용하지 않습니다. `-hf`는 Hugging Face GGUF를 내려받아 cache에 두고, 모델이 지원하는 경우 vision projector도 자동으로 읽을 수 있습니다.
첫 시작은 수십 GB 모델을 다운로드하고 CUDA에 적재하는 시간이 포함됩니다. 서버 터미널에서 `server is listening`이 나타나기 전에는 API가 준비되지 않았습니다. 128GB unified memory는 CPU9와 GPU가 함께 쓰므로 모델 용량을 더하는 계산만으로 여유를 보장하지 않습니다. context, operating system, 다른 앱이 차지하는 양도 기록합니다.
MTP를 켠 명령에는 `--spec-type draft-mtp`와 `--spec-draft-n-max 3`이 들어갑니다. NVIDIA playbook의 MTP 호환 예제 값이며, 이름이 비슷한 체크포인트10나 다른 모델에 그대로 쓰지 않습니다. `preserve_thinking`은 모델 템플릿이 생성한 thinking block을 다음 turn history에서 보존해 에이전트가 이미 한 reasoning을 다시 요청 본문에서 버리지 않게 합니다.
cd ~/llama.cpp/build
./bin/llama-server -hf unsloth/Qwen3.6-35B-A3B-MTP-GGUF:UD-Q4_K_XL --host 127.0.0.1 --port 30000 --chat-template-kwargs '{"preserve_thinking":true}' --spec-type draft-mtp --spec-draft-n-max 3 --alias qwen3.6-35b-a3b --ctx-size 8192 -ngl 99
health check 뒤에 짧은 API 요청을 보냅니다
서버 로그에서 모델이 load되고 `speculative decoding11 context initialized`가 나타나는지 본 다음 별도 Spark 터미널에서 health endpoint를 확인합니다. 이 로그는 MTP context 준비를 뜻하지만, 해당 모델이 현재 요청에서 언제나 더 빠른 속도를 낸다는 측정은 아닙니다. 준비 실패면 먼저 model download, CUDA build, 메모리 오류를 확인합니다.
그다음 OpenAI 호환 `/v1/chat/completions`에 서버에 올라온 모델 ID와 한 문장 요청을 보냅니다. 답변이 돌아오면 endpoint 연결이 확인된 것입니다. 여기까지는 smoke test이며 속도 측정이 아닙니다. 코드 에이전트는 이어서 같은 대화 ID/history로 수정 요청을 보내야 합니다. 앱이 thinking block을 제거하거나 재작성한다면 `preserve_thinking`이 있어도 이전 내용을 보존할 수 없습니다.
멀티턴 확인에서는 먼저 첫 turn에서 함수와 요구사항을 보내고, 두 번째 turn에서 테스트 로그와 ‘실패 원인만 고쳐 달라’는 동일 대화의 지시를 보냅니다. 답이 앞서 제안한 수정과 실행 로그를 연결하는지 확인합니다. API wrapper가 메시지 history를 실제로 다시 보내는지와 raw response에 thinking content가 노출되는지는 앱 설정 및 모델의 response format에 따라 다를 수 있습니다.
curl --fail-with-body http://127.0.0.1:30000/health
curl --fail-with-body http://127.0.0.1:30000/v1/chat/completions -H 'Content-Type: application/json' -d '{"model":"qwen3.6-35b-a3b","messages":[{"role":"user","content":"Review this Python function for empty-list input and suggest a minimal fix: def first_item(items): return items[0]"}],"max_tokens":128,"temperature":0}'
에이전트용 대화와 속도 시험을 따로 봅니다
첫 응답을 확인했으면 두 번째 요청도 같은 대화 history로 전송해 thinking 기록이 이어지는지 점검합니다. 긴 context를 쓰는 코드 에이전트는 history와 코드 파일이 함께 context를 사용합니다. NVIDIA playbook은 agentic/coding 작업에서 최소 32K, 가능하면 100K 이상을 선호하도록 안내하지만, Spark의 모든 사용 조합에서 그 크기가 여유롭게 들어간다는 보증은 아닙니다. 실제 저장소의 입력 길이와 동시 앱 메모리를 고려해 필요한 만큼 설정합니다.
속도 비교를 할 때는 같은 모델 revision, 입력, 생성 상한을 두고 준비 실행 뒤 측정합니다. MTP가 활성화됐는지는 초기화 로그와 응답의 server timings 또는 speculative 통계로 확인합니다. 답변이 빨라졌는지를 비교하려면 baseline command에서 MTP 옵션만 빼고 같은 질문을 여러 번 보내야 합니다. 처음 다운로드와 모델 로딩 시간은 generation 결과에 넣지 않습니다. NVIDIA playbook은 이 조합의 직접 비교 tok/s 수치를 제공하지 않으므로 결과를 추정하거나 꾸미지 않습니다.
모델 ID, backend, 메모리부터 되돌아봅니다
`curl: (7) Failed to connect`이면 모델 속도 문제가 아닙니다. 서버가 아직 listening 상태가 아닌지, 클라이언트와 서버가 같은 Spark의 127.0.0.1 및 30000을 쓰는지 확인합니다. 서버가 시작 중 종료됐다면 표준 오류 로그에서 잘못된 Hugging Face 모델 이름, 다운로드 실패, CUDA 초기화 문제, OOM 메시지를 찾습니다.
서버는 떴는데 응답이 없거나 문장이 비정상이라면 먼저 MTP 호환 GGUF를 선택했는지, 실행 파일이 실제로 `draft-mtp`를 초기화했는지, 에이전트가 같은 model ID와 chat template를 쓰는지 점검합니다. `preserve_thinking`을 true로 썼다고 앱이 history를 자동 보존하는 것은 아닙니다. 두 번째 요청의 messages에 필요한 앞선 turn이 포함되어 있는지 확인합니다.
메모리 부족이면 우선 동시 실행 앱과 불필요한 context를 줄이고, 필요하면 `--ctx-size`로 명시적 상한을 설정합니다. 긴 에이전트 세션에서 context를 줄이면 대화 이력 일부를 모델이 더 이상 볼 수 없게 되므로, 단순 속도 설정처럼 취급하지 않습니다. 모델 파일을 다른 양자화로 바꾼다면 새 파일에서도 MTP head와 지원 여부를 다시 확인합니다.
공식 실행 자료
설치와 지원 조건은 아래 공식 자료를 기준으로 확인했습니다. 재현할 때는 사용한 모델과 실행기 버전을 함께 기록하세요.
용어 각주
MTP — 한 번에 여러 미래 토큰을 예측하도록 학습하는 방식 또는 관련 모델 구성입니다. 실제 생성 속도 향상 여부는 구현과 실행 조건에 달려 있습니다.
본문으로 돌아가기CUDA — NVIDIA GPU에서 범용 계산을 실행하기 위한 소프트웨어 플랫폼입니다. CUDA용으로 만든 프로그램은 다른 GPU에서 그대로 동작한다고 보장되지 않습니다.
본문으로 돌아가기GGUF — 모델 정보를 담는 파일 형식으로 llama.cpp 계열 도구에서 널리 사용됩니다. 파일 형식만으로 특정 하드웨어 호환성이나 속도가 보장되지는 않습니다.
본문으로 돌아가기API — 프로그램의 기능을 다른 코드에서 호출하기 위한 약속된 인터페이스입니다. API라는 말만으로 외부 서버 전송을 뜻하지는 않습니다.
본문으로 돌아가기통합 메모리 — CPU와 GPU가 같은 물리 메모리 풀을 공유하는 구조입니다. 메모리 용량이 자동으로 늘어나는 것은 아니며, 실제 사용 가능량은 시스템에 따라 다릅니다.
본문으로 돌아가기KV 캐시 — 어텐션에서 이전 토큰의 키·값을 저장해 다음 토큰 생성 때 재사용하는 메모리입니다. 문맥 길이와 배치 크기에 따라 용량이 달라집니다.
본문으로 돌아가기양자화 — 모델의 수치를 더 적은 비트로 표현하는 방법입니다. 메모리 사용량과 함께 정확도나 실행 속도도 달라질 수 있으며, 영향은 형식과 구현에 따릅니다.
본문으로 돌아가기GPU — 많은 계산을 병렬로 처리하는 프로세서입니다. AI 모델 실행에서는 모델 계산을 맡습니다.
본문으로 돌아가기CPU — 컴퓨터에서 일반적인 프로그램 명령을 실행하는 중앙 처리 장치입니다. AI 작업에서는 GPU 등 다른 프로세서와 역할을 나누기도 합니다.
본문으로 돌아가기체크포인트 — 학습된 모델의 가중치 등을 저장한 파일입니다. 같은 모델 계열도 버전이나 용도에 따라 다른 체크포인트를 쓸 수 있습니다.
본문으로 돌아가기추측 디코딩 — 출력 후보를 먼저 제안한 뒤 본 모델이 검증하는 생성 기법입니다. 후보는 별도 초안 모델, MTP 헤드 또는 문맥의 반복 구간 조회 등으로 만들 수 있으며, 속도 효과는 구현과 조건에 따라 달라집니다.
본문으로 돌아가기