ONNX Runtime으로 시작하는 C++ 머신러닝

발표자: 박문식(이스트소프트 유틸리티 개발팀)

기존의 머신러닝 모델 개발 및 배포 환경

• 고성능 서버 머신
• Python
• GPU 가속 사용
• PyTorch, Tensorflow 등의 머신러닝 프레임워크

왜? 이렇게 정형화 되었는가?

• 예전에는 CPU를 사용
• 때문에 연산 처리에 한계가 존재
• GPU의 등장으로 상황이 변하게 됨
  • 간단한 연산들을 병렬적으로 계산
  • 쿠다가 없었을 때, 그래픽 API만 노출되었기 때문에 쉐이더로 계산함

현재 하나의 패러다임이 추가됨

• (ML Model) Interface at the edge
• 기술이 발전함에 따라 머신러닝 모델들의 연산 요구량은 낮아졌고 정확도는 증가됨
• 엣지 디바이스의 연산 능력 향상, 전력 낮아짐
• 엣지 디바이스에서 모델을 돌리면 응답 속도, 보안성 강화
• 때문에 고성능 서버에서만 돌아가는 시절은 아니다. 클라이언트에서도 사용할 수 있게 됨

엣지 디바이스 특성

• 우리가 관리하는 디바이스가 아니기 때문에 호환성 문제가 발생
  • CPU, GPU, 메모리 속도와 용량 등을 다 따져봐야 함
  • 휴대용 엣지 디바이스의 경우, 배터리 문제가 추가됨
  • 결국 연산 요구량이 적은 머신러닝 모델을 돌려야함

C++ 머신러닝 플랫폼

• libtorch
  • PyTorch 모델만 돌릴 수 있음
  • 바이너리 사이즈가 큼
  • 실제 모델에서 사용하기에는 아직 무리
• ggml
  • OpenAI Whisper(Speech to Text) -> whisper.cpp
  • Meta LLaMA -> llam.cpp
  • CPU에서 잘 돌아갈 수 있음(단, GPU만큼의 성능이 나온다고 볼 수 없음)
  • 유명 모델만 최적화가 들어가기 때문에 개발자가 추가적으로 최적화를 해야함

ONNX(Open Neural Network Excange)

• ONNX
  • MS에서 만듬
  • .NET과 Java와 같이 중간 언어라는 개념을 도입해서 만든 머신러닝 모델을 표준화하기 위해 제안된 규격
  • MS에서 만들었기 때문에 Windows 지원이 뛰어남
  • iOS, macOS, Linux, Android, Web도 지원
  • 많은 하드웨어 가속을 지원
  • 오픈 소스
• 특징
  • 플랫폼에 종속적이지 않음
  • 환경에 종속적이지 않아 ONNX Runtime이 지원하는 모든 환경에서 ONNX로 만들어진 모델을 돌릴 수 있음
  • 런타임 바이너리 크기가 작음 = 쉽게 배포 가능
  • 특정 연산에 대해 특정 환경에서 제공하는 다양한 최적화 모델 수정 없이 활용할 수 있음

실습

• github: microsoft/onnxruntime
• MNIST: ONNX에서 사용되는 머신러닝 필수 구조체
• tensor: ML에서 사용되는 추상화된? 행렬

QnA

Q1. 디바이스의 CPU에서만 돌아가는 것을 전제로 깔았는가?

A1. GPU는 환경 문제가 크기 때문에 CPU를 전제로 깔았다.

Q2. PyTorch, Tensorflow를 ONXX로 변경하기 위해서 따로 공부해야 하는가?

A2. ONNX에서 ONNX로 변경하는 기능을 제공하므로 굳이 공부할 필요는 없다. 
단, ONNX에서 아직 제공하지 못하는 일부 기능들이 있기 때문에 완벽하게 변경된다고 확신할 수 없다.

D3D12 Mesh Shader 소개

발표자: 유영천

프로젝트의 운명을 좌우하는 레서기 코드

발표자: 정민우

DBMS의 특징

• 매우 긴 소프트웨어의 수명
• 많은 개발자들이 참여
• 많은 개발자들이 퇴사...
• 고객사들의 변화에 매우 민감
• 회사의 지출 대부분이 유지 보수

레거시 코드란?

• 테스트 코드가 없는 코드
• 바꾸기 힘든 코드
• 정체를 알아볼 수 없는 코드
  -> 함부로 건들이지 못함

레거시 코드
Naming Issues

