로컬 실행은 위치에 관한 말이다
Ollama는 지원하는 모델을 가져와 실행하고 API로 요청할 수 있게 하는 도구다. 로컬 모델이라는 말은 이번 응용에서 어디서 추론하느냐를 가리키며 로봇 환경을 자동 이해하거나 제어 기한을 보장한다는 뜻이 아니다. 모델의 입력 모달리티/도구 호출·출력 형식 지원과 실행 설정은 모델/런타임 버전별로 확인한다. 텍스트 모델에 영상을 보냈다고 VLM이 되는 것도 아니다.
작성 환경에서는 Ollama client 0.20.6이 존재했지만 실행 중 인스턴스에 연결되지 않았다. 버전 확인만 했고 서버/모델을 시작하거나 다운로드하지 않았다. 아래 값은 모델 실행에서 얻은 성능이 아니라 교육용 입력이다. 실제 환경이 없어도 자료 분석으로 학습 목표를 완료할 수 있다.
Ollama 공식 Modelfile은 기반 모델 FROM, 실행 PARAMETER와 prompt의 SYSTEM/TEMPLATE 등을 구분한다. 시스템 문구를 바꾸거나 context/temperature를 설정하는 것은 추론 계약의 변경이지 가중치를 학습한 파인튜닝이 아니다. '항상 올바르게 실행하라'라는 문구가 M22.02의 스키마/현재 상태 검증을 대체하지 않는다.
모델 가져오기와 학습도 다른 단계다
파인튜닝은 과업 자료와 손실로 모델 파라미터를 조정하는 학습이다. LoRA는 원래 가중치를 고정하고 저랭크 행렬로 변화량을 학습하는 대표 접근이다. LoRA 원논문의 아이디어처럼 전체 행렬보다 적은 수의 학습 파라미터를 쓸 수 있지만, 기본 모델의 가중치/실행 메모리가 필요 없어지는 것은 아니다.
한 정방 가중치 W가 4096×4096이라면 원소는 16,777,216개다. rank r=8의 두 행렬 A(8×4096)/B(4096×8)로 변화량을 표현하면 8×4096+4096×8=65,536개의 학습 원소다. 이는 해당 한 행렬 원소 수의 약 0.390625%이며 전체 모델의 실제 학습 파라미터 비율/메모리 절감을 측정한 값은 아니다. 적용 layer/분류 head와 optimizer·activation 등도 고려해야 한다.
학습된 가중치를 실행 형식으로 변환/가져오는 작업은 학습을 다시 수행하는 것과 다르다. 현재 Ollama import 문서는 지원 구조의 Safetensors/GGUF 모델 가져오기를 설명한다. 모든 모델/adapter가 그대로 호환된다고 가정하지 않고 기본 모델 revision·tokenizer/template, 구조·변환/양자화 방식과 실행 버전을 확인한다. 기본 모델이 다른 LoRA 변화량을 파일 이름만 같게 해서 붙이지 않는다.
학습 데이터/분할·라벨/평가와 모델/전처리 버전을 보존하고, 가져온 뒤에도 같은 입력/출력의 회귀 검사를 수행한다. Modelfile에 license 문구를 적는 것만으로 원 모델/데이터의 사용 조건이 새로 생기는 것은 아니므로 해당 배포 자료의 조건을 별도로 확인한다. 이 단위는 특정 모델 구매/선택이나 학습/배포 명령을 수행하지 않는다.
가중치 파일은 전체 메모리의 일부다
양자화는 파라미터/연산의 수치 표현을 더 낮은 정밀도로 바꾸는 처리다. N개 파라미터를 b bit로만 저장한다고 이상화하면 가중치 payload는 N×b/8 byte다. 합성 N=3,000,000,000/b=4라면 1,500,000,000 byte=1.5 GB다. 여기서 GB는 10⁹ byte이며 GiB는 2³⁰ byte라 같은 크기가 약 1.397 GiB다.
실제 양자화 형식은 block별 scale/metadata와 다른 정밀도 성분을 포함할 수 있어 '4bit'라는 이름에서 정확한 파일/메모리 크기를 확정하지 않는다. 런타임 버퍼/활성값, KV cache와 입력/출력·복수 요청, 다른 프로그램도 메모리를 쓴다. CPU/RAM과 GPU/VRAM이 나뉜 시스템은 각 영역/전송 비용도 따로 본다.
합성 예에서 같은 메모리 영역에 가중치 1.5 GB/KV=0.8 GB/기타 실행 버퍼 0.7 GB가 들어가면 합 3.0 GB다. 실제 가용 4.0 GB에서 여유 0.8 GB를 남기려면 허용 사용은 3.2 GB로 계산상 0.2 GB가 남는다. 이 수치는 정해진 항목의 예산일 뿐 peak/동시 요청·메모리 단편화와 다른 비용을 측정한 것이 아니다. 실제로 올라간다고 승인하려면 해당 입력/context·장치에서 peak를 확인해야 한다.
context를 늘리면 cache도 함께 검토한다
KV cache는 attention에서 이전 토큰의 key/value를 저장해 새 토큰 생성 때 재사용하는 자료다. Transformers 공식 설명은 layer별 cache와 token 길이/차원을 다룬다. Ollama context 자료도 더 긴 context의 메모리 비용을 설명한다. 대화 기록을 길게 붙이면 비용/지연과 유효 정보의 범위를 다시 평가한다.
한 요청·단순 dense cache의 근사 크기를 2×L×T×h_kv×d×s byte로 두자. 2는 key/value 두 개, L은 layer 수, T는 보관 토큰 수, h_kv는 key/value head 수, d는 head당 성분 수, s는 성분당 byte다. 실제 구조/양자화·sliding cache나 복수 요청에서는 다른 항목을 확인해야 한다.
독립적인 작은 예 L=4/T=128/h_kv=2/d=16/s=2이면 2×4×128×2×16×2=65,536 byte=64 KiB다. KiB는 1024 byte다. 같은 가정에서 T=256이면 128 KiB로 두 배다. 앞의 3B 모델 KV=0.8 GB를 이 작은 구조에서 계산했다는 뜻은 아니고 두 예는 별도 입력이다. 가중치 양자화와 KV dtype도 자동으로 같다고 가정하지 않는다.
token/s는 전체 응답 지연이 아니다
Ollama generate API는 생성 token 수와 생성/전체·로딩/프롬프트 평가 duration을 제공하며 duration 단위는 ns다. 실제 응답 형식/streaming과 지원 옵션을 버전별로 확인한다. 이 단위에서는 다음을 합성으로 준다: eval_count=20/eval_duration=2,000,000,000 ns/total_duration=2,500,000,000 ns.
생성 구간은 2 s로 20/2=10 token/s다. 전체 응답은 2.5 s라 생성 밖의 시간 0.5 s가 포함된다. 첫 요청의 모델 로딩과 이미 올라간 모델의 요청, prompt 길이/동시성·장치/온도에 따라 달라질 수 있다. 생성 rate가 같아도 전체 지연은 같지 않으며 한 번의 평균으로 꼬리 지연/기한을 보장하지 않는다.
응용의 제안 준비 기한이 0.5 s라면 전체 2.5 s는 2.0 s 초과다. streaming으로 일부 글자를 먼저 받았더라도 아직 완성/검증하지 않은 JSON을 동작 명령으로 실행하지 않는다. 느린 언어 계획과 주기적인 로봇 제어를 같은 동기 루프에 묶기보다, 유효한 제안만 adapter에 전달하고 현재 상태/TTL·실행 결과를 관리하는 역할을 나눈다. 로컬이라는 이유만으로 실시간/오프라인 기능 전체가 자동 보장되지는 않는다.
평가에는 모델/런타임·양자화/분포/학습 버전, context/출력 길이·캐시/동시성·peak 메모리와 지연 분포, 구조/의미 오류와 과업 결과를 남긴다. 기존 5.7 LoRA와 기존 6.2 지연/지터 진단에서 학습/실행의 다른 비용을 연결해 보자. 기본 활동은 수치 표만으로 끝난다.