Gemma 4 12b 8Q Heretic 모델의 원샷 코딩 성능

요약

Gemma 4 12b Heretic 모델을 활용하여 단 한 번의 프롬프트로 복잡한 레트로 게임 코드를 생성하는 성능을 테스트했습니다. llama.cpp 환경에서 8-bit KV 캐시를 적용하여 높은 캐시 재사용률과 안정적인 생성 속도를 유지하며 성공적인 결과를 얻었습니다.

핵심 포인트

Gemma 4 12b Heretic 모델의 뛰어난 원샷 코딩 능력 확인
8-bit KV 캐시 적용을 통한 높은 캐시 재사용률(최대 96.4%) 달성
대규모 컨텍스트 확장 시에도 안정적인 생성 속도(약 18t/s) 유지
llama.cpp를 활용한 효율적인 로컬 모델 추론 설정 공유

오늘 출시된 Gemma 4 12b 버전에 꽤 깊은 인상을 받았고, heretic 버전도 출시된 것을 확인했습니다. 저는 이미 8Q 공식 모델에서 거절(refusals)을 경험하고 있었기에, heretic 버전이 레트로 게임을 원샷(oneshotting)으로 구현하는 능력이 어느 정도인지 확인해 보기로 했습니다. 결과는 매우 수월하게 해냈습니다. 시작부터 끝까지 단 하나의 프롬프트로 총 45k 토큰을 소모했습니다.

하드웨어 스택 (Hardware Stack): Ryzen 9 9950X + AMD RX 6800 (16GB VRAM), Vulkan 백엔드 사용, 32GB 6000 시스템 RAM.
모델 및 설정 (Model & Config): H-gemma-4-12B-heretic-Q8.gguf, 8-bit KV 캐시 ( --cache-type-k q8_0 --cache-type-v q8_0 ) 적용.
생성 속도 (Generation Speed): 매우 안정적이었으며, 4번의 턴 전체에 걸쳐 18.44 t/s에서 18.93 t/s 사이를 일정하게 유지했습니다.
컨텍스트 스케일링 (Context Scaling): 마지막 턴에서 활성 컨텍스트가 23,125 토큰까지 확장되었음에도 불구하고 속도 저하가 거의 없었습니다.
주요 실행 결과 (The Big Run): 2번째 턴에서 18.76 t/s의 속도로 4분 동안 연속적인 스트림을 통해 4,372 토큰의 연속된 코드(467줄의 게임 작성)를 생성했습니다.
프롬프트 처리 (Prompt Processing): 깨끗한 상태에서 228.79 t/s로 시작하여, 컨텍스트 깊이가 증가함에 따라 자연스럽게 157.72 t/s로 감소했습니다.
캐시 효율성 (Cache Efficiency): llama-server가 컨텍스트 체크포인트와 최장 공통 접두사 (LCP, Longest Common Prefix) 유사성을 성공적으로 활용하여, 후속 턴에서 91.7% 및 96.4%의 캐시 재사용률을 기록하며 방대한 재평가 과정을 우회했습니다.

다음은 제 llama.cpp 실행 명령입니다.
./llama.cpp/build/bin/llama-server -m /home/dsmason321/models/H-gemma-4-12B-heretic-Q8.gguf -c 256000 --jinja --chat-template-file /home/dsmason321/llama.cpp/models/templates/custom_pub_chat_template_gemma4.jinja --reasoning off --cache-type-k q8_0 --cache-type-v q8_0

다음은 프롬프트입니다.
전문 시니어 프론트엔드 개발자(Senior Frontend Developer)이자 게임 디자이너(Game Designer)로서 행동하십시오. 당신의 작업은 단일한, 독립적인 HTML 파일 내에 포함된 완전하고, 완전히 기능하며, 시각적으로 세련된 "레트로 사이버펑크 벽돌 깨기(Retro Cyberpunk Brick Breaker)" 게임을 작성하는 것입니다. 플레이스홀더(placeholders), 말줄임표(...), 또는 누락된 구현 없이 반드시 최종 완성된 코드를 전달해야 합니다. 게임은 브라우저에서 저장하고 여는 즉시 완전히 플레이 가능해야 합니다.

