Ollama API 서버를 외부에 열기 전에 반드시 알아야 할 보안 문제

로컬에서 모델을 돌리다 보면 어느 순간 “다른 기기에서도 쓰고 싶다”는 생각이 든다. 스마트폰 앱과 연동하거나, 같은 네트워크의 팀원에게 공유하거나, 클라우드 인스턴스에 Ollama를 올려두고 어디서든 접근하고 싶어지는 것이다. 그때 자연스럽게 찾게 되는 설정이 OLLAMA_HOST=0.0.0.0이다. 바인딩 주소를 바꾸는 것만으로 Ollama가 모든 인터페이스에서 연결을 받아들이게 된다. 그런데 이 한 줄이 생각보다 훨씬 넓은 문을 열어젖힌다. Ollama의 기본 동작은 … 더 읽기

Claude Code에 로컬 LLM을 붙이면 API 비용이 얼마나 줄어드나

Claude Code를 쓰다 보면 어느 순간 청구서가 신경 쓰이기 시작한다. 단순히 파일 내용을 읽어오거나 grep 결과를 정리하는 작업에도 토큰이 꼬박꼬박 빠져나가는 구조이기 때문이다. 그래서 요즘 실무자들 사이에서 자주 나오는 질문이 있다. “서브에이전트 작업 일부를 로컬 LLM으로 돌리면 실제로 얼마나 아낄 수 있을까?” 설정은 생각보다 단순하다 Claude Code는 서브에이전트 호출 시 OpenAI 호환 API 엔드포인트를 지정할 … 더 읽기

Mac Mini와 MacBook을 썬더볼트로 연결해 LLM 분산 추론하기 — 가능한가, 의미 있는가

Mac Mini 두 대, 혹은 Mac Mini와 MacBook을 옆에 나란히 두고 썬더볼트 케이블 하나로 연결한 뒤 70B짜리 거대 모델을 돌릴 수 있다면 — 그리고 그게 실제로 빠르기까지 하다면 — 꽤 매력적인 이야기가 된다. 결론부터 말하면 “가능은 하다”. 그런데 “의미 있는가”는 조금 다른 질문이다. llama.cpp RPC 서버가 만든 가능성 llama.cpp는 꽤 오래전부터 –rpc 플래그를 통해 분산 … 더 읽기

컨텍스트 길이를 늘리면 메모리가 폭발하는 이유 — KV Cache의 구조와 비용

로컬에서 LLM을 직접 돌려본 사람이라면 한 번쯤 당혹스러운 경험을 했을 것이다. 모델 크기는 8B로 동일한데, 컨텍스트 길이를 4K에서 32K로 늘렸을 뿐인데 VRAM이 부족하다는 경고가 뜬다. 혹은 같은 모델인데 설정 하나 바꿨더니 갑자기 스왑 메모리를 15GB 이상 잡아먹기 시작한다. 도대체 컨텍스트 길이와 메모리 사이에 무슨 일이 벌어지고 있는 걸까. 이 현상을 이해하려면 트랜스포머(Transformer) 모델의 핵심인 어텐션(Attention) … 더 읽기

맥북에서 70B를 억지로 돌리는 것과 27B를 쾌적하게 돌리는 것 — 어느 쪽이 실제로 더 나은가

로컬 LLM을 처음 접하는 사람들이 가장 흔히 하는 실수 중 하나는 “더 큰 모델이 무조건 낫다”는 전제로 접근하는 것이다. 70B 파라미터 모델을 맥북에서 돌릴 수 있다는 사실 자체가 일종의 도전 과제처럼 느껴지기도 하고, 벤치마크 수치만 보면 70B가 27B보다 당연히 앞서 보인다. 그런데 실제로 써보면 이야기가 달라지는 경우가 적지 않다. “억지로 돌린다”는 표현이 다소 거칠게 들릴 … 더 읽기

같은 파라미터 수인데 MoE 모델이 더 빠른 이유

Mixtral 8x7B를 처음 접했을 때 많은 사람들이 혼란을 겪는다. “총 47B 파라미터짜리 모델인데 왜 13B 모델 속도로 돌아간다는 거지?” 숫자가 안 맞는 것 같지만, 이게 바로 Mixture of Experts(MoE, 혼합 전문가 방식) 아키텍처의 핵심이다. Dense 모델이 작동하는 방식 일반적인 트랜스포머 기반 언어 모델, 이른바 Dense 모델은 토큰 하나가 들어올 때마다 모든 레이어의 모든 파라미터가 관여한다. … 더 읽기

Q4_K_M vs Q8_0: 로컬 LLM 양자화, 어디서 타협할 것인가

로컬에서 LLM을 돌려본 사람이라면 한 번쯤 파일 목록 앞에서 멈칫한 경험이 있을 것이다. Q4_K_M, Q5_K_S, Q8_0… 이름만 봐서는 무엇이 좋은지 직관적으로 와닿지 않는다. 다운로드 크기를 보면 두 배 가까이 차이가 나고, 그렇다고 무작정 큰 파일을 받자니 VRAM이나 RAM이 버텨줄지 걱정이 앞선다. 결국 품질을 얼마나 포기해야 메모리를 아낄 수 있는지, 그 거래 비율을 이해하는 것이 핵심이다. … 더 읽기

`arch -arm64` 한 줄이 추론 속도를 바꾸는 이유 — Rosetta 함정

맥북에서 Ollama를 설치했는데 생각보다 느리다는 경험이 있다면, 범인은 모델 크기가 아닐 수 있다. 터미널 한 줄로 실행 아키텍처를 확인해보면 의외의 원인이 드러나는 경우가 꽤 있다. Rosetta가 하는 일과 하지 못하는 일 애플이 인텔에서 자체 실리콘으로 전환할 때 만든 Rosetta 2는 x86_64(인텔) 바이너리를 arm64(애플 실리콘) 환경에서 실행할 수 있게 해주는 동적 번역 레이어다. 처음 실행할 때 … 더 읽기

Ollama와 llama.cpp, 같은 엔진인데 왜 속도가 다를까

로컬 LLM을 써본 사람이라면 한 번쯤 이런 의문을 품는다. Ollama가 내부적으로 llama.cpp를 쓴다고 하는데, 왜 직접 llama.cpp를 빌드해서 실행하면 더 빠른 경우가 생기는 걸까. 같은 엔진 위에서 돌아가는 거라면 결과도 같아야 하지 않나. 사실 Ollama는 llama.cpp를 그대로 가져다 쓰지 않는다. 정확하게는 llama.cpp의 C++ 코어를 Go로 작성된 서버 레이어로 감싼 형태다. 사용자가 ollama run 명령을 실행하면 … 더 읽기

MLX가 llama.cpp보다 빠를 때, 그리고 느릴 때 — 조건별로 따져보기

맥에서 로컬 LLM을 돌려본 사람이라면 한 번쯤 이 질문에 부딪혔을 것이다. MLX를 써야 할까, llama.cpp를 써야 할까. 두 런타임 모두 Apple Silicon에서 잘 돌아가고, 커뮤니티도 활발하며, 지원 모델도 점점 겹쳐가고 있다. 그런데 실제로 써보면 상황에 따라 체감 속도 차이가 꽤 크게 날 때가 있다. 단순히 “MLX가 애플 공식이니까 더 빠르다”는 식의 설명은 절반만 맞다. MLX가 … 더 읽기