I Gave Two AI Supercomputers a Real Job

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

I Gave Two AI Supercomputers a Real Job를 중심으로, Turnstone은 모델 서비스와 작업 노드를 연결하는 하네스로, 작업 배정·역할별 에이전트 생성·감사 과정을 묶는다. 작업 실행를 핵심 판단 포인트로 압축 정리한다.

📌 핵심 요점

1. Turnstone은 모델 서비스와 작업 노드를 연결하는 하네스로, 작업 배정·역할별 에이전트 생성·감사 과정을 묶는다. 작업 실행 장치와 AI 추론 장치는 서로 달라도 된다.
2. 실제 과제로 Windows 개발 환경 설치 저장소의 ARM 대응 브랜치 작성과 Code Needle의 테스트 파일 토큰 수 문제 수정을 맡겼다. 작업과 하위 작업, 토큰 사용량을 살펴볼 수 있는 화면도 시연했다.
3. DGX Station과 RTX Pro 6000 8개를 탑재한 Grando의 강점은 다르다. 영상은 DGX Station의 HBM 대역폭과 Grando의 GPU 메모리 수용 능력을 비교하며, 모델 크기와 구조에 따라 결과가 달라진다고 설명한다.
4. Windows ARM 작업을 같은 모델과 유사한 프롬프트로 실행한 결과, 영상에서 보고한 총 소요 시간은 DGX Station 21분, Grando 37분이었다. 입력 토큰은 각각 약 2,600만 개와 2,300만 개로, 작업량까지 동일한 비교는 아니었다.
5. 경제성의 핵심은 높은 이용률이다. 영상은 개발팀의 동시 작업, 개인정보 보호 요구, 클라우드 상위 모델과 로컬 작업자 모델의 분업을 활용 사례로 제시하며, 장비를 지속적으로 가동해야 비용을 따져볼 수 있다고 말한다.

🧩 배경과 문제 정의

영상은 두 AI 슈퍼컴퓨터를 실제 업무에 어떻게 활용할 수 있는지 묻는다. 비교 대상은 RTX Pro 6000 8개를 탑재한 Grando와 DGX Station이며, Wendell이 Turnstone을 이용해 모델 서비스와 여러 작업 노드를 연결하는 방법을 시연한다.

진행자는 여러 장치에 분산해 실행하던 코딩 세션의 배정을 자동화하고 싶어 한다. 구체적인 과제는 x86 중심의 Windows 개발 환경 설치 저장소를 ARM에 맞게 바꾸는 일과, LLM 코드 벤치마크 저장소의 버그를 수정하는 일이다. 영상은 이 과정에서 작업 분업과 감사, 메모리 구조에 따른 성능 차이, 로컬 실행의 비용 조건을 살펴본다.

🕒 시간순 섹션별 상세정리

1. 두 장비 소개와 운영 환경

• Wendell이 Turnstone으로 실제 작업을 수행하는 방법을 보여준다. 하드웨어 비교의 출발점은 RTX Pro 6000 8개와 DGX Station이다. [00:28]
• 진행자는 실내에서 약 6,000W의 열이 발생한다고 말하고, 보조 배터리에 연결한 장비의 소비전력과 잔량도 보여준다. 별도 공간의 소음 때문에 문을 닫았다고 보여준다. [01:06]
• 장비는 화면 없이 원격으로 운영한다. 관리 포트에서 센서·로그·BIOS와 KVM을 확인하고 전원을 켜는 과정을 시연한다. [01:45]

2. 여러 모델을 묶는 서비스 광고

• 진행자는 연구·코딩·긴 컨텍스트·이미지·영상 작업에 따라 모델을 바꿔 쓴다고 설명하며 Abacus AI의 ChatLLM을 보여준다. [02:15]
• 모델 자동 선택, 에이전트, 앱 제작과 호스팅 등을 홍보하고 월 10달러부터 시작한다고 안내한다. 이 구간은 이후 Turnstone 실습과 구분되는 광고성 소개다. [03:00]

3. Turnstone 설치와 모델·역할 설정

• 저장소를 복제하고 Mac에 Turnstone을 설정하도록 요청한다. 홈 디렉터리가 삭제됐다는 말 뒤에는 실제로 그러지 않았다는 확인이 계속된다. [03:27]
• 여러 DGX Spark에 분산하던 코딩 세션을 한곳에서 요청하고, 실행 위치를 자동으로 고르는 구성을 원한다고 보여준다. 모델은 기본 URL로 연결하고 추가할 수 있다. [04:08]
• 요청별 모델 배정, 역할별 페르소나, MCP 서버 활용, 글쓰기 선호와 기억 저장 기능을 보여준다. [04:40]

4. 작업 노드와 Windows ARM 과제 정의

