각각 22GB VRAM을 가진 2개의 구형 RTX 2080 Ti로 f16 KV cache를 사용하여 Qwen3.6 27B를 38

제 카드 두 장 모두 전력이 150W로 제한되어 있다는 점을 꼭 유념해 주세요 (소음이 싫어서요).

그저 저의 현재 설정을 공유하여 다른 사용자분들에게 도움이 될까 하여 올립니다...

services:
  llama-server:
    image: ghcr.io/ggml-org/llama.cpp:full-cuda12-b9128
    container_name: llama-server
    restart: unless-stopped
    ports:
      - "16384:8080"
    volumes:
      - ./models:/models:ro
    command: >
      --server
      --model /models/Qwen3.6-27B-IQ4_XS-uc.gguf
      --alias "Qwen3.6 27B"
      --temp 0.6
      --top-p 0.95
      --min-p 0.00
      --top-k 20
      --port 8080
      --host 0.0.0.0
      --cache-type-k f16
      --cache-type-v f16
      --fit on
      --presence-penalty 1.32
      --repeat-penalty 1.0
      --jinja
      --chat-template-file /models/Qwen3.6.jinja
      --mmproj /models/Qwen3.6-27B-mmproj-BF16.gguf
      --webui
      --spec-default
      --chat-template-kwargs '{"preserve_thinking": true}'
      --reasoning-budget 8192
      --reasoning-budget-message "... thinking budget exceeded, let's answer now.\n"
      --split-mode tensor
    user: "1000:1000"
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    environment:
      - NVIDIA_VISIBLE_DEVICES=all

이것이 저의 정확한 설정입니다. 저의 매우 오래된 2080Ti GPU 2장은 중국에서 각각 22GB VRAM을 갖도록 업그레이드되었습니다... 그리고 eBay에서 NVLINK를 구매했습니다 (측정 가능한 차이가 나타나지 않으므로 구매를 추천하지는 않습니다).

제가 실행하는 양자화 (Quantisation)는 IQ4_XS입니다.

만약 KV 캐시 (KV cache)를 q8_0로 변경하면, 긴 코딩 세션 중에 모델이 루프를 도는 현상이 가끔 발생합니다. 이것이 제가 f16 KV 캐시를 사용하는 이유이며, 그 이후로는 이런 문제를 전혀 겪지 않고 있습니다.

저는 hauhaucs의 Qwen3.6 모델 (uncensored, IQ4 matrix quants 적용)을 사용합니다.

해당 그래픽 카드들은 대역폭 제한 (bandwidth bound)이 아닌 연산 제한 (compute bound) 상태이므로, MTP (Multi-Token Prediction)에 대해서도 고려할 필요가 없습니다.

가장 압도적인 성능 향상은 --split-mode tensor 옵션에서 왔으며, 이를 통해 14 token/s에서 38 token/s로 속도가 향상되었습니다.

전력 제한 (power limit)을 해제한다면 45 token/s까지도 가능할 것 같습니다.

또한 제가 미처 생각하지 못했던 부분은 --fit on 옵션입니다. 저는 항상 컨텍스트 길이 (context length)를 수동으로 선언해 왔고 그것도 잘 작동했지만, VRAM 사용량을 항상 95%로 유지하며 실행하는 것은 좋은 생각이 아닌 것 같습니다. --fit on 옵션은 토큰 생성 (token gen) 속도도 약간 개선해 주었습니다.

참고로, 이 설정은 1,000달러 미만의 구성이며 벽 콘센트 기준 피크 전력은 400W이며, hermes 및 opencode와 함께 매우 잘 작동합니다.

제가 사용하는 jinja 템플릿은 다음과 같습니다:
https://huggingface.co/froggeric/Qwen-Fixed-Chat-Templates (이 설정의 template 11을 사용 중이며, 더 최신 템플릿들은 아직 테스트하지 않았습니다.)

프롬프트 처리 (Prompt Processing) 속도는 674t/s입니다 (카드당 150W 전력 제한 상태에서 13k 텍스트 입력을 테스트했을 때 기준).
토큰 생성 (Token Generation) 속도는 38+t/s입니다 (동일한 13k 테스트 및 카드당 150W 전력 제한 상태 기준).