모드콘 2026 맥스 이기종 지원, 지금 바꿀까

2026년 8월 17일 기준 맥스의 최신 안정판은 26.5이며, 같은 시점의 야간판은 26.6.0.dev2026081705입니다. 공식 문서도 안정판은 더 검증된 버전, 야간판은 새 기능과 버그가 함께 들어갈 수 있는 버전으로 구분합니다. 따라서 모드콘 2026의 시연만 보고 생산 추론 환경을 바로 바꾸기보다, 이번 주에는 기존 환경을 유지하면서 맥스 이중 검증을 시작하는 편이 안전합니다. (공식 버전 목록)

이 글은 엔비디아와 에이엠디 기반의 구매·확장 계획을 담당하는 인프라 책임자를 위한 글입니다. 오픈 모델 서비스를 직접 운영하면서 맥스를 기술 후보에 넣을지 고민하는 개발팀, 모조 1.0의 발표보다 실제 배포 가능성을 확인하려는 엔지니어도 대상입니다.

마지막 업데이트: 2026년 8월 18일. 모드콘 공식 일정, 맥스 공식 문서와 버전 목록, 공식 저장소, 퀄컴 발표 자료를 기준으로 확인했습니다.

발표보다 먼저 확인할 네 가지 통과 조건

모드콘 2026은 2026년 8월 18일 미국 샌프란시스코에서 열리며, 공식 일정에는 통합 인공지능 연산 계층, 맥스 추론 계층, 다중 실리콘 스택, 모조 1.0, 퀄컴 신경망 처리 장치 관련 세션이 포함되어 있습니다. (모드콘 공식 일정)

하지만 발표 현장의 시연, 개발자가 내려받을 수 있는 제품, 서비스 수준 협약을 만족하는 생산 환경은 서로 다른 단계입니다. 마케팅 문구에서 말하는 “모든 칩을 하나의 계층으로 묶는다”는 방향성만으로는 구매 결정을 내릴 수 없습니다.

우리의 최소 전환 조건은 다음과 같습니다.

• 공식 문서와 설치 파일을 실제로 확보할 수 있어야 합니다.
• 목표 모델과 사용하는 정밀도, 양자화 방식이 실행되어야 합니다.
• 같은 조건에서 결과를 다시 얻을 수 있어야 합니다.
• 장애가 발생했을 때 기존 엔진이나 다른 하드웨어로 돌아갈 수 있어야 합니다.

이 네 가지 중 하나라도 빠지면 모드콘 2026은 “검토를 시작할 신호”일 뿐, “생산 이전을 승인할 증거”가 아닙니다.

하드웨어 지원은 이름이 아니라 단계로 비교해야 합니다

모드콘 2026 이후 바로 맥스로 이전해야 할까요?

현재 판단은 아닙니다. 우선 목표 하드웨어별로 지원 단계를 나눠야 합니다. 맥스 공식 패키지 문서는 엔비디아와 에이엠디 하드웨어를 각각 서빙 검증 완료와 개발 호환으로 나누고 있습니다. 엔비디아 쪽은 B200이 서빙 검증 대상으로 표시되고, H100·H200·L40·A100 등은 개발 호환 목록에 포함됩니다. 에이엠디 쪽은 MI355X·MI300X·MI325X가 서빙 검증 대상으로, MI250X와 여러 라데온 계열은 개발 호환 대상으로 기재되어 있습니다. (맥스 하드웨어 호환 문서)

이 차이는 단순한 표현 차이가 아닙니다. 서빙 검증은 특정 하드웨어와 소프트웨어 조합으로 실제 모델 서비스를 확인했다는 뜻에 가깝지만, 개발 호환은 개발·시험이 가능하다는 범위입니다. 생산 장애 대응이나 장시간 안정성까지 자동으로 보장하지는 않습니다.

애플 실리콘은 더 신중하게 봐야 합니다. 공식 문서는 애플 실리콘에서 모조를 이용한 GPU 프로그래밍과 맥스 모델 추론을 계속 개발 중이라고 설명합니다. 일부 라마, 젬마, 네모트론, 플럭스 계열은 수동으로 실행했지만, 모든 모델과 세대가 동일한 검증 계층에 들어간 것은 아닙니다. 그래프 컴파일 단계에서 필요한 금속 커널이 없으면 추론을 시작하기 전에 실패할 수 있다는 경고도 있습니다. (애플 실리콘 및 GPU 호환 문서)

퀄컴 신경망 처리 장치는 현재 배포 완료 목록으로 읽으면 안 됩니다. 공식 모드콘 일정에 관련 세션이 있고 퀄컴은 2026년 7월 모듈러 인수를 발표했지만, 특정 칩과 맥스 버전, 컨테이너, 모델 조합이 공식 호환 목록과 다운로드 가능한 문서에 올라왔는지는 별도로 확인해야 합니다. 인수 후 생태계 투자를 약속하는 발표와 현재 운영 가능한 기능은 같은 항목이 아닙니다. (퀄컴의 인수 완료 발표)

실무에서는 “같은 소프트웨어 계층”을 다음처럼 쪼개서 확인해야 합니다.

