KoHRM-Text-1.4B CPU Runtime
This repository contains a CPU-oriented inference runtime for
LLM-OS-Models/KoHRM-Text-1.4B.
It does not duplicate the original model weights. The runtime downloads the
base model from Hugging Face and applies CPU quantization at load time.
KoHRM-Text CPU Runtime Pack
작성일: 2026-06-09
결론
LLM-OS-Models/KoHRM-Text-1.4B는 현재 GGUF로 바로 만들 수 없다.
이유는 모델 구조가 일반 Llama/Qwen/Gemma 계열이 아니라 아래 전용 구조이기 때문이다.
1model_type: hrm_text
2architectures: HrmTextForCausalLM
3H_cycles: 2
4L_cycles: 3
5prefix_lm: true
llama.cpp 변환기로 직접 시도하면 다음 지점에서 막힌다.
ERROR:hf-to-gguf:Model HrmTextForCausalLM is not supported따라서 지금 현실적인 CPU 경로는 GGUF가 아니라 PyTorch 전용 runtime이다.
추가한 파일
1HRM-Text/inference/kohrm_cpu_runtime.py
2HRM-Text/inference/requirements-cpu.txt
3HRM-Text/scripts/upload_kohrm_cpu_runtime_pack.py
이 runtime은 기존 HRM-Text/notebooks/kohrm_colab_generate.py의 safetensors 직접 로딩 경로를 재사용하고, CPU용 양자화와 H/L cycle override를 추가한다.
사용법
기본 권장값은 dynamic-int8이다.
1cd /home/work/.projects/LLM-OS-Models/Terminal
2
3CUDA_VISIBLE_DEVICES= OMP_NUM_THREADS=8 \
4python HRM-Text/inference/kohrm_cpu_runtime.py \
5 --model LLM-OS-Models/KoHRM-Text-1.4B \
6 --quant dynamic-int8 \
7 --prompt "리눅스에서 현재 디렉토리 파일 목록을 보는 명령어는?" \
8 --max-new-tokens 128 \
9 --max-seq-len 768 \
10 --temperature 0
16GB CPU RAM 환경에서는 아래 순서로 쓰면 된다.
11순위: dynamic-int8
22순위: none
33순위: weight-int4
dynamic-int8은 PyTorch CPU dynamic quantization을 사용한다. 일반적으로 메모리와 속도 균형이 가장 낫다.
weight-int4는 직접 구현한 portable 4bit weight-only fallback이다. 메모리는 줄지만 매 forward마다 unpack/dequantize가 들어가서 매우 느리다. “반드시 작은 메모리로 돌아가야 한다”는 경우에만 쓴다.
H/L cycle override
KoHRM은 같은 H/L module을 반복 적용한다. 기본은 H=2, L=3이다.
CPU에서는 아래처럼 반복 횟수를 줄여 속도를 올릴 수 있다.
1CUDA_VISIBLE_DEVICES= OMP_NUM_THREADS=8 \
2python HRM-Text/inference/kohrm_cpu_runtime.py \
3 --model LLM-OS-Models/KoHRM-Text-1.4B \
4 --quant dynamic-int8 \
5 --h-cycles 1 \
6 --l-cycles 1 \
7 --prompt "리눅스에서 현재 디렉토리 파일 목록을 보는 명령어는?" \
8 --max-new-tokens 128 \
9 --max-seq-len 768 \
10 --temperature 0
주의할 점은 명확하다.
H=2,L=3: 원래 품질 경로.H=1,L=1: CPU 속도 우선 경로.- cycle을 줄이면 품질이 떨어질 수 있다.
Smoke test 결과
같은 짧은 prompt, max_new_tokens=4, max_seq_len=128, OMP_NUM_THREADS=8 기준이다.
1none:
2 elapsed: 1.48s
3 speed: 2.69 tok/s
4 cycles: H=2, L=3
5
6dynamic-int8:
7 elapsed: 0.53s
8 speed: 7.59 tok/s
9 cycles: H=2, L=3
10
11dynamic-int8 + H=1,L=1:
12 elapsed: 0.24s
13 speed: 8.18 tok/s
14 cycles: H=1, L=1
15
16weight-int4:
17 elapsed: 23.25s
18 speed: 0.17 tok/s
19 cycles: H=2, L=3
짧은 smoke test라 절대 성능 숫자는 참고용이다. 하지만 방향은 분명하다.
1실사용: dynamic-int8
2메모리 강제 절약: weight-int4
3품질 유지: H=2,L=3
4속도 우선: H=1,L=1
왜 GGUF가 어려운가
GGUF 파일은 단순히 weight를 담는 포맷이 아니다. llama.cpp가 해당 architecture의 forward pass를 알아야 한다.
KoHRM은 일반 Transformer block을 한 번씩 쌓는 모델이 아니다.
- H module과 L module이 있다.
H_cycles, L_cycles만큼 recurrent하게 반복한다.- PrefixLM formatting과 stop token 처리가 다르다.
- KV cache 구조도 일반 chat causal LM과 다르다.
따라서 GGUF를 제대로 만들려면 다음 작업이 필요하다.
11. llama.cpp MODEL_ARCH에 HRM_TEXT 추가
22. H/L recurrent forward 구현
33. gqkv gated attention 구현
44. PrefixLM prompt/token boundary 처리
55. tokenizer pre-tokenizer hash 등록
66. quantized tensor name mapping 작성
77. llama-cli generation smoke test
단순 converter patch로 끝나는 문제가 아니다.
HF CPU pack
HF에는 가중치를 중복 업로드하지 않고 CPU runtime pack을 따로 올린다.
대상 repo:
LLM-OS-Models/KoHRM-Text-1.4B-CPU-Runtime이 repo에는 다음만 들어간다.
1README.md
2inference/kohrm_cpu_runtime.py
3inference/requirements-cpu.txt
4notebooks/kohrm_colab_generate.py
가중치는 실행 시 원본 repo에서 받는다.
LLM-OS-Models/KoHRM-Text-1.4B공용컴 기준으로 HF token은 .env에서 읽되 출력하지 않는다.
