Google TPU 8tx·8i Max: 보안 추론과 긴 문맥을 위한 새 구성

Google이 2026년 11월 9일 TPU 8tx와 TPU 8i Max를 발표했다. 기존 8세대 TPU에 보안 추론과 긴 문맥 처리를 겨냥한 시스템을 추가한 소식이다. 모델을 바꾸기보다 추론 인프라를 고르는 개발팀이 살펴볼 만하다.

보안 추론과 긴 문맥을 위한 두 구성

Google 설명에 따르면 8tx는 TPU 8t와 같은 실리콘에 5세대 AMD EPYC 호스트와 Boardfly 네트워크를 결합한다. 처리 중인 데이터와 모델 가중치를 보호하는 기밀 컴퓨팅에 초점을 맞췄다. TPU 8t 대비 지연이 최대 절반 수준이라는 수치는 회사 발표이며 이 글에서 독립적으로 재현하지 않았다.

8i Max는 TPU 8i 칩 두 개를 한 패키지에 넣는다. Google은 8i 대비 연산량·SRAM·HBM 대역폭이 각각 두 배라고 밝혔다. 이 수치만으로 애플리케이션 처리량이나 지원 문맥 길이가 두 배가 된다고 단정할 수는 없다.

원문은 두 구성을 새로운 시스템으로 설명한다. 확인한 발표 본문에는 가격·제공 리전·두 시스템의 일반 제공 일정이 명시되지 않았다. 발표일을 곧바로 사용 가능한 날짜로 받아들이지 않는 편이 좋다. Google 공식 발표에서 하드웨어 설명과 회사의 성능 주장을 확인할 수 있다.

도구의 지원 범위도 따로 확인하기

하드웨어 소식과 함께 읽을 자료는 Google Cloud의 PyTorch on Cloud TPU 문서다. 문서는 TorchTPU를 PyTorch용 TPU 백엔드로 소개하고 vLLM·SGLang 서빙 경로를 안내한다. TPU agent suite는 Preview로 표시하며 문서가 설명하는 대상은 TPU v6e와 TPU7x의 Transformer 추론이다. 문서의 마지막 갱신일은 11월 6일이다.

이 문서만으로 새 8tx·8i Max의 모든 소프트웨어 조합이 검증됐다고 읽어서는 안 된다. 도입을 검토한다면 사용할 모델·연산자·서빙 엔진 버전을 정하고 해당 구성의 지원 여부부터 확인해야 한다. 새 하드웨어 발표와 기존 개발 도구 문서가 같은 날의 호환성 보증을 뜻하지는 않는다.

개발팀의 검증은 실제 요청에서 시작한다

다음은 발표 수치를 도입 판단에 쓰기 위한 실무 제안이다. Google이 제공한 벤치마크 결과와 구분해서 읽어야 한다.

보안 추론이 목적이라면 보호할 데이터를 먼저 정해 보자. 모델 가중치, 입력 문서, 도구 호출 결과 중 무엇을 어떤 운영 주체로부터 격리해야 하는지 문서화하면 공급사에 물어볼 조건이 구체적이 된다. 하드웨어 보호 범위와 애플리케이션의 로그·접근 권한도 함께 검토할 수 있다.

긴 문맥이 목적이라면 실제 서비스 요청으로 비교하는 편이 낫다. 입력 길이와 동시 요청 수를 고정하고 첫 토큰 지연, 생성 속도, 오류율, 요청당 비용을 함께 기록하자. 대역폭 수치를 서비스의 응답 시간으로 바꾸려면 이런 측정이 필요하다. 도구를 기다리는 시간이 긴 에이전트라면 대기 시간도 따로 분리해 두면 좋다.

이번 발표를 바탕으로 당장 이전 일정을 확정하기보다는 공급 가능 조건을 확인하고 작은 비교 실험을 준비할 수 있다. 두 시스템의 성능 주장은 실제 모델과 요청 조건에서 다시 측정할 대상으로 남겨 두자.