• 모델 구조와 모델 버전이 같은가
• 연산자와 사용자 정의 연산자가 모두 지원되는가
• 컨테이너와 런타임이 하드웨어별로 동일한가
• 드라이버와 컴파일러 요구 조건이 맞는가
• 쿠버네티스, 자동 확장, 로그 수집 방식이 바뀌지 않는가

공식 저장소에는 엔비디아와 에이엠디 환경용 컨테이너, 두 환경을 겨냥한 통합 컨테이너가 소개되어 있습니다. 그러나 컨테이너 이름이 같거나 설치 명령이 비슷하다는 사실만으로 모델 성능과 장애 대응이 같다고 볼 수는 없습니다. (공식 저장소의 컨테이너 안내)

성능은 발표 숫자가 아니라 재현 기록으로 판단합니다

맥스의 에이엠디와 엔비디아 실행 결과가 같은 서비스 품질을 보장할까요?

같은 모델이 실행되는 것과 같은 비용·지연·안정성을 제공하는 것은 별개의 문제입니다. 맥스 공식 시작 문서도 일부 대형 모델에는 96 GiB보다 많은 GPU 메모리가 필요할 수 있으며, 예시로 엔비디아 B200 또는 에이엠디 MI355X를 권장합니다. 이 수치는 특정 모델과 입력 방식에 대한 요구 조건이지, 모든 모델의 성능 동등성을 뜻하지 않습니다. (공식 시작 문서)

검증할 때는 다음 항목을 한 세트로 고정해야 합니다.

• 모델 저장소와 커밋 또는 버전
• 정밀도와 양자화 방식
• 입력 토큰과 출력 토큰의 길이
• 배치 크기와 동시 요청 수
• 하드웨어 모델, 드라이버, 맥스 버전
• 첫 토큰 지연 시간
• 전체 처리량
• 장시간 부하에서의 오류율과 메모리 변화

발표 자료가 처리량만 보여준다면 생산 판단에 필요한 정보가 부족합니다. 특히 첫 토큰 지연 시간은 대화형 서비스의 체감 품질과 직접 연결되고, 장시간 부하 안정성은 자동 확장 비용과 장애율에 영향을 줍니다. 모델이 한 번 시작되었다는 이유만으로 엔비디아와 에이엠디의 운영 비용이 같다고 계산해서는 안 됩니다.

검증 순서는 다음과 같이 잡는 것이 좋습니다.

1. 기존 서비스와 동일한 모델 파일을 준비합니다.
2. 두 하드웨어에서 같은 맥스 안정판을 고정합니다.
3. 동일한 입력 집합과 요청 생성기를 사용합니다.
4. 낮은 동시성에서 기능 오류를 먼저 확인합니다.
5. 목표 동시성에서 지연 시간과 처리량을 측정합니다.
6. 장시간 부하 후 메모리 증가와 재시작 여부를 확인합니다.
7. 결과와 로그를 저장해 다른 팀원이 다시 실행합니다.

야간판은 기능 확인용으로만 쓰는 편이 낫습니다. 공식 버전 목록은 야간판에 새 기능이 포함될 수 있지만 완성되지 않았고 새로운 오류가 생길 수 있다고 명시합니다. 생산 후보를 평가할 때는 안정판과 야간판의 결과를 섞지 않아야 합니다. (맥스 버전 관리 문서)

이전 비용은 코드보다 주변 운영 계층에서 커집니다

맥스가 오픈AI 호환 인터페이스를 제공하더라도 기존 서비스가 그대로 옮겨진다고 단정할 수 없습니다. 공식 저장소에는 호환형 추론 끝점과 파이썬 기반 모델 파이프라인이 소개되어 있지만, 실제 이전에서는 다음 항목이 비용을 만듭니다. (공식 저장소의 추론 서버 안내)

• 사용자 정의 연산자와 특수한 모델 구조
• 기존 양자화 파일과 변환 도구
• 프롬프트 캐시와 키값 캐시 정책
• 컨테이너 빌드와 보안 스캔
• 지표 이름, 로그 형식, 추적 도구 연결
• 자동 확장 조건과 준비 상태 검사
• 배포 스크립트와 장애 시 재시작 순서

개발 검증과 생산 전환도 분리해야 합니다. 개발자는 한 대의 장비에서 모델이 동작하는지만 확인할 수 있지만, 운영팀은 여러 복제본의 시작 시간, 이미지 캐시, 노드 교체, 롤백, 권한, 비밀값 관리까지 확인해야 합니다.

모조 1.0도 같은 관점에서 봐야 합니다. 언어 버전이 안정 단계로 이동하고 공개 범위가 넓어지는 것은 유지보수 비용을 낮출 가능성이 있지만, 그것만으로 맥스 전체의 생산 성숙도가 증명되지는 않습니다. 실제 판단에는 언어 버전, 맥스 응용 프로그램 인터페이스, 커널 라이브러리, 모델 파이프라인의 안정 표기가 각각 필요합니다.

모조 1.0이 기존 인공지능 추론 배포 결정을 바로 바꿀까요?

