작업별 모델 전환을 동시성 프로토콜로 간주하세요 노트

작업별 모델 전환을 동시성 프로토콜로 간주하세요

실행 중인 작업에 대한 AI 모델 변경은 단순한 설정 업데이트가 아닌 분산 작업입니다. 현재 작업을 읽고, 자격 증명을 준비하고, 재시작을 요청하고, 결과를 받고, 활성 모델을 유지하는 과정을 포함합니다. 여러 모델 전환 요청이 겹칠 경우, 완료 순서가 요청 순서와 다를 수 있으므로 어떤 의도가 우선하는지 결정하는 규칙이 필요합니다. MonkeyCode 시스템은 모델 ID 및 요청 ID와 같은 세부 정보로 모델 전환 시도를 기록합니다. 일반적인 워크플로우는 전환 기록을 생성하고, 작업 흐름에 재시작을 요청한 다음, 전환 기록을 완료하는 것을 포함합니다. 그러나 소스 검토에서 명시적인 비교 및 교환(compare-and-swap) 생성 또는 겹치는 요청에 대한 작업별 직렬화 계약은 확립되지 않았습니다."마지막 완료가 이기는" 접근 방식의 불안정성은 네트워크 타이밍으로 인해 나중에 성공한 완료가 이전 완료를 덮어쓸 수 있는 시나리오에서 입증됩니다. 동반 시뮬레이터는 이 순서 의존성을 시각화하여 호출자의 최신 의도가 본질적으로 고려되지 않음을 보여줍니다. 이를 해결하기 위해 각 요청에 고유한 생성 번호를 할당하는 단조 생성(monotonic generation)이 제안됩니다. 시스템은 완료의 생성이 작업의 현재 요청된 생성과 일치하는 경우에만 활성 모델을 업데이트해야 합니다. 이 생성 가드(generation guard)는 나중에 완료되더라도 오래된 작업이 적용되지 않도록 합니다.생성 가드는 중복 요청, 경쟁 요청, 지연 성공, 재시작 실패, 프로세스 충돌, 세션 로딩 및 자격 증명 바인딩에 대한 계약을 정의해야 하는 포괄적인 프로토콜의 일부일 뿐입니다. 작업별 잠금(per-task locks)과 같은 직렬화는 대안이지만 임대 만료(lease expiry) 및 공정성(fairness)과 같은 복잡성을 야기합니다. 단위 테스트는 다양한 단계에서 작업의 제어된 인터리빙(interleaving)으로 이 프로토콜을 검증해야 합니다. 불변량(invariant)은 활성 모델이 항상 가장 큰 대체되지 않은 생성에 대한 성공적인 결과에 해당해야 한다는 것입니다. 모델 전환을 프로토콜로 취급하면 UI, 감사 기록, 재시도 및 지속성 전반에 걸쳐 일관성을 보장합니다.