3줄 요약
- 대상: 로컬 LLM + Home Assistant 통합 #3: N100 GPU 가속과 듀얼 Ollama 운영 내용을 빠르게 파악하려는 독자
- 핵심: 설치·설정·운영 포인트를 핵심 단계 중심으로 정리
- 결과: 재현 가능한 절차와 점검 기준으로 시행착오를 줄임
트러블슈팅
- 증상이 나오면 로그·버전·포트/권한·네트워크 순서로 확인합니다.
- 설정 반영이 안 되면 서비스 재시작/캐시 비우기 후 다시 검증합니다.
결론 + 다음 단계
핵심 절차를 먼저 완료하고, 운영 단계에서는 백업·모니터링·기본 보안 설정을 함께 적용하세요.
3줄 요약
- 대상: 로컬 LLM + Home Assistant 통합 #3: N100 GPU 가속과 듀얼 Ollama 운영 내용을 빠르게 파악하려는 독자
- 핵심: 설치·설정·운영 포인트를 핵심 단계 중심으로 정리
- 결과: 재현 가능한 절차와 점검 기준으로 시행착오를 줄임
트러블슈팅
- 증상이 나오면 로그·버전·포트/권한·네트워크 순서로 확인합니다.
- 설정 반영이 안 되면 서비스 재시작/캐시 비우기 후 다시 검증합니다.
결론 + 다음 단계
핵심 절차를 먼저 완료하고, 운영 단계에서는 백업·모니터링·기본 보안 설정을 함께 적용하세요.
요약: 이 글은 “로컬 LLM + Home Assistant 통합 #3: N100 GPU 가속과 듀얼 Ollama 운영” 주제의 핵심 개념과 실제 적용 절차를 빠르게 정리합니다.
트러블슈팅: 트러블슈팅: 설정이 적용되지 않거나 접속/권한 오류가 나면 “로그 확인 → 네트워크/포트 → 권한/경로” 순서로 점검하세요.
결론/다음 단계: 결론/다음 단계: 동작 확인 후 운영 루틴(백업·업데이트·모니터링)을 추가하고, 관련 가이드도 함께 적용해 완성도를 올리세요.
함께 보면 좋은 글
이 글은 N100 환경에서 로컬 LLM(Ollama)을 Home Assistant와 함께 운영할 때, GPU 가속/듀얼 Ollama 같은 고급 구성을 안정화하는 방법을 정리한다. 핵심은 ‘설치’보다 리소스 설계(메모리/스왑) + 안정성(재시작/모델 관리)을 먼저 잡는 것이다.
이 글의 목표(성공 기준)
- Ollama가 안정적으로 실행되고, Home Assistant에서 응답이 일관되게 나온다.
- GPU 가속(가능한 환경) 또는 성능 최적화 포인트가 정리된다.
- 문제 발생 시(느림/메모리 부족/모델 충돌) 점검 순서가 정리되어 있다.
0. 로컬 LLM 홈어시스턴트 구축의 험난한 여정 세번 째
지난번 Proxmox LXC에 Ollama를 올리고 N100 iGPU 패스스루를 마쳤다. (이전 글) 이때만 해도 내 스마트홈은 이미 로컬 LLM 홈어시스턴트를 갖춘 자비스(Jarvis) 급 지능을 갖춘 줄 알았다. 하지만 인간의 욕심은 끝이 없고, 같은 실수를 반복한다고 했던가. “어차피 클라우드 모델 쓰면 되는 거 아냐?”라며 안일하게 생각했던 과거의 나를 반성하며, 이번 삽질기를 기록해본다.
1. 깨달음: 내 GPU는 놀고 있었다
사건의 발단은 단순했다. 분명 GPU 패스스루를 끝냈는데, 막상 모델을 돌려보니 CPU 점유율만 100%를 찍고 서버가 비명을 지르고 있었다. “아니, GPU가 있는데 왜 일을 안 하니?”
알고 보니 일반적인 Ollama 설치 방식(공식 스크립트)으로는 인텔 내장 그래픽(iGPU)의 성능을 1%도 쓰지 못하고 있었다. 마치 페라리를 사놓고 아파트 단지 내에서만 1단 기어로 주행하며 엔진 열만 내고 있는 꼴이었다. N100의 iGPU를 제대로 갈구기(?) 위해서는 인텔 전용 최적화 엔진이 필수였다.
2. Intel GPU의 구원자, IPEX-LLM
여기서 등장하는 구세주가 바로 IPEX-LLM이다.
**IPEX-LLM (Intel Extension for PyTorch)**이란?
인텔에서 제공하는 오픈소스 라이브러리로, 인텔 CPU 및 GPU(iGPU, Arc 등)에서 거대 언어 모델을 극도로 최적화하여 실행할 수 있게 해준다.
쉽게 말해, 인텔 하드웨어의 ‘사용 설명서’를 Ollama에게 제대로 알려주는 역할을 한다. 이걸 설치해야 비로소 N100의 GPU 코어들이 눈을 뜨고 연산을 시작한다.
3. 본격 삽질: GPU 가속의 심폐소생술
기존의 꼬인 설정들을 과감히 밀어버렸다. root 권한의 권력을 휘두르며 rm -rf를 날릴 때의 쾌감이란! (물론 식은땀도 좀 났다.)
작업: Intel GPU 전용 Ollama 설치
패키지 매니저가 해주는 편안한 삶은 포기했다. 직접 바이너리를 옮기고 라이브러리 경로를 잡아주는 노가다를 시작했다.
Bash
# 1. 기존 서비스 중지 및 바이너리 경로 생성
systemctl stop ollama
mkdir -p /usr/local/lib/ollama/bin
mkdir -p /usr/local/lib/ollama/lib
# 2. IPEX-LLM 바이너리 및 라이브러리 복사 (압축 해제 폴더 기준)
cd /root/intel-ollama/ollama-ipex-llm-2.2.0-ubuntu/
cp ollama ollama-bin /usr/local/lib/ollama/bin/
cp -r ollama-lib /usr/local/lib/ollama/bin/
cp *.so* /usr/local/lib/ollama/lib/
# 3. 실행 권한 부여 및 심볼릭 링크 생성
chmod +x /usr/local/lib/ollama/bin/ollama
chmod +x /usr/local/lib/ollama/bin/ollama-bin
ln -sf /usr/local/lib/ollama/bin/ollama /usr/local/bin/ollama
그리고 서비스 파일(/etc/systemd/system/ollama.service)을 만들어 GPU가 일할 수 있는 환경 변수들을 주입했다. 그런데 이건 꼭 안해도 되는 것 같다. 그냥 해보고 안되면 그 때 해도 늦지 않다.
Ini, TOML
[Service]
ExecStart=/usr/local/bin/ollama serve
User=root
Group=root
Restart=always
Environment="SYCL_PI_LEVEL_ZERO_USE_IMMEDIATE_COMMANDLISTS=1"
Environment="ONEAPI_DEVICE_SELECTOR=level_zero:0"
Environment="LD_LIBRARY_PATH=/usr/local/lib/ollama/lib"
Environment="OLLAMA_HOST=0.0.0.0:11434"
결과는 성공적이었다. journalctl -u ollama -f 로그에 **found 1 SYCL devices**라는 문구가 떴을 때, 마치 잃어버린 자식을 찾은 기분이었다.
4. 첫 로컬 테스트: 0.5B의 기적과 초경량 모델들
GPU 가속의 맛을 보기 위해 가장 먼저 선택한 것은 Qwen2.5-0.5B였다. 7B 모델만 보다가 0.5B를 보니 “이게 똑똑하겠어?” 싶었지만, 엔터를 치는 순간 답변이 폭포수처럼 쏟아졌다. 속도가 내가 생각하는 속도보다 빨랐다.
N100 iGPU 추천 가성비 모델 비교
| 모델명 | 파라미터 | 용량 | N100 체감 속도 | 특징 |
| Qwen2.5:0.5b | 5억 개 | ~390MB | 광속 | 매우 빠름, 간단한 HA 명령용 최강 |
| Llama3.2:1b | 10억 개 | ~700MB | 매우 빠름 | 메타의 깔끔한 문장력 |
| Qwen2.5:1.5b | 15억 개 | ~1.1GB | 빠름 | 한국어 이해도와 속도의 최고 접점 |
실행 커맨드:
Bash
# Qwen 0.5B 실행
ollama run qwen2.5:0.5b
# Llama 3.2 1B 실행
ollama run llama3.2:1b
5. 두 번째 벽: “Kimi야, 왜 응답이 없니?”
로컬 모델의 속도에 감탄하던 것도 잠시, 복잡한 질문을 던지자 0.5B 모델은 헛소리를 하기 시작했다. “아, 역시 언어 이해력은 클라우드 모델이지!”라며 최신 기능을 맛보고자 kimi-k2.5:cloud를 당겨보려 했다.
하지만 돌아오는 건 **”The model requires a newer version of Ollama”**라는 차가운 에러 메시지.
인텔 GPU 최적화 버전은 안정성을 위해 본진(Upstream)보다 엔진 버전이 조금 낮게 유지되는데, 최신 모델들은 더 높은 버전을 요구하는 딜레마에 빠진 것이다. 인텔 버전을 업데이트하자니 GPU 가속이 깨질 것 같고, 안 하자니 최신 모델을 못 쓰는 진퇴양난의 상황!
6. 하이브리드 전략: 하나의 CT, 두 개의 뇌 (Dual Ollama)
“그렇다면 둘 다 깔면 되지 않을까?”라는 무모하지만 합리적인 생각이 머리를 스쳤다. 하나는 GPU 전용으로, 하나는 최신 기능을 지원하는 CPU 전용으로 분리하는 것이다.
CPU 전용 최신 Ollama 설치
Bash
# 공식 최신 바이너리 추출 (기존 GPU용과 안 겹치게 이름 변경)
curl -L https://ollama.com/download/ollama-linux-amd64.tar.zst -o ollama.tar.zst
apt install -y zstd
tar --zstd -xf ollama.tar.zst
cp bin/ollama /usr/bin/ollama-cpu
chmod +x /usr/bin/ollama-cpu
포트 분리 설정 (/etc/systemd/system/ollama-cpu.service)
서로 다른 포트(11434 vs 11435)와 모델 경로를 지정해 평화협정을 맺어주었다.
Bash
cat <<EOF > /etc/systemd/system/ollama-cpu.service
[Unit]
Description=Ollama CPU Only (Latest)
After=network-online.target
[Service]
ExecStart=/usr/bin/ollama-cpu serve
Environment="OLLAMA_HOST=0.0.0.0:11435"
Environment="OLLAMA_MODELS=/root/.ollama/models_cpu"
Environment="CUDA_VISIBLE_DEVICES=-1"
Restart=always
EOF
systemctl daemon-reload
systemctl enable --now ollama-cpu
7. 실전 활용: 구분해서 사용하기
이제 터미널에서 헷갈리지 않게 .bashrc에 별칭(Alias)을 설정해주었다.
Bash
# 별칭 등록
echo 'alias ollama-gpu="OLLAMA_HOST=127.0.0.1:11434 /usr/local/bin/ollama"' >> ~/.bashrc
echo 'alias ollama-cpu="OLLAMA_HOST=127.0.0.1:11435 /usr/bin/ollama-cpu"' >> ~/.bashrc
source ~/.bashrc
이제 내 LXC 컨테이너는 하이브리드 AI 기지가 되었다. 아주 간단한 hearbeat check이나 단순 계산 같은 작업들은 로컬 모델을 쓰고 대화형 작업이 필요할 때는 클라우드 모델을 쓰면 된다.
- 속도가 필요할 때:
ollama-gpu run qwen2.5:1.5b - 최신 클라우드 모델이 필요할 때:
ollama-cpu run kimi-k2.5:cloud
맺으며: 이제 제어할 시간이다
인텔 iGPU의 봉인을 해제하고 듀얼 Ollama 시스템까지 구축하니, 드디어 ‘로컬 LLM 홈어시스턴트’의 하드웨어적 완성 단계에 도달했다. 이제 깡통 같았던 내 Home Assistant에 이 강력한 두 개의 뇌를 이식할 차례다.
다음 글에서는 [로컬 LLM 홈어시스턴트 통합 프로젝트 #4] Home Assistant에서 Ollama 연동해서 우리 집 제어하기 편으로 돌아오겠다. 언젠가는 로컬 LLM을 완전히 연동한 에이전틱 AI를 완성하는 그날까지 멈추지 않겠다.
로컬 LLM 홈어시스턴트 실전 적용 체크리스트
이 글의 핵심은 로컬 LLM 홈어시스턴트를 한 번에 완성하려 하지 않고, 작은 단위로 검증하면서 안정적으로 운영하는 데 있습니다. 아래 체크리스트는 실제 운영 과정에서 실패 확률을 줄이기 위한 순서입니다.
- 설치 전 현재 환경(버전, 포트, 저장소, 백업 정책)을 먼저 기록합니다.
- 변경은 한 번에 하나씩 적용하고, 적용 직후 로그와 동작 결과를 확인합니다.
- 장애 대비를 위해 복구 절차를 문서화하고 실제로 한 번 복원 테스트를 진행합니다.
- 운영 중에는 주간 점검 항목(리소스, 오류 로그, 업데이트)을 정해 반복 점검합니다.
로컬 LLM 홈어시스턴트 관련 자주 묻는 질문
처음 시작할 때 가장 먼저 점검할 것은 무엇인가요?
네트워크 연결, 스토리지 여유 공간, 그리고 롤백 가능한 백업 상태를 먼저 확인하는 것이 가장 안전합니다. 이 세 가지가 준비되면 이후 설정 변경 과정에서 복구 시간을 크게 줄일 수 있습니다.
성능과 안정성을 함께 잡으려면 어떻게 해야 하나요?
단기 성능 최적화보다 지속 가능한 운영을 우선하세요. 모니터링 지표를 정하고, 변경 전후를 비교해 개선 여부를 확인하면 로컬 LLM 홈어시스턴트 환경을 장기적으로 안정화할 수 있습니다.
참고 자료
공식 문서도 함께 확인하면 시행착오를 줄일 수 있습니다. OpenClaw Documentation / Proxmox VE 공식 안내
운영 메모: 는 설치 자체보다 운영 루틴이 더 중요합니다. 변경 전에는 백업 상태를 먼저 확인하고, 변경 후에는 로그와 리소스 사용량을 즉시 점검하세요. 특히 환경에서는 작은 설정 변경도 체감 성능에 영향을 주므로, 검증 가능한 체크리스트를 기준으로 단계별로 진행하는 것이 안정적입니다.