Qwen3.8 Basalt 벤치마크, 16GB VRAM에서 초당 153토큰 보고

10월 25일 게시된 Qwen3.8 Basalt 벤치마크 결과는 16GB 그래픽 메모리 한계에도 불구하고 RTX 5080에서 초당 153토큰을 기록했다고 보고했다. 워크스테이션은 시스템 메모리도 54.1GB 사용했다. 게시물의 제목은 초당 250토큰 이상의 생성 성능을 강조하지만, 이 수치는 지속 출력이 아닌 짧은 순간의 최고치다.

이 차이는 로컬 코딩 어시스턴트를 고려하는 개발자에게 중요하다. 게시자에 따르면 세션은 103개의 요청을 처리했으며, 별도 테스트에서는 서로 다른 컨텍스트 길이에서 새로운 프롬프트를 처리했다. 이 작업 부하는 반응성에 관한 유용한 근거를 제공하지만, 어느 쪽도 코딩 정확성이나 독립적으로 검증된 성능을 입증하지는 않는다.

핵심 쟁점은 유용한 속도와 수용 가능한 출력을 유지하면서 대형 모델을 워크스테이션에 탑재하는 일이다. 특화 추론 엔진인 Basalt는 Strata 및 llama.cpp 같은 더 폭넓은 대안과 이 작업 부하를 두고 경쟁한다. 이 보고서는 그래픽 메모리 용량이 더 이상 중요하지 않다는 일반적 주장이 아니라, 이 접근법을 더 면밀히 조사할 근거를 제공한다.

Qwen3.8 Basalt 벤치마크는 최고치와 지속 속도를 구분한다

가장 유용한 생성 수치는 보고된 평균값이다. 코딩 중 초당 153.0토큰, 컨텍스트 스윕 중 초당 154.9토큰이다.

토큰은 언어 모델이 처리하거나 생성하는 텍스트 단위다. 초당 토큰 수는 처리량을 측정하지만, 생성된 코드가 실제로 작동하는지를 직접 측정하지는 않는다. 평균 출력과 최고 출력의 구분은 이 결과를 요약할 때마다 유지할 필요가 있다.

RTX 5080 benchmark는 모델 구성을 Qwen3.8-Flash-Next IQ3_S로 명시한다. IQ3_S는 양자화 형식으로, 모델 가중치를 낮은 수치 정밀도로 표현한다는 뜻이다. 이 구성은 서로 바꿔도 되는 세부 사항이 아니라 결과의 정체성을 이루는 일부다.

보고된 워크스테이션은 RTX 5080에 Core Ultra 9 285K 프로세서와 62GB DDR5-6800 메모리를 조합했다. 그래픽 메모리 사용량은 15.7GB에 이르렀다. 엔진은 시스템 메모리 54.1GB를 사용한 것으로 알려졌으며, 코딩 중에는 5.2GB, 스윕 중에는 5.1GB가 남았다.

코딩 세션은 코딩 에이전트 인터페이스인 opencode를 사용해 103개 요청을 처리했고, 약 130,000토큰의 컨텍스트에 도달했다. 컨텍스트는 모델이 응답을 생성할 때 사용할 수 있는 정보다. 출처는 약 262,000토큰의 구성된 용량을 보고했으며, 이는 코딩 세션에서 관찰된 깊이를 초과한다.

게시자에 따르면 생성은 생성 토큰과 디코드 시간을 기준으로 초당 평균 153.0토큰을 기록했다. 디코드 시간은 출력 토큰을 생성하는 데 쓰이는 기간이다. 보고된 초당 262토큰의 최고치는 전체 요청이나 세션이 아니라 가장 성능이 좋았던 개별 1초를 포착한 수치다.

별도 스윕은 약 15,000~207,000토큰 범위의 새로운 프롬프트를 사용했다. 생성 평균은 초당 154.9토큰에 도달했고 최고치는 186.6이었다. 게시자는 이 측정값을 요청 평균으로 설명하며, 384토큰 응답, 샘플링 온도 0.7, 각 깊이당 두 번의 실행을 사용했다.

