6.6

View in English

6.6 AI 인프라와 운영

개요와 동기

AI 인프라와 운영은 AI 워크로드가 요구하는 특화된 컴퓨트, 스토리지, 서빙 시스템을 프로비저닝하고, 스케줄하고, 운영하되, 비용 효율적이고, 믿을 만하고, 관찰 가능하게 하는 규율입니다. 현대 AI는 운영하기 비쌉니다. 큰 모델의 학습과 서빙에는 희소한 가속기(GPU와 TPU), 고대역폭 네트워킹, 검색을 위한 대규모 벡터 스토리지(비슷한 항목을 빨리 찾을 수 있도록 데이터를 숫자 벡터로 색인하는 것), 지연과 처리량에 맞게 튜닝된 서빙 계층이 필요합니다. 이 인프라를 제대로 갖추는 것이 지속 가능하게 확장되는 AI와, 기대에 못 미치면서 예산을 조용히 소비하는 AI의 차이입니다.

큰 팀에게 핵심 문제는 규모, 희소성, 비용입니다. 가속기는 한정되어 있고 비싸므로 스케줄링과 활용률이 엄청나게 중요합니다. 놀고 있는 GPU는 태우는 돈이고, 제대로 배치되지 않은 추론은 요청당 비용을 곱합니다. 검색 비중이 큰 애플리케이션은 커져도 빠르게 유지되는 벡터 데이터베이스가 필요합니다. 생성형 AI 애플리케이션은 안전하게 운영하고 시간이 지나며 개선하려면 프롬프트 버전 관리, 평가 파이프라인, 관측 가능성(때로 LLMOps라 부름)이 필요합니다. 공유 인프라와 운영 규율이 없으면 모든 팀이 같은 싸움을 하고 비용이 걷잡을 수 없이 불어납니다.

정부와 규제 조직은 데이터 주권, 보안, 예측 가능한 지출에 대한 요건을 더합니다. 민감한 데이터와 모델이 통제된 경계를 결코 떠나지 않도록 온프레미스나 주권 클라우드 배포가 필요할 수 있습니다. 인프라 지출을 예측하고 정당화해야 하며, 보안과 가용성 표준을 충족해야 합니다. 이런 환경에서 AI 인프라 결정은 여러 해의 결과를 낳으므로, 조달, 보안, 퇴출을 염두에 두고 내리십시오.

핵심 원칙

  • 가속기 컴퓨트를 쌓아 두는 것이 아니라 스케줄하고 활용할 희소하고 비싼 자원으로 다루십시오.
  • 원시 용량이 아니라 유용한 작업 단위당 비용을 최적화하십시오.
  • 모델과 하드웨어를 과업에 맞게 크기를 조정하십시오. 가장 큰 옵션이 가장 비용 효율적인 경우는 드뭅니다.
  • 배치와 캐싱을 일급 기법으로 삼아 지연과 처리량을 위해 서빙을 설계하십시오.
  • AI 시스템을 관찰 가능하게 만드십시오. 비용, 지연, 품질, 오류를 지속적으로 추적하십시오.
  • 프롬프트와 모델을 코드와 같은 엄밀함으로 버전 관리하고 평가하십시오.
  • 인프라와 서빙 선택에서 이식성을 계획하고 종속을 피하십시오.

권장 사항

가속기 컴퓨트를 계획하고 통제한다

학습과 추론의 수요를 따로 예측하십시오. 모양이 다르기 때문입니다. 학습은 돌발적이고 스케줄 가능하며, 추론은 지속적이고 지연에 민감합니다. 스케줄러와 쿼터로 희소한 GPU와 TPU를 팀 전반에 공유하고, 워크로드의 우선순위를 정하고, 활용률을 끌어올리십시오. 활용률을 측정하고 만성적 유휴를 고칠 문제로 다루십시오. 비용을 통제하도록 기본 부하에는 예약 용량을, 돌발에는 온디맨드나 스팟 용량을 섞으십시오. 더 싸거나 작은 가속기, 또는 가벼운 모델의 CPU 추론으로 충분한지 고려하십시오. 규모에서의 비용, 데이터 주권 필요, 돌발 패턴에 근거해 클라우드, 온프레미스, 하이브리드 중에서 고르고, 퇴출 경로를 유지하십시오.

