Edge AI SLAFlow란? 품질과 지연시간을 함께 잡는 최신 런타임 기술 살펴보기

현장 카메라가 설비의 미세한 이상 징후를 포착했습니다. AI는 이미 이미지를 분석했고, 이제 관련 정비 이력과 매뉴얼을 검색한 뒤 원인을 설명하는 답변을 생성해야 합니다. 마지막으로 답변의 형식과 논리를 검증하고, 필요하다면 한 번 더 수정할 수도 있습니다.

문제는 시간이 없습니다.

요청의 deadline까지 남은 시간은 단 10초. 이때 Edge AI 시스템은 무엇을 줄여야 할까요?

• 검색 근거를 8개에서 3개로 줄일까?
• 생성 답변을 768토큰이 아니라 256토큰으로 제한할까?
• 검증 후 수행하는 마지막 재생성을 포기할까?
• 아니면 품질을 유지하려다 deadline을 넘길까?

이 질문은 단순한 모델 성능 문제가 아닙니다. 실제 서비스에서는 “가장 좋은 답변”보다 제시간에 도착하는 충분히 좋은 답변이 더 가치 있을 수 있습니다.

특히 Edge AI 환경에서는 이 문제가 더 날카롭습니다. 클라우드에 보내는 왕복 지연을 피하기 위해 현장에서 추론을 수행하지만, 사용할 수 있는 CPU·메모리·가속기 자원은 제한적입니다. 카메라 분석, 지식 검색, LLM 생성, 결과 검증이 순차적으로 이어지면 각 단계의 작은 지연이 빠르게 누적됩니다.

예를 들어 검색 범위를 넓히면 답변의 근거는 풍부해질 수 있습니다. 그러나 retrieval 시간이 늘어납니다. 생성 토큰 예산을 키우면 설명은 더 상세해질 수 있지만, 생성 지연도 함께 증가합니다. 검증 뒤 refinement를 한 번 더 수행하면 오류를 줄일 가능성은 있지만, 그 한 번의 수정 때문에 전체 SLA를 놓칠 수 있습니다.

SLAFlow가 주목하는 지점이 바로 여기입니다. 이 기술은 “항상 긴 답변을 생성하라”거나 “항상 가장 작은 설정을 쓰라”고 정하지 않습니다. 대신 요청마다 남은 시간, 현재 CPU와 메모리 상태, 대기열 길이, 입력의 불확실성, 단계별 지연시간 profile을 함께 살핍니다. 그리고 deadline 안에 완료할 수 있는 선택지 가운데 예상 품질이 가장 높은 구성을 고릅니다.

핵심은 실행 도중에도 판단을 다시 한다는 점입니다. 초기 답변을 생성하고 검증한 뒤, 시스템은 다음 refinement가 정말 가치 있는지 재계산합니다.

남은 시간 안에 수정할 수 있는가?
수정했을 때 품질이 의미 있게 좋아질 가능성이 있는가?

둘 중 하나라도 아니라면, AI는 과감히 마지막 수정을 포기합니다. 대신 이미 검증을 통과한 가장 최근 결과를 반환합니다.

이러한 판단은 겉으로 보기에는 “품질을 희생하는 일”처럼 보일 수 있습니다. 하지만 deadline을 넘겨 아무 결과도 제공하지 못하는 것보다, 제한된 시간 안에 검증된 결과를 전달하는 편이 훨씬 실용적입니다. Edge AI의 경쟁력은 무조건 더 많이 추론하는 데 있지 않습니다. 주어진 시간 안에서 무엇을 끝까지 수행하고, 무엇을 멈출지 정확히 결정하는 능력에 있습니다.

Edge AI의 세 개의 다이얼: 검색량·토큰·재생성 횟수

검색 근거를 3개에서 8개로 늘리고, 생성 토큰을 256에서 768로 높이고, 답변을 두 번 더 다듬으면 품질은 좋아질 수 있습니다. 하지만 가장 풍부한 설정의 p95 서비스 시간은 370초에 달합니다.

