로컬 대규모 언어 모델을 실행하다 보면 종종 하드웨어 선택의 한계에 부딪히게 됩니다. NVIDIA 사용자들은 CUDA 생태계 안에서 활동합니다.

로컬 대규모 언어 모델(LLM)을 실행하다 보면 종종 하드웨어의 한계에 부딪히게 됩니다. NVIDIA 사용자는 CUDA 생태계 안에서 움직이고, Apple 개발자는 Metal을 선택합니다. 그 외의 사용자들은 자신의 GPU가 OpenCL을 지원하기를 바라거나, 단순히 CPU로 전환하여 실행해야 합니다. 이러한 파편화는 데스크톱 AI 애플리케이션을 배포하는 과정을 불필요하게 어렵게 만듭니다. TensorSharp는 Vulkan 백엔드를 추가함으로써 이 문제를 해결하기 시작했으며, 이를 통해 다양한 제조사의 외장 GPU를 아우르는 신뢰할 수 있는 경로를 엔진에 제공합니다.

Vulkan이 판도를 바꾸는 이유

Vulkan은 보통 게임 업계에서 주로 논의되지만, 저지연(low-overhead) 크로스 플랫폼 컴퓨팅 API로서 추론(inference) 분야에서도 그 중요성이 매우 큽니다. Vulkan은 CUDA가 무시하는 하드웨어까지 지원합니다. Intel UHD 및 Iris Xe 내장 칩, 구형 외장 그래픽 카드, NVIDIA 스티커가 붙어 있지 않은 저가형 Windows 노트북 등이 그 예입니다. 로컬 추론 엔진에게 이러한 확장성은 실질적인 힘이 됩니다. 개발자는 CUDA 전용 솔루션보다 훨씬 더 많은 기기에서 작동하는 단일 바이너리 경로를 배포할 수 있습니다.

TensorSharp의 Vulkan 지원은 GGML 프로젝트를 통해 처음 선보였습니다. 현재 이 통합 기능은 정상적으로 작동하며, 개발자는 추후 네이티브 Vulkan 백엔드를 구축할 계획입니다. GGML을 가교로 활용한 것은 적절한 단계적 조치였습니다. 이는 아키텍처를 검증하는 동시에 테스터들이 즉시 하드웨어를 사용할 수 있게 해줍니다. 이후 네이티브 백엔드가 도입되면 추상화 오버헤드를 제거하고, C# 중심의 엔진이 커맨드 버퍼(command buffers)와 메모리 배리어(memory barriers)를 더욱 세밀하게 제어할 수 있게 될 것입니다.

현재까지의 테스트 범위

검증 작업은 이미 매우 다른 두 가지 Windows 환경을 대상으로 완료되었습니다. 개발자는 NVIDIA GeForce RTX 3080 Laptop GPU와 일반 Intel UHD Graphics에서 테스트를 진행했으며, 두 환경 모두 원활하게 작동했습니다. 이 범위는 주목할 만합니다. 추론 분야에서 고전력 외장 그래픽과 기본적인 내장 그래픽이 이토록 쉽게 공통된 테스트 환경을 공유하는 경우는 드뭅니다. 전용 GPU가 없는 가벼운 노트북을 사용 중이라면, 이제 TensorSharp는 NVIDIA 드라이버에 의존하지 않는 실질적인 가속 경로를 제공합니다.

현재 테스트 범위에서 빠져 있는 부분은 AMD입니다. 아직 Radeon 하드웨어는 테스트되지 않았습니다. AMD GPU를 보유하고 있다면 프로젝트에 피드백을 보내주시기 바랍니다. RX 6000 또는 7000 시리즈 카드에 대한 커뮤니티 검증은 실험적인 백엔드를 프로덕션급 옵션으로 탈바꿈시키는 핵심입니다. 오류가 발생하면 이슈를 등록해 주시고, 성능이 뛰어나다면 역시 이슈를 남겨주세요. 어떤 결과든 프로젝트를 앞으로 나아가게 합니다.

TensorSharp는 래퍼(Wrapper)가 아닙니다

이 점은 강조할 가치가 있습니다. TensorSharp는 llama.cpp를 C#으로 묶어놓은 바인딩이 아닙니다. 개발자는 엔진 전체를 처음부터 직접 구축했습니다. CPU 백엔드는 순수 C#으로 작성되었습니다. GPU 없이 추론을 실행할 때, 여러분은 C++ 바이너리로 FFI(foreign function interface)를 통해 마샬링하는 것이 아니라 매니지드 코드(managed code)를 직접 실행하게 됩니다. 또한 이 프로젝트는 CUDA, Apple의 MLX, GGML을 위한 전용 백엔드도 유지 관리합니다. 이러한 아키텍처적 독립성에도 불구하고, 성능은 대부분의 로컬 추론 프로젝트가 목표로 삼는 기준점인 llama.cpp와 대등한 수준입니다. 이러한 동등한 성능을 확보하는 것은 매우 어려운 일입니다. 이는 메모리 레이아웃, 커널 디스패치, 텐서 연산이 실제 부하 상황에서도 안정적으로 유지됨을 의미합니다.