검색 인프라를 구축한다: 임베딩과 벡터 데이터베이스

검색 증강 애플리케이션을 위해 임베딩(비슷한 항목을 서로 가까이 놓는 숫자 벡터 표현)을 생성하고, 여러분의 규모에서 빠른 근사 최근접 이웃 검색(모든 벡터를 빠짐없이 비교하지 않고 가장 비슷한 벡터를 찾는 것)을 지원하는 벡터 데이터베이스에 저장하는 인프라를 세우십시오. 세 가지를 계획하십시오. 임베딩 생성의 비용과 지연, 문서가 바뀜에 따른 색인 신선도, 색인을 일관되게 유지하는 운영 부담입니다. 전용 벡터 데이터베이스, 기존 데이터베이스의 벡터 지원 확장, 관리형 서비스 중 무엇이 규모와 종속 허용도에 가장 잘 맞는지 평가하십시오. 검색 품질이 애플리케이션 품질을 직접 정하므로 검색 지연과 재현율을 모니터링하십시오.

모델 서빙을 최적화한다: 배치, 캐싱, 지연

서빙은 추론 비용과 사용자 경험이 정해지는 곳입니다. 배치로 여러 요청을 함께 처리해 가속기 처리량을 높이되 배치 크기와 지연의 균형을 맞추십시오. 캐싱을 공격적으로 쓰십시오. 동일하거나 의미상 비슷한 요청을 캐시하고, 임베딩을 캐시하고, 플랫폼이 지원하는 곳에서는 프롬프트나 접두사 캐싱을 활용해 공유된 컨텍스트를 다시 계산하지 마십시오. 분명한 지연 목표를 정하고, 평균만이 아니라 꼬리 지연을 측정하십시오. 요청을 알맞은 크기의 모델로 라우팅하십시오. 쉬운 경우에는 작은 모델, 필요할 때만 더 큰 모델입니다. 수요에 맞춰 서빙을 자동 확장하고, 출시 전에 부하 테스트를 해서 용량과 비용 곡선을 아십시오.

LLMOps를 실천한다: 프롬프트 버전 관리, 평가 파이프라인, 관측 가능성

프롬프트를 리뷰와 롤백 능력이 있는 소스 제어의 버전 관리되는 산출물로 다루십시오. 프롬프트나 모델이 바뀔 때마다 오프라인 테스트 스위트를 자동으로 돌리는 평가 파이프라인을 만들어 릴리스 전에 회귀를 잡으십시오. 프로덕션을 포괄적으로 계측하십시오. 입력, 출력, 지연, 토큰 사용량, 비용, 오류를 샘플링과 프라이버시 보호 장치와 함께 기록합니다. 품질 신호와 사용자 피드백을 온라인으로 추적하십시오. 이 관측 가능성이 저하를 잡고, 비용을 통제하고, 실패를 디버깅하고, 시스템을 안전하게 개선하게 해 줍니다. 프로덕션 생성형 AI의 운영 뼈대입니다.

비용을 끈질기고 관찰 가능하게 관리한다

AI 지출을 팀과 사용 사례에 귀속시켜 비용이 보이고 소유되게 하십시오. 예산과 알림을 설정하고, 요청당 및 성과당 비용을 모니터링하고, 가장 큰 비용 동인을 정기적으로 검토하십시오. 가진 지렛대를 당기십시오. 모델 크기 조정, 캐싱, 배치, 프롬프트와 컨텍스트 다듬기, 요건을 충족하는 가장 싼 배포 선택입니다. AI 비용은 사용량에 따라 놀랍게 커질 수 있으므로, 불쾌한 놀람을 피하려면 지속적 비용 관측 가능성이 필수입니다.

