AnythingLLM Max Tokens: 긴 답변이 잘릴 때 확인할 설정

AnythingLLM의 긴 답변이 문장 중간에서 멈추면 Max Tokens가 해당 출력을 제한했는지 먼저 확인하세요. 컨텍스트 창을 늘리는 것과 프록시 제한 시간을 늘리는 것은 같은 문제의 대체 해결책이 아닙니다. 실제 전송된 출력 예산, 상위 API의 finish_reason, 조건 하나만 바꾼 재시험 결과를 확인하되 기존 설정은 복원할 수 있도록 남겨 두세요.

종료 증거에 따라 해결 방향을 고르세요

화면에 글자가 더 이상 나오지 않는 것은 증상이지 원인이 아닙니다. OpenAI Chat Completions의 정의에서 length는 요청에 지정한 토큰 한도에 도달했다는 뜻입니다. stop은 자연스럽게 끝났거나 지정한 중지 시퀀스를 만났다는 뜻일 수 있습니다. tool_calls는 도구 호출로 넘어갔다는 뜻이며 최종 답변이 완성됐다는 의미가 아닙니다. 호환 API에서는 실제 서버 동작도 함께 확인해야 합니다.

확보한 증거	먼저 확인할 항목	다음 행동
상위 API가 finish_reason=length를 반환했고 실제 출력 예산도 확인 가능함	출력 한도	입력은 고정하고 지원 범위 안의 출력 예산만 변경
서버가 명시적으로 컨텍스트 초과를 알리며, 기록이나 검색 문서를 줄이면 같은 작업이 완료됨	컨텍스트 부담	출력만 늘리지 말고 입력을 줄여 실제 모델의 창 크기를 확인
시간 초과, 연결 재설정, 취소 기록이 있거나 종료 사유 없이 스트림이 끝남	연결, 취소, 스트리밍 호환성	시각을 대조해 요청을 끝낸 구간을 확인. 필드가 없다는 사실만으로 네트워크 오류를 단정하지 않음
stop이 반환됐지만 일부 절이나 번호 항목이 빠짐	지시, 중지 시퀀스, 내용 완전성	누락 내용을 점검. 정상 종료와 작업 완료는 다름

출력 예산은 한 요청에서 얼마나 생성할 수 있는지를 제한합니다. 컨텍스트 창은 모델이 처리할 수 있는 컨텍스트의 용량입니다. 대화 기록, 시스템 지시, 검색으로 가져온 문서 조각도 입력에 들어갈 수 있으며 AnythingLLM의 Generic OpenAI 어댑터가 이를 조합합니다. 따라서 질문이 짧아도 요청 전체는 클 수 있고, 화면의 창 크기를 크게 입력해도 서버 모델의 능력이 확장되지는 않습니다.

issue #6703의 한 사용자는 출력 제한으로 잘린 답변 때문에 리버스 프록시와 WebSocket 제한 시간을 먼저 조사했다고 보고했습니다. 점검 순서를 정하는 데 참고할 개별 사용자 경험이지, 현재 설치에서도 원인이 같다는 증거는 아닙니다.

기존 설정을 보존하고 실제 호출 모델을 확인하세요

바꾸기 전에 현재 상태부터 기록하세요. AnythingLLM 버전, Desktop 또는 자체 호스팅 여부, 전역 제공자, 작업 공간과 채팅에서 선택한 제공자 및 모델, 에이전트 사용 여부, 컨텍스트와 출력 설정을 적어 둡니다. 스크린샷에서는 키를 가리고, 시험하려고 기존 작업 공간이나 대화, 색인된 문서를 삭제하지 마세요.

Settings에서 LLM 제공자 설정을 열고 시험이 실제로 Generic OpenAI를 사용하는지 확인합니다. 공식 설정 안내는 API 기능과 추론 응답 형식 모두 OpenAI와 호환돼야 한다고 설명합니다. 요청이 다른 제공자로 간다면 Generic OpenAI를 수정해도 그 경로의 설정은 바뀌지 않습니다.

