TL;DR
작성자는 RTX 3090용 NInfer fork를 CMP170HX의 70-SM SM80 구성에 맞게 이식하면서 실제 SM 수를 읽는 planner, 16→8→4→2 Split-K fallback, SM80 전용 커널 선택을 추가했습니다. CUDA forward-compatibility libcuda를 제거하고 int8 KV 캐시, MTP, 262K context를 적용한 결과 Qwen3.6-35B에서 text와 image processing 모두 일관된 2배 성능 향상을 얻었으며, 단일 요청에서 prefill 4000 초과와 token generation 210 초과를 기록했습니다. Qwen3.8-27B는 MoE의 memory bandwidth 제약 때문에 prompt에 따라 10%에서 35% 향상으로 편차가 컸습니다. 이 구성은 llama-swap과 Docker를 결합해 Home Assistant와 HA Voice용 모델을 필요할 때 실행하는 용도로 사용됐습니다.
주요 논점
CMP170HX의 하드웨어 특성에 맞춰 SM 수, CUDA 커널, 메모리 스케줄을 조정하면 기존 RTX 3090용 NInfer fork를 재활용하면서도 Qwen3.6-35B의 추론 성능을 크게 높일 수 있다는 입장입니다.
성능 수치는 Qwen3.6-35B에서 가장 일관됐지만 Qwen3.8-27B에서는 모델 구조와 prompt에 따라 개선 폭이 달라졌으므로, 다른 모델과 환경에도 같은 2배 향상을 기대하기는 어렵다는 입장입니다.
합의점 vs 논쟁점
논쟁점
- CMP170HX에서 Qwen3.6-35B의 2배 성능 향상은 구체적인 실행 설정과 측정 화면으로 뒷받침되지만, 게시물에 커뮤니티 댓글 반응이나 독립적인 재현 결과는 포함되지 않았습니다.
- Qwen3.8-27B의 성능 향상 폭은 10%에서 35%로 변동해 모델 구조와 prompt에 따른 결과 차이가 확인됐지만, 어떤 prompt와 측정 조건에서 각 수치가 나왔는지는 제시되지 않았습니다.
실용적 조언
- CMP170HX에 NInfer를 포팅할 때는 컴파일 대상 아키텍처만 SM80으로 바꾸지 말고 실제 SM 수를 planner에 반영해야 합니다. 협력적 커널이 상주하지 못하는 경우를 대비해 Split-K 분할 크기를 단계적으로 낮추고 비협력 커널로 전환하는 경로도 필요합니다. RTX 5090용 170-SM launch policy와 Blackwell 전용 NVFP4/W4A4 커널을 SM80 빌드에서 제외해야 하며, 컨테이너의 CUDA forward-compatibility libcuda를 제거해 호스트 드라이버를 사용하게 해야 합니다.
- Qwen3.6-35B를 긴 context로 운용하려면 int8 KV 캐시, --max-context 262144, --kv-capacity 262144 설정을 함께 적용할 수 있습니다. 게시물의 실행 예시는 MTP와 --draft-tokens 3을 사용하고, --prefill-chunk 1024와 --max-concurrency 1을 지정했습니다. 실제 성능은 모델 구조에 따라 달라지므로 Qwen3.8-27B처럼 MoE 모델에서는 별도 측정이 필요합니다.
섹션별 상세
용어 해설
- 협력적 커널 실행(Cooperative Launch)
- — 여러 thread block이 동시에 실행돼야 하는 CUDA 커널 실행 방식입니다. GPU의 SM 자원이 부족해 전체 grid를 한 번에 상주시키지 못하면 실행이 실패할 수 있어, 실제 SM 수에 맞는 작업 분할과 안전한 대체 커널 선택이 중요합니다.
- Split-K 스케줄(split-K)
- — 행렬 연산의 K 차원 작업을 여러 조각으로 나눠 GPU 자원에 맞게 처리하는 실행 스케줄입니다. 이 글에서는 16, 8, 4, 2 단계로 분할 크기를 줄여 협력적 실행이 가능한 구성을 찾고, 모두 실패하면 비협력 커널로 전환하는 방식으로 사용됐습니다.
- SM80 아키텍처 대상 빌드(SM80)
- — NVIDIA Ampere 계열 GPU의 CUDA 컴파일 및 커널 선택 기준입니다. CMP170HX는 70개 SM을 가진 SM80 장치로 취급되므로, RTX 3090용 SM86 가정과 Blackwell 전용 커널을 제거하고 SM80에 맞는 수치 검증을 거쳐야 합니다.
- KV 캐시(KV-cache)
- — 긴 대화에서 이미 계산한 attention의 key와 value를 저장해 이전 토큰을 반복 계산하지 않도록 하는 메모리 구조입니다. 글의 설정은 int8 KV 캐시와 262K 용량을 함께 사용해 Qwen3.6-35B에서 최대 262K context를 확보했으며, 26GiB를 사용하고도 여유가 있었다고 기록합니다.
- Mixture of Experts
- — 모델 전체가 아니라 입력마다 일부 전문가 네트워크를 선택해 계산하는 구조입니다. 글에서는 Qwen3.8-27B의 성능 향상이 prompt에 따라 10%에서 35%로 달라졌고, MoE 모델은 memory bandwidth의 영향을 크게 받아 Dense 모델보다 일관된 개선 폭이 작았다고 설명합니다.
코드 예제
docker run --init --rm --no-healthcheck --name ninfer-jarvis-sm80 \
--network container:llama-swap \
--gpus all --ipc host --shm-size 16g \
-e CUDA_SCALE_LAUNCH_QUEUES=4 \
-v /home/your/models:/models:ro \
-v /home/your/llama-swap/logs:/logs \
-v /tmp:/tmp \
cmp170hx-ninfer:sm80-metrics-r1 \
/usr/local/bin/ninfer-serve \
/models/Qwen/qwen3.6_35b-a3b.ninfer \
--host 127.0.0.1 --port ${PORT} \
--model-id qwen3.6-35b-a3b --device 0 \
--max-context 262144 --kv-capacity 262144 \
--max-concurrency 1 --max-pending-requests 4 \
--prefill-chunk 1024 --kv-dtype int8 \
--spec mtp --draft-tokens 3 --lm-head-draft \
--vision --preserve-thinking --no-cuda-graph \
--temperature 0.7 --top-p 0.95 --top-k 40 --min-p 0.0 \
--presence-penalty 1.5 --frequency-penalty 0CMP170HX에서 Qwen3.6-35B를 NInfer로 실행하고 llama-swap이 필요할 때 Docker 컨테이너를 올리도록 구성하는 실행 명령입니다.
cmdStop: "docker stop ninfer-jarvis-sm80"
ttl: 300
useModelName: qwen3.6-35b-a3b
env: ["CUDA_VISIBLE_DEVICES=0"]llama-swap이 NInfer 컨테이너를 중지하고, 300초 TTL과 모델 이름 및 GPU 식별자를 적용하는 설정입니다.
언급된 도구
GPU별 CUDA 커널과 추론 실행 경로를 조정해 Qwen 모델을 로컬에서 서비스하는 추론 엔진입니다.
모델 요청에 따라 Docker 기반 NInfer 컨테이너를 필요할 때 로드하고 timing 및 throughput metrics를 연결하는 모델 관리 도구입니다.
작성자가 NInfer fork와 구분해 언급한 로컬 AI 추론 프로젝트입니다.
Qwen3.6-35B의 비교 측정에 사용된 로컬 추론 구현입니다.
작성자가 NInfer fork와 함께 언급한 로컬 AI 추론 프로젝트입니다.
언급된 리소스
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
