vLLM은 Tenstorrent의 Mesh 아키텍처를 어떻게 지원하나

들어가며

vLLM이 Tenstorrent 가속기를 서빙 스택에 연결하는 TT Plugin을 소개했습니다. 플러그인을 설치하고 TT-Metal의 ttnn을 가져올 수 있는 환경에서 실행하면 Tenstorrent 하드웨어가 vLLM 플랫폼으로 등록됩니다. 애플리케이션 개발자 입장에서는 서비스 표면이 거의 달라지지 않습니다. OpenAI 호환 API와 기존 요청 형식, 클라이언트 코드를 그대로 사용할 수 있습니다.

하지만 이번 작업은 단순히 백엔드 하나를 추가한 사례가 아닙니다. Tenstorrent 시스템은 코어와 칩이 연결된 Mesh를 기본 실행 단위로 삼습니다. 칩 간 데이터 이동도 호스트가 매번 GPU식 집합 통신을 호출하는 방식이 아니라, 컴파일된 프로그램과 패브릭의 일부로 처리됩니다. 따라서 GPU 중심 추론 스택이 당연하게 여겨온 몇 가지 가정을 다시 설계해야 했습니다.

핵심 설계

• 외부 플러그인 방식의 통합. 플랫폼, 워커, 스케줄러, 모델 아키텍처는 vLLM의 기존 확장 지점을 통해 등록됩니다. Tenstorrent 전용 설정은 새로운 코어 CLI 플래그가 아니라 일반적인 additional-config 네임스페이스를 사용합니다.
• 런타임 랭크 대신 Mesh 실행. 모델은 전체 대상 Mesh를 기준으로 컴파일되고 트레이스됩니다. 디바이스 구성은 MESH_DEVICE로 선택하며, 기존의 -tp와 -pp 옵션은 일반적인 의미를 가진 것처럼 처리하지 않고 거부합니다. 실제 병렬화 방식은 모델 구현과 Mesh 형태의 조합으로 정해집니다.
• 단계 제약형 스케줄링. 각 스텝은 prefill 전용, decode 전용 또는 빈 작업 중 하나입니다. prefill과 decode를 한 배치에 섞지 않습니다. 긴 프롬프트는 여러 prefill 스텝으로 나눌 수 있고, 그 사이에 decode를 넣어 처리 중인 요청이 계속 진행되도록 합니다.
• 안정적인 형태의 배치 선호. 디바이스 실행은 고정된 배치 형태를 위한 트레이스 재생에 크게 의존합니다. 따라서 형태가 크게 다른 배치보다 동질적이고 안정적인 배치가 이 실행 방식에 더 잘 맞습니다.
• 디바이스 측 샘플링. Mesh 프로그램의 끝까지 샘플링을 포함할 수 있어, 일부 모드에서는 전체 logits를 호스트로 보내지 않고 선택된 토큰을 직접 반환합니다. 동시에 호스트에서 처리하는 대체 경로도 남겨 둡니다.
• 멀티모달 범위. 지원 대상에는 Llama, Qwen, Mistral, Gemma, DeepSeek, GPT-OSS 계열과 일부 Vision 및 멀티모달 아키텍처가 포함됩니다. 외부 디렉터리의 모델 번들을 시작 시 등록할 수 있어 플러그인 소스 수정도 필요하지 않습니다.

의미와 영향

이 프로젝트는 vLLM의 플러그인 경계가 실제로 하드웨어에 독립적인지를 보여주는 사례입니다. Tenstorrent의 Mesh를 GPU 프로세스 묶음처럼 위장하는 대신, Mesh 컴파일과 스케줄링 제약, 샘플링 동작을 플러그인과 TT-Metal 모델 구현에 배치했습니다. 그 결과 vLLM의 API와 생태계를 재사용하면서 코어 변경은 최소화할 수 있습니다.

물론 비용도 있습니다. 운영자는 GPU용 텐서 병렬 설정을 그대로 가져올 수 없고, prefill과 decode를 분리하는 배치 정책을 이해해야 합니다. 그럼에도 하드웨어 업체 입장에서는 장기간 포크를 유지하기보다 확장 인터페이스를 통해 vLLM의 발전을 따라갈 수 있다는 점이 중요합니다.

이번 사례가 주는 더 큰 교훈은 추론 프레임워크의 확장성이 새 칩을 발견하는 능력에만 있지 않다는 것입니다. 서로 다른 실행 모델을 GPU식 추상화에 억지로 맞추지 않고 표현할 수 있어야 진정한 확장성이 성립합니다.

출처: vLLM Blog