반응형

전체 글 195

Draft 모델로 LLM 추론 속도 높이기: Speculative Decoding 실전 판단 기준

LLM은 토큰을 하나씩 순서대로 만들어야 한다. GPU가 아무리 강력해도 이 구조적 한계는 바뀌지 않는다. 흥미롭게도 병목은 행렬 연산이 아니라 메모리 대역폭에 있다. 수십억 개 파라미터를 GPU 메모리에서 읽어오는 시간이 실제 연산보다 오래 걸리고, 토큰을 하나씩 처리할 때마다 그 비용이 반복된다.Speculative Decoding은 이 구조를 우회한다. 작은 Draft 모델이 토큰 k개를 먼저 빠르게 예측하면, 큰 타깃 모델이 한 번의 포워드 패스로 그 예측들을 병렬 검증한다. 파라미터 로딩 비용을 여러 토큰에 분산할 수 있어 처리량이 늘어난다. 핵심은 수학적 보장이다. 타깃 모델이 Draft 토큰을 거부하더라도 최종 출력 분포는 타깃 모델 단독으로 생성한 것과 동일하다. 속도만 높이고 품질은 바꾸..

보상 모델 없이 LLM 정렬하기 — DPO 핵심 원리와 실전 구현

보상 모델 없이 LLM을 정렬하는 방법SFT(지도 파인튜닝)만 마친 모델은 "어떤 응답이 더 낫다"는 비교 판단을 스스로 하지 못합니다. 다음 토큰 확률을 최대화하도록만 학습되었기 때문입니다. 이 간극을 메우는 과정이 정렬(alignment)이며, 오랫동안 RLHF가 표준이었습니다. 문제는 RLHF가 SFT → 보상 모델 학습 → PPO 강화학습이라는 3단계를 요구한다는 점입니다. 각 단계는 이전 단계의 품질에 종속되어 오류가 누적되며, PPO 단계에서는 SFT 모델·보상 모델·정책 모델·가치 함수 네 개를 동시에 GPU에 올려야 합니다.DPO(Direct Preference Optimization)는 이 구조를 수학적으로 단순화합니다. RLHF 목적함수의 최적 정책을 닫힌 형태로 풀면 보상 함수를 두 ..

에이전트를 여럿으로 나눠야 할 때 — OpenAI Agents SDK 핸드오프와 가드레일

에이전트를 나눌수록 강해지는 구조LLM 기반 서비스가 단순 Q&A를 넘어 복잡한 업무 자동화로 확장되면서, 하나의 에이전트가 모든 도구와 지식을 보유하는 구조가 한계를 드러내기 시작했다. 도구 수가 10개를 넘어서면 모델이 상황에 어울리지 않는 도구를 선택하는 빈도가 눈에 띄게 높아지고, 시스템 프롬프트는 갈수록 비대해진다. 결제 처리, 기술 지원, 일반 문의처럼 민감도와 권한 범위가 다른 업무를 하나의 에이전트가 떠안으면 감사 추적이나 권한 분리도 구조적으로 불가능에 가깝다.OpenAI Agents SDK(2025년 3월 공개)는 이 문제를 핸드오프(handoff) 를 일급 개념으로 정의함으로써 풀고자 했다. 핸드오프는 단순한 함수 호출과 의미론적으로 다르다. 일반 도구 호출은 결과만 받아 에이전트가 ..

개발 중 LLM 비용 0원 만들기: Ollama 실전 가이드

상용 LLM API를 개발 중에 무제한으로 호출하면 어떻게 될까요. 프로토타입 하나를 만들다 보면 반복 테스트와 CI 파이프라인 통합이 쌓이면서 청구서가 예상보다 빠르게 불어납니다. Ollama는 이 문제에 대한 실용적인 답입니다. macOS·Linux·Windows 어디서나 단일 바이너리 설치로 Llama 3, Mistral, Qwen 같은 오픈 가중치 모델을 로컬에서 서빙하고, OpenAI와 동일한 API 형식으로 노출합니다. 개발할 때는 비용 없는 로컬 모델, 프로덕션에서는 상용 API, 이 전환을 환경 변수 하나로 처리하는 것이 핵심입니다.비용과 보안, 두 문제를 한 번에LLM 기반 애플리케이션 개발에서 API 비용은 생각보다 빨리 문제가 됩니다.예시 1. GPT-4o 기준 입력 토큰 $2.50/..

LLM 응답을 실시간으로 흘려보내는 법 — SSE 스트리밍 실전 가이드

LLM 스트리밍이 필요한 이유GPT-4나 Claude 같은 모델은 500 토큰 분량의 응답을 생성하는 데 보통 5~10초가 걸린다. 동기적 API 방식에서는 이 시간 동안 사용자가 빈 화면을 바라봐야 한다. SSE(Server-Sent Events) 스트리밍을 적용하면 첫 번째 토큰이 300ms 안에 화면에 나타나기 시작하고, 이후 텍스트가 흘러내리는 경험을 제공한다. 체감 응답 속도가 수십 배 빨라지는 셈이다.타임아웃 문제도 현실적인 이유다. AWS Application Load Balancer의 기본 유휴 연결 타임아웃은 60초다. 긴 문서 요약이나 복잡한 코드 생성처럼 응답이 60초를 넘을 수 있는 작업에서 동기 방식을 쓰면 응답이 완성되기 전에 연결이 강제로 끊긴다. 스트리밍 방식에서는 데이터가 ..

프롬프트도 배포가 필요하다: PromptOps 실전 가이드