이러한 정의는 오해를 막는다. 1초 단위 최대치와 요청 수준 평균은 서로 다른 관측값을 설명한다. 둘 다 초당 토큰 수를 사용한다는 이유만으로 어느 하나가 다른 하나를 대체해서는 안 된다.

지속 성능 수치는 이 보고서를 제목만으로 보이는 것보다 더 흥미롭게 만든다. 코딩 워크플로는 반복 상호작용 전반에서 일관된 응답을 필요로 한다. 짧은 순간의 폭발적 성능은 시스템 특성을 파악하는 데 도움이 되지만, 개발자가 실제로 경험하는 것은 완전한 요청, 중단, 도구 실행, 수정이다.

이 수치는 여전히 자체 보고된 측정값이다. 이용 가능한 근거는 게시자가 무엇을 보고했는지와 측정 범주를 설명할 뿐이다. 다른 워크스테이션이 같은 결과를 재현하거나 모든 요청이 집계 평균을 유지했다는 사실을 입증하지는 않는다.

캐시 재사용이 응답 시간의 의미를 바꾼다

보고된 중앙값 0.2초의 응답 시작 시간은 프롬프트 토큰 캐시 재사용률이 99.5%인 세션에 해당한다.

프롬프트 캐싱은 이전 입력에서 이미 계산한 정보를 다시 처리하는 대신 재사용한다. 연속된 요청이 대화 기록, 저장소 자료, 지침을 자주 공유하는 코딩 세션에서는 이 동작이 중요하다. 이러한 작업을 재사용하면 진행 중인 세션의 체감 반응성이 크게 향상될 수 있다.

게시자는 프롬프트 토큰의 99.5%가 프롬프트 캐시에서 왔다고 보고했다. 첫 토큰까지 걸리는 중앙값 시간은 0.2초였다. 첫 토큰까지의 시간은 답변을 완료하는 데 필요한 시간이 아니라 출력이 시작되기 전의 지연을 측정한다.

함께 보면, 이 수치는 반복 상호작용에 유리한 작업 부하를 설명한다. 엔진이 전혀 익숙하지 않은 긴 저장소 프롬프트를 읽고 같은 지연 시간 내에 응답을 시작할 수 있음을 보여주지는 않는다. 새로운 요청은 별도로 평가해야 한다.

출처는 캐시되지 않은 처리 측정을 통해 이 차이를 일부 다룬다. 코딩 세션에서 프롬프트 처리는 초당 평균 5,011토큰, 최고 5,118토큰을 기록했다. 게시자는 이 수치가 각각 약 10,700개와 8,000개의 새 토큰을 포함한 두 번의 상당한 규모의 비캐시 읽기를 나타낸다고 밝혔다.

프롬프트 처리는 답변을 생성하기 전에 입력을 받아들이는 데 필요한 계산이다. 이 단계에서 모델은 다른 작업을 수행하므로 처리량은 생성 처리량과 다르다. 이를 하나의 속도 주장으로 합치면 독자에게 필요한 정보가 가려진다.

새 프롬프트 스윕에서는 프롬프트 처리 처리량이 초당 평균 5,475토큰, 최고 5,662토큰으로 보고됐다. 이는 입력 처리에 관한 별도의 관측값을 제공한다. 누군가 엔진의 반응성을 설명할 때는 캐시 비중이 높은 코딩 결과와 함께 제시해야 한다.

개발자에게 주는 함의는 작업이 컨텍스트를 어떻게 축적하는지에 따라 달라진다. 같은 프로젝트를 반복적으로 다시 살펴보는 어시스턴트는 유지된 계산의 이점을 얻을 수 있다. 문서를 자주 교체하거나 저장소를 바꾸는 워크플로는 다른 작업 부하를 만든다.

프로젝트를 읽고, 편집안을 제안하고, 컴파일러 오류를 받은 뒤 패치를 수정하는 에이전트를 생각해 보자. 주변 정보의 상당 부분은 이러한 차례에 걸쳐 계속 관련성을 가진다. 따라서 모델의 기본 생성 속도가 변하지 않아도 캐시 동작은 경험에 영향을 줄 수 있다.

반대로 하루 종일 서로 관련 없는 문서 모음을 여는 분석가를 생각해 보자. 반복되는 자료의 비중은 더 낮을 수 있다. 코딩 세션의 중앙값 응답 지연을 이 워크플로에 적용하려면 게시물이 제공하지 않는 근거가 필요하다.

