slack2026년 5월 28일

Slack AI: 멀티 클라우드로 가는 길 (새 탭에서 열림)

Slack AI는 초기 SageMaker 기반 운영에서 출발해 Amazon Bedrock으로 이전하며, 수동적인 GPU·용량 관리에서 관리형·다중 클라우드 오케스트레이션으로 발전했다. 이 과정의 목표는 단순히 최신 LLM을 도입하는 것이 아니라, GPU 부족과 지역 장애에도 견디면서 엔터프라이즈 수준의 보안·성능·신뢰성을 유지하는 것이었다. 특히 부하 테스트, 품질 비교, 점진적 트래픽 전환을 통해 고객 영향 없이 마이그레이션을 완료한 점이 핵심이다. ## SageMaker 기반 초기 아키텍처 - 2023년 초 Slack은 AWS SageMaker를 LLM 서빙의 출발점으로 선택했다. - SageMaker는 다음 요구사항을 충족했다. - 보안성과 FedRAMP 준수 - 모델 가용성과 제어권 - Escrow VPC를 활용한 제로 지식 환경 - Slack의 데이터는 외부에 노출되지 않았고, 모델 제공업체의 비공개 가중치에도 Slack이 접근할 수 없었다. - 글로벌 가용성을 위해 여러 AWS 리전에 컨테이너를 배포했다. - 운영팀은 리전 간 IAM 역할, 모델 엔드포인트 라우팅, 용량 계획, 자동 확장을 직접 관리해야 했다. ## 자체 운영에서 발생한 비용 - **확장 지연** - 인스턴스 초기화 시간이 길어 즉각적인 확장이 어려웠다. - **GPU 부족** - A100, H100 같은 고성능 NVIDIA GPU를 필요한 시점에 확보하기 어려웠다. - **과잉 프로비저닝** - 피크 시간대 SLA를 맞추기 위해 유휴 리소스를 미리 확보해야 했다. - 2024년 초에는 On-Demand Capacity Reservations와 cron 기반 사전 확장으로 문제를 완화했지만, 엔지니어링 리소스가 인프라 조정 업무에 과도하게 투입됐다. - 결국 Slack은 수동 조정이 아니라 자동화된 용량 확보가 필요하다고 판단했다. ## SageMaker의 모델 출시 지연 - AWS가 관리형 LLM 서비스인 Bedrock을 우선적으로 발전시키면서, SageMaker 기반 커스텀 서빙 환경은 최신 모델 도입에서 뒤처지기 시작했다. - Escrow VPC에서 Anthropic 모델을 호스팅하는 방식은 Bedrock보다 모델 업데이트와 최적화 적용이 수주에서 수개월 늦었다. - AI 기능 품질이 경쟁력과 직결되는 Slack에는 이러한 지연이 큰 문제가 됐다. ## Amazon Bedrock으로의 전환 - 2024년 중반 Slack은 FedRAMP Moderate 인증과 필요한 보안 수준을 갖춘 Bedrock으로 이전했다. - 전환의 주요 이점은 다음과 같다. - 개별 GPU 인스턴스와 엔드포인트를 직접 확장하지 않아도 되는 운영 단순화 - 최신 모델을 공개 직후 빠르게 사용 가능 - 사용 패턴에 따른 비용·용량 최적화 - 예측 가능하고 지연 시간에 민감한 채널 요약에는 **Provisioned Throughput(PT)**를 사용했다. - 간헐적이고 예약 실행되는 Recap 작업에는 **On-Demand(OD)**를 사용해 유휴 용량 비용을 줄였다. ## Model Unit 기반 용량 관리 - Bedrock의 용량은 GPU 인스턴스가 아니라 **Model Unit(MU)**로 측정된다. - 각 MU는 분당 토큰 수로 표현되는 일정한 처리량을 제공한다. - Slack은 하드웨어 세부사항 대신 필요한 토큰 처리량에 집중할 수 있게 됐다. - 마이그레이션 위험을 줄이기 위해 먼저 Provisioned Throughput 환경을 이전하고, On-Demand 환경은 후속 단계로 진행했다. ## 무중단 마이그레이션 전략 - **규정 준수 검토** - Legal, Security, FedRAMP 승인을 받은 뒤 운영 트래픽을 전환했다. - **용량 검증** - 다양한 트래픽 패턴에서 SageMaker와 동일한 성능을 내는 MU 수를 부하 테스트로 산정했다. - **품질 비교** - A/B 테스트와 평가 프레임워크로 모델 출력 품질과 지연 시간을 나란히 비교했다. - **점진적 롤아웃** - 기능 플래그를 사용해 트래픽을 단계적으로 이동했다. - 문제가 발생하면 즉시 이전 환경으로 롤백할 수 있도록 구성했다. - 대규모 부하 테스트와 shadow request를 통해 기존 환경과의 성능 패리티를 확인했고, 고객에게 영향을 주는 장애 없이 전환을 완료했다. ## Bedrock 도입 이후의 운영 개선 - 엔지니어들은 GPU 수명주기, 엔드포인트 관리, 용량 예약 대신 모델 성능과 기능 품질에 집중할 수 있게 됐다. - 최신 모델을 더 빨리 적용하면서 AI Search에 고도화된 추론 모델을 신속히 도입했고, 더 정교하고 맥락에 맞는 답변을 제공할 수 있었다. - 인프라 운영은 다음과 같이 단순화됐다. - Slack이 필요한 quota를 요청 - AWS가 MU를 프로비저닝 - Slack이 해당 용량으로 트래픽을 처리 - 수요가 발생한 뒤 대응하는 방식에서, 몇 주 앞을 내다보고 용량을 예약하는 전략적 예측 방식으로 전환했다. - Slack이 강조한 운영 원칙은 **먼저 측정하고, 점진적으로 이전하며, 지속적으로 모니터링하는 것**이다. ## 남은 효율성 문제 - Provisioned Throughput은 안정적이고 예측 가능한 워크로드에는 효과적이었지만 모든 트래픽에 최적은 아니었다. - 미국 동부·서부 지역의 업무 시작 시간처럼 특정 시간대에 AI 요약과 검색 요청이 급증하는 패턴을 처리하려면 높은 MU 기본 용량을 유지해야 했다. - 그 결과 피크 시간대 성능을 보장하는 대신, 사용량이 낮은 시간에는 일부 용량이 유휴 상태로 남는 과잉 프로비저닝 문제가 여전히 존재했다. ## 실용적인 결론 LLM 인프라를 확장할 때는 직접 GPU를 운영하는 것보다 관리형 서비스가 모델 접근성과 운영 효율을 크게 높일 수 있다. 다만 서비스 이전은 단순한 엔드포인트 교체가 아니라, 부하·품질·규정 준수 검증과 점진적 롤백 체계를 포함한 통제된 마이그레이션으로 진행해야 한다.

