KCC 2026 2차 프로젝트 진행요강

노타 × 한국정보과학회 — NetsPresso 활용 On-Device AI 최적화 경진대회 2026 2차: On-Device LLM 텍스트 생성 런타임 최적화

2차에 진출한 12팀을 위한 안내 문서입니다.

• 2차는 지정 모델 하나를 Raspberry Pi 5에서 실제 텍스트 생성 으로 돌리며 TTFT · 토큰 생성속도 · 메모리 · 품질을 최적화하는 과제입니다.
• 양자화·KV cache·커널·런타임·생성 파이프라인 전 계층을 자유롭게 최적화할 수 있습니다.

---

1. 2차 한눈에

항목	내용
대상 모델	meta-llama/Llama-3.2-1B-Instruct (지정 revision, §3.1)
목표	지정 모델을 실제 텍스트 생성(prefill+decode)에서 빠르고·가볍고·자연스럽게 최적화
Target device	Raspberry Pi 5 (16GB), 인터넷 가능
Runtime	ExecuTorch v1.1.0 / Backend XNNPACK (커널·백엔드 최적화 자유)
제출물	model.pte + 추론/생성 코드(run.sh) + 최적화 재현 스크립트 + 로그
평가 축	TTFT · 토큰 생성속도(TPOT) · Memory · 품질 · 재현성
측정	운영진이 동일 RPi5에서 제출 코드를 고정 조건으로 재실행한 값이 공식 점수

역할 한눈에 — 제공 / 수행 / 제출 / 평가

운영진이 제공	참가자가 수행	참가자가 제출	운영진이 평가
모델명+revision(§3.1)	모델 download(직접)	model.pte	RPi5 재실행 측정
RPi5 1일 + ExecuTorch 환경	export → .pte	run.sh + runner/(빌드된)	TTFT·TPOT·Memory
고정 tokenizer	PTQ 양자화·KV cache	repro/(재현 스크립트)	품질(degeneration gate + 루브릭)
제출물 가이드(run.sh 계약)	러너 빌드/작성·커널 튜닝	README·logs/	재현성 + 무결성 검증(§4.1)
프롬프트 형식 예시(더미 소수)	러너 작성 + 자체 측정		(점수 = baseline 대비 ratio)

---

2. 일정

일정	내용
6/15(일) 10:30	본 진행요강 전 팀 동시 발송 (채점 항목·측정 방식·run.sh 규격 포함)
6/15(일) ~ 6/18(목)	공통 수행 기간 (디바이스 밖 — 모델 download·export·양자화·코드 작성)
6/16(화) ~ 6/18(목)	RPi5 단독 사용 — 팀당 배정일 1일, 매일 07:00 ~ 19:00 (§2.1 배정표)
6/18(목) 21:00	2차 결과물 제출 마감 — 전 팀 공통
6/19(금) 17:00	2차 평가 후 본선 진출팀 선정·안내
6/22(월) 19:00	발표자료 제출
6/24(수) 14:00	본선 및 시상식

• 제출 마감은 전 팀 공통 6/18(목) 21:00입니다.
• 점수는 6/19 운영진 재측정으로 산정되며, 디바이스는 개발·튜닝·검증용입니다.
• 디바이스 운영 정책(19:00 종료 · 19:05 cleanup · 결과물 회수 · 보존 경로)은 §3.4 참고.

2.1 RPi5 배정일 (랜덤 추첨 결과)

팀은 익명 코드(KCC-1001 ~ KCC-1012)로 표기합니다.

일자	배정 팀
6/16(화)	KCC-1001, KCC-1002, KCC-1003, KCC-1004
6/17(수)	KCC-1005, KCC-1006, KCC-1007, KCC-1008
6/18(목)	KCC-1009, KCC-1010, KCC-1011, KCC-1012

2.2 접속 (VPN)

