기존 서버에 PCIe 카드만 꽂으면 바로 운영될 것 같지만, 부팅 후 GPU가 인식되지 않거나 전원·냉각·ROCm 호환성에서 막힐 수 있습니다.
호환 서버와 지속 부하, ROCm 운영 역량이 모두 확인된 팀은 업그레이드를 검토하고, 그중 하나라도 불확실하면 먼저 단기 AI 대여로 시험하는 편이 안전합니다.
이 글은 기존 서버에 AI 추론 용량을 추가하려는 기업 IT 팀을 위한 안내서입니다. AMD GPU 자립을 검토하는 초기 기업과, 이전 위험 및 장기 인프라 비용을 통제해야 하는 플랫폼 책임자도 대상입니다.
AMD Instinct MI350P 서버 업그레이드는 카드 구매보다 조건 확인이 먼저입니다
AMD는 MI350P를 기존 인프라에 배치할 수 있는 PCIe 카드로 소개하고 있습니다. 그러나 “PCIe GPU”라는 외형만으로 기존 서버와의 호환성이 보장되지는 않습니다. MI350P는 수동 냉각 방식이며, 최대 보드 전력은 600 W, 설정 가능한 일반 보드 전력은 450 W입니다. 전원 공급 장치와 서버 팬 설계가 데이터센터용 가속기를 전제로 하지 않았다면 장시간 추론에서 열 제한이나 장애가 발생할 수 있습니다. AMD 공식 MI350P 제품 사양
공식 사양상 MI350P는 144 GB HBM3E, 최대 메모리 대역폭 4 TB/s, PCIe 5.0 x16, 이중 슬롯 구조를 사용합니다. 길이는 267 mm이며 운영체제 지원 범위는 리눅스 엑스여섯십사 비트로 기재되어 있습니다. 이 수치는 카드 자체의 조건이지, 네가 보유한 서버가 해당 조건을 만족한다는 뜻은 아닙니다. AMD MI350P 상세 사양
실제 검토에서는 다음 제한을 따로 확인해야 합니다.
- 전원 제한: 그래픽 카드용 보조 전원 케이블이 있어도 12V-2x6 연결과 서버 제조사의 전원 구성이 일치해야 합니다.
- 냉각 제한: 수동 냉각 카드는 서버 내부의 전면 흡기와 후면 배기가 충분해야 합니다. 일반 워크스테이션에 넣는 방식으로 판단하면 안 됩니다.
- 슬롯과 펌웨어: 물리적인 x16 슬롯, 슬롯 간격, 바이오스의 대형 자원 할당, 리눅스 커널과 드라이버 조합을 함께 확인해야 합니다.
- 네트워크 병목: 추론 서버가 모델 저장소나 다른 노드에서 가중치를 자주 가져오면 GPU보다 네트워크와 저장 장치가 먼저 한계에 도달할 수 있습니다.
- 보증 책임: 기존 서버에 비공식 부품을 추가하면 장애 발생 시 서버 제조사와 카드 공급자 중 누가 원인을 분석할지 불명확해질 수 있습니다.
- 정지 시간: 카드 설치만이 아니라 펌웨어, 운영체제, 컨테이너, 모니터링 구성을 검증하는 작업이 필요합니다.
기존 AI 서버에 MI350P를 바로 설치해도 되나요?
가능 여부는 카드가 아니라 서버 모델, 전원 구성, 냉각 방식, 슬롯 배치와 제조사 호환 목록으로 판단해야 합니다. AMD의 제품 페이지가 “기존 인프라” 배치를 설명하더라도, 특정 서버 모델의 판매 상태와 지원 범위까지 대신 보증하지는 않습니다. 따라서 서버 제조사의 호환 목록과 실제 공급자의 납품 조건을 함께 확인해야 합니다.
팀별로 구매와 AI 대여의 기준이 달라집니다
기존 서버와 전담 운영자가 있는 기업
서버에 여유 전력과 냉각 용량이 있고, 운영팀이 리눅스 드라이버·펌웨어·컨테이너를 관리할 수 있다면 구매의 장점이 커집니다. 지속적으로 발생하는 추론 요청을 외부 환경으로 옮기지 않아도 되고, 내부 네트워크와 인증 체계를 그대로 유지할 수 있기 때문입니다.
다만 장기 부하가 있다고 해서 곧바로 구매해야 하는 것은 아닙니다. 먼저 대표 모델의 정확도, 지연 시간, 배치 처리량, 장애 복구 절차를 정해 놓아야 합니다. 공식 예제만 실행한 뒤 구매하면 실제 서비스에서 사용하는 사용자 정의 연산자나 양자화 라이브러리에서 문제가 드러날 수 있습니다.
처음 ROCm을 도입하는 모델 개발팀
ROCm은 공식 문서와 지원 도구가 계속 확장되고 있지만, 기존 CUDA 중심 프로젝트를 그대로 옮긴다는 의미는 아닙니다. CUDA 전용 연산자, 사용자 정의 확장, 컨테이너 이미지, 프로파일러, 알림 도구를 목록화해야 합니다. ROCm 문서는 MI350 계열의 아키텍처와 성능 계수기 사용 방법을 제공하지만, 네 프로젝트의 모든 의존성이 자동으로 이전된다는 약속은 아닙니다. ROCm MI350 아키텍처 문서 및 ROCm 성능 분석 문서
처음 ROCm을 옮길 때는 카드를 사는 편이 좋을까요, 먼저 빌리는 편이 좋을까요?
이전 범위를 아직 계산하지 못했다면 먼저 빌리는 편이 낫습니다. 짧은 검증 기간 동안 실제 모델을 실행하고, 오류 수정에 필요한 작업과 운영 지표를 확인한 뒤 구매 여부를 정해야 합니다. ROCm 설치 문서의 지원 목록에 포함되는지, 사용하려는 프레임워크와 버전이 맞는지도 설치 전에 확인해야 합니다. ROCm 리눅스 시스템 요구 사항
부하가 출렁이는 AI 제품팀
신제품 출시, 공개 시연, 임시 압력 시험처럼 피크가 특정 시기에 몰리는 팀은 고정 GPU를 사도 유휴 시간이 길어질 수 있습니다. 이 경우에는 평상시 이용률보다 피크 기간의 지속 시간과 재현 가능성을 봐야 합니다.
모델 버전이 자주 바뀌는 팀도 같은 기준을 적용해야 합니다. 현재 모델에 맞춘 서버를 구매했는데 다음 분기 모델이 다른 연산자나 더 큰 메모리를 요구하면, 카드보다 소프트웨어 재검증과 서버 교체가 먼저 문제가 됩니다. 불확실한 성장 계획에는 짧은 AI 대여가 더 적합합니다.
데이터 경계가 엄격한 연구팀
데이터가 지정된 환경 밖으로 나가면 안 된다는 조건과, 반드시 자체 하드웨어를 소유해야 한다는 결론은 다릅니다. 원격 환경을 검토할 때는 전용 자원 여부, 저장 데이터 암호화, 접근 권한, 작업 종료 뒤 데이터 삭제, 로그 보관 위치를 확인해야 합니다.
내부 규정이 원격 실행을 허용하고 검증 환경의 격리 수준을 입증할 수 있다면 대여가 가능할 수 있습니다. 반대로 데이터 반출 자체가 금지되거나 물리적 인터페이스가 필요한 경우에는 로컬 서버가 필수에 가깝습니다.
하드웨어 담당자가 없는 소규모 팀
구매는 월 사용료를 없애지만 운영 책임을 없애지는 않습니다. 드라이버 업데이트, 펌웨어 관리, 장애 분석, 예비 부품, 온도 감시, 용량 배정과 보안 패치까지 내부 책임이 됩니다. 담당자가 없다면 GPU 한 장의 가격보다 서비스 중단과 문제 해결 지연이 더 큰 비용이 될 수 있습니다.
이런 팀은 전부 구매하거나 전부 대여하기보다 핵심 업무만 안정적인 환경에 두고, 신규 모델과 시험 부하는 외부 환경에서 검증하는 이중 운영이 현실적입니다.
구매 전 반드시 끝내야 할 검증 절차
다음 순서대로 진행하면 “카드는 인식되지만 서비스는 실행되지 않는” 상황을 줄일 수 있습니다.
- 서버 조건을 수집합니다. 서버 모델, 전원 공급 장치, 슬롯 위치, 슬롯 간격, 팬 구성, 랙 깊이와 운영체제 버전을 기록합니다.
- 제조사 호환 목록을 대조합니다. 단순히 PCIe 5.0 x16 슬롯이 있는지 보지 말고, MI350P와 해당 서버 조합이 지원되는지 확인합니다.
- ROCm 의존성을 분류합니다. 표준 프레임워크, 사용자 정의 연산자, 컨테이너, 모델 변환 도구와 모니터링 도구를 정상·수정 필요·대체 필요로 나눕니다.
- 대표 모델을 선정합니다. 가장 자주 호출되는 모델과 가장 문제가 많이 발생하는 모델을 골라 정확도, 지연 시간, 처리량, 메모리 사용량을 같은 조건에서 비교합니다.
- 운영 시험을 진행합니다. 재부팅, 드라이버 재설치, GPU 오류, 모델 롤백, 로그 수집과 알림 전송을 실제 절차로 실행합니다.
- 부하 기록을 만듭니다. 피크 시간, 평상시 요청량, 배포 주기와 임시 압력 시험 횟수를 기록해 고정 자산이 놀게 될 시간을 추정합니다.
- 구매 승인 조건을 정합니다. 호환성, 모델 정확도, 서비스 지연 시간, 장애 복구 담당자와 보증 책임이 모두 확인된 경우에만 구매로 넘어갑니다.
바로 실행하는 선택 점검표
- [ ] 서버 제조사의 MI350P 호환 목록을 확인했습니다.
- [ ] 전원과 수동 냉각 조건을 공급자에게 서면으로 확인했습니다.
- [ ] 현재 모델의 ROCm 의존성과 사용자 정의 연산자를 분류했습니다.
- [ ] 대표 모델을 실제 서비스 컨테이너로 실행했습니다.
- [ ] 재부팅과 장애 복구 절차를 시험했습니다.
- [ ] 최소 한 번은 피크 부하를 재현했습니다.
- [ ] 장기 운영 담당자와 보증 책임자를 정했습니다.
- [ ] 위 항목 중 하나라도 비어 있으면 단기 AI 대여를 먼저 검토합니다.
사는 방식과 빌리는 방식의 차이
아래 표는 카드 사양의 우열이 아니라, 팀이 떠안는 책임과 회수 가능한 선택지를 비교한 것입니다.
| 판단 항목 | 직접 업그레이드 | AI 대여 | 이중 운영 |
|---|---|---|---|
| 서버 조건 | 호환 목록과 전원·냉각 확인 필수 | 공급자가 제공하는 환경 사용 | 핵심 업무는 내부, 시험은 외부 |
| ROCm 적응 | 내부에서 지속 관리 | 짧은 기간에 실제 모델 검증 | 안정된 모델만 내부 이전 |
| 부하 형태 | 장기간 안정적인 추론 | 변동 부하와 임시 시험 | 핵심 부하와 실험 부하 분리 |
| 데이터 조건 | 내부 보관이 가장 단순 | 격리·접근·삭제 정책 확인 필요 | 민감 데이터는 내부에 유지 |
| 운영 인력 | 드라이버·펌웨어·장애 담당 필요 | 공급자 지원 범위 확인 | 내부 운영 범위를 제한 |
| 적합도 | 성숙한 팀에 높음 | 불확실성이 큰 팀에 높음 | AMD 도입 초기 기업에 높음 |
MI350P는 계속되는 추론과 임시 프로젝트 중 어느 쪽에 더 맞나요?
지속적인 추론량이 실제 기록으로 확인되고, 모델과 ROCm 환경이 안정됐으며, 서버 운영자가 있다면 직접 업그레이드가 맞습니다. 반대로 임시 프로젝트, 모델 실험, 출시 전 압력 시험이 중심이면 AI 대여가 더 유연합니다. 사용 기간을 미리 확정하기 어렵다면 먼저 대여하고, 반복되는 부하만 구매 후보로 분리해야 합니다.
| 선택 결과 | 구매를 선택할 조건 | 대여를 선택할 조건 |
|---|---|---|
| 서버 자산 | 전원·냉각·슬롯·펌웨어가 확인됨 | 기존 서버 검증이 끝나지 않음 |
| 소프트웨어 | ROCm 이전 범위와 수정 담당자가 확정됨 | 사용자 정의 연산자 문제가 남아 있음 |
| 업무 부하 | 지속적인 추론 수요가 있음 | 피크와 시험 수요가 중심임 |
| 데이터 | 반드시 내부 장비가 필요함 | 원격 격리와 삭제 정책을 승인받음 |
| 운영 | 장애 대응 담당자가 있음 | 전담 하드웨어 인력이 없음 |
| 최종 판단 | 조건이 모두 충족될 때 | 하나라도 불확실할 때 |
기존 방식의 약점과 SSHMac을 활용한 검증
기존 서버에 MI350P를 직접 추가하는 방식은 초기에는 자산 활용처럼 보이지만, 서버 호환성 확인, 냉각 개조, ROCm 이전, 펌웨어 관리가 한 팀에 집중됩니다. 반대로 일반적인 퍼블릭 환경은 데이터 격리나 원하는 GPU 구성의 지속성을 세밀하게 통제하기 어려울 수 있습니다. 특히 모델 검증 기간이 짧거나 피크 부하가 예측되지 않는다면 어느 한쪽에 전부 투자하는 방식이 위험합니다.
이럴 때는 현재 서버 조건, 모델 소프트웨어 구성, 예상 운영 기간과 피크 부하를 정리해 SSHMac에 적합성 검증 요청으로 전달하는 방식이 현실적입니다. SSHMac 지원 센터에서 요구 조건을 먼저 정리하고, 결제와 이용 조건이 중요한 팀은 SSHMac 이용 안내를 함께 확인하면 됩니다. 단기 시험으로 실제 모델이 통과한 뒤 구매를 결정하면, 호환되지 않는 카드와 유휴 서버를 떠안는 위험을 줄일 수 있습니다.
필요한 것이 장기간 고정된 대규모 추론 자산이라면 직접 구매가 더 적합할 수 있습니다. 그러나 일시적인 인공지능 연산 자원 수요, ROCm 이전 검증, 출시 전 압력 시험이 목적이라면 SSHMac의 원격 맥 및 산출 환경을 먼저 활용해보는 편이 더 빠르게 결론에 도달할 수 있습니다.