d1-3B를 로컬에서 구동하여 장비 점검 기록 48건 재측정 — 클라우드에 전송할 수 없는 데이터 선별에 활용 가능한가

결론: 로컬에서도 '판단'은 작동한다. 속도는 하드웨어 사양에, 정확도는 임계치 설정에 달려있다

먼저 세 가지 결론을 말씀드립니다.

• 사양이 낮은 PC에서도 작동했습니다. Celeron(4코어・GPU 없음) + 메모리 3GB의 WSL2 환경에서 d1-3B는 구동됩니다. 모델 파일은 Q4_K_M으로 1.67GB입니다. 다만, 건당 속도는 약 2분 (중앙값 115.1초)으로, 클라우드 유료 사용량(0.48초)의 약 240배에 달합니다. 참고치로, 공식 RTX 4090에서는 8ms, Jetson Orin Nano에서도 50ms이므로, 같은 모델이라도 자릿수가 3~4개 차이가 납니다. 따라서 '로컬 = 느리다'가 아니라 '로컬 = 하드웨어 사양에 따라 다르다'입니다.
• 정확도는 클라우드와 큰 차이가 없었습니다. 즉시 필요 여부는 41/48 (85.4%)로, 클라우드의 d1·Jev와 동률입니다. 대응 수준은 48/48로 세 모델 중 최고였습니다. 다만 놓친 케이스가 1건 발생했습니다 (클라우드는 0건). 3B 모델을 현장에서 사용하려면 임계치(threshold) 교정이 클라우드보다 더 중요합니다.
• 모델 이용료는 0원이며, 데이터는 외부에 나가지 않습니다. 모델을 한 번 다운로드하면 추론은 완전히 로컬에서 이루어집니다. C#(.NET)에서도 HttpClient를 통해 바로 호출할 수 있었습니다. 다만 라이선스(LFM Open License v1.0)에 따르면 연간 매출 1,000만 달러 이상의 기업의 상업적 이용은 무상 대상이 아닙니다. 사내에서 사용하기 전에 반드시 확인해야 합니다 (FAQ에서 후술).

즉, '로컬이 즉시 판단을 대체할 수는 없다. 하지만

여기서가 난관의 첫 번째 지점(ハマりどころその1)이었습니다. 이 미니 PC의 CPU는 AVX 명령어에 대응하지 않습니다(SSE4.2까지). 순수하게 생각하면, 빌드된 바이너리는 'Illegal instruction'으로 다운될 가능성이 있습니다. 하지만 최근의 llama.cpp는 CPU 기능별 라이브러리(sse42~cannonlake)를 포함하고 있어, 시작 시 맞는 것을 자동으로 선택해 줍니다. 실제로 제 환경에서는 SSE4.2 버전으로 그대로 작동했습니다.

3. 서버 실행하기

llama-b11539/llama-server -m d1-3B-Q4_K_M.gguf \
-c 4096 --host 127.0.0.1 --port 8080 -t 4

실행 로그를 보면, 제대로 판별 모델로 인식되었습니다.

load_model: loading model 'd1-3B-Q4_K_M.gguf'
init: decision model type: lfm2-d1
llama_server: model loaded
...

모델 로드는 9.6초, 동작 중 메모리 사용량은 약 1.7GB였습니다. 메모리 3GB의 WSL2에 겨우 들어가는 정도가 이 환경의 실태입니다(스왑을 사용하면서도, 48건의 측정 중에는 한 번도 다운되지 않았습니다).

4. 판별 데이터를 전송하기 — 클라우드 버전과 완전히 동일한 형식

