7. 프롬프트, 컨텍스트, KV 캐시를 이해하며 품질 올리기
7. 프롬프트, 컨텍스트, KV 캐시를 이해하며 품질 올리기
같은 모델인데도 어떤 날은 똑똑하고, 어떤 날은 엉뚱하게 답하는 이유가 있습니다. 초보자는 종종 "모델이 별로네"라고 생각하지만, 실제로는 입력 방식이 문제인 경우가 많습니다. 특히 llama.cpp에서는 채팅 템플릿, 시스템 프롬프트, 컨텍스트 길이, KV 캐시 설정이 결과를 크게 바꿉니다. 최신 GGUF 모델은 대개 모델 메타데이터 안에 tokenizer.chat_template를 담고 있고, llama.cpp나 llama-cpp-python은 이를 우선 활용해 대화를 하나의 프롬프트 텍스트로 바꿉니다.12
이 장의 목표는 아주 분명합니다. "질문을 더 잘하는 법"을 감으로 익히는 것이 아니라, 모델이 실제로 어떤 순서로 입력을 읽고 다음 토큰을 뽑는지 이해해서 품질과 안정성을 올리는 것입니다. 한마디로 말하면, 모델을 혼내기 전에 먼저 입력 파이프를 정리하자는 이야기입니다.

