Machine Learning

LLM과 Autonomous Agent에 대한 단상

The image is captured from Andrew Ng’s talk: What’s next for AI agentic workflows.

최근에 지인들이 모인 디스코드에서 얘기했던 생각들을 퇴근길에 정리해봤다.

1. LLM에 컴퓨팅과 데이터를 때려넣으면 성능이 올라가는 것에 대해 한계효용 체감이 있을 것이라는 얘기는 계속 있어왔고, 그러한 경쟁조차도 치열한 접전이 되었다. 이번에 GPT-4o의 초점이 달라진 것을 보면 그러한 상황을 반영한 것이 아닌가 싶기도 하다. (이러고나서 GPT-5가 짜잔하고 나올 수도 있지만…)

2. Auto-Regressive LM의 본질 상 planning과 reasoning에 한계로 인해 현재의 기술만으로 singularity는 달성되지 않을 듯하다.

3. 치열한 경쟁으로 인해 LLM weights와 fine tuning 도구들은 commodity가 되었다.

4. 현재 ChatGPT 등은 스마트한 information retrieval 도구이고 엔터프라이즈에서 이러한 일을 대신 해주는 회사들도 많다.

5. 우리의 일을 최소한의 관여로 대신해주는 것에 관한 것은 아직 충분한 성과가 보이지 않는 것 같다.

이러한 상황으로 볼 때는 특정한 영역에 대해 autonomous agent를 구축하는 것에 대해 좀 더 많은 투자가 이루어져야 할 것 같다. 현재의 LLM capability와 실제 세상과 연결하기 위한 복잡다단한 엔지니어링, 요소마다 최적화하기 위한 모델들을 조합하고 제품 다듬기에 충분한 노력을 기울이면, 어떤 영역의 일반 작업들에서는 충분한 매력이 있는 제품을 얻을 수 있을 것 같다.

물론 이러한 생각을 하는 사람들(예를 들어 Andrew Ng의 agentic workflow)과 스타트업들(코딩을 완전 자동화했다는 주장..)은 이미 엄청나게 많을 것으로 예상된다.

이러한 소프트웨어를 빌드해서 실제로 돈을 벌 수 있을지에 대해서는 굉장히 의문스럽고, 아마도 실패할 수도 있고 매우 힘들겠지만, 그래도 빌드하는 과정은 인생을 한번 걸어보고 싶을 정도로 재미있을 것 같기는 하다.

LLM과 Autonomous Agent에 대한 단상 더 읽기"

Talk: DEVIEW 2020 밑바닥부터 만드는 인공지능 서빙 플랫폼