그렇다면 Edge AI 서비스에서 더 많이 추론하는 것이 언제나 더 나은 선택일까요? SLAFlow는 이 질문을 세 개의 조절 다이얼로 풀어냅니다.

다이얼	조절 대상	평가 범위	기대 효과	비용
검색량	Retrieval depth (k)	3, 5, 8	더 많은 근거 확보	검색 지연 증가
생성량	Token budget (T)	256, 512, 768	더 긴 설명·복잡한 응답 생성	LLM 생성 시간 증가
재생성 횟수	Refinement depth (R_{\max})	0, 1, 2	오류 수정 및 형식 개선	검증·재생성 시간 증가

검색량: 근거를 많이 찾을수록 항상 정확할까?

Retrieval depth (k)는 답변 생성 전에 검색할 evidence item의 최대 개수입니다. 예를 들어 (k=3)이면 상위 3개의 근거만 사용하고, (k=8)이면 최대 8개의 문서·지식 항목을 답변에 반영합니다.

검색 결과가 많으면 모델은 더 풍부한 맥락을 참고할 수 있습니다. 의료 지원 서비스라면 관련 사례와 지침을 더 많이 확인할 수 있고, 산업 진단 서비스라면 더 많은 과거 장애 기록을 비교할 수 있습니다.

그러나 검색량을 늘리는 데는 두 가지 비용이 따릅니다.

• 검색 자체에 걸리는 시간이 길어진다.
• 더 많은 근거를 읽고 정리해야 하므로 이후 generation 부담도 커진다.

특히 Edge AI 환경에서는 로컬 저장소, 제한된 메모리, 저전력 CPU 또는 NPU가 병목이 될 수 있습니다. 따라서 “근거가 많을수록 좋다”는 원칙은 deadline이 충분할 때만 성립합니다.

생성 토큰: 더 긴 답변이 더 좋은 답변은 아니다

Generation token budget (T)는 초기 응답 생성에 허용하는 최대 토큰 수입니다. SLAFlow의 평가 범위는 256, 512, 768 token입니다.

토큰 예산이 커지면 모델은 더 자세한 근거 설명, 더 많은 조건 분기, 더 완성도 높은 구조를 담을 수 있습니다. 하지만 생성형 모델에서 토큰 수는 대체로 지연시간 증가와 직접 연결됩니다.

실험에서 token budget을 256에서 768로 확대하자 p95 generation latency는 다음처럼 증가했습니다.

생성 토큰 예산	p95 생성 지연시간
256	74.7초
768	223.2초

즉, 최대 토큰 수를 세 배로 늘리는 선택은 단순히 답변 길이만 늘리는 것이 아닙니다. Edge AI 서비스 전체의 SLA 여유를 크게 소모하는 결정입니다.

짧은 현장 경고문, 설비 이상 알림, 카메라 이벤트 요약처럼 즉시성이 중요한 작업이라면 256 token이 더 합리적일 수 있습니다. 반대로 긴 보고서 초안이나 복잡한 의사결정 지원처럼 수십 초 이상의 지연을 허용할 수 있다면 더 큰 예산이 유효할 수 있습니다.

재생성 횟수: 수정은 품질을 높이지만, 수익은 줄어든다

Refinement depth (R_{\max})는 validation 이후 답변을 다시 고칠 수 있는 최대 횟수입니다. 값이 0이면 초안만 생성하고, 1 또는 2이면 검증 결과에 따라 답변을 한두 차례 수정합니다.

이 과정은 다음과 같은 흐름으로 이해할 수 있습니다.

1. 초기 답변을 생성한다.
2. 형식, 논리, 필수 항목 누락 여부를 검증한다.
3. 문제가 있거나 품질 개선 가능성이 있으면 답변을 수정한다.
4. 남은 시간이 충분하면 다시 검증하고 필요 시 반복한다.

재생성은 유용하지만, 모든 요청에 무조건 적용할 수는 없습니다. 논문 실험에서 refinement 한 번의 p95 latency는 102.3초였습니다. 게다가 refinement의 품질 개선 효과는 반복할수록 작아졌습니다.

