Forge, 8B 로컬 모델을 에이전트 작업에서 53%에서 99%까지 끌어올리는 가드레일 공개

• Forge는 자체 호스팅 LLM의 도구 호출(tool-calling)을 안정화하는 신뢰성 레이어임

  • 목표는 작은 로컬 모델이 다단계 에이전트 작업에서 형식을 깨거나 단계를 빼먹는 문제를 줄이는 것임
  • rescue parsing, retry nudges, step enforcement 같은 가드레일과 VRAM 인식 컨텍스트 관리, 계층형 압축을 제공함

• 벤치마크 숫자가 꽤 공격적임

  • 현재 상위 자체 호스팅 설정인 Ministral-3 8B Instruct Q8 + llama-server 조합은 Forge의 26개 시나리오 평가에서 86.5%를 기록함
  • 가장 어려운 advanced_reasoning 티어에서도 76%를 냄
  • 제목에선 가드레일로 8B 모델의 에이전트 작업 성능을 53%에서 99%까지 끌어올렸다고 강조함

• 사용 방식은 세 가지로 나뉨

  • WorkflowRunner는 도구 정의, 백엔드 선택, 구조화된 에이전트 루프 실행까지 Forge 위에서 직접 빌드할 때 쓰는 방식임
  • Guardrails middleware는 이미 자체 오케스트레이션 루프가 있는 팀이 Forge의 응답 검증, 잘못된 도구 호출 복구, 필수 단계 강제만 끼워 넣는 방식임
  • Proxy server는 OpenAI 호환 프록시로, opencode, Continue, aider 같은 기존 클라이언트와 로컬 모델 서버 사이에 끼워 넣는 방식임

• 프록시 모드의 아이디어가 특히 실전적임

  • 클라이언트는 http://localhost:8081/v1을 API base URL로 설정하면 됨
  • Forge 프록시는 요청에 도구가 있으면 합성 respond 도구를 자동 주입함
  • 모델은 일반 텍스트를 바로 쓰는 대신 respond(message="...")를 호출하게 되고, Forge는 이 호출을 최종 응답에선 제거함
  • 클라이언트 입장에선 그냥 정상 텍스트 응답을 받은 것처럼 보임

sequenceDiagram
    participant 클라이언트
    participant Forge프록시
    participant 로컬모델
    participant 도구
    클라이언트->>Forge프록시: OpenAI 호환 요청
    Forge프록시->>로컬모델: respond 도구 포함 요청
    로컬모델->>Forge프록시: 도구 호출 또는 respond 호출
    Forge프록시->>도구: 필요한 도구 실행
    도구-->>Forge프록시: 실행 결과 반환
    Forge프록시-->>클라이언트: 일반 텍스트 응답

• 작은 로컬 모델에선 이 respond 도구 주입이 중요하다고 설명함

  • 약 8B급 모델은 일반 텍스트 응답과 도구 호출 중 무엇을 골라야 하는지 안정적으로 판단하기 어렵다고 봄
  • 그래서 계속 도구 호출 모드 안에 머물게 유도해야 Forge의 전체 가드레일 스택이 적용됨

• 지원 백엔드도 로컬 LLM 사용자들이 실제로 쓰는 조합을 겨냥함

  • Ollama는 설치와 모델 관리가 쉬운 대안으로 소개됨
  • llama-server는 성능이 가장 좋고, 상위 10개 평가 설정이 모두 llama-server에서 돌아갔다고 함
  • Llamafile은 단일 바이너리와 무의존성이 장점이지만 네이티브 함수 호출은 없고 프롬프트 주입 방식임
  • Anthropic은 로컬 GPU 없이 쓰는 프런티어 기준선 또는 하이브리드 워크플로용으로 지원함

• 평가 스위트는 26개 시나리오로 구성됨

  • OG-18 기본 티어와 8개 advanced_reasoning 티어로 나뉨
  • 다단계 도구 호출 워크플로를 모델과 백엔드 조합이 얼마나 안정적으로 통과하는지 측정함
  • 논문 형태로도 “Forge: A Reliability Layer for Self-Hosted LLM Tool-Calling”이 공개됐고 DOI도 제시돼 있음

기술 맥락

• Forge의 기술적 선택은 모델을 바꾸기보다 모델 주변 실행 환경을 단단하게 만드는 쪽이에요. 8B급 로컬 모델은 비용과 프라이버시 면에서 매력적이지만, 도구 호출 형식 오류나 단계 누락 때문에 에이전트로 쓰면 자주 삐끗하거든요.

• 그래서 rescue parsing과 retry nudges가 중요해요. 모델 출력이 살짝 깨졌을 때 바로 실패 처리하지 않고 복구하거나, 필요한 형식으로 다시 시도하게 만들면 전체 워크플로 성공률이 크게 올라갈 수 있어요.

• respond 도구를 합성으로 넣는 설계도 꽤 현실적이에요. 작은 모델에게 “텍스트로 답할지 도구를 부를지 알아서 판단해”라고 맡기면 흔들리니, 아예 마지막 답변도 도구 호출처럼 만들고 프록시가 바깥에서 일반 응답으로 바꿔주는 방식이에요.

• VRAM 인식 컨텍스트 관리는 로컬 환경에선 필수에 가까워요. 클라우드 대형 모델처럼 넉넉한 컨텍스트와 메모리를 기대하기 어렵기 때문에, 긴 세션에서 무엇을 남기고 무엇을 압축할지 런타임이 계속 판단해야 해요.

• 이 접근은 온프레미스, 사내망, 개인 GPU에서 에이전트를 돌리려는 팀에 특히 맞아요. 모델 성능만 보는 게 아니라 백엔드, 프록시, 가드레일, 평가 시나리오를 한 묶음으로 봐야 실제 업무 자동화에 쓸 수 있거든요.