이 말인 즉슨 최소 13000의 react 앱이 메타 내부에서 굴러간다는데 메타가 리액트를 놓지 못하고 계속 끌고가야하는 동기가 엿보이네요
다른 라이브러리들은 너도나도 signal 도입하는데 리액트는 못하고 리액트 컴파일러까지 만들어가면서 리렌더링 붙잡고 있는 현황도
문득 혹시나 내부 코어 라이브러리가 dom 리렌더링에 의존하는 식으로 짜여져있어서 쉽사리 못바꾸는 건 아닐까 하는 생각이 드네요
좋은 지적 감사합니다. DRIFT를 단순히 큰 모델을 어떻게든 돌리는 도구로 보면 CPU/SSD offloading과 비교하게 되는데, 그 축에서 DRIFT가 이긴다고 주장하진 않습니다. 단일 머신에서 느려도 돌아가기만 하면 되는 경우엔 offloading이 더 단순하고 현실적일 수 있겠습니다. 다만 글에서도 언급했듯 본 프로젝트가 추구하는 목적은 조금 다릅니다. CPU나 SSD로 밀어내는 대신 서로 다른 머신에 레이어를 나눠 올리고 hidden state만 주고받으면서, 분산 실행 결과가 단일 머신 결과와 같은지 검증하는 쪽에 초점을 둔 프로젝트입니다. 즉 “큰 모델 실행”보다는 “서로 다른 개인 장비 간 정확한 레이어 분산 추론”이 핵심입니다.
서울-뉴욕 예시는 말씀하신 대로 인터랙티브 latency 관점에서는 좋은 실전 예시가 아닌 거는 분명합니다. 장거리에서는 느려집니다. 현재 레포 자체의 현실적인 타깃은 LAN, 같은 지역, 개인 장비 조합이고, 서울-뉴욕은 DRIFT가 이상향으로 바라보는 탈중앙화의 가능성을 보여주는 그림에 가깝습니다.
문서 톤이 AI스럽다는 피드백은 리드미에 관해서 주의할 필요가 있을 것 같네요. 기술적으로 보여줘야 할 건 결국 숫자, 제약, 비교 같은 부분인데 표현이 좀 과하게 간 부분이 있는 것 같네요. 한번 담백하게 정리해보겠습니다.
저도 비슷하게 느끼고 있었는데... 모델성능 믿고 너무 하는거 같아요... 모델도 점점 클라우드 툴 위주로 트레이닝 시켜서 다른 하네스에서는 성능이 떨어지고 실수도하고 그러네요. 그리고 API KEY 구매해서 쓰도록 유도하도록 트레이닝 된거 같은 느낌도 Fable 쓰면서는 많이 받았어요.
오 필요했는데 감사합니다
맞습니다. "추적보다 예방"이 더 현실적이더라고요.
저희도 비슷한 방향으로 가고 있습니다.
각 에이전트마다 할 수 있는 것 / 할 수 없는 것을
명시적으로 정해두는 방식인데요 —
범위 자체를 좁히면 사후 추적 부담도 줄더라고요.
CLI로 제한하신다고 하셨는데,
에이전트 여러 개가 순서대로 작업할 때도
각각 별도 CLI 제한을 두시나요?
저희가 딱 그 지점에서 막혀있어서요.
cli로 수정과 책임 범위를 줄입니다. ai에 맏기면 확율이라 오류나 환각을 피할 수 없습니다.
q8_0은 너무 크고 Q4-K_XL~Q6-K_XL도 큰 품질하락 없이 좋다고 생각합니다. 조금 더 조이면 32GB램 안에서도 잘 돌아가서요
ai agent 개발이 더뎌진다는데 왜 ai 개발 생산성에 대한 논의 댓글만 한가득인지 아시는분
그렇게 사람 많은데, 페이스북은 왜 스팸도 많고, 광고도 너무 많고, 기능은 제한적이고 그런지 모르겠네요
저도 그 사이트가 좀 아쉽긴 한데 좋은 사례라 넣어봤습니다.
아마 이 분야에서도 니치한 기회가 더 나오지 않을까 싶기도 하고요.
GOATY? 뭐지? 하면서
스트라바 체스닷컴 가민이랑 견줄만한 뭔가 잇구나? 하는 맘에 신나서 찾아봤는데
클로드로 급조한 사이트 느낌이 드는건....왜일까...요 ㅠㅠ
이 말인 즉슨 최소 13000의 react 앱이 메타 내부에서 굴러간다는데 메타가 리액트를 놓지 못하고 계속 끌고가야하는 동기가 엿보이네요
다른 라이브러리들은 너도나도 signal 도입하는데 리액트는 못하고 리액트 컴파일러까지 만들어가면서 리렌더링 붙잡고 있는 현황도
문득 혹시나 내부 코어 라이브러리가 dom 리렌더링에 의존하는 식으로 짜여져있어서 쉽사리 못바꾸는 건 아닐까 하는 생각이 드네요
좋은 지적 감사합니다. DRIFT를 단순히 큰 모델을 어떻게든 돌리는 도구로 보면 CPU/SSD offloading과 비교하게 되는데, 그 축에서 DRIFT가 이긴다고 주장하진 않습니다. 단일 머신에서 느려도 돌아가기만 하면 되는 경우엔 offloading이 더 단순하고 현실적일 수 있겠습니다. 다만 글에서도 언급했듯 본 프로젝트가 추구하는 목적은 조금 다릅니다. CPU나 SSD로 밀어내는 대신 서로 다른 머신에 레이어를 나눠 올리고 hidden state만 주고받으면서, 분산 실행 결과가 단일 머신 결과와 같은지 검증하는 쪽에 초점을 둔 프로젝트입니다. 즉 “큰 모델 실행”보다는 “서로 다른 개인 장비 간 정확한 레이어 분산 추론”이 핵심입니다.
서울-뉴욕 예시는 말씀하신 대로 인터랙티브 latency 관점에서는 좋은 실전 예시가 아닌 거는 분명합니다. 장거리에서는 느려집니다. 현재 레포 자체의 현실적인 타깃은 LAN, 같은 지역, 개인 장비 조합이고, 서울-뉴욕은 DRIFT가 이상향으로 바라보는 탈중앙화의 가능성을 보여주는 그림에 가깝습니다.
문서 톤이 AI스럽다는 피드백은 리드미에 관해서 주의할 필요가 있을 것 같네요. 기술적으로 보여줘야 할 건 결국 숫자, 제약, 비교 같은 부분인데 표현이 좀 과하게 간 부분이 있는 것 같네요. 한번 담백하게 정리해보겠습니다.
단순 큰 모델 돌리는게 목적이라면
CPU ,SSD오프로딩 대비 이점이 있나요?
첫화면에 서울 뉴욕 예시 들어져 있는데 레이턴시 생각하면 현실성 있는지도 모르겠고
문서도 ai삘이 너무 과하네요.
6년 전에 같은 사이트가 올라왔었는데요. 글 내용은 더 짧지만, 그 글이 더 좋은 거 같아요. 그 글은 올려주신 분의 의도와 마음과 생각이 전달 되어서 그런지.
오픈 소스 어플리케이션의 아키텍쳐
"Meta 내부에서 (중략) 13,000개 이상의 앱을 구동하며.
엄청나군요. 소비자로써는 숏폼 늘고, 광고 빈도 많이 늘어난거 빼곤, 10년 전이나, 5년 전이나, 지금이나 별 다른거 없어 보이는데.
감사합니다. 덕분에 잘 적용했습니다.
과연 애플이 할까요?
팝콘 팔아야 하나요? ㅎㅎㅎ
번역서가 있었군요.
감사합니다.
저도 비슷하게 느끼고 있었는데... 모델성능 믿고 너무 하는거 같아요... 모델도 점점 클라우드 툴 위주로 트레이닝 시켜서 다른 하네스에서는 성능이 떨어지고 실수도하고 그러네요. 그리고 API KEY 구매해서 쓰도록 유도하도록 트레이닝 된거 같은 느낌도 Fable 쓰면서는 많이 받았어요.
정말 감사합니다 !
굉장하네요 스타눌렀어요
애플 같은 느낌이네요, 성능은 좋은데 생태계는 닫고 자기 플랫폼 안에서만 돌게 묶는