단계	평균 sample-wise F1
Perception만 수행	0.600
Initial generation 후	0.719
Refinement 1회 후	0.733
Refinement 2회 후	0.753

초기 generation은 많은 사례에서 의미 있는 개선을 만들지만, 후속 refinement는 추가 비용 대비 이득이 제한될 수 있습니다. 실제로 초기 generation은 35%의 사례에서 개선을 보인 반면, 첫 번째 refinement는 12%, 두 번째 refinement는 10%의 사례에서만 개선을 보였습니다.

세 다이얼은 따로 움직이지 않는다

SLAFlow의 핵심은 검색량, 토큰 예산, 재생성 횟수를 각각 독립적으로 최적화하지 않는다는 점입니다. 세 변수는 하나의 workflow 예산을 나눠 쓰는 관계입니다.

가장 작은 구성은 다음과 같습니다.

[ (k,T,R_{\max})=(3,256,0) ]

이 구성은 근거 3개, 최대 256 token 생성, refinement 없음이라는 의미입니다. Macro-F1은 0.726, p95 service time은 약 80초였습니다.

반면 가장 큰 구성은 다음과 같습니다.

[ (k,T,R_{\max})=(8,768,2) ]

근거 8개를 검색하고, 최대 768 token으로 답변을 만들며, 필요하면 두 번까지 수정합니다. 품질은 가장 높게 나타났지만 p95 service time은 370초에 이르렀습니다.

중간 구성인 ((5,512,1))은 Macro-F1 0.792, p95 service time 226초를 기록했습니다. 따라서 좋은 Edge AI 정책은 언제나 최고 사양을 택하는 방식이 아니라, 요청별 deadline 안에서 가장 높은 품질을 낼 수 있는 조합을 찾는 방식에 가깝습니다.

더 많은 추론은 잠재적으로 더 나은 결과를 만듭니다.
하지만 남은 시간이 없는 순간, 더 많은 추론은 더 나은 답변이 아니라 SLA 위반이 될 수 있습니다.

이 때문에 SLAFlow는 요청마다 남은 시간, 시스템 부하, 입력의 불확실성, 단계별 예상 비용을 확인합니다. 그리고 “지금 이 요청에 검색을 더 할지, 토큰을 늘릴지, 한 번 더 고칠지”를 다시 결정합니다. 이것이 단순한 모델 선택을 넘어선 Edge AI runtime orchestration의 핵심입니다.

Edge AI 실행 중 재계획: 남은 시간으로 다음 단계를 다시 결정하다

처음 세운 실행 계획이 끝까지 유효하다는 보장은 없습니다. 생성 단계가 예상보다 오래 걸리거나, 다른 작업 때문에 CPU 사용률과 대기열이 급증할 수 있기 때문입니다. 특히 제한된 자원에서 동작하는 Edge AI 서비스는 몇 초의 오차가 전체 SLA 위반으로 이어질 수 있습니다.

SLAFlow는 요청을 시작할 때 한 번만 설정을 고르는 방식에 머물지 않습니다. 초기 생성과 validation이 끝난 뒤, “이제 refinement를 한 번 더 수행할 가치가 있는가?”를 다시 계산합니다.

남은 deadline을 기준으로 상태를 다시 읽는다

재평가 시점에서 SLAFlow는 다음 정보를 반영합니다.

• 현재 시각과 요청의 남은 deadline
• 최근 500ms 동안의 CPU·메모리 사용량
• 대기열 길이와 최근 단계별 실행 지연
• 다음 refinement 단계의 예상 실행 비용
• refinement로 기대되는 sample-wise F1 개선량
• 사전에 구축한 플랫폼·모델·지식베이스별 성능 profile

핵심은 단순합니다. 처음에는 여유가 있어 보였더라도, 실제 생성이 길어졌다면 이후 계획을 축소해야 합니다. 반대로 예상보다 빠르게 생성이 끝났고 자원 여유가 있다면, 품질을 높이기 위한 추가 refinement를 검토할 수 있습니다.

“오류가 있으니 다시 생성”은 충분하지 않다