curl http://127.0.0.1:8080/v1/systemone -H "Content-Type: application/json" -d '{ 
"state": "【일상점검】…（점검 기록의 텍스트）",
"questions": { ...

난관의 두 번째 지점이 바로 여기입니다. 모델이 작동한다고 판별할 수는 없습니다. 판별 모델은 문장을 생성하지 않는 모델이기 때문에, '질문(noul/score/choice)을 해석하여 확률로 변환하는' 실행 환경 측의 대응이 필요합니다. llama.cpp의 llama-server

는 /v1/systemone

엔드포인트에서 이것을 제공하고 있으며, 클라우드의 d1・Jev와 완전히 동일한 요청 형식으로 사용할 수 있습니다. 지난번 측정 코드가 URL 한 줄만 바꾸면 그대로 로컬에서도 작동한다는 것이 이번에 가장 기쁜 포인트였습니다.

참고로, 처음에 공식 문서의 샘플(환불 문의)을 전송했을 때는 29.5초가 걸렸습니다. 이 시점에서 '이건 즉시 판단 속도가 아니구나'라고 알았지만, 측정은 측정이라 끝까지 진행했습니다.

실측 — 같은 48건을 다시 전송하기

속도 — 건당 약 2분. 클라우드의 약 240배

48건으로 약 1시간 35분입니다. 야간 배치 작업이라면 충분히 돌릴 수 있는 범위입니다. 서버 로그를 보면, 프롬프트 처리는 약 4.0 토큰/초였고, 세 가지 질문은 개별 슬롯에 분리되어 병렬로 처리되고 있었습니다.

참고로, Liquid AI 공식의 수치는 RTX 4090에서 8ms, Jetson Orin Nano에서 50ms입니다. 기록의 길이도 언어도 다르기 때문에 단순 비교는 할 수 없지만, 사용하는 하드웨어에 따라 자릿수가 3~4개 변한다는 것은 확실합니다.

정확도 — 놓친 건 1건. 대응 수준은 48/48

읽는 법은 3가지입니다.

정답률만 보면 3자 동률이지만, 내용은 다릅니다. 지난번에는 클라우드의 d1과 Jev가 48건에서 이진 판단이 완전 일치했습니다. 로컬은 2건에서 판단이 갈렸습니다. 한 건은 놓친 경우(후술), 나머지 한 건은 반대로, 클라우드 d1이 '과잉'으로 판정한 케이스를 로컬이 올바르게 보류하고 있습니다. 참고로, 정답 라벨은 지난번부터 변경하지 않았습니다 (지난번 재검토 후보로 제시했던 2건도 비교를 위해 그대로 두었습니다).

놓친 1건에 대해 솔직하게 말씀드리겠습니다. EQ-035, 프레스 브레이크의 굽힘 각도(90.8°・기준 외)와 암 평행도(0.18mm・기준 0.15mm 이하) 악화 기록입니다. 정답 라벨은 '오늘 양산 전 보전 확인' = 에스컬레이션 필요였습니다. 그런데 로컬은 확률이 0.16으로 낮게 보고 보류했습니다. 클라우드 d1은 0.96으로 포착했습니다. 즉, '수치는 기준 외이나 급격한 정지 징후는 없다'는 소견의 온도감을 3B 모델이 가볍게 읽어버린 경우입니다. 멈춰야 할 케이스를 놓친 것이라 현장에서 사용한다면 가장 주의해야 할 오류입니다 (이 건의 확률은 재실행에서도 0.16으로 변함이 없었으므로, 흔들림이 아니라 경향성입니다).

대응 레벨(0~3)은 48/48로 전일치했습니다. '얼마나 심각한가'의 단계 평가는 3B 모델에서도 안정적이어서 의외였습니다. 지난번 클라우드 d1이 놓쳤던 2건(열처리로의 모호한 경보, 컴프레서의 경계 사례)도 로컬은 정답 측이었습니다.

시연할 부분도 다시 언급합니다. 프레스#5의 안전 광선(한쪽 차광으로 정지하지 않음)은 로컬에서도 0.980・심각 2.92로 즉시 포착했습니다. 교정기#2의 틀어짐(어제 출하 판정에 파급)도 즉시 + 계장으로 정답이었습니다. 중대한 케이스 포착에는 로컬도 문제가 없었습니다.

임계값을 움직이면 무슨 일이 생길까

놓친 1건(0.16)을 잡으려면, 임계값을 낮춰야 합니다. 48건으로 추산하면 다음과 같습니다.

클라우드는 0.5로 놓침이 0이었지만, 로컬은 0.15까지 낮춰야 겨우 0이 됩니다. 대신 '과잉'이 6건에서 11건으로 늘어납니다 (임계값을 낮추면 대응 필요할 뿐만 아니라 경미/정상 기록도 '과잉'에 포함되기 때문에, 즉시 불필요한 39건이 상한선입니다). 이번 로컬(3B)에서는 교정의 여백을 넓게 잡을 필요가 있었습니다. 다만, 0.15는 놓친 1건에 맞춰 결정한 값입니다. 같은 48건으로 나중에 정하기 때문에, 다른 데이터에서도 놓침이 0이 될 것이라는 보장은 없습니다. 실제 운영에서는 다른 기록 세트로 재검증할 것입니다. 임계값은 '모델의 기본값'이 아니라 '자신의 놓침 비용'으로 결정해야 합니다—지난번에 작성한 원칙이 로컬에서는 더욱 유효합니다.

재현성

대표 3건(정상 기록・놓친 케이스・안전 케이스)을 나중에 다시 흘려보냈습니다. 결과는 소수점 이하까지 완전 일치했습니다 (EQ-035는 재실행에서도 0.16240377533874165, EQ-044는 0.9802823834891077). 같은 장비・같은 모델 파일이라면, 로컬에서는 답이 안정적이었습니다 (확인한 것은 3건뿐입니다). 지난번 클라우드 버전 Jev에서는 0.31과 0.29와 같은 흔들림이 있었기 때문에, '어제와 오늘로 판정이 달라졌다'는 일이 일어나기 어려운 것이 기록을 남기는 업무에서는 로컬의 장점일 수 있습니다.

C#에서 호출하기 — 업무 도구에 통합은 HttpClient 하나면 충분

지난 기사에서 '다음은 C#부터'라고 했기에, 해보았습니다. 로컬 서버는 127.0.0.1에 닫혀 있고 API 키도 필요 없으므로, HttpClient로 POST만 하면 됩니다. .NET 10의 콘솔 앱으로 의존 패키지는 없습니다.

// Program.cs — 로컬 d1-3B(llama.cpp /v1/systemone)을 C#에서 호출하는 최소 구현
using System.Diagnostics;
using System.Net.Http.Json;
...

실행 결과입니다.

HTTP 200 / 115.0 초
즉시 에스컬레이션 필요: 0.980 → 필요
대응 레벨(0~3): 2.92
...

48건 측정의 동일 레코드(EQ-044: 0.980・2.92・electrical)와 같은 답이 돌아왔습니다. 클라우드 버전과 같은 질문 형식 그대로, 호출 대상을 로컬로 바꿀 수 있다는 의미입니다. WinForms나 WPF 점검 기록 앱에 추가하려면, 기록 저장 시 이 호출을 거쳐 '확인 필요' 태그를 다는 형태가 됩니다.

다만 한 가지 주의할 점이 있습니다. 위 코드에서 Timeout을 15분으로 설정했습니다. 기본값인 100초로는 Celeron 환경에서는 첫 번째 건에서 시간 초과가 발생합니다. '느리기는 하지만 기다리면 돌아온다'는 전제하에, 업무 도구 측은 비동기 방식 + 진행 표시를 함께 구현하는 것이 현실적입니다.

보충 설명: 동일한 /v1/systemone 형식은 Ollama 0.35 이후 버전에서도 사용할 수 있습니다(nimble이나 tev1 등에도 대응). 또한, Ollaya(Apache 2.0・TypeSafe 호환 API)라는 실행 애플리케이션도 출시되어 로컬 실행의 선택지가 늘어나고 있습니다. 이번에는 llama.cpp 공식 절차를 통해 진행했습니다.

'클라우드에 전송할 수 없는 데이터'로 판정 모델 사용 조건

이번 실측을 통해 활용처를 정리합니다.

요약 — 로컬 실행의 현재 위치

• d1-3B는 GPU가 없는 메모리 3GB PC에서도 구동됩니다 (모델 1.67GB・로드 9.6초・추론 중 1.7GB) - 속도는 건당 약 2분.
  즉시 판단은 불가능하지만, 야간 배치 작업의 1차 선별은 현실적입니다 - 정확도는 클라우드에 근접합니다 (즉시 필요 여부 85.4% 동률・레벨 48/48). 다만 놓친 건이 1건 있으며, 임계값을 0.15로 하면 놓친 건 0으로 만들 수 있습니다 (이번 48건 기준이며, 과도하게 설정하면 늘어남) - C#에서는 HttpClient로 바로 호출 가능합니다. API 키가 필요 없고 시간 초과만 길게 설정할 수 있습니다 - 데이터는 외부로 나가지 않으며 모델 이용료는 0원입니다 (단 라이선스 조건 있음)・재현성은 양호합니다 (3건 재실행 시 소수점 이하까지 일치).

다음으로는 d1-3B가 이미지도 처리할 수 있게 되었기 때문에, 이쪽을 시도해 볼지, 아니면 C# 앱에 상주시켜 '기록 입력과 동시에 태그가 붙는' 형태로 만들지 고민하고 있습니다. 어느 쪽으로 진행하게 되면 여기에 다시 작성하겠습니다.

자주 묻는 질문

Q. GPU 없이도 정말 구동되나요?

A. 구동됩니다 (본 기사의 실측 결과입니다). CPU는 Celeron, 메모리 3GB로 건당 약 2분 정도 걸립니다. 다만 '구동된다'와 '사용 가능하다'는 별개이므로, 즉시 판단에는 적합하지 않습니다. 야간 배치나 시험 운영부터 시작하는 것을 추천합니다.

Q. 모델은 어디서 얻나요? 라이선스는요?

A. Hugging Face의 LiquidAI/d1-3B-GGUF에서 무료로 다운로드할 수 있습니다. 라이선스는 LFM Open License v1.0이며, Apache 2.0을 기반으로 연간 매출 1,000만 달러(환율에 따라 약 15억 원 전후) 이상의 기업은 무상 상업 이용 대상에서 제외된다는 조건이 붙어 있습니다 (공식 가이드). 업무에서의 이용은 '상업'에 해당할 가능성이 있으므로, 사내 법무/지적재산권 부서에 확인해 주십시오. 양자화는 메모리 용량에 맞춰 선택합니다(3GB 환경이라면 Q4_K_M의 1.67GB).

Q. 클라우드 버전과의 정확도 차이는 얼마나 되나요?

A. 이번 48건에서는 즉시 필요 여부 정답률이 동일하게 85.4%였습니다. 다만 내용물이 달랐는데, 로컬은 놓친 건 1개/과잉 6개, 클라우드는 놓친 건 0개/과잉 7개였습니다. 대응 레벨은 로컬이 48/48로 가장 안정적입니다. 경계 판단에 차이가 생기므로, 자체 데이터에서의 보정이 전제되어야 합니다.

Q. Ollama에서도 같은 것이 가능한가요?

A. Ollama는 0.35 이후 버전부터 판정 모델(nimble・tev1 등)의 로컬 구동을 지원합니다. d1-3B 실행은 본 기사에서는 llama.cpp (llama-server의 /v1/systemone)를 사용했습니다. 둘 다 동일한 요청 형식이므로, 취향에 따라 선택할 수 있습니다.

Q. 설비 안전장치 판단에 사용할 수 있나요?

A. 사용하지 않는 전제로 설계해 주십시오 (이전부터 일관). 안전은 결정론적인 별도의 시스템에 두고, 판정 모델은 '사람이 봐야 할 것의 선별'까지만 합니다.

출처

• Liquid AI 블로그 「Open d1: 텍스트, 비전 및 오디오를 위한 Edge decision models」
• Liquid AI 문서 (d1-3B) / llama.cpp 배포 절차
• Hugging Face 「LiquidAI/d1-3B-GGUF」
• Liquid AI 「LFM Open License v1.0 가이드」
• GIGAZINE 「로컬 실행 가능하고 이미지 입력도 OK한 의사결정 모델 『d1-3B』와 음성 입력도 가능한 『d1-omni-600M』 등장」
• GIGAZINE 「Ollama가 Jev 유사 의사결정 모델의 실행을 지원」
• GIGAZINE 「Jev 유사 의사결정 모델을 로컬에서 실행할 수 있는 Ollama 스타일 앱 『Ollaya』 등장」
• llama.cpp 릴리스 (b11539)
• Ollaya (GitHub)

측정일: 2026년 10월 10일 (48건 × 1회 + 재현성 3건). 측정 코드와 테스트 데이터는 지난 기사의 것을 재활용했습니다.

【연재】

• GitHub Copilot으로 루프 엔지니어링을 구성할 수 있는지 조사해봤다
• 루프 엔지니어링 다음은 정말 '그래프'인지 생각해봤다
• AI 에이전트의 '판단' 문제, 검사 공정은 이미 해결했다
• 판단에만 특화된 AI 모델 'Jev'를, 루프 → 그래프 → 판단 계보로 읽어내기
• Jev 활용 사례를 제조업의 눈으로 조사 — 검사의 1차 선별부터 로봇의 판단층까지
• Jev와 d1을 설비 점검 기록 48건으로 실측 비교 — 가동 재개 전 '멈출지' 판단에 사용 가능한가

스킬(AI의 행동을 고정하는 메커니즘)을 만드는 방법은 모아놓은 책에 적어두었습니다.

Discussion