API 비용을 피하기 위해 로컬 LLM 장비를 구축했지만, 결국 다시 OpenAI를 사용하게 된 이유

저는 1인 AI 기업을 운영하고 있습니다. 사이클당 수천 건의 단일 문서 추출이 필요한 2asy.ai의 파일링 파이프라인(filing pipeline)의 경우, 로컬 장비(local rig)가 배치 경로(batch lane)에서 밀려났고 OpenAI Batch가 승리했습니다. 이는 회사당 기준이 아닌, 파이프라인당 기준입니다.

결정적인 규칙은 다음과 같았습니다: 문서 간 어텐션(cross-document attention) 금지. 각 파일링은 자신만의 프롬프트 창(prompt window)을 가집니다. 문자열 연결(string concatenation)은 허용되지 않습니다. 이 규칙은 제가 이미 비용을 지불한 Neo4j 롤백(rollback) 사례에서 비롯되었습니다.

빠른 결과는 다음과 같습니다.

• llama.cpp 기반 로컬 Gemma 4 26B (RTX 4090 + W6800): 실시간 서빙(live serving)은 괜찮습니다. 하지만 배치 경로는 막혔습니다. vLLM에는 제가 필요한 4-bit MoE 경로가 없고, 컨테이너는 CUDA 12.9를 요구하지만 호스트 드라이버는 12.8입니다. 그래프 최적화 도중 세그멘테이션 오류(segfault)가 발생할 때 GGML_CUDA_DISABLE_GRAPHS=1 설정이 llama.cpp를 유지시켜 줍니다.
• OpenRouter: 실제적인 배치가 없습니다. 실시간 가격이 적용됩니다. 동시성(concurrency) 32에서 지연 시간(latency)은 2초에서 17초 사이이며, 121초 타임아웃과 429 오류가 발생합니다.
• Gemini batch SDK: 문서를 하나의 컨텍스트로 조용히 인라인 연결(inline-concatenates)해 버립니다. 문서 간 정보 유출(Cross-document leak)이 발생합니다. Neo4j 롤백 상황입니다. 업스트림 googleapis/python-genai 이슈 1984는 계획되지 않은 동작입니다.
• OpenAI Batch (gpt-5.4-mini): JSONL 라인 단위로 격리되어 있으며, 50% 저렴합니다. 2.7분 만에 100개 문서의 나노 게이트(nano gate)를 통과하며, 429 오류가 전혀 없고 문서당 약 1센트 정도의 비용이 듭니다.

로컬 장비는 실시간 서빙, ER API LLM 게이트, 멀티모달(multimodal) 및 절제 실험(ablations)을 위해 유지됩니다. 배치 경로는 OpenAI로 이동합니다.

비교 표를 포함한 전체 회고는 다음에서 확인하세요: https://hannune.ai/blog/local-llm-to-openai-batch.html