SSD Nodes Learn Hosting plans →
가이드 Matt Connor작성자 Matt Connor · 업데이트됨 2026-09-12

Ollama Cloud와 로컬 서버 차이점 및 설정 가이드

Ollama Cloud와 로컬 서버는 동일한 API를 사용하지만 데이터 전송 경로와 보안 정책이 다릅니다. 모델 이름 접미사 설정과 자격 증명 저장 위치를 확인하여 로컬 환경과 클라우드 환경의 차이를 명확히 구분하고 안전하게 운영하는 방법을 상세히 안내합니다.

Ollama Cloud의 변경 사항과 유지되는 사항

Ollama Cloud는 사용자의 하드웨어가 아닌 ollama.com에서 모델을 실행합니다. 이때 기존에 사용하던 ollama 명령어와 REST API는 그대로 유지됩니다. 변경되는 사항은 요청할 모델 이름과 자격 증명이 저장되는 위치, 이 두 가지뿐입니다. 애플리케이션의 나머지 부분은 전혀 바뀌지 않습니다.

이러한 편리함은 곧 위험 요소이기도 합니다. 코드상에서 클라우드 모델에 보내는 요청은 로컬 모델에 보내는 요청과 동일하게 보입니다. 따라서 어떤 프롬프트가 직접 제어하는 머신에서 실행되고, 어떤 프롬프트가 외부 기업으로 전송되는지 파악하기 어려울 수 있습니다. 이 가이드는 그 경계를 명확히 하고, 단일 설정값으로 로컬 모델을 대체 수단(fallback)으로 사용하여 어느 환경에서 실행 중인지 결정하는 방법을 설명합니다.

아직 로컬 환경을 구축하지 않았다면, 먼저 직접 VPS에서 Ollama 실행하기를 참조하여 시작하십시오. 아래의 모든 내용은 Linux 서버에서 ollama이 정상적으로 작동하고 있음을 전제로 합니다.

Ollama Cloud에 접근하는 두 가지 방법

호스팅된 모델에 접근하는 경로는 두 가지가 있으며, 서로 호환되지 않습니다. 어떤 경로를 선택하느냐에 따라 자격 증명이 저장되는 위치, 작성해야 하는 모델 이름, 서버에서 패킷 캡처 시 나타나는 내용이 결정됩니다.

첫 번째 경로: 로컬 데몬이 요청을 전달하는 방식. 한 번 로그인한 뒤, 이름이 -cloud로 끝나는 모델을 요청합니다.

ollama signin
ollama pull gpt-oss:120b-cloud
ollama run gpt-oss:120b-cloud

ollama signin는 이 머신을 사용자의 ollama.com 계정과 연결합니다. ollama signout은 연결을 해제합니다. 로그인 후, 애플리케이션은 기존에 사용하던 로컬 포트로 계속 통신합니다.

curl http://localhost:11434/api/chat -d '{
  "model": "gpt-oss:120b-cloud",
  "messages": [{"role": "user", "content": "Why is the sky blue?"}],
  "stream": false
}'

해당 URL을 다시 확인하십시오. localhost라고 되어 있지만, 추론은 그곳에서 발생하지 않습니다. 로컬 데몬이 -cloud 접미사를 인식하여 요청을 ollama.com으로 전달하고, 응답을 스트리밍 방식으로 반환합니다. 이것이 첫 번째 경로의 핵심입니다. 11434 포트의 Ollama API를 이미 가리키고 있는 애플리케이션은 코드 변경이 전혀 필요 없으며, 모델 문자열만 다르게 입력하면 됩니다.

두 번째 경로: 클라이언트가 ollama.com을 직접 호출하는 방식. 이 방식에서는 로컬 데몬이 전혀 관여하지 않습니다. https://ollama.com/settings/keys에서 키를 생성한 뒤, 이를 Bearer 토큰으로 전송하십시오.