따라서 캐싱은 보고된 결과의 실질적인 일부다. 사용자가 벤치마크를 예측치로 받아들이기 전에 자신의 요청 패턴을 살펴봐야 하는 이유를 설명한다. 결정적인 질문은 애플리케이션이 실제로 얼마나 많은 계산을 재사용할 수 있는가다.

시스템 메모리가 워크스테이션의 절충점을 떠안는다

16GB 그래픽 카드는 이 구성을 지탱하지만, 보고된 작업 부하는 시스템 메모리 54.1GB에도 의존한다.

VRAM은 그래픽 프로세서에 연결된 메모리이며, 시스템 RAM은 더 넓은 컴퓨터 환경을 지원한다. 이 보고서는 둘 다 사용한다. 결과를 그래픽 카드만으로 설명하면 관련된 시스템 자원을 축소해 보이게 하고, 잠재적 사용자에게 중요한 실질적 제약을 가린다.

expert memory design은 Basalt를 NVIDIA Blackwell 하드웨어를 목표로 하는 Strata 포크로 설명한다. 이는 계산을 위해 특화된 모델 구성 요소를 선택하는 mixture-of-experts 모델을 실행한다. 그래픽 메모리 용량을 초과하는 전문가 구성 요소는 시스템 RAM에 상주할 수 있다.

이 설계는 이 특정 벤치마크를 독립적으로 검증하지 않고도 전반적인 접근법을 설명한다. 프로젝트 문서는 시스템 메모리 사용이 의도된 것임을 보여준다. Reddit 측정값은 명시된 워크스테이션의 보고된 속도와 메모리 소비량을 제공한다.

실질적인 부담은 기존 장비가 로컬 어시스턴트를 지원할 수 있는지 결정하는 개발자에게 돌아간다. 그래픽 메모리 용량만으로는 불완전한 답이 된다. 사용 가능한 시스템 메모리, 다른 애플리케이션, 작업 부하의 컨텍스트 요구 사항도 같은 평가에 포함해야 한다.

보고된 여유 메모리 수치는 특히 주목할 만하다. 코딩 중 5.2GB가 남았다는 사실이 불안정성을 입증하지는 않지만, 해당 테스트 장비의 여유 용량이 제한적이었음을 보여준다. 에디터, 브라우저, 빌드 프로세스 또는 다른 로컬 서비스는 추가 수요를 만든다.

그렇다고 모든 비슷한 워크스테이션이 일반적인 개발 환경에서 실패한다는 뜻은 아니다. 이 벤치마크가 쾌적한 멀티태스킹을 보장할 수 없다는 의미다. 사용자는 추론 엔진이 단독으로 작동할 때가 아니라 실제 개발 환경이 실행 중일 때 측정한 결과가 필요하다.

같은 논리는 그래픽 메모리 수치에도 적용된다. 보고된 15.7GB 사용량은 해당 카드의 16GB 용량에 근접한다. 이 관측은 관련 없는 그래픽 작업 부하나 다른 엔진 설정을 위한 넉넉한 여유 공간을 가정하지 않도록 해야 한다.

여기서 제목의 매력은 운영상의 절충점과 맞닿는다. 이 보고서는 작업 부하가 가용 자원 전반에 걸쳐 들어맞도록 하는 할당 전략을 설명한다. 적당한 그래픽 메모리 예산 안에서만 모델이 완전히 작동한다는 설명은 아니다.

따라서 구매 결정은 전체 워크스테이션에서 시작해야 한다. 그 외에는 제약이 많은 장비에 호환 그래픽 카드를 추가한다고 해서 보고된 환경이 재현되는 것은 아니다. 메모리 용량을 맞춘다고 해서 프로세서 동작, 소프트웨어 설정, 지속 처리량까지 반드시 재현되는 것도 아니다.

지식 집약적 애플리케이션에는 또 다른 고려 사항이 있다. 소스 자료를 정리하는 일은 모델을 실행하는 일과 별개로 남는다. searchable knowledge base는 문서 접근성을 다루는 반면, 이 벤치마크는 입력이 엔진에 도달한 뒤의 계산을 다룬다.