장단점

결정옵션 A옵션 B트레이드오프
컴퓨트 위치클라우드온프레미스탄력성과 낮은 선행 비용 대 통제, 주권, 정상 상태 경제성
용량예약온디맨드/스팟예측 가능한 비용 대 유연성과 중단 위험
배치 크기큰 배치작은 배치처리량과 비용 대 지연
모델 크기큰 모델작은 모델품질 대 비용과 속도
벡터 저장소전용 데이터베이스기존 데이터베이스 확장규모에서의 성능 대 단순함과 더 적은 시스템
캐싱공격적최소더 낮은 비용과 지연 대 신선도와 복잡성

지배적 트레이드오프는 비용 대 지연과 품질입니다. 배치, 캐싱, 더 작은 모델은 비용을 줄이지만 지연을 더하거나 품질을 낮출 수 있습니다. 올바른 균형은 애플리케이션의 허용도에 달려 있습니다. 온프레미스 대 클라우드는 통제와 정상 상태 경제성을 탄력성과 낮은 약정에 맞바꾸며, 데이터 주권 필요와 규모가 크게 좌우하는 결정입니다.

팀과 논의할 질문

  1. 오늘 유용한 성과당 비용은 얼마이며, 어떤 지렛대가 그것을 가장 많이 움직입니까? 원시 용량과 요청당 평균은 중요한 숫자를 가립니다. 실제 가치 한 단위를 전달하는 데 드는 비용과 그것이 사용량에 따라 어떻게 확장되는지입니다. 큰 팀에서 최적화된 배포와 최적화되지 않은 배포 사이의 간극은 지출에서 몇 배인 경우가 많으므로, 이 질문은 청구서에 대한 막연한 걱정을 순위가 매겨진 수정 목록으로 바꿉니다. 팀과 사용 사례별 현재 비용 귀속, 요청당 및 성과당 추세, 가장 큰 비용 동인을 가져오십시오. 지렛대를 보답 순서로 논의하십시오. 모델 크기 조정, 캐싱(접두사와 의미 캐싱 포함), 배치, 프롬프트나 컨텍스트 다듬기입니다. 정부에서는 여러 해 지출을 예측하고 정당화해야 하는 압박을 더하십시오. 답은 가장 큰 비용 동인 각각에 어깨 으쓱이 아니라 소유자와 지렛대를 배정해야 합니다.

  2. 현재 추론 제공자가 내일 가격을 두 배로 올리거나 중단되면, 얼마나 빨리 바꿀 수 있습니까? 조용한 종속은 만들기 쉽고 벗어나기 고통스러우며, 서빙 스택이 그것이 가장 깊이 숨는 곳입니다. 기업, 특히 정부에게 이식성은 호의가 아니라 조달과 연속성의 요건입니다. 아키텍처를 가져오십시오. 모델이 내부 인터페이스 뒤에 있는지, 프롬프트와 평가 스위트가 이식 가능한지, 제공자 고유의 서빙 동작에 얼마나 의존하는지입니다. 지켜볼 신호는 누군가 평가 스위트를 두 번째 제공자나 두 번째 배포 대상에 대해 돌려 본 적이 있는가입니다. 전환에 몇 달이 걸리고 핵심 경로를 다시 써야 한다면, 그것을 지금 다룰 설계 결함으로 다루십시오. 주권 및 온프레미스 옵션이 거의 예고 없이 의무가 될 수 있기 때문입니다.

  3. 지금 우리 가속기 활용률은 얼마이며, 놀고 있는 GPU와 배치되지 않은 추론이 얼마를 태우고 있습니까? 가속기는 희소하고 비싸므로 만성적 유휴와 요청별 서빙은 더 많은 역량에 자금을 댈 수 있는 예산을 조용히 소진합니다. 팀 전반에 GPU를 공유하는 큰 조직에서 이 질문은 스케줄링, 쿼터, 우선순위가 실제로 활용률을 높게 유지하는지, 쌓아 두고 덜 쓰는 하드웨어가 일상인지를 드러냅니다. 사용자가 느린 꼬리를 느끼므로 평균만이 아니라 실제 활용률 숫자, 배치와 캐싱 태세, 꼬리 지연 측정을 가져오십시오. 학습과 추론 수요를 모양이 다르므로 따로 예측하는지, 가벼운 경우에는 더 작은 모델이나 CPU 추론으로 충분한지 논의하십시오. 답은 회수할 구체적 유휴 용량과, 배치하거나 알맞은 크기의 모델로 라우팅할 구체적 요청을 가리켜야 합니다.

  4. 프롬프트나 모델 변경이 출하될 때, 조용한 품질이나 비용 회귀가 사용자에게 닿는 것을 무엇이 막습니까? 서빙 스택은 지연과 가동 시간에서는 건강해 보이는데 반환하는 답은 조용히 나빠지거나, 새 프롬프트가 요청당 토큰 사용량을 두 배로 만들 수 있습니다. 많은 그룹이 프롬프트를 편집하고 모델을 독립적으로 바꾸는 큰 팀에서 관문 없는 변경은 기다리는 프로덕션 사고이고, 공유 플랫폼의 팀마다 피해 범위가 커집니다. 평가 커버리지를 가져오십시오. 어떤 프롬프트와 모델에 오프라인 테스트 스위트가 있는지, 그 스위트가 모든 변경마다 자동으로 도는지, 어떤 품질과 비용 임계값이 릴리스를 관문 통제하는지, 얼마나 빨리 롤백할 수 있는지입니다. 프롬프트가 리뷰와 함께 소스 제어에 있는지, 누군가 여전히 라이브 시스템 프롬프트를 손으로 편집할 수 있는지 논의하십시오. 기업과 정부 환경에서는 각 변경을 감사 추적과 지명된 승인자에 묶으십시오. “누가 이것을 바꿨고 무엇을 테스트했는가”를 묻는 규제 기관에는 기억이 아니라 기록된 답이 필요하기 때문입니다.

  5. 클라우드, 온프레미스, 주권 배포 중에서 어떻게 결정하며, 시범 사업이 아니라 실제 정상 상태 경제성의 가격을 매겼습니까? 컴퓨트 위치의 선택은 비용 곡선, 데이터 주권 태세, 퇴출 옵션을 여러 해 동안 정하는데, 규모에서의 프로덕션과 전혀 닮지 않은 시범 사업의 클라우드 청구서로 내려지는 경우가 많습니다. 큰 조직에서 탄력적 클라우드 용량은 시작하기 싸고 추론이 지속적으로 돌면 단일 최대 항목이 될 수 있는 반면, 온프레미스는 낮은 약정을 통제와 정상 상태 경제성에 맞바꿉니다. 예측된 학습과 추론 물량, 예약이나 소유 하드웨어가 온디맨드를 이기는 손익분기점, 데이터 거주와 보안 제약, 하이브리드를 주장하는 돌발 패턴을 가져오십시오. 정부와 규제 환경에서는 거의 예고 없이 의무가 될 수 있는 주권 클라우드나 온프레미스 요건을 저울질하고, 강제 이전이 핵심 경로를 다시 쓰게 하지 않도록 아키텍처가 모델을 내부 인터페이스 뒤에 두는지 확인하십시오.

  6. AI 지출을 실제로 소유하며, 각 팀이 자신이 일으키는 비용을 보고 책임질 수 있습니까? AI 비용은 사람들을 놀라게 하는 방식으로 사용량에 따라 확장되고, 귀속이 없으면 청구서는 어느 팀도 줄일 책임을 느끼지 않는 하나의 불투명한 숫자로 떨어집니다. 큰 조직에서 아무도 소유하지 않는 비용은 아무도 최적화하지 않는 비용이므로, 질문은 지출이 예산, 알림, 성과당 추세와 함께 팀과 사용 사례에 태그되어 있는지, 재무가 에스컬레이션할 때에야 발견되는지입니다. 비용 귀속 모델, 팀별 가장 큰 동인, 각 소유자가 통제하는 지렛대를 가져오십시오. 모델 크기 조정, 캐싱, 배치, 컨텍스트 다듬기입니다. 기업과 정부 예산에서는 여러 해의 인프라 지출을 예측하고 정당화하는 규율을 더하십시오. 컴퓨트 청구서를 항목별로 설명할 수 없는 공공 기관은 리뷰에서 그것을 방어하기 어렵기 때문입니다.