• 현재 노드는 Docker 안에서 제한적으로 동작하며 공유 작업 공간은 아직 연결하지 않았다고 보여준다. 관리·조율 역할이 작업자와 평가자를 만들어 프로젝트를 진행한다. [05:04]
• 기존 Windows 개발 환경 설치 저장소가 x86에서는 동작하지만 ARM에서는 문제가 있어, ARM 대응용 별도 브랜치를 요청한다. [05:44]
• Python·Node를 포함한 설치 소프트웨어를 조사하고 ARM 대응 경로를 만들도록 구체적으로 지시한다. 노드 배정은 자동으로 이뤄지며, Grando의 모델 서비스를 이용하고 감사자도 추가한다. [06:48]

5. Code Needle 버그 수정의 병행 실행

• 두 번째 과제는 LLM 코드 벤치마크인 Code Needle의 버그 조사다. 생성된 테스트 파일이 파일명에 표시된 값보다 많은 토큰을 사용하는 문제를 수정하도록 요청한다. [07:22]
• 두 작업을 Grando에서 동시에 실행한다. 진행자들은 DGX Station과 RTX Pro 6000 8개 구성 중 어느 쪽이 유리한지는 업무에 따라 달라진다고 드러낸다. [07:35]

6. 메모리 구조와 모델별 성능 차이

• HBM에 전부 올라가는 모델의 빠른 생성 속도를 보여준다. 영상에서는 DGX Station의 HBM을 252GB, 전체 통합 메모리를 748GB로 설명하며, HBM 밖의 메모리를 사용하면 속도가 낮아질 수 있다고 드러낸다. [08:07]
• HBM3e·LPDDR5·GDDR7의 대역폭과 GPU 사이 PCIe 연결을 비교한다. MoE 모델에서는 일부 구성 요소를 느린 메모리에 배치할 수 있다는 설명도 덧붙인다. [08:48]
• 약 614GB 모델과 DeepSeek 계열 결과를 소개하며 모델의 메모리 배치에 따른 차이를 논한다. 특히 HBM의 프리필, 즉 입력 프롬프트 처리 성능을 강조한다. [10:04]

7. 다중 사용자 처리량과 모델 분업

• 장비를 개발팀이나 개인정보 보호 중심 업무에 활용하려면 다중 사용자 처리량을 봐야 한다고 보여준다. 예시로 초당 약 3,800토큰과 2,000토큰을 넘는 처리량을 언급한다. [10:41]
• Claude Opus 같은 상위 모델이 관리하고 로컬 모델 작업자 8~10개가 기본 업무를 수행하는 구성을 제안한다. 로컬 작업자에게 단위 테스트·통합 테스트·개발 작업을 맡길 수 있다고 보여준다. [11:25]
• 진행자는 벤치마크 수치를 별도 링크로 제공하겠다고 안내한다. 해당 링크의 원본 자료는 이번 입력에 포함되지 않았다. [11:31]

8. 영상 생성과 작업 감사 화면

• H3로 영상 생성을 시도하며, 작은 모델이 HBM에 들어가기 때문에 DGX Station에서 더 빠르게 실행된다고 보여준다. 5초 클립 생성에 약 2분이 걸렸다고 드러낸다. [12:03]
• 생성된 영상들을 보며 추가 동작을 요청하고 결과를 확인한다. 이 구간은 코딩 외의 장비 활용 사례를 보여준다. [12:42]
• Turnstone의 작업·하위 작업 화면에서 수행 과정을 살펴본다. 해결책을 찾았다는 표시와 약 1만 5,000토큰 사용량, 하위 작업별 사용량을 확인한다. [13:04]

9. Spark 작업자 클러스터와 실행 권한

• Wendell은 DGX Spark와 Dell GB10 장치들에서 작은 모델과 평가용 Judge 모델을 운영하고, 큰 모델은 별도 대형 장비에서 실행하는 구성을 보여준다. [13:34]
• Spark에서 Docker를 사용하거나 셸에서 직접 작업을 실행할 수 있다고 보여준다. 직접 실행하면 Docker 샌드박스보다 실제 장치에 더 넓게 접근할 수 있다. [13:58]
• 작업 노드의 하드웨어 종류는 고정되지 않는다. AI 추론이 다른 곳에서 실행된다면 작업자 장치 자체가 AI 전용 장비일 필요도 없다고 보여준다. [14:10]

10. DGX Station 추가와 ARM 감사 결과

• DGX Station을 두 번째 모델 서비스로 추가한다. 기본 URL을 입력한 뒤 인증키가 필요하다는 오류를 확인하고, 모델을 연결해 다른 장비의 모델을 작업별로 선택한다. [15:04]
• 저장소 이슈 중 빠르게 해결할 수 있는 것을 평가하도록 요청한다. executive 역할은 작업자들을 지켜보지만 직접 도구를 사용하지 못하며, Turnstone 자체는 작은 장치에서도 실행할 수 있다고 보여준다. [15:37]
• Windows ARM 감사 결과에서 Firefox·OBS Studio·7Zip·Cinebench 등의 검토 항목을 확인한다. Chocolatey의 x64 설치 경로 대신 다른 설치 경로를 논의하고, Python의 ARM64 선택을 바꿀 수 있다고 보여준다. [16:33]