먼저 큰 그림부터: 답변은 이렇게 만들어진다
온디바이스 LLM의 답변은 마법처럼 생기지 않습니다. 대략 이런 순서로 흘러갑니다.
사용자의 대화 메시지와 시스템 지시를 준비합니다.
채팅 템플릿이 이를 모델이 이해하는 하나의 긴 텍스트로 바꿉니다.
토크나이저가 텍스트를 토큰으로 나눕니다.
모델이 현재까지의 토큰을 읽고 다음 토큰 후보들의 확률을 계산합니다.
샘플링 설정에 따라 다음 토큰 하나를 선택합니다.
방금 뽑은 토큰이 다시 입력 뒤에 붙고, 이 과정을 반복합니다.3
이 흐름을 이해하면 왜 같은 질문이라도 템플릿이 틀리면 이상한 답이 나오고, 컨텍스트가 넘치면 앞 내용을 잊어버리고, KV 캐시가 커질수록 메모리가 빠르게 부족해지는지 자연스럽게 연결됩니다.
Step 1. 채팅 템플릿이 왜 중요한가
초보자가 가장 자주 놓치는 부분이 바로 채팅 템플릿입니다. 우리는 보통 대화를 system, user, assistant 같은 구조화된 메시지로 생각하지만, 모델은 그 구조를 그대로 읽지 않습니다. 실제로는 각 모델 계열이 기대하는 특정 문자열 형식으로 변환된 뒤 입력됩니다.14
예를 들어 어떤 모델은 ChatML 스타일을 기대하고, 어떤 모델은 Llama 3 스타일 헤더 토큰을 기대하며, 어떤 모델은 Gemma 스타일 turn 구분자를 기대합니다.15 즉, 겉으로는 모두 "채팅"이지만 모델 내부에서는 서로 다른 문법을 쓰는 셈입니다.
아주 쉽게 비유하면 이렇습니다. 같은 내용을 한국어로 말하느냐, 일본어로 말하느냐에 따라 상대가 이해하는 방식이 달라지듯, 모델도 자신이 훈련 때 자주 본 대화 형식을 더 잘 이해합니다. 템플릿이 맞으면 "아, 지금은 시스템 지시구나", "이건 사용자 질문이네", "이제 내가 답할 차례군" 하고 흐름을 잘 잡습니다. 템플릿이 틀리면 역할 경계가 흐려져서 말투가 깨지거나, 질문을 반복하거나, 엉뚱한 특수 토큰을 흉내 내기도 합니다.15
llama.cpp는 여러 내장 템플릿을 지원하고, 모델 메타데이터에 있는 chat_template를 바탕으로 자동 감지하거나 지정된 템플릿을 적용할 수 있습니다.15 llama-cpp-python 역시 우선순위에 따라 chat_handler, chat_format, GGUF의 tokenizer.chat_template, 마지막으로 기본 포맷을 사용합니다.2
초보자 입장에서 기억할 핵심은 하나입니다. 모델이 Instruct/Chat 모델이라면, 반드시 그 모델에 맞는 채팅 형식으로 넣어야 한다는 점입니다.
Step 2. 템플릿이 맞지 않을 때 나타나는 증상
템플릿 문제는 생각보다 티가 많이 납니다. 다음과 같은 현상이 반복되면 거의 의심해볼 만합니다.
답변 첫 줄에 이상한 특수 토큰이 그대로 출력된다.
모델이 사용자 역할까지 이어서 써 버린다.
시스템 지시를 무시하고 기본 말투로 돌아간다.
여러 턴 대화에서 역할이 뒤섞인다.
"Assistant:"나
<|im_start|>같은 문자열을 계속 출력한다.15
이런 경우 모델 자체 성능이 나쁜 것이 아니라, 입력 포맷이 어긋난 경우가 많습니다. 특히 GGUF로 변환된 파일마다 메타데이터 품질이 조금씩 다를 수 있으므로, 자동 감지가 잘 안 되는 모델은 명시적으로 템플릿을 지정하는 편이 안전합니다.1
예를 들어 서버를 띄울 때 이런 식으로 템플릿을 직접 지정할 수 있습니다.
./build/bin/llama-server -m ./models/model.gguf --chat-template llama3혹은 ChatML 계열 모델이라면 다음처럼 사용할 수 있습니다.
./build/bin/llama-server -m ./models/model.gguf --chat-template chatml반대로, 최신 GGUF 모델이라면 템플릿 정보가 메타데이터에 포함되어 있어서 별도 지정 없이도 잘 동작하는 경우가 많습니다.12
Step 3. 시스템 프롬프트는 모델의 "작업 모드"를 정한다
시스템 프롬프트는 단순한 소개 문장이 아닙니다. 모델의 역할, 말투, 금지사항, 출력 형식, 우선순위를 정하는 최상위 지시입니다. 채팅 모델은 보통 시스템 메시지를 먼저 읽고, 그 뒤에 사용자 질문을 읽습니다. 그래서 같은 질문이라도 시스템 프롬프트에 따라 답변이 완전히 달라질 수 있습니다.45
예를 들어 사용자가 "이 문서를 요약해줘"라고 말했을 때, 시스템 프롬프트가 없으면 모델은 일반적인 요약을 시도합니다. 하지만 시스템 프롬프트를 이렇게 주면 이야기가 달라집니다.
당신은 초보자를 돕는 한국어 기술 튜터입니다.
모르는 내용은 추측하지 말고, 불확실하면 그렇게 말하세요.
답변은 1) 한 줄 요약 2) 핵심 설명 3) 다음 행동 순서로 작성하세요.이 지시는 모델에게 세 가지를 동시에 알려줍니다. 역할, 안전성 기준, 출력 형식입니다. 이 세 가지가 정리되면 답변 품질이 안정됩니다.
하지만 시스템 프롬프트는 길다고 무조건 좋은 것이 아닙니다. 너무 장황하면 중요한 규칙이 묻히고, 토큰만 많이 차지합니다. 더 나쁜 경우에는 규칙끼리 충돌해서 모델이 우왕좌왕합니다. 초보자에게는 다음 원칙이 좋습니다.
역할을 한 문장으로 정합니다.
반드시 지켜야 할 규칙만 넣습니다.
출력 형식을 짧고 명확하게 지정합니다.
금지사항은 최소한만 둡니다.
예를 들어 "친절하게, 간단히, 예시를 포함해 설명하라" 정도는 좋습니다. 하지만 "절대 A를 하지 말고, B를 우선하되 C는 조건부로 허용하고, D는 예외이며…"처럼 법전처럼 길어지면 오히려 품질이 떨어질 수 있습니다.
Step 4. 좋은 시스템 프롬프트를 만드는 실전 공식
초보자는 아래 틀만 기억해도 체감 품질이 꽤 올라갑니다.
당신은 [역할]입니다.
대상 독자는 [대상]입니다.
답변은 [스타일]로 작성하세요.
모르면 추측하지 말고 불확실하다고 말하세요.
출력은 [형식]을 따르세요.예를 들어 llama.cpp 로컬 챗봇이라면 이렇게 쓸 수 있습니다.
당신은 온디바이스 LLM 구축을 돕는 한국어 기술 코치입니다.
대상 독자는 초보 개발자입니다.
답변은 쉬운 한국어로, 단계별로 설명하세요.
명령어를 제시할 때는 짧은 설명을 덧붙이세요.
모르는 사실은 지어내지 말고 확인이 필요하다고 말하세요.
출력은 핵심 설명 뒤에 실행 순서를 제시하세요.이 정도면 충분히 강력합니다. 시스템 프롬프트는 "크게 외치는 규칙"이 아니라 "계속 유지되는 분위기와 기준"이라고 이해하면 좋습니다.
Step 5. 사용자 프롬프트는 짧게가 아니라, 분명하게가 핵심이다
좋은 사용자 프롬프트는 멋있게 쓰는 문장이 아닙니다. 모델이 헷갈리지 않게 쓰는 문장입니다. 특히 로컬 모델은 초대형 클라우드 모델보다 추론 여유가 적을 수 있어서, अस्पष्ट한 요청에 더 흔들리기 쉽습니다.
예를 들어 이런 질문은 애매합니다.
이거 좀 설명해줘.모델은 "이거"가 무엇인지, 얼마나 자세히 설명해야 하는지, 누구 수준에 맞춰야 하는지 모릅니다. 반면 이렇게 바꾸면 훨씬 좋아집니다.
KV 캐시가 무엇인지 초보자 기준으로 설명해줘.
llama.cpp 사용자를 대상으로 하고,
1) 개념 2) 왜 메모리를 많이 쓰는지 3) 줄이는 방법 순서로 알려줘.좋은 프롬프트는 보통 범위, 대상, 형식이 보입니다. 이 세 가지가 명확하면 작은 모델도 훨씬 안정적으로 답합니다.
Step 6. 컨텍스트 길이는 "기억력"이 아니라 "작업 공간"이다
이제 많은 사람이 헷갈리는 컨텍스트를 보겠습니다. 컨텍스트 길이는 모델이 한 번에 바라볼 수 있는 토큰의 최대 범위입니다. 쉽게 말하면 작업 책상 크기입니다. 책상이 너무 작으면 필요한 자료를 다 펼칠 수 없고, 너무 크게 잡으면 메모리 부담이 커집니다.67
중요한 점은 컨텍스트에 들어가는 것이 현재 질문만이 아니라 시스템 프롬프트, 이전 대화, 첨부 문서, 그리고 방금 생성 중인 답변까지 모두 포함된다는 점입니다.68 그래서 초반에는 멀쩡하던 모델이 대화를 오래 하다 보면 갑자기 앞의 약속을 잊어버리거나, 문체가 흐려지거나, 중요한 정보를 놓치는 일이 생깁니다. 책상 위가 이미 꽉 찼기 때문입니다.
llama.cpp에서는 컨텍스트 크기를 --ctx-size 또는 -c로 조정합니다.8
./build/bin/llama-cli -m ./models/model.gguf -c 4096 -p "안녕하세요"기본값은 환경과 빌드에 따라 다를 수 있지만, 일반적으로 무턱대고 크게 잡는 것은 좋지 않습니다. 모델 카드에 "128K 지원"이 적혀 있어도, 실제 장비에서는 KV 캐시 메모리 때문에 그 길이를 현실적으로 쓰기 어렵습니다.67
초보자에게는 다음 감각이 중요합니다.
일반 채팅은 4K~8K면 충분한 경우가 많습니다.
긴 문서 요약이나 RAG는 16K 이상이 필요할 수 있습니다.
컨텍스트를 두 배로 늘리면 편해지는 것이 아니라, 메모리 부담도 거의 선형으로 함께 커집니다.67
Step 7. KV 캐시는 왜 메모리를 잡아먹는가
KV 캐시는 긴 컨텍스트를 이해하는 데 꼭 필요한 메모리 구조입니다. 모델은 새 토큰을 생성할 때 이전 모든 토큰을 매번 처음부터 다시 계산하지 않으려고, 각 토큰의 Key와 Value 정보를 저장해 둡니다. 이것이 KV 캐시입니다.679
이 덕분에 생성 속도는 빨라집니다. 하지만 대가가 있습니다. 토큰이 하나 늘어날 때마다, 각 레이어에 대해 저장해야 할 값도 늘어납니다. 그래서 컨텍스트가 길어질수록 KV 캐시가 선형으로 커집니다.67
감각적으로 이해해 봅시다. 모델 가중치는 "기본 장비"입니다. 한 번 로드하면 크기가 거의 고정됩니다. 반면 KV 캐시는 "작업 중 쌓이는 메모장"입니다. 대화가 길어질수록 계속 커집니다. 짧은 대화에서는 별것 아니지만, 32K나 128K처럼 긴 컨텍스트에 가면 모델 가중치보다 KV 캐시가 더 큰 메모리를 차지할 수도 있습니다.67
이 때문에 "모델 파일은 5GB인데 왜 실행하면 10GB 넘게 먹지?" 같은 일이 생깁니다. 모델 파일 크기만 보고 메모리를 판단하면 안 되는 이유가 바로 여기 있습니다.
Step 8. KV 캐시를 줄이는 가장 현실적인 방법
KV 캐시 문제를 해결하는 가장 쉬운 방법은 놀랍게도 "정말 필요한 만큼만 컨텍스트를 쓰는 것"입니다.6 필요 이상으로 32K, 64K를 잡아두면 품질이 좋아지기보다 메모리와 속도만 손해 보는 경우가 많습니다.
그다음으로 유용한 방법은 KV 캐시 양자화입니다. llama.cpp는 K와 V 캐시 타입을 지정할 수 있고, f16 대신 q8_0이나 q4_0 같은 형식을 사용해 캐시 메모리를 줄일 수 있습니다.8
예를 들면 다음과 같습니다.
./build/bin/llama-server \
-m ./models/model.gguf \
--ctx-size 32768 \
--cache-type-k q8_0 \
--cache-type-v q8_0이 설정은 FP16보다 메모리를 덜 쓰게 해 줍니다.8 더 강하게 줄이고 싶다면 q4_0 같은 선택도 가능하지만, 긴 컨텍스트에서 품질 저하가 보일 수 있으므로 실제 작업으로 꼭 시험해야 합니다.68
실전에서는 이런 순서가 좋습니다.
먼저
--ctx-size를 현실적으로 줄입니다.그래도 메모리가 부족하면
q8_0KV 캐시를 시도합니다.더 줄여야 할 때만
q4_0계열을 পরীক্ষা합니다.긴 컨텍스트에서 품질 저하가 없는지 실제 업무 프롬프트로 확인합니다.
연구 쪽에서는 KV 캐시를 더 공격적으로 압축하는 기법도 발전하고 있습니다. 예를 들어 KVQuant는 저비트 KV 캐시 양자화로 긴 컨텍스트에서 메모리 사용을 줄이면서 정확도 저하를 최소화하는 방향을 보여줍니다.10 다만 초보자가 당장 실무에서 바로 쓰기에는 연구 성격이 강하므로, 현재는 llama.cpp의 기본 KV 캐시 타입 설정을 이해하는 것이 먼저입니다.
Step 9. 토큰 생성은 한 글자씩 쓰는 것이 아니라, 한 토큰씩 고르는 과정이다
이제 "답변이 만들어지는 순간"을 더 가까이 보겠습니다. 모델은 문장을 통째로 한 번에 쓰지 않습니다. 현재까지 입력된 토큰들을 보고, 다음에 올 수 있는 토큰 후보들의 점수, 즉 로짓(logits)을 계산합니다. 그다음 샘플링 규칙을 적용해 하나를 선택합니다. 그리고 그 토큰을 문장 뒤에 붙이고, 다시 같은 과정을 반복합니다.3
이 구조 때문에 두 가지 사실이 생깁니다.
첫째, 시작이 중요합니다. 초반 몇 토큰이 잘못 뽑히면 그 뒤의 문맥도 함께 기울어집니다. 그래서 템플릿과 시스템 프롬프트가 특히 중요합니다.
둘째, 생성 파라미터가 결과에 직접 영향을 줍니다. 온도(temperature), top-k, top-p, 반복 패널티 같은 설정이 다음 토큰 선택 방식에 관여하기 때문입니다.3
예를 들어 기술 문서 요약 같은 작업에서는 너무 높은 temperature가 필요하지 않습니다. 반대로 아이디어 브레인스토밍에서는 조금 더 자유로운 설정이 도움이 될 수 있습니다. 즉, 좋은 답변은 모델 크기만으로 결정되지 않고 프롬프트 + 컨텍스트 + 샘플링의 합으로 결정됩니다.
Step 10. 프롬프트 품질을 올리는 가장 쉬운 구조
초보자가 바로 써먹기 좋은 방식은 "역할 + 작업 + 입력 자료 + 출력 형식" 구조입니다.
역할: 당신은 초보자를 돕는 기술 튜터입니다.
작업: 아래 내용을 5문장 이하로 요약하세요.
입력 자료: [문서 본문]
출력 형식: 1) 한 줄 요약 2) 핵심 3개 3) 주의점 1개이 구조가 좋은 이유는 모델이 해야 할 일을 단계별로 분리해서 보기 때문입니다. 특히 llama.cpp 기반의 로컬 모델은 입력 구조가 잘 잡혀 있을수록 결과가 덜 흔들립니다.
반대로 다음과 같은 입력은 품질이 불안정합니다.
이거 읽고 알아서 정리해줘. 너무 길지 않게.사람끼리는 알아들을 수 있어도, 모델에게는 여지가 너무 큽니다. "알아서"는 모델에게 친절한 말이 아닙니다.
Step 11. llama.cpp에서 바로 적용하는 실전 패턴
이제 실제 명령 수준에서 품질을 올리는 패턴을 정리해 보겠습니다.
패턴 A. 채팅 모델은 채팅 형식으로 넣기
가능하면 llama-server나 채팅 지원 API를 사용하고, 모델 메타데이터의 템플릿을 활용하세요.12 직접 프롬프트 문자열을 조립할 때는 해당 모델이 기대하는 형식을 따라야 합니다.
패턴 B. 시스템 프롬프트는 짧고 강하게 쓰기
역할, 대상, 출력 형식 정도만 넣고 길게 늘이지 마세요. 긴 규칙집보다 짧은 운영 원칙이 효과적입니다.
패턴 C. 컨텍스트는 필요한 만큼만 쓰기
대화형 비서라면 4K~8K부터 시작해도 충분합니다. 처음부터 32K를 주는 습관은 버리는 편이 좋습니다.6
패턴 D. 메모리 부족 시 KV 캐시부터 의심하기
모델 자체보다 긴 컨텍스트 때문에 메모리가 터지는 경우가 많습니다. --ctx-size를 낮추고, 필요하면 --cache-type-k, --cache-type-v를 조정하세요.8
패턴 E. 반복되는 큰 접두사는 캐싱 효과를 노리기
긴 시스템 프롬프트나 공통 접두사가 계속 반복되는 서버형 환경이라면 llama-server의 host-memory prompt caching 기능을 활용해 TTFT를 크게 줄일 수 있습니다. --cram, --np, --system-prompt-file 같은 옵션으로 공통 프롬프트를 RAM에 캐싱해 재사용하는 방식입니다.11
이 패턴은 특히 사내 챗봇처럼 "큰 규칙집 + 여러 사용자 요청" 구조에서 효과적입니다. 품질 자체를 올리는 기능은 아니지만, 공통 프롬프트를 안정적으로 재사용하면서 첫 토큰까지 걸리는 시간을 줄여 체감 사용성을 높여 줍니다.11
Step 12. 자주 하는 실수 5가지
처음 실습할 때 흔한 실수를 정리해 보겠습니다.
첫 번째는 템플릿을 무시하는 것입니다. Instruct 모델인데도 그냥 평문 completion처럼 넣으면 답변 형식이 깨질 수 있습니다.15
두 번째는 시스템 프롬프트를 너무 길게 쓰는 것입니다. 규칙이 많을수록 좋아 보이지만, 실제로는 중요한 규칙이 묻히고 컨텍스트만 낭비하기 쉽습니다.
세 번째는 컨텍스트를 과하게 크게 잡는 것입니다. "지원 가능"과 "내 장비에서 실용적"은 다릅니다.67
네 번째는 모델 파일 크기만 보고 메모리를 계산하는 것입니다. 긴 대화에서는 KV 캐시가 메모리 사용량의 주범이 될 수 있습니다.679
다섯 번째는 생성 품질 문제를 모두 모델 탓으로 돌리는 것입니다. 사실은 입력 구조와 샘플링 설정 문제가 더 큰 경우가 많습니다.3
Step 13. 따라 해보는 품질 개선 미니 실습
이제 아주 짧은 실습을 해 봅시다. 목표는 같은 모델로 입력만 바꿨을 때 차이를 직접 보는 것입니다.
실습 1: 시스템 프롬프트 유무 비교
먼저 시스템 프롬프트 없이 질문합니다.
KV 캐시를 설명해줘.그다음 시스템 프롬프트를 추가합니다.
당신은 초보 개발자를 돕는 한국어 기술 튜터입니다.
어려운 용어는 쉬운 비유로 설명하세요.
답변은 1) 개념 2) 왜 필요한지 3) 메모리와의 관계 순서로 작성하세요.그리고 같은 질문을 다시 넣어 봅니다.
KV 캐시를 설명해줘.보통 두 번째가 훨씬 읽기 쉽고 구조가 분명할 것입니다.
실습 2: 모호한 질문 vs 구조화된 질문
먼저 모호하게 묻습니다.
이 설정 왜 느려?그다음 구조화해서 묻습니다.
llama.cpp에서 8B 모델을 Q4_K_M으로 실행 중입니다.
ctx-size는 32768이고, GPU VRAM은 8GB입니다.
답변이 느린 이유를
1) 모델 크기 2) 컨텍스트 길이 3) KV 캐시 관점으로 나눠 설명해줘.작은 모델일수록 두 번째 입력에서 차이가 더 크게 납니다.
실습 3: 컨텍스트 길이 조절
같은 모델로 -c 4096과 -c 32768을 각각 써 보고, 메모리 사용량과 응답 속도를 비교해 보세요. 긴 컨텍스트가 항상 좋은 것이 아니라는 점이 체감될 것입니다.68
Step 14. 품질과 안정성을 위한 권장 기본값
모든 환경에 정답은 없지만, 초보자용 출발점은 제시할 수 있습니다.
일반적인 한국어 채팅이나 질의응답이라면 4K~8K 컨텍스트에서 시작하세요. 시스템 프롬프트는 5줄 안팎으로 유지하고, 사용자 프롬프트는 목적과 출력 형식을 분명히 적습니다. 메모리가 빠듯하면 KV 캐시를 q8_0으로 시험해 보고, 정말 필요할 때만 더 낮은 비트로 내립니다.68
서버를 돌릴 때 공통 시스템 프롬프트가 길다면, 프롬프트 캐싱 옵션도 고려할 만합니다.11 그리고 템플릿 문제가 의심되면 자동 감지에만 맡기지 말고 --chat-template로 직접 고정해 보는 습관을 들이세요.1
마무리: 모델 성능보다 입력 설계가 먼저다
이 장에서 꼭 가져가야 할 메시지는 단순합니다. 같은 모델이라도 어떻게 입력하느냐에 따라 체감 성능은 크게 달라진다는 것입니다.
채팅 템플릿은 모델이 대화를 읽는 문법입니다. 시스템 프롬프트는 모델의 작업 모드입니다. 컨텍스트 길이는 작업 책상 크기입니다. KV 캐시는 그 책상 위에 계속 쌓이는 메모장입니다. 그리고 토큰 생성은 매 순간 다음 조각을 하나씩 고르는 과정입니다.136
이제부터 로컬 LLM이 이상하게 답할 때는 이렇게 순서대로 점검해 보세요. 템플릿이 맞는가, 시스템 프롬프트가 지나치게 길지 않은가, 컨텍스트가 과한가, KV 캐시 때문에 메모리가 눌리고 있지 않은가. 이 네 가지만 확인해도 품질 문제의 절반은 방향이 보입니다.
다음 장에서는 여기서 한 발 더 나아가, 실제로 느림, 메모리 부족, 발열 같은 문제를 어떻게 최적화하는지 실전 관점에서 다뤄보겠습니다.
참고
1Templates supported by llama_chat_apply_template · ggml-org/llama.cpp Wiki · GitHub
2Getting Started - llama-cpp-python
3Token Sampling and Generation ggml-org/llama.cpp DeepWiki
4Chat Templates and Tool Calling qualcomm/llama.cpp DeepWiki
5Chat Templates and Conversation System jina-ai/llama.cpp DeepWiki
6KV Cache: Why Context Length Eats Your VRAM (And How to Fix It)
7KV cache is what makes long-context inference expensive.
8llama-cli(1) — llama.cpp-tools — Debian experimental — Debian Manpages
10KVQuant: Towards 10 Million Context Length LLM Inference with KV Cache Quantization
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.