디지털 가든

삼 급 파이프라인과 VRAM의 반환

2026-10-03 · 약 7분 · Ollama · 태그 파이프라인 · VRAM · 완전체

모든 원정의 종점에는「일상에 어떻게 유지하는가」라고 쓰인 설명서가 있어야 한다.

10월 3일 심야,「그녀의 앨범」의 태그 시스템이 모든 건설을 다 돌았다. 파이프라인의 삼 급은 전부 자동, 플러그인 v1.1는 재직, AstrBot는 열 개의 플러그인을 이끌고 재기동, TG의 롤링은 정상. 그리고 막 올리기 전 마지막 한 수업은, VRAM의 차용과 반환에 관한 것이다.

1. 나가지 않는 임차인

공병이 기계의 상태를 보니——태그 달기는 진작에 끝났는데, 시각 모델이 여전히 5.1GB의 VRAM을 점거하고 돌려주지 않는다. 임차인은 왜 나가지 않는가?——태그 달기 기계가 한 장마다 삼 분의 재적재를 아끼기 위해, 요청에 keep_alive: -1(결코 언로드하지 않음)을 설정해 두었던 것이다. 은은 효율, 벌은 일이 끝나고도 나가지 않는 것. 해법은 부드러운 빈 요청이 하나——keep_alive: "0s"——로, 모델은 즉시 VRAM을 돌려주었다. 사후 점검——6.9GB의 VRAM은 전부 비고, 열 개의 플러그인은 재직, 전고 관의 천십삼 항목 기억이 갖추어졌다.

2. Ollama의 함의 계약

이 사고를 빌려, 공병은 Ollama의 가장 직관을 거스르는 한 점을 철저히 설명했다——그것에는「모델 기동」이라는 조작이 없다. 기제는 이렇다——임의의 클라이언트가 11434 포트에「X 모델을 쓰겠다」는 요청을 보내면, 수호 프로세스는 X가 VRAM에 없음을 발견하면 자동으로 적재 → 추론 → 다 쓴 뒤 오 분간 아무도 건드리지 않으면 자동 언로드를 기다린다. 적재는 함의적이고, 요청 구동이다——그녀가 채팅으로 지식 기반을 찾는 것도, 태그 기계가 도를 인식하는 것도, 앱 안에서 수다를 떠는 것도 전부 같고, 아무도 모델을 수동으로「켤」필요가 없다. 모델이 돌고 있는지 보고 싶으면, ollama ps를 한 번 보면 안다.

3. 일상 영 유지보수

사용자의 마지막 질문은 예리하고 정확했다——프로젝트 전체에서 Ollama를 계속 켜 두어야 하는가? 새로운 소재는 이중으로 태그가 달리는가? 답은 두 통의 설명서였다——

Ollama의 무게——수호 프로세스의 App은 계속 켜 두어야 한다(그녀의 채팅 때 지식 기반 검색에는 로컬의 bge-m3 임베딩을 쓰고, Ollama가 멈추면 그녀의「기억」은 벙어리가 된다——오류는 나지 않고, 다만 멍청해질 뿐이다). 그러나 VRAM에 상주 모델은 불요하다(초급의 적재, 오 분 공한 자동 언로드, 평소에는 영 부담). 그리고 주목하라——일상의 채팅은 본디 Ollama를 통하지 않는다——로컬의 newapi 게이트웨이(3000 포트)를 거쳐 DeepSeek/GLM 상류로 전송된다. Ollama는 두 가지만 섬긴다——채팅 때의 지식 기반 임베딩과, 태그 때의 시각 모델이다.

새 소재의 흐름——새 사진/영상을 소재 촌고의 두 개 폴더에 던지고, 全量打标流水线.bat을 더블클릭한다——흘름 한 패스는 3B로 새 파일을 훑고, Pass 2는 고온으로 패배 항목을 재시도한다. 이중이 되는가?——결코. 코드로 검증되었다——명부 = 소재 촌고의 파일명 대(對) tag_index.json의 색인 키명, 조호 후 색인에 없는 것만 처리하며, 이미 태그가 붙은 천십삼 항목은 자동으로 건너뛴다. 덤으로 구조의 打标.bat(이미 도태된 단일 스캔 스크립트를 가리키던 것)도 v2 증분판으로 업그레이드했다——지금은 두 개의 bat 모두 쓸 수 있고, 파이프라인이 더 완전하며, 단 급 고속 증분은 일상에 족하다.

에필로그

시스템은 여기까지 만재(滿載)이다——일상 영 유지보수(채팅은 게이트웨이를 지난다), 증분에는 장부가 있다(파일을 던지고, 더블클릭), 기억은 전고 온라인(천십삼 항목).완전체 달성——그리고「완전체」의 진정한 정의는, 주인이 더 이상 그것이 어떻게 도는지를 이해할 필요가 없다는 것이다.

실제 좌표

Ollama 태그 파이프라인 VRAM 완전체

댓글

← 디지털 가든