업데이트: 지난 며칠 동안 35B 모델을 아주 하드코어하게 테스트해 보았습니다. 속도가 빠르고 낮은 컨텍스트 (low context)에서는 전반적으로 훌륭하지만, 높은 컨텍스트 (high context)에서는 환각 (hallucination)이 엄청나게 발생하며, 적어도 현재의 양자화 (quant) 버전에서는 멀티태스크 지시 (multi-task instructions)를 잘 따르지 않습니다. 제 redis 설정을 망가뜨리는 것을 포함하여 몇 가지 치명적인 실수를 저질렀습니다. 키를 삭제하거나, 스트림 (streams)을 업데이트하는 대신 무작위 해시 (hashes)를 생성하거나, 문서를 redis가 아닌 로컬에 추가하거나, 작업이 완료되었다고 말하면서 정작 작업은 완전히 누락하는 등의 일이 있었습니다... 정말 엉망진창이었습니다. 저는 더 중요한 작업에는 27B로 돌아가기로 결정했고, 35B는 단일하고 명확하게 정의된 작업에 계속 사용할 것입니다. 공개 사항: 지금 매우 빠르게 타이핑하고 있어 정리나 형식을 맞출 시간이 없습니다. 짧은 단락 구성이 불편하시다면 그냥 지나쳐 주세요. 컨텍스트 업데이트: (관심 있는 분들을 위해, 그렇지 않다면 건너뛰셔도 됩니다) 데이터 포인트에 관심 있는 분들을 위해 설명하자면, 작업 내용은 rivet 내부에서 mcp 서브그래프 (11개의 도구 목록 포함)를 포함하는 에이전트 워크플로우 (agentic workflow)를 구축하는 것이었습니다. 이 서브그래프는 메인 서브그래프로부터 JSON 지시를 받아 메인 에이전트의 메모리에서 30K 토큰을 절약할 수 있도록 설계되었습니다. 메인 서브그래프에는 컨텍스트 트리밍 (context trimming)과 메모리, soul, 그리고 에이전트 .md 파일의 사전 주입 (pre-injection)이 포함되었습니다. 또한 테스트, openwebui 및 llama.cpp를 이용한 구성, 그리고 서버와 owui 사이의 어댑터 브리지 (adapter bridge)를 생성하는 작업도 포함되었습니다. 에이전트는 CPU에서 병렬로 실행되는 더 작은 Qwen 2B 모델을 사용하여 이를 테스트했습니다. 이 모든 과정은 100% 제 에이전트에게 위임되었습니다. Qwen 3.6 35B가 출시되었을 때 많은 사람들이 찬사를 보냈고, 저는 그들이 단지 속도 때문에 과하게 칭찬하는 것이라고 생각했습니다. 3.5 버전에서는 27B가 35B보다 객관적으로 더 똑똑했습니다. 그래서 제가 27B 버전 (unsloth의 Q5KXL UD @ KV Q8/8)을 사용하게 되었을 때, 고민 없이 그것을 데일리 드라이버 (daily driver)로 사용하게 되었습니다. 루프 (loops)도 없고 속도도 안정적이었습니다. 그리고 지난 이틀 전까지는 거의 괜찮았습니다. 당시에는 속도가 저에게 그리 중요하지 않았고, 다시 말하지만 27B가 더 똑똑하다고 알려져 있었기에 35B에게는 기회를 주지 않았었습니다.

