이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.
TL;DR
ThinkPad P14s Gen 6 AMD의 Radeon 890M에서 Qwen3.6-35B-A3B Q8_0을 구동한 측정 결과, 프리필은 약 450 t/s지만 65k 토큰부터 콜드 시작 대기가 실사용 한계가 됐다. 작성자는 qwen-code의 세션 워밍업과 llama.cpp의 디스크 프롬프트 캐시로 41.6k 토큰 시작 프롬프트의 첫 요청을 100초에서 9초로 줄였고, SLOT_RESTORE 버그 수정으로 캐시 복구 후 처리 시간을 10.01초에서 0.17초로 낮췄다. IOMMU를 끄면 프리필 26%, 생성 16%가 빨라졌으며, DPM·VRAM carve-out·CPU governor 같은 설정은 대부분 이득이 없거나 조건에 따라 성능을 악화시켰다. 따라서 이 구성은 노트북 iGPU에서 쓸 수 있지만 전체 코딩 작업을 대체하기보다 캐시 재사용이 가능한 제한된 작업에 적합하다.
실용적 조언
- 긴 시작 프롬프트를 사용하는 coding client에서는 세션 시작 시 max_tokens=1 워밍업 요청을 보내고, llama.cpp 서버를 -np 1로 실행해 워밍업 요청과 실제 요청이 같은 슬롯의 KV cache를 공유하게 해야 한다.
- 로그인 때마다 서버를 재시작한다면 --cache-disk-path로 프롬프트 캐시를 디스크에 보존하고, 복구 뒤 prompt.checkpoints가 실제로 채워지는지 확인해야 한다.
- GPU 성능 비교 때는 /proc/cmdline을 측정 결과에 함께 기록해 amd_iommu 설정을 고정해야 하며, 전력 소비가 낮다는 이유만으로 스로틀링을 단정하지 않아야 한다.
- UMA/VRAM carve-out, CPU governor, TSME, GPU DPM을 바꿀 때는 프리필과 생성을 분리해 측정해야 한다. 특히 DPM high는 프리필과 생성에 반대 방향의 영향을 줄 수 있고, GPU 클록과 전력이 비정상적으로 낮으면 하드웨어 상태부터 확인해야 한다.
- speculative decoding은 draft 방식별 거부율을 확인해야 한다. 글의 측정에서는 draft-mtp가 생성 속도를 13% 높였지만 ngram 계열은 초안 87~92%가 거부되어 손해가 발생했다.
섹션별 상세
작성자는 Ryzen AI 9 HX PRO 370과 Radeon 890M iGPU에서 Qwen3.6-35B-A3B Q8_0을 llama.cpp와 Vulkan으로 구동한 6주간의 측정값을 공개했다. 18k 토큰 콜드 프롬프트 기준 프리필은 GPU DPM auto에서 420~449 t/s, 생성은 22.7~23.0 t/s였으며, 96GB DDR5-5600과 256k 컨텍스트에서도 모델과 KV cache 자체는 메모리에 들어갔다. 다만 프리필 시간이 65k 토큰에서 145초, 128k에서 285초, 256k에서 570초로 늘어나 실제 사용 한계는 메모리가 아니라 첫 토큰을 기다리는 시간이 됐다.
coding client의 약 41.6k 토큰 시작 프롬프트가 매 세션 전체 프리필을 강제하는 병목으로 측정됐다. qwen-code fork는 세션 초기화 때 max_tokens=1 요청으로 시작 프롬프트를 미리 처리하고, llama.cpp가 보내는 prompt_progress 청크를 UI의 진행률 표시줄로 렌더링하도록 바꿨다. 실제 클라이언트에서 첫 요청은 워밍업 전 100초에서 워밍업 후 9초로 줄었고, 서버를 -np 4로 실행하면 요청이 서로 다른 슬롯에 배정되어 워밍업이 오히려 2배의 프리필을 만들 수 있어 -np 1이 필요했다.
서버 프로세스가 로그인 때마다 재시작되면서 메모리 프롬프트 캐시가 사라지는 문제가 디스크 캐시 계층으로 보완됐다. llama.cpp fork의 --cache-disk-path는 세션 중 약 2GB인 4개 캐시 엔트리를 저장했고, 다음 시작 때 이를 약 0.8초에 다시 읽어 41.6k 토큰 prefix를 첫 요청 전에 준비했다. SLOT_RESTORE가 hybrid/recurrent 모델의 prompt.checkpoints를 복구하지 않던 버그도 수정했으며, 동일 상태에서 체크포인트가 0개면 10.01초가 걸리던 요청이 3개 복구 후 99.9% 캐시 적중 상태에서 0.17초로 줄었다.
IOMMU 설정은 전력 소비가 아니라 GPU가 실제 작업을 수행하는 사이클에 영향을 주는 변수로 확인됐다. IOMMU를 켠 상태에서는 프리필 374.9 t/s와 생성 17.81 t/s였지만 끄자 각각 473.1 t/s와 20.65 t/s로 올라 프리필 26%, 생성 16%의 차이가 났다. 같은 2900MHz에서 IOMMU를 켰을 때 GPU 전력이 46.7W로 낮고 끄면 53.1W였기 때문에 낮은 전력을 스로틀링으로 오인할 수 있었지만, 실제로는 주소 변환 대기로 유효 작업량이 줄어든 결과였다.
여러 설정은 성능을 높이는 것처럼 보였지만 재현 가능한 이득이 없거나 하드웨어 문제를 설정 문제로 오인하게 만들었다. GPU DPM high는 프리필을 13% 높였지만 생성은 8.6% 낮추고 패키지 온도는 95°C, 전력은 29W 더 높였으며, 1150MHz와 13W에 고정된 GPU는 설정이 아니라 고장 증상이었다. UMA/VRAM carve-out을 8GB에서 1GB로 바꿔도 차이가 없었고, TSME 비활성화는 0.5%에 그쳤으며, CPU governor performance도 약 0%였다.
추측 디코딩에서는 방식에 따라 결과가 크게 갈렸다. --spec-draft-n-max는 --spec-type draft-mtp와 함께 사용해도 단계당 초안 토큰 하나만 생성해 동작 변화가 없었지만, draft-mtp 자체는 생성 속도를 13% 높였다. 반대로 ngram 계열은 초안의 87~92%가 거부되어 검증 비용만 추가됐고 추측을 사용하지 않을 때보다 느렸으므로, 초안 생성 방식과 거부율을 함께 측정해야 했다.
용어 해설
- 프리필(Prefill)
- — 프리필은 사용자가 입력한 프롬프트 전체를 모델이 처음 처리해 첫 출력 토큰을 준비하는 단계이다. 입력 토큰을 순차적으로 계산해 KV cache를 만들며, 긴 코딩 클라이언트 시작 프롬프트에서는 생성 속도보다 첫 응답까지의 대기 시간을 크게 좌우한다.
- KV 캐시(KV Cache)
- — KV Cache는 Attention 계산에 사용한 Key와 Value를 저장해 이미 처리한 프롬프트를 다시 계산하지 않도록 하는 메모리 구조이다. 캐시가 재사용되면 긴 시작 프롬프트의 전체 프리필을 건너뛰고 새로 입력된 부분만 처리할 수 있다.
- Graphics Translation Table(GTT)
- — GTT는 GPU가 시스템 RAM에 배치된 데이터를 GPU 주소 공간에서 접근하도록 연결하는 구조이다. 이 사례처럼 모델이 약 36GB의 시스템 RAM에 상주하면 GPU 접근마다 주소 변환 비용이 발생할 수 있어 IOMMU 설정에 따라 프리필과 생성 속도가 달라진다.
- IOMMU
- — IOMMU는 장치가 메모리에 접근할 때 주소 변환과 접근 격리를 수행하는 하드웨어 기능이다. 글의 환경에서는 GTT에 저장된 모델 데이터에 대한 GPU 접근이 주소 변환으로 지연되어 IOMMU를 끄자 프리필이 26%, 생성이 16% 빨라졌다.
- 추측 디코딩(Speculative Decoding)
- — 추측 디코딩은 작은 초안 생성기가 다음 토큰을 먼저 예측하고, 큰 모델이 해당 토큰을 한 번에 검증하는 방식이다. 글에서는 draft-mtp가 생성 속도를 13% 높였지만 ngram 방식은 초안의 87~92%가 거부되어 추측을 사용하지 않을 때보다 느렸다.
언급된 도구
언급된 리소스
GitHubjstormes/p14
GitHubjstormes/qwen-code
AI 분석 전체 내용 보기
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
원문 발행 2026. 08. 23.수집 2026. 08. 23.출처 타입 REDDIT
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