• 예시
  • 무책임한 이름
  • 약어의 남용
    • MInfo
    • 이름만으로는 어떤 역할인지 알 수가 없음...
    • 정답은 메인 정보를 담는 변수
  • 너무 일반적인 이름
    • 너무 범용적인 이름이라면 오히려 정확히 어떤 역할을 하는지 알 수 없음
    • 서로 구분하기 힘든 이름
      • 암시적인 규칙에 의한 함수 이름과 비슷한 작동을 하는 이름의 함수
• 좋지 않은 이름의 피해
  • 코드 구성 요소간의 역할 구분이 어려움
  • 코드를 이해하는 시간 증가
• 해결책
  • 이름 짓는 것에 조금 더 성의 있게...
  • 동료와 충분한 커뮤니케이션
    • 성의 있는 커밋 메시지
    • 코드 리뷰 시간
    • 문서화

함수

• 예시
  • 너무 많은 파라미터
    • 비슷한 동작을 하는 A, B 상황
    • 플래그를 이용해서 분기 적용
  • 전역 변수 사용
    • 유지.보수에서 최악
    • 함수 재사용이 까다로움
    • 함수를 바꾸기 어려워짐
    • 디버깅이 힘들어짐
    • 컴파일 시간 증가
• 해결책
  • 너무 많은 파라미터
  • 흠..
  • 당장의 쉬운 구현은 절대 정답이 아님
  • 이해하기 쉬운 함수를 작성했는지 항상 생각해야 함
  • 테스트 코드
  • 코드 리뷰 시간

지식의 중복

• 지식의 중복: 하나의 변수를 변경했을 때, 다른 변수까지 변경해야하는 것
• 왜 문제인가?
  • 문제 발생시, 디버깅이 너무 어려워짐
  • 여러 데이터간 정합성이 맞지 않아 에러...
• 해결책
  • Attribute를 Getter로 대체
• 교훈
  • 데이터 간 지식의 중복은 무조건 잊혀지기 마련
  • 지식의 중복은 반드시 피하거나 감춰야 함

직접 겪은 레거시 코드...

• 막대한 레거시 코드
• 고객사가 증가할 수록 유지.보수 비용 증가
• 95% 이상의 종사자들의 업무가 유지.보수
• 발전이 정체된 소프트웨어
• 업무 만족도 저하 -> 잦은 퇴사 -> 기존의 직원 업무 질 저하 -> 반복

해결책

• 바꾸기 쉬운 코드인지 항상 생각하자
• 좋은 개발 문화
  • 테스트 코드
  • 코드 리뷰
  • 문서화
  • 활발한 커뮤니케이션
• 주기적인 리팩토링
  • 기업 입장에서는 돈이 되지 않지만 유지.보수에는 매우 좋음

QnA

Q1. 가장 길었던 함수나 파일

A1. gdd를 많이 사용, 만줄이 넘어가는 파일 존재, 조금만 만져도 컴파일 시간이 너무 늘어난다.

Q2.
* 패키지 형태로 오랫동안 유지.보수하는 회사가 적은거 같다.
* 함수명, 변수명을 잘했으면 좋겠다고 생각을하지만 그러면 이름이 너무 길어진다.
* 문서화하는 것은 좋다 하지만, 현실의 괴리감이 자주 발생하게 된다(코드와 문서와 동기화 안됨).

A2-1.
* 너무 긴 것도 않좋다고 생각한다. 그래서 코드 리뷰를 통해 적절한 이름을 찾는 것도 한 방법이라 생각한다
* 모든 코드의 문서화 보단 핵심 부분(약어 규칙, 명명 규칙 등)을 정해, 다른 문서가 필요 없게...

A2-2. 다른 분의 답변
* 변수/함수명이 길어졌다면 코드 리팩토링을 해야 할 신호라고 생각
* 주석, 커밋 메시지를 현재와 미래의 팀원 뿐만 아니라 미래의 내가 봤을 때도 알아 볼 수 있게 작성해야 한다(경험담...).

Q3. 특별한 개발 문호가 존재하는가?

A3. 특출난 것은 없고 코드 리뷰 시간을 최대한 갖으려고 한다. 하지만 윗 분들은 잘 이해하지 못해서 아쉽다. 
책은 이상적이지만 그래도 배울 것이 많기 때문에 많이 읽어보려고 한다.

Q4. 우리 회사 같은 경우, Wrapping을 하고 구분이 더 힘들어 졌다.

A1. 제대로 못들음...

Q5. 코드 리뷰, 현업이 궁금하다. 참석자 모두가 리뷰하는가? 또는 몇 명만 하는가?

A5. 코드에 따라 다르다. 간단한 것은 몇 명만 집중적으로, 핵심적인 코드는 참석자 모두가 인지해야하기 때문에 모두 참여한다.
우리는 코드 리뷰 시간을 따로 할당해서 정식적으로 부정적인 생각 없이 참여하게 만들었다.