Q: GLiNER2 개체 추출이 긴 문서에서 처음 512개 단어 이후의 개체를 누락하는 이유는 무엇인가요?

수정 이전 버전에서는 GLiNER2 모델(`fastino/gliner2-base-v1`, `fastino/gliner2-large-v1`)에서 엔티티, 관계 및 구조화 추출 시 각 항목의 텍스트가 `max_seq_length`(기본값 512단어)에서 자동으로 잘렸으므로, 해당 윈도우를 벗어난 콘텐츠는 모델에 전달되지 않았습니다. 해결 방법: PR #552(커밋 `689e4d808cbd66008500da8f58d8fa6e71510b8f`)가 포함된 빌드로 업그레이드하세요. 수정 후에는 너무 긴 항목이 자동으로 일부만 읽히는 대신 항목별 명시적 `INPUT_TOO_LONG` 오류로 실패합니다. 거부된 항목은 모델 호출에서 제외되고 입력 토큰 사용량이 0으로 보고되며, 같은 배치 내 유효한 항목들은 결과와 원래 위치를 그대로 유지합니다. 겹치는 윈도우를 통한 전체 문서 추출은 아직 병합되지 않은 개선 사항(#649)입니다. 이 기능이 적용되기 전까지는 `POST /v1/extract/{model}`을 호출하기 전에 긴 문서를 단어/서브워드 윈도우에 맞는 청크로 분할하세요.

Q: gliner2 2.0.0으로 업그레이드한 후 중복 NER 엔티티 및 'structured extraction property must be a string' 오류를 수정하는 방법은?

gliner2 2.0.0은 `fastino/gliner2-base-v1` 및 `fastino/gliner2-large-v1`의 출력을 두 가지 방식으로 변경했습니다: (1) NER 중복 제거(dedup) 키가 `text.lower()`에서 `(text.lower(), start, end)`로 변경되어, 반복되는 엔티티의 첫 번째 언급만 반환되던 대신 모든 언급이 반환됩니다(엔티티 수가 긴 텍스트에서 예를 들어 21 → 100으로 급증할 수 있음); (2) 구조화 추출(structured extraction)이 재점수화되어 일부 필드가 이제 `null`을 반환하며, SIE `GLiNER2Adapter`는 이를 `GLiNER2 structured extraction property 'person' must be a string` 오류로 거부하여 전체 요청이 실패합니다. 해결 방법: gliner2를 1.x 라인으로 고정하세요(`gliner2>=1.3.1,<2`, 즉 1.3.2) — 이는 기본 번들과 루트 lock이 사용하는 방식입니다. 참고: 옵트인 엔티티 LoRA 어댑터는 정확히 gliner2 1.3.2를 요구하므로 2.x에서는 작동하지 않습니다. 2.0.0을 반드시 실행해야 한다면, 1.x 동작을 복원하기 위해 소문자 표면형(surface form)을 기준으로 엔티티를 직접 중복 제거하고, 요청을 실패시키는 대신 `null` 구조화 필드를 처리하세요(속성을 생략하거나 항목별 오류를 발생시킴). 이러한 모델의 2.x 마이그레이션은 언급 정책, null 처리 및 리베이스라이닝에 대한 결정이 내려지기를 기다리며 여전히 보류 중입니다.

Q: macOS arm64(Apple Silicon)에서 mmap을 통해 safetensors 가중치를 로드할 때 torch.nn.functional.linear에서 발생하는 NaN/Inf 출력을 수정하는 방법은?

원인: 영향을 받는 macOS arm64 스택(예: torch 2.9.1, Python 3.12)에서는 메모리 매핑된 safetensors 텐서가 정렬되지 않은 주소에서 시작할 수 있습니다(data_ptr % 64 != 0, 텐서의 파일 오프셋이 4/64바이트로 정렬되어 있지 않기 때문). 이러한 매핑된 가중치를 `torch.nn.functional.linear`에 전달하면 가중치, 입력, 바이어스가 모두 유한함에도 불구하고 비유한(NaN/Inf) 출력이 생성됩니다. 해결 방법: 사용 전에 가중치를 정렬된 인메모리 복사본으로 강제로 만들거나(`weight = weight.clone()`), `safe_open` / 지연 로딩 텐서 프레임워크를 통한 mmap 뷰 대신 `safetensors.torch.load_file("model.safetensors")`로 체크포인트를 로드하십시오. 복제 후에는 바이트가 완전히 동일한 가중치가 비유한 값 0개를 생성하며 float64 NumPy 참조 값과 일치합니다(최대 절대 오차 ~5.2e-6). 영향을 받는지 확인하려면 `tensor.data_ptr() % 64`를 검사하십시오. 매핑된 텐서에서 0이 아닌 값이 나오면 위험이 있음을 나타냅니다.

Q: GLiFormer 추론이 짧은 텍스트에서 GPU가 대부분 유휴 상태임에도 불구하고 느린 이유는 무엇이며, 어떻게 해결할 수 있나요?