export OLLAMA_API_KEY=your_api_key
curl https://ollama.com/api/chat \
  -H "Authorization: Bearer $OLLAMA_API_KEY" \
  -d '{
    "model": "gpt-oss:120b",
    "messages": [{"role": "user", "content": "Why is the sky blue?"}],
    "stream": false
  }'

모델 이름을 확인하십시오. 두 번째 경로에서는 -cloud 접미사가 없는 gpt-oss:120b을 사용합니다. 접미사는 로컬 데몬에게 요청을 상위 서버로 전달하라고 지시하기 위한 것이므로, 첫 번째 경로에서만 사용해야 합니다. https://ollama.com를 호출할 때는 이미 목적지에 도달한 상태이므로, 일반 모델 이름을 작성합니다. 해당 이름들의 공식 목록은 호스트 자체에서 제공합니다.

curl https://ollama.com/api/tags

이 글을 포함하여 기사에 인쇄된 모델 목록을 신뢰하는 대신, 위 명령을 실행하십시오. 카탈로그는 계속 변경되며, api/tags은 항상 최신 상태를 유지합니다.

어떤 클라이언트 호출이 변경되고 어떤 것이 변경되지 않는지

공식 Python 및 JavaScript 라이브러리는 클라이언트를 생성할 때 호스트와 헤더를 인자로 받습니다. 해당 줄 이후의 코드는 차이가 없습니다. 첫 번째 경로에서는 기본값이 로컬 데몬이므로 생성자가 비어 있습니다.

from ollama import Client

client = Client()

messages = [{'role': 'user', 'content': 'Why is the sky blue?'}]

for part in client.chat('gpt-oss:120b-cloud', messages=messages, stream=True):
  print(part['message']['content'], end='', flush=True)

두 번째 경로에서는 생성자에 호스트와 토큰이 포함됩니다.

import os
from ollama import Client

client = Client(
    host="https://ollama.com",
    headers={'Authorization': 'Bearer ' + os.environ.get('OLLAMA_API_KEY')}
)

messages = [{'role': 'user', 'content': 'Why is the sky blue?'}]

for part in client.chat('gpt-oss:120b', messages=messages, stream=True):
  print(part['message']['content'], end='', flush=True)

client.chat() 호출, 스트리밍 루프, 메시지 목록 및 응답 형태는 두 경우 모두 동일합니다. 이것이 바로 호스팅 환경과 자체 호스팅 환경 간의 전환이 코드 재작성이 아닌 설정 변경으로 가능한 이유입니다. OpenAI 호환 인터페이스도 로컬에서 동일하게 동작합니다. OpenAI SDK를 http://localhost:11434/v1/로 지정하고 api_key='ollama'을 전달하십시오. 로컬 서버는 이 값을 요구하지만 실제로는 무시합니다.

자격 증명의 위치와 사용 권한

두 번째 경로에서 자격 증명은 OLLAMA_API_KEY 환경 변수에 저장됩니다. 이 값을 셸 히스토리나 저장소에 남기지 마십시오. systemd 서비스의 경우, Environment= 줄에 명시하거나 root 소유의 600 권한을 가진 환경 파일에 저장해야 합니다.

첫 번째 경로는 사용자들에게 혼란을 주는 부분입니다. 로그인 정보는 사용자가 아닌 데몬에 귀속됩니다. Ollama FAQ는 Linux에서 서비스 ID가 /usr/share/ollama/.ollama/id_ed25519.pub에 위치하며, ollama 서비스 사용자가 이를 소유한다고 명시합니다. 로컬 API에는 요청별 인증 기능이 없으므로, 11434 포트에 접근할 수 있는 모든 호출자는 사용자의 계정 권한을 상속받아 할당량을 소모하게 됩니다. 데몬이 루프백 인터페이스에서만 대기 중일 때는 문제가 되지 않습니다. 하지만 OLLAMA_HOST=0.0.0.0:11434을 설정하여 다른 머신에서 접근하도록 허용하는 순간, 열린 포트는 곧 열린 과금 관계가 됩니다. 이것이 바로 바인드 주소를 확장하기 전에 Ollama 엔드포인트 앞에 인증을 설정하는 방법을 먼저 읽어봐야 하는 이유입니다.