일반적인 workflow라면 validation에서 문제가 발견되었을 때 재생성을 시도할 수 있습니다. 하지만 Edge AI 환경에서는 이 선택이 항상 옳지 않습니다. 재생성 자체가 deadline을 넘기면, 더 나은 답변을 만들려다 아무 결과도 제시간에 전달하지 못할 수 있기 때문입니다.

SLAFlow는 refinement를 수행하기 전에 두 가지 조건을 모두 확인합니다.

1. 예상 refinement 시간이 남은 deadline 안에 들어갈 것
2. 예상 품질 향상이 최소 기준을 넘을 것

논문에서는 예상 sample-wise F1 개선량이 최소 0.005 이상일 때만 refinement를 진행합니다. 즉, 품질 개선 효과가 미미하다면 CPU 시간과 deadline을 소비하면서까지 재생성을 반복하지 않습니다.

이 판단은 다음과 같이 표현할 수 있습니다.

[ \text{Estimated Refinement Cost} \leq

\text{Remaining Deadline}

\text{Safety Margin} ]

여기에 품질 이득 조건까지 만족해야만 다음 단계를 실행합니다. SLAFlow가 단순한 token 제한 정책이 아니라, 실행 경과를 반영하는 runtime orchestration인 이유입니다.

예상과 현실의 차이를 흡수하는 구조

예를 들어 초기 계획이 retrieval 5개, 512 token 생성, refinement 1회였다면 처음에는 1회의 수정까지 가능한 시간 예산이 있다고 판단했을 수 있습니다. 그러나 실제 생성이 길어지고 CPU 부하가 높아지면 refinement의 예상 비용이 남은 시간보다 커질 수 있습니다.

이 경우 SLAFlow는 refinement를 포기하고 현재 결과를 반환합니다. 반대로 생성이 빠르게 끝나고 validation 결과가 개선 가능성을 보여 준다면, 남은 시간 안에서 refinement를 추가할 수 있습니다.

실행 중 상황	SLAFlow의 판단
생성이 예상보다 오래 걸림	refinement 축소 또는 중단
CPU·메모리 부하가 높아짐	보수적인 구성으로 전환
남은 시간이 충분하고 개선 가능성이 큼	refinement 진행
품질 개선 예상치가 낮음	현재 결과 반환
refinement 중 실패 또는 시간 초과	이전의 검증된 결과 반환

마지막 출력보다 중요한 last_valid

실행 중 재계획은 실패 안전성까지 고려합니다. SLAFlow는 가장 최근 생성 결과인 candidate와 validation을 통과한 최신 결과인 last_valid를 분리해 관리합니다.

따라서 refinement가 실패하거나 시간이 초과되더라도, 이전에 유효한 결과가 있다면 이를 반환할 수 있습니다. 무조건 마지막 출력만 내보내는 방식보다 안정적입니다. 제한된 메모리와 불안정한 부하 환경을 가진 Edge AI 서비스에서 특히 중요한 설계입니다.

결국 SLAFlow의 차별점은 “처음에 가장 좋은 계획을 고르는 것”이 아닙니다. 실행 중 현실이 바뀌면, 남은 시간과 예상 품질을 기준으로 다음 행동을 다시 결정하는 것입니다.

품질을 높였지만 deadline은 놓쳤다: Edge AI 숫자가 보여준 역설

SLAFlow의 성과는 분명 인상적입니다. 일반적인 부하인 Nominal workload와 촉박한 SLA 조건에서 SLAFlow는 Deadline-Weighted Quality(DWQ) 0.668, SLA 위반률 2.7%를 기록했습니다. 고정된 작은 설정인 Static-Small은 위반률 0%를 달성했지만, DWQ는 0.610에 그쳤습니다.

이 조건만 보면 결론은 간단해 보입니다. 요청마다 검색량, 생성 토큰, 재생성 횟수를 조절하는 SLAFlow가 품질과 지연시간의 균형을 가장 잘 맞춘다는 것입니다.

하지만 트래픽이 갑자기 몰리는 Bursty workload에서는 이야기가 달라집니다.

