이것은 사용자가 2024-8-29 13:07에 https://www.reddit.com/r/mlops/comments/1do2lqx/reflections_on_working_with_100s_of_ml_platform/을(를) 위해 저장한 이중 언어 스냅샷 페이지로, 몰입형 번역에 의해 제공된 이중 언어 지원이 있습니다. 저장하는 방법을 알아보세요?
Skip to main content Reflections on working with 100s of ML Platform teams : r/mlops
Go to mlops

Reflections on working with 100s of ML Platform teams
100개 이상의 ML 플랫폼 팀과 함께 일한 소감

Tales From the Trenches

Having worked with numerous MLOps platform teams—those responsible for centrally standardizing internal ML functions within their companies—I have observed several common patterns in how MLOps adoption typically unfolds over time. Having seen Uber write about the evolution of their ML platform recently, it inspired me to write my thoughts on what I’ve seen out in the wild:
회사 내부의 머신러닝 기능을 중앙에서 표준화하는 역할을 담당하는 수많은 머신러닝 플랫폼 팀과 함께 일하면서, 시간이 지남에 따라 머신러닝 도입이 일반적으로 어떻게 전개되는지에 대한 몇 가지 공통된 패턴을 관찰했습니다. 최근 Uber가 ML 플랫폼의 진화에 대해 쓴 글을 보고 제가 현장에서 본 것에 대한 제 생각을 적어보려고 했습니다:

🧱 Throw-it-over-the-wall → Self-serve data science
🧱 벽에 던져 넣기 → 셀프 서비스 데이터 과학

Usually, teams start with one or two people who are good at the ops part, so they are tasked with deploying models individually. This often involves a lot of direct communication and knowledge transfer. This pattern often forms silos, and over time teams tend to break them and give more power to data scientists to own production. IMO, the earlier this is done, the better. But you’re going to need a central platform to enable this.
일반적으로 팀은 운영 파트에 능숙한 한두 명으로 시작하기 때문에 개별적으로 모델을 배포하는 임무를 맡게 됩니다. 여기에는 종종 많은 직접적인 커뮤니케이션과 지식 전달이 수반됩니다. 이러한 패턴은 종종 사일로를 형성하며, 시간이 지남에 따라 팀은 사일로를 깨고 데이터 과학자에게 더 많은 권한을 부여하여 프로덕션을 소유하게 되는 경향이 있습니다. 이러한 작업은 빠르면 빠를수록 좋습니다. 하지만 이를 가능하게 하려면 중앙 플랫폼이 필요합니다.

Tools you could use: ZenML, AWS Sagemaker, Google Vertex AI
사용할 수 있는 도구: ZenML, AWS Sagemaker, Google Vertex AI

📈 Manual experiments → Centralized tracking
📈 수동 실험 → 중앙 집중식 추적

This is perhaps the simplest possible step a data science team can take to 10x their productivity → Add an experiment tracking tool into the mix and you go from non-centralized, manual experiment tracking and logs to a central place where metrics and metadata live.
데이터 과학 팀이 생산성을 10배로 높이기 위해 취할 수 있는 가장 간단한 단계 → 실험 추적 도구를 추가하면 비중앙 집중식 수동 실험 추적 및 로그에서 메트릭과 메타데이터가 있는 중앙 위치로 이동할 수 있습니다.

Tools you could use: MLflow, CometML, Neptune
사용할 수 있는 도구: MLflow, CometML, Neptune

🚝 Mono-repo → Shared internal library
🚝 모노 리포 → 공유 내부 라이브러리

It’s natural to start with one big repo and throw all data science-related code in it. However, as teams mature, they tend to abstract commonly used patterns into an internal (pip) library that is maintained by a central function and in another repo. Also, a repo per project or model can also be introduced at this point (see shared templates).
하나의 큰 리포지토리에서 시작하여 모든 데이터 과학 관련 코드를 그 안에 넣는 것은 자연스러운 일입니다. 하지만 팀이 성숙해지면 일반적으로 사용되는 패턴을 중앙 기능과 다른 리포지토리에 의해 유지 관리되는 내부(pip) 라이브러리로 추상화하는 경향이 있습니다. 또한, 이 시점에서 프로젝트 또는 모델별 리포지토리를 도입할 수도 있습니다(공유 템플릿 참조).

