엔비디아, 에이전트용 경량 모델 Nemotron 3.5 Lightning과 스마트 라우팅 라이브러리 NeMo Switchyard 공개

NeMo Switchyard 프롬프트 캐싱 어떻게 처리하는지 궁금함. 세션마다 같은 모델에 고정 안 시키면 두번째 요청이 최적 모델로 안 갈 수도 있잖아

깃허브 README 보면 "실험용, 프로덕션 사용 금지"라고 써있음. 보도자료는 배포하라는데 README는 하지 말라는거, 서로 다른 얘기하는 중

캐시 유지랑 라우팅 성능 사이 트레이드오프 설정 가능한 라우터 본 적 있는데, 이런 오버헤드가 진짜 그만큼 가치있나 싶긴 함

모델들이 같은 공유 캐시 쓰면 캐싱 가능함. 근데 다른 프로바이더 모델 섞어쓰는 경우엔 공유 캐시 자체가 불가능함, 이 라우터는 한곳에 모델 모아두고 쓰는 걸 전제로 한듯

Meta의 30B 모델 Muse Glimmer가 훨씬 낫다는 벤치마크 봄

Glimmer는 dense고 Lightning은 sparse라서 activated 파라미터가 10배 차이남, 그만큼 Glimmer가 느림

Qwen 계열을 Artificial Analysis 그래프에서 슬쩍 빼놓은 거 좀 비겁함, Max 버전 하나만 끼워넣고

Nemotron 3.5 Lightning 얼마나 적은 VRAM에서 도나, q4로 16GB에서 될까

안 될 것 같은데. 커스터마이징 쉽다는 얘기 듣고 생각해보니 35B용 LoRA도 만들 수 있는데 굳이 벤치마크상 더 안좋은 이 모델 쓸 이유가 있나 싶음. 20B-A3B에 LoRA 붙여서 로컬 오케스트레이터로 쓰는게 16GB VRAM엔 더 맞을듯

램아포칼립스 이후로 작고 효율적인 모델에 더 집중하게 될거같음, 트릴리언 파라미터 모델들은 뭔가 근본적으로 놓치고 있다고 봄

Bitter Lesson 잊지 말자. 작은 모델도 결국 정보이론 한계에 부딫힘. 효율 개선 더하기 큰 모델 조합이 항상 더 나음

파라미터 낮추는거 컴퓨트나 인재 없는 소규모 랩들의 자기위안임. sparse 대형모델이 메모리 효율도 동등하면 작은 dense 모델은 존재 이유가 없음