얼마 전 열렸던 DEVIEW 2020의 세션 중 하나인 ‘밑바닥부터 만드는 인공지능 서빙 플랫폼’ 발표를 듣고 그 내용을 요약합니다. 플랫폼 개발의 이유를 명확하게 설명하고 이로부터 이어지는 시스템의 설계 내용이 논리적으로 잘 맞아떨어져서 즐겁게 들을 수 있었던 발표였습니다. 마이크로서비스들의 배포와 서빙을 위한 플랫폼과 머신러닝 배포 및 서빙 플랫폼 사이에 기능적, 기술적으로는 연관관계가 많이 있는 반면에, 둘 사이에 사용자, 환경, 작업 흐름의 차이 때문에 현실적으로는 머신러닝에 국한된 프로덕트가 필요하다는 생각을 가지게 되었습니다.


  • 시작
    • 2019년 초 weight 파일 + 인퍼런스 코드 + flask 서버로 서빙 시작
    • 지금은 각 모듈을 공통화
  • 모델 공통화 동기
    • 모델 수 증가 -> 서빙을 위한 엔지니어링 코스트 증가
    • 지속적인 모델 학습과 배포: A/B 테스트, 로그를 저장하고 이를 통한 학습
    • 사내시스템 연동: 유지보수가 잘 안되는 코드
    • 협업 가능한 환경 구축: 엔지니어가 모델러로부터 받은 인퍼런스 코드를 재작성하는 엔지니어링 코스트. 모델러와 엔지니어의 관심사에 따라 분리.
    • 공통화 요소
      • 게이트웨이
        • 인증, 레이트리미트, 로깅, 트래픽 관리, 비동기 처리
      • 인퍼런스를 위한 공통 라이브러리 (SDK)
        • 모델러 등의 협업 인터페이스 정의
        • http, grpc 라이브러리 제공
        • 모델 디스커버리, 로깅, 헬스체크 고려 (?)
      • 이종의 환경을 디플로이하기 위한 시스템
        • 이종의 환경을 디플로이하기 위한 단일한 인터페이스
  • MDS: 공통 모델 패키징
    • 요구사항
      • ML 프레임워크 – 텐서플로, PyTorch -> 베이스 이미지 제공
      • REST API -> Decorator/Flask
      • CPU/GPU 환경 -> GPU 환경을 위한 operator, 배치 처리 기능 추가
      • 종속성/배포 문제로 인해 Docker -> 모든 배포에 Docker 사용
    • 모델 서빙 클래스: 전처리, 인퍼런스, 후처리 코드를 decorator로 지정
    • 모델 서빙 클래스 + 모델 파일로 이루어진 모델 패키지를 생성
    • mds는 모델 패키지의 서빙 클래스를 flask와 연동하여 서빙
    • 배치 인퍼런스: 여러 리퀘스트를 한꺼번에 처리
    • 멀티 모델 파이프라인
  • DPLO: 공통 모델 배포
    • 요구사항
      • CPU/GPU 클러스터 -> 사내 주요 클러스터 오퍼레이터 구현
      • 배포 단계 제어 및 이력 관리 -> 선언적 배포 구성 파일
      • 라우팅 자동화 -> 엔드포인트 자동 등록
    • 모델 패키지를 S3에 업로드하고 DPLO에 배포 요청
    • DPLO는 패키지를 다운로드 받아서 이미지를 빌드하고 Docker Registry에 업로드
    • 요청 받은 클러스터로 배포
      • k8s 오퍼레이터 (NCC 클러스터 – 네이버 사내 컨테이너 클러스터), C3DL 오퍼레이터 (C3DL 클러스터 – 네이버 사내 딥러닝 플랫폼)
    • 클러스터의 엔드포인트 정보를 얻어 AIGW의 라우팅 정보를 업데이트
    • 기술
      • golang으로 작성
      • gRPC API 및 gRPC gateway로 REST API 노출
      • 배포 요청은 protobuf로 정의
    • 선언 파일을 통한 배포
      • Git을 통한 배포 제어 및 관리
      • 배포 상태와 배포 선언 파일 사이의 변경 관리
    • 동적 엔드포인트 디스커버리
      • 새로운 인스턴스 배포/기존 인스턴스 재시작에 따른 엔드포인트 정보 업데이트
      • MDS는 Route provider (Consul)에 라우트 정보를 등록, AIGW는 Route provider로부터 엔드포인트 업데이트
  • AIGW: 공통 모델 라우팅
    • nginx, istio 대신 직접 개발
    • 라우팅 scheme: project/model/version
      • project: 서비스, model: ML 기능, version: 버전
      • 버전 사이에서는 weighted round robin, 하나의 버전 내에서는 round robin
    • 요청 미러링 기능
      • 서비스 중인 모델의 요청을 복제해서 신규 모델에 요청 실행 가능
    • 가중치 기반 라우팅
      • 카나리 배포, A/B 테스트를 위한 버전간 가중치 라우팅
    • 로그 유통
      • 기본적인 메트릭 전송
      • anomaly detection
      • 사내 로그 저장/분석 플랫폼 활용
      • 로그 시각화
        • 미러링된 요청 구분 가능
    • 모델 서빙 모니터링
      • 모델 서버의 작동 여부
      • 쓰루풋, 응답 코드, latency, connection 수 등의 메트릭 모니터링

Talk: DEVIEW 2020 밑바닥부터 만드는 인공지능 서빙 플랫폼 더 읽기"