Tools you could use: Pip, Poetry
사용할 수 있는 도구: Pip, Poetry

🪣 Manual merges → Automated CI/CD
🪣 수동 병합 → 자동화된 CI/CD

I’ve often seen a CI pattern emerge quickly, even in smaller startups. However, a proper CI/CD system with integration tests and automated model deployments is still hard to reach for most people. This is usually the end state → However, writing a few GitHub workflows or Gitlab pipelines can get most teams starting very far in the process.
저는 소규모 스타트업에서도 CI 패턴이 빠르게 나타나는 것을 종종 보았습니다. 하지만 통합 테스트와 자동화된 모델 배포를 갖춘 적절한 CI/CD 시스템은 아직 대부분의 사람들에게 도달하기 어렵습니다. 이것이 보통 최종 상태 → 하지만 몇 가지 GitHub 워크플로 또는 Gitlab 파이프라인을 작성하면 대부분의 팀이 프로세스의 시작 단계에 도달할 수 있습니다.

Tools you could use: GitHub, Gitlab, Circle CI
사용할 수 있는 도구: GitHub, Gitlab, Circle CI

👉 Manually triggered scripts → Automated workflows
👉 수동 트리거 스크립트 → 자동화된 워크플로

Bash scripts that are hastily thrown together to trigger a train.py are probably the starting point for most teams, but very quickly teams can outgrow these. It’s hard to maintain, intransparent, and flaky. A common pattern is to transition to ML pipelines, where steps are combined together to create workflows that are orchestrated locally or on the cloud.
대부분의 팀에서 train.py를 트리거하기 위해 급하게 만든 Bash 스크립트가 시작점일 수 있지만, 팀들은 금방 이보다 더 큰 스크립트를 만들 수 있습니다. 유지 관리가 어렵고 투명하지 않으며 불안정하기 때문입니다. 일반적인 패턴은 여러 단계를 결합하여 로컬 또는 클라우드에서 오케스트레이션되는 워크플로를 만드는 ML 파이프라인으로 전환하는 것입니다.

Tools you could use: Airflow, ZenML, Kubeflow
사용할 수 있는 도구: Airflow, ZenML, Kubeflow

🏠 Non-structured repos → Shared templates
🏠 비정형 리포지토리 → 공유 템플릿

The first repo tends to evolve organically and contains a whole bunch of stuff that will be pruned later. Ultimately, a shared pattern is introduced and a tool like cookie-cutter or copier can be used to distribute a single standard way of doing things. This makes onboarding new team members and projects way easier.
첫 번째 리포지토리는 유기적으로 진화하는 경향이 있으며 나중에 정리될 많은 내용을 담고 있습니다. 궁극적으로 공유 패턴이 도입되고 쿠키 커터나 복사기와 같은 도구를 사용하여 하나의 표준 작업 방식을 배포할 수 있습니다. 이렇게 하면 새로운 팀원과 프로젝트를 훨씬 쉽게 온보딩할 수 있습니다.

Tools you could use: Cookiecutter, Copier
사용할 수 있는 도구: 쿠키 커터, 복사기

🖲️ Non-reproducible artifacts → Lineage and provenance
🖲️ 재현할 수 없는 아티팩트 → 계보 및 출처

At first, no artifacts are tracked in the ML processes, including the machine learning models. Then the models start getting tracked, along with experiments and metrics. This might be in the form of a model registry. The last step in this is to also track data artifacts alongside model artifacts, to see a complete lineage of how a ML model was developed.
처음에는 머신 러닝 모델을 포함하여 ML 프로세스에서 아티팩트가 추적되지 않습니다. 그런 다음 모델이 실험 및 메트릭과 함께 추적되기 시작합니다. 이는 모델 레지스트리의 형태일 수 있습니다. 마지막 단계는 모델 아티팩트와 함께 데이터 아티팩트도 추적하여 ML 모델이 어떻게 개발되었는지에 대한 전체 계보를 확인하는 것입니다.

Tools you could use: DVC, LakeFS, ZenML
사용할 수 있는 도구: DVC, LakeFS, ZenML

💻 Unmonitored deployments → Advanced model & data monitoring
💻 모니터링되지 않는 배포 → 고급 모델 및 데이터 모니터링