짧은 입력(40-140 토큰)에서 GLiFormer의 47 ms forward는 커널 실행 오버헤드로 인해 CPU-bound 상태입니다: 약 1,270개의 소규모 CUDA 커널을 실행하고 약 71회의 stream synchronization이 발생하며(그중 31회는 태스크 헤드의 `.item()` 호출에서 발생), GPU가 실제로 작업 중인 시간은 약 8 ms에 불과합니다. 해결책은 CUDA graph replay이며, #367의 GLiClass 접근 방식을 따라 PR #796에서 구현되었습니다: forward의 정적 부분(고정된 패딩 shape을 가진 DeBERTa 백본)은 한 번만 기록되어 CUDA graph로 재생되고, 데이터 의존적 제어 흐름을 가진 태스크 헤드는 eager 상태를 유지하며 그래프의 정적 출력 버퍼를 읽습니다. CUDA graph는 opt-in 방식이며 기본값은 OFF입니다 — eager 실행과 bit-identical한 출력으로 pretrained parity 검사를 통과하는 'exact shapes' 모드를 활성화하면 됩니다. Bucketed (padded-length) 모드는 고정된 수치 허용 오차 한도를 통과하지 못해 거부/사용 불가 처리되었습니다. 메모리 사용량은 모델별 예산으로 상한이 정해지고, 한 번에 하나의 기록만 실행되며, 메모리 압박 상황에서는 기록이 건너뛰어지고, 모델 언로드 시 그래프 메모리가 해제됩니다.

Question 1

Docker 이미지 빌드에서 uv.lock에 고정된 버전보다 더 최신 패키지 버전이 설치되는 이유는 무엇이며, pip 설치를 재현 가능하게 만드는 방법은 무엇인가요?

Accepted Answer

이 문제는 이미지 빌드가 범위 지정자(예: `gliner>=0.2.26,<1`)와 함께 `pip install -r`을 실행할 때 발생합니다: pip이 빌드 시점에 조건에 맞는 최신 릴리스를 해석(resolve)하면서 `uv.lock`에 고정된 정확한 버전을 덮어쓰기 때문에, 같은 커밋의 두 빌드가 서로 다른, 테스트되지 않은 버전을 포함할 수 있습니다. sie_server에서는 PR #653과 #802를 통해 이 문제가 수정되었습니다: 번들 이미지는 더 이상 빌드 중에 범위를 해석하지 않습니다. 대신 릴리스된 11개의 Linux amd64 이미지 전체와 지원되는 4개의 CPU arm64 조합을 포괄하는 15개의 체크인된 타깃 잠금 파일에서 저장된 의존성 클로저(dependency closure)를 설치합니다. 명시적이고 문서화된 번들 예외가 적용되지 않는 한 패키지는 루트 `uv.lock`의 고정 버전을 유지하며, CI는 오래되었거나 일관성이 없는 잠금 파일을 거부하고, 이미지 빌드는 설치된 `/app/bundle-libs` 인벤토리(`pip freeze`)를 검증하고 보존하여 배포된 모든 버전을 감사할 수 있도록 합니다. 자체 프로젝트에서 이 문제를 해결하려면: (1) `uv export --frozen --no-hashes`로 잠긴 버전을 내보내고 이를 제약 파일(constraints file)로 pip에 전달하여(`pip install -c constraints.txt -r requirements.txt`) 잠긴 패키지가 고정된 버전을 유지하도록 하거나, (2) 정확한 버전이 리포지토리에 체크인된 번들별 잠금 파일을 유지 관리하고, (3) 이미지 내부에 설치된 타깃 디렉터리의 해석된 `pip freeze`를 기록하세요.

Question 2

GLiNER2 개체 추출이 긴 문서에서 처음 512개 단어 이후의 개체를 누락하는 이유는 무엇인가요?

Accepted Answer

수정 이전 버전에서는 GLiNER2 모델(`fastino/gliner2-base-v1`, `fastino/gliner2-large-v1`)에서 엔티티, 관계 및 구조화 추출 시 각 항목의 텍스트가 `max_seq_length`(기본값 512단어)에서 자동으로 잘렸으므로, 해당 윈도우를 벗어난 콘텐츠는 모델에 전달되지 않았습니다. 해결 방법: PR #552(커밋 `689e4d808cbd66008500da8f58d8fa6e71510b8f`)가 포함된 빌드로 업그레이드하세요. 수정 후에는 너무 긴 항목이 자동으로 일부만 읽히는 대신 항목별 명시적 `INPUT_TOO_LONG` 오류로 실패합니다. 거부된 항목은 모델 호출에서 제외되고 입력 토큰 사용량이 0으로 보고되며, 같은 배치 내 유효한 항목들은 결과와 원래 위치를 그대로 유지합니다. 겹치는 윈도우를 통한 전체 문서 추출은 아직 병합되지 않은 개선 사항(#649)입니다. 이 기능이 적용되기 전까지는 `POST /v1/extract/{model}`을 호출하기 전에 긴 문서를 단어/서브워드 윈도우에 맞는 청크로 분할하세요.

Question 3

gliner2 2.0.0으로 업그레이드한 후 중복 NER 엔티티 및 'structured extraction property must be a string' 오류를 수정하는 방법은?

