설정¶

Backend.AI GO는 설정을 세 가지 내비게이션 그룹으로 나눕니다.

• 앱
• 에이전트
• 시스템

예전 문서에 보이던 Inference, Network, Storage 같은 이름은 현재 UI와 맞지 않습니다.

현재 설정 탭¶

주요 제어 항목의 현재 위치¶

모델 디렉토리¶

설정 > 모델을 엽니다.

추가 모델 폴더¶

설정 > 모델 > 추가 모델 폴더를 엽니다. 앱은 자체 모델 디렉토리 외에도 LM Studio 라이브러리, Hugging Face 캐시, Ollama 모델 저장소처럼 다른 애플리케이션이 소유한 폴더에서 모델을 읽을 수 있습니다. 폴더 추가로 폴더를 직접 고르거나, 다른 앱의 모델 찾기를 눌러 LM Studio의 기본 위치(~/.lmstudio/models, ~/.cache/lm-studio/models), Hugging Face 캐시(Hugging Face 캐시 참고), Ollama의 기본 위치(Ollama 모델 참고)를 확인하고 한 번의 클릭으로 추가할 수 있습니다.

추가한 폴더의 모델은 다른 모델과 똑같이 목록에 표시되고 불러올 수 있으며, 모델 페이지에는 폴더 이름이 표시됩니다. 폴더 자체는 읽기 전용으로 다룹니다. 앱은 그 폴더에 아무것도 쓰지 않으므로 이 모델들에는 삭제가 제공되지 않고, 여기서 하는 어떤 작업도 다른 애플리케이션이 보는 내용을 바꾸지 않습니다. 이런 모델에 대한 설정(별칭과 실행 구성 포함)은 앱 자체 데이터 디렉토리에 보관되며, 폴더를 제거했다가 다시 추가해도 유지됩니다.

각 폴더는 제거하지 않고 끌 수 있으며, 끄면 다시 켤 때까지 그 폴더의 모델이 숨겨집니다. 경로가 없거나, 연결되지 않은 드라이브에 있거나, 앱이 읽을 수 없는 폴더는 사용 불가로 목록에 남습니다. 사용 불가인 동안 그 폴더의 모델은 숨겨지지만 모델 페이지의 새로 고침을 해도 인덱스에는 유지되며, 폴더를 다시 읽을 수 있게 되면 모델이 다시 나타납니다. 폴더를 제거했다가 같은 키로 다시 추가하면 그 모델에 저장해 둔 설정이 복원됩니다.

폴더는 모델 디렉토리, 다른 추가 폴더, 앱 자체 데이터 디렉토리와 겹칠 수 없고, 파일 시스템 루트, 홈 디렉토리, 홈 디렉토리를 포함하는 폴더(/home 등)도 지정할 수 없습니다. 최대 16개까지 추가할 수 있습니다. 모델 디렉토리에서 추가한 폴더로 이어지는 심볼릭 링크는 따라가지 않으므로, 같은 파일이 두 번 나열되지 않고 링크를 통해 폴더에 쓰는 일도 없습니다.

서버에서는 config.toml에 선언한 폴더가 우선합니다. 설정에 저장된 폴더가 같은 키를 쓰면 저장된 항목은 버려지고 경고가 기록됩니다. 추가 모델 소스를 참고하십시오.

Ollama 모델¶