로컬에서 동일한 모델의 컨텍스트가 더 작게 느껴지는 이유

이는 두 경로에서 모델이 동일하게 동작할 것이라고 가정하는 사용자들이 흔히 겪는 차이점입니다. 실제로는 그렇지 않으며, 그 원인은 메모리에 있습니다.

Ollama는 시스템에서 감지된 비디오 메모리를 기반으로 로컬 기본 컨텍스트 길이를 결정합니다.

ChartOllama documented default context length by local VRAM, August 2026
The data behind this chart
[
  {
    "label": "Under 24 GiB VRAM",
    "default_context_tokens": "4,096"
  },
  {
    "label": "24 to 48 GiB VRAM",
    "default_context_tokens": "32,768"
  },
  {
    "label": "48 GiB VRAM or more",
    "default_context_tokens": "262,144"
  }
]

GPU가 없는 VPS는 최하위 계층에 해당하므로, 로컬 모델은 4,096 토큰의 컨텍스트로 시작합니다. 반면 대용량 카드가 장착된 장비는 262,144 토큰으로 시작합니다. 클라우드 모델은 이러한 계층을 무시합니다. Ollama 문서에 따르면 클라우드 모델은 기본적으로 최대 컨텍스트 길이로 설정되는데, 이는 해당 컨텍스트를 유지하는 메모리가 사용자의 자원이 아니기 때문입니다.

따라서 gpt-oss:120b-cloud에서 정상 작동하던 동일한 프롬프트가 사양이 낮은 장비의 로컬 모델에서는 알림 없이 잘릴 수 있습니다. 로컬 컨텍스트 제한을 명시적으로 높이십시오.

OLLAMA_CONTEXT_LENGTH=32768 ollama serve

systemd 환경에서는 systemctl edit ollama.service을 사용하여 Environment="OLLAMA_CONTEXT_LENGTH=32768"으로 설정한 뒤, systemctl daemon-reload && systemctl restart ollama를 수행하십시오. 리소스 사용량에 주의해야 합니다. 컨텍스트가 길어지면 키-값 캐시가 커지며, 이 캐시는 모델 가중치 외에 추가로 필요한 RAM을 점유합니다. 제한을 너무 높게 설정하면 생성 속도가 느려지거나 모델 로드에 실패할 수 있습니다. num_ctx 및 OLLAMA_CONTEXT_LENGTH를 올바르게 설정하는 방법에서 계산법을 다루며, 실제 보유한 메모리에 맞는 모델 확인하기에서 가중치 관련 내용을 다룹니다.

실제로 외부로 전송되는 데이터

이 부분은 독자들이 직접 호스팅을 선택하는 주된 이유이므로 정확하게 이해해야 합니다.

로컬에서 실행할 경우, 아무것도 외부로 나가지 않습니다. Ollama의 개인정보 처리방침은 로컬 사용에 대해 "당사는 귀하의 프롬프트, 응답, 모델 상호작용 또는 로컬에서 처리하는 기타 콘텐츠를 수집, 저장, 전송하거나 이에 접근하지 않습니다"라고 명시하고 있습니다. 한 가지 주의할 점은 모델을 가져오는(pull) 행위는 여전히 ollama.com에서 다운로드하는 것이며, 방침에는 "모델 다운로드 메타데이터"와 귀하의 IP 주소가 수집 항목으로 포함되어 있다는 것입니다. 레지스트리는 귀하가 어떤 모델을 가져갔는지는 알지만, 귀하가 그 모델에 무엇을 물어봤는지는 알지 못합니다.

