요약
Java용 GPU 프레임워크 TornadoVM 7이 CUDA 라이브러리 직접 호출과 멀티 GPU 실행을 지원합니다.
인포큐가 오픈소스 이기종 프로그래밍 프레임워크(CPU·GPU 등 서로 다른 하드웨어에서 코드를 돌리는 도구) TornadoVM의 7.3 버전 출시를 전했습니다. TornadoVM은 JVM을 대체하지 않고, OpenJDK·GraalVM·Temurin 같은 기존 JDK 위에서 Java 코드를 GPU로 넘겨 실행합니다.
왜 중요한가
- 실험 기능인 JVMCI(JVM 컴파일러 인터페이스) 의존을 없애 JDK 21, 25, 26, 27에서 같은 방식으로 돌아갑니다.
- 노트북의 OpenCL·Metal에서 개발한 코드를 엔비디아 GPU 서버에 그대로 배포할 수 있습니다.
- 엔비디아가 최적화한 선형대수·FFT·신경망 라이브러리를 Java다운 방식으로 쓰는 길이 열립니다.
핵심 내용
- 백엔드가 JNI(Java Native Interface) 대신 FFM API(외부 함수·메모리 API)를 쓰도록 바뀌었습니다.
- TaskGraph에서 cuBLAS, CUTLASS 같은 CUDA 라이브러리를 바로 부르고, JIT로 만든 커널과 이어 붙일 수 있습니다.
- 새 TileContext로 엔비디아의 cuTile 모델을 지원하고, 애플의 MLX 라이브러리 연동과 멀티 GPU 실행도 더했습니다.
- 루프에 붙이는 단순한 병렬 애너테이션만으로는 실서비스에 필요한 성능을 내기 어려웠다고 합니다.
- 함께 나온 jitLLM 2.0은 JAR 파일 하나로 배포되는 Java 추론 엔진이고, 팀은 llama.cpp·Ollama와 성능으로 겨룬다고 밝혔습니다.
HN 반응
- Java로 AI 인프라를 만들 수 있느냐는 질문에는 jitLLM과, 일부 작업에서 llama.cpp보다 빠르다는 순수 Java 추론 엔진 사례가 답으로 나왔습니다.
- 반면 JAR로 배포되는데 VM이라 부르면 헷갈린다는 지적과, 커널을 Java로 다시 짜기보다 기존 커널을 부르는 편이 낫다는 의견도 있었습니다.
예제에 나온 것만 해 줘도 꽤 괜찮은 성과 같습니다.
하지만 방 안의 코끼리는 Vector API입니다. 이것도 로깅처럼 되는 건 아닐까요? 표준 API이긴 한데 10년이나 늦게 나왔고 이미 자리 잡은 것들보다 나을 게 없어서 아무도 안 쓰는 그런 신세 말입니다.
그리고 기존 VM 위에서 돌아가는 JAR 파일로 배포하면서 왜 굳이 VM이라고 불러서 다들 헷갈리게 만드는 걸까요?
타일링은 어떻게 되나요? 커널을 자바로 다시 짜는 것보다, 이미 있는 커널이나 퓨전된 메가커널을 호출하는 편이 낫겠는데요.
https://github.com/beehive-lab/TornadoVM 여기가 메인 저장소입니다.
JDK 21 이상이면 어디서든 쓸 수 있고, Nvidia나 Apple 하드웨어에서 각각 Nvidia 라이브러리나 MLX 라이브러리를 이용해 쓰면 됩니다.
TPU 지원은 어떤가요? 구글 TPU와 호환되나요, 아니면 CUDA나 Metal 같은 GPU 백엔드로만 엄격하게 제한되나요?
아직 TPU는 지원하지 않습니다. NVIDIA, Apple, 그리고 OpenCL을 지원하는 다른 하드웨어만 됩니다.
그럼 자바로 AI 인프라를 만들 수 있다는 뜻인가요?
아니면 추상 AI 인프라 팩토리를요?
https://github.com/beehive-lab/jitllm 이미 TornadoVM을 GPU 백엔드로 쓰는 vllm 같은 추론 엔진이 있습니다. 전부 자바로 작성됐습니다.
아마 소프트웨어 팩토리 다음 유행이 그거겠죠.
이름이 AbstractAiInfrastructureFactory가 아니면 실망할 것 같네요.
이런 식의 불평은 슬슬 지겹네요. 기분 전환 삼아 Objective-C 구경이나 하세요.
https://github.com/Quotation/LongestCocoa
네, 됩니다(JVM 언어라면 뭐든요). 이런 것도 있습니다.
https://qxotic.ai/
... 의존성 없는 단일 JAR 파일로, 로컬 모델의 추론을 SIMD로 가속합니다. 토크나이저부터 전부 자바로 작성됐습니다. macOS에서는 Metal도 쓸 수 있습니다. 요즘은 작은 모델도 놀랄 만큼 강력해서, 빠른 CPU만 있으면 충분합니다. LLM뿐 아니라 이미지, 영상, 음성 모델도 됩니다.
놀랍게도 프리필 같은 일부 작업에서는 llama.cpp보다 훨씬 빠릅니다(디코딩은 메모리 대역폭에 묶여 있어서 언어가 별 차이를 만들지 못합니다). 적어도 GraalVM에서 돌릴 때는 그렇습니다(JVM이든 네이티브 이미지든 둘 다 됩니다). 그러니까 AI에서 자바로 C++ 성능을 이길 수 있다는 얘기입니다.
인상적입니다.
한마디로 파이썬 대신 자바용 JAX네요.
자바용 JAX를 만드는 데 필요한 구성 요소 상당수는 이미 https://github.com/beehive-lab/jitllm 에서 검증됐습니다.
"당신네 과학자들은 할 수 있느냐에만 정신이 팔려서, 해야 하느냐는 생각해 보지도 않았죠."