배경 및 맥락
온디바이스 LLM은 개인정보, latency, 오프라인 사용성 때문에 계속 중요해지고 있지만, 실제 제품화 단계에서는 모델 크기보다 runtime coverage가 더 큰 병목이 된다. NPU가 일부 op만 처리하고 나머지를 CPU나 GPU로 넘기면 전력, 발열, latency가 급격히 흔들리며 사용자는 cloud inference보다 안정적인 체감을 얻기 어렵다.
최근 Notion cache에는 Kog Laneformer 2B처럼 serving-layer latency를 모델 설계로 다루는 사례와 Intel XPU Kernel Skill처럼 kernel optimization을 agent가 돕는 사례가 들어갔다. QHexRT는 이 흐름을 edge device 쪽으로 옮긴다. 핵심은 또 다른 small model 발표가 아니라 Qualcomm Hexagon NPU에서 prefill과 decode를 포함한 inference path를 runtime 수준으로 묶었다는 점이다.
핵심 내용
RunAnywhereAI는 2026년 6월 27일 기준 Hugging Face에 QHexRT 소개 글을 공개했다. QHexRT는 Qualcomm Hexagon NPU용 inference engine이며, 첫 model catalog entry로 Liquid AI가 2026년 6월 25일 공개한 LFM 2.5 230M을 지원한다. 발표는 runanywhere/lfm2_5_230m_HNPU bundle을 제시하고, decode graph, prefill graph, lm-head, embeddings가 모두 HTP에 머무른다고 설명한다.
이 점은 온디바이스 LLM에서 중요하다. 많은 edge demo는 일부 layer나 operator만 accelerator를 사용하고, 나머지 연산이 CPU fallback으로 흘러가면서 성능과 전력 예측 가능성이 깨진다. QHexRT가 강조한 full NPU path는 작은 모델을 단순히 양자화하는 수준을 넘어, 모델별 graph export와 runtime packaging을 product-grade deployment 단위로 관리하려는 방향이다.
경쟁 구도 / 비교
GPU 서버 추론에서는 vLLM, SGLang, TensorRT-LLM 같은 serving stack이 throughput과 batching을 경쟁한다. 반면 Hexagon NPU 같은 edge accelerator에서는 operator support, graph partitioning, memory movement, vendor SDK integration이 성능을 좌우한다. 같은 LFM 계열 모델이라도 GPU cloud에 올리는 것과 NPU bundle로 제품에 넣는 것은 전혀 다른 엔지니어링 문제다.
Qualcomm 생태계 관점에서도 QHexRT는 Windows Copilot+ PC와 Android edge AI 앱이 실제로 local model을 사용할 수 있는지를 가르는 하위 계층이다. 모델 제공자는 parameter count와 benchmark를 제시하는 데서 끝나지 않고, target silicon별 runtime artifact와 regression test를 함께 제공해야 한다.
의미
산업적으로 edge AI 경쟁은 cloud cost 절감만이 아니라 사용자 데이터가 머무는 위치와 응답 체감 품질을 재설계하는 문제다. 작은 모델이 충분히 좋아지고 NPU runtime이 안정화되면, 문서 요약, local search, private assistant, low-latency tool invocation 같은 기능은 cloud API 의존도를 낮출 수 있다.
실무적으로는 NPU 지원을 체크박스로 보지 말고, 모델 catalog, graph coverage, fallback policy, power profile, device별 QA matrix를 제품 요구사항에 넣어야 한다. 특히 agentic mobile feature는 background execution과 thermal limit에 민감하므로, QHexRT 같은 runtime 발표를 모델 평가 파이프라인의 일부로 다뤄야 한다.