유용한 결론은 구체적이다. 이 구성을 평가하는 개발자는 추론과 주변 도구 모두를 위한 메모리를 예산에 포함해야 한다. 보고된 속도는 이 평가를 할 가치가 있게 하지만, 시스템 메모리 요구 사항은 여전히 결과의 핵심이다.

Strata와 llama.cpp에는 조건을 맞춘 비교가 필요하다

이 워크스테이션 보고서는 Basalt, Strata, llama.cpp 간의 통제된 성능 순위를 입증하지 않는다.

제목은 Strata와 Basalt를 함께 언급하지만, 제공된 작업 부하 설명은 사용된 엔진이 Basalt임을 밝힌다. 독자는 이 구분을 유지해야 한다. 포크의 결과가 자동으로 상위 프로젝트의 성능 주장으로 바뀌어서는 안 된다.

Strata는 Basalt의 계보를 제공하며, llama.cpp는 또 다른 관련 로컬 추론 기준점이다. 이들의 존재는 경쟁 구도를 형성한다. 일치하는 모델 파일, 설정, 하드웨어, 요청 순서 없이는 승자를 선언할 근거가 되지 않는다.

inference benchmark documentation은 프롬프트 처리와 텍스트 생성을 구분하고, 지정된 컨텍스트 깊이에서의 테스트를 지원한다. 또한 반복 측정값을 기록한다. 이러한 범주는 제목의 처리량 수치를 나란히 놓는 것 이상이 비교에 필요한 이유를 보여준다.

동일 조건의 비교라면 엔진 간 워크로드를 알아볼 수 있을 만큼 일관되게 유지해야 한다. 동일한 프롬프트, 응답 길이, 모델 표현 방식, 컨텍스트 조건이 평가의 기준점이 되어야 한다. 그렇지 않으면 겉보기의 소프트웨어 우위에는 설정의 다른 차이가 포함될 수 있다.

캐시 조건도 동등하게 다뤄야 한다. 이미 워밍업된 코딩 세션과 낯선 프롬프트를 비교하면, 생성이 시작되기도 전에 후자에 불리한 조건이 된다. 두 시나리오 모두 유용하지만, 서로 다른 운영상 질문에 답하므로 별도의 결과로 제시해야 한다.

엔진에 차이를 귀속하려면 하드웨어 구성 역시 고정되어야 한다. 다른 사용자의 더 빠른 그래픽 카드나 더 큰 메모리 예산은 추가 변수가 된다. 이 정보는 탐색의 방향을 잡는 데 도움이 될 수 있지만, 소프트웨어만의 기여를 입증하지는 못한다.

출력 동작도 또 다른 복잡성을 낳는다. 추측 디코딩은 모델이 출력을 수용하기 전에 검증하는 초안 토큰을 사용한다. 이러한 가속이 포함된 비교라면 설정을 공개하고, 측정한 구성이 어떤 동작을 유지하는지 검증해야 한다.

관련 기준은 정확한 실행에 관한 투명성이다. 독자는 모델 아티팩트, 소프트웨어 리비전, 구성, 측정 방법을 식별할 수 있어야 한다. 익숙한 모델 이름이 동일한 수치 표현이나 동일한 출력을 보장하지는 않는다.

호스팅형 코딩 서비스를 대체한다는 주장에도 같은 주의가 필요하다. 이 보고서는 코딩 세션 중의 로컬 추론 동작을 측정한다. 완료된 작업, 개발자 개입, 서비스 안정성 또는 호스팅형 대안 대비 통합 노력에 대한 동일 조건의 평가는 제공하지 않는다.

엔진 유지보수자에게 경쟁 압력은 더 좁은 범위에서 여전히 현실적이다. 유망한 워크스테이션 보고서는 사용자에게 특화된 구현을 살펴볼 이유를 제공한다. 중요한 대응은 각 엔진이 어디에서 뛰어난 성능을 보이는지 보여 주는 재현 가능한 증거다.

개발자에게는 순위보다 후보 목록이 더 타당하다. Basalt는 보고된 지속 속도가 대화형 작업과 관련 있으므로 호환 하드웨어에서 테스트할 가치가 있다. Strata와 llama.cpp 역시 동일한 조건에서 동작을 측정해야 하는 비교 후보로 남는다.