Accepted Answer

gliner2 2.0.0은 `fastino/gliner2-base-v1` 및 `fastino/gliner2-large-v1`의 출력을 두 가지 방식으로 변경했습니다: (1) NER 중복 제거(dedup) 키가 `text.lower()`에서 `(text.lower(), start, end)`로 변경되어, 반복되는 엔티티의 첫 번째 언급만 반환되던 대신 모든 언급이 반환됩니다(엔티티 수가 긴 텍스트에서 예를 들어 21 → 100으로 급증할 수 있음); (2) 구조화 추출(structured extraction)이 재점수화되어 일부 필드가 이제 `null`을 반환하며, SIE `GLiNER2Adapter`는 이를 `GLiNER2 structured extraction property 'person' must be a string` 오류로 거부하여 전체 요청이 실패합니다. 해결 방법: gliner2를 1.x 라인으로 고정하세요(`gliner2>=1.3.1,<2`, 즉 1.3.2) — 이는 기본 번들과 루트 lock이 사용하는 방식입니다. 참고: 옵트인 엔티티 LoRA 어댑터는 정확히 gliner2 1.3.2를 요구하므로 2.x에서는 작동하지 않습니다. 2.0.0을 반드시 실행해야 한다면, 1.x 동작을 복원하기 위해 소문자 표면형(surface form)을 기준으로 엔티티를 직접 중복 제거하고, 요청을 실패시키는 대신 `null` 구조화 필드를 처리하세요(속성을 생략하거나 항목별 오류를 발생시킴). 이러한 모델의 2.x 마이그레이션은 언급 정책, null 처리 및 리베이스라이닝에 대한 결정이 내려지기를 기다리며 여전히 보류 중입니다.

Question 4

macOS arm64(Apple Silicon)에서 mmap을 통해 safetensors 가중치를 로드할 때 torch.nn.functional.linear에서 발생하는 NaN/Inf 출력을 수정하는 방법은?

Accepted Answer

원인: 영향을 받는 macOS arm64 스택(예: torch 2.9.1, Python 3.12)에서는 메모리 매핑된 safetensors 텐서가 정렬되지 않은 주소에서 시작할 수 있습니다(data_ptr % 64 != 0, 텐서의 파일 오프셋이 4/64바이트로 정렬되어 있지 않기 때문). 이러한 매핑된 가중치를 `torch.nn.functional.linear`에 전달하면 가중치, 입력, 바이어스가 모두 유한함에도 불구하고 비유한(NaN/Inf) 출력이 생성됩니다. 해결 방법: 사용 전에 가중치를 정렬된 인메모리 복사본으로 강제로 만들거나(`weight = weight.clone()`), `safe_open` / 지연 로딩 텐서 프레임워크를 통한 mmap 뷰 대신 `safetensors.torch.load_file("model.safetensors")`로 체크포인트를 로드하십시오. 복제 후에는 바이트가 완전히 동일한 가중치가 비유한 값 0개를 생성하며 float64 NumPy 참조 값과 일치합니다(최대 절대 오차 ~5.2e-6). 영향을 받는지 확인하려면 `tensor.data_ptr() % 64`를 검사하십시오. 매핑된 텐서에서 0이 아닌 값이 나오면 위험이 있음을 나타냅니다.

Question 5

GLiFormer 추론이 짧은 텍스트에서 GPU가 대부분 유휴 상태임에도 불구하고 느린 이유는 무엇이며, 어떻게 해결할 수 있나요?

Accepted Answer

짧은 입력(40-140 토큰)에서 GLiFormer의 47 ms forward는 커널 실행 오버헤드로 인해 CPU-bound 상태입니다: 약 1,270개의 소규모 CUDA 커널을 실행하고 약 71회의 stream synchronization이 발생하며(그중 31회는 태스크 헤드의 `.item()` 호출에서 발생), GPU가 실제로 작업 중인 시간은 약 8 ms에 불과합니다. 해결책은 CUDA graph replay이며, #367의 GLiClass 접근 방식을 따라 PR #796에서 구현되었습니다: forward의 정적 부분(고정된 패딩 shape을 가진 DeBERTa 백본)은 한 번만 기록되어 CUDA graph로 재생되고, 데이터 의존적 제어 흐름을 가진 태스크 헤드는 eager 상태를 유지하며 그래프의 정적 출력 버퍼를 읽습니다. CUDA graph는 opt-in 방식이며 기본값은 OFF입니다 — eager 실행과 bit-identical한 출력으로 pretrained parity 검사를 통과하는 'exact shapes' 모드를 활성화하면 됩니다. Bucketed (padded-length) 모드는 고정된 수치 허용 오차 한도를 통과하지 못해 거부/사용 불가 처리되었습니다. 메모리 사용량은 모델별 예산으로 상한이 정해지고, 한 번에 하나의 기록만 실행되며, 메모리 압박 상황에서는 기록이 건너뛰어지고, 모델 언로드 시 그래프 메모리가 해제됩니다.

sie

주요 기능

할 수 없는 것

사용 사례

태그

시작하기

유사한 프로젝트