11. 실제 작업 시간 비교와 비용 결론

• 같은 모델과 거의 같은 프롬프트로 DGX Station에 작업을 다시 맡기되 별도 브랜치를 만들도록 한다. 진행자는 완전한 일대일 비교가 어렵다고 밝히고 두 장비가 만든 브랜치를 보여준다. [17:04]
• Turnstone 화면에 작업 시간이 바로 표시되지 않아 데이터베이스를 조사했다. 보고된 입력 토큰은 DGX Station 약 2,600만 개, Grando 약 2,300만 개이며, 총 소요 시간은 각각 21분과 37분이다. [17:22]
• Grando는 Wendell의 추가 실험을 위해 이동하고 DGX Station은 ASUS에 반환한다고 알린다. Windows ARM 작업의 클라우드 비용을 캐시 사용 시 약 5~36달러, 미사용 시 약 24~240달러로 추정하며, 개발팀이 지속적으로 가동할 때 도입 경제성을 계산해야 한다는 말로 마무리한다. [18:23]

🧾 결론

• 실제 개발 과제를 통해 두 장비를 활용하는 흐름을 보여줬으며, Turnstone의 작업 분해와 감사 기능이 그 연결 고리였다.
• 장비 선택은 단일 사용자의 생성 속도뿐 아니라 모델의 메모리 배치, 프롬프트 처리, 동시 사용자 처리량을 함께 봐야 한다.
• 브랜치 생성과 감사 보고서는 확인됐지만, 변경된 설치 스크립트가 실제 Windows ARM 환경에서 끝까지 정상 동작했는지는 제공된 전사만으로 확인되지 않는다.
• 21분과 37분이라는 결과는 해당 시연의 관측값이다. 이를 모든 모델과 개발 작업에 적용할 수 있는 성능 비율로 해석하기는 어렵다.

📈 투자·시사 포인트

• 로컬 AI 장비의 도입 판단에는 구매비와 함께 전력·발열·소음, 운영 부담, 실제 이용률을 반영해야 한다. 영상에서도 두 장비의 전력과 열 부담을 직접 언급한다.
• 고성능 클라우드 모델이 관리하고 로컬 모델 여러 개가 기본 개발 작업을 수행하는 구성이 제안된다. 이 경우 비용 절감 가능성은 작업자 모델의 품질과 검수 부담에 좌우된다.
• 영상의 Windows ARM 작업 비용 추정은 프롬프트 캐시 사용 시 약 5~36달러, 미사용 시 약 24~240달러다. 영상 당시 가격을 적용한 추정이므로 구매 판단에는 자신의 모델·캐시 조건을 다시 대입해야 한다.
• 팀 단위 동시 처리와 민감한 코드의 로컬 처리가 필요한 조직은 검토할 이유가 있다. 반면 간헐적인 작업만으로 고가 장비의 투자비를 회수할 수 있다는 근거는 제시되지 않았다.

⚠️ 불확실하거나 확인이 필요한 부분

• 하드웨어 비교는 완전히 통제된 실험이 아니다. 진행자도 일대일 비교의 어려움을 인정했으며, 두 실행의 입력 토큰 수와 생성 브랜치 지시가 달랐다.
• Windows ARM 브랜치와 감사 결과는 소개됐지만, 실제 ARM 장치에서 설치·실행 검증을 통과했다는 결과는 전사에 없다. Code Needle 수정 역시 최종 테스트 결과가 구체적으로 제시되지 않는다.
• 모델명과 제품명에 전사 표기 혼선이 있다. 메모리 용량·대역폭·처리량도 영상 발언에 근거한 수치이며, 제공 자료에는 원본 결과표나 세부 측정 조건이 없다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• Windows ARM 대응 변경사항을 검토하고 Python·Node 및 각 설치 패키지의 아키텍처 선택이 올바른지 실제 ARM 환경에서 확인한다.
• 같은 저장소 상태·모델·프롬프트·완료 기준으로 반복 실행해 작업 시간, 입력·출력 토큰, 결과 품질을 함께 기록한다.
• 단일 사용자 속도와 별도로 예상 팀 규모의 동시 작업을 실행해 처리량과 대기 시간을 측정한다.
• 작업 노드의 공유 작업 공간, Docker 격리 범위, 직접 셸 실행 권한과 모델 서비스 인증키를 점검한다.

❓ 열린 질문

• 두 장비가 같은 완료 기준과 검증 절차를 적용받았을 때도 작업 시간 차이가 반복되는가?
• 실제 개발팀의 작업량과 캐시 조건에서 장비 투자비를 회수하려면 어느 정도의 지속 이용률이 필요한가?
• 로컬 작업자 모델이 맡을 수 있는 업무 범위와 상위 모델의 검수 비용은 어떻게 달라지는가?