공유 홈 AI 서비스에서 요청별 비용 한도를 설정할 수 있게 하는 기능은 무엇인가요?

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

What Features Enable Per-Request Cost Limits in a Shared Home AI Service?

요청별 비용 한도는 게이트웨이가 정책을 토큰, 시간, 메모리, 도구, 재시도 및 대기 작업에 적용할 수 있는 예산으로 변환할 때 작동합니다.

가족 구성원이 공유 홈 서버에서 간단한 검색을 수행했는데, 예기치 않게 긴 모델 응답, 세 번의 검색 단계, OCR 및 여러 에이전트 도구가 실행될 수 있습니다. 로컬 추론에는 토큰당 클라우드 청구서가 없지만, 여전히 부족한 가속기 시간, 전력, RAM 및 대화형 처리 용량을 소비합니다. 서비스에는 사전 추정, 실시간 사용량 기록, 취소 지점, 그리고 한 예산이 소진되었을 때의 명확한 동작이 필요합니다.

실행 허가 추정은 제한된 리소스 범위를 예약합니다

실행 전에 게이트웨이는 입력 토큰, 최대 출력량, 모델 등급, KV 캐시 메모리, 검색 깊이, 도구 수 및 기한을 추정합니다. 사용자, 엔드포인트 및 워크플로 정책을 결합해 하나의 변경 불가능한 요청 예산을 만들며, 다운스트림 서비스는 이를 몰래 늘릴 수 없습니다.

반복 단위 스케줄링은 반복 단위의 세분성으로 생성을 스케줄링하고 서로 다른 길이의 요청을 동적으로 배치합니다. 이 설계는 실제 디코딩 작업이 초기 프롬프트만으로 완벽하게 알려지는 것이 아니라 토큰 단위로 드러나는 이유를 보여 줍니다. 이러한 차이는 이후 가정용 환경 테스트에서도 확인됩니다.

따라서 추정치는 상한을 예약하되 모든 요청이 그 상한에 도달하는 것처럼 요금을 부과해서는 안 됩니다. 규모는 크지만 위험이 낮은 백그라운드 작업은 대기열에 들어갈 수 있고, 최악의 경우 필요한 메모리가 기존 예약을 초과할 때는 대화형 작업을 조기에 거부할 수 있습니다.

런타임 미터는 토큰, 시간, 메모리 및 도구를 적용합니다

모든 서비스는 요청 ID에 따라 표준화된 사용량을 보고합니다. 여기에는 프롬프트 및 생성 토큰, GPU 밀리초, 최대 메모리, CPU 시간, 읽은 바이트 수, 도구 호출, 재시도 및 외부 작업이 포함됩니다. 중앙 원장은 사용량을 원자적으로 차감하므로 병렬 분기가 각각 남은 예산 전체를 사용할 수 없습니다.

청크 단위 프리필 스케줄링은 처리량과 디코딩 지연 시간의 균형을 맞추기 위해 청크 단위 프리필과 정체 없는 스케줄링을 연구합니다. 이는 하나의 긴 프롬프트가 작업을 강제 가능한 단위로 나누지 않으면 서비스 용량을 일시적으로 과도하게 소비할 수 있음을 보여 줍니다. 자동화가 다음 단계를 수행하기 전에 중간 결과를 확인할 수 있어야 합니다.

도구 예산에는 단순한 호출 횟수가 아니라 의미적 범주가 필요합니다. 읽기 전용 메타데이터 호출 열 번과 메시지 전송 한 번 또는 재귀적 파일 스캔 한 번은 다르므로, 정책은 부작용의 종류, 대상 범위, 출력 바이트 수 및 누적 실행 시간을 독립적으로 제한할 수 있어야 합니다.

취소와 부분 결과가 예산의 경계를 정의합니다

협력적 취소는 검색, 생성 및 도구 실행 전반으로 전파되며, 각 단계는 비용이 큰 작업을 시작하기 전에 기한 또는 남은 예산을 확인합니다. 멱등성 키는 취소된 재시도가 외부 부작용을 반복하지 않도록 방지합니다. 이 경계는 현실적인 운영 조건에서 별도로 측정해야 합니다.

공정한 GPU 스케줄링은 가속기 사이클을 시분할해 요청 고갈을 방지하고 추론 컨텍스트 이동 비용을 검토합니다. 이 연구는 공정성 제어가 연산 시간과 메모리 상태를 모두 고려해야 함을 보여 줍니다. 여러 소스가 제한된 컨텍스트를 놓고 경쟁할 때 이러한 실질적 결과가 나타납니다.

실패의 경계는 적용 없이 사용량만 기록하는 것입니다. 대시보드가 초과 사용을 보고하는 동안에도 한 요청이 GPU를 계속 독점할 수 있습니다. 한도에 도달하면 시스템은 안전한 체크포인트에서 중지하고, 명시적인 부분 결과를 반환하며, 예산 소진을 모델 또는 도구 실패와 구분해야 합니다.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

적대적인 요청 형태로 예산을 테스트합니다

대용량 입력, 출력이 제한되지 않은 프롬프트, 재귀적 도구 계획, 병렬 분기, 재시도 루프, 느린 도구, 캐시 미스 및 부작용이 발생하는 도중의 취소를 포함하는 요청을 생성합니다. 두 사용자와 하나의 백그라운드 서비스에 서로 다른 예산을 할당합니다. 이 의존성은 최종 인터페이스에 명시적으로 남아 있어야 합니다.

사용자별 리소스 정책의 사용자별 QoS 경계를 사용해 예약 토큰과 실제 토큰, GPU 시간, 최대 메모리, 대기열 지연, 도구 작업, 재시도 횟수, 취소 지연 및 부분 결과 품질을 기록합니다. 자식 스팬이 부모 예산을 초기화하지 않고 상속하는지 확인합니다.

모든 비용이 큰 작업이 귀속되고, 문서화된 정리 작업을 제외하면 어떤 요청도 하드 한도를 초과하지 않을 때만 통과로 판정합니다. 정확한 추정이 불가능하다면 보수적으로 실행을 허용하고 사용하지 않은 용량을 환불해야 하며, 다운스트림 서비스가 새로운 예산을 임의로 만들어 내도록 허용해서는 안 됩니다.