Qwopus v2를 사용하면 Qwen보다 효율적으로 작업을 진행할 수 있을까? 【로컬 LLM 벤치마크】
요약
Qwen3.6을 기반으로 파인튜닝된 Qwopus와 Pi(reasoning/tune) 모델의 성능 및 효율성을 비교 분석한 벤치마크 결과입니다. Claude의 추론 능력을 증류한 Qwopus와 코딩 작업 데이터를 학습한 Pi 모델의 품질 및 작업 속도 차이를 검증합니다.
핵심 포인트
- Qwopus는 Claude Opus의 추론을 증류하여 출력 단축 및 시간 감소를 목표로 함
- Pi 모델은 비공개 코딩 데이터를 통해 태스크 분해 및 디버깅 능력을 강화함
- 모델별 품질(응답 정확도)과 속도(생성 속도 및 태스크 완료 시간)를 다각도로 비교
- 에이전트로서의 파일 조작 및 빌드 포함 실행 능력을 평가 단계에 포함
Qwen3.6을 베이스로 한 파인튜닝 (Fine-tuning) 모델이 잇따라 공개되고 있다. Claude Opus 4.6 / 4.7의 추론을 증류(Distillation)한 Qwopus ※1과, 비공개 코딩 작업 데이터로 추가 학습한 Pi (reasoning / tune)가 대표적인 예다.
각 모델의 특징은 다음과 같다.
표1 비교 대상 모델 계통 베이스 Qwen3.6과 각 파인튜닝 모델의 제작자·학습 데이터·개선점.
| 계통 | 제작자 | 학습 데이터 | 개선점 |
|---|---|---|---|
| Qwen3.6 (기준) | Alibaba | — | 비교 기준 |
| Qwopus | Jackrong | Claude Opus 4.6 / 4.7의 추론을 증류 | 출력을 짧게 하고, 완료 시간을 단축하는 것을 목표로 함 ※1 |
| Pi reasoning | bytkim | 비공개 코딩 작업 데이터 (약 1,200건, 사고 과정 포함) | 태스크 분해·디버깅(Debug) 중시 ※2 |
| Pi tune | bytkim | 비공개 코딩 작업 데이터 (사고 과정 없음, 건수 비공개) | 즉답 중시 ※3 |
※1 Qwopus: 제작자는 자체 30문항 벤치마크에서 throughput 1.66배·총 시간 56.5% 감소·생성 토큰 27.7% 감소를 보고함 (출처)
※2 Pi reasoning: 프로그램 수정 등의 지시에 대해, AI가 파일을 조사하고, 명령어를 실행하고, 코드를 수정하고, 테스트를 완료하기까지의 기록을 학습한 모델. 제작자에 따르면 비공개 학습 데이터는 약 1,200건이며, 작업 중에 생각한 문장도 포함된다. 공개 샘플은 70건이며, 전체 데이터의 요청 내용이나 입수처는 공개되지 않았다 (출처)
※3 Pi tune: 마찬가지로 AI가 코딩 작업을 마칠 때까지의 기록을 학습에 사용한다. 단, 작업 중에 생각한 문장은 학습 데이터에 포함하지 않고, 직접 작업이나 답변으로 진행하는 형태로 학습한다. 학습 데이터의 건수와 개별 요청 내용은 비공개이다 (출처)
제작자가 제시한 수치는 각각의 벤치마크 환경에서 측정한 것이다. 본고에서는 필자 rS의 환경(WSL2 + llama-swap + 양자화 GGUF, OpenCode 경유)에서 동일한 경향이 나타나는지 확인하고자 했다.
살펴볼 점은 두 가지이다.
- 품질이 떨어지지 않았는가 — 실제 태스크에서 베이스 Qwen3.6과 비교해 큰 차이가 없는가.
- 작업을 더 빨리 끝낼 수 있는가 — 생성 속도와 태스크를 마칠 때까지의 시간에 차이가 나는가.
P2~P5의 동일한 29문항으로 품질과 속도를 비교했다. P1의 2문항은 도구를 사용할 수 있는지에 대한 사전 확인용으로 사용했다.
태스크 (P2~P5의 29문항 + P1 사전 확인) 페이즈(Phase)가 올라갈수록 작업이 복잡해진다. 호출 방식은 두 가지로, P2·P3는 모델이 직접 생성한 출력을 채점하며 (순수 응답 품질), P4·P5는 OpenCode 상에서 에이전트(Agent)로서 실행시켜 그 결과물을 채점한다 (파일 조작·빌드 포함).
채점 각 출력을 GLM-5.1과 Claude Sonnet으로 1~5점으로 채점했다. 각 모델은 2회 반복하여 (r1 / r2), 채점자 간·반복 간의 편차를 확인했다.
속도 P2·P3는 생성 속도(tok/s), P4·P5는 도구 실행을 포함한 실시간으로부터 시간당 완료 태스크 수(tasks/hour)를 산출했다.
표2 평가 단계 (Phase) 구성 각 Phase의 호출 형식·내용·문항 수. Phase가 올라갈수록 작업이 복잡해진다.
| 단계 | 형식 | 내용 | 문항 수 |
|---|---|---|---|
| P1 | OpenCode | 도구 호출 가능 여부 (사전 확인) | 전단 |
| ... |
비교는 동일한 구성 그룹 (27B MTP · 27B MTP + TQ · 35B MTP) 내에서 베이스 Qwen3.6과 튜닝 모델을 대조한다.
표3 대상 모델 (15종) 구성 그룹별 양자화·컨텍스트 길이·역할.
| 그룹 | 모델 | 양자화 | 컨텍스트 | 역할 |
|---|---|---|---|---|
| 27B MTP | Qwen3.6 (베이스) | Q3_K_M | 50K | 비교 기준 |
| ... |
MTP = 멀티 토큰 예측 (Multi-Token Prediction). 다음 토큰을 초안 형태로 미리 작성하여 한꺼번에 검증함으로써 생성을 가속화한다.
TQ = TurboQuant KV. KV 캐시(문맥 유지를 위해 사용하는 메모리)를 더욱 효율적으로 압축하는 방식으로, 동일한 VRAM에서 더 긴 문맥을 담을 수 있다. VRAM 16GB에서는 27B MTP 그룹은 KV q4_0를 사용하여 50K까지, MTP+TQ 그룹은 64K까지 담을 수 있었다. 따라서 두 그룹 간의 컨텍스트 사이즈(Context Size)가 다르다. 35B(MoE)는 KV가 작아 128K까지 담을 수 있다.
표 4 실행·채점 환경 GPU, 추론 서버, 에이전트, 채점 모델의 구성.
| 항목 | 내용 |
|---|---|
| GPU | NVIDIA RTX 5070 Ti (VRAM 16GB, 드라이버 596.36) |
| ... |
로컬 모델은 모두 VRAM 16GB 단일 GPU에서 동작하는 양자화(Quantized) GGUF이다. TurboQuant KV는 업스트림(upstream)인 llama.cpp가 지원하지 않기 때문에 전용 포크(Fork)를 사용했다. 추론 파라미터(temperature 등의 샘플링 설정)는 비교 대상 모델 간에 통일했다 (27B 그룹 및 35B 그룹에서 각각 공통 적용. 대조 모델은 각 권장값 사용).
TurboQuant 포크 (TheTom/llama-cpp-turboquant / commit 2cbfdc6)
파인튜닝(Fine-tuning)으로 인해 품질이 저하되는지는 모델에 따라 갈렸다. Qwopus (v2, Coder, A3B)와 Pi reasoning은 태스크별로 고저 차이는 있으나 베이스 모델인 Qwen 3.6과 거의 동등했다 (평균적으로 보면 약간 차이가 나지만, 측정 횟수와 평가 모델에 따른 편차가 더 크다). 즉, 속도를 얻는 대신 품질을 희생한 모습은 보이지 않았다. 반면, Pi tune은 코드 계열의 일부 태스크에서 낮은 점수를 기록했다.
차이가 나타난 것은 P4·P5였으며, P2·P3에서는 나타나지 않았다.
P2·P3 (직접 생성): Qwopus와 Pi를 포함한 27B 비교 그룹은 높은 점수에 모여 있으며, 차이가 작다.
P4·P5 (에이전트 실행 / 생성·빌드): Qwopus 그룹과 Pi reasoning은 베이스 모델과 비슷한 수준이었다. Pi tune만 P4의 model_watchdog_alerts
・py_screener_backtest
・llm_stack_doctor
, P5의 py_catboost_stock
・html_rocket_simulator
에서 낮은 점수를 보였다.
그림 1 스테이지별 품질 점수 각 모델의 평균 z-score를 전체(All)와 P2~P5의 6개 측면으로 나눈 것. 가로 2축 = 코드/비코드 품질의 z-score (오른쪽일수록 높음), 세로축 = 속도 (tasks/hour). P2·P3에서는 27B 비교 그룹이 고품질 영역에 밀집되어 있으며, P4·P5에서 좌우로 분산된다. Pi tune (보라색)과 대조 모델이 왼쪽의 저품질 쪽으로 떨어진다. 플롯(Plot)은 평균을, 바(Bar)는 2회 반복 및 2개 평가 모델의 점수 편차(표준 편차, 엄밀하지는 않음)를 나타낸다. 속도 축 방향은 플롯이 평균, 바가 2회 반복의 상하 폭을 나타낸다.
z-score란 각 태스크의 원점수(1~5점)를 해당 태스크 내의 모든 모델 평균 0, 표준 편차 1로 표준화한 상대값이다. 0이 평균, 양수는 위, 음수는 아래를 나타낸다. 태스크별 채점의 엄격함이나 난이도를 상쇄하고 채점자 간의 기준점을 맞출 수 있기 때문에, 원점수를 그대로 더하는 것보다 비교에 적합하다.
그림 2·그림 3 분야·스테이지별 품질 z-score 행 = 모델, 열 = Phase × 분야 (code/prose). 초록색은 평균 초과, 빨간색은 평균 미만. 그림 2는 GLM-5.1, 그림 3은 Sonnet의 채점이다. P2·P3는 중앙 쪽에 치우쳐 있으며, 빨간색은 P4·P5에 집중되어 있다. Pi tune은 코드 계열에서 빨간색이 짙게 나타난다.
시간당 완료 수(tasks/hour)에는 차이가 발생했다. 생성 속도(tok/s)는 모델 간에 거의 비슷했다.
파일 조작, 테스트, 재시도를 포함한 소요 시간으로부터 산출했다. 전체 Phase 통산(tasks/hour, MTP / TQ) 27B 그룹은 모델에 따라 베이스 대비 차이가 갈렸다.
Qwopus v2 — 가장 빠름. 베이스 초과 (17.5→23.0 / 20.2→32.6)
Pi tune — 베이스보다 빠름 (18.4 / 24.6)
Qwopus Coder — 베이스와 비슷함
Pi reasoning — 베이스보다 느림 (15.1 / 11.6)
35B Qwopus A3B — 베이스(11.8)에 미치지 못함 (10.5)
차이는 P4·P5(에이전트 실행)에 집중되었으며, P2·P3는 비슷하게 나타났다 (P2·P3는 단문이기 때문에 tasks/hour의 편차가 크다). P4의 베이스 대비 비율은 구성별로 다음과 같다 (수치는 히트맵 참조).
27B MTP— Pi tune 약 2배, Qwopus v2 약 1.5배, Coder 약 1.4배, Pi reasoning 약 0.8배 -
27B MTP+TQ— Qwopus v2 약 1.6배, Pi tune 약 1.5배, Coder 약 1.3배, Pi reasoning 약 0.7배 -
35B MTP— Qwopus A3B는 베이스와 동등하며, 더 빨라지지 않음
개선은 TQ 구성에서 더 크게 나타났으며, 실행(run) 간의 편차도 작은 경향을 보였다. Qwopus v2는 MTP에서는 반복 시 흔들림이 있었으나 (all 29.8 → 16.2 tasks/hour), TQ에서는 안정적이었다 (36.4 → 28.8).
직접 생성(Direct Generation)인 P2·P3로 측정했다. 27B 그룹은 Qwen, Qwopus, Pi 모두 약 4560 tok/s로, 베이스와 튜닝 모델 간의 차이가 없다. 35B 그룹은 약 4050 tok/s로 27B 그룹보다 느리다.
그림 4 스테이지별 속도 스코어 그림 1과 동일한 배치에서, 속도(세로축, tasks/hour, 위쪽이 빠름)를 보기 쉬운 각도로 조정한 것. 차이는 P4·P5에서 벌어지며, P2·P3는 나란히 위치한다. TurboQuant 구성의 Qwopus v2가 P4·P5에서 상단(고속), Pi reasoning이 하단(저속)에 위치한다.
그림 5 속도 실측값 왼쪽 블록 = 생성 속도 (tok/s, P2·P3), 오른쪽 블록 = 태스크 처리 속도 (tasks/hour, 전체·P2~P5). run1·run2를 좌우로 나란히 배치. 색상은 각 열의 최속을 100%로 한 상대값 (열별 정규화, 열 간의 농담 비교는 불가).
대조 모델(Gemma4-12B-QAT, Qwen3.5-9B)은 품질의 하한선을 측정하기 위한 것이며, 속도 비교의 기준은 아니다.
이번 환경에서 가장 실용적이라고 판단된 것은 Qwopus v2 27B, 특히 TQ 구성이었다. 품질은 베이스인 Qwen3.6과 동등하면서, 에이전트 태스크(P4·P5)를 베이스보다 빠르게 완료했다. TQ에서는 개선 폭이 컸고, 반복 간의 편차도 작았다. 이는 품질을 유지하면서 에이전트 태스크를 효율화하고 있다고 판단된다.
다른 파인튜닝(Fine-tuning) 모델들은 장단점이 있었다. Pi reasoning은 품질은 유지하지만 빨라지지 않았고, Pi tune은 P4에서 빠른 경우가 있었으나 코드 계열의 품질에 우려가 있었다.
단, 이 결과는 이번 평가 체계에서의 결과이며, 환경이나 벤치마크의 성격에 따라 결과가 달라질 가능성이 있다.
그림 6 전체 태스크 평균 품질·속도 (품질 관점) P2~P5의 전체 태스크 평균 z-score를 모델당 1점으로 표시. 가로 2축 = 코드/비코드 품질의 z-score, 세로축 = 속도 (tasks/hour, 참고용. 실측값은 그림 5). 색상은 계열 (파랑=Qwen, 주황=Qwopus, 보라=Pi, 초록=대조 GLM, 빨강=대조 소형 모델). 오른쪽 뒤쪽이자 위쪽일수록 품질을 유지하며 빠르다. Qwopus 그룹과 베이스는 오른쪽에, Pi tune과 대조 소형 모델은 왼쪽의 저품질 쪽에 위치한다.
그림 7 전체 태스크 평균 품질·속도 (속도 관점) 그림 6과 동일한 데이터를 속도(세로축)를 보기 쉬운 각도로 표시. 품질이 거의 비슷한 27B 비교 그룹 중에서, TurboQuant 구성의 Qwopus v2가 가장 빠르고(상단), Pi reasoning이 가장 느리다(하단).
Qwen과 Qwopus v2의 디코딩 tok/s는 거의 동일함에도 불구하고, P4에서는 Qwopus v2가 더 빨리 끝났다. 디코딩 속도만으로는 설명되지 않는다. 본고의 데이터에서는 검증하지 않았으나, 다음과 같은 가능성이 고려된다.
- 사고(Reasoning) 시의 출력 토큰이 적을 가능성
- 도구 호출(Tool calling)이나 재시도(Retry)가 적을 가능성
- 도구 결과를 다시 읽는 프리필(Prefill) 처리가 빠를 가능성
모두 가설이며, 다음 기사에서 검증할 예정이다.
Qwopus v2가 빠른 이유 조사— 사고 시의 출력량, 도구 호출 횟수, 프리필 속도를 비교 (다음 기사) -
벤치마크 개선— 태스크와 채점을 재검토하고, 널리 사용되는 평가 세트도 일부 도입 (Pi가 이번에 뒤처져 보인 것은 평가 체계 때문일 수도 있다. 그런 모델의 장점을 찾아내는 것이 이 벤치마크 제작자의 묘미이다) -
신규 모델 지속 비교— Qwen 계열의 새로운 튜닝 모델을 동일한 벤치마크에 추가해 나감
모든 태스크의 점수를 Overall / Code / Prose로 나누어 순위를 매겼다. 용도별로 살펴보면, Code에서는 Qwopus v2 27B가 로컬 최상위(전체에서도 대조군인 클라우드 GLM-5.1에 이어 그다음 순위)에 위치하며 파인튜닝 (Fine-tuning)의 강점이 드러난다. Overall은 베이스 모델인 Qwen 35B · 27B-TQ · 27B가 상위에 있으며, 파인튜닝 모델과 베이스 모델은 근소한 차이로 팽팽하게 맞선다. 반면 Prose에서는 Qwopus v2 27B의 순위가 떨어지기 때문에, 용도를 가리지 않는 '절대적인 순위'라고 보기는 어렵다.
다만, 인접한 모델 간의 차이는 run · 채점자 간의 편차와 비슷한 수준이므로, 엄격한 순위에 통계적인 의미를 부여하기는 어렵다. 상위권의 대부분은 실질적으로 거의 동점이라고 보는 것이 타당하며, 어떤 모델부터 시도할지의 기준으로 사용하는 정도가 적당하다. 각 열은 run1 · run2, GLM-5.1 · Sonnet의 평균 z-score로 각각 정렬하였다.
그림 S1 용도별 랭킹 (Overall / Code / Prose) 모든 태스크의 평균 z-score로 용도별(종합 · 코드 · 문장) 순위를 매김. 각 열은 run1 · run2 × GLM-5.1 · Sonnet의 평균 z. 인접 모델 간의 차이는 편차와 비슷한 수준이며, 엄격한 순위에 통계적인 의미는 없음.
각 단계(Phase)에서 부여한 태스크의 상세 내용은 다음과 같다.
모델이 OpenCode 상에서 파일 읽기/쓰기 도구를 올바르게 사용할 수 있는지 확인하는 사전 체크. 2문제가 있으며, 두 문제 모두 통과한 모델만 P4 · P5로 진행한다.
표 S1 P1 태스크 (도구 호출 확인) OpenCode 상에서 파일 읽기/쓰기 도구를 사용할 수 있는지 확인하는 사전 확인 2문제.
| ID | 카테고리 | 내용 |
|---|---|---|
tool_read | 코드 | 디렉토리 내의 readme.md를 파일 읽기 도구로 읽고, 내용 중에서 키워드나 수치를 답변한다 |
tool_write | 코드 | 지정된 경로에 지정된 문자열(EVAL_PROBE_OK)만을 기록한다 |
모델이 직접 출력하는 순수 응답 품질을 측정한다. 도구는 사용하지 않는다.
표 S2 P2 태스크 (기초 품질 · 직접 생성) 도구를 사용하지 않는 순수 응답 품질을 측정하는 3문제.
| ID | 카테고리 | 내용 |
|---|---|---|
ja_logic | 문장 | "AI로 모든 직업이 사라진다"라는 주장의 논리적 타당성을 평가하고, 암묵적 가정 지적 · 반론 · 대안을 제시한다 |
py_rate_limiter | 코드 | 토큰 버킷 (Token Bucket) 방식의 스레드 세이프 (Thread-safe) 레이트 리미터 (Rate Limiter)를 구현 (타임아웃이 포함된 acquire 메서드) |
fin_nikkei_cross | 코드 | yfinance로 닛케이 평균 데이터를 가져와 이동 평균 교차 (Moving Average Cross) 전략의 백테스트(Backtest) + Buy & Hold 비교 그래프를 생성한다 |
P2와 마찬가지로 모델이 직접 출력하는 품질을 측정한다. 보다 복잡한 지시 이행 (Instruction Following) · 코드 · 구조화된 출력 · 수리 계산 등을 부여한다.
표 S3 P3 태스크 (실무 품질 · 직접 생성) 지시 이행 · 코드 · 구조화된 출력 · 수리 계산 등의 8문제.
| ID | 카테고리 | 내용 |
|---|---|---|
ja_instruction | 문장 | 5개 지자체의 인구 순위 리스트 작성 (특산물 2개씩, 지정된 포맷 엄수) |
ja_logic_chain | 문장 | A/B/C사의 직원 수 · 여성 비율로부터 남성 합계를 도출 ("답: XXX명" 형식) |
py_binary_search | 코드 | 제네릭한 이진 탐색 (Binary Search) 함수를 루프로 구현 (타입 힌트 · docstring · 테스트 포함) |
py_bugfix | 코드 | 3개의 버그가 있는 단어 빈도 카운트 코드를 수정하고 테스트를 통과시킨다 |
json_output | 문장 | 지정된 스키마의 JSON만을 출력 (불필요한 텍스트 불가) |
math_reasoning | 문장 | 사과의 매입 · 판매 이익을 계산 (재고 20% 폐기, "답: XXX엔" 형식) |
en_ja_translation | 문장 | GPU 사양 문장을 일본어로 번역 (고유명사는 영어 유지, "~입니다/합니다" 체) |
long_context_extract | 코드 | 로그에서 ERROR 엔트리만을 JSON 배열로 추출 (다른 레벨 혼입 불가) |
OpenCode 상에서 에이전트 (Agent)로 실행시킨다. 파일 조작 · 빌드 · DB 연결을 포함하는 실제 태스크.
표 S4 P4 태스크 (에이전트 실행) 파일 조작 · 빌드 · DB 연결을 포함하는 실제 태스크 7문제.
| ID | 카테고리 | 내용 |
|---|---|---|
py_strategy_compare | ||
| 코드 | 주가 데이터로 Buy&Hold vs 자체 전략 백테스트(Backtest) 비교 (그래프 + 리포트 생성) | |
py_screener_backtest | ||
| 코드 | PostgreSQL 재무 DB에서 종목 스크리닝 → 스코어링(Scoring) → 수익률 상관관계 분석 (Spearman) | |
html_affiliate_draft | ||
| 코드 | LLM 벤치마크 + 투자 연구 웹사이트 메인 페이지 제작 (어필리에이트 가정, CTA 포함) | |
multi_file_debug | ||
| 코드 | Python 프로젝트에서 5개의 버그를 수정하고 pytest를 모두 통과(PASS)시키기 | |
neuron_candle_competitor_lp | ||
| 문장 | 경쟁사 조사 → 차별화 요소 정리 → 웹사이트 초안 구축 (3개 파일 출력) | |
llm_stack_doctor | ||
| 코드 | 로컬 LLM 스택 진단 CLI 제작 (--quick --json으로 JSON 출력, 파괴적인 작업 금지) | |
model_watchdog_alerts | ||
| 코드 | 모델 출시 워처(Watcher) 프로토타입 — 후보 추출 · 스코어링 · Telegram 알림 문구 생성 (dry-run만 수행) |
P4와 마찬가지로 에이전트 실행. 일본어 라이팅과 Python/HTML 빌드를 포함.
표 S5 P5 태스크 (생성·빌드계) 일본어 라이팅과 Python/HTML 빌드를 포함하는 11문제.
| ID | 카테고리 | 내용 |
|---|---|---|
jp_local_llm_review | ||
| 문장 | 로컬 LLM 5선 기술 기사 (장점 · 단점 · 비교표 · 용도별 추천, 1500자 이상) | |
jp_qiita_author_analysis | ||
| 문장 | Qiita 작성자 「rS_alonewolf」의 기사 분석 — 독창성 · 차별화 포인트 (800자 이상) | |
jp_car_repair_negotiation | ||
| 문장 | S660 수리 문제로 인한 80만 엔 배상 협상 전략 + 대화 시뮬레이션 (민법 근거 포함, 3회 왕복 이상) | |
jp_beginner_llm_guide | ||
| 문장 | 비엔지니어를 위한 로컬 LLM 입문 가이드 (Ollama 절차 · 트러블슈팅, 2000자 이상) | |
jp_investment_report | ||
| 문장 | 닌텐도(7974) 기관 투자자용 애널리스트 리포트 (SWOT + 재무 추이표, 1500자 이상) | |
jp_debate_script | ||
| 문장 | 「AI는 인간의 일자리를 빼앗을 것인가」 토론 대본 — 찬성/반대/중립 3인이 반론 · 재반론 (2000자 이상) | |
candle_animation | ||
| 코드 | 다크 테마 양초 불꽃 애니메이션 HTML (CSS animation, 호버 인터랙션 포함) | |
py_benchmark_report | ||
| 코드 | 벤치마크 결과 YAML을 읽어 들임 → 랭킹 막대그래프 + 용도별 권장 리포트 생성 | |
py_catboost_stock | ||
| 코드 | PostgreSQL 재무 DB에서 CatBoost로 일본 주식 상승 예측 — 백테스트(2019-2023) + 포워드 테스트 (상위 20개 종목) | |
html_recommendation_site | ||
| 코드 | 「당신을 위한 추천」 기능이 있는 정보 사이트 — 카테고리 필터 + LocalStorage 선호도 저장 + 다크 테마 | |
html_rocket_simulator | ||
| 코드 | 로켓 궤도 시뮬레이터 — 속도 · 각도 슬라이더 → Canvas로 실시간 궤도 그리기 (궤도 진입/탈출/낙하 판정) |
평가 본체: P2(3) + P3(8) + P4(7) + P5(11) = 29문제. P1은 별도로 2문제의 사전 확인.
비교 대상 (27B / 35B)
- 기본 Qwen3.6-27B (GGUF): https://huggingface.co/unsloth/Qwen3.6-27B-GGUF
- 기본 Qwen3.6-35B-A3B (GGUF): https://huggingface.co/unsloth/Qwen3.6-35B-A3B-GGUF
- Qwopus v2 (27B): https://huggingface.co/Jackrong/Qwopus3.6-27B-v2-MTP-GGUF
- Qwopus Coder (27B): https://huggingface.co/Jackrong/Qwopus3.6-27B-Coder-MTP-GGUF
- Qwopus A3B (35B): https://huggingface.co/Jackrong/Qwopus3.6-35B-A3B-v1-MTP-GGUF
- Pi reasoning (27B): https://huggingface.co/bytkim/Qwen3.6-27B-MTP-pi-reasoning-GGUF
- Pi tune (27B): https://huggingface.co/bytkim/Qwen3.6-27B-MTP-pi-tune-GGUF
대조군
-
Qwen3.5-9B: https://huggingface.co/unsloth/Qwen3.5-9B-GGUF
-
Gemma4-12B-QAT: https://huggingface.co/google/gemma-4-12b (QAT GGUF 버전을 사용)
-
GLM-5.1: z.ai의 클라우드 API (HuggingFace 배포 없음)
-
llama.cpp: https://github.com/ggml-org/llama.cpp
-
TurboQuant 포크 (TheTom): https://github.com/TheTom/llama-cpp-turboquant
-
llama-swap: https://github.com/mostlygeek/llama-swap
-
OpenCode: https://opencode.ai
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기