🤖
1264 in / 3688 out / 4952 total tokens
오늘은 두 가지가 눈에 띈다. 하나는 Liquid AI가 발표한 대규모 MoE 모델이고, 다른 하나는 AI 엔지니어링을 처음부터 배울 수 있는 깃허브 저장소다. 두 가지 모두 "AI를 어떻게 효율적으로 만들고 배울 것인가"라는 공통된 맥락에서 읽힌다.
🔥 핫 토픽
Liquid AI, 38T 토큰 학습한 8B-A1B MoE 모델 공개
이게 왜 중요한가: Liquid AI가 LFM2-5-8B-A1B라는 MoE(Mixture of Experts) 모델을 발표했다. 총 파라미터 8B, 활성화 파라미터 1B, 학습 데이터 38T 토큰. 이 숫자 조합이 의미하는 바가 꽤 크다.
먼저 MoE 구조를 간단히 설명하면, 모델 내부에 여러 "전문가(Expert)" 네트워크를 두고, 입력에 따라 필요한 전문가만 선택적으로 활성화하는 아키텍처이다. 게임 서버 아키텍처에 비유하면, 모든 플레이어 요청을 하나의 거대한 서버가 처리하는 대신, 로그인 서버, 매치메이킹 서버, 게임플레이 서버 등 역할별로 분리해 필요한 서버만 돌리는 것과 비슷하다. 리소스를 아끼면서도 전체 성능은 유지할 수 있다.
8B 파라미터 중 1B만 활성화된다는 건, 추론 시 실제로 계산에 참여하는 파라미터가 12.5%라는 뜻이다. 이는 엣지 디바이스에서 구동 가능한 사이즈다. 언리얼 엔진으로 치면, 풀 폴리곤 메시 대신 LOD(Level of Detail)를 사용해서 먼 거리에서는 저폴리 모델로 렌더링하는 것과 같은 원리다. 성능은 비슷하게 내면서 비용은 크게 줄일 수 있다.
38T 토큰 학습 데이터도 주목할 만하다. Llama 3.1이 15T 토큰으로 학습한 것과 비교하면 2.5배다. 데이터 양이 많다고 무조건 좋은 건 아니지만, Liquid AI는 데이터 품질과 다양성에 신경 썼다고 강조한다. 이 부분은 실제 벤치마크 결과를 봐야 확인할 수 있겠다.
개발자 관점에서 중요한 이유는, 이런 모델이 실제 상용 서비스에 통합 가능하기 때문이다. 게임 NPC AI, 실시간 콘텐츠 생성, 플레이어 행동 예측 등에 1B 활성화 파라미터 모델은 충분히 실시간 처리가 가능하다. 서버 사이드에서 GPU 한 대로 여러 세션을 처리할 수도 있다.
경쟁 구도에서 보면, Mistral의 Mixtral, DeepSeek-MoE 등과 같은 라인업에 Liquid AI가 합류한 셈이다. 차이점은 Liquid AI가 "Liquid Foundation Models"라는 자체 아키텍처를 사용한다는 점. 트랜스포머 기반이 아닐 가능성도 있지만, 정확한 구조는 논문을 봐야 알 수 있다.
한 가지 우려되는 점은, MoE 모델이 메모리 효율은 좋지만 전체 파라미터를 RAM에 올려야 한다는 것이다. 8B 파라미터면 FP16 기준 약 16GB VRAM이 필요하다. 활성화 파라미터는 1B지만, 나머지 7B도 어딘가에 저장은 해둬야 한다. 게임 클라이언트에 내장하기에는 여전히 무거울 수 있다.
출처: Liquid AI Blog
⭐ 오픈소스
FloatingFlowGod/ai-engineering-from-scratch-915
이게 왜 중요한가: "Learn it. Build it. Ship it for others."라는 슬로건이 마음에 든다. AI 엔지니어링을 처음부터 배우고, 직접 만들고, 남에게 제공할 수 있게 하는 저장소다.
저장소 태그를 보면 agents, ai-agents, ai-engineering, computer-vision가 포함되어 있다. 단순히 LLM API 호출하는 방법을 가르치는 게 아니라, 에이전트 시스템과 컴퓨터 비전까지 아우르는 종합적인 커리큘럼으로 보인다.
이런 저장소가 지금 시점에서 중요한 이유는, AI 분야가 너무 빠르게 변하고 있어서 "어디서부터 시작해야 할지" 모르는 사람이 많기 때문이다. 매일 새로운 모델, 새로운 프레임워크, 새로운 기법이 쏟아진다. 게임 개발도 마찬가지지만, AI는 더 심하다. 체계적인 학습 경로를 제공하는 것은 큰 가치가 있다.
실무 관점에서 특히 유용한 부분은 "Ship it for others" 단계일 것이다. 모델을 학습시키는 것도 중요하지만, 실제 서비스로 만들어 배포하는 건 완전히 다른 문제다. API 서버 구축, 모니터링, 에러 핸들링, 스케일링 등 고려할 게 많다. 게임 서버 개발자로서 이 부분은 특히 공감된다. 좋은 게임 로직이 있다고 서버가 저절로 돌아가진 않는다.
앞서 언급한 Liquid AI 모델과 연결해서 생각하면, 이런 학습 자료는 새로운 모델을 실제 프로젝트에 통합하는 방법을 배우는 데도 도움이 된다. MoE 모델을 어떻게 배포하고, 어떻게 API로 제공하고, 어떻게 클라이언트와 통신할지. 이론과 실습 사이의 간극을 메워주는 역할을 할 수 있다.
아쉬운 점은 저장소가 아직 초기 단계라는 것. Score가 2인 걸 보면 방금 올라온 듯하다. 앞으로 얼마나 내용이 채워질지 지켜봐야 한다. 하지만 방향성은 좋다. "처음부터"라는 접근이 특히 그렇다. 추상화된 라이브러리에 의존하지 않고 원리를 이해하려는 시도는, 장기적으로 더 강한 개발자를 만든다.
💭 연결고리
두 뉴스를 묶어보면 하나의 흐름이 보인다. Liquid AI는 "효율적인 모델 구조"를 제시하고, ai-engineering-from-scratch는 "그런 모델을 다루는 개발자를 양성"한다. 모델이 작아지고 효율적일수록, 더 많은 개발자가 자신의 서비스에 AI를 통합할 수 있다. 그리고 그 개발자들이 필요로 하는 것이 바로 이런 실전 중심의 학습 자료다.
오늘의 한 줄: 모델은 가벼워지고, 진입 장벽은 낮아진다. 남은 건 "뭘 만들 것인가"뿐이다.