항목	내용
VPN App	FortiClient VPN — https://www.fortinet.com/support/product-downloads#vpn
VPN 계정 / 디바이스 접속 정보	<팀별 개별 안내>
접속 가능 시간	배정일 07:00 ~ 19:00

App 설치 후 개별 안내되는 계정으로 VPN 접속 → 배정된 RPi5에 SSH 접속합니다. 계정·비밀번호 등 인증정보는 팀별로 할당 당일 개별 안내합니다.

---

3. 환경 및 자원

3.1 모델

• meta-llama/Llama-3.2-1B-Instruct 를 HuggingFace에서 직접 다운로드해 사용합니다. RPi5에서 받아도 되고 본인 PC에서 받아도 됩니다.
• Meta 라이선스 동의·접근 승인이 필요하며, 승인에 시간이 걸릴 수 있으니 지금 바로 신청하세요.
• 모든 팀이 동일 가중치를 쓰도록 아래 revision(commit) 을 고정합니다.

  huggingface-cli download meta-llama/Llama-3.2-1B-Instruct \
    --revision 9213176726f574b556790deb65791e0c5aa438b6

  (revision 9213176726f574b556790deb65791e0c5aa438b6, 2024-10-24)

3.2 디바이스 (팀당 1일 단독 SSH)

• ExecuTorch v1.1.0 소스·빌드 환경(~/executorch/, cmake-out/)과 venv(torch 2.x+cpu 등), executor_runner 가 준비되어 있습니다.
• 외부통신 가능합니다.
• C++ 커널/백엔드를 직접 수정·재빌드할 수 있습니다.
• RPi5는 ARM(aarch64, Cortex-A76) 입니다. 러너 바이너리는 aarch64로 빌드해야 하고, 커널·런타임 최적화와 성능 측정은 디바이스에서 합니다.
• .pte는 본인 환경에서 만들어 복사(scp)해도 됩니다. 제출물은 RPi5/ExecuTorch에서 정상 동작해야 합니다.

3.3 제공 항목

• 고정 tokenizer(지정 revision)
• 프롬프트 형식 예시(소수 더미 — run.sh 형식 확인용, 대표성 없음)
• 제출물 가이드(run.sh 계약 — §5.4 / 제출물_가이드_2차.md).
• 추론 러너는 제공하지 않습니다. ExecuTorch 예제 러너 llama_main을 직접 빌드해 쓰거나 자작 러너를 만드세요(§4·§5).
• baseline은 운영진이 원본 모델을 동일 조건으로 측정한 내부 기준값(비배포). 참가자는 자신의 .pte를 직접 만듭니다.

3.4 RPi5 사용 유의사항

• 접속·종료: SSH는 배정일 07:00~19:00만. 19:00 정각 세션·백그라운드 프로세스 강제 종료, 19:05 home cleanup. 결과물은 18:50까지 회수.
• 보존 / 삭제: 보존 = ~/results/ · ~/.ssh/ · ~/executorch/ · ~/venv/ · ~/.local/. 그 외(~/work/·다운로드물 등)는 삭제됩니다.
• 빌드는 본인 슬롯에서(평가기와 동일 aarch64 이미지). 풀빌드는 길 수 있으니 오전 착수 권장.
• 디스크: df -h / 로 여유 확인. .pte·빌드 산출물이 쌓이면 정리(최종본만 ~/results/).

---

4. 무엇을 최적화할 수 있나 (자유도 = 전면 허용)

핵심 원칙: 지정 base 모델·revision에서 출발해, 추론 효율을 높이는 변환은 자유. 단 모델을 다른 것으로 바꾸거나 학습으로 가중치를 다시 만드는 것은 금지합니다(§4.1).

아래 세 계층 어디서든 자유롭게 최적화할 수 있습니다.

