AI 에이전트를 만들고 토큰·비용을 아끼는 데 도움이 되는 오픈소스 도구와 기법을 모읍니다.
Model Shifter는 Claude Code에서 쓰는 모델과 작업 강도를 자동차 수동 기어처럼 바꾸는 맥용 도구다. 화면에는 최근 1분 동안 쓰는 토큰 양, 현재 5시간 사용 구간에서 남은 사용량, 저장된 기록 기준 누적 토큰 사용량이 자동차 계기판처럼 표시된다. 기어를 바꿀 때 클러치를 쓰면 새 세션을 열어 캐시 소모를 피하도록 설계됐다. 이후 실제 레이싱 게임용 기어 장치와 연결해 물리적으로 기어를 바꿀 때 Claude Code 모델도 바뀌는 기능이 추가됐다. FANATEC 장비는 기본으로 동작하고, Logitech 장비도 매핑할 수 있는 흐름이 언급됐다. 관련 논의에서는 Fable 사용량 제한과 사용 크레딧 전환 때문에 남은 사용량을 아끼거나 효율적으로 쓰려는 관심이 함께 나타났고, Fable과 Opus를 섞어 품질과 비용을 조절하려는 방식도 거론됐다.
Claude Code가 작업 전에 확인을 너무 적게 하거나 너무 자주 요구하는 문제를 줄이는 워크플로다. 핵심 방법은 프로젝트의 CLAUDE.md 파일에 실행 규칙을 넣어, 어떤 작업은 실행 전에 반드시 확인해야 하는지 미리 정하는 것이다. 이렇게 하면 AI가 사용자가 원하지 않은 변경까지 밀고 나가는 범위 확장을 줄이고, 아주 작은 작업마다 승인을 묻는 승인 피로도 줄일 수 있다. 난이도는 중급이며, 품질 관리, 토큰 절약, 문맥 관리, 디버깅, 배포 흐름에 쓰는 방식으로 분류되어 있다. 제공된 평가는 유용성 85점, 신선도 70점, 신뢰도 0.95이며 상태는 활성으로 표시되어 있다.
개인 환경에서 투기적 디코딩을 실제 전력 사용량까지 재서 비교한 결과, 속도 향상은 없었고 토큰당 에너지 사용량은 오히려 늘었다. 실험 장비는 8기가바이트 메모리의 RX 6650 XT 그래픽카드와 윈도우 11이었고, 실행 도구는 llama.cpp의 Vulkan 방식이었다. 기본 모델은 Qwen2.5-3B-Instruct 양자화 버전, 미리 초안을 만드는 작은 모델은 Qwen2.5-0.5B-Instruct 양자화 버전이었다. 두 모델은 모두 GPU에서 실행됐다. 같은 8개 질문을 반복 사용했고, 매번 256개 토큰을 만들었으며, 프롬프트 캐시는 껐다. 1개 요청만 처리하는 경우와 8개 요청을 동시에 처리하는 경우를 나눠 시험했고, 결과는 여러 번 생성한 값을 평균냈다. 전력은 LibreHardwareMonitor로 GPU 전력 사용량을 초당 약 6번 측정한 뒤, 생성 시간 전체의 에너지 사용량으로 계산했다. GPU가 쉬고 있을 때 전력은 약 19와트였고, 부하가 커질수록 투기적 디코딩의 에너지 손해가 더 커졌다.
개인 실험에서 GPT 5.5가 빈 깃허브 저장소를 맡아 매시간 스스로 작업하도록 설정됐다. 목표는 이전 작업을 확인하고, 다음 할 일을 정하고, 코드를 쓰고, 테스트한 뒤 변경 내용을 저장하는 것이다. 첫 작업은 실제 기능 구현이 아니라 작업 계획표, 변경 기록, 상태 파일, 결정 이유를 적는 파일을 만드는 데 쓰였다. 이후 AI는 자신이 만들려는 것을 “Autonomous Forge”라고 설명했고, 깃허브 프로젝트를 안전하게 관리하는 AI 유지보수 도구를 만들고 있다고 밝혔다. 저장소는 공개되어 있어 작업 판단, 테스트 실패, 수정, 과도한 문서 작업까지 그대로 지켜볼 수 있다. 아직 실제로 쓸 만한 도구가 될지는 확인되지 않았다.
한 AI 비서가 다른 고객의 문서를 요약한 일이 있었다. 외부 침입이 아니라, 벡터 검색이 요청받은 대로 의미가 비슷한 문서 조각을 찾아온 결과였다. 벡터 검색은 내용이 비슷한지를 볼 뿐, 누가 그 문서를 볼 수 있는지는 스스로 판단하지 못한다. 실제 문제는 문서 검색 뒤에 붙은 권한 필터 구조였다. 작업 공간, 소유자, 공개 범위, 역할, 보관 여부 같은 조건을 앱 코드 안에 직접 짜 넣었고, 세 가지 기능마다 조금씩 다른 복사본이 있었다. 이 필터는 매번 검색 때 실행되며 사실상 보안 경계였지만, 제대로 테스트되지 않았다. 조건 하나가 빠져도 오류가 나지 않고, AI는 사용자가 보면 안 되는 내용을 섞어 자연스럽고 확신 있는 답을 만들 수 있다. 나중에 조사하려 해도 로그에는 앱이 요청한 내용만 남고, 각 검색에서 실제로 어떤 권한 조건이 적용됐는지는 남지 않아 과거 접근 가능 범위를 증명하기 어려웠다.
Claude, Codex, Copilot, OpenCode, Z.AI, Kiro, Antigravity 같은 여러 인공지능 서비스를 함께 쓰는 사람을 위한 사용량 확인 도구가 공개됐다. 이 도구는 각 서비스의 사용량과 남은 한도를 터미널이나 Waybar에서 바로 확인할 수 있게 한다. 목적은 하루 동안 여러 서비스를 오가며 쓰다가 갑자기 한도에 막히는 일을 줄이는 것이다. 현재는 실제로 여러 서비스를 매일 쓰는 사람들에게 어떤 지표가 있어야 한도 초과를 피하는 데 도움이 되는지 의견을 모으고 있다.
회의 녹음과 통화 녹음을 많이 넣는 거대 언어 모델 파이프라인에서 음성을 글로 바꾸는 단계는 잘 작동한다. Whisper는 말소리를 텍스트로 바꾸지만, 결과물은 길고 정리되지 않은 문장 덩어리가 된다. 그 안에는 “음”, “어” 같은 군말과 말이 없는 구간까지 섞인다. 이 텍스트를 잘라 벡터 데이터베이스에 넣으면 RAG 에이전트가 쓸모없는 내용에도 컨텍스트 토큰을 많이 쓴다. 화자 이름이나 문서 구조가 없으면 대화 흐름을 놓치거나 환각이 생기기 쉽다. 핵심 문제는 녹취록을 그대로 넣을지, 먼저 정리해서 비용과 오류를 줄일지다.
모델을 새 데이터로 추가 학습할 때, 악의적인 데이터가 몰래 들어가면 특정 문구나 패턴에 반응하는 숨은 행동이 생길 수 있다. 제안된 방법은 모델이 아무 방향으로나 바뀌지 못하게 하고, 미리 신뢰한 LoRA 어댑터들이 표현할 수 있는 범위 안에서만 바뀌게 제한한다. 그러면 필요한 맞춤 조정은 어느 정도 가능하지만, 일부 악성 변화 방향은 구조적으로 닿을 수 없게 된다. 예를 들어 회사가 사용자 데이터, 외부 데이터, 생성 데이터로 모델을 계속 다듬을 때 작은 양의 오염 데이터가 뒷문 행동을 만들 수 있는데, 이 방식은 그런 변화를 탐지하기보다 애초에 배울 수 있는 업데이트 범위를 좁힌다. 개인 기기 안의 비서가 사용자에게 맞춰 계속 적응하는 경우에도, 새 데이터에서 어떤 행동이든 배우게 두지 않고 신뢰한 어댑터 묶음이 이미 담고 있는 행동 변화 안에서만 적응하게 만들 수 있다. 실험은 공개 LoRA 어댑터 196개와 방어를 우회하려는 적응형 공격까지 포함해 진행됐다.
앱에 대형 언어 모델을 넣으려면 특정 용도에 맞춘 미세 조정이 필요하다. 원래는 Together AI나 Fireworks 같은 서비스에서 LoRA 방식으로 조정한 모델을 토큰 사용량만큼 내는 종량제로 쓰려는 계획이었다. 하지만 예전처럼 LoRA 미세 조정 모델에 종량제 가격을 제공하는 곳을 찾기 어려워졌다. 관련 정보도 온라인에서 잘 보이지 않는다. 앱 테스트는 앞으로 몇 달 동안 간헐적으로만 진행될 예정이라, GPU를 빌려 계속 켜 두는 방식은 비용이 맞지 않는다. 핵심 고민은 LoRA 어댑터를 붙인 모델을 가장 싸게 호스팅하는 방법이다.
ElevenLabs 같은 유료 음성 생성 서비스는 비용이 부담될 수 있다. 대신 쓸 수 있는 오픈소스 텍스트 음성 변환 모델도 있지만, 보통 GitHub 저장소 안에 흩어져 있다. 직접 찾아서 내려받고 실행해야 해서 비전문가나 빠르게 비교하려는 사람에게는 불편하다. 이 도구는 여러 텍스트 음성 변환 모델을 한 화면에서 둘러보고, 실제 목소리를 바로 시험해 볼 수 있게 만든 독립형 화면이다.
Gemini 모델을 쓰는 다중 AI 에이전트 흐름에서 간단한 질문도 답이 나오기까지 약 2분이 걸린다. 흐름은 입력 가드레일, 플래너 에이전트, 여러 하위 에이전트, 응답 작성기, 출력 가드레일 순서로 이어진다. 입력과 출력 가드레일에는 NeMo가 쓰인다. 기능은 잘 작동하지만, 최종 답을 만들기 전에 모든 단계가 차례로 실행되기 때문에 전체 응답 시간이 길어진다. 핵심 고민은 실제 서비스에서 끝까지 걸리는 시간을 줄이는 방법, 가드레일을 동시에 돌릴지 차례로 돌릴지, 에이전트 작업이 끝나기 전에도 답변을 스트리밍할 수 있는지다. 예시 구조는 Smart Bill Book 워크플로 에이전트의 깃허브 이미지로 공유되어 있다.
대규모 언어 모델이 많은 기존 노드를 참고해야 하는 플랫폼을 만들고 있다. 예를 들어 DAG를 만들 때, 이미 정의된 여러 노드를 알고 있어야 하며 그래프를 구성하면서 그 노드들을 정확히 참조해야 한다. 핵심 고민은 많은 문맥을 모델에 넣으면서도 응답 지연, 비용, 추론 품질을 함께 관리하는 방법이다. 대부분의 문맥이 요청마다 거의 바뀌지 않는다면 문맥 캐싱이 좋은 해법인지가 문제다. 다른 선택지로는 Retrieval-Augmented Generation과 벡터 데이터베이스를 쓰는 방식이 있다. 다만 이 방식은 의미가 비슷한 몇 개만 찾아오는 데 강할 수 있어서, 모델이 많은 노드를 넓게 참조해야 하는 경우에는 부족할 수 있다는 우려가 있다.
AI 에이전트에게 지켜야 할 규칙을 프롬프트에 적어 두는 것만으로는 충분하지 않다. 프롬프트 안의 지시는 모델이 무시할 수 있고, 대화가 길어지면 앞부분의 문맥이 약해지며, 잘못된 판단으로 사라진 것처럼 행동할 수도 있다. 실제 규칙은 애플리케이션 코드나 설정처럼 예측 가능한 곳에서 강제해야 한다. 에이전트가 어떤 도구를 실행할 수 있는지, 어떤 데이터를 읽을 수 있는지, 어떤 행동을 할 수 있는지를 프롬프트 밖에서 제한해야 한다. 그렇게 하지 않으면 규칙이 아니라 모델에게 바라는 요청에 가깝다.
Mozilla 최고기술책임자 Raffi Krikorian은 2026년 7월 14일 오후 1시(미 동부시간)에 오픈소스 AI의 현재 상태를 다루는 실시간 질의응답을 진행한다. 같은 날 Mozilla는 첫 번째 ‘State of Open Source AI’ 보고서를 공개할 예정이다. 핵심 주제는 실제 서비스 운영에서 오픈소스 AI가 어떻게 쓰이는지, 기업과 개발자가 어디에서 막히는지, 무료처럼 보이는 모델과 폐쇄형 도구가 실제로는 어떤 비용을 만들 수 있는지다. 또 무료이면서 성능이 좋은 중국 모델들이 시장의 힘의 균형을 어떻게 바꾸는지, 950명 이상의 개발자가 어떤 AI 도구를 신뢰하는지, 그 이유가 무엇인지도 다룬다. 특히 모델 자체보다 그 위에서 에이전트를 움직이게 하는 agentic harness 계층이 더 중요한 경쟁 지점이 되고 있다는 관점이 포함된다.
AksharaMD는 LLM이나 RAG에 문서를 넣기 전에, 변환된 문서가 믿을 만한지 먼저 확인하는 로컬 파이썬 명령줄 도구다. PDF 같은 파일을 Markdown, 구조화된 JSON, 검증 경고, 작업 기록, 조각 JSON으로 바꿔 준다. 작업 기록에는 0~100점 준비 점수와 HIGH, OK, RISKY, POOR 같은 품질 등급이 들어간다. 경고에는 OCR이 필요한 문서, 글자 밀도가 낮은 문서, 깨진 글자 흔적, 토큰이 불필요하게 늘어나는 문제가 포함된다. OCR, 이미지·표 추출, 수식 OCR, 음성 전사, S3 입력은 선택 기능으로 붙일 수 있다. 소스 코드는 공개되어 있지만 PolyForm Noncommercial 1.0.0 조건이라 상업적 사용에는 제한이 있다.
Lians는 AI 에이전트가 필요한 사실을 저장하고 다시 꺼내 쓰게 하는 오픈소스 메모리 엔진이다. 시간에 민감한 정보나 규제가 있는 데이터를 다루는 상황을 겨냥한다. 모든 사실은 언제 실제로 유효했는지와 언제 시스템이 알게 됐는지를 함께 기록하는 방식으로 저장된다. 그래서 에이전트는 특정 과거 날짜 기준으로 당시 알려져 있던 내용만 불러올 수 있다. 기록 전체는 나중에 몰래 바꾸기 어렵도록 추가만 되는 해시 체인으로 남는다. 사람이나 대상별 암호화 키를 따로 두기 때문에, 키를 없애는 방식으로 삭제를 증명하면서도 감사 기록은 유지할 수 있다. 실행 방식은 앱 안에서 직접 돌리기, 직접 운영 서버에 올리기, 클라우드 사용을 모두 지원한다. Python, TypeScript, Go, Java, C용 SDK와 MCP 지원이 있고, 데이터 저장은 로컬 SQLite나 직접 운영하는 Postgres를 쓸 수 있다.
한 독립 연구자가 개인 소유 RTX 3090 한 대로 진행한 연구에서, '패스트웨이트 메모리 뱅크'라는 새로운 메모리 구조를 제안했다. 이 방식은 모델이 자기 자신의 순전파(forward pass, 입력을 한 번 통과시켜 출력을 얻는 계산 과정) 과정에서 작은 벡터 저장 공간(뱅크)에 직접 값을 써넣고, 이후 이 값을 데이터가 아니라 모델 가중치처럼 읽어들이는 구조다. 각 저장 슬롯은 하이퍼네트워크(다른 신경망의 가중치를 생성하는 신경망)를 거쳐 저랭크 MLP 레이어로 확장되어 입력 토큰 흐름에 적용된다. 목표는 역전파(backward pass, 오차를 거꾸로 전달해 가중치를 수정하는 학습 과정) 없이, 즉 별도의 최적화 과정이나 가중치 복제, 문맥 길이 증가 없이 추론 도중 새로운 지식을 계속 익히는 것이다. 실험은 3.08M 파라미터짜리 De카시크 스타일의 작은 트랜스포머에 8개 슬롯 메모리 뱅크를 붙여 진행했다. 대화마다 2개의 키 토큰에 새로운 규칙을 연결하고, 그 규칙을 13개 토큰으로 딱 한 번만 보여준 뒤, 나중 대화 턴에서 처음 보는 기호로 질문하는 방식이다. 각 턴은 완전히 독립된 순전파라서, 규칙이 턴을 넘어 전달되려면 반드시 메모리 뱅크를 거쳐야 한다. 무작위로 맞힐 확률은 0.008에 불과했고, 메모리 뱅크를 제거하면 정확히 그 무작위 확률 수준으로 떨어지는 것을 대조군으로 확인했다. 핵심 결과는 이 방식이 실제로 작동하고 일반화된다는 것으로, 단 한 번의 13토큰 제시만으로 한 번도 학습된 적 없는 규칙을 0.79~1.00의 정확도로 처음 보는 질문에 적용할 수 있었다(두 개의 시드에서 재현). 또한 해당 규칙을 저장한 슬롯을 물리적으로 강제 삭제해도 규칙이 살아남는 현상이 확인됐다.
중견 물류 회사에서 AI 에이전트를 화물 경로 결정에 쓰려 하고 있다. 이 에이전트는 어떤 운송사를 고를지, 여러 화물을 어떻게 묶을지, 어떤 경로로 보낼지 같은 결정을 돕는다. 문제는 잘못된 판단 하나가 바로 비용 손실로 이어질 수 있다는 점이다. 예를 들어 트럭이 잘못된 하역장으로 배정되면 운영 화면에서 사람이 알아차릴 때는 이미 손해가 난 뒤일 수 있다. 필요한 것은 채팅 로그 수준의 감시가 아니라, 에이전트가 어떤 입력을 보고 어떤 판단 흐름을 거쳤는지 확인하는 의사결정 수준 추적이다. 또 TMS에 실제로 반영되기 전에 운송사 최대 수용량 같은 업무 규칙을 자동으로 검사해야 한다. 일반적인 LLM 모니터링 도구는 대화형 챗봇을 살피는 데 맞춰져 있어, 큰 금액이 걸린 배차 결정을 실행 전에 막고 검증하는 용도에는 부족해 보인다.
추측 디코딩의 수학적 증명에 따르면, 거절 샘플링 방식은 최종 출력 분포를 큰 목표 모델과 같게 유지한다. 작은 초안 모델의 품질은 정답 보장 자체에는 들어가지 않는다. 초안 모델이 나쁘면 더 자주 거절되어 속도가 느려질 뿐, 목표 모델이 낼 답을 바꾸지는 않는다. 그래서 양자화처럼 품질을 조금 포기하고 속도나 비용을 얻는 방식과 다르다. 수용률은 초안 모델과 목표 모델의 출력 분포가 얼마나 다른지를 나타내는 총변동거리와 직접 연결되며, 구체적으로 1에서 총변동거리를 뺀 값이다. 이 관점에서는 추측 디코딩이 손실 없는 가속 기법이라면 왜 로컬 환경에서 기본값이 아닌지, 실제 모델 조합에서 어느 정도 빨라지는지가 핵심 질문이 된다.
koder는 브라우저 화면에서 쓰는 코딩·컴퓨터 작업용 에이전트 도구다. 11주 동안 약 1,300번의 커밋으로 만들어졌고, 리눅스에서 로컬 또는 오프라인으로 쓰는 것을 중심으로 설계됐다. OpenAI 호환 방식이라 로컬 모델뿐 아니라 클라우드 모델도 연결할 수 있다. 개발 환경의 기준은 리눅스, llama.cpp, Qwen 3.6 27b Q8이며, 이 조합에서는 안정적으로 동작한다고 한다. 다른 모델에서는 결과가 달라질 수 있고, Gemma 4는 잘 맞지 않았다고 한다. 작업 범위는 일반 코딩을 넘어 Ghidra를 이용한 역공학, 도구 제작, OpenSCAD 코드 작성과 렌더링 확인, 온라인 조사까지 포함된다.
MIRA는 General Intuition, Kyutai, Epic Games가 함께 만든 멀티플레이어용 세계 모델이다. 로켓 리그와 비슷한 4인 게임 상황을 예측하고 이어서 보여주는 모델이며, 1만 시간 분량의 합성 데이터로 학습됐다. 모델 크기는 50억 매개변수다. 한 대의 B200 그래픽 처리 장치에서 4명이 참여하는 장면을 초당 20프레임으로 실행할 수 있다. 온라인에서 직접 해볼 수 있는 데모, 자세한 기술 보고서, 4인 플레이 1천 시간 분량의 데이터셋, GitHub 저장소가 공개됐다. ICML 행사 현장에서는 플레이스테이션 컨트롤러로 직접 체험할 수 있는 데모도 운영된다.
GLM-5.2라는 7440억 개 매개변수 규모의 공개 AI 모델을 12코어, 25GB 메모리 노트북에서 실행한 개인 실험이다. 이 모델은 MoE 구조라서 전체 모델을 한꺼번에 메모리에 올리지 않아도 일부 조각만 골라 쓸 수 있다. 이를 위해 colibrì라는 작은 pure-C 실행 엔진을 만들었고, 자주 필요한 밀집 부분은 메모리에 약 10GB만 올린 뒤 필요한 전문가 조각은 디스크에서 그때그때 읽어 왔다. 양자화, 스트리밍, MTP 조정, 코딩 에이전트의 도움을 거쳐 실제 대화 응답까지 만들었다. 속도는 매우 느려서 처음 실행 기준 초당 약 0.05~0.1 토큰 수준이다. 그래도 이탈리아어 대화가 가능했고, 작은 장비에서도 대형 공개 모델이 실제로 응답할 수 있다는 점을 확인했다. 아직 1인 초기 프로젝트라 완성도는 낮으며, 더 빠른 NVMe 저장장치나 더 많은 메모리를 가진 사람이 성능 수치를 공유해 주길 기대하고 있다.
RAG 앱에서 벡터 데이터베이스가 저장 요청을 성공으로 돌려줘도, 그 자료가 곧바로 검색 가능한 상태라는 뜻은 아닐 수 있다. 사용자가 PDF를 올리고 화면에는 준비가 끝났다고 보이지만, 바로 이어서 질문하면 그 PDF 내용이 검색되지 않는 일이 생길 수 있다. 권한 정보가 바뀐 뒤에도 잠깐 동안 예전 권한 기준의 결과가 계속 나올 수 있다. 그래서 단순한 쓰기 지연 시간만 보면 실제 앱에서 겪는 문제를 놓친다. 중요한 기준은 API가 저장 요청을 받았는지뿐 아니라, 새 벡터가 검색되는지, 메타데이터 필터가 제대로 적용되는지, 재현율이 안정됐는지, 실제 클라우드 비용이 얼마인지까지 포함해야 한다. VDBBench 실험은 저장 요청 수락, 검색 가능 상태, 완전한 색인 완료, 비용을 나누어 측정하려는 접근이다.
Anthropic이 AI 모델이 실제로 글을 쓰기 전에 내부적으로 어떤 판단을 거치는지 들여다보는 연구를 발표했다. 이 연구는 '글로벌 워크스페이스'라는, 모델 내부에 정보가 모이고 처리되는 특정 영역이 존재한다는 것을 보여준다. Anthropic은 이 내부 구조를 들여다볼 수 있는 도구인 J-Space 렌즈 코드를 공개했고, 협력 파트너는 Qwen 3.6 27B라는 오픈소스 모델에 이 도구를 적용한 실제 시연 사례를 만들어 공개했다.
작은 4B 언어 모델로 만든 스마트홈 도우미는 한 문장 안에 여러 동작이 섞일 때 어려움을 겪는다. 예를 들어 “침실 조명을 켜고, 따뜻한 흰색으로 바꾸고, 밝기를 20%로 맞춰줘”는 세 동작처럼 보이지만 실제로는 하나의 최종 기기 상태다. 이를 순서대로 나누면 조명이 기본 설정으로 켜진 뒤 색이 바뀌고 다시 어두워져 사용 경험이 나빠질 수 있다. 반대로 “침실 조명을 켜고, 이 설정을 저녁 선호도로 저장해줘”는 기기 제어와 선호도 저장이라는 다른 영역이 섞였으므로 나누는 편이 맞다. 단일 명령에서는 Outlines로 켜기·끄기, 밝기, 색온도 같은 값을 뽑을 수 있지만, “복도 조명 3개를 30% 밝기로 켜고 침실 조명 4개를 꺼줘”처럼 여러 장소와 여러 동작이 들어가면 단순 분리가 문장을 망가뜨릴 수 있다. 핵심 고민은 먼저 영역을 분류한 뒤 기기 담당 에이전트가 관련 속성을 한꺼번에 처리하게 할지, 작은 언어 모델에 더 맞는 계획 방식이 있는지다.
다섯 개의 실제 인공지능 지식 베이스를 무료로 진단하고 고치는 실험이 진행된다. 대상은 겉으로는 작동하지만 정보를 자꾸 잊거나, 정해 둔 규칙을 무시하거나, 서로 다른 답을 내거나, 컨텍스트 창을 불필요하게 많이 쓰는 시스템이다. 점검 대상에는 RAG 프로젝트, ChatGPT나 Claude 위에 만든 프로젝트 지식 베이스, 바이브 코딩 방식의 문서와 프로젝트 규칙, 내부 인공지능 비서, 인공지능 작업 흐름에 넣을 문서 묶음, 웹에 배포된 인공지능 앱이나 챗봇이 포함된다. 핵심 문제는 이미 알려 준 내용을 인공지능이 반복해서 틀리거나, 문서를 넣었는데도 답이 맞지 않는 상황이다. 참여하려면 프로젝트와 겪는 문제를 개인 메시지나 댓글로 보내면 된다. 회사 기밀이나 민감한 정보는 보내지 말아야 한다.
Qwen 3.6 27B 모델을 MTP로 실행했을 때 초당 생성되는 토큰 수가 약 2배로 늘었다. 이는 같은 시간에 더 많은 답변을 만들 수 있다는 뜻이다. 경험자는 이 결과를 보고 MTP를 지원하는 다른 모델, 특히 abliterated MTP 모델도 찾아보려 한다.
로컬 인공지능 모델로 긴 대화를 처리하면 속도가 크게 떨어질 수 있다. M5 맥북 프로와 128GB 통합 메모리에서도 대화 길이가 16,000토큰쯤 되면 추론이 매우 느려졌다는 경험이 제시된다. 문제의 핵심은 모델 자체보다 계속 커지는 컨텍스트 크기다. 해결 방향은 한 에이전트가 모든 대화 기록을 들고 가는 방식이 아니라, 일을 작은 조각으로 나누고 각 조각을 짧은 새 세션에서 처리한 뒤 요약 결과만 다음 단계로 넘기는 방식이다. 예를 들어 밤새 여러 자료를 긁어 모으고 아침 대시보드를 만들 때, 작업자 여러 명이 각각 작은 추출을 맡고 마지막 집계자가 짧은 요약만 모아 결과를 만드는 map-reduce 방식이 더 현실적이다. 다만 CrewAI, AutoGen, 기본 LangChain 같은 도구는 전체 기록을 계속 끌고 다니는 경우가 많아, 짧은 컨텍스트를 유지하는 작업자 구조에 잘 맞는 오픈소스 에이전트 오케스트레이션 도구를 찾는 것이 과제로 남는다.
로컬에서 LLM을 돌릴 때 장비 투자 대비 효과를 계산하면 보통 답변을 만들어내는 속도인 디코딩에만 집중한다. 하지만 긴 자료를 읽고 정리하는 에이전트 작업에서는 입력을 먼저 처리하는 프리필도 비용과 성능에 큰 영향을 줄 수 있다. 예시로 GLM 5.2를 NVIDIA DGX Spark 4대에서 4비트 방식과 추측 디코딩 등으로 최적화했을 때, 6명이 동시에 쓰는 조건에서 출력 속도는 초당 약 60토큰이었다. 이 속도로 24시간 내내 에이전트 작업을 돌리면 하루 출력은 약 518만 토큰이고, 출력 토큰 100만 개당 4.40달러로 계산하면 약 22달러 수준이다. 같은 장비에서 프리필 처리량은 초당 약 3,000토큰으로 알려져 있으며, 입력 토큰 가격은 100만 개당 약 1.40달러로 더 낮다. 출력은 입력보다 100만 토큰당 보통 3~5배 비싸지만, 프리필은 디코딩보다 10~30배 빠르고 이 예시에서는 약 50배 빠르다. 그래서 로컬 LLM 장비의 경제성을 따질 때 출력 속도만 보면, 입력을 많이 읽는 작업에서 실제 이득을 놓칠 수 있다.
개인용 로컬 인공지능 서버가 16GB 그래픽카드 4장으로 구성되어 있다. 일반 서버 랙 대신 주방 선반 같은 구조에 장비를 쌓아 올렸고, 메인 슬롯 분할과 라이저 케이블을 이용해 여러 그래픽카드를 연결했다. 이 장비는 llama.cpp 두 개를 동시에 돌리며, Qwen 모델을 낮은 용량 형식으로 실행한다. 각 실행 환경은 약 15만 토큰 길이의 문맥을 다루도록 맞춰져 있고, 입력을 읽는 속도는 초당 약 1,000토큰, 답을 생성하는 속도는 초당 약 45~60토큰이다. 중앙처리장치는 i5이고 메모리는 32GB DDR4지만, 실제 모델 실행은 대부분 그래픽카드 메모리에서 처리된다. opencode로 llama.cpp 실행 관리와 토큰 계산을 하는 백엔드를 만들었고, 거친 계산으로는 이미 약 60달러를 아낀 것으로 추정된다. 아직 버그가 많고, 앞으로는 그래픽카드 일부에는 병렬 작업 2개를, 다른 일부에는 병렬 작업 1개를 배정해 요청을 알맞은 서버로 보내는 라우터를 만들려는 단계다.