분야별 관점

스타트업. 피할 수 있는 인프라는 소유하지 마십시오. 호스팅 추론 API를 호출하고, 쉬운 요청은 작고 싼 모델로 라우팅하고 더 큰 모델은 어려운 경우에 남겨 두고, 반복되는 프롬프트가 공짜가 되도록 공격적으로 캐시하십시오. 직접 운영하지 않도록 관리형 벡터 데이터베이스를 쓰고, 변경마다 짧은 평가 스크립트와 함께 프롬프트를 git에 두고, 폭주하는 청구서가 해를 입히기 전에 보이도록 요청당 비용을 기록하십시오. 가장 희소한 자원은 엔지니어링의 주의이므로 운영성을 사고 전환을 싸게 유지하십시오.

소기업. 플랫폼 팀이 없으니 서빙, 검색, 관측 가능성을 인력을 두는 시스템이 아니라 이미 쓰는 도구 안에서 사는 것으로 다루십시오. 투명하고 예측 가능한 가격의 관리형 추론과 관리형 벡터 검색을 선호하고, 첫날부터 엄격한 지출 상한과 청구 알림을 설정하십시오. 결정을 구매 대 구축으로 정직하게 구성하십시오. 여러분의 물량에서 GPU나 벡터 색인을 운영하는 것은 좀처럼 보답하지 않으며, 호스팅 API 뒤의 작은 모델이 보통 훨씬 적은 노력으로 필요를 충족합니다.