정책	DWQ	SLA 위반률
SLAFlow	0.604	11.4%
Static-Small	0.601	1.5%

SLAFlow는 Static-Small보다 DWQ가 0.003 높았습니다. 그러나 그 작은 품질 이득을 위해 SLA 위반률은 1.5%에서 11.4%로 약 7.6배 증가했습니다.

이 숫자는 Edge AI 운영에서 매우 중요한 질문을 던집니다.

품질 점수 0.003을 더 얻기 위해, 열 건 중 한 건 이상이 deadline을 놓치는 선택은 성공일까요?

평균 품질보다 중요한 것은 ‘제시간에 도착한 결과’다

DWQ는 deadline을 넘긴 요청의 품질을 0으로 처리하는 지표입니다. 즉, 출력 자체의 정확도만 보는 것이 아니라 사용자 또는 시스템이 필요한 시간 안에 결과를 받았는지까지 품질에 포함합니다.

그럼에도 bursty workload에서 SLAFlow의 위반률이 높아진 이유는 적응형 정책의 구조적 딜레마와 연결됩니다. SLAFlow는 가능한 범위 안에서 더 높은 품질의 구성을 선택합니다. 예를 들어 더 많은 evidence를 검색하거나, 더 긴 답변을 생성하거나, refinement를 한 번 더 수행할 수 있습니다.

문제는 부하가 급증하면 다음 변수들이 빠르게 변한다는 점입니다.

• 대기열이 짧은 시간 안에 길어진다.
• CPU와 메모리 경쟁이 증가한다.
• 프로파일링으로 예측한 단계별 latency가 실제보다 길어진다.
• 앞선 요청의 지연이 뒤 요청의 남은 deadline을 압박한다.

결국 “현재 시점에서는 가능해 보였던” 고품질 설정이, 실제 실행 과정에서는 deadline을 넘길 수 있습니다. 특히 생성형 워크플로우는 token 생성 시간과 refinement 비용이 길기 때문에, 작은 예측 오차도 전체 서비스 시간의 큰 차이로 이어질 수 있습니다.

고정된 작은 설정이 더 나은 순간

Static-Small은 retrieval depth 3, generation token budget 256, refinement 0회라는 보수적인 구성에 가깝습니다. 최고 품질을 목표로 하지는 않지만, 실행 시간이 비교적 예측 가능하고 자원 사용량도 제한적입니다.

부하가 폭증하는 상황에서는 이 단순함이 강점이 됩니다. 각 요청이 적은 자원을 빠르게 사용하고 끝나므로, 대기열이 연쇄적으로 늘어나는 현상을 줄일 수 있습니다. 그 결과 품질은 약간 낮더라도 SLA 위반률을 1.5% 수준으로 유지했습니다.

이는 SLAFlow가 실패했다는 뜻은 아닙니다. 오히려 Edge AI 정책 설계에서 목적 함수를 명확히 해야 한다는 사실을 보여줍니다.

• 고객 상담이나 현장 지원 도구처럼 답변 품질이 중요한 서비스라면, 약간의 deadline 위반을 감수하고 더 높은 DWQ를 선택할 수 있습니다.
• 산업 제어, 안전 감시, 로보틱스, 자율주행처럼 응답 시점 자체가 안전과 연결되는 서비스라면, 품질을 조금 포기하더라도 위반률 상한을 엄격히 지켜야 합니다.

‘최대 품질’이 아니라 ‘위반률 예산’으로 설계해야 한다

실제 제품 환경에서는 단순히 품질을 최대화하는 정책보다 다음과 같은 제약 조건이 더 현실적입니다.

[ \text{maximize quality} \quad \text{subject to} \quad \text{SLA violation rate} \leq \epsilon ]

여기서 (\epsilon)은 서비스가 허용할 수 있는 위반률입니다. 예를 들어 안전 감시 시스템이 위반률 1% 이하를 요구한다면, SLAFlow는 품질이 높은 configuration을 선택하기 전에 먼저 이 한도를 지킬 수 있는지 판단해야 합니다.

따라서 bursty workload에서 필요한 것은 더 공격적인 품질 선택이 아니라, 다음과 같은 보수적 제어일 수 있습니다.