클라우드 경로로 실행할 경우, 전체 프롬프트와 전체 완성본이 제3자에게 전송됩니다. 여기에는 예외가 없습니다. 귀하가 보내는 모든 토큰과 받는 모든 토큰은 ollama.com에서 처리됩니다. 해당 방침에 따르면 회사는 "서비스 제공을 위해 귀하의 프롬프트와 응답을 일시적으로 처리"하며 "귀하의 입력이나 출력을 AI 모델 학습에 사용하지 않는다"고 밝히고 있으며, "프롬프트 및 응답 콘텐츠의 보관을 최소화하도록 설계된 기술적 조치"를 설명하고 있습니다. 이는 합리적인 약속입니다. 하지만 이는 귀하가 직접 관리하는 인프라의 속성이 아니라, 귀하가 넘겨준 데이터에 대해 타인이 하는 약속일 뿐입니다. 모든 공급업체의 약속을 평가하는 것과 같은 기준으로 판단하십시오. 계약상 또는 법적으로 자체 인프라 내에 보관해야 할 의무가 있는 데이터를 전송하기 전에 해당 방침을 다시 읽어보시기 바랍니다.

함정은 첫 번째 경로에 있습니다. 귀하의 코드는 http://localhost:11434이라고 되어 있고 방화벽 규칙도 변경되지 않았더라도, 모델 이름 뒤에 붙은 -cloud 접미사가 라우팅을 수행하기 때문에 귀하의 프롬프트는 여전히 인터넷을 거치게 됩니다. localhost URL만으로는 추론이 어디에서 발생했는지 알 수 없습니다. 모델 이름이 이를 결정합니다.

로컬 모델을 폴백으로 유지하기

두 경로 모두 동일한 API를 사용하므로, 코드 분기 대신 런타임 설정으로 선택할 수 있습니다.

가장 간단한 방식은 별도의 코드가 필요 없습니다. 애플리케이션이 로컬 데몬을 가리키도록 유지하고 모델 이름을 설정 파일에 넣으십시오. 이를 llama3.2으로 설정하면 로컬 장비에서 실행됩니다. gpt-oss:120b-cloud으로 설정하면 동일한 데몬이 ollama.com으로 요청을 전달합니다. 환경 변수 하나만 바꾸면 되며, 재배포도 필요 없습니다.

로컬 모델을 기본값으로 사용하고 클라우드를 오버플로 처리용으로 쓰려면, 두 클라이언트를 모두 구성하고 요청마다 선택하십시오.

import os
from httpx import ConnectError
from ollama import Client, ResponseError

LOCAL_MODEL = os.environ.get("LOCAL_MODEL", "llama3.2")
CLOUD_MODEL = os.environ.get("CLOUD_MODEL", "gpt-oss:120b")

local = Client(host="http://127.0.0.1:11434")
cloud = Client(
    host="https://ollama.com",
    headers={"Authorization": "Bearer " + os.environ["OLLAMA_API_KEY"]},
)

def chat(messages):
    try:
        return local.chat(LOCAL_MODEL, messages=messages)
    except (ConnectError, ResponseError) as err:
        print(f"local inference failed ({err}); sending this prompt to ollama.com")
        return cloud.chat(CLOUD_MODEL, messages=messages)

httpx은 ollama 패키지의 의존성으로 포함되어 있으므로 추가 설치가 필요 없습니다. ConnectError은 데몬이 중단된 경우를 처리합니다. ResponseError은 데몬이 실행 중이지만 요청을 거부하는 경우(예: 로컬 모델을 내려받지 않은 경우)를 처리합니다.

print 줄은 장식이 아닙니다. 조용한 폴백은 로컬 하드웨어에서 처리하려던 프롬프트가 업그레이드 중 데몬이 재시작되는 첫 순간에 제3자에게 몰래 전송됨을 의미합니다. 모든 폴백을 기록하고, 민감한 작업이라면 폴백 대신 오류를 발생시키십시오. 개인정보 보호가 중요한 배포 환경에서 가장 안전한 폴백 정책은 명확하게 실패를 알리는 것입니다.