대부분의 팀에서는 바로 바꾸지 않는 편이 합리적입니다. 모조 1.0은 사용자 정의 커널과 하드웨어 추상화를 검토할 중요한 계기이지만, 현재 운영 중인 모델의 연산자 지원, 디버깅 도구, 버전 고정, 장애 대응 문서가 모두 준비되었는지를 별도로 확인해야 합니다. 모조의 공개 범위와 컴파일러 저장소 변화는 공식 발표와 저장소 태그를 기준으로 다시 확인해야 합니다.

운영 성숙도와 철수 능력을 함께 점검합니다

새 추론 계층을 도입할 때 비용은 사용료만이 아닙니다. 장애를 분석하지 못해 복구 시간이 길어지거나, 특정 버전에 묶여 보안 업데이트를 늦추는 비용도 포함해야 합니다.

다음 항목이 공식 문서와 실제 테스트에 모두 있어야 합니다.

• 안정판과 야간판을 분리해 설치하는 방법
• 버전과 컨테이너 태그를 고정하는 방법
• 업그레이드 전 호환성 확인 절차
• 문제 추적과 재현 정보를 제출하는 방법
• 다중 GPU 설정과 모델별 제한
• 로그, 지표, 준비 상태 확인 방법
• 이전 엔진으로 되돌리는 배포 절차

맥스 문서는 모델마다 필요한 메모리가 다르며, 애플 실리콘처럼 GPU가 시스템 메모리를 공유하는 환경에서는 운영체제와 다른 프로세스가 사용하는 메모리까지 함께 고려해야 한다고 설명합니다. 따라서 장비의 메모리 용량만 보고 모델 탑재 가능 여부를 판단하면 안 됩니다. (공식 메모리 및 GPU 주의사항)

우리의 권장 철수 조건은 간단합니다. 기존 컨테이너와 모델 파일을 일정 기간 보관하고, 트래픽 일부를 되돌릴 수 있는 라우팅 규칙을 유지하며, 맥스 업그레이드 전에 같은 검증 묶음을 다시 실행해야 합니다. 이 절차를 만들 수 없다면 맥스가 빠르거나 저렴해 보여도 생산 이전 시점이 아닙니다.

첫 검증을 위한 실행 목록

아래 항목은 발표 당일의 인상보다 실제 이전 가능성을 확인하기 위한 최소 목록입니다.

• [ ] 현재 서비스의 모델, 정밀도, 양자화, 입력 길이를 문서화합니다.
• [ ] 목표 엔비디아와 에이엠디 장비의 드라이버 조건을 확인합니다.
• [ ] 맥스 안정판과 야간판을 별도 환경에 설치합니다.
• [ ] 공식 모델 목록에서 목표 모델의 지원 상태를 확인합니다.
• [ ] 사용자 정의 연산자와 캐시 방식을 별도로 점검합니다.
• [ ] 동일한 컨테이너와 요청 생성기로 양쪽 하드웨어를 시험합니다.
• [ ] 첫 토큰 지연, 처리량, 메모리, 오류율을 함께 기록합니다.
• [ ] 장시간 부하와 노드 재시작을 시험합니다.
• [ ] 기존 엔진으로 돌아가는 라우팅과 이미지 보관 절차를 실행합니다.
• [ ] 결과가 재현되기 전에는 구매·확장 계획을 맥스 기준으로 확정하지 않습니다.

테스트 환경을 짧게 빌려 먼저 확인하려는 경우에는 오픈 모델 배포와 성능 검증 관련 글을 함께 참고할 수 있습니다. 애플 실리콘에서 모조와 맥스를 확인하려는 팀은 JexMac의 클라우드 맥 환경에서 실제 설치 절차를 분리해 검증하는 방식이 적합합니다.

결론은 하드웨어 조합별로 다르게 내려야 합니다

우리의 최종 평가는 “교체 승인”이 아니라 “조건부 시범 운영”입니다. 에이엠디와 엔비디아에서 목표 모델을 같은 방식으로 실행하고, 성능 결과를 재현하며, 운영 장애 때 기존 환경으로 돌아갈 수 있는 팀이라면 제한된 트래픽으로 맥스를 시험할 수 있습니다. 반대로 미지원 연산자, 엄격한 서비스 수준 협약, 다중 GPU 의존성이 핵심이라면 공식 지원 문서가 채워질 때까지 기존 환경을 유지하는 편이 비용 분석상 유리합니다.

기존 방식은 특정 GPU 공급업체에 종속되고, 하드웨어별 컨테이너와 드라이버를 따로 관리해야 하며, 새 모델을 시험할 때 장비를 직접 확보하는 시간이 길다는 단점이 있습니다. 그렇다고 장기 중부하 서비스에 임시 환경을 계속 쓰는 것도 맞지 않습니다. 다만 아직 하드웨어 조합을 확정하지 못했거나 모조와 맥스의 설치 가능성만 빠르게 확인하려는 단계라면, JexMac의 맥 환경을 짧게 활용해 결과를 확보한 뒤 구매나 장기 임대 여부를 결정하는 편이 불확실한 선투자를 줄이는 방법입니다.