gpullmmodel-servingaws-bedrock+3

meta2026년 5월 26일

SilverTorch: 모델로서의 인덱스 — 추천 시스템을 위한 새로운 검색 패러다임 (새 탭에서 열림)

SilverTorch는 추천 시스템의 검색(retrieval) 단계를 여러 마이크로서비스가 아닌 하나의 통합 신경망으로 재설계한 아키텍처다. ‘Index as Model’ 패러다임을 통해 사용자 임베딩, ANN 검색, 적격성 필터링, 재순위화와 다중 작업 점수화를 하나의 PyTorch 모델에서 처리한다. 그 결과 기존 방식보다 최대 23.7배 높은 처리량과 20.9배 높은 컴퓨팅 비용 효율을 달성하면서도 추천 품질을 개선하고, 100ms 이하의 지연시간 제약을 유지할 수 있다고 설명한다. ## 기존 마이크로서비스 기반 검색의 한계 - 전통적인 추천 검색 시스템은 다음과 같은 서비스 조합으로 구성된다. - 사용자 타워 모델: 사용자의 관심사를 벡터인 사용자 임베딩으로 변환 - 후보 검색·필터링 서비스: 사용자 벡터와 유사한 콘텐츠를 찾고 언어·지역·정책 등을 기준으로 필터링 - 점수화 서비스: 남은 후보의 참여 가능성을 계산하고 순위를 조정 - 오케스트레이터: 각 서비스에 요청을 분산하고 결과를 통합 - 서비스 간 네트워크 왕복과 데이터 직렬화 과정이 100ms 이하의 검색 지연시간을 소모한다. - 사용자 모델, 아이템 인덱스, 필터링 규칙이 서로 다른 시점에 배포되어 버전이 불일치할 수 있다. - 예를 들어 사용자 모델은 v2인데 아이템 인덱스가 v1이면 서로 다른 버전의 임베딩이 비교된다. - ML 엔지니어는 주로 PyTorch를, 인프라 엔지니어는 C++를 사용해 개발 환경과 배포 주기가 분리된다. - Faiss-GPU와 같은 개별 최적화는 특정 서비스만 빠르게 만들 뿐, 서비스 간 데이터 이동과 독립적인 실행 구조라는 근본 문제는 해결하지 못한다. ## Index as Model: 인덱스를 모델 안으로 통합 - SilverTorch는 아이템 인덱스 자체를 모델 내부의 텐서로 표현한다. - 사용자 타워, ANN 검색, 적격성 필터, 점수화 계층을 모두 하나의 PyTorch 신경망에 포함한다. - 사용자의 요청은 단일 모델의 한 번의 forward pass를 거치며 다음 작업을 수행한다. - 사용자 관심사와 유사한 콘텐츠 검색 - 언어·국가·콘텐츠 정책 등에 따른 노출 가능 여부 확인 - 후보 재순위화 - 좋아요·공유·댓글 등 여러 참여 행동의 확률 예측 - 여러 예측값을 결합한 최종 점수 계산 - 하나의 모델 아티팩트와 단일 실행 경로를 사용하므로 구성 요소 간 공동 최적화와 일관된 버전 관리가 가능하다. - 모델 복잡도와 평가 후보 수를 늘리면서도 100ms 이하의 응답시간을 유지하는 것을 목표로 한다. ## 모델 내부의 검색·필터링·재순위화 - ANN 검색 영역은 전체 카탈로그를 모두 확인하지 않고 사용자와 가까운 아이템을 빠르게 찾는다. - 적격성 필터링 영역은 후보가 사용자에게 노출 가능한지 검사한다. - 언어 - 국가 및 지역 - 콘텐츠 정책 - 기타 서비스별 자격 조건 - 다중 작업 재순위화 영역은 여러 참여 행동을 동시에 예측한다. - 좋아요 - 공유 - 댓글 - 예측 결과를 종합해 참여 가능성이 높은 후보를 계산한다. - 일부 연산은 엔지니어가 직접 작성하고, 일부는 역전파를 통해 종단 간 학습할 수 있다. - 런타임에서는 모든 구성 요소가 동일한 `nn.Module`로 취급되므로 검색 모듈과 학습된 재순위화 모델을 자유롭게 조합할 수 있다. ## 모든 단계를 순수 PyTorch 모듈로 재구현 - 기존 ANN 검색, Bloom 인덱스 필터, 신경망 재순위화, 복합 점수화는 주로 독립적인 C++ 서비스로 구현되어 있었다. - 이러한 구현은 안정적이지만 각자 별도의 메모리·자료구조·실행 모델을 사용해 모듈 간 공동 최적화가 어렵다. - SilverTorch는 모든 데이터를 텐서로 표현하고, 모든 로직을 텐서 입력과 텐서 출력으로 통일한다. - 각 구성 요소는 PyTorch의 표준 `nn.Module` 인터페이스를 따른다. - 이를 통해 다음과 같은 최적화가 가능해진다. - 유망한 클러스터를 먼저 선택 - 선택된 클러스터 안에서만 필터링 - 필터를 통과한 후보만 점수화 - ML 엔지니어와 인프라 엔지니어가 서로 다른 계층에서 작업하는 대신 동일한 실행·개발 계층에서 모듈을 구성하고 최적화할 수 있다. ## 성능과 확장성 - 8천만 개 아이템을 대상으로 한 종단 간 평가에서 기존의 강력한 다중 서비스 기준선보다 초당 요청 처리량이 최대 23.7배 높았다. - CPU 기반 솔루션보다 추정 총소유비용(TCO) 효율이 20.9배 개선되었다. - 피드와 동영상 콘텐츠를 제공하는 여러 애플리케이션 제품군에 적용 가능한 규모 확장성을 보였다고 설명한다. - 신경망 재순위화와 다중 작업 점수화를 지연시간 예산 안에서 실용적으로 수행해, 기존 마이크로서비스 구조에서는 적용하기 어려웠던 추천 품질 개선을 가능하게 했다. 실용적으로는 검색 단계의 서비스 수가 많고, 후보 수·모델 복잡도·지연시간 간 충돌이 큰 시스템일수록 SilverTorch와 같은 통합 모델 구조의 효과가 크다. 다만 모든 구성 요소를 PyTorch로 통일하려면 GPU 메모리 관리, 모델 배포 안정성, 디버깅과 장애 격리 같은 운영 과제를 함께 해결해야 한다.