로컬 모델을 신뢰할 수 있는 기본값으로 만드는 또 다른 방법은 모델을 상주시키는 것입니다. CPU 전용 VPS에서 콜드 로드는 수십 초가 걸릴 수 있으며, 이것이 바로 사용자들이 클라우드 경로를 선택하게 만드는 주된 이유입니다. keep_alive를 사용하여 모델을 메모리에 유지하기는 이러한 첫 요청 시의 지연 시간을 제거합니다.

커밋 전 비교해야 할 사항

가격만으로 비교하지 마십시오. 이 글을 포함하여 기사에 명시된 가격을 그대로 신뢰해서도 안 됩니다. 다음 네 가지 항목을 비교하고, 각 항목은 벤더의 공식 페이지에서 직접 확인하십시오.

  • 모델 가용성. 현재 호스팅되는 카탈로그를 확인하려면 curl https://ollama.com/api/tags을 실행하십시오. 로컬에서 실행 가능한 모델은 사용자의 RAM 및 VRAM 용량에 따라 제한됩니다.
  • 컨텍스트 제한. 호스팅 모델은 기본적으로 최대치로 설정됩니다. 로컬 모델은 위와 같이 VRAM 등급에 따라 기본값이 결정됩니다. 작업 부하가 긴 문서라면 이 항목이 결정적인 기준이 됩니다.
  • 속도 제한. 호스팅된 추론 서비스는 사용량에 따라 요금이 부과됩니다. 제한을 초과하면 API는 429 Too Many Requests를 반환합니다. 자체 서버에는 속도 제한이 없는 대신 엄격한 동시성 상한선이 존재하며, 이는 다른 유형의 오류이자 종종 더 심각한 문제가 될 수 있습니다.
  • 보존 정책. 실제 정책 문서를 읽고 읽은 날짜를 기록해 두십시오. 갱신하기 전에 다시 확인해야 합니다.

비용 측면에서는 여기서 계산을 다시 수행하지 마십시오. GPU VPS가 토큰당 과금 방식을 앞지르는 시점에서는 손익분기점을 정확하게 분석합니다. 여기에는 사람들이 간과하기 쉬운 부분, 즉 유휴 상태의 GPU 서버도 가동 중인 서버와 동일하게 요금이 청구된다는 사실이 포함되어 있습니다.

여러 공급자 앞에 라우터를 두는 경우는 어떻습니까?

세 번째 선택지는 라우터입니다. 이는 애플리케이션에 하나의 API를 제공하고 요청을 여러 백엔드로 분산하는 프록시입니다. 직접 호스팅하는 LiteLLM 프록시나 OpenRouter와 같은 호스팅 서비스가 이러한 역할을 수행합니다. 이 방식의 장점은 확실합니다. 클라이언트 설정은 하나로 유지하면서 여러 모델을 사용할 수 있고, 특정 공급자에 장애가 발생했을 때 페일오버(failover)를 지원합니다. 이는 앞서 언급한 폴백(fallback) 패턴을 두 개 이상의 백엔드로 확장한 자연스러운 형태입니다. 다만 비용 측면을 명확히 이해해야 합니다. 호스팅된 라우터를 사용하면 귀하의 프롬프트를 볼 수 있는 운영자가 하나 더 늘어나는 셈이므로, 단일 공급자에게 요구했던 데이터 보존 정책에 관한 질문을 이제 두 곳에 해야 합니다. 직접 호스팅하는 라우터는 해당 단계를 귀하의 서버 내에서 처리하지만, 대신 운영, 패치, 모니터링해야 할 서비스가 하나 더 늘어납니다. 라우터는 모델 선택과 가용성 문제를 해결해 줍니다. 하지만 프롬프트가 결국 라우팅된 목적지로 전달되기 때문에 개인정보 보호 문제까지 해결해주지는 않습니다.