대기업. 문제는 많은 팀에 걸친 공유 포장된 길 플랫폼입니다. 활용률을 끌어올리는 스케줄러, 쿼터, 우선순위가 있는 풀링된 가속기, 표준 배치와 캐싱, 크기 조정 라우터, 각 팀과 사용 사례에 귀속되는 비용입니다. 자동화된 평가 스위트로 프롬프트와 모델 변경을 관문 통제하고, 제공자와 배포 대상이 교체 가능하도록 인터페이스 계층을 표준화하고, 각 그룹이 비싸고 덜 쓰이는 인프라를 다시 발명하게 두는 대신 성과당 비용을 일급 지표로 관리하십시오.

정부. 데이터 주권, 보안, 예측 가능한 지출이 모든 선택을 형성합니다. 민감한 데이터와 모델이 통제된 경계 안에 머물도록 온프레미스나 주권 클라우드 배포를 선호하고, 조달에서 정당화할 수 있는 쿼터로 부처 전반에 희소한 GPU를 스케줄하고, 여러 해 지출을 항목별로 방어하도록 용량을 예측하십시오. 기록된 감사 추적과 함께 프롬프트와 모델을 버전 관리하고 평가하고, 비용과 품질에 대한 포괄적 관측 가능성을 유지하고, 새 제공자나 주권 플랫폼으로의 강제 이전이 발목을 잡지 않도록 모델을 내부 인터페이스 뒤에 두십시오.

사례

스타트업. AI 글쓰기 기능을 운영하는 한 작은 스타트업은 GPU를 하나도 소유하지 않고도 청구서를 건전하게 유지했습니다. 호스팅 추론 API를 호출했고, 쉬운 요청은 더 싼 작은 모델로 라우팅하고 더 큰 모델은 어려운 경우를 위해 남겨 두었으며, 반복되는 프롬프트의 답을 캐시했습니다. 변경마다 도는 짧은 평가 스크립트와 함께 프롬프트를 git에 저장했고, 직접 운영하지 않도록 검색에 관리형 벡터 데이터베이스를 썼으며, 창업자들이 놀람이 되기 전에 지출이 오르는 것을 볼 수 있도록 요청당 비용을 기록했습니다.

