TornadoVM 7로 Java 애플리케이션에서 GPU 네이티브 워크로드를 돌릴 수 있게 됐습니다

TornadoVM 7 Enables GPU-Native Workloads from Java Applications

infoq.com ▲ 83 댓글 15 pjmlp

요약

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로 다시 짜기보다 기존 커널을 부르는 편이 낫다는 의견도 있었습니다.

댓글

15개 표시 · 전체 15개
  1. zmmmmm HN

    예제에 나온 것만 해 줘도 꽤 괜찮은 성과 같습니다.

        void matmul(Matrix2DFloat A, Matrix2DFloat B, Matrix2DFloat C, int size) {
          for (@Parallel int i=0; i<size; i++) {
            for (@Parallel int j=0; j<size; j++) {
              float sum = 0f;
              for (int k=0; k<size; k++)
                sum += A.get(i,k)*B.get(k,j);
              C.set(i, j, sum);
            }
          }
        }
    

    하지만 방 안의 코끼리는 Vector API입니다. 이것도 로깅처럼 되는 건 아닐까요? 표준 API이긴 한데 10년이나 늦게 나왔고 이미 자리 잡은 것들보다 나을 게 없어서 아무도 안 쓰는 그런 신세 말입니다.

    그리고 기존 VM 위에서 돌아가는 JAR 파일로 배포하면서 왜 굳이 VM이라고 불러서 다들 헷갈리게 만드는 걸까요?

  2. russli1993 HN

    타일링은 어떻게 되나요? 커널을 자바로 다시 짜는 것보다, 이미 있는 커널이나 퓨전된 메가커널을 호출하는 편이 낫겠는데요.

  3. mikepapadim HN

    https://github.com/beehive-lab/TornadoVM 여기가 메인 저장소입니다.

    JDK 21 이상이면 어디서든 쓸 수 있고, Nvidia나 Apple 하드웨어에서 각각 Nvidia 라이브러리나 MLX 라이브러리를 이용해 쓰면 됩니다.

  4. Akseleu_omirbay HN

    TPU 지원은 어떤가요? 구글 TPU와 호환되나요, 아니면 CUDA나 Metal 같은 GPU 백엔드로만 엄격하게 제한되나요?

  5. mikepapadim HN

    아직 TPU는 지원하지 않습니다. NVIDIA, Apple, 그리고 OpenCL을 지원하는 다른 하드웨어만 됩니다.

  6. the_arun HN

    그럼 자바로 AI 인프라를 만들 수 있다는 뜻인가요?

  7. vlowrian HN

    아니면 추상 AI 인프라 팩토리를요?

  8. mikepapadim HN

    https://github.com/beehive-lab/jitllm 이미 TornadoVM을 GPU 백엔드로 쓰는 vllm 같은 추론 엔진이 있습니다. 전부 자바로 작성됐습니다.

  9. keeda HN

    아마 소프트웨어 팩토리 다음 유행이 그거겠죠.

  10. kitd HN

    이름이 AbstractAiInfrastructureFactory가 아니면 실망할 것 같네요.

  11. pjmlp HN

    이런 식의 불평은 슬슬 지겹네요. 기분 전환 삼아 Objective-C 구경이나 하세요.

    https://github.com/Quotation/LongestCocoa

  12. mike_hearn HN

    네, 됩니다(JVM 언어라면 뭐든요). 이런 것도 있습니다.

    https://qxotic.ai/

    ... 의존성 없는 단일 JAR 파일로, 로컬 모델의 추론을 SIMD로 가속합니다. 토크나이저부터 전부 자바로 작성됐습니다. macOS에서는 Metal도 쓸 수 있습니다. 요즘은 작은 모델도 놀랄 만큼 강력해서, 빠른 CPU만 있으면 충분합니다. LLM뿐 아니라 이미지, 영상, 음성 모델도 됩니다.

    놀랍게도 프리필 같은 일부 작업에서는 llama.cpp보다 훨씬 빠릅니다(디코딩은 메모리 대역폭에 묶여 있어서 언어가 별 차이를 만들지 못합니다). 적어도 GraalVM에서 돌릴 때는 그렇습니다(JVM이든 네이티브 이미지든 둘 다 됩니다). 그러니까 AI에서 자바로 C++ 성능을 이길 수 있다는 얘기입니다.

    인상적입니다.

  13. amir734jj HN

    한마디로 파이썬 대신 자바용 JAX네요.

  14. mikepapadim HN

    자바용 JAX를 만드는 데 필요한 구성 요소 상당수는 이미 https://github.com/beehive-lab/jitllm 에서 검증됐습니다.

  15. mathisfun123 HN

    "당신네 과학자들은 할 수 있느냐에만 정신이 팔려서, 해야 하느냐는 생각해 보지도 않았죠."

Hacker News에서 보기 ↗