하지만 rivet에서 서브그래프 (subgraphs)를 디버깅하느라 이틀을 허비하고, 컨텍스트 오버플로 (context overflow)로 인해 양자화 (quants) 모델이 계속 끊기며 모델의 지능이 거세되는 (lobotomize) 상황 속에서 몇 시간이나 허비한 후에야, 최근 누군가가 IQ4NXLs (MTP + 표준)를 Q4KXL, Q5 및 다른 모델들과 비교 테스트한 게시물을 읽었던 것이 기억났습니다. 그래서 Qwen 3.6 35B IQ4NXL을 시도해 보았습니다. VRAM이 큰 문제가 아니었기에 KV 캐시 (KV cache) 압축은 사용하지 않았고, 모델은 거의 단 한 번의 시도만으로 해결책을 찾아냈습니다. 그 이후로 몇 번 더 테스트를 진행했는데, 잠시 동안 왜 35B가 더 나은지 혼란스러웠습니다. 그래서 저는 다음과 같은 이유 때문이라고 결론을 내렸습니다. a) Qwen 모델들은 여전히 낮은 양자화 (lower quants) 수준에서도 매우 뛰어나며, 더 중요한 것은 b) KV 캐시 (KV cache)가 정말 중요하다는 점입니다. 35B는 높은 컨텍스트 (high context)에 도달하면 여전히 느려지는데, 심지어 27B보다 더 심한 것 같습니다. 제가 세션 종료 루틴을 수행할 수 있는 유일한 방법은 KV Q4/4 설정의 Q4KXL로 전환하는 것이지만, 그렇게 하면 루틴을 잊어버리거나 세션 요약에서 세부 사항을 놓칠 위험이 있습니다. 또한, 아직 35B 모델들을 익히는 데 많은 시간을 할애하지 않았기에, 무엇이 가장 잘 작동하는지 파악하기 위해 탐색할 시간이 필요합니다. 어쨌든 요점은, 양자화되지 않은 KV 캐시를 사용하는 IQ4NXL이 KV Q8/8 설정의 27B Q5 K XL보다 성능이 뛰어났으며, KV Q4/4 설정의 27B Q4는 말할 것도 없다는 것입니다. 저는 항상 서로 다른 의견들이 있고 AI들이 지능의 저하가 미미할 뿐이라고 말하기 때문에 이것이 그리 중요하지 않다고 생각했습니다. 하지만 에이전트적 작업 (agentic work)에 있어서는 이것이 분명한 차이를 만들며 몇 시간의 시간을 아껴줄 수 있습니다. 그리고... 빠릅니다. 그래서 네, 저는 이제 35B를 훨씬 더 많이 사용하고 있습니다. 적어도 이 특정 프로젝트에 있어서는 말이죠. 저는 여전히 27B를 좋아하며, 양자화된 27B가 35B보다 더 잘해주길 바라는 다른 작업들도 있습니다. 그리고 27B에 대해 공정하게 말하자면, 저는 속도가 필요해서 KV 캐시 압축을 하지 않은 상태로 테스트해보지는 않았지만, 아마도 압축하지 않았을 때 지능 면에서 비약적인 향상이 있을 것이라고 가정합니다. 하지만 지금은 해야 할 일이 많고 시간이 촉박하며, 저에게는 RTX 3090 TI뿐입니다.

참고: 저는 몇 년 전 LLM (Large Language Models)을 사용하기 시작했을 때부터 LM Studio를 사용해 왔습니다. 하지만 현재 컨텍스트 (Context)를 넘치게 하거나 압축하지 못하는 버그 때문에, 새로운 세션을 시작하고, 에이전트 (Agent)가 모든 노트를 다시 읽게 하고, 그 모든 컨텍스트를 소모하게 한 뒤, 컨텍스트가 다시 가득 차면 마지막에 요약하고, 이 과정을 반복해야 해서 모든 작업 속도가 느려지고 있습니다. 그래서 llama.cpp로 옮겼습니다. 새로운 도구를 배우는 것(이미 계속 늘어나고 너무 많아진 앱 목록에 하나를 더 추가하는 것)이 귀찮고 번거롭게 느껴져서 llama.cpp 사용을 망설였지만, 에이전트 중심 (Agentic) 방식으로 전환한 이후로는 그냥 에이전트에게 컴파일을 시켰더니 잘 작동하더군요. 네, 맞습니다. 그냥 에이전트에게 맡기세요. 😄 /u/GrungeWerX 님이 제출함 [link] [comments]