기업. 트래픽이 많은 LLM 기능을 운영하는 한 미디어 회사가 추론 비용을 상당히 줄였습니다. 쉬운 요청은 작은 모델로 라우팅하고 더 큰 모델은 어려운 요청을 위해 남겨 두었습니다. 반복 질의의 응답을 캐시하고 공유 시스템 프롬프트에 접두사 캐싱을 켰습니다. 활용률을 높게 유지하려고 공유 스케줄러를 통해 GPU를 돌리고, 변경을 관문 통제하는 자동화된 평가 스위트와 함께 모든 프롬프트를 git에서 버전 관리하고, 각 제품 팀이 자기 지출을 소유하도록 요청당 비용을 계측했습니다.

정부. 엄격한 데이터 주권 규칙이 있는 한 국가 기관이 민감한 데이터와 모델이 통제된 환경을 결코 떠나지 않도록 AI 시스템을 온프레미스에 배포했습니다. 쿼터와 우선순위로 부처 전반에 희소한 GPU를 스케줄했고, 여러 해 조달을 정당화하도록 용량을 예측했으며, 공식 문서에 대한 검색을 위한 벡터 검색 플랫폼을 구축했습니다. 프롬프트와 모델은 릴리스 전에 버전 관리되고 평가되었습니다. 포괄적 관측 가능성이 비용과 품질을 추적했고, 아키텍처는 퇴출 경로를 보존하고 종속을 피하도록 모델을 내부 인터페이스 뒤에 두었습니다.

비즈니스 사례: 동기, ROI, TCO

규율 있는 AI 인프라의 동기는 단순합니다. 규모에서 AI는 비싸고, 최적화된 배포와 최적화되지 않은 배포의 간극은 지출에서 몇 배인 경우가 많습니다. ROI는 더 높은 가속기 활용률, 배치와 캐싱을 통한 더 낮은 요청당 비용, 알맞은 크기의 모델, 과잉 프로비저닝 회피에서 나옵니다. 관측 가능성과 평가 파이프라인은 비싼 사고를 막고 안전한 반복을 가능하게 해 보답합니다.

TCO는 가속기 컴퓨트(많은 워크로드에서 가장 큰 항목), 벡터 스토리지, 서빙 인프라, 네트워킹, 그것을 운영할 플랫폼 및 운영 인력에 걸칩니다. 이를 투자하지 않는 비용에 견주어 저울질하십시오. 폭주하는 추론 청구서, 도입을 해치는 나쁜 지연, 확장하지 못함입니다. 정부에서는 주권이나 보안 요건을 충족하지 못하는 비용을 더하십시오. 각자 비싸고 덜 쓰이는 인프라를 만드는 대신 많은 팀이 AI를 효율적으로 배포하게 하는 포장된 길 플랫폼과 성과당 비용 추세를 보여 리더십을 설득하십시오.

안티패턴과 함정

  • 놀고 있는 가속기. 희소한 GPU를 덜 쓰는 팀에 전용으로 배정하는 것.
  • 배치나 캐싱 없음. 모든 요청을 개별로 서빙하고 공유 컨텍스트를 다시 계산하는 것.
  • 기본으로 가장 큰 모델. 작은 모델로 될 곳에 비싼 모델을 쓰는 것.
  • 비용 맹목. 청구서가 도착할 때까지 귀속, 예산, 요청당 비용 가시성이 없는 것.
  • 버전 관리되지 않는 프롬프트. 버전 관리나 평가 관문 없이 프로덕션에서 프롬프트를 바꾸는 것.
  • 꼬리 지연 방치. 사용자가 느린 꼬리를 겪는 동안 평균 지연을 최적화하는 것.
  • 조용한 종속. 이식성 없이 한 제공자의 서빙 스택 위에 깊이 만드는 것.

