본문으로 건너뛰기
r/LocalLLaMA

Intel Arc Pro B70과 vLLM XPU의 52토큰/초 실측

Intel Arc Pro B70에서 vLLM XPU가 Qwen3.8-27B를 52.2 tok/s로 실행했다.

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

작성자는 Ubuntu Linux에서 Intel Arc Pro B70 32 GB와 vLLM XPU를 사용해 Qwen3.8-27B GPTQ INT4를 MTP2 방식으로 실행하고 median 52.2 tok/s를 측정했다. FP8 KV cache와 prefix caching으로 64K 컨텍스트를 production profile로 운용했으며, 128K까지 모든 깊이의 needle-in-a-haystack 검사를 통과했지만 0.95 GPU util과 약 2.5 GB의 여유 메모리만 남았다. vision, tool calling, OpenCode 기반 coding agent 테스트도 통과했으며 llama.cpp SYCL의 29.0 tok/s보다 1.8배 높은 속도를 기록했다. 다만 MTP 동시 요청 충돌, prefix-caching pointer bug, 긴 컨텍스트의 높은 TTFT와 간헐적인 반복 토큰 문제가 있어 --max-num-seqs 1과 패치 적용이 필요한 구성이다.

주요 논점

01찬성다수

Intel Arc Pro B70이 32 GB VRAM과 vLLM XPU, MTP2, FP8 KV cache를 조합하면 27B INT4 모델을 약 52 tok/s로 실행하고 vision·tool calling·agent 작업까지 처리할 수 있다는 입장이다.

02중립소수

성능과 기능은 충분하지만 MTP 동시 요청 충돌, prefix-caching 버그, 긴 컨텍스트의 높은 TTFT, 반복 토큰 문제 때문에 운영 안정성에는 조건이 붙는다는 입장이다.

합의점 vs 논쟁점

합의점

  • MTP2 설정이 이 측정 환경에서 MTP1과 MTP3·MTP4보다 높은 decode 속도를 기록했다.
  • 32 GB VRAM에서는 64K 컨텍스트가 production profile이고 128K는 높은 GPU 사용률과 적은 메모리 여유를 감수해야 한다.
  • MTP를 사용하는 동안에는 --max-num-seqs 1 설정이 필요하며 동시 요청 처리에는 제약이 있다.

논쟁점

  • vLLM의 52.2 tok/s와 llama.cpp의 29.0 tok/s 비교는 모델 양자화 구성이 동일하다고 명시되지 않아 일반적인 프레임워크 우열로 확대하기 어렵다.
  • 128K 컨텍스트와 약 2.5 GB VRAM 여유가 실제 운영에 충분한지는 요청 길이와 agent turn에 따라 달라질 수 있다.

실용적 조언

  • Intel Arc Pro B70에서 Qwen3.8-27B를 운용할 때는 vLLM XPU, MTP2, FP8 KV cache, prefix caching을 함께 설정하고 64K를 기본 프로파일로 두는 방식이 적합하다.
  • MTP를 켠 환경에서는 --max-num-seqs 1로 요청을 직렬화하고, 동시 요청 처리가 우선이면 MTP를 끈 33 tok/s 구성을 고려해야 한다.
  • 128K 프로파일은 0.95 GPU util이 필요하므로 64K와 128K 서버를 동시에 실행하지 말고, 한 서버를 종료한 뒤 다른 프로파일을 시작하는 전환 방식을 사용해야 한다.
  • prefix-caching pointer bug가 있는 vLLM 0.27.1 XPU 환경에서는 원문에 사용된 mamba_utils.py 패치를 적용하기 전에 변경 내용을 검증하고 upstream 보고 여부를 확인해야 한다.

섹션별 상세

