Question 1

LocalAI가 모델별 context_size를 무시하고 항상 전역 Default Context Size를 사용하는 문제를 어떻게 해결하나요?

Accepted Answer

LocalAI v4.11.0에서는 context_size를 parameters 아래가 아니라 모델 YAML의 최상위 레벨에 두십시오. 로더가 parameters.context_size를 무시하므로 대신 전역 Default Context Size가 사용됩니다.

올바른 구성:

backend: llama-cpp
context_size: 8192

parameters:
  model: Qwen3-VL-4B-Thinking-Q4_K_M.gguf

변경 사항을 저장한 후 LocalAI를 다시 시작하고 시작 로그를 확인하십시오.

load_model: initializing, n_slots = 1, n_ctx_slot = 8192

최상위 context_size가 전역 Default Context Size보다 우선합니다. YAML이 영향을 받은 갤러리 템플릿에 의해 생성된 경우, context_size를 수동으로 parameters 블록 밖으로 이동하십시오. 갤러리 수정은 이 옵션을 YAML 루트에 둡니다.

Question 2

LocalAI 4.3.4에서 'reasoning_effort=none'이 작동하지 않는 문제를 해결하는 방법

Accepted Answer

이는 LocalAI 4.0.0 이후 버전에서 발생하는 알려진 회귀(issue #10072)입니다. `reasoning_effort=none` 파라미터는 모델이 추론 토큰을 생성하지 못하도록 막고 응답 속도를 높여야 하지만, 최신 버전의 버그로 인해 이 파라미터가 무시됩니다. 임시 해결책으로, 이 기능이 llama-cpp 백엔드 모델(예: Qwen3)에서 정상 작동하는 것으로 보고된 LocalAI v4.0.0 또는 v3.12.1로 다운그레이드하세요. 다운그레이드가 불가능한 경우, `top_p=0` 및 `temperature=0`을 설정하여 모델이 추론을 건너뛰도록 강제하거나, 지연 시간이 중요한 작업에는 비추론 모델을 사용해 볼 수도 있습니다. 영구적인 해결을 위해서는 GitHub issue #10072를 모니터링하고 패치가 릴리스되면 업그레이드하세요. 모델 설정 파일에서 `reasoning_effort` 옵션이 백엔드 파라미터에 올바르게 매핑되도록 하십시오(예: llama-cpp에서는 `--reasoning-effort none`에 매핑되어야 함).

Question 3

왜 일부 LocalAI v4.3.2 Docker 이미지가 Docker Hub에서 누락되었나요?

Accepted Answer

CI 빌드 실패로 인해 여러 v4.3.2 태그의 게시가 불가능했습니다. 영향을 받아 누락된 태그: v4.3.2, v4.3.2-gpu-nvidia-cuda-12, v4.3.2-gpu-nvidia-cuda-13, v4.3.2-gpu-vulkan, v4.3.2-gpu-intel. 성공적으로 게시된 태그: v4.3.2-gpu-hipblas, v4.3.2-nvidia-l4t-arm64, v4.3.2-nvidia-l4t-arm64-cuda-13. 해결 방법으로 `localai/localai:master` 이미지를 사용하세요.

Question 4

LocalAI가 별도의 reasoning 필드 대신 content 필드 안에 reasoning/thinking 출력을 반환하는 이유는 무엇인가요?

Accepted Answer

이는 LocalAI v4.3.1의 알려진 리그레션으로, 모델 임포트 코드보다 오래된 설정을 가진 갤러리 제공 모델(예: qwen3-4b)에 영향을 미칩니다. `...` 추론이 `reasoning` 필드로 분리되지 않고 `content`에 병합되는 문제입니다. 이는 PR #9991에서 수정되었으므로, 해당 수정이 포함된 릴리스로 LocalAI 컨테이너 이미지를 업그레이드하세요(예: `localai/localai:v4.3.1-gpu-vulkan` 대신 latest 태그를 pull). 임시 해결 방법으로는, 분리가 올바르게 작동하는 v4.0.0으로 다운그레이드하거나 임포트된(갤러리가 아닌) 모델을 사용하세요. 임포트 코드가 도입되기 전에 설치된 갤러리 모델이 영향을 받기 때문입니다. 백엔드를 재설치하거나 데이터 디렉터리를 삭제해도 v4.3.1에서는 해결되지 않습니다.

Question 5

LocalAI 스트리밍 `/v1/chat/completions`에서 `index` 값이 서로 다른 중복 `tool_calls`를 어떻게 수정하나요?

Accepted Answer

이 문제는 C++ chat-template autoparser와 Go iterative JSON parser가 동일한 tool call을 모두 출력할 때 LocalAI의 스트리밍 경로에서 발생합니다. 각 파서는 자체 인덱스 추적을 사용하므로 하나의 논리적 호출이 인덱스 `0`, `1`, 때로는 `2`에 나타날 수 있습니다. 스트리밍이 아닌 요청은 영향을 받지 않습니다.

즉시 적용 가능한 해결 방법: tool-calling 요청에서 스트리밍을 비활성화합니다:

```json
{
  "stream": false
}
```

예시:

```bash
curl -s -X POST http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "orca-agent-v0.1",
    "messages": [{"role":"user","content":"Run ls /tmp | wc -l"}],
    "tools": [{
      "type":"function",
      "function":{
        "name":"bash",
        "description":"Run a bash script",
        "parameters":{
          "type":"object",
          "properties":{"script":{"type":"string"}},
          "required":["script"]
        }
      }
    }],
    "stream": false
  }'
```

다음 설정들은 중복 문제를 해결하지 못합니다: `disable_peg_parser: true`, `grammar.no_mixed_free_string: true`, `parallel_tool_calls: false`. 특히 마지막 설정은 `/v1/chat/completions`에서 적용되지 않습니다.

코드 수준 수정: `core/http/endpoints/openai/chat.go`에서 요청당 하나의 tool-call 파서만 사용합니다. C++ autoparser에서 생성된 `chatDeltas`에 tool call이 이미 존재하는 경우 `functions.ParseJSONIterative`를 건너뜁니다. 또는 C++가 출력한 호출을 사용하여 `lastEmittedCount`를 초기화하고 증가시킨 뒤, `chat_emit.go`에서 지연된 flush의 중복을 제거합니다.

LocalAI

주요 기능

할 수 없는 것

사용 사례

태그

시작하기

유사한 프로젝트