성숙도 모델

  1. 시작. 가장 크게 요구하는 사람에게 반응하는 즉흥적 GPU 할당, 배치나 캐싱 없음, 청구서가 도착할 때까지 비용 가시성 없음, 라이브로 편집되고 버전 관리되지 않는 프롬프트, 최소한의 모니터링.
  2. 발전. 일부 팀이 공유 스케줄링, 캐싱, 버전 관리되는 프롬프트를 채택하지만 실천은 조직 전반에서 일관되지 않습니다. 한 그룹은 배치하고 평가하는 반면 다른 그룹은 여전히 모든 요청을 개별로 서빙하고 프롬프트를 손으로 바꿉니다.
  3. 표준화. 문서화된 포장된 길 플랫폼이 조직 전체에서 시행됩니다. 쿼터와 우선순위가 있는 공유 스케줄링, 표준 배치, 캐싱, 크기 조정, 검색을 위한 벡터 인프라, 모든 프롬프트나 모델 변경을 관문 통제하는 자동화된 평가 파이프라인, 팀과 사용 사례에 대한 비용 귀속입니다.
  4. 관리. 플랫폼이 기준선에 대해 측정되고 통제됩니다. 가속기 활용률, 유용한 성과당 비용, 꼬리 지연, 검색 재현율, 변경별 품질 회귀가 알림과 임계값과 함께 추적되고, 비용은 각 팀이 소유하며, 변경의 진행 또는 중단은 직관이 아니라 증거로 결정됩니다.
  5. 오케스트레이션. 인프라가 지속적으로 개선되고 적응합니다. 라우팅, 배치, 확장이 라이브 비용과 품질 신호에 맞춰 스스로 튜닝되고, 수요와 제약이 이동함에 따라 팀 사이와 클라우드, 온프레미스, 주권 대상 사이에서 용량이 재균형되며, 이식성이 예행연습되고, 인프라 계획이 제품, 보안, 조달과 통합됩니다.

논의를 위한 아이디어

  • 우선순위 워크로드를 굶기지 않고 가속기 활용률을 어떻게 끌어올립니까?
  • 지연 요건에 맞는 배치와 캐싱의 올바른 균형은 어디입니까?
  • 온프레미스나 주권 배포는 언제 클라우드보다 비용을 정당화합니까?
  • 많은 팀에 걸쳐 AI 지출을 어떻게 귀속하고 통제합니까?
  • 프롬프트나 모델 변경이 프로덕션에 닿는 것을 무엇이 관문 통제해야 합니까?
  • 제공자를 바꿀 수 있을 만큼 서빙 인프라를 어떻게 이식 가능하게 유지합니까?

핵심 요점

  • 가속기는 희소하고 비쌉니다. 의도적으로 스케줄하고, 공유하고, 활용하십시오.
  • 배치, 캐싱, 모델 크기 조정이 비용과 지연의 주요 지렛대입니다.
  • 검색 애플리케이션에는 잘 운영되는 임베딩과 벡터 검색 인프라가 필요합니다.
  • LLMOps(프롬프트 버전 관리, 평가 파이프라인, 관측 가능성)는 생성형 AI의 운영 뼈대입니다.
  • 비용을 관찰 가능하게 관리하고 종속을 피하도록 이식성을 보존하십시오.

참고 문헌과 더 읽을거리

  • Chip Huyen, Designing Machine Learning Systems.
  • Google, Site Reliability Engineering (Beyer, Jones, Petoff, Murphy, editors).
  • Jared Kaplan et al., Scaling Laws for Neural Language Models.
  • Reza Yazdani Aminabadi et al., DeepSpeed Inference: Enabling Efficient Inference of Transformer Models at Unprecedented Scale.
  • Woosuk Kwon et al., Efficient Memory Management for Large Language Model Serving with PagedAttention (vLLM).
  • Andriy Burkov, Machine Learning Engineering.