ollama pull로 받은 모델은 Ollama가 보관하는 위치에서 그대로 읽으며, 복사하거나 변환하지 않습니다. 다른 앱의 모델 찾기는 OLLAMA_MODELS가 가리키는 폴더, ~/.ollama/models(Windows에서는 %USERPROFILE%\.ollama\models), 그리고 Linux에서는 Ollama 서비스 설치가 쓰는 /usr/share/ollama/.ollama/models에서 Ollama 저장소를 찾습니다. 폴더를 직접 추가할 때는 그 models 폴더를 고르면 되는데, 한 단계 위의 .ollama 폴더를 골라도 그 안의 models 폴더가 추가됩니다. 앱은 Ollama의 매니페스트를 읽어 각 모델을 Ollama의 blob 저장소에서 곧바로 llama-server로 불러옵니다. 태그마다 llama3.2:3b나 hf.co/Qwen/Qwen3-0.6B-GGUF:Q8_0처럼 Ollama가 보여 주는 이름으로 나열되므로 같은 가중치를 가리키는 태그 두 개는 항목도 두 개가 되고, 별칭과 실행 설정은 가중치 파일 단위로 보관되기 때문에 두 항목이 함께 씁니다. 다운로드에 프로젝터가 포함된 비전 모델은 프로젝터와 함께 불러오며 이미지를 읽을 수 있는 모델로 표시됩니다.

다운로드가 끝나지 않았거나 가중치가 없는 모델, Ollama가 MLX 엔진용 safetensors 가중치로만 보관한 모델, 기반 모델 위에 얹는 파인튜닝 어댑터(LoRA)는 나열되지 않습니다. 채팅 템플릿은 모델 파일 자체에 들어 있는 것을 쓰는데, Ollama의 템플릿은 Ollama의 Go 템플릿 엔진용이라 쓰지 않으므로 파일에 채팅 템플릿이 없는 모델은 모델 디렉토리에 있을 때와 똑같이 동작합니다.

앱은 저장소 안에서 일반 파일이 아닌 항목, 예를 들어 모델 파일이 있어야 할 자리에 놓인 named pipe나 장치 파일을 기다리지 않고 건너뜁니다. 러너가 여러 개인 매니페스트는 항목을 최대 8개까지만 읽으므로 항목을 부풀린 매니페스트를 끝까지 읽지 않습니다. REST API 로드 요청(POST /models/load)에서 프로젝터(mmprojPath)를 지정하려면 모델 디렉토리나 추가 모델 폴더 안의 파일이어야 하며, 그 밖의 경로는 400 오류로 거부됩니다. 이미 삭제된 프로젝터 파일, 예를 들어 Ollama가 지운 파일은 무시되고 모델은 프로젝터 없이 불러옵니다.

Ollama는 저장소를 스스로 관리합니다. ollama rm을 실행하면 모델 파일을 지우고, 시작할 때 어떤 모델도 참조하지 않는 파일을 정리하며(OLLAMA_NOPRUNE을 설정하지 않은 경우), 거기서 제거된 모델은 다음 스캔 때 이 앱에서도 사라집니다. Windows에서는 이 앱이 불러온 모델의 파일이 열려 있으므로 모델을 내릴 때까지 Ollama가 그 파일을 지울 수 없습니다. Ollama 라이브러리의 일부 모델은 Ollama 엔진은 실행하지만 llama.cpp가 아직 지원하지 않는 아키텍처를 쓰는데, 이런 모델도 나열되며 불러오면 엔진의 로드 오류로 실패합니다.

Hugging Face 캐시¶

huggingface-cli download, huggingface_hub 라이브러리, mlx-lm, llama.cpp -hf로 받은 모델은 Hugging Face 캐시에 보관되는데, 기본 위치는 ~/.cache/huggingface/hub(Windows에서는 %USERPROFILE%\.cache\huggingface\hub)입니다. HF_HUB_CACHE가 설정되어 있으면 그 폴더가 캐시가 되고, HF_HOME이 설정되어 있으면 그 안의 hub 폴더가 캐시가 되며, 다른 앱의 모델 찾기는 이 세 위치를 모두 확인합니다. 캐시를 직접 추가할 때는 models--<org>--<name> 폴더들이 들어 있는 hub 폴더 자체를 고르십시오. 이런 폴더가 하나도 없는 폴더는 비어 있지 않은 한 거부됩니다.