• 대기열이 일정 수준을 넘으면 retrieval depth와 token budget을 즉시 축소
• 혼잡 구간에서는 refinement를 기본적으로 비활성화
• latency 예측 오차가 커질수록 safety margin 확대
• 시스템 부하에 따라 고품질 모드와 안정성 모드를 명확히 전환
• 최근 SLA 위반률이 임계값을 넘으면 Static-Small과 같은 안전 모드로 fallback

SLAFlow의 가장 흥미로운 결과는 “적응형 정책이 언제나 고정 정책보다 낫다”는 결론이 아닙니다. 오히려 적응성 자체도 안전 제약 안에서 작동해야 한다는 사실입니다. Edge AI에서 좋은 판단은 가장 많은 추론을 수행하는 판단이 아니라, 필요한 품질을 필요한 시간 안에 반복해서 제공하는 판단입니다.

Edge AI, 모델이 아니라 서비스 전체를 최적화하는 다음 단계

SLAFlow가 던지는 진짜 질문은 “어떤 모델을 사용할 것인가?”에서 끝나지 않습니다. 더 현실적인 질문은 이것입니다.

“이 요청에 남은 시간 안에서, 어떤 단계를 어디까지 수행해야 하는가?”

이 질문은 Edge AI 최적화의 단위를 모델 하나에서 서비스 전체 workflow로 바꿉니다. 이제는 작은 모델과 큰 모델 중 하나를 고르는 것만으로 충분하지 않습니다. 검색을 몇 건까지 수행할지, 답변을 몇 토큰까지 생성할지, 검증 후 재생성을 허용할지까지 함께 결정해야 합니다.

예를 들어 현장 의료 보조 서비스가 240초 안에 결과를 반환해야 한다고 가정해 보겠습니다. 시스템은 이미지 분석 후 관련 evidence를 검색하고, LLM이 결과를 생성하며, 형식과 논리를 검증한 뒤 필요하면 수정 답변을 만들 수 있습니다. 그러나 생성과 refinement를 모두 수행하면 deadline을 넘길 수 있습니다.

SLAFlow는 이때 모든 요청에 같은 품질 설정을 강제하지 않습니다.

• 시간이 충분하고 입력 불확실성이 높다면 검색 범위와 token budget을 늘립니다.
• 대기열이 길거나 CPU 사용률이 높다면 더 작은 구성을 선택합니다.
• 초기 결과가 유효하더라도, refinement의 품질 향상이 작거나 시간이 부족하면 재생성을 생략합니다.
• 마지막 refinement가 실패하면 무조건 마지막 출력을 반환하는 대신, 이전에 검증된 last_valid 결과를 보존합니다.

즉, SLAFlow는 “최고 품질의 답변을 만들기 위해 최대한 많은 계산을 수행하는 시스템”이 아닙니다. 정해진 시간 안에서 낼 수 있는 가장 좋은, 그리고 가능한 한 안전한 결과를 선택하는 시스템에 가깝습니다.

모델 선택을 넘어선 서비스 수준의 제어

기존 Edge AI 최적화는 대체로 다음과 같은 선택에 집중했습니다.

• 경량 모델과 대형 모델 중 선택
• CPU, GPU, NPU 자원 배분
• Edge와 cloud 사이의 추론 offloading
• batch 크기 또는 요청 순서 조정

반면 SLAFlow는 하나의 요청 내부에서 발생하는 여러 단계를 동시에 조절합니다.

제어 대상	SLAFlow의 질문
Retrieval	근거 문서를 3개만 찾을까, 8개까지 확장할까?
Generation	256 token으로 짧게 답할까, 768 token까지 허용할까?
Refinement	검증 후 수정 답변을 한 번 또는 두 번 더 만들 가치가 있을까?
Deadline	남은 시간 안에 품질 개선이 실제로 가능한가?