gpumicroservicesrecommendation-systemsneural-networks+3

kakao2026년 4월 21일

카나나 스칼라 1회 세미나 현장 스케치 (새 탭에서 열림)

카카오의 ‘카나나 스칼라’ 1회 세미나는 카나나 파운데이션 모델의 기술 성과와 향후 AI 전략을 학계와 공유한 자리였다. 카카오는 적은 학습 토큰으로 높은 성능을 달성한 효율성과 한국어·다중모달 처리 능력을 강조했으며, 기술 주권과 서비스 최적화를 위해 자체 모델 개발을 지속하겠다는 방향을 밝혔다. 또한 초개인화 에이전트, 디지털 월드모델, 실전형 실행 능력, 산학 협력을 중심으로 AI 생태계를 확장할 계획을 제시했다. ## 카나나 파운데이션 모델의 성과 - 카카오는 외부 모델을 활용하는 대신, 처음부터 직접 개발하는 ‘카나나’ 파운데이션 모델 라인업을 구축하고 있다. - 유사한 규모의 글로벌 모델이 23조 개의 학습 토큰을 사용한 데 비해, 카나나는 약 11조 개의 토큰만으로도 뛰어난 성능을 달성했다고 설명했다. - 이는 학습 데이터의 정제 수준과 품질이 모델 효율성에 크게 기여했다는 의미로 소개됐다. - 텍스트와 이미지뿐 아니라 오디오까지 실시간 처리하는 옴니 모델 **Kanana-o**도 시연했다. - Kanana-o는 감정을 담은 음성 표현과 다화자 대화 처리를 선보였으며, 현장에서는 한국어 구사 능력이 뛰어나다는 평가를 받았다. ## 자체 모델 개발과 기술 주권 - 외부 AI 모델에 의존할 경우 라이선스 정책 변경이나 기술 공개 제한 등 외부 변수에 영향을 받을 수 있다. - 카카오는 독자 모델을 통해 서비스 환경에 맞는 고효율·맞춤형 AI를 운영하고, 실질적인 비즈니스 성과를 창출하려 한다. - 교수진은 한국의 문화적 맥락과 사회적 이슈를 독자적으로 통제하려면 자체 모델이 필요하다고 평가했다. - 독자적인 모델 역량은 서비스 안정성과 기술 주권을 확보하는 전략적 자산으로 논의됐다. ## 디지털 월드모델과 초개인화 에이전트 - 카카오는 카카오톡 플랫폼에서 발생하는 사용자의 행동과 대화 맥락을 이해하는 ‘상황 이해 지능’에 주목하고 있다. - 온디바이스 기술을 활용하면 대화 내용이 외부로 유출되지 않도록 보호하면서도 사용자의 요청을 즉시 처리할 수 있다. - 이를 바탕으로 사용자의 일상과 맥락에 맞춰 행동하는 초개인화 에이전트를 구현하려 한다. - 교수진은 디지털 월드모델을 로봇이나 물리적 환경에만 한정하지 말고, 플랫폼 내 상호작용과 인과관계를 예측하는 모델로 확장하자고 제안했다. - 카카오톡의 방대한 서비스·사용자 상호작용은 카카오만의 차별화된 디지털 월드모델을 구축할 기반으로 평가됐다. ## 생성 능력보다 중요한 실전형 실행력 - 카카오는 단순히 문장을 생성하는 능력보다, AI가 작업을 계획하고 필요한 기능을 호출해 최종 과업을 완료하는 능력을 중시한다. - 자체 ‘오케스트레이션 벤치마크’를 개발해 복합적인 실제 문제 해결 능력을 평가할 계획이다. - 이는 여러 단계의 추론과 도구 사용이 필요한 서비스 환경에서 AI의 실질적인 유용성을 검증하기 위한 접근이다. - 교수진은 사용자가 느끼는 지능은 벤치마크 점수보다 복잡한 요구를 끝까지 해결하는 능력에서 드러난다고 강조했다. - 글로벌 모델과 단순 생성 품질 경쟁을 하기보다, 카카오 서비스 안에서의 실행력에 집중하는 전략이 효과적일 수 있다는 의견이 제시됐다. ## 학계와 산업계의 AI 인재 협력 - 카카오는 세미나를 계기로 대학 연구실과 학부 AI 동아리에 GPU 자원을 지원하는 방안을 검토하고 있다. - 지원 방식으로는 GPU 크레딧 제공이나 공동 과제 형태 등이 논의됐다. - 이러한 협력은 연구자와 학생들이 실제 AI 모델 개발과 실험을 수행할 수 있도록 돕고, 국내 AI 인재 생태계를 강화하는 데 목적이 있다. - 카나나 스칼라는 기술 논의뿐 아니라 지속적인 산학 협력의 출발점으로 추진될 예정이다. 카카오는 카나나를 단순한 대규모 언어 모델이 아니라, 한국어와 국내 서비스 맥락을 이해하고 실제 작업까지 수행하는 플랫폼형 AI로 발전시키려 한다. 향후에는 모델 성능 자체보다 개인정보 보호, 카카오 서비스와의 결합도, 복합 과업 실행력, 그리고 산학 협력을 통한 생태계 확장이 중요한 경쟁력이 될 것으로 보인다.