Models are notoriously hard to monitor - Whether its watching for spikes in the inputs or seeing deviations in the outputs. Therefore, detecting things like data and concept drift is usually the last puzzle piece to fall as teams mature into full MLOps maturity. If you’re automatically detecting drift and taking action, you are in the top 1% of ML teams.
모델은 입력의 급격한 증가를 감시하거나 출력의 편차를 확인하는 등 모니터링하기 어려운 것으로 악명이 높습니다. 따라서 데이터 및 개념의 편차와 같은 것을 감지하는 것은 일반적으로 팀이 완전한 MLOps 성숙 단계에 접어들면서 마지막으로 해결해야 할 퍼즐 조각입니다. 드리프트를 자동으로 감지하고 조치를 취하고 있다면 상위 1%의 ML 팀에 속하는 것입니다.

Tools you could use: Evidently, Great Expectations
사용할 수 있는 도구: 분명히 큰 기대가 있습니다.

Have I missed something? Please share other common patterns, I think its useful to establish a baseline of this journey from various angles.
제가 놓친 것이 있나요? 다른 일반적인 패턴을 공유해 주세요. 다양한 각도에서 이 여정의 기준을 설정하는 것이 유용하다고 생각합니다.

Disclaimer: This was originally a post on the ZenML blog but I thought it was useful to share here and was not sure whether posting a company affiliated link would break the rules. See original blog here: https://www.zenml.io/blog/reflections-on-working-with-100s-of-ml-platform-teams
면책 조항: 원래 ZenML 블로그에 게시된 글이었으나, 회사 제휴 링크를 게시하는 것이 규칙을 위반하는 것인지 확실하지 않아 여기서 공유하는 것이 유용할 것 같아서 공유하게 되었습니다. 여기에서 원본 블로그를 참조하세요: https://www.zenml.io/blog/reflections-on-working-with-100s-of-ml-platform-teams

You will never turn off your computer again. No Install. Play for free.
Clickable image which will reveal the video player: You will never turn off your computer again. No Install. Play for free.


Sort by:
Best
Open comment sort options

Great info thanks!  좋은 정보 감사합니다!

Thank you!!  감사합니다!!

More replies

Awesome. I work in programming across research primarily and I am obsessed with the ops part to automate what can be automated. This is great.
굉장하네요. 저는 주로 연구 전반에 걸쳐 프로그래밍을 하고 있으며, 자동화할 수 있는 부분을 자동화하기 위해 운영 부분에 집착하고 있습니다. 정말 대단하네요.

Thank you!!  감사합니다!!

More replies

you missed main parts about data
데이터에 대한 주요 부분을 놓쳤습니다.

What about data did I miss
놓친 데이터는 무엇인가요?

More replies

Gotta ask you on how is KServe doing these days compared to other deployment options. Is it still a good choice for starting out on <10 ML services (which, to be fair can definitely be self-managed by a bunch of Flask-based containers/pods on K8s) or only needed at scale.
다른 배포 옵션과 비교했을 때 요즘 KServe는 어떻게 진행되고 있는지 궁금합니다. 여전히 <10 ML 서비스를 시작하기에 좋은 선택인지(공정하게 말하자면, K8의 Flask 기반 컨테이너/팟으로 자체 관리할 수 있음) 아니면 대규모로만 필요한지 궁금합니다.

I’d say 10 is a good number to start introducing some sort of automated inference tooling. I like BentoML the most in that space but seldon and kserve are also relatively mature in that space. Kserve had a rough patch where it split up from Kubeflow and many people lost faith at that point AFAIK… but there seems to some activity in the GitHub recently so maybe it’s more you should try it out and see if it fits
자동화된 추론 툴을 도입하기 시작하기에 10은 좋은 숫자라고 생각합니다. 저는 이 분야에서 BentoML을 가장 좋아하지만, seldon과 kserve도 이 분야에서 비교적 성숙해졌습니다. Kserve는 Kubeflow에서 분리되는 거친 패치가 있었고 많은 사람들이 그 시점에서 믿음을 잃었습니다... 하지만 최근 GitHub에서 약간의 활동이 있는 것 같으니 사용해보시고 적합 여부를 확인해 보시는 것이 좋을 것 같습니다.

More replies