2026-10-16에 확인한 공식 UI 소스에는 다음 필드가 있습니다.

필드	확인할 내용
Base URL, API Key, Selected Model	이전에 정상 호출된 주소, 해당 키, 정확한 모델 식별자. 표시 이름만 보고 식별자를 추측하지 않기
Model context window	설정된 컨텍스트 용량. 답변의 출력 예산과 구분하기
Max Tokens	생성 출력 예산. 컨텍스트 설정과 별도로 확인하기

저장한 다음 설정을 다시 열어 값이 유지되는지 확인하세요. 권한이 있는 요청 기록을 볼 수 있다면 실제 model과 출력 한도 필드도 점검합니다. 스크린샷은 화면에 표시된 값만 보여 줄 뿐 서버가 받은 요청을 증명하지 않습니다. 일반 채팅과 에이전트도 따로 시험하세요. Desktop v1.16.2 변경 기록에는 Generic OpenAI 에이전트 스트림에서 max tokens가 무시되던 문제의 수정이 명시돼 있습니다.

이미 BetterToken을 사용한다면 이 단계에서 Chat Completions 연결 안내와 현재 주소, 키, 모델 설정을 대조하세요. 이는 연결 설정의 참고 자료이지 AnythingLLM의 모든 기능이나 출력 제한 해제를 보장하는 해결책은 아닙니다.

0, 매개변수 이름, 버전을 구분하세요

0은 무제한 출력을 뜻하지 않습니다. Desktop v1.17.0 변경 기록은 Generic OpenAI에서 0을 사용해 요청의 max_tokens를 생략할 수 있다고 설명합니다. 그러면 상위 서버의 기본값과 제한이 적용됩니다. 진단에는 모델이 지원하는 명시적인 양수 예산을 쓰는 편이 비교하기 쉽습니다.

2026-10-16에 확인한 어댑터 소스에서 출력값은 GENERIC_OPEN_AI_MAX_TOKENS, 창 크기는 GENERIC_OPEN_AI_MODEL_TOKEN_LIMIT에서 가져옵니다. 기본 출력 필드는 max_tokens이며 GENERIC_OPEN_AI_MODEL_MAX_TOKEN_KEY로 다른 이름을 지정할 수 있습니다. 이는 확인한 소스의 동작이며 모든 설치 버전이 같은 설정을 제공한다는 약속은 아닙니다.

호환 API의 매개변수 이름을 일괄적으로 바꾸지 마세요. OpenAI의 현재 매개변수 문서에 있는 max_completion_tokens는 보이는 출력과 추론 토큰을 함께 예산에 포함합니다. 따라서 화면의 답변이 짧아도 예산을 다 쓸 수 있습니다. 실제 백엔드와 모델이 받는 필드를 확인하고, 설치 버전이 지원할 때 해당 설정을 바꾸세요.

Desktop에서는 화면 설정을 사용하고 인터넷 예시만 보고 .env를 편집하지 마세요. 공식 설정 문서는 해당 지침을 자체 호스팅 또는 Docker에만 적용합니다. v1.17.0에서는 작업 공간 설정의 저장 방식도 바뀌었습니다. 모든 버전에 같은 저장 버튼이 있을 것이라 가정하지 말고 설정을 다시 열어 값으로 확인하세요.

finish_reason과 실제 사용량은 어디서 확인하나요?

모델 서비스가 AnythingLLM에 보낸 응답을 우선 확인하세요. 비스트리밍 Chat Completions에서는 choices[0].finish_reason과 반환된 usage를 봅니다. 스트리밍에서는 종료 사유가 있는 청크와 서버의 전체 종료 절차가 도착했는지 확인하세요. 첫 청크의 빈 값은 최종 상태가 아닙니다. 공식 응답 정의를 기준으로 해석하면 됩니다.