gpuaiai-agentmultimodal-ai+4

netflix2026년 2월 13일

넷플릭스의 LL (새 탭에서 열림)

넷플릭스는 일반적인 기초 모델을 자사 서비스의 카탈로그와 사용자 맥락에 맞게 최적화하기 위해, 인프라의 복잡성을 추상화한 '포스트 트레이닝(Post-Training) 프레임워크'를 구축했습니다. 이 프레임워크는 대규모 분산 GPU 클러스터 환경에서 데이터 파이프라인과 모델 훈련 워크플로우를 효율적으로 조율하여 연구자들이 하드웨어가 아닌 모델 혁신에만 집중할 수 있게 돕습니다. 결과적으로 엔지니어링 병목 현상을 해결함으로써 개인화 추천 및 검색 경험을 고도화하는 데 핵심적인 역할을 수행합니다. ### 데이터 처리 및 모델 설정의 기술적 난제 - **정교한 손실 마스킹(Loss Masking):** 지시어 이행(Instruction following)이나 연쇄 사고(CoT) 품질을 높이기 위해, 프롬프트가 아닌 응답(Assistant) 토큰에만 손실을 적용하여 모델이 부적절한 텍스트를 학습하지 않도록 제어합니다. - **시퀀스 패킹(Sequence Packing):** 가변적인 문장 길이로 인한 연산 낭비를 줄이기 위해 여러 샘플을 고정 길이 시퀀스로 묶고, 샘플 간 간섭을 방지하는 '도큐먼트 마스크'를 적용하여 GPU 효율을 극대화합니다. - **분산 로딩 및 메모리 최적화:** 단일 GPU 메모리를 초과하는 모델을 위해 FSDP(Fully Sharded Data Parallel)나 TP(Tensor Parallel) 샤딩을 사용하며, 대규모 어휘집 처리 시 발생하는 메모리 스파이크를 방지하기 위해 로짓 청킹(Logit chunking) 기법을 도입했습니다. ### 넷플릭스 포스트 트레이닝 프레임워크의 구조 - **기술 스택의 통합:** 넷플릭스 내부 ML 플랫폼인 'Mako' 위에서 PyTorch, Ray, vLLM 등 오픈소스 구성 요소를 결합하여 단일 노드부터 수백 개의 GPU까지 확장 가능한 환경을 제공합니다. - **표준화된 레시피:** SFT(지도 미세 조정), DPO(직접 선호도 최적화), RL(강화 학습), 지식 증류 등 주요 워크플로우를 설정 파일만으로 실행할 수 있는 재사용 가능한 레시피 형태로 지원합니다. - **유연한 아키텍처 확장성:** 단순 챗 모델을 넘어 도메인 특화 특수 토큰 사용이나 비표준 아키텍처 실험이 가능하도록 유연성과 확장성을 최우선으로 설계되었습니다. ### 시스템 고도화를 위한 4대 핵심 요소 - **데이터(Data):** 로컬 저장 공간을 초과하는 대규모 데이터를 클라우드에서 실시간 스트리밍하며, CPU 기반 패킹 작업을 GPU 연산과 비동기적으로 병렬 처리하여 유휴 시간을 제거합니다. - **모델(Model):** Qwen, Gemma 등 최신 아키텍처와 MoE(Mixture-of-Experts) 모델을 지원하며, LoRA 통합 및 고수준 샤딩 API를 통해 복잡한 분산 코딩 없이도 대형 모델을 다룰 수 있게 합니다. - **연산(Compute):** MFU(Model FLOPS Utilization) 모니터링을 통해 연산 효율을 실시간 추적하며, 장애 발생 시 훈련 상태를 정확히 복구할 수 있는 정교한 체크포인팅 시스템을 갖추었습니다. - **워크플로우(Workflow):** 단순 학습 루프를 넘어 온폴리시(On-policy) 강화 학습처럼 생성(Rollout)과 업데이트가 반복되는 복잡한 단계를 SPMD(Single Program, Multiple Data) 스타일로 관리합니다. 복잡한 분산 시스템의 세부 사항을 프레임워크 수준에서 표준화함으로써, 넷플릭스는 고도화된 AI 모델 실험의 진입 장벽을 낮추고 대규모 서비스에 최적화된 모델을 더 빠르게 배포할 수 있는 기반을 마련했습니다. 이러한 엔지니어링 접근 방식은 인프라의 복잡성에 구애받지 않고 최신 모델링 기법을 신속하게 도입하려는 기업들에게 유용한 사례가 됩니다.

gpudatabase-designllmcloud-computing+4