앱은 모델 저장소마다 한 리비전만 읽는데, 저장소의 refs/main에 적힌 리비전을 쓰고 그 파일이 없으면 가장 최근에 수정된 스냅숏을 씁니다. GGUF 파일, 분할된 GGUF 파일, MLX safetensors 저장소는 저장소 이름(ggml-org/Qwen3-0.6B-GGUF) 아래에 Hugging Face 캐시 표시와 함께 나열되고, 복사 없이 캐시에서 바로 불러옵니다. 아직 받는 중이거나 중단된 다운로드는 건너뛰고, 같은 캐시에 있는 데이터셋과 Space는 무시합니다. 다른 추가 폴더와 마찬가지로 앱은 캐시에 아무것도 쓰지 않으므로 캐시 관리는 계속 huggingface-cli가 맡습니다.

refs/main과 snapshots 폴더는 캐시가 일반 항목으로 만든 경우에만 사용합니다. refs 폴더, refs/main 파일, snapshots 폴더가 링크이면 따라가지 않고, 리비전 해시보다 큰 refs/main은 읽지 않으며, 이 경우에는 가장 최근에 수정된 스냅숏을 쓰고 snapshots 폴더가 링크인 저장소는 나열하지 않습니다. hub 폴더로 이어지는 링크를 통해 캐시를 추가했더라도 모델을 불러올 때 목록에 나온 이름이 그대로 유지됩니다. 헤더에서 데이터를 비정상적으로 깊게 중첩한 GGUF 파일은 목록에는 나오지만 상세 정보는 읽지 않으며, 그런 파일 하나 때문에 스캔이 멈추지는 않습니다. 캐시의 디퓨전 모델은 같은 스냅숏 폴더에서 VAE와 텍스트 인코더 같은 보조 파일을 찾습니다.

앱 표면별 기본 모델¶

설정 > 모델을 엽니다.

형식별 기본 엔진¶

설정 > 모델을 엽니다.

기본 추론 노력과 생성 기본값¶

설정 > 생성을 엽니다.

모델의 최대 컨텍스트 사용을 켜면 Backend.AI GO는 모델이 보고한 최대값에서 시작해 자동 컨텍스트 상한을 적용합니다. 실행 메모리 추정치가 사용 가능한 RAM과 VRAM에 맞지 않으면 값을 더 낮출 수 있습니다. 이 추정치는 모델 실행 성공을 보장하지 않습니다. 시스템 메트릭을 사용할 수 없거나 512토큰에서도 모델 추정치가 맞지 않으면 자동 컨텍스트 상한값을 그대로 선택하며, 일반 호환성 검사가 최종 판단을 담당합니다.

실행할 때 명시한 컨텍스트가 가장 먼저 적용됩니다. 모델별 저장 컨텍스트가 두 번째이며, 두 값은 변경하지 않습니다. 두 값이 없으면 제한을 적용한 모델 최대값, 선택한 프리셋, 사용자 지정 기본값 순서로 선택합니다.

MLX 엔진 기본값¶

설정 > 생성을 엽니다.

클러스터에서 실행의 전송 포트 범위¶

설정 > 고급 > 포트 및 네트워킹을 엽니다.

소켓 디렉토리¶

설정 > 고급 > 포트 및 네트워킹을 엽니다. 소켓 디렉토리를 비워 두면 로컬 소켓 위치에서 설명한 사용자별 런타임 디렉토리를 사용합니다. 직접 지정하는 값은 홈 디렉토리 안의 절대 경로여야 하고 62바이트 이하여야 하며(소켓 이름이 103바이트 제한 안에 들어가도록), 다음 실행부터 라우터, 모델 서버, Management API, 모니터에 모두 적용됩니다. 더 긴 경로는 저장 시 바이트 수와 함께 거부됩니다.

이 컴퓨터에서의 모델 속도¶