웹 또는 자체 호스팅 웹 화면에서는 브라우저 개발자 도구의 Network 패널을 열고 로그를 유지한 뒤 문제를 한 번 재현합니다. 해당 채팅 요청의 시각, 상태, 응답을 기록하세요. 단, 이것은 브라우저와 AnythingLLM 사이를 보여 주는 것이며 모델 서비스의 원본 응답이라고 볼 수는 없습니다.

2026-10-16에 읽은 Generic OpenAI 스트림 처리 코드는 상위 응답의 비어 있지 않은 종료 사유를 그대로 UI에 전달하지 않고 AnythingLLM 자체의 close: true 메시지로 바꿉니다. 제공자가 사용량을 보내지 않으면 텍스트 청크 수로 추정하는 코드도 있습니다. 따라서 화면의 종료 표시나 토큰 숫자만으로 완전한 답변 또는 정확한 예산 소진을 확인할 수 없습니다.

접근 권한이 있는 모델 서비스 로그나 요청 상세에서 원래 종료 사유와 사용량을 확보하세요. 접근할 수 없다면 설치 관리 담당자에게 요청 시각과 식별자를 알려 주세요. Desktop v1.16.2 변경 기록에는 창 상단의 버전 표시를 눌러 로그와 저장 위치를 여는 방법이 있습니다. 해당 폴더를 열 수 있다는 사실이 모든 버전에서 원본 종료 필드를 기록한다는 뜻은 아닙니다.

최종 사용량 청크 자체를 받지 못할 수도 있습니다. OpenAI 문서는 스트림 중단이나 취소 시 마지막 usage 청크가 도착하지 않을 수 있다고 설명합니다. 이때는 “확보하지 못함”으로 기록하고 0으로 취급하지 마세요. 앱의 추정치를 청구 데이터로 대신해서도 안 됩니다.

기존 설정을 유지한 짧은 답변·긴 답변 비교

호출 경로를 먼저 고정한 다음 요구하는 답변 길이만 바꾸세요. 지식 문서를 연결하지 않은 시험용 작업 공간을 사용합니다. 같은 제공자와 모델을 고르고 시스템 지시, 온도, 출력 예산과 나머지 설정을 동일하게 유지하세요. 각 시험은 빈 채팅에서 시작해 두 번째가 첫 번째 기록을 물려받지 않도록 합니다. 에이전트나 도구 없이 일반 채팅부터 확인하세요.

짧은 답변 시험 A:

프로젝트 문서를 관리하는 방법 3가지를 제안해 주세요. 각 항목을 2–3문장으로 설명하고, 모두 마치면 별도 줄에 [END]를 써 주세요.

긴 답변 시험 B:

프로젝트 문서를 관리하는 방법 20가지를 제안해 주세요. 각 항목을 2–3문장으로 설명하고, 모두 마치면 별도 줄에 [END]를 써 주세요.

보낸 뒤 생성이 끝날 때까지 기다리고 중지 버튼이나 새로고침을 누르지 마세요. 시간 초과나 연결 중단이 생기면 계속 재시도하는 대신 발생 시각을 기록합니다. 표시된 답변 전체를 로컬 A.txt, B.txt에 복사하세요. 요청 시각, 실제 모델과 출력 예산, 종료 사유, usage가 제공자 보고값인지 여부, 마지막 번호와 [END] 유무도 남깁니다. 이 숫자는 시험 과제의 요구사항이며 모델 한도나 반드시 반환되는 길이가 아닙니다.

A는 완전하고 B는 불완전하더라도 긴 출력 상황에서 문제가 생긴다는 것만 알 수 있습니다. 아직 Max Tokens가 원인이라고 확정할 수는 없습니다. B가 length를 반환했다면 같은 프롬프트와 모든 다른 설정을 유지하고 출력 예산만 서버가 허용하는 명시적인 큰 값으로 바꿔 빈 채팅에서 C를 실행하세요. C.txt로 저장합니다. 20개 항목과 종료 표시가 모두 있고 length로 끝나지 않았다면 이 경우에는 예산 조정이 효과가 있었다는 근거가 됩니다.