LLM 기반 서비스를 운영하다 보면 코드보다 프롬프트를 더 자주 손댑니다. 새로운 엣지 케이스가 생길 때마다, 모델이 업그레이드될 때마다, 요구사항이 바뀔 때마다 프롬프트는 조금씩 달라집니다. 문제는 이 변경 이력이 누군가의 메모나 Notion 페이지에만 남는다는 것입니다. 어떤 버전이 지금 프로덕션에서 돌고 있는지, 왜 그렇게 됐는지 추적할 방법이 없다면 서비스 품질 관리는 사실상 불가능합니다. PromptOps는 이 혼란에 체계를 부여하는 방법론입니다.프롬프트를 아티팩트로 취급하라PromptOps의 출발점은 단순합니다. 프롬프트를 소스 코드나 컨테이너 이미지처럼 버전이 붙은 관리 대상으로 다루는 것입니다. 컨테이너에 :v2.3.0 태그가 있듯, 프롬프트에도 식별 가능한 버전 번호가 있어야 합니다. 그..

LLM 앱을 공격하는 방법, 그리고 막는 방법

LLM 기반 서비스가 고객 응대, 문서 요약, 코드 생성 같은 핵심 업무에 쓰이기 시작하면서, 자연어 인터페이스 자체가 공격의 진입점이 되고 있습니다. 기존 보안은 SQL 인젝션이나 XSS처럼 특정 문법 구조를 겨냥했습니다. LLM 공격은 그 반대입니다. 모델이 "의미를 이해한다"는 특성을 역이용해, 올바른 자연어만으로 시스템 지시를 무력화하거나 민감한 정보를 빼냅니다.LLM 공격이 기존 보안과 다른 이유LLM 애플리케이션에서는 시스템 프롬프트, 사용자 메시지, RAG로 주입된 외부 문서, 도구 응답이 모두 단일 컨텍스트 창 안에 섞입니다. 모델은 이것들을 구조적으로 구분하지 않고 의미 기반으로 처리합니다. 신뢰도 높은 시스템 프롬프트와 신뢰도 낮은 사용자 입력이 같은 공간에서 충돌할 때 예측하기 어려운..

Qdrant 프로덕션 운영: 컬렉션 설계 실수부터 검색 느림 진단까지

Qdrant 프로덕션 운영: 설계 실수와 성능 진단벡터 데이터베이스를 개발 환경에서 돌리는 것과 실제 서비스에 붙이는 것은 전혀 다른 이야기다. Qdrant는 기본 설정만으로도 작동하지만, 수백만 개 이상의 벡터가 쌓이고 트래픽이 올라오면 초기 컬렉션 설계 결정 하나가 수 시간짜리 재색인 작업으로 돌아온다.운영 환경에서 가장 먼저 마주치는 함정은 컬렉션 재생성 비용을 과소평가하는 것이다. 차원(dimension)이나 거리 메트릭(distance metric)을 잘못 설정하면 데이터를 전부 버리고 처음부터 다시 색인해야 한다. 이 두 파라미터는 생성 후 변경이 불가능하기 때문에, 전체 데이터의 1% 샘플로 먼저 설정을 검증한 뒤 전체를 적재하는 습관이 필수다.예시 1. 5백만 개 문서를 OpenAI tex..

에이전트가 망가지는 이유는 모델이 아니라 컨텍스트다

LLM 에이전트를 운영하다 보면 이상한 경험을 한다. 분명 같은 모델인데, 어제는 잘 작동하던 에이전트가 오늘은 엉뚱한 도구를 호출하거나 이미 완료된 작업을 반복한다. 모델 탓을 하고 싶지만, 정작 원인을 추적하면 모델이 아니라 컨텍스트가 문제였다는 결론에 이르는 경우가 많다.Context Engineering은 LLM이 올바른 작업을 수행하도록 컨텍스트 윈도우 안에 담길 정보를 의도적으로 설계하는 실천이다. 단순히 프롬프트를 다듬는 것을 넘어, 무엇을 넣고, 어떻게 구조화하고, 언제 갱신할지를 체계적으로 결정하는 공학 영역이다.컨텍스트가 에이전트 성능을 결정한다에이전트가 도구를 호출하고 여러 단계에 걸쳐 추론하는 복잡한 워크플로우가 보편화되면서, 단일 프롬프트 최적화의 한계가 드러났다. 에이전트 루프가..

RAG 검색 품질을 결정하는 청킹 전략 3가지

문서를 쪼개는 방식 하나가 RAG 시스템 전체 품질을 결정한다는 말이 과장처럼 들릴 수 있다. 하지만 벡터 검색의 작동 원리를 들여다보면 이 말은 꽤 정확하다. 아무리 뛰어난 임베딩 모델을 써도, 청크 하나가 "하나의 의미 단위"를 온전히 담지 못하면 쿼리 벡터와의 유사도 계산이 처음부터 어긋난다. 청킹은 단순한 전처리가 아니라 검색 가능성 자체를 설계하는 작업이다.청킹이 검색 품질을 결정하는 이유RAG 시스템에서 문서는 청크 단위로 임베딩되어 벡터 DB에 저장된다. 검색 시 쿼리도 같은 모델로 벡터화되고, 코사인 유사도로 가장 가까운 청크를 찾는다. "G1GC Region 분할 방식"만 담은 청크는 그 주제에 밀집된 벡터가 생성되지만, 3페이지짜리 GC 개요 문서를 통째로 하나의 청크로 만들면 "Jav..

반응형