• 모델 / Export — 양자화, KV cache, export 옵션 등
• 런타임 / 커널 (디바이스, ARM 타깃) — XNNPACK·커널·affinity·스케줄 튜닝, C++ 커널·백엔드 수정·재빌드 등 (스레드 수는 측정 시 4 고정)
• 생성 파이프라인 / 러너 — 생성 루프·KV 관리 등. llama_main을 쓰든 직접 작성하든 자유이며, 러너 자체를 개발 사용하셔도 됩니다.

4.1 허용 / 금지

✅ 허용

• 양자화(PTQ: 8da4w·GPTQ·AWQ 등 학습 없는 calibration 기반)·KV cache·export 옵션 조정
• C++ 커널/백엔드 수정·재빌드, 러너 자작
• 직접 export(도구 자유), 공개 데이터를 이용한 calibration
• AI agent 사용, 본인 환경에서 export 후 .pte·코드 반입

❌ 금지 (위반 시 감점/실격)

• 지정 모델 외 외부 모델·체크포인트·가중치 사용 / 외부 추론 API 사용
• 추가 학습·fine-tuning, 그리고 학습을 동반하는 양자화(QAT·SpinQuant 등). — PTQ(학습 없음)는 허용.
• 모델 구조·용량 변경(pruning·레이어 삭제·distillation 등).
• 평가 데이터셋을 보고 튜닝하거나 calibration·설정 탐색에 사용
• 출력 하드코딩·정답 매핑·프롬프트 변조, 측정 구간 밖으로 연산 이동, 타이밍 조작
• 다른 팀 산출물 접근, 시스템 설정 무단 변경

무결성 검증: 제출 .pte가 지정 모델(§3.1 revision)에서 허용된 방법으로만 만들어졌는지 검증합니다 — ① repro/가 지정 모델에서 model.pte를 재현하는지(스팟체크), ② .pte의 구조 지문(vocab·레이어 수·차원 등)이 지정 모델과 일치하는지. 다른 모델·pruning·학습 흔적이 확인되면 실격됩니다.

---

5. 제출물

5.1 제출 항목 (4종)

"모델 → 최적화 → 실행"의 전 과정이 재현 가능하도록 아래를 제출합니다.

구성	필수	설명
① model.pte	✅	최적화한 결과물 (평가에 직접 사용)
② 추론/생성 portable bundle (run.sh + runner)	✅	.pte로 텍스트를 생성하는 러너 + §5.4 규격의 실행 진입점. C++/커스텀 ExecuTorch라면 RPi5 aarch64 prebuilt 바이너리와 필요한 라이브러리를 제출물 안에 포함(평가 시 설치·빌드하지 않음).
③ 최적화 재현 스크립트	✅	지정 모델로부터 model.pte를 만든 전 과정(export·양자화·calibration·커널 diff 등)
④ README.md	✅	실행/재현 방법, 사용한 최적화 요약, 의존성

실행 로그(logs/execution.log)는 선택(재현·디버깅에 도움).

5.2 제출 폴더 구조

<team_name>/
├── model.pte                  # ① 최적화 결과물
├── run.sh                     # ② 실행 진입점 (§5.4) — 평가에 직접 사용
├── runner/                    # ② 추론/생성 코드: 소스 + prebuilt 바이너리/라이브러리
│   ├── bin/                   #    RPi5 aarch64 실행파일
│   └── lib/                   #    필요 시 동봉 .so
├── repro/                     # ③ model.pte 재현 (export·양자화·calibration·커널 diff)
│   └── optimize_to_pte.sh     #    지정 모델 → 최적화 전 과정 → model.pte 재현
├── README.md                  # ④ 실행/재현 방법, 최적화 요약, 의존성
└── logs/                      # (옵션) 실행 로그
    └── execution.log          #    (옵션)