B가 이미 완성된다면 불필요하게 예산을 크게 잡지 마세요. 같은 실제 업무를 기존 대화와 빈 채팅에서 비교하되 출력 설정은 고정합니다. 대화 기록이나 검색 문서와 함께 문제가 나타날 때 컨텍스트를 조사하세요. 더 이상 필요 없는 임시 설정은 복구하고 원래 기록은 보존합니다. 유료 API 시험에는 일반적인 호출 요금이 발생할 수 있습니다.

증거에 맞는 설정만 수정하세요

출력 한도가 확인됐다면 예산과 실제 전송 필드를 점검하세요

실제 호출 경로에서 사용하는 예산만 모델이 허용하는 범위 안에서 늘립니다. 화면의 숫자는 늘었는데 요청이 그대로라면 제공자 선택, 저장 여부, 버전, 일반 채팅과 에이전트 차이를 확인하세요. 서버까지 전달되지 않은 출력 설정은 컨텍스트 창을 넓혀도 고쳐지지 않습니다.

컨텍스트가 너무 크다면 작업과 예산은 유지하고 입력을 줄이세요

먼저 같은 긴 작업을 빈 채팅에서 다시 실행합니다. 그다음 검색 문서 조각이나 불필요한 기록을 따로 줄이세요. 서버가 컨텍스트 한도를 명시하면 실제 모델 용량에 맞게 창 크기를 설정합니다. 더 큰 숫자를 적는다고 확장되지는 않습니다. 명시적인 오류 없이 빈 채팅에서만 개선됐다면 컨텍스트는 아직 확인이 필요한 가설입니다.

연결이나 스트림 오류라면 먼저 끊긴 구간을 찾으세요

같은 시간대의 브라우저, AnythingLLM, 상위 API 기록을 대조해 취소, 시간 초과, 연결 종료를 찾습니다. 상위 API는 완료했지만 브라우저에 일부만 왔다면 중간 전송과 표시 처리를 조사합니다. 상위 API부터 실패했다면 그 오류부터 해결하세요. 로그가 특정 구간을 가리킬 때만 그 구간의 제한 시간을 조정합니다.

자체 호스팅 또는 Docker 관리자는 스트리밍을 독립적으로 시험할 수 있습니다. 공식 설정의 GENERIC_OPENAI_STREAMING_DISABLED="true"는 Generic OpenAI에만 적용되며, 변경 후 해당 서비스나 컨테이너를 다시 시작해야 합니다. 다른 조건은 유지하고 같은 긴 프롬프트를 실행한 뒤 이전 값으로 되돌려 다시 시작하세요. 비스트리밍 성공은 조사 범위를 스트림 관련 경로로 좁힐 뿐 프록시가 원인임을 증명하지 않습니다. Desktop에는 이 .env 편집을 적용하지 마세요.

해결됐는지 확인하고, 계속 실패하면 필요한 기록을 전달하세요

답변이 길어진 것만으로는 충분하지 않습니다. 요청한 절이나 번호가 모두 있는지, 마지막 문장이 완성됐는지, 종료 표시가 있는지 확인하세요. 원래 종료 사유와 연결 로그를 함께 살펴 다시 잘리지 않았는지도 확인합니다. stop이나 [END]는 내용 검토를 대신하지 못합니다. 단순화한 시험 이후에는 원래 실패했던 실제 작업도 다시 실행해야 합니다.

계속 실패하면 버전과 배포 방식, 일반 채팅 또는 에이전트, 제공자와 모델 식별자, 비밀값을 가린 설정, 최소 프롬프트, A/B/C 차이, 시각과 확보한 원본 종료 사유를 담당자에게 전달하세요. API 키, 인증 헤더, 비공개 문서 내용은 제거하고 없는 필드는 “확보하지 못함”으로 적습니다. 그래야 다음 조사가 구체적인 요청에서 시작되고, 프록시 제한 시간을 추측으로 바꾸는 일을 반복하지 않습니다.