작성자는 Linux 환경의 Intel Arc Pro B70에서 vLLM 0.27.1 XPU와 Qwen3.8-27B GPTQ INT4를 조합해 52.2 tok/s의 median decode 속도를 측정했다. MTP를 끄면 33.2 tok/s였지만 MTP1은 47.1 tok/s, MTP2는 52.2 tok/s까지 올라갔고, GPU 전력도 230 W에서 174 W로 낮아졌다. 64K 컨텍스트를 production profile로 운용하면서 128K까지 needle-in-a-haystack 검사를 통과했다는 점에서 단순 채팅 속도 측정보다 실제 운용에 가까운 결과이다.
작성자는 성능 수치만이 아니라 vision, tool calling, coding agent 실행까지 같은 장비에서 통과시켰다. OpenAI-compatible API를 통해 2턴 도구 호출과 중첩 JSON 인자를 처리했고, seeded repository에서 headless OpenCode가 버그를 찾고 최소 수정과 신규 테스트 8개를 수행한 뒤 약 2분 안에 정직한 요약을 반환했다. 따라서 이 구성은 토큰 생성 속도뿐 아니라 에이전트 작업 흐름에서도 사용할 수 있는지 확인한 사례이다.
vLLM XPU와 llama.cpp SYCL을 같은 계열의 작업에 비교한 결과, llama.cpp의 최고 기록은 Q5_K_M과 MTP2에서 29.0 tok/s였고 vLLM은 Qwen3.8-27B INT4에서 52.2 tok/s를 기록했다. 작성자는 vLLM이 1.8배 빠르고 tool calling과 vision 지원도 더 나았다고 평가했지만, llama.cpp는 fallback으로 남겼다. 비교 조건과 모델 양자화 구성이 완전히 같다고 명시되지는 않았으므로 수치는 이 설정에 대한 실측 결과로 읽어야 한다.
구성에는 뚜렷한 제약도 있었다. MTP를 켠 상태에서 concurrent requests가 hybrid 모델의 D17 오류로 엔진을 중단시켜 --max-num-seqs 1로 요청을 직렬화해야 했고, MTP를 끄면 33 tok/s에서 전체 동시 요청이 가능했다. 128K는 GPU 사용률 0.95에서만 실행되며 약 2.5 GB 여유만 남고, 192K 이상은 32 GB VRAM에서 실행할 수 없었다.
긴 agent turn 뒤 반복 토큰이 나오는 decoding degeneration이 한 차례 발생했으며 재시작으로 해소됐다. vLLM 0.27.1 XPU의 prefix-caching pointer bug는 mamba_utils.py에 bind-mounted patch를 적용해 우회했고, xpu-smi의 GPU utilization 값은 N/A라서 전력과 주파수를 실용적인 지표로 사용했다. 이 결과는 Arc Pro B70이 무조건적인 plug-and-play 장비라기보다 특정 드라이버와 패치, 요청 직렬화 설정을 함께 관리해야 하는 실용적 추론 카드라는 점을 드러낸다.

용어 해설

추측 디코딩(Speculative Decoding)
— 작은 보조 예측 단계가 다음 토큰 후보를 미리 만들고, 주 모델이 이를 한꺼번에 검증해 순차 디코딩보다 생성 속도를 높이는 방식이다. 이 글에서는 MTP 헤드를 사용해 후보를 생성하며 MTP2 설정에서 가장 높은 decode 속도가 측정됐다.
멀티 토큰 예측(MTP)
— 한 번의 추론 단계에서 여러 미래 토큰을 예측하도록 학습된 헤드를 활용하는 기법이다. MTP1부터 MTP4까지 비교한 결과 MTP2가 52.2 tok/s로 가장 높았고, MTP를 끄면 33.2 tok/s로 낮아졌다.
FP8 KV 캐시(FP8 KV cache)
— Transformer의 어텐션 계산에 필요한 Key와 Value를 FP8 형식으로 저장해 같은 메모리에서 더 긴 컨텍스트를 처리하는 방식이다. 32 GB VRAM 환경에서 64K를 production profile로 사용하고 128K까지 확장하는 데 활용됐다.
프리픽스 캐싱(Prefix caching)
— 이전 요청에서 계산한 공통 프롬프트 부분을 저장한 뒤 후속 대화에서 재사용해 prefill 계산을 줄이는 기능이다. 이 설정 덕분에 긴 컨텍스트의 첫 요청은 느려도 두 번째 이후 대화의 처리 시간이 크게 줄어들었다.
Level Zero
— Intel GPU에서 장치와 메모리 같은 저수준 실행 자원을 제어하는 인터페이스다. 이 환경에서는 Arc Pro B70의 32 GB VRAM 중 31.9 GiB를 사용할 수 있도록 Intel XPU 소프트웨어 스택의 일부로 작동했다.

언급된 도구

vLLM추천

Intel XPU에서 Qwen3.8-27B GPTQ INT4를 OpenAI-compatible API로 제공하고 MTP2, FP8 KV cache, prefix caching을 실행하는 inference engine

llama.cpp중립

SYCL 기반 추론 성능을 비교하고 vLLM 장애 시 fallback으로 사용하는 실행 도구

OpenCode추천

seeded repository에서 버그 진단, 최소 수정, 테스트 실행을 수행한 headless coding agent

DeepSeek Harness추천

모델 선택, streaming, reasoning effort, vision, tool calling을 통합한 provider 실행 환경

AI 분석 전체 내용 보기

AI 요약 · 북마크 · 개인 피드 설정 — 무료

출처 · 인용 안내

원문 발행 2026. 08. 22.수집 2026. 08. 22.출처 타입 REDDIT

인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.