Qwen에게 자기 llama.cpp 서버를 튜닝하게 했더니 같은 GPU에서 36초 작업이 23초로 줄었습니다 | DAKER 커뮤니티

유튜브 채널 Weights & Wonders가 10월 19일 공개한 실험 영상 「I asked Qwen to Optimise Itself. Here's What it Did!」에서 Qwen 3.8 Flash-Next는 자기가 돌아가는 llama.cpp 서버의 속도 설정을 2시간 동안 스스로 바꿨고, 같은 시험 작업은 같은 그래픽카드에서 36초에서 23초로 줄었습니다. 영상이 정리한 결론은 단순합니다. 모델이 GPU 메모리에 다 들어가지 않는 환경에서는 한 번에 읽는 묶음(batch·ubatch)을 키운 것이 가장 크게 통했고, 스레드를 늘리거나 메모리를 줄이는 시도는 오히려 느렸습니다. 대회 추론 코드를 다듬는 팀이 오늘 가져갈 행동은 하나입니다. 고정된 시험 작업과 품질 시험을 먼저 정해 두고, 속도 설정은 한 번에 하나씩 바꿔 시간을 기록하는 것입니다.

신문지를 오려 붙인 콜라주 스타일로, 메모리 스틱 쪽에서 큐브를 가득 실은 카트가 작업대 위 그래픽카드로 향하고 옆에 초시계가 놓인 설명용 생성 이미지
설명용 생성 이미지입니다.

영상에서 실제로 한 실험은 무엇이었습니까

영상 설명과 자막에 따르면 실험 환경은 Unsloth가 공개한 3비트 양자화 파일(82GB)의 Qwen 3.8 Flash-Next, 2018년에 나온 48GB 워크스테이션 카드 Quadro RTX 8000 한 장, 48스레드 Xeon과 251GB 시스템 메모리였습니다. 모델 파일이 82GB라 48GB 카드에 다 올라가지 않으므로, 일부는 카드에, 나머지는 시스템 메모리에 두고 답할 때마다 카드가 필요한 부분을 가져오는 구조입니다. 영상은 이 왕복이 느린 이유라고 설명합니다.

모델은 오픈소스 코딩 에이전트 OpenCode를 통해 컴퓨터 전체를 다룰 수 있었고, 주어진 과제는 「스스로를 더 빠르게 만들라」 하나였습니다. 사람이 고정한 조건도 분명했습니다. 문맥 길이 65,536토큰, 사용자 1명, Qwen 권장 샘플링, 사고 수준 medium은 바꿀 수 없었고, 더 작은 모델로 바꾸는 것도 금지였습니다. 바꿀 수 있는 것은 속도 관련 설정뿐이었습니다.

제작자는 모델이 기록을 경신할 때마다 20문항 퀴즈를 다시 풀고, 아주 긴 메시지 하나를 메모리 부족 없이 처리해야 한다는 조건을 걸었습니다. 시작 점수는 20점 만점이었고, 1문항 이상 떨어지면 안 됐습니다. (영상 설명 요약)

이 조건이 실험의 핵심입니다. 속도만 재면 답의 질을 깎아 빨라지는 설정도 통과해 버립니다. 품질 시험을 같이 걸어 두었기 때문에 최종 결과인 23초도 의미가 있습니다. 최종 설정은 퀴즈 19점으로 기준을 겨우 넘겼다고 영상은 밝힙니다.

자기 서버를 고치면 자기 자신이 꺼진다는 문제

이 실험에는 독특한 제약이 있었습니다. 모델이 튜닝하는 대상이 바로 자신이 돌아가는 서버였기 때문에, 설정을 바꿀 때마다 서버가 재시작되고 모델은 그때까지의 작업 기억을 잃었습니다. 영상에 따르면 모델은 재시작 후 대화 전체를 처음부터 다시 읽어 어디까지 했는지 파악했고, 약 45분이 지나 대화가 너무 길어지자 지금까지의 결과를 스스로 요약해 이어 갔습니다.

대회 팀에도 같은 문제가 있습니다. 노트북 커널이 죽거나 세션이 끊기면 어떤 설정으로 몇 초가 나왔는지 기억에 의존하게 됩니다. 모델이 한 것처럼 실험 결과를 매번 파일로 남기면, 사람이든 에이전트든 중간에 끊겨도 같은 지점에서 다시 시작할 수 있습니다.

9분 동안 문서를 읽고 할 일 목록부터 만들었습니다