설정 > 성능을 엽니다. 탭 맨 위에는 이 컴퓨터(칩이나 GPU, 메모리, 가속기)를 보여 주는 카드와, 그 옆에 이 컴퓨터에서 측정한 가장 빠른 로컬 모델과 답변 속도가 나옵니다. 이 탭은 로컬 모델마다 이 컴퓨터에서의 답변 속도와 첫 응답을 보여 주는데, 이 값은 15초 동안 재는 빠른 측정으로 얻고(실행 중이 아닌 모델은 측정하는 동안 실행할지, 다른 실행 중인 모델을 내릴지 그대로 둘지 먼저 묻습니다), 해당 수치가 다음 실행을 더 이상 나타내지 않으면 엔진 바뀜이나 설정 바뀜을 붙여 알려 줍니다. 모델 상세에는 대화에 충분한지에 대한 판정과 측정 당시의 엔진, 설정이 함께 나오고, 이 모델의 기록을 누르면 벤치마크 페이지에서 해당 모델의 기록이 열리죠. 측정 결과 비교와 llama-bench 고급 측정도 해당 페이지에 있습니다. 옵션에서는 모델을 처음 실행할 때의 빠른 측정을 켜거나 끄고(기본값은 꺼짐이라 직접 측정하기 전에는 측정하지 않음), 프로바이더 모델 표시(측정할 때마다 요청 비용이 들어 기본값은 꺼짐)와 기록 보관 기간(기본값 90일, 기준 기록은 남음)을 정합니다.

설정 자동 맞춤(기본값은 꺼짐)을 켜면 컴퓨터를 사용하지 않는 동안 로컬 모델의 설정이 대화에 맞춰집니다. 키보드나 포인터 입력과 라우터를 거친 요청이 10분 동안 없고, 불러오거나 측정 중인 모델이 없으며, 전원에 연결되어 있고, 모델을 실행할 메모리가 남아 있을 때만 시작합니다. Linux에서는 컴퓨터를 사용하지 않은 시간을 GNOME이나 xprintidle로 알아야 해서, 둘 다 없으면 시작하지 않습니다. 한 번에 한 모델씩, 실행 중인 모델부터 맞추고, 대화용으로 맞출 설정이 있는 모델만 맞춥니다. 같은 모델은 모델 파일이나 엔진, 컴퓨터가 바뀌었을 때만 다시 맞춥니다. 벤치마크 페이지의 설정 맞추기와 같은 측정을 하되 드래프터 비교는 하지 않고, 실행 중인 모델을 묻지 않고 멈췄다가 끝나면 다시 실행합니다. 컴퓨터를 사용하거나, 대화 요청이 들어오거나, 모델을 불러오거나, 직접 측정을 시작하거나, 배터리로 바뀌거나, 스위치를 끄거나, 앱을 종료하면 바로 멈추고 아무 설정도 바꾸지 않습니다. 끝난 측정은 1.1배 이상 빨라진 속도 설정(배치 크기, 스레드, Flash Attention, GPU 레이어, CPU MoE 레이어, MLX 프리필 청크, n-gram 추측)만 적용하고, 직접 바꾼 값은 바꾸지 않습니다. 모델을 다시 실행하지는 않아서 다음 실행부터 적용됩니다. 적용된 값은 모델 설정의 하드웨어 탭과 모델 상세의 프로필에 AI:GO가 맞춤으로 표시되고, 되돌리기로 이전 값으로 돌려놓을 수 있습니다. 벤치마크 페이지의 기록에는 자동으로 표시되고 중간에 멈춘 측정에는 멈춘 이유가 남으며, 스위치 아래에는 지금 하는 일이 나옵니다. 헤드리스 서버는 스스로 설정을 맞추지 않으며, 해당 설정은 저장만 됩니다.

사용 목적에 맞는 더 빠른 설정을 직접 찾는 설정 맞추기는 벤치마크 페이지에 있습니다(설정 맞추기 참고). 모델 상세의 프로필에는 사용 목적마다 프로필이 하나씩 남는데, 되돌리기는 적용하기 전 설정으로 돌려놓고(적용한 날짜를 알려 주며 먼저 확인을 받습니다), 저장해 둔 프로필의 적용은 벤치마크 페이지에서 결과 화면을 엽니다. 적용과 되돌리기는 모델을 다시 실행하기 때문에 다른 측정이 진행 중이면 누를 수 없습니다.

