์ฌ์ ๋ฆฌ๋
์ธํ๋ผ์ ์ ํ ํ ์ฐ๊ฒฐ: GenAI ํ๋ซํผ ๊ตฌ์ถ์์ ์ป์ ๊ตํ
의심할 여지없이: 제너레이티브 AI, 또는 GenAI는 최근 2년 동안 가장 인기 있는 주제입니다. 자동화된 프로세스, 새로운 제품 디자인 생성, 콘텐츠 생성 등 다양한 도메인에서 목표를 달성하기 위해 조직은 이제 가장 중요한 작업을 시작하고 GenAI 전략을 실행에 옮겨야 합니다.
GenAI의 성공은 연구에서 훈련 및 최종적으로 추론까지의 작업을 포함하며, 배포, 관찰 가능성, 비용 관리, 텔레메트리 및 기본 인프라 및 서비스의 지연 시간 목표에 대한 긴밀한 조정이 필요합니다. 이러한 요소는 AI 작업에 대한 달성 가능한 효율성을 제공하며, 계산과 통신 간의 균형을 유지하고 GPU가 필요한 데이터를 항상 갖도록 합니다.
하지만 구조적인 간극이 존재합니다. 인프라 엔지니어링은 컴퓨팅 및 배포 스택에 중점을 두고, 소프트웨어 및 제품 팀은 실제 세계에서 GenAI를 구현하는 사용자 중심의 애플리케이션을 개발하는 데 집중합니다. 이러한 그룹이 완전히 일치하지 않으면 배포 지연, 성능 문제 및 사용성 문제가 발생할 수 있습니다.
그렇다면 이러한 간극은 실제로 어떤 모습일까요? 그리고 GenAI의 성공을 위해 인프라와 제품 팀을 어떻게 일치시킬 수 있을까요?
불일치의 문제
인프라와 제품 팀이 불일치할 때, 증상은 종종 명백하지만, 항상 kịpzeitig으로 해결되지 않습니다. 불일치한 팀의 특징은 지연 시간 예상치 또는 모델 기능에 대한 일치하지 않는 가정입니다. 예를 들어, 인프라 엔지니어링 팀은 실제 인프라 설계와 일치하지 않는 성능 수준을 가정하는 기능 또는 배포를 계획할 수 있습니다. 이는 늦은 단계의 작업, 범위 변경 및 배포 지연으로 이어집니다.
불일치는 또한 최적화되지 않은 인프라에 배포하여 발생하는 성능 저하로 이어질 수 있습니다. 이는 지연 시간 변동 및 확장성 문제로 나타나며, 훈련 또는 대규모 분산 추론 작업의 성능에 영향을 미칩니다. 다운스트림 보안 및 규정 준수 위험도 팀 불일치의 특징입니다. 두 팀 간의 초기 협력이 부족하기 때문에 데이터 개인 정보 보호 및 규정 준수 요구 사항이 무시될 수 있습니다.
마지막으로, 팀 불일치는 사용자 경험을 저하합니다. 이는 인프라 엔지니어링 팀이 제약 조건이 불분명할 때 작업을 회피하도록 유도하여 반복 주기를 느리게 하고 기술 부채를 증가시킵니다. 물론, 제품 및 인프라 팀 간의 불일치는 모든 소프트웨어 프로젝트에서 비용이 많이 들 수 있지만, 특히 GenAI의 경우, 운영 비효율성, 경쟁 우위 상실 및 보안 위험 등이 더 높은 위험을 초래합니다.
성공으로의 다리
GenAI의 성공은 강력한 인프라를 갖는 것뿐만 아니라, 인프라와 제품 프로세스를 연결하는 전술적 프레임워크를 생성하는 데에도 의존합니다. 예를 들어, 내부 자체 서비스 API를 위한 GPU 프로비저닝의 아이디어를 생각해 보십시오. 인프라 팀의 경우, 이러한 API는 접근을 표준화하고, 티켓 오버헤드를 줄이며, 규정 준수를 보장합니다. 제품 팀의 경우, 빠르고 예측 가능한 컴퓨팅에 대한 접근을 제공하여 대기열에서 기다리지 않아도 됩니다. 결과적으로, 두 그룹 모두 동일한 API “계약”에서 작업하여 병목 현상을 제거하고 기대치를 명확히 합니다.
실시간 사용량 대시보드는 유사한 역할을 합니다. 시스템 로드 및 효율성을 인프라 엔지니어에게 시각화하고,同時적으로 제품 팀에게 작업량이 실제 소비로 어떻게 변환되는지 보여줍니다. 양쪽 모두 동일한 데이터를 볼 수 있으므로 성능 또는 병목 현상에 대한 논의는 더 협력적이고 적대적이지 않게 됩니다. 단일 진실의 원천이 있습니다.
자동 확장은 또 다른 통일 메커니즘입니다. 인프라 엔지니어에게서 지속적인 소방을 해제하고, 제품 개발자가 작업량 피크 期間 동안 성능 상한을 맞지 않도록 보장합니다. 이는 안정성과 민첩성 간의拔河戦이 아닌 공동 전략이 됩니다. 규모는 자동으로 관리되며, 운영 복원력 및 제품 성능 목표와 일치합니다.
마지막으로, 비용 통찰력은 공동의 관점에 금융적 차원을 추가합니다. 인프라 팀은 할당량을 최적화하고 용량 계획을 정당화할 수 있으며, 제품 팀은 아키텍처 또는 모델 선택이 어떻게 지출에 영향을 미치는지 이해할 수 있습니다. 이러한 투명성은 공동의 책임을 조성하며, 효율성을 숨겨진 관심사에서 집단적 책임으로 전환합니다.
그러나 일치에는 공유 도구 이상의 것이 필요합니다. 공동의 비전도 필요합니다. 이것이 공동 로드맵이 필요한 이유입니다. 각 팀은 전체적인 목표뿐만 아니라 이를 달성하기 위한 단계를 이해해야 합니다. 인프라의 경우, 이는 하드웨어 및 소프트웨어의 심층 기술적 근간을 넘어 개발자 및 최종 사용자가 실제로 시스템을 경험하는 방식과 관련하여 참여하는 것을 의미합니다. 제품 팀의 경우, 이는 지연 시간, 비용 및 모델 효율성과 같은 제약 조건을尊重하는 것을 의미하며, 운영 현실을 이해하여 혁신을 지속 가능하게 만듭니다.
마지막으로, 어떤 파트너십도 보안 및 규정 준수에 대한 상호적인 약속 없이 지속될 수 없습니다. SOC2, HIPAA, ISO 또는 기타 프레임워크가 적용되든, 특정 요구 사항은 고객 기반 및 산업 垂直에 따라 다르지만, 책임은 공유됩니다. 인프라 및 제품 팀 모두 이러한 의무를 내면화해야 하며, 규정 준수가 단순한 체크 박스 작업이 아닌 사용자와의 신뢰의 기초라는 것을 인식해야 합니다.
이러한 관행 및 사고방식을รวม하면 인프라와 제품을 일치된 단위로 엮어, 공유 언어, 공유 가시성 및 진행, 복원력 및 신뢰성에 대한 공유 책임이 생성됩니다.
지식이 풍부한 팀
올바른 시스템을 갖는 것만큼 중요한 것은 올바른 사람을 갖는 것입니다. 이상적으로, 팀은 이미 GenAI를 알고 있는 구성원 또는 고성능 컴퓨팅 및 초대형 데이터 센터 배경을 가진 구성원으로 구성되어야 합니다. 실제로 중요한 것은 실용적인 경험과 GPU-as-a-Service 플랫폼을 구축 및 지원하면서 얻은 교훈입니다. 이는 GPU가 서로 어떻게 통신하는지, 어떻게緊密하게 결합된 훈련이 동작하는지, 그리고 지연 시간, 동기화 및 데이터 전달에 어떻게 민감한지 이해하는 것을 의미합니다.
모델이 계속 성장하고 배포가 확장됨에 따라, 팀은 전체 고객 여정을 생각해 보아야 합니다. 이는 초기 연구 및 실험에서 시작하여 대규모 훈련, 세부 조정 및 최종적으로 추론으로 진행됩니다. 각 단계는 조금씩 다르며, 요구 사항은 변경됩니다. 모델 개발의 반복적인 특성은 지속적으로 인프라, 워크플로 및 능력에 대해 GenAI 데이터 센터를 적합하게 유지하는 방법을 가르칩니다.
인프라 및 제품 팀은 종종 자신의 버블 내에서 작동합니다. GenAI를 대규모로 생산에 배포하려는 모든 회사에게 이것은 변경되어야 합니다. 성공은 이러한 실로를 분해하고 플랫폼에 대한 공유 소유권을 생성하는 데 의존합니다. 올바른 사람, 명확한 비전 및 실용적인 프레임워크와 함께, 양쪽 모두 동일한 플레이북에서 일치할 수 있습니다. 이는 더 빠르게 이동하고, 책임을 지며, 궁극적으로 성공적인 GenAI 배포를 제공하는 데 도움이 됩니다.