제작자가 처음에 지시한 것은 매뉴얼을 읽으라는 것뿐이었지만, 모델은 약 9분 동안 훨씬 많은 것을 읽었다고 영상은 전합니다. 속도에 관련된 llama.cpp 설정, 프로세서·메모리·그래픽카드 사용량, 자기 서버가 실행된 정확한 명령, 그리고 모델 파일 자체를 확인했습니다. 모델 파일 안에서는 이 모델이 512개의 작은 전문가로 이뤄져 있고 단어마다 그중 10개만 일한다는 구조를 찾았습니다. 시작 로그에 뜬 경고 메시지의 뜻을 알아내려고 소스 코드까지 찾아봤습니다.

그다음 모델은 스스로 할 일 목록을 적었습니다.

  1. 앞질러 추측하기(MTP, 다중 토큰 예측)를 켜 보기
  2. 읽기 속도에 영향을 주는 설정 시험하기
  3. 몇 단어 앞까지 추측할지 조정하기
  4. 보고서 쓰기

그리고 이 순서대로 진행했습니다. 무작정 설정을 바꾸기 전에 환경과 병목부터 확인한 셈입니다. 대회에서도 추론 시간이 길다면 먼저 GPU 메모리에 무엇이 올라가 있는지, 데이터를 어떤 크기로 넘기는지부터 확인하는 편이 순서상 맞습니다.

첫 시도는 오히려 느려졌습니다

모델이 처음 고른 방법은 MTP였습니다. 영상은 이를 느린 선임 작가 옆에 빠른 후배가 앉아 다음 몇 단어를 미리 추측하고, 선임이 그 추측을 한 번에 검토하는 구조로 설명합니다. 추측이 맞으면 답이 빨리 나옵니다. 모델은 MTP 파일을 카드에 올릴 자리를 만들려고 대화 기억(KV 캐시)을 절반 정도로 압축했습니다.

결과는 43초로, 출발점인 36초보다 느렸습니다. 쓰기는 빨라졌지만 읽기가 느려졌고, 시험 작업은 긴 문서를 읽는 비중이 컸기 때문입니다. 메모리를 다시 확인해 보니 압축 없이도 MTP가 들어갔고, 압축을 빼자 40초가 됐습니다. 쓰기 속도는 초당 36토큰에서 57토큰으로 올랐지만 읽기는 여전히 약 3분의 1 느렸습니다. 병목이 쓰기에서 읽기로 옮겨 간 것입니다.

이 장면은 대회 팀에게 익숙합니다. 한 가지 최적화를 넣고 전체 시간이 늘었다면 그 기법이 나쁜 것이 아니라 작업의 구성(읽기 대 쓰기, 전처리 대 추론)이 다를 수 있습니다. 구간별 시간을 나눠 재야 다음 수가 보입니다.

시험 스크립트를 스스로 만들고 15번 실험했습니다

설정을 하나 시험할 때마다 서버를 재시작하고 속도 시험을 돌려야 했기 때문에, 모델은 요청받지 않은 일을 했습니다. 새 설정으로 재시작하고, 속도 시험을 돌리고, 점수를 적고, 다음 설정으로 넘어가는 작은 시험 프로그램을 직접 만든 것입니다. 첫 버전은 따옴표 처리 오류로 깨졌고, 모델은 그것을 고친 뒤 다섯 가지 설정을 연달아 돌렸습니다. 영상은 모델이 전체적으로 15번의 실험을 했다고 말합니다.

1차 라운드에서는 MTP를 한 단어 더 앞까지 추측하게 하고, 그 위에 한 번에 한 가지만 바꿨습니다. 48스레드 전부 사용, 시작 로그 경고가 권장한 다른 모델 적재 방식, 두 가지 크기의 큰 묶음입니다. 셋은 출발점보다 느렸고, 스레드 전부 사용이 가장 느렸습니다. 출발점을 이긴 것은 큰 묶음뿐이었고, 클수록 좋았습니다.

영상의 설명은 이렇습니다. 카드에 들어가지 않는 전문가 가중치는 시스템 메모리에 있으므로, 입력을 작은 묶음으로 나눌수록 카드가 그 가중치를 가져오는 왕복이 늘어납니다. 장바구니 하나씩 열 번 나르는 것과 카트에 한 번 싣는 것의 차이라고 비유합니다. 이 라운드의 승자를 제작자가 직접 재 보니 28.4초였고, 퀴즈는 20점 그대로였습니다.

최종 설정과 그만둔 시점

2차 라운드에서 모델은 3·4·6단어 앞 추측, 더 큰 묶음, 전문가용 메모리 설정, 그리고 Unsloth가 권장하는 다른 MTP 파일을 시험했습니다. 권장 파일은 특수한 llama.cpp 빌드가 필요해 이 환경에서는 아예 적재되지 않았습니다. 6단어 앞 추측은 3단어보다 나빴고, 메모리 설정도 느렸으며, 가장 큰 묶음이 다시 읽기를 빠르게 했습니다.