• run.sh는 폴더 최상단에 두고, 추가 빌드 없이 바로 실행되어야 합니다.
• C++ 러너/커스텀 커널/수정 ExecuTorch 런타임은 빌드된 바이너리와 필요한 라이브러리를 제출물 안에 포함하세요(평가 시 재빌드·설치하지 않음). 빌드 방법·patch·source는 runner/ 또는 repro/에 함께 둡니다.
• 러너 구동에 필요한 파일(예: params.json, config)은 번들에 포함하세요.
• 토크나이저는 운영진이 전달하는 공식 토크나이저(지정 revision) tokenizer.model 을 사용합니다(러너는 --tokenizer 경로 사용).

5.3 제출 archive 및 업로드

팀별 단일 archive(teamXX_round2_submission.tar.gz)로 받으며, 위 폴더 + MANIFEST.sha256을 포함합니다.

• 기본 최대 크기 5GB 이하. 초과가 필요하면 6/18 18:00까지 운영진에 사전 요청.
• 포함 가능: 개조한 실행파일, 자작 inference pipeline, 커스텀 ExecuTorch가 링크된 prebuilt runner, 필요한 .so, 빌드 재현용 source/patch/script.
• 포함 금지: 원본 HF checkpoint, 여러 .pte 후보, calibration dataset, build cache/cmake-out 전체, .git, Python venv/conda 환경 전체.
• 제출 URL은 팀별로 안내합니다. 재업로드 가능하되 마감 전 마지막 업로드만 인정합니다.

5.4 추론 코드 작성 규격 (run.sh)

운영진은 모든 팀의 run.sh를 동일한 방식으로 호출해 측정합니다. 내부 구현(C++/파이썬)과 .pte 포맷은 자유지만, 아래 호출 규격은 지켜 주세요.

./run.sh --prompts <프롬프트.jsonl> --max-new-tokens 128 --greedy \
         --cpu-threads 4 --tokenizer <공식_tokenizer> --out result.jsonl

• 출력 result.jsonl(프롬프트당 한 줄)에 generated_text, output_token_ids, ttft_ms, per_token_ms[], num_prompt_tokens, num_generated_tokens 포함.
• 사전 빌드 후 한 번에 실행되어야 하며, greedy 생성·종료 조건은 운영진 측정과 동일해야 합니다.
• run.sh는 제출 폴더 내부의 runner/binary/library만 사용합니다. 평가 중 sudo·apt·pip·cmake --build·시스템 경로 수정은 금지.
• 최장 평가 프롬프트와 max_new_tokens=128 생성을 truncation 없이 처리(최소 context 768 tokens 이상).
• 상세 규격·입출력 스키마·패키징(self-contained 번들)·예시는 본 repo의 제출물_가이드_2차.md (run.sh 계약)를 따르세요.

⚠️ 제출 전 반드시 할당된 RPi5 슬롯에서 self-contained 동작을 확인하세요(제출물_가이드_2차.md §6 자가 점검). dev 환경에 기대지 않고 번들만으로 돌아가야 하며, 평가기에서 실행되지 않으면 측정 0점입니다.

---

6. 평가

평가 항목·방식·배점·산식·게이트는 아래와 같습니다. (실제 채점 프롬프트셋만 비공개 — §6.1.)

6.1 측정 방식

• 운영진이 제출 run.sh를 동일 RPi5에서 재실행해 측정합니다(공식값, 자체측정값 비인정).
• 고정 조건: greedy(temperature=0) · max_new_tokens=128 · cpu_threads=4. chat template는 운영진이 적용한 고정 문자열로 전달(러너는 토큰화만, 재적용 금지).
• 타이밍(TTFT·TPOT): 길이대 3종(짧음 ~32 / 보통 ~128 / 긺 ~512 토큰) 대표 프롬프트로 warmup 1회 + 측정 5회 중앙값. Memory는 이 실행에서 외부 측정(/usr/bin/time -v).
• 품질: 6개 카테고리(요약·사실 QA·상식 추론·지시 수행·개방형 글쓰기·분류/추출) 24개 프롬프트(영어) 1회 생성(greedy라 결정적이라 반복 불필요). 루브릭 채점(LLM-judge + 사람 검수)은 디바이스 밖에서 수행.
• 결정성: 일부 프롬프트를 2회 실행해 output_token_ids 동일 확인.
• 형식 확인용 예시 프롬프트(대표성 없음)는 사전 배포, 실제 채점은 비공개 평가셋으로.
• baseline은 원본 모델을 동일 조건에서 측정한 값(per-device). 성능은 baseline 대비 ratio.