이러한 방식은 특히 생성형 Edge AI 서비스에 적합합니다. 이미지 분류처럼 한 번의 추론으로 끝나는 작업과 달리, RAG 기반 assistant나 현장 진단 시스템은 검색·생성·검증·수정이 연속적으로 연결됩니다. 어느 한 단계만 느려져도 전체 SLA가 깨질 수 있습니다.

SLAFlow는 개별 단계의 평균 latency가 아니라, 요청 전체에 남은 시간을 기준으로 선택을 내린다는 점에서 차별화됩니다.

품질을 높이는 것과 deadline을 지키는 것은 다르다

이 접근이 중요한 이유는 품질이 항상 선형적으로 증가하지 않기 때문입니다. 논문 실험에서 retrieval depth, 생성 token 수, refinement 횟수를 최대로 늘린 구성은 가장 높은 품질을 낼 수 있었지만, p95 서비스 시간은 370초까지 증가했습니다.

반대로 최소 구성인 ((k=3, T=256, R=0))은 p95 약 80초로 훨씬 빠르지만, 품질은 제한됩니다.

특히 refinement는 무조건 실행할수록 좋은 작업이 아닙니다. 초기 생성은 비교적 큰 품질 개선을 만들 수 있지만, 두 번째 수정 단계로 갈수록 개선 폭은 작아집니다. 그런데 refinement 한 번에도 상당한 시간이 필요합니다. 남은 시간이 부족한 상황에서 작은 품질 향상을 위해 재생성을 시도하면, 결과적으로 deadline을 넘겨 전체 서비스 품질이 0으로 평가될 수 있습니다.

그래서 SLAFlow는 refinement를 실행하기 전에 두 가지를 확인합니다.

1. 다음 refinement가 safety margin을 포함한 남은 시간 안에 끝날 수 있는가
2. 예상되는 sample-wise F1 개선이 최소 기준인 0.005 이상인가

이러한 제어는 “invalid이므로 다시 생성한다”는 단순 규칙보다 훨씬 운영 친화적입니다. Edge AI 환경에서는 자원이 제한되고 부하 변동이 크기 때문에, 좋은 결과를 더 만들려는 시도 자체가 서비스 실패로 이어질 수 있기 때문입니다.

그러나 실제 NPU에서도 같은 결과를 낼 수 있을까?

여기서 반드시 짚어야 할 한계가 있습니다. SLAFlow의 가능성은 분명하지만, 현재 평가는 Intel Core i5-4460 기반 CPU 환경에서 이뤄졌습니다. GPU나 실제 임베디드 NPU를 사용하지 않았으며, 단일 FIFO worker와 batch size 1 조건의 prototype 평가입니다.

따라서 다음 질문에는 아직 답이 남아 있습니다.

• Jetson, Hailo, Qualcomm Dragonwing, Raspberry Pi 같은 실제 Edge AI 하드웨어에서도 profile 기반 예측이 정확할까?
• NPU의 컴파일 최적화, 메모리 전송, thermal throttling, 동시 실행 간섭은 latency profile에 어떤 영향을 줄까?
• 모델, runtime, knowledge base가 변경될 때 profile을 얼마나 자주 재구축해야 할까?
• 여러 edge node와 cloud가 함께 동작하는 환경에서도 같은 정책이 안정적으로 작동할까?
• 안전 감시나 산업 제어처럼 violation rate 상한이 엄격한 분야에서, 품질 향상보다 deadline 준수를 우선하도록 정책을 재설계할 수 있을까?

특히 bursty workload에서는 SLAFlow가 Static-Small보다 DWQ를 아주 근소하게 높였지만, SLA 위반률은 더 높게 나타났습니다. 이는 “품질을 조금 더 얻기 위해 deadline 위반을 어디까지 허용할 것인가”라는 제품 정책의 문제를 남깁니다.

결국 SLAFlow의 핵심 가치는 특정 모델이나 특정 하드웨어의 승리를 선언하는 데 있지 않습니다. Edge AI가 발전할수록 중요한 것은 가장 큰 모델을 실행하는 능력이 아니라, 매 순간 제한된 시간·전력·메모리 안에서 서비스 전체를 현명하게 축소하거나 확장하는 능력이라는 점을 보여준 데 있습니다.