3차 라운드는 최적 지점 주변을 좁혀 찾는 단계였습니다. 최종 승자는 가장 큰 묶음(batch 8192, ubatch 4096)에 MTP 3단어 앞 추측을 더한 설정이었고, 제작자가 잰 시간은 23초였습니다. 긴 메시지도 처리했고 퀴즈는 19점으로 통과했습니다. 모델은 30분 넘게 시간이 남았는데도 실험을 멈추고 마지막 할 일인 보고서를 썼습니다. 보고서의 결론은 앞질러 추측하기는 쓰기를, 큰 묶음은 읽기를 빠르게 했고 나머지는 도움이 되지 않았다는 것입니다.

내 컴퓨터에서 따라 할 때의 순서

영상 설명란은 직접 시도할 때의 순서를 이렇게 정리합니다.

주의할 점도 있습니다. 이 결과는 특정 모델, 특정 카드, 긴 문서를 읽는 비중이 큰 시험 작업 하나에서 나온 수치입니다. 모델이 카드에 다 들어가는 환경이나 짧은 입력이 많은 작업에서는 같은 크기의 효과를 기대하기 어렵습니다. 영상도 사고 수준을 더 높이면 결과가 달라질 수 있다며 열린 질문으로 마무리합니다. 영상 내레이션은 AI 음성이라고 설명란에 밝혀져 있습니다.

추론 시간이 순위를 가르는 대회에 옮기면

지금 DACON에서 진행 중인 항만 문제해결을 위한 AI 기술 공모전 평가 안내에는 동점자 우선순위가 추론 시간 짧은 순, 제출 ZIP 용량 작은 순, 동일 점수 달성 빠른 순으로 적혀 있습니다. 같은 페이지 기준 평가 서버는 NVIDIA L4(VRAM 22.4GiB), 6 vCPU, RAM 26GB이고, 추론 코드 실행은 데이터 로딩·전처리·추론·결과 저장을 포함해 최대 30분입니다. 2026년 10월 23일 오전 확인 시점에 페이지에는 참가 928명, 종료까지 D-10이 표시돼 있었습니다. 같은 페이지 일정상 리더보드 제출 마감은 11월 1일, 대회 종료는 11월 2일입니다.

이 대회의 평가 서버는 llama.cpp가 아니라 참가자의 script.py를 실행하는 구조이므로 영상의 설정값을 그대로 옮길 수는 없습니다. 옮길 수 있는 것은 실험 방식입니다.

  1. 로컬에서 고정된 시험 데이터 묶음과 시간 측정 스크립트를 먼저 만듭니다.
  2. 점수 하락 허용 범위를 정해 두고, 속도 설정을 바꿀 때마다 검증 점수를 같이 기록합니다.
  3. 배치 크기, 데이터 로더 설정, 정밀도처럼 속도에 영향을 주는 항목을 한 번에 하나씩만 바꿉니다.
  4. 결과를 파일 한 곳에 누적해 세션이 끊겨도 이어서 볼 수 있게 합니다.

제출 기록에 실행 시간과 압축 파일 용량을 함께 적는 방법은 DAKER 대회 글 같은 점수면 추론 시간이 짧은 팀이 앞서는 항만 AI, 제출마다 실행 시간과 압축 파일 용량을 같이 적습니다에 정리돼 있습니다. 대회 규칙 전문은 항만 AI 공모전 규칙에서 확인하십시오.

함께 보면 좋은 글

작은 모델을 튜닝할 때 무엇이 점수를 올렸는지는 DAKER 잡담의 Qwen 4B 강화학습 실험 정리에서, 최신 경량 모델의 실사용 속도 감각은 DeepSeek V4.1 Flash 1017 실전 테스트 정리에서 이어 볼 수 있습니다. 로컬 모델을 API 서버로 띄우는 다른 선택지가 궁금하다면 vLLM 소개 글도 참고하십시오.

출처: Weights & Wonders 유튜브 영상 「I asked Qwen to Optimise Itself. Here's What it Did!」(2026년 10월 19일 공개)의 자막과 설명란, DACON 항만 문제해결을 위한 AI 기술 공모전 평가 안내(2026년 10월 23일 확인). 영상 속 수치는 제작자 환경에서 측정한 값이며 DAKER가 재현한 결과가 아닙니다.

여러분은 추론 시간을 줄일 때 어떤 설정부터 바꿔 보십니까? 한 번에 하나씩 바꿔 잰 기록이 있다면 댓글로 나눠 주십시오.