모델 지원 범위에는 Gemma4, DiffusionGemma, Qwen3.6이 포함됩니다. 런타임은 멀티모달 작업도 처리합니다. 비전, 오디오, 추론 파이프라인이 동일한 엔진을 통해 실행됩니다. 스크린샷을 읽고 음성 명령을 받는 데스크톱 어시스턴트를 프로토타이핑할 때, 세 개의 별도 런타임을 하나로 엮고 메모리 점유율이 기기 용량 안에 들어오기를 기도할 필요가 없습니다.

플랫폼 및 API 유연성

TensorSharp는 Windows, macOS, Linux에서 실행됩니다. 새로운 Vulkan 백엔드는 기존의 CUDA 및 Metal 경로와 함께 해당 플랫폼 환경에 깔끔하게 통합됩니다. 엔진은 OpenAI 및 Ollama API와의 호환성도 제공합니다. 이러한 선택은 통합 과정의 마찰을 제거합니다. 프롬프트 템플릿을 다시 작성하거나 새로운 응답 형식을 파싱할 필요 없이, 기존 클라이언트 코드를 로컬 TensorSharp 서버로 연결할 수 있습니다. 이미 내부적으로 Ollama를 실행 중이거나 OpenAI의 REST 인터페이스를 기반으로 개발 중인 팀의 경우, 로컬 TensorSharp 인스턴스로 전환하는 것은 단순히 기본 URL(base URL)을 변경하는 문제에 불과합니다.

효과적인 최적화 기술 도입

성능은 단순히 어떤 API가 GPU와 통신하느냐에만 달려 있지 않습니다. TensorSharp는 다른 곳에서 프로덕션 환경을 통해 검증된 여러 최적화 기술을 통합했습니다.

vLLM에서 가져온 Paged KV cache는 긴 대화 중에 메모리가 급격히 팽창하는 것을 방지합니다. 시퀀스당 하나의 연속된 스크래치패드(scratchpad)를 예약하는 대신, 엔진은 고정된 크기의 페이지를 할당하고 필요에 따라 이를 매핑합니다. RAM 사용량이 급증하는 것을 걱정하지 않고도 컨텍스트 창을 더 오래 열어둘 수 있습니다.

vLLM에서 제공하는 컨티뉴어스 배칭(Continuous batching)은 처리량을 향상시킵니다. 엔진은 현재 그룹이 완료될 때까지 기다리는 대신, 활성 배치에 새로운 요청을 끼워 넣을 수 있습니다. 한 사용자의 프롬프트가 10토큰이고 다른 사용자의 프롬프트가 200토큰이라면, 하드웨어는 더 바쁘게 작동하며 평균 지연 시간은 감소합니다.

Mixture-of-Experts 모델의 경우, TensorSharp는 oMLX에서 가져온 SSD 기반 캐시 전략을 구현합니다. 자주 액세스하는 전문가 가중치(expert weights)는 시스템 RAM을 차지하기 위해 경쟁하는 대신 빠른 스토리지에 준비된 상태로 유지됩니다. 메모리는 제한적이지만 괜찮은 NVMe 드라이브를 갖춘 머신에서, 이는 MoE 아키텍처를 계속 사용할 수 있게 해줍니다.

양자화는 llama.cpp에서 확립된 GGUF 표준을 따릅니다. 양자화된 4비트 및 5비트 모델은 별도의 변환 단계 없이 바로 로드됩니다.

핵심 요약

Vulkan 지원을 통해 TensorSharp는 흥미로운 C# 실험 프로젝트에서 이기종 하드웨어를 위한 실용적인 추론 옵션으로 거듭납니다. 로드맵은 명확합니다. AMD 및 Intel 외장 실리콘에서 검증한 다음, 네이티브 Vulkan 백엔드로 구현을 정교화하는 것입니다. 워크스테이션이나 노트북에 AMD 카드가 있다면, 빌드를 실행하고 결과를 공유해 주세요. 그러한 피드백 루프가 실험적인 코드를 실제로 배포 가능한 수준으로 견고하게 만듭니다.

릴리스 상세 정보는 개발자의 글에서 확인할 수 있습니다. 이 프로젝트가 CUDA 툴킷을 다루느라 애쓰거나 macOS 버전 제약과 씨름하는 수고를 덜어주었다면, 저장소에 스타(star)를 남겨주세요. 지속적인 토론과 커뮤니티 테스트 스레드를 위해 Telegram 그룹은 항상 열려 있습니다.