기술 아키텍처 (Technical Architecture)

언어 (Language): HTML5, CSS3, 그리고 Vanilla JavaScript.
렌더링 (Rendering): HTML5 <canvas> API.
파일 구조 (File Structure): 단일 파일. 모든 CSS는 <style> 태그 내에, 모든 JavaScript는 <script> 태그 내에 포함.
에셋 (Assets): 외부 이미지, 오디오 파일 또는 라이브러리 사용 금지. 모든 시각적 에셋(플레이어 패들, 공, 벽돌, 파티클)은 Canvas 2D 컨텍스트 드로잉 메서드(그라데이션, 사각형, 호)를 사용하여 프로그래밍 방식으로 그려져야 함.

게임 메커니즘 및 사양 (Game Mechanics & Specifications)

핵심 루프 (Core Loop): 하단의 패들이 공을 위로 튕겨 올려 상단의 그리드 기반 벽돌을 파괴함. 모든 벽돌을 파괴하면 "승리 (Victory)" 상태가 트리거되며, 공이 하단 경계 너머로 사라지면 생명이 차감됨.
조작 (Controls): 패들을 움직이기 위한 부드러운 마우스 트래킹 또는 왼쪽/오른쪽 화살표 키. 패들이 캔버스 너비 내에 안전하게 제한되도록 보장할 것.
물리 (Physics): 공이 패들의 어느 부위에 부딪히는지에 따른 현실적인 각도 반사 (패들의 가장자리에 부딪히면 공이 더 날카로운 각도로 발사됨).
진행 및 점수 (Progression & Score):

점수 시스템 구현 (예: 벽돌당 10점).
플레이어 생명 추적 (3개로 시작).
현재 점수 (Current Score), 최고 점수 (High Score, localStorage에서 저장/로드), 남은 생명 (Remaining Lives)을 상단의 깔끔한 HUD로 표시.
게임 상태 (Game States): 명확한 "시작 화면 (Start Screen)" (클릭하여 플레이), "게임 오버 화면 (Game Over Screen)", 그리고 즉각적인 키보드 또는 클릭 재시작 트리거가 있는 "승리 화면 (Victory Screen)".
로컬 LLM 안전 기능 (중요) (Local LLM Safety Feature):
낮은 연산 성능의 로컬 추론 (local inference) 환경에서 루프가 성능 저하나 메모리 누수를 일으키지 않도록 벽돌 그리드 크기를 적절하게 유지할 것 (예: 4행 8열).

미적 및 시각적 완성도 (Aesthetic & Visual Polish)

테마 (Theme): 사이버펑크 (Cyberpunk) / 네온 신스웨이브 (Neon Synthwave).
배경 (Background): 짙은 미드나잇 블랙 또는 어두운 보라색 그라데이션.
요소 (Elements): 벽돌과 패들에 밝은 네온 컬러 (시안, 마젠타, 일렉트릭 라임) 사용.
주시성 (Juiciness): 벽돌이 파괴될 때 간단한 파티클 폭발 효과 구현 (몇 프레임에 걸쳐 사라지는 5~8개의 작은 부서지는 파티클 객체 생성).
ctx.shadowBlur 및 ctx.shadowColor를 사용하여 캔버스 요소에 미묘한 글로우(glow) 효과 추가.

구현 요구사항 (Implementation Requirements)

전체 스크립트를 깔끔하게 감싸세요.
모든 변수 초기화 (variable initializations), 이벤트 리스너 (event listeners), 상태 리셋 루프 (state reset loops), 그리고 requestAnimationFrame 업데이트 루프가 완전히 작성되었는지 확인하세요.
코드 블록 전후에 텍스트 주석을 추가하지 마세요. 그래야 원시 출력 (raw output)을 쉽게 추출할 수 있습니다. <!DOCTYPE html>로 직접 시작하세요.

/u/devildip가 r/LocalLLaMA에 제출함 [link] [comments]

AI 자동 생성 콘텐츠

원문 바로가기