실제로 마주하게 될 오류

API는 상태 코드를 문서화하고 있으며, 각 코드는 서로 다른 문제를 가리킵니다. 429 Too Many Requests는 속도 제한에 도달했음을 의미하므로, 루프를 돌며 재연결을 시도하기보다는 잠시 대기한 후 다시 요청해야 합니다. 502 Bad Gateway은 이 주제와 직접적으로 관련된 오류입니다. 클라우드 모델에 도달할 수 없을 때 반환되므로, 첫 번째 경로에서는 데몬은 정상이나 업스트림에 문제가 있음을 뜻합니다. 모델 이름에 대한 404 Not Found은 대개 접미사가 호스트와 일치하지 않거나, -cloud 이름을 https://ollama.com로 직접 보냈거나, 로그인하지 않은 데몬에 이름만 보냈을 때 발생합니다. 오류는 JSON 형태로 전달되며, 스트리밍 도중에는 NDJSON 응답 내에 {"error":"an error was encountered while running the model"}과 같은 줄로 나타납니다. 이것이 단순한 스트리밍 클라이언트가 부분적인 답변만 출력하고 아무런 설명 없이 중단되는 이유입니다. 스트리밍되는 각 줄을 파싱하여 error 키가 있는지 확인하십시오.

로컬 측에서 가장 흔한 오류는 포트 11434에 대한 연결 거부이며, 이는 데몬이 실행 중이지 않음을 의미합니다. systemctl status ollama를 확인하십시오. 또 다른 흔한 사례는 셸에서는 잘 작동하는 요청이 컨테이너에서는 실패하는 경우인데, 이는 컨테이너의 localhost이 호스트의 것과 다르기 때문입니다.

오류 메시지가 전혀 나타나지 않는 실패 유형은 인터넷 연결이 끊긴 경우입니다. 클라우드 경로는 완전히 작동을 멈추지만, 로컬 경로는 이를 감지하지 못합니다. 기기를 외부로 가져가거나 서비스 제공업체에 라우팅 문제가 발생하면, 이러한 차이가 제품 전체의 동작을 결정짓게 됩니다.

각 선택이 올바른 경우

작업량이 불규칙하거나, 모델이 VPS에서 실행하기에 너무 크거나, 특정 모델을 기반으로 개발할 가치가 있는지 결정하는 단계라면 Ollama Cloud를 사용하십시오. 하루에 20분만 작동하는 유휴 GPU 비용을 지불하는 것보다 요청당 비용을 지불하는 것이 경제적이며, 120-billion-parameter 모델은 점심 식사 가격 수준의 서버에는 탑재할 수 없습니다.

프롬프트가 인프라를 벗어나면 안 되거나, 기기가 오프라인 상태에서 작동해야 하거나, 임대한 GPU가 항상 바쁘게 돌아갈 정도로 부하가 일정하다면 직접 실행하십시오. 일정한 부하는 정직한 신호입니다. 종량제 추론은 항상 실행 중일 때 정확히 비용이 많이 발생합니다. 이 단계에 도달하여 Ollama의 단일 요청 처리량이 병목 현상을 일으킨다면, vLLM이 Ollama보다 동시 부하 처리에 더 적합합니다. 이는 호스트를 변경하는 것이 아니라 엔진을 변경하는 것입니다.

대부분의 실제 배포 환경은 결국 두 가지 방식을 모두 사용하게 되며, 분리 기준만 명확하다면 이는 좋은 전략입니다. 설정 파일에 모델 이름을 명시하고 모든 폴백(fallback) 상황을 기록하십시오. 그러면 이 상황에서 유일하게 중요한 질문인 "어떤 프롬프트가 외부로 전송되었는가?"에 항상 답할 수 있을 것입니다.

FAQ

Ollama Cloud가 내 프롬프트를 볼 수 있습니까?