노트북에서는 배터리로 사용 중에는 미루기를 켜 두면 처음 실행할 때의 빠른 측정을 전원에 연결된 다음 실행으로 미룹니다.

엔진이나 앱이 업데이트되면 측정값에 엔진 바뀜이 붙고, 다시 측정하기 전까지 그대로 남습니다. 측정이 저절로 시작되면 실행 중인 모델을 멈추게 되니 측정은 하지 않고, 대신 실제 대화의 속도를 계속 기록하죠. 새 엔진에서 기준 기록과 같은 설정으로 64토큰 이상 답변한 대화가 10번 쌓이면 답변 속도의 중앙값을 기준 기록과 비교하는데, 기준의 80%보다 느리면 모델 행과 상세에 "Qwen3-8B가 업데이트 전보다 느립니다. 답변 34 tok/s, 전에는 45 tok/s." 같은 경고가 나오고, 다시 측정과 설정 맞추기가 있는 알림이 모델과 엔진 빌드마다 한 번 옵니다. 다시 측정은 빠른 측정을 하고 결과가 어떻든 해당 결과를 새 기준 기록으로 삼습니다. 이전 속도와 10% 이내로 차이 나면 측정값은 전과 같고 느려진 것은 대화 내용 때문일 수 있다고 알려 주고, 그렇지 않으면 경고가 남고, 알림의 설정 맞추기는 벤치마크 페이지에서 설정 맞추기를 엽니다. 기준 기록과 다른 설정으로 답변한 대화는 비교하지 않는데, 설정이 다른 것은 느려진 것이 아니기 때문이고, 프로바이더 모델도 비교하지 않습니다. 헤드리스 서버도 웹 UI에서 나눈 대화로 똑같이 확인합니다.

도구 권한, MCP, 웹 검색¶

설정 > 도구 및 확장을 엽니다.

일반에는 도구 호출 스위치와 사용 가능한 도구가 있습니다. 사용 가능한 도구를 누르면 도구마다 스위치와 테스트 동작이 있는 목록이 열립니다. 그 아래에 MCP 서버와 웹 검색 도구가 이어지고, 워크스페이스 컨텍스트, Python 샌드박스, 로컬 네트워크 접근, 스킬 셸 주입은 맨 아래 고급에서 각각 엽니다.

이 항목은 Backend.AI GO가 원격 MCP 서버에 접속하는 클라이언트 쪽 설정입니다. Backend.AI GO 자체를 MCP 서버로 노출하려면 설정 > API 서버 > 관리 API의 MCP 엔드포인트 문서를 참고하세요.

음성 입력 동작¶

설정 > 음성 입력을 엽니다.

업데이트 채널¶

설정 > 일반을 열고 업데이트 섹션에서 정합니다. 채널은 업데이트 검사가 받아 오는 빌드를 정합니다: 안정, 베타, 카나리.

채널을 옮기면 해당 채널로 이동하고, 앱은 버전 번호가 아니라 발행 시점을 기준으로 현재 빌드 이후에 발행된 대상 채널의 가장 최신 빌드를 제공합니다. 현재 빌드 이후에 발행된 빌드가 없으면 검사 결과는 업데이트 없음이고 지금 빌드에 머뭅니다. 같은 채널 안의 검사는 버전 번호를 비교하는 방식 그대로입니다.

커넥터 설정¶

설정 > 커넥터를 엽니다.

데이터 허브 검색 프리셋과 관리 작업¶

설정 > 데이터를 열거나, 데이터 페이지의 데이터 설정 탭을 누릅니다. 프리셋마다 편집기, 임베딩 실행, 삭제를 담은 화면이 따로 열리며, 저장하지 않은 수정이 있으면 뒤로 가기 전에 먼저 묻습니다.

유지보수 작업¶

설정 > 유지보수를 엽니다.

관련 페이지¶

• 모델 설정
• 벤치마킹
• 에이전트 확장
• MCP 연동하기
• Claude Code용 API 서버 설정