6.2 배점 (1000점)

항목	배점	산정
품질 (Quality)	350	게이트 통과 후, 24개 생성 출력의 정성 루브릭
토큰 생성속도 (TPOT)	300	baseline 대비 ratio (4×→85%, 8×→100%)
첫 토큰 지연 (TTFT)	150	baseline 대비 ratio (4×→85%, 8×→100%)
Memory	100	baseline 대비 ratio 선형보간 (캡 8.0×)
재현성 (Reproducibility)	100	제출 완전성(40) + 규격 준수(40) + .pte 재현(20) — §6.3
합계	1000

PPL은 점수에 포함하지 않습니다(가능 시 소규모 subset·사후 감사로만 활용). 비중 의도: 사용자 체감을 좌우하는 품질(350) + 생성속도(TPOT 300) 에 무게, TTFT 150, 메모리·재현성 각 100.

6.3 산식

• 품질 Q = 350 × (rubric_avg − 1) / 4. rubric_avg는 24개 프롬프트 × 5항목(정확성·일관성·지시준수·환각없음·유창성, 각 1~5점)의 평균.
• 성능 S·F·M = baseline 대비 ratio (ratio = baseline / submit; TPOT·TTFT는 시간↓, Memory는 사용량↓ → ratio>1이 개선). ratio<1이면 0점.
  • TPOT·TTFT (2구간): 1×=배점의 20%, 4×=85%, 8×=100%.
    • 1 ≤ r ≤ 4: 배점 × (0.2 + 0.65 × (r−1)/3)
    • 4 < r ≤ 8: 배점 × (0.85 + 0.15 × (r−4)/4) (r>8이면 만점)
  • Memory (단일 선형, 캡 8×): 배점 × (0.2 + 0.8 × (min(r,8)−1)/7).
• 재현성 R (100) = 아래 3개 합산:
  • 제출 완전성 (40): §5 필수 항목(model.pte · run.sh · runner/(prebuilt 바이너리·필요 .so) · repro/optimize_to_pte.sh · README.md)을 규격 폴더 구조로 모두 제출. 누락·구조 불일치 시 항목별 감점.
  • 규격 준수 (40): run.sh 계약 준수 — 지정 인자 처리 + result.jsonl 스키마 완전 + self-contained(절대경로·네트워크·평가 중 빌드 없음). 미흡 시 감점.
  • .pte 재현 (20): repro/optimize_to_pte.sh가 지정 모델에서 model.pte를 재현(스팟체크). 완전 재현 20 / 부분(스크립트는 있으나 결과 불일치·일부 수동) 10 / 재현 불가 0.

6.4 게이트 (미통과 시 Team Score 0)

• 실행: .pte 정상 로드 + run.sh가 OOM·타임아웃 없이 생성 완료.
• degeneration gate: 생성이 전반적으로 degenerate(반복·공백·프롬프트 무관·즉시 종료)면 탈락 — 속도만 노린 제출 차단. (개별 프롬프트의 낮은 품질은 루브릭으로 반영.)
• 무결성: 구조 지문이 지정 모델과 불일치(다른·작은 모델) 또는 학습·pruning 흔적 → 실격 (§4.1).

재현의 정도(repro 품질)는 게이트가 아니라 §6.3 재현성(100점)으로 채점합니다.

---

7. 문의

환경이나 문서에 문의 있으시면 팀명, 실행한 명령, 로그, 재현 경로등을 함께 전달해 주세요.

© 2026. Nota Inc.