먼저, 이것은 클릭베이트가 아닙니다. 이 결과는 실제입니다. 저는 Qwen 3.8 Flash Next Q2를 실행하여 테스트했던 어떤 Qwen 3.6 35B A3B 파인튜닝이나 Qwen 3.8 27B 모델보다도 더 나은 벤치마크 및 실사용 테스트 결과를 얻었습니다. 또한 현재 사용 중인 Qwen 3.6 35B A3B 설정보다도 빠릅니다. 자세한 내용은 다음과 같습니다.
약 일주일 전, 저는 이 레딧(subreddit)에서 Strata에 대해 배우게 되었고 이것이 무엇을 할 수 있는지 알게 되었습니다. VRAM, RAM, SSD 저장소 전반에 걸쳐 워크로드를 분산하고, 125B 파라미터 모델을 구동하며, 놀라운 프롬프트 처리 속도와 토큰 생성 속도를 제공하는 기능은 거의 너무 좋아서 믿기 어려울 정도였습니다. 하지만 이는 VRAM이 12GB일 경우에만 해당되었습니다. 처음에는 제 장비에서는 비슷한 결과를 얻지 못할 것이라고 생각했지만, 직접 시도해 보기로 했습니다. 그 결과는 저를 놀라게 했고, 그래서 여러분과 공유하고 여러분의 하드웨어에서 모델을 구동하는 데 도움을 드리고자 합니다.
먼저, 제 시스템 사양은 다음과 같습니다:
GPU: RTX 5060 Laptop, 8 GB VRAM
CPU: AMD Ryzen 9 8945HX, 최대 5.4 GHz, 16 코어 / 32 스레드
RAM: 32 GB (16 + 16 GB) DDR5-5200
SSD: 1 TB, 읽기 속도 5,200 MiB/s, 쓰기 속도 4,200 MiB/s
PCIe: Gen 4 x8
OS: Linux
제 Strata 설정은 여기에서 확인할 수 있습니다: Chat (Pastebin) | Chat (GDrive) | Agentic (Pastebin) | Agentic (GDrive).
모델 및 전문가 파일의 경로를 업데이트하는 것을 기억하십시오. 일반적인 채팅과 같은 단일 세션으로 모델을 사용하려면 Chat 구성을 사용하십시오. 에이전트 기반 시스템에서와 같이 여러 세션 및 위임(delegation) 작업을 처리할 때는 Agentic을 사용하십시오. 차이점은 아래에서 더 자세히 설명하겠습니다.
튜닝해야 할 주요 매개변수:
--mmap-experts: 메모리에 맞지 않는 전문가(experts)들을 SSD에 배치합니다.
--kv-resident 20480: KV 캐시를 VRAM과 RAM 사이에 분산합니다. 이 값을 낮추면 더 많은 VRAM을 확보할 수 있습니다. 20480은 최소값입니다.
--vram-reserve-mib 500: 다른 작업을 위해 일부 VRAM을 남겨둡니다. 제 설정에서는 500이 작동 가능한 가장 낮은 값이었지만, 저는 900을 사용하는 것을 권장합니다.
--pcie-frac 0.35는 레이어별 VRAM 누락(misses) 중 GPU가 PCIe를 통해 읽어오는 비율을 제어합니다. 이 매개변수는 캘리브레이션 명령어 ./setup.sh --calibrate .를 사용하여 조정할 수 있습니다. 저는 제 환경에 가장 적합한 값을 찾았습니다. 프롬프트 처리 속도에 만족하지 못한다면 직접 캘리브레이션 할 수도 있습니다.
STRATA_RESIDENT_HEADROOM_GIB=4는 다른 작업을 위해 RAM을 GiB 단위로 예약합니다. Windows를 사용한다면 이 값을 더 높게 설정하십시오. 제 환경에서 가장 큰 성능 향상은 --vram-reserve-mib와 STRATA_RESIDENT_HEADROOM_GIB를 조정하면서 얻었습니다.
저는 Gyro S 모델을 사용했는데, 이것이 제 하드웨어에 가장 적합한 양자화(quant)라고 생각하며 테스트한 모델들 중에서 가장 강력한 결과를 보여주었기 때문입니다. 이전에 GSQ-RCO Coder, GSQ-RCO IQ2_XS 및 다른 양자화 모델들을 시도했지만, 반복 루프에 빠지거나 영어 외의 언어 처리에 어려움을 겪었습니다. Gyro S는 품질과 속도 사이에서 좋은 균형을 제공합니다.
저는 MTP를 사용하지 않습니다. 이는 TG(Token Generation)를 개선할 수 있지만, VRAM을 소모하고 PP(Prompt Processing)를 감소시키므로 이 환경에서는 트레이드오프가 더 나쁠 가능성이 높습니다. VRAM이 10GB 이상이라면 활성화할 수 있습니다.
저는 Vision 처리를 CPU에서 실행합니다. 이미지당 약 1~2초가 소요되지만, 이는 상당한 양의 VRAM을 절약해 줍니다. Strata는 Vision을 별도의 프로세스로 실행하므로 스왑(swap)으로 옮길 수 있습니다. 이는 모델 성능에 큰 영향을 주지 않으면서 더 많은 RAM을 확보해 줍니다.
병렬 에이전트 호출을 위해 로컬 모델을 사용하는 경우 중요한 제한 사항이 하나 있습니다. 컨텍스트 크기가 131K 토큰 이상일 경우, --parallel을 안전하게 사용할 수 없습니다. 왜냐하면 이 옵션은 VRAM과 RAM 모두를 대량으로 소모하기 때문입니다. 이는 속도의 급격한 저하나 Out-of-Memory (OOM) 오류를 유발할 수 있습니다.
더 안전한 대안은 --conversation-cache입니다. 이는 제한된 수의 세션을 보관하여 순차적으로 재개할 수 있게 합니다. 이것이 진정한 병렬 처리를 제공하지는 않지만, 세션 간 전환 시 긴 컨텍스트를 다시 읽어야 하는 것을 방지해 줍니다.
다음은 관련 파라미터들입니다: --conversation-cache-mib 4096 - 주차된 세션 캐시의 크기입니다. 이 값을 더 크게 설정하면 세션의 캐시가 제거되어 컨텍스트를 다시 읽어야 할 가능성을 줄일 수 있습니다. --conversation-cache-slots 2 - 주차된 세션 슬롯의 개수입니다. 두 개의 슬롯은 한 번에 두 개의 세션을 저장할 수 있게 합니다. --conversation-cache-min-tokens 8000 - 토큰 수가 이 임계값 이하인 경우 캐싱하지 않습니다. 적절한 값은 사용자의 PP 속도와 해당 토큰들을 처리하기 위해 기다릴 의향이 있는 시간에 따라 달라집니다. --conversation-cache-min-free-mib 1024 - 캐싱 시 보존해야 하는 최소 여유 RAM 양입니다. 새 항목을 캐시하는 것이 약 1,024 MiB의 여유 RAM만 남기게 된다면, OOM(Out Of Memory) 위험을 줄이기 위해 이전 캐시가 지워집니다. 이 파라미터들을 직접 조정할 때는 주의해야 합니다: 잘못된 설정은 시스템 안정성에 영향을 주거나 모델이 과도한 스와핑(swapping) 상태에 빠지게 할 수 있습니다. 시스템에서 사용 가능한 총 메모리를 초과하지 마십시오. 모든 테스트는 Linux에서 실행되었는데, 이는 RAM 할당 측면에서 더 많은 유연성을 제공합니다. Windows를 사용하는 경우, 모델에 할당하는 메모리를 줄여보세요. 이렇게 하면 처리량(throughput)이 상당히 감소하지만, 메모리 부족 위험도 낮출 수 있습니다. 저는 Linux 환경에서 다른 애플리케이션을 위해 전용 32 GB 스왑 파티션(swap partition)을 생성했습니다. 또한, 시스템d 서비스를 사용하여 서버 프로세스를 메모리에 고정(pinning)하여 스와핑되는 것을 막았으며, 이 설정은 다음과 같습니다: [Service] MemorySwapMax=0. 이는 서버의 메모리가 스와핑되어도 캐시된 컨텍스트나 주차된 세션 캐시가 크더라도 일관된 읽기 및 쓰기 성능을 유지하는 데 도움이 됩니다. Chat 구성을 사용했을 때 얻은 결과는 다음과 같습니다: 262K 컨텍스트: PP 800-970 t/s 및 TG 30-40 t/s, 131K 컨텍스트: PP 930-1,040 t/s 및 TG 30-45 t/s. Agentic 구성을 사용했을 때 얻은 결과는 다음과 같습니다: 262K 컨텍스트: PP 520-740 t/s 및 TG 30-40 t/s, 131K 컨텍스트: PP 670-890 t/s 및 TG 30-45 t/s. 제 관점에서 볼 때, 이는 매우 뛰어난 결과이며, llama.cpp에서 실행된 Qwen 3.6 35B A3B와 비교해도 그렇습니다.
Qwen 3.6 35B A3B를 사용하고 VRAM 제약이 있는 expert layout과 MTP/Vision을 비활성화했을 때, 저는 PP(tokens/s) 630-680 t/s와 TG(tokens/s) 27-35 t/s를 얻었습니다. 오늘날에도 Qwen 3.6 35B A3B가 에이전트 작업(agentic tasks)에 여전히 사용할 가치가 있다고 생각하시나요? Strata는 응답 품질에는 영향을 미치지 않습니다. 대신, 사용 가능한 리소스 전반에 걸쳐 모델을 분산시키고 자주 사용되는 expert를 메모리에 유지하는 데 도움을 줍니다. 이것은 여러 가지 주요 최적화 중 하나일 뿐입니다. 모델의 양자화(quantization)가 출력 품질에 영향을 미치는 요소입니다. VRAM이 8GB보다 많다면, Gyro M/L이나 다른 양자화 버전을 시도해 볼 수 있습니다. 제 설정을 시작점으로 사용하시고 자신의 하드웨어와 워크로드에 맞게 조정하십시오. 사용자님의 컴포넌트 조합과 사용 사례는 저와 다를 수 있습니다.
실제 품질 테스트
이제 이 하드웨어에 모델을 구동하는 방법을 다루었으니, 출력물의 품질을 살펴보겠습니다. 몇 가지 대표적인 테스트들을 포함했습니다. 저는 광범위한 벤치마크 스위트나 표준화된 평가를 수행하지 않았습니다. 대신 지난주 동안 실용적이고 일상적이며 까다로운 작업에 모델을 테스트하는 데 시간을 보냈습니다. 더 넓은 범위의 벤치마킹 테스트는 커뮤니티에 맡기겠습니다. 저는 Ornith 1.5 Heretic을 기반으로 현재 고성능 환경인 Cyber-Tiel 35B A3B와 비교할 것입니다. Tiel 35B A3B는 종종 반복적이고 순환하는 응답을 주었기 때문에, 저는 Cyber-Tiel로 전환했습니다. Flint 모델은 최근에 출시되었지만, 이 비교에는 포함하지 않겠습니다. 제 관점에서는 Qwen 3.6보다 뒤처지므로, 나중에 두 가지를 비교하고 그 테스트들을 본문에 추가할 수도 있습니다.
테스트 1: Pagoda
이 테스트는 최소한의 도구 세트(LSP 및 Playwright MCP)가 있는 Pi Agent에서 실행되었습니다. Qwen Flash Next Gyro S의 경우, reasoning_effort를 'high'로 설정했습니다. https://reddit.com/link/1xft2ae/video/vycdc57ifsxh1/player
테스트 2: Flappy Bird 클론
조건은 이전 테스트와 동일했습니다. https://reddit.com/link/1xft2ae/video/97i98026fsxh1/player
테스트 3: Pelican
이 테스트에서는 두 가지 다른 모델뿐만 아니라 Qwen Flash Next Gyro S에 대한 다양한 reasoning_effort 설정도 비교했습니다.
에이전트 환경은 동일했습니다: Pi Agent. https://preview.redd.it/ifhdl3y7fsxh1.png?width=2067&format=png&auto=webp&s=e9eb5d9ad5046a2a58d339406ab83f8f4429f1c4 저는 더 많은 테스트를 실행했지만, 기밀 유지상의 이유로 공유할 수 없습니다. 제가 말씀드릴 수 있는 것은 모든 코딩 에이전트를 이 모델로 교체했다는 것입니다. 그 변화 덕분에 개발 속도가 빨라졌고 코드 품질은 5배 향상되었습니다. 이 예시들에서 볼 수 있듯이, 결과는 8GB의 VRAM에 맞는 제가 테스트했던 다른 어떤 모델보다도 좋습니다. Qwen 3.8 Flash Next는 인상적이며, Gyro S 양자화(quant) 덕분에 저와 같은 하드웨어에서도 로컬 코딩 및 에이전트 작업(agentic tasks)을 위해 이 모델을 실행할 수 있게 합니다. 이 게시물의 목표는 여전히 Qwen 3.6 35B A3B 또는 그 파인튜닝(fine-tunes) 버전을 로컬에서 사용하는 사람들에게, 제 경험상 이를 훨씬 능가하는 모델이 생겼다는 것을 보여주는 것입니다. 예시들이 이러한 주장을 뒷받침하기를 바랍니다. 저는 항상 다른 관점에 열려 있으니, 댓글로 비판을 자유롭게 공유해 주세요. 구성에 대한 제안이나 개선 사항이 있다면 그것도 공유해 주십시오. 다른 사용자들도 이점(benefit)을 얻을 수 있습니다. 제가 드릴 말씀은 여기까지입니다. 좋은 도구를 사용하시고, 즐거운 코딩 되세요! /u/BleynSpecnaz 제출 [link] [comments]