1편에서는 AI 에이전트가 왜 기존 서빙 시스템의 가정을 무너뜨리는 '프로그램형 워크로드'인지, 그리고 세계 최고 시스템 학회들이 이 문제를 어떻게 다루고 있는지 살펴봤습니다. CacheBlend 사례에서 확인했듯, 그 답의 상당 부분은 GPU 메모리 바깥의 자원, 즉 소비자용 PC가 가진 DRAM과 SSD를 어떻게 활용하느냐에 달려 있었습니다. 이제 비용 이야기로 돌아와, 그 흐름이 왜 "소비자용 GPU 클라우드"라는 그림으로 수렴하는지 이어가 보겠습니다. 4. 그 많은 호출, 전부 초거대 모델이어야 할까: SLM이라는 답 NVIDIA Research는 지난해 "Small Language Models are the Future of Agentic AI"라는 도발적인 제목의 논문을 내놓았습니다 [1]. 요지는 이렇습니다. 에이전트 루프에서 실제로 발생하는 일의 상당수는 검색 결과 요약, tool 호출용 JSON 생성, 문서에서 정형 필드 추출,

안녕하세요. AIEEV 개발팀에서 AI 인프라 연구개발을 담당하고 있는 조용래입니다. 분산 시스템 성능 확장성 및 신뢰성을 주제로 컴퓨터 공학과 박사 학위를 받았으며, 지금은 Air Cloud 위에서 LLM 서빙의 효율과 신뢰성, 그리고 AI 에이전트 기술 연구개발에 관심을 두고 일하고 있습니다. AI 에이전트처럼 한 번의 요청에 모델을 수십, 수백 번씩 호출하는 서비스가 늘어날수록, 추론 비용 청구서는 예상보다 훨씬 빠르게 불어납니다. 회사에서 에이전트 기능을 붙여 보신 분이라면 한 번쯤 겪어보셨을 겁니다. AIEEV가 줄곧 붙들고 있는 문제의식도 바로 여기서 출발합니다. 이 글은 그 문제를 연구자의 시선으로 끝까지 파고든 기록입니다. 2부로 나눠, 1편에서는 AI 에이전트가 서빙 인프라에 던지는 도전이 무엇인지 세계 최고 시스템 학회들의 최신 연구로 짚어보고, 2편에서는 그 흐름이 왜 "아주 많은 소비자용 GPU 위에서 돌아가는 작은 모델들"

유휴 GPU를 API Capacity로 바꾸는 Distributed GPU Cloud 이야기, 그리고 Ray 💡 핵심 메시지 "아무리 좋은 GPU도 API로 전환되지 않으면 가치가 없습니다." Aircloud는 인프라 하드웨어가 실제 서비스 레이어로 도달할 수 있도록 런타임부터 플랫폼 계층까지의 모든 파이프라인을 연결합니다. 들어가며 요즘 AI 인프라를 이야기하면 가장 먼저 나오는 키워드는 GPU shortage입니다. H100을 얼마나 확보했는지, B200 수급은 어떤지, 데이터센터 전력은 충분한지 같은 이야기가 자연스럽게 따라옵니다. 하지만 실제 서비스를 만들고 운영하다 보면, 문제는 단순히 “GPU가 부족하다”에서 끝나지 않습니다. GPU가 부족한 것도 맞지만, 동시에 이미 존재하는 GPU가 항상 잘 활용되고 있는 것도 아닙니다. 어떤 GPU는 요청이 몰려 과부하 상태이고, 어떤 GPU는 비어 있습니다. 평균 GPU utilization은

안녕하세요. AIEEV Dev Team의 김진범입니다. 저는 학부와 대학원에서 컴퓨터공학을 전공하고 AIEEV 창업 초기부터 함께하며 Air Cloud에 더 많은 분산 자원이 효율적으로 운영될 수 있도록 기여하고 있습니다 연구생 시절에는 AI 서비스의 성능 향상을 위한 이론적 연구와 실험을 많이 진행했습니다. 하지만 실제 서비스를 운영하다 보니, 좋은 모델과 높은 성능만으로는 충분하지 않다는 것을 알게 되었으며, 중요한 것은 AI 서비스를 사용자가 실제로 사용할 수 있을 만큼 빠르고, 비용 측면에서도 지속 가능하며, 안정적으로 제공할 수 있느냐였습니다. 저희 팀도 분산 GPU 환경에서 서비스를 운영하며 이 문제를 계속 마주해왔습니다. 더 큰 모델을 안정적으로 배포하고, 더 많은 요청을 처리하면서도 응답 지연시간을 일정하게 유지하려면 추론 단계의 최적화가 필요합니다. 모델 크기가 커질수록 GPU 메모리 사용량은 자연스럽게 증가합니다. 여기에 긴 시스

AirCloud의 4월 릴리스는 AI 워크로드를 더 빠르게 실행하고, 더 안정적으로 운영하며, 보유 GPU 자원까지 유연하게 활용할 수 있도록 하는 데 초점을 맞췄습니다. 이번 업데이트에는 Air Container 운영 기능 강화, Air API 정식 GA, Resource Provider, RP 지원, 그리고 지능형 스케줄러 도입이 포함됩니다. 개발자는 컨테이너 접속과 로그 확인, 오류 대응, API 연동을 더 간단하게 처리할 수 있고, 기업·기관·GPU 보유 사업자는 보유 GPU 자원을 AirCloud 리소스 풀에 연결해 더 유연하게 활용할 수 있습니다. 1. Air Container 기능 보강 AI 워크로드를 운영할 때 가장 자주 필요한 작업은 컨테이너에 접속하고, 로그를 확인하고, 문제 상황을 빠르게 파악하는 것입니다. 이번 릴리스에서는 Air Container의 접속성, 운영 가시성, 제어 편의성을 전반적으로 개선했습니다. SSH 접속 지

안녕하세요, 개발팀에서 DevOps/SRE를 담당하고 있는 이창윤입니다. 최근 Air API 출시와 함께 저희 팀은 인프라 모니터링 체계를 구축하고 있습니다. 이번 글에서는 그 과정에서 개발한 OpenClaw 플러그인을 소개하려고 합니다 🙂 시작하기 전에 OpenClaw를 한동안 써본 분이라면 한 번쯤 이런 상황을 겪어보셨을 겁니다. 외부 모델 프로바이더를 연결하려는 순간, 설정 메뉴를 뒤적이고 Base URL을 복사-붙여넣기 하고 사용할 모델마다 엔드포인트를 손으로 하나씩 등록하는 그 과정을요. 하다보면 동작은 하는데, 세팅이 유쾌하지는 않습니다. 이 글에서는 저희 팀이 개발한 플러그인을 통해 plugins install 명령어 하나가 이 모든 반복을 어떻게 없애는지를 소개해보도록 하겠습니다. 그리고 그 뒤에서는 실제로 무슨 코드가 돌아가는지까지도 함께 들여다보겠습니다. 기존 방식: Custom Provider, 모델마다 반복 아래 그림처럼,