LLM 배포 최적화 연구
A study of how a persona LLM should actually be deployed: three fine-tuning regimes and two inference paths, compared on latency, memory, and persona consistency rather than benchmark score.
페르소나 LLM을 실제로 어떻게 배포할지에 대한 연구. 파인튜닝 3가지와 추론 경로 2가지를 벤치마크 점수가 아니라 지연·메모리·페르소나 일관성으로 비교했습니다
Role · ML engineer — fine-tuning pipeline, QLoRA/GGUF quantization, 4-axis deployment evaluation.
Key Metrics
Why it matters
LLM-only baseline: 65% QA / 3.2s / 7.2GB. After QLoRA + conditional hybrid RAG on Jetson: 83% QA / 1.4s / 4.1GB. The +18%p accuracy came from architecture, not a bigger model.
LLM 단독: QA 65% / 3.2s / 7.2GB. QLoRA + 조건부 하이브리드 RAG 적용 후(Jetson): QA 83% / 1.4s / 4.1GB. 정확도 +18%p는 더 큰 모델이 아니라 아키텍처 설계에서 왔습니다.
Problem
In production, generation quality alone doesn't guarantee service quality. Three configs measured: LLM-only (65% QA, 3.2s, 7.2GB) vs Jetson hybrid RAG (83% QA, 1.4s, 4.1GB) vs Server RAG (91% QA, 0.9s, server-side). The highest-scoring config is not the one that ships to a Jetson. I reframed model selection as 'which config is reliable to operate' and built the 4-axis evaluation (accuracy · latency · memory · persona consistency) to answer that — so the deployment decision is explainable, not a guess.
운영 환경에서는 생성 품질만으로 서비스 품질이 보장되지 않습니다. 3가지 설정을 측정: LLM 단독(QA 65%, 3.2s, 7.2GB) vs Jetson 하이브리드 RAG(QA 83%, 1.4s, 4.1GB) vs 서버 RAG(QA 91%, 0.9s). 가장 높은 설정이 Jetson에 배포되는 설정이 아닙니다. 4축 평가(정확도·지연·메모리·페르소나 일관성)를 설계해 배포 결정을 설명 가능하게 만들었습니다.
What I built
Fine-tuning pipeline: Persona dataset (situation→input→response, stateful flow) → Full FT vs LoRA vs QLoRA comparison → GGUF Q4_K conversion + deployment
파인튜닝 파이프라인: 페르소나 데이터셋(상황→입력→응답, 상태형) → Full FT/LoRA/QLoRA 비교 → GGUF Q4_K 변환
4-axis evaluation: QA accuracy · inference latency · memory footprint · persona consistency — measured across 3 configs
4축 평가: QA 정확도·추론 지연·메모리·페르소나 일관성. 3개 설정에서 측정
Config results: LLM-only (65%/3.2s/7.2GB) → Jetson hybrid RAG (83%/1.4s/4.1GB) → Server RAG (91%/0.9s/server-side)
설정별 결과: LLM단독(65%/3.2s/7.2GB) → Jetson 하이브리드 RAG(83%/1.4s/4.1GB) → 서버 RAG(91%/0.9s)
Conditional hybrid RAG: FAISS + BM25 score-merged → length/semantic/redundancy filter → summarized injection (each extra doc ≈ +120–180 tokens)
조건부 하이브리드 RAG: FAISS+BM25 점수 병합 → 필터 → 요약 주입(추가 문서 1개당 약 +120–180 토큰)
Jetson-specific: embedding cache (no re-embedding at runtime), FAISS top-k=3/BM25 top-k=5 merged to 2–3, conditional activation (skip casual/emotional turns)
Jetson 특화: 임베딩 캐시, top-k 튜닝(FAISS=3/BM25=5 → 2–3개 병합), 캐주얼/감정 대화 RAG 스킵
Key Decisions (trade-offs)
QLoRA over full fine-tuning
Full fine-tuning needs GPUs I didn't have. QLoRA trains on constrained hardware and keeps memory/latency deployable — accepting a small adapter-bound capacity ceiling for a shippable model.
QLoRA로 제한된 하드웨어에서 학습, 메모리·지연을 배포 가능한 수준으로 유지. 어댑터 기반 용량 상한을 받아들이는 대가로 실제 배포 가능한 모델을 얻었습니다.
GGUF Q4_K — 40% memory cut, persona intact
4-bit quantization risks persona drift. Verified empirically: ~40% memory saving with no measured loss in persona consistency across repeated dialogue scenarios. Quantization was a free win, not a quality gamble.
4비트 양자화는 페르소나 드리프트 위험이 있습니다. 반복 대화 시나리오에서 실증 검증: 약 40% 메모리 절감, 페르소나 일관성 손실 없음.
Synthesize the dataset under human guidance, not in bulk
Persona injection fails in a specific way: the model learns surface tics (catchphrases, sentence endings) while its actual behaviour stays generic. Scraping more data makes that worse, because volume dilutes the traits that define the persona. The pipeline generates situation→input→response triplets with a human-authored labeling guide constraining each field, so the dataset teaches stance and reaction rather than vocabulary. Persona alignment comes from data design, not data volume.
페르소나 주입은 특정한 방식으로 실패합니다. 말버릇과 어미 같은 표층 특징만 학습하고 실제 행동은 범용 모델 그대로 남습니다. 데이터를 더 긁어 모으면 오히려 나빠집니다. 양이 늘수록 페르소나를 정의하는 특성이 희석되기 때문입니다. 이 파이프라인은 사람이 작성한 라벨링 가이드로 각 필드를 제약한 상황→입력→응답 삼중항을 생성해, 어휘가 아니라 태도와 반응을 학습시킵니다. 정렬 품질은 데이터 양이 아니라 데이터 설계에서 나옵니다.
Keep the pipeline independent of any product
The obvious shortcut is to hard-code one persona and one deployment target into the training scripts. That produces a working model and an unusable pipeline. Data generation, QLoRA training, and inference are separated into three scripts that share only file contracts (jsonl in, merged model out), so swapping the persona means swapping the labeling guide. The cost is more configuration surface; the return is that the same pipeline retrains for a different character without touching training code.
가장 쉬운 방법은 학습 스크립트에 페르소나 하나와 배포 대상 하나를 박아 넣는 것입니다. 그러면 동작하는 모델은 나오지만 재사용할 수 없는 파이프라인이 남습니다. 데이터 생성·QLoRA 학습·추론을 세 스크립트로 분리하고 파일 계약(jsonl 입력, 병합 모델 출력)만 공유하게 했습니다. 페르소나를 바꾸는 일이 라벨링 가이드를 바꾸는 일이 됩니다. 설정할 것이 늘어나는 대신, 학습 코드를 건드리지 않고 다른 캐릭터로 재학습할 수 있습니다.
Evaluate on four axes, not one
Accuracy alone hides operational cost. Scoring accuracy + latency + memory + persona-consistency across three configs (LLM-only / Jetson RAG / Server RAG) turns model selection into a defensible operations decision. Jetson hybrid RAG won: +18%p accuracy, 2.3× faster, 43% less memory vs LLM-only.
3개 설정(LLM 단독/Jetson RAG/서버 RAG)을 4축으로 채점. Jetson 하이브리드 RAG 최종 선택: 정확도 +18%p, 속도 2.3배, 메모리 −43% vs LLM 단독.