빠른 생성 속도가 코딩 품질을 입증하지는 않는다

빠진 연결 고리는 작업 성능이다. 이 보고서는 생성된 코드가 문제를 얼마나 안정적으로 해결하는지는 확립하지 않은 채 출력 속도만 측정한다.

코딩 세션은 고립된 텍스트 생성보다 더 알아보기 쉬운 워크로드를 제공한다. 이는 에이전트 인터페이스가 반복 요청을 보냈다는 점을 보여 준다. 하지만 요청 횟수만으로는 성공적인 수정, 통과한 테스트, 불필요한 재시도 또는 사람의 수정을 알 수 없다.

이 구분은 양자화에서 특히 중요해진다. 수치 정밀도를 낮추면 실행되는 모델 표현 방식이 바뀐다. 더 빠르거나 더 작은 구성도 사용자가 맡기려는 작업에서 평가가 필요하다.

공개된 양자화 모델 평가는 텍스트 청크와 고정밀 기준을 사용해 제한적인 품질 증거를 제시한다. 이 비교는 모델 동작을 특성화하는 데 도움이 된다. 하지만 리포지터리 수정 정확도, 신뢰할 수 있는 도구 사용 또는 성공적인 장문 컨텍스트 코딩을 입증하지는 않는다.

긴 컨텍스트는 관련된 검증 공백을 만든다. 시스템은 긴 프롬프트를 받을 수 있지만, 모든 관련 세부 사항을 안정적으로 적용하지 못할 수 있다. 처리 용량과 해당 입력 내 검색 정확도는 둘 다 동일한 사용자 경험에 영향을 미치더라도 서로 다른 특성이다.

따라서 컨텍스트 스윕은 범위를 제한해 해석해야 한다. 이는 길이가 다른 새 프롬프트 전반의 처리량을 보고한다. 모델이 묻혀 있는 요구 사항을 일관되게 찾아냈는지, 상충하는 지침을 조정했는지, 또는 코드를 편집하면서 프로젝트 제약을 유지했는지는 입증하지 않는다.

집계된 생성 속도 역시 경험의 분포를 불분명하게 남긴다. 평균은 더 느린 요청을 숨긴 채 세션을 요약할 수 있다. 어려운 수정을 기다리는 개발자는 가장 빠른 순간적 속도보다 그러한 지연을 더 중요하게 여길 수 있다.

같은 한계는 응답 시작 중앙값에도 적용된다. 중앙값은 중간 관측치를 설명한다. 가장 긴 대기 시간, 캐시 미스 이후의 동작, 또는 완전하고 사용 가능한 패치를 받는 데 걸리는 시간은 보여 주지 않는다.

동시 요청을 뜻하는 동시성은 또 다른 경계 조건을 더한다. 이 요약 자료는 동시성을 1로 명시한다. 이는 결과가 개별 스트림과 관련 있음을 뜻하지만, 공동 팀의 처리 용량이나 겹치는 에이전트 요청에서의 성능을 추정할 근거는 제공하지 않는다.

이러한 공백은 보고된 성과를 지우지 않으면서 해석의 기준이 되어야 한다. 출처는 명시적인 측정 정의를 제공하고 워크로드 유형을 구분한다. 이러한 세부 사항은 최고 속도만 보여 주는 설명 없는 스크린샷보다 주장을 더 평가 가능하게 만든다.

독립 재현은 기존 처리량 범주에 작업 결과를 추가해야 한다. 유용한 코딩 평가는 테스트 통과 여부, 변경이 요청을 충족하는지, 사람이 얼마나 자주 개입하는지를 기록할 것이다. 성공한 실행만 보고하지 말고 실패도 보존해야 한다.

Qwen3.8 Basalt 벤치마크에서 해결되지 않은 질문은 보고된 응답성이 신뢰할 수 있는 작업 결과를 동반하는지다. 동일 조건의 작업 증거가 나오기 전까지 속도는 구성의 실행에 대한 증거일 뿐, 더 나은 코딩 어시스턴트를 제공한다는 증거는 아니다.

