Qwen 및 Gemma를 위한 에이전틱 LLM 추론 파라미터 참조
에이전틱 LLM 튜닝 참고 자료
이 페이지는 에이전트형 LLM 추론 튜닝에 대한 실용적인 참고 자료입니다(temperature, top_p, top_k, penalties 및 다단계 및 도구 중심 워크플로우에서의 상호 작용 방식).
이 내용은 더 광범위한 LLM 성능 엔지니어링 허브와 함께 제공되며, 명확한 LLM 호스팅 및 서비스 스토리와 가장 잘 부합합니다. 모델이 자원 부족 상태일 때 처리량과 스케줄링이 여전히 지배적이지만, 불안정한 샘플링은 GPU가 처리하기 전에 재시도와 출력 토큰을 소모합니다.
이 페이지는 다음 내용을 통합합니다:
- 벤더 권장 매개변수
- GGUF 및 API의 내장 기본값
- 실제 커뮤니티 발견 사항
- 에이전트 워크플로우 최적화
현재 다음과 같은 모델에 초점을 맞추고 있습니다:
- Qwen 3.6 (Dense 및 MoE)
- Gemma 4 (Dense 및 MoE)
OpenCode와 같은 터미널 에이전트를 실행 중이라면, 이 참고 자료를 OpenCode의 로컬 LLM 동작와 함께 사용하여 워크로드 수준의 결과와 샘플러 기본값이 일치하도록 하세요.
목표는 간단합니다:
에이전트 루프, 코딩, 다단계 추론을 위한 모델 구성을 위한 단일 장소를 제공합니다.
TLDR 참고 테이블 - 모든 모델 (에이전트 기본값)
| 모델 | 모드 | temp | top_p | top_k | presence_penalty |
|---|---|---|---|---|---|
| Qwen 3.5 27B | thinking general | 1.0 | 0.95 | 20 | 0.0 |
| Qwen 3.5 27B | coding | 0.6 | 0.95 | 20 | 0.0 |
| Qwen 3.5 35B MoE | thinking | 1.0 | 0.95 | 20 | 1.5 |
| Qwen 3.5 35B MoE | coding | 0.6 | 0.95 | 20 | 0.0 |
| Gemma 4 31B | general | 1.0 | 0.95 | 64 | 0.0 |
| Gemma 4 31B | coding | 1.2 | 0.95 | 65 | 0.0 |
| Gemma 4 26B MoE | general | 1.0 | 0.95 | 64 | 0.0 |
| Gemma 4 26B MoE | coding | 1.2 | 0.95 | 65 | 0.0 |
“에이전트 추론"의 실제 의미
대부분의 매개변수 가이드는 다음과 같은 가정하에 작성됩니다:
- 채팅
- 단발성 완료(Single-shot completion)
- 인간 상호 작용
에이전트 시스템은 다릅니다.
에이전트 시스템은 다음을 요구합니다:
- 다단계 추론
- 도구 호출(Tool calling)
- 일관된 출력
- 낮은 오류 전파
이는 튜닝 우선순위를 변경시킵니다.
핵심 변화
| 사용 사례 | 우선순위 |
|---|---|
| 채팅 | 자연어 품질 |
| 창작 | 다양성 |
| 에이전트 | 일관성 + 추론 안정성 |
Qwen 3.6 튜닝
Dense와 MoE의 차이
Qwen은 다음과 같은 특징을 가진 몇 안 되는 모델 패밀리입니다:
MoE는 다른 페널티가 필요합니다
Dense (27B)
- 안정적
- 예측 가능
- 라우팅 복잡성 없음
권장 사항:
- presence_penalty = 0.0
MoE (35B-A3B)
- 토큰별 전문가 라우팅
- 반복 루프 발생 위험
권장 사항:
- presence_penalty = 1.5 (일반)
- 코딩용: 0.0
왜 중요한가
MoE 모델은 동일한 전문가를 재사용하는 데 고착될 수 있습니다.
Presence penalty는 다음과 도움을 줍니다:
- 토큰 경로 다양화
- 추론 탐색 개선
Qwen 에이전트 코딩 설정
여기서 대부분의 사람들이 실수를 합니다.
올바른 설정
- temperature = 0.6
- top_p = 0.95
- top_k = 20
- presence_penalty = 0.0
왜 낮은 temperature가 효과적인가
코딩 에이전트는 다음이 필요합니다:
- 결정론적 출력(Deterministic outputs)
- 반복 가능한 도구 호출
- 안정적인 포맷팅
높은 temperature의 문제점:
- JSON 파손
- 환각된 API 도입
- 재시도 증가
Gemma 4 튜닝
Gemma는 다르게 동작합니다.
공식 기본값 부재
- 모델 카드가 비어 있음
- 설정이 암묵적임
- 실제 튜닝은 다음에서 나옴:
- Google AI Studio
- GGUF 기본값
- 커뮤니티 벤치마크
직관에 반하는 발견
Gemma 4는 높은 temperature에서 더 잘 수행됩니다.
관찰된 동작
| Temp | 결과 |
|---|---|
| 0.5 | 추론 성능 저하 |
| 1.0 | 안정적인 기준선 |
| 1.2 to 1.5 | 최고의 코딩 성능 |
이는 일반적인 조언과 상충됩니다.
왜 높은 temperature가 여기서는 효과적인가
가설:
- 학습 분포가 탐색을 선호
- 추론 모드가 다양성에 의존
- 명시적 Chain-of-Thought 제어의 부족을 모델이 보상
결과:
높은 temperature가 솔루션 탐색 공간을 개선
Gemma 에이전트 코딩 설정
권장 사항:
- temperature = 1.2
- top_p = 0.95
- top_k = 65
- penalties = 0.0
중요
전통적인 “코드는 낮은 temperature” 규칙을 맹목적으로 적용하지 마십시오.
Gemma는 예외입니다.
사고 모드(Thinking Mode)와 에이전트 시스템
Qwen과 Gemma 모두 추론 모드를 지원합니다.
왜 중요한가
에이전트 루프는 다음을 요구합니다:
- 중간 단계 추론
- 오류 복구
- 다단계 계획
실용적인 규칙
다음에 대해 항상 사고 모드를 활성화하십시오:
- 코딩 에이전트
- 도구 사용
- 다단계 작업
사용 사례별 매개변수 전략
코딩 에이전트
- 결정론 우선
- 페널티 최소화
- 안정적인 샘플링
추론 에이전트
- 중간 temperature
- 탐색 허용
- 구조 보존
도구 호출
- 엄격한 포맷팅
- 낮은 무작위성
- 일관된 토큰 패턴
Schema와 JSON 도구는 로짓(Logits)과 직교합니다; 유효성 검사기가 fewer 재시도를 보도록 이 샘플링 규칙을 Ollama 및 Qwen3를 위한 구조화된 출력 패턴과 결합하십시오.
벤더 기본값 대 현실
벤더 기본값은 다음과 같습니다:
- 안전함
- 일반적임
- 최적화되지 않음
커뮤니티 발견 사항은 종종 다음을 보여줍니다:
- 더 나은 성능
- 작업별 튜닝
- 아키텍처 인식 조정
예시
Gemma:
- 공식: 지침 부재
- 커뮤니티: 높은 temperature가 코딩 개선
Qwen:
- 공식: 불일치하는 섹션
- 커뮤니티: 표준화된 값으로 수렴
실용적인 배포 참고 사항
동시성 하에서 큐잉과 메모리 분할은 샘플링만큼 재시도와 상호 작용합니다—위의 프리셋과 함께 Ollama가 병렬 요청을 처리하는 방법을 읽으십시오.
Ollama
- 두 패밀리 모두 잘 작동
- GPU 호환성 확인
- 기본값이 참고 자료와 다를 수 있음
vLLM
- 고급 샘플링 지원
- 프로덕션에 안정적
- 명시적 매개변수 사용
llama.cpp
- 샘플러 순서 필요
- 현대 모델에는 항상 jinja 활성화
- 잘못된 샘플러 체인이 출력 품질 저하
주요 요점
- 보편적인 매개변수 세트는 없음
- 아키텍처가 모델 크기보다 중요
- 에이전트 시스템은 채팅과 다른 튜닝 필요
- 커뮤니티 벤치마크가 종종 벤더보다 앞서 있음
최종 의견
대부분의 매개변수 가이드는过时되었습니다.
그들은 다음을 가정합니다:
- 채팅 사용
- 코딩용 낮은 temperature
- 정적 구성
현대 모델은 이러한 가정을 깨뜨립니다.
에이전트 시스템을 구축 중이라면:
추론 튜닝을 일급 시스템 설계 문제로 취급하십시오
설정 파일이 아닙니다.
미래 방향
이 참고 자료는 다음과 같이 발전될 것입니다:
- 모델별 심층 분석
- 에이전트 전용 구성
- 벤치마크 기반 튜닝
왜냐하면:
추론은 모델 기능이 시스템 성능으로 전환되는 곳입니다
