[Python] Gradio로 AI 기능 테스트 어플리케이션 구축
그래서 AI 어디까지 개발 되었나요 ?
회사에서 다양한 AI 기능 새롭게 기능을 출시하는 기능이 많아지면서, 출시 해야하는 기능을 테스트 해보고 싶어하는 상황들이 생겼다. 실제 어느정도의 개발 상태인지 확인해보고 싶었고, 단순히 slack 또는 회사 wiki를 통해 확인하는 것이 와닿지 않아 하는 경우들도 있었다.
AI 팀에서는 github README.md를 보거나 source code를 작성하고, 실행하는 것이 어렵지 않기 때문에 나름 괜찮았지만, 다른 팀은 조금더 GUI 형태로 편하게 test 할 수 있는 환경에 대한 니즈가 있었고, 이와 관련해서 gradio라는 라이브러리를 이용하여 test 서버를 구축하게 되었다.
gradio
Gradio is the fastest way to demo your machine learning model with a friendly web interface.
gradio는 선언형으로 빠르게 Web Interface를 빌드할 수 있는 라이브러리이다.
gradio python package를 설치하면, 쉽게 사용할 수 있다.
import gradio as gr
hello_interface = gr.Interface(
fn=say_hello,
inputs=[
gr.Image(label="My Image"),
gr.Text(label="My Name")
],
outputs=[gr.Text()],
title="Hello Printer",
)
Interface는 기본적으로 아래 3개의 paramater fn, inputs, outputs 값을 작성하여 만들 수 있다.
a_interface = gr.Interface(
fn = test,
inputs= gr.Text(),
outputs=gr.Text()
)inputs, outputs에서는 gradio의 component를 이용하여 작성할 수 있다.
gradio에서 제공하는 Component들이 매우 다양하고, 주로 vision 쪽 model 개발을 하면서, gr.Image(), gr.Video()를 사용하고 있다.
그 외에도 AI 관련해서 input, output으로 사용되는 다양한 데이터들을 처리할 수 있는 component를 지원하고 있다.
interface를 선언한 다음 아래 code로 web application을 실행할 수 있다.
a_interface.queue().launch()한 interface를 선언하면 아래와 같이 test를 할 수 있는 페이지가 나타난다.
기능이 여러개로 늘어나면서, 여러개의 페이지를 구성해야 할 때는, 아래와 같이 gr.TabbedInterface 를 활용하여 구현할 수 있다.
demo = gr.TabbedInterface(
[
a_interface,
b_interface,
c_interface
],
[
"A Feature",
"B Feature",
"C Feature"
]
)
demo.queue().launch()처음 gradio를 사용할 때는 tutorial 기반으로 파일을 작성하였고, 팀원과 함께 기능을 배포하다보니 컨벤션이 제대로 정립되지 않은 형태로 개발을 진행했다.
그러다보니 interface와 interface 내에서 기능 로직이 잘 분리되지 않았고, 각각의 input, output과
그러면서 자연스럽게, gradio로 선언하는 interface와 기능 로직을 분리하고 싶어졌다.
우선 UI (Interface) <-> 기능 로직(task)으로 분리를 진행했다.
따라서 interface를 구현한 부분을 packaging하고, 각 interface에서는 task를 호출하는 형태로 구성했다.
tab <-> task <-> service로 Layer 추가 분리.
위와 같은 방법으로 구현했을 때, 훨씬 가독성도 좋아지고 code의 재활용도 가능해지기 시작했다.
하지만 어떠한 기능들 같은 경우에는 같은 model을 사용하여 비즈니스 로직을 작성하는 상황이 있었다.
따라서 model을 단순히 task에만 선언하면서, 같은 model을 반복 호출하게 되는 상황이 존재했다.
memory 관점에서 비효율적인 로직(같은 model을 다른 interface에서 중복호출함)이었고, 따라서 service라는 layer를 하나 더 두고, service에서는 model로 inference하는 코드만 작성하고, 실제 동작하는 비즈니스 로직은 task layer에서, 각 interface에 맞는 UI는 tab layer에 선언하는 형태로 프로젝트를 구성했다.
좋은 소통의 근거
이와 같은 형태로 현재 약 20개 정도의 기능을 test 할 수 있는 서버를 운영하고 있고, AI model 개발 상황이나 model을 활용한 feature들을 기반으로 이후에 팀 내의 회의나 타 팀과의 회의 등에서 소통의 근거로 활용하고 있다.
gradio test 서버 기반으로, develop 되었으면 하는 방향도 제시 받고 있다.
특히 application을 실행하는 launch method에 share라는 option으로 domain을 받아 바로 hosting을 할 수 있는 기능을 지원하고 있다. 간단한 인증 option도 있어서, 데모 시연과 같이 임시적으로 외부에서 사용해야하는 상황들에서도 활용할 수 있는 장점이 있다.
앞으로 해보면 좋을 점 ..
조금 더 자동화할 수 있는 기능들이 추가되면 좋을 것 같다. on-premise CI-CD pipeline 또는 기능이 업데이트 되면 해당 기능을 추출하여, 자동으로 gradio interface를 만드는 방향을 고민해보고 있다. (test 서버이기 때문에, test 서버만을 위한 기능 로직을 최소화 하는 방법에 대해 고민중이다.) 사내 private LLM과 함께 시도해고자 한다.