결과가 얼마나 널리 적용될지를 결정할 세 가지 신호

다음 증거는 이 순서대로 재현성, 코딩 신뢰성, 덜 유리한 운영 조건에서의 성능을 확립해야 한다.

첫 번째 신호는 비교 가능한 RTX 5080 워크스테이션에서의 독립 재현이다. 유용한 공개 자료에는 정확한 모델 아티팩트, 엔진 리비전, 구성, 요청 순서 및 원시 타이밍 기록이 포함되어야 한다. 반복 실행은 캐시 의존도가 높은 세션과 새 입력을 구분해야 한다.

근접한 재현은 이 구성이 개별 개발자에게 반복 가능한 선택지를 제공한다는 주장을 강화할 것이다. 상당한 차이가 난다면 이를 하드웨어, 소프트웨어 또는 워크로드 탓으로 돌리기 전에 조사가 필요하다. 어느 결과든 사용자에게 제공되는 증거를 개선할 것이다.

재현은 원래의 측정 구분을 유지해야 한다. 세션 평균 생성, 요청 평균 생성, 1초 단위 피크는 분리된 상태로 남아야 한다. 관측된 최고 순간 속도만 맞추는 것으로는 가장 중요한 지속 성능 주장이 여전히 해결되지 않는다.

두 번째 신호는 동일한 양자화 구성을 사용한 코딩 평가다. 그 가치는 또 다른 생성 속도 차트가 아니라 완료된 작업과 기록된 수정에서 나올 것이다. 이 평가는 에이전트가 실제로 필요로 하는 프로젝트 컨텍스트를 포함해야 한다.

강력한 작업 결과는 처리량 보고서가 소프트웨어 개발에 갖는 중요성을 높일 것이다. 생성 속도가 빠르게 유지되더라도 잦은 실패는 그 매력을 좁힐 것이다. 사용할 수 없는 패치를 더 빨리 만들어도 작업을 마치는 데 필요한 노력은 줄어들지 않는다.

세 번째 신호는 더 폭넓은 운영 조건에서의 성능이다. 관련 증거에는 낯선 긴 프롬프트, 더 긴 출력, 추론과 함께 실행되는 일반 개발 애플리케이션, 겹치는 요청이 포함된다. 각 조건은 보고된 경험이 워크로드 변화에서도 유지되는지 검증한다.

안정적인 동작은 신중하게 관찰된 개인 세션을 넘어 이 구성을 사용할 근거를 강화할 것이다. 메모리 압박, 더 긴 대기, 또는 저하된 출력은 실용적 경계를 드러낼 것이다. 이러한 경계는 사용자가 엔진을 단순히 배제하기보다 워크로드를 선택하는 데 도움이 된다.

이 신호들 중 어느 것도 출시일을 지어내거나 불가피한 승자를 예측할 필요가 없다. 이는 유지보수자와 독립 사용자가 향후 몇 달 동안 공개할 수 있는 구체적인 증거 형태다. 현재 게시물은 그 작업을 위한 유용한 출발점을 제공한다.

더 넓은 함의는 여전히 구체적이다. 그래픽 메모리 16GB를 갖춘 워크스테이션이 상당한 시스템 메모리도 사용하면서 대화형 생성을 지속했다는 보고가 있다. 이는 그래픽 메모리 용량만으로 로컬 추론을 판단하는 것보다 전체 시스템 평가를 더 중요하게 만든다.

설정을 바꾸기 전에 Qwen3.8 Basalt 벤치마크를 자신의 작업에서 가져온 세션과 비교하라. 프롬프트를 보존하고, 캐시가 무엇을 재사용하는지 기록하며, 결과 수정이 자신의 검사를 통과하는지 확인하라. 보고된 머신은 여유 시스템 메모리가 제한적이었으므로 평소 열어 두는 애플리케이션도 포함하라. 응답 시작 지연과 완료 시간을 분리하고, 지속 출력은 지속 출력과 비교하라. 결정은 자신의 조건에서 완료된 유용한 작업을 기준으로 내려야 한다. 재현 가능한 실행이 정확한 변경, 수용 가능한 대기 시간, 그리고 나머지 개발 환경을 위한 충분한 여유 메모리를 제공할 수 있는가?