네. 호스팅 경로를 이용하면 전체 프롬프트와 전체 응답이 ollama.com으로 전송되어 처리됩니다. Ollama의 개인정보 처리방침에 따르면 "서비스 제공을 위해 귀하의 프롬프트와 응답을 일시적으로 처리"하며 "귀하의 입력이나 출력을 AI 모델 학습에 사용하지 않는다"고 명시되어 있으며, 데이터 보관을 최소화하기 위한 조치를 설명하고 있습니다. 이는 이미 제공한 데이터에 대한 공급업체의 약속입니다. 로컬 모델의 경우 동일한 방침에서 회사가 "귀하의 프롬프트, 응답, 모델 상호작용 또는 로컬에서 처리하는 기타 콘텐츠를 수집, 저장, 전송하거나 이에 접근하지 않는다"고 명시합니다. 콘텐츠가 인프라 외부로 절대 유출되지 않아야 한다면 로컬 경로만 이를 충족합니다.

모델이 클라우드에서 실행 중인데 왜 내 앱은 여전히 localhost를 가리키나요?

로컬 데몬이 프록시 역할을 하기 때문입니다. ollama signin를 실행한 후 이름이 -cloud로 끝나는 모델을 요청하면, 데몬이 해당 요청을 ollama.com으로 전달하고 응답을 포트 11434를 통해 스트리밍합니다. 애플리케이션 URL은 변경되지 않으며, 이것이 바로 코드 수정이 필요 없는 이유입니다. 또한 이는 localhost 주소가 추론이 어디에서 발생했는지에 대한 정보를 제공하지 않음을 의미합니다. URL이 아닌 모델 이름을 확인하십시오. -cloud 접미사는 프롬프트가 인터넷을 거쳤음을 의미합니다.

왜 동일한 모델이 로컬에서는 훨씬 짧은 컨텍스트를 제공하나요?

Ollama는 사용 가능한 비디오 메모리에 따라 로컬 기본값을 선택합니다. 24 GiB VRAM 미만에서는 약 4k 토큰, 24~48 GiB 사이에서는 32k, 48 GiB 이상에서는 256k입니다. GPU가 없는 VPS는 가장 낮은 단계에 해당합니다. 클라우드 모델은 메모리를 제공자가 보유하고 있으므로 기본적으로 최대 컨텍스트 길이로 설정됩니다. OLLAMA_CONTEXT_LENGTH을 사용하여 로컬 값을 높이십시오. OLLAMA_CONTEXT_LENGTH=32768 ollama serve로 설정하거나 systemctl edit ollama.service 아래에 Environment= 라인으로 추가할 수 있습니다. 컨텍스트가 길어지면 RAM에 더 큰 키-값 캐시가 필요하므로, 작은 서버에서 값을 높이면 생성 속도가 느려지거나 모델 로딩이 중단될 수 있습니다.

클라우드에 연결할 수 없을 때 자동으로 로컬 모델로 전환할 수 있습니까?

네, 가능합니다. 두 경로 모두 동일한 API를 사용하므로 몇 줄의 코드로 구현할 수 있습니다. 두 개의 Client 객체를 생성하십시오. 하나는 로컬 데몬을 위해 host 인자를 비워두고, 다른 하나는 host="https://ollama.com"과 Authorization: Bearer 헤더를 포함합니다. 그런 다음 첫 번째 호출 주변에서 httpx.ConnectError와 ollama.ResponseError을 처리하십시오. 전환 방향은 신중하게 결정해야 합니다. 로컬을 우선하고 클라우드를 대체 수단으로 삼으면, 비공개로 유지하려던 프롬프트가 일상적인 데몬 재시작 중에 외부로 유출될 수 있습니다. 따라서 모든 대체 전환을 기록하고, 민감한 작업의 경우 전환 대신 오류를 발생시키십시오.

#ollama#self-hosting#llm#privacy#gpu