소형 모델을 사용한 에이전트형 코딩 워크플로

좋습니다.

안녕하세요.

저는 호세입니다. 이안, 조이와 함께 진행하겠습니다.

LLM에 대해서는 모두 잘 알고 있습니다.

레시피 찾기, YouTube 동영상 요약, 코딩 등 모든 작업에 사용합니다.

Gemini 모델과 같이 정말 놀라운 기능을 갖춘 대규모 언어 모델도 있지만, 이 강연에서는 소규모 언어 모델에 대해 이야기해 보겠습니다.

40억 개의 무언가를 가진 것은 작을 수 없기 때문에 이들도 LLM이지만, 이제부터는 프런티어 모델과 소규모 언어 모델, 즉 로켓과 자전거로 구분하겠습니다.

소형 모델을 프런티어 모델의 대안이 아닌 보완책으로 논의할 것입니다.

소규모 언어 모델의 모든 이점, 특히 개방형이고 가중치가 공개되어 있으며 다운로드 가능한 경우의 이점을 살펴보겠습니다. 하지만 먼저 비용을 살펴보겠습니다.

이 강연을 위해 많은 벤치마크를 실행했는데, 그중 하나는 1억 3, 100만 개에 가까운 토큰을 사용하여 200개의 중간 및 어려운 작업으로 구성된 데이터 세트를 9달러 미만으로 처리한 것입니다.

이 작업에는 Gemma 4를 사용했기 때문에 무료로 다운로드하여 자체 하드웨어에서 실행할 수도 있었지만, 공정한 비교를 위해 상용 게이트웨이에서 실행했습니다.

그렇다면 프런티어 모델의 비용은 얼마나 될까요?

토큰 캐싱 및 기타 요인에 따라 약 20~200배 더 많습니다.

따라서 자전거는 가장 빠른 교통수단은 아닐 수 있지만 가장 효율적인 교통수단임은 분명합니다.

휴대전화를

그렇다면 품질과 정확성에는 어떤 차이가 있을까요?

이 특정 데이터 세트에서 Gemma 4는 작업의 53% 를 해결할 수 있습니다.

이는 두 가지를 의미합니다.

왼쪽의 작업을 실행하는 데 프런티어 모델을 사용한다면 과도한 것일 수 있습니다.

오른쪽의 작업을 실행하는 데 작은 모델을 사용하는 경우 모델을 솔루션으로 안내하거나 더 큰 모델을 사용해야 합니다.

이 강연에서는 모든 토큰을 최대한 활용하는 방법을 알려드립니다.

조이가 소형 모델을 선택하는 방법을 안내하고 이안이 Gemma 모델에 대해 설명하여 Gemma 모델로 무엇을 할 수 있는지에 대한 생각을 정리하는 방법을 이해할 수 있도록 도와줄 것입니다.

그런 다음 Android 스튜디오에서 Gemma 4를 사용해 보는 방법을 간단히 보여드리고, 마지막으로 소형 모델을 일상적인 워크플로에 적용하는 방법과 실제 Android 개발 벤치마크를 보여드려 소형 모델의 기능을 직관적으로 이해할 수 있도록 도와드리겠습니다.

이제 조이님에게 넘기겠습니다.

호세님, 감사합니다.

따라서 모든 작업에 하나의 모델을 사용하는 것은 마치 땅콩을 까는 데 망치를 사용하는 것과 같습니다.

효율적이기는 하지만 약간 불균형합니다.

따라서 소형 모델을 생각할 때는 도구 세트를 확장하는 것과 같습니다.

워크플로에 무엇을 도입해야 하는지 알기 위해서는 도구 세트를 열고 무엇을 사용할 수 있는지, 사양은 무엇인지, 어떤 용도에 적합한지 확인해야 합니다.

따라서 소형 모델을 선택하려면 소형 모델에 대해 알아야 합니다.

대부분의 사람들이 언어 모델을 생각할 때 떠올리는 모델 유형은 자동 회귀 언어 모델입니다.

토큰으로 청크된 입력을 기반으로 후보 목록에서 가장 가능성이 높은 다음 토큰을 선택하므로 자기회귀적입니다.

그런 다음 선택된 가장 가능성이 높은 다음 토큰이 입력으로 다시 들어가고, 이 과정이 반복됩니다. 이 과정은 일관되고 지능적으로 들리는 대답을 생성할 수 있지만, 선형적으로 작동하는 것을 포함하되 이에 국한되지 않는 몇 가지 주의 사항이 있습니다.

따라서 비선형적으로 작업할 수 있습니다.

확산 모델도 동일한 접근 방식을 사용하지만 한 번에 토큰 블록을 처리합니다.

마치 스케치에 초점이 맞춰지는 것 같습니다.

이 경우 DiffusionGemma는 한 번에 256개의 토큰 청크를 처리합니다.

따라서 기본적으로 전체 블록에서 작동하는 패스를 얻게 되므로 지연 시간이 짧은 결과를 생성할 수 있습니다.

그렇다면 Google의 도구 세트에는 글을 쓸 수 있는 모델이 있는 거죠?

아닙니다

기본적으로 임베딩 모델은 이미지, 텍스트 또는 기타 개념과 같은 객체를 벡터로 변환합니다.

이를 통해 두 가지를 개념적으로 비교할 수 있는 고차원 공간에 좌표를 매핑할 수 있습니다.

예를 들어 핫도그가 샌드위치라면 서로 가까운 공간으로 이어지거나 가까운 공간에서 끝날 가능성이 높습니다.

이로 인해 두 개념이 관련되어 있는지 확인하는 것은 모델 패스 대신 약간의 수학이라고 할 수 있습니다. 이 역시 약간의 수학이라고 할 수 있지만, 이 패러다임은 더 나아갑니다.

한 가지 작업을 매우 잘 수행할 수 있는 더 작고 전문화된 모델도 있습니다.

예를 들어 자연어를 API 호출로 변환하는 함수 모델, 이름만으로도 기능을 알 수 있는 비전 모델, 특정 매개변수를 기반으로 입력에 점수를 부여할 수 있는 분류기 등이 있습니다.

선택할 수 있는 옵션이 정말 많죠?

다양한 유형의 모델이 있으며, 모델마다 차원, 크기, 컨텍스트 윈도우, 기능, 메모리 사용량이 다릅니다. 도구 상자를 열고 모든 가능성을 고려하면 옵션이 기하급수적으로 늘어나 DIY 팬이라면 누구나 기뻐하거나 결정 장애로 인해 얼어붙을 수 있습니다.

그렇다면 소형 모델을 선택하려면 어떻게 해야 할까요?

먼저 로컬에서 실행할 수 있는 개방형 소형 모델인 Gemma 모델의 도구 상자를 열어 보겠습니다.

이안, 부탁할게요.

조이, 감사합니다.

호세가 처음에 언급했듯이 소규모 언어 모델은 기본적으로 약 50% 의 작업을 수행할 수 있습니다.

하지만 로컬 모델을 선택하는 이유는 무엇일까요?

결국 네 가지로 요약할 수 있습니다.

첫 번째는 개인 정보 보호입니다.

예를 들어 API 키, 독점 코드 또는 노트북에서 벗어날 수 없는 항목이 있을 수 있습니다.

두 번째는 지연 시간입니다.

따라서 모델이 실제로 메모리(그래픽 메모리 또는 통합 메모리)에 로드되면 계산이 완료되는 즉시 응답을 받게 됩니다.

따라서 서버와의 왕복 시간이 없고 추가 지연 시간 비용도 발생하지 않습니다.

다음은 한계 비용이 0이라는 점입니다.

따라서 모델은 실행 위치를 제어할 수 있을 때 비용 효율적입니다.

예를 들어 로컬 머신에서 무언가를 실행하는 경우 오류 루프에서 추가 재시도를 수행할 수 있습니다.

비용이 들지 않으며, 이 부분에 대해서는 예상치 못한 API 비용이 발생하지 않습니다.

마지막으로 네 번째는 오프라인 액세스입니다.

비행기, 기차, 버스, 지하철 등 하드웨어에서 모델을 실행할 수 있는 곳이라면 어디에서나 이 기능을 사용할 수 있다고 상상해 보세요.

좋은 방법이지만 이러한 결정을 내릴 때 고려해야 할 두 가지 주요 요소가 있습니다.

하나는 메모리이고, 두 번째는 속도입니다.

이 다이어그램을 보면 하단의 두 모델인 26B와 31B는 모두 16비트 양자화인 BF16에서 실행하는 데 50GB가 넘는 비디오 RAM이 필요합니다.

여기서 문제는 많은 하드웨어에 맞지 않는다는 것입니다.

따라서 정밀도를 4비트 부동 소수점으로 축소하는 양자화라는 프로세스를 수행합니다.

이제 좀 더 합리적입니다.

14GB와 17GB를 말하는 거죠?

이제 통합 메모리 Mac과 같은 기기에도 적합합니다.

학습 후 양자화의 문제는 가중치를 압축할 때 기본 모델에서 모델의 정확도가 약간 떨어진다는 점입니다. Google에는 이를 해결할 수 있는 기술이 있습니다.

이를 양자화 인식 학습이라고 합니다.

이렇게 하면 모델이 학습될 때 더 작은 크기로 학습된다는 것을 알게 되므로 실제로 손실이 더 적습니다.

따라서 RAM 요구사항이 75% 줄어들어 이제 이러한 기기에 맞출 수 있습니다.

여기서 한 단계 더 나아갑니다.

따라서 많은 휴대전화에서 작동하는 모바일 양자화 접근 방식을 사용하면 모든 레이어가 작동하는 방식과 작동할 수 있는 크기를 이해하여 모델을 더 축소할 수 있습니다.

따라서 다양한 양자화 기법이 존재합니다.

따라서 11.4GB Gemma E2B에서 1.1GB로 줄어듭니다.

이제 중급형에서 고급형 휴대전화에서는 훨씬 더 합리적입니다.

다음은 속도입니다.

조이가 언급했듯이 자기 회귀 모델을 사용하면 다음 토큰 집합을 예측합니다.

코딩 작업에서는 이러한 토큰 중 상당수가 실제로 예측 가능합니다. 예를 들어 메서드 서명의 끝이거나 여는 중괄호 또는 닫는 중괄호일 수 있습니다.

이때 추측 디코딩이라는 기법을 사용할 수 있습니다.

이렇게 하면 더 작은 초안 작성 모델을 사용하여 여러 토큰을 예측한 다음 더 큰 모델로 검증합니다.

Gemma 4 아키텍처에서 이 기능이 작동하는 이유는 동일한 KV 캐시를 공유하기 때문입니다.

따라서 이를 모델의 단기 기억과 같은 것으로 생각하면 됩니다.

그러면 작은 초안 모델이 미리 3~4개의 토큰을 예측하고, 더 큰 모델이 동일한 KV 캐시를 살펴보고 기본적으로 출력을 검증합니다.

이로 인해 모델 출력의 품질이 실제로 저하되지 않으면서 성능이 약 3배 빨라질 수 있습니다. 예측한 다음 통과 또는 실패 여부, 즉 올바른지 여부를 결정하기 때문입니다.

따라서 수행하는 작업에 따라 조금씩 다릅니다.

따라서 창의적인 글쓰기와 같은 작업에는 변동성이 크기 때문에 잘 작동하지 않지만, JSON 구조 및 코딩과 같이 예측 가능한 작업에는 매우 잘 작동합니다.

그렇다면 이러한 모델 중 하나를 실제로 어떻게 평가할 수 있을까요?

가장 먼저 할 수 있는 일은 LiveCodeBench나 MMLU와 같은 벤치마크를 살펴보고 점수를 확인하는 것입니다.

하지만 이는 모델의 기능에 대한 대략적인 지표만 제공합니다.

실제로 해야 할 일은 실행 중인 전체 스택을 평가하는 것입니다.

사용 중인 모델, 가중치, 양자화 접근 방식, 런타임의 추론(llama.cpp, Ollama, LiteRT 등), 사용 중인 에이전트 하네스(Pi, OpenCode, Antigravity 등), 모델이 처리할 수 있는 모든 데이터의 공간인 컨텍스트 윈도우가 있습니다.

이 모든 요소가 결합되어 실현 가능성이 결정됩니다.

간단한 예를 들자면, Android Bench에서 Gemma 4를 테스트하고 있었는데, 기본 32k 컨텍스트를 사용하는 Ollama 버전을 실행하고 있었습니다.

버그를 찾는 테스트 중 하나에서 에이전트 하네스의 압축으로 인해 해당 파일이 메모리에서 이동되어 모델이 작업을 완료하지 못하고 실패하는 것을 발견했습니다.

컨텍스트를 32k에서 256k로 늘리는 것만으로도 메모리에 유지할 수 있게 되었고, 모델은 해당 테스트를 통과할 수 있었습니다.

그 결과 해당 작업의 성공률이 두 배로 증가했습니다.

이러한 작은 요소 중 하나라도 이 모델이 적합한지 여부에 큰 영향을 미칠 수 있다는 것을 보여줍니다.

그렇다면 실제로 자체 평가를 수행하려면 어떻게 해야 할까요?

세 가지 간단한 제안을 드리겠습니다.

하나는 Git 기록을 가져와서 이미 성공한 PR을 모델에 프롬프트 입력으로 사용하고 모델이 얼마나 잘 작동하는지 확인하는 것입니다.

다음으로, 모델의 출력이 올바른지 평가하는 데 도움이 되는 결정론적 채점기와 같은 것이 필요합니다.

이에 대한 두 가지 좋은 예가 있습니다.

컴파일러와 단위 테스트가 있습니다.

생성된 항목을 실행하면 특정 작업의 성공 여부를 알려줍니다.

세 번째는 로그 궤적입니다.

따라서 에이전트를 실행할 때 에이전트의 다양한 동작을 추적하고, 성공한 부분과 실패한 부분을 확인하고, 이를 사용하여 모델이 얼마나 잘 상호작용하고 도구를 사용할 수 있는지 평가할 수 있습니다.

그리고 질문의 프레임을 '이 모델이 이 대형 프런티어 모델만큼 똑똑한가?'에서

"이 하드웨어에서 이 특정 구성으로 이 작업을 수행할 수 있는가?"로 바뀝니다.

이를 파악하기 위해 '목표에 도달했나요?'라는 프레임워크를 만들었습니다.

또는 AWTY입니다.

이 프레임워크의 전체 원칙은 준비도 측면에서 이 축에 있는 다양한 작업에 점수를 매기는 것입니다.

모델 자체, 사용 중인 추론 엔진, 하네스, 하드웨어 구성이 있습니다.

그러면 준비가 되었는지 알 수 있습니다.

예를 들어 특정 작업의 안정성을 살펴볼 수 있습니다.

10번 연속으로 실행하면 매번 같은 작업을 수행하나요?

지연 시간을 보고 있을 수 있습니다.

실시간 응답이 필요할 수도 있습니다.

작업 속도에 대한 기준은 무엇인가요?

그런 다음 RAM 요구사항을 살펴볼 수 있습니다.

따라서 기기가 보유한 RAM뿐만 아니라 기기가 보유한 RAM, 즉 사용할 수 있는 분할과 해당 하드웨어에서 실행해야 하는 다른 애플리케이션 및 기타 도구도 고려해야 합니다.

RAM의 50% 를 차지할 수 있나요, 아니면 10% 만 차지할 수 있나요?

최종 컨디션 점수를 받게 됩니다.

녹색이면 구성이 준비된 것입니다.

주황색, 노란색 또는 빨간색이면 구성에서 무언가를 변경해야 할 수 있습니다.

지연 시간을 줄이기 위해 더 빠른 가속기가 필요할 수도 있고, 더 강력한 대규모 모델이 필요할 수도 있습니다.

이 점을 살펴보시기 바랍니다.

현재 프리뷰 버전이 제공되고 있으며 이 도구가 얼마나 유용한지에 관한 의견을 보내주시기 바랍니다.

조이가 나중에 평가를 설정하는 방법에 대해 좀 더 자세히 설명할 예정이지만, 지금은 호세에게 넘겨 Gemma 4를 시작하는 매우 빠른 방법을 보여드리겠습니다.

이안, 감사합니다.

네, 현재 Gemma 4를 가장 빠르게 사용해 보는 방법은 Android 스튜디오를 이용하는 것입니다.

그 방법을 보여드리겠습니다.

노트북으로 전환해 주세요.

좋습니다

설정의 모델 제공업체 페이지로 이동하여 Gemma를 선택하면 각 모델의 크기를 명확하게 파악할 수 있습니다.

모델을 하드 드라이브에 다운로드하기만 하면 됩니다.

그러면 llama.cpp 서버가 열리거나 시작되며, 처음부터 올바르게 구성됩니다.

하지만 원하는 경우 자체 llama.cpp 서버, Ollama, LM Studio를 자유롭게 사용해도 됩니다.

그러려면 여기로 와서 로컬 제공업체를 추가하면 됩니다.

또한 원격 제공업체를 통해 소형 모델을 사용하는 것도 매우 합리적입니다.

따라서 OpenAI 또는 Anthropic과 호환되는 경우 여기에 추가하여 연결할 수 있습니다.

좋습니다. 살펴보겠습니다.

Android 스튜디오에서 모델을 선택하는 방법은 이 드롭다운을 사용하는 것입니다.

Gemma 4 26B를 선택하고 'ViewModel이 뭐야?'라고 물어볼 수 있습니다.

좋습니다.

따라서 모델을 변경할 때마다 전체 대화가 처음부터 새 모델로 다시 전송된다는 점을 기억해야 합니다.

따라서 모델과 매우 긴 대화를 생성하고 새 대화로 전환하려면 새 대화를 시작하거나 압축하는 등의 작업을 해야 합니다.

이제 다시 슬라이드로 돌아가 조이와 함께 작은 모델로 실행할 수 있는 다양한 워크플로에 대해 알아보겠습니다.

호세님, 감사합니다. 이안님, Gemma 모델에 대한 개요와 아직 준비가 되었는지 여부에 대해 설명해 주셔서 감사합니다.

지금까지 어떤 유형의 모델이 있고 사양은 어떤지 살펴봤습니다. 이제 모델이 수행할 수 있는 작업 유형을 이해해야 합니다.

이미 하고 계실 첫 번째 유형의 작업은 디버깅이나 문제 해결과 같은 코딩 워크플로입니다. 또는 테스트 적용 범위를 늘리는 작업도 있습니다. 이 작업은 모두가, 적어도 저는 직접 하는 것을 매우 그리워할 것입니다.

그렇죠?

이러한 것들은 이미 모두가, 아마도 인지하지 못한 채로, 하고 있는 일들입니다.

하지만 그 이상의 것을 생각하도록 권장하고 싶습니다.

소형 모델은 가중치 공개 모델일 수 있고 로컬에서 실행할 수 있다는 점을 고려할 때, 시간을 절약해 줄 수 있는 것은 무엇일까요?

그렇죠?

로켓을 사용하지 않는 것에 대해 이야기하고 있는데, 왜 뇌를 사용하는 거죠?

그렇다면 그 이상으로 소형 모델이 할 수 있는 일에는 무엇이 있을까요?

어떤 워크플로에 AI를 도입하면 업무가 더 수월해지고, 더 하고 싶은 일에 더 많은 역량을 투입할 수 있을까요?

예를 들어 변경사항에 따라 문서가 항상 최신 상태로 유지되도록 하거나, 사전 커밋 후크의 일부인 자동 회귀 테스트를 수행하거나, 워크플로의 일부로 에이전트가 수신하는 컨텍스트가 최적화되어 더 빠르게 작동하도록 할 수 있습니다.

이러한 예시가 있습니다.

결국 어느 정도는 한계가 없거나 아키텍처가 한계이며, 구현 방법을 생각할 수 있는 방법은 많습니다.

사양, 도구, 워크플로가 있지만 여전히 어디서부터 시작해야 할지 모르겠다면

바로 이럴 때 벤치마크가 필요합니다.

이안이 말했듯이 일반적인 리더보드, 특히 Python용 리더보드는 소형 모델이 Android 워크플로에 도움이 될지 여부를 거의 알려주지 않습니다.

석고보드 드릴이 콘크리트 드릴에 대해 많은 것을 알려주지 않는 것과 마찬가지입니다.

하지만 자체 평가에 투자해야 합니다.

자체 아키텍처를 테스트하는 데 투자해야 하지만, 그 전에 모든 리소스를 투입하고 싶지 않을 수도 있습니다.

시간, 비용, 노력이 필요하므로 공개적으로 제공되는 벤치마크를 살펴보면 자체 평가에 투자하기 전에 아이디어를 얻고 후보 목록을 만들 수 있습니다.

벤치마크를 평가할 때마다 살펴봐야 할 세 가지가 있습니다.

조금 메타적인 질문이지만, 기본적으로 첫 번째는 이 모델이 수행하는 작업의 유형이 무엇인가요?

구체적인 정도

이러한 작업이 여러분이 모델에 부여할 작업 유형과 유사한가요?

두 번째는 작업의 범위입니다.

문서 작성, PR 해결, 아니면 여러분이 하는 일과 비슷한 작업인가요?

마지막으로, 시스템의 복잡성이 제공하려는 복잡성과 유사한가요?

여기에서 Python 벤치마크가 Android를 대표하지 않는 이유를 알 수 있습니다.

이러한 이유로 Google은 Android 생태계와 Android 작업을 포착하는 벤치마크인 Android Bench를 개발했습니다.

첫 번째 버전에는 100개의 PR 크기 Android 작업이 포함되어 있으며, 오늘 Harbor를 통해 직접 실행하여 에이전트, 모델, 기술 조합을 확인할 수 있습니다.

Google은 더 복잡하고 장기적인 작업을 수행하는 2.0을 출시하여 오늘날 사용자가 부여하는 작업에서 프런티어 모델의 역량을 파악하고자 합니다.

이제 호세에게 마이크를 넘겨 이 작업을 통해 얻은 결과와 소규모 모델을 최적화하는 몇 가지 방법을 보여드리겠습니다.

네, 감사합니다, 조이.

좋습니다. 이제 작은 모델이 해결할 수 있는 작업과 어려움을 겪기 시작하는 지점을 살펴보겠습니다.

그리고 임의로 소형, 중형, 대형, 장기라는 네 가지 작업 카테고리를 정의해 보겠습니다.

장기 작업은 사람이 완료하는 데 며칠 또는 몇 주가 걸릴 수 있는 작업입니다.

예를 들어 마이그레이션, 대규모 리팩터링 등이 있습니다. 그리고 스포일러를 하자면, 작은 모델로는 이러한 작업을 수행할 수 없습니다.

적어도 한 번에 말이죠.

이에 대해서는 나중에 설명해 드리겠습니다.

좋습니다. 작은 작업입니다.

이러한 작업은 한두 개의 파일을 읽고 쓰는 작업이며 많은 지식이 필요하지 않습니다.

예를 들어 작은 모델은 Compose, 적어도 Compose의 기본 사항에 매우 능숙합니다.

예를 들어 요소 사이에 8dp가 있어야 한다거나 하드코딩된 색상 대신 테마를 사용해야 한다거나 문자열을 추출해야 한다는 등의 규칙이 있습니다.

이러한 작업은 작은 모델로도 쉽게 처리할 수 있습니다.

하지만 이 작업은 더 고급 주제를 다루지만 여전히 간단합니다.

@Composable
 fun AnimatedDrawer() {
   val offsetX = remember { Animatable(0f) }
-  Box(modifier = Modifier.offset(x = offsetX.value.dp)) {}
+  Box(modifier = Modifier.graphicsLayer { translationX = offsetX.value }) {}
 }

이 경우의 어려움은 지식이 아니라 범위에 관한 것입니다.

따라서 프롬프트는 최적화할 컴포저블과 문제(프레임마다 재구성됨)를 알려줍니다.

따라서 Gemma 4와 같은 소형 모델에서도 이 작업을 매우 쉽게 수행할 수 있습니다.

이 경우 3분이 걸렸으며 한 줄만 변경하면 됩니다.

좋습니다.

이제 소형 모델이 무엇인지 잘 알게 되었습니다.

죄송합니다. 작은 작업이 무엇인지 살펴보겠습니다.

중간 난이도 작업을 살펴보겠습니다.

소형 모델은 대부분의 작업을 수행할 수 있어야 합니다.

이 작업에서는 Pocket Casts 앱에서 요청에 사용자 에이전트가 누락되었으며 재시도 로직에 오류가 있습니다.

이 작업은 조금 더 어렵습니다. 먼저 이 작업에서는 두 가지를 동시에 요청하고 있으며, 코드베이스에서 이러한 항목이 어디에 있는지에 대한 힌트가 없기 때문입니다.

하지만 통과했습니다.

10분 정도 걸렸습니다.

파일 3개가 수정되었습니다.

참고로 OpenRouter를 통해 6센트가 들었습니다.

이제 동일한 데이터 세트에서 실패한 작업을 살펴보겠습니다.

이것은 Now in Android의 예시로, 꽤 포괄적인 보고서 또는 프롬프트가 있지만 클래스 이름이나 파일이 언급되지 않았습니다. 따라서 에이전트는 앱의 아키텍처, 데이터 레이어, 동기화 메커니즘 등을 이해하는 데 더 많은 노력을 기울여야 합니다. 이 특정 실행에서는 실패했습니다.

모든 것이 거의 올바르게 구현되었지만 초기 동기화 값이 -1이라고 가정했습니다. 하지만 실제로는 0입니다.

val isInitialSync = currentVersion == -1

val isInitialSync = currentVersion == 0

이상입니다.

에이전트가 기존 단위 테스트를 실행했다면 이 버그를 발견했을 것입니다.

따라서 이 그래프는 일반적으로 소형 모델이 최첨단 모델보다 조금 더 일찍 중단되는 경향이 있음을 보여줍니다.

상담사에게 문제를 확인하는 것이 아니라 해결해 달라고 요청했습니다.

따라서 확인 단계가 포함되도록 작업을 수정해야 할 수도 있습니다.

이에 대해서도 잠시 후에 설명하겠습니다.

이제 대규모 작업에 대해 이야기해 보겠습니다.

이 정의에서 대규모 작업의 약 절반은 매번 통과합니다.

실패한 일부는 실제로 소형 모델에는 너무 길고 복잡해서 할 수 있는 일이 많지 않습니다.

하지만 실제로 일어난 일을 살펴보면 모델이 90% 정도는 맞았다는 것을 알 수 있습니다.

그중 하나를 선택해 보겠습니다.

불안정한 테스트이기 때문에 이 테스트를 선택했습니다.

실행 시간의 절반 정도를 통과합니다.

따라서 이 모델은 소형 모델이 할 수 있는 일의 최전선에 있다고 생각합니다.

또는 적어도 4월에 출시된 모델입니다.

Coil 라이브러리에서 잘못된 형식의 URL을 파싱하는 것과 관련이 있습니다.

보시다시피 PR 설명은 매우 포괄적이지만 요구사항이 누락되었습니다.

간단히 살펴보겠습니다.

모든 실행에서 일반적인 URL 인코딩과 오류를 확인했지만, 절반만 잘못 인코딩된 문자에 대한 테스트를 추가했으므로 해당 테스트 사례가 있습니다.

그렇지 않은 모델은 평가에 실패했습니다.

모든 실행이 거의 완벽하지만, 작은 모델이 항상 추가 단계를 수행하지는 않는다는 것을 다시 한번 보여줍니다.

요청 사항을 따르지만 프런티어 모델처럼 사용자를 놀라게 하려고 하지는 않습니다.

요즘 에이전트에서 노력을 설정할 수 있는 방법을 알고 계신가요?

작은 모델을 사용할 때는 너무 낮게 설정되어 있다고 생각하면 됩니다.

따라서 큰 작업을 소형 모델이 약 50% 의 확률로 완료할 수 있는 작업으로 정의해 보겠습니다. 이는 조이가 이전에 언급한 Android Bench v1 데이터 세트에서 Gemma 4 31B가 달성할 수 있는 수준입니다.

장기 작업에 대해 이야기하기 전에, 소형 모델이 이러한 작업을 수행하는 데 도움이 되는 방법이 있을까요?

물론입니다. 이러한 작업은 전혀 노력이 필요하지 않습니다.

먼저, 이안이 언급한 것처럼 Gemma 4와 같은 모델을 로컬에서 사용하는 경우 올바르게 구성되어 있는지 확인하세요.

예를 들어 Ollama를 사용하여 Gemma 4를 서빙하는 경우 실제로는 8배 더 많은 토큰을 지원하지만 기본적으로 32,000개의 토큰 컨텍스트 윈도우로 설정됩니다.

물론 Android 스튜디오를 통해 Gemma 4를 사용하는 경우에는 구성할 필요가 없습니다.

기본적으로 올바르게 구성되어 있습니다.

평가 세트에서 전체 컨텍스트를 사용 설정하면 결과가 26%에서 53%로 증가했습니다.

다음으로 Android CLI 도구인 Android CLI를 사용하여 문서를 검색합니다.

모델은 기본에 충실하므로 이 방법이 항상 적용되는 것은 아니지만, 새 API나 틈새 API를 사용할 때는 문서가 핵심입니다.

경험상 웹 검색 도구를 사용하는 것보다 훨씬 낫습니다.

다음으로 인증 힌트를 추가합니다.

이 문제에 관해 이야기했습니다.

모델에 테스트 실행 방법, 사용 가능한 테스트 유형, 에뮬레이터 관리 방법 등을 알려줍니다. AGENTS.md 파일에서 이 작업을 수행할 수 있으며, 이렇게 하면 모든 에이전트가 안내를 사용할 수 있습니다. 어쨌든 좋은 일입니다.

네가 가져야 해.

하지만 너무 긴 AGENTS.md 파일도 주의해야 합니다. 다양한 에이전트를 사용해 보면 일부 에이전트에는 대규모 시스템 프롬프트와 도구 설명이 포함되어 있어 소형 모델의 성능을 저하시키는 것으로 보이기 때문입니다.

실제로 OpenCode로 이러한 벤치마크를 실행해 보았는데, 아마도 더 큰 도구 설명과 시스템 프롬프트를 사용하기 때문에 Pi보다 훨씬 낮은 성능을 보였습니다.

다음으로 스킬을 추가하고 삭제합니다.

소형 모델은 새롭고 틈새 API를 사용할 때 약간의 도움이 필요할 수 있지만, 예를 들어 일반적인 Compose 기술로 컨텍스트를 채우지 않는 것이 좋습니다.

그렇다면 장기 작업은 어떨까요?

수십 개의 파일에 걸쳐 있고, 심각한 아키텍처 결정을 요구하며, 일반적으로 계획을 세우고 다양한 작업을 실행하는 하위 에이전트 무리를 시작하는 사고 모델에 의해 처리되는 작업입니다.

장기 작업의 예로는 전체 앱을 XML에서 Compose로 이전하거나, 복잡한 앱을 처음부터 만들거나, 크로스 플랫폼 앱을 네이티브 Android로 변환하는 것이 있습니다.

장기 작업에만 초점을 맞춘 Android Bench V2의 결과를 보면 프런티어 모델의 점수가 3~40%에 불과합니다.

따라서 소형 모델의 경우 이 작업은 역부족이라고 할 수 있습니다.

하지만 초기 분석을 프런티어 모델을 통해 라우팅한 다음 더 간단한 작업을 더 작은 모델로 연쇄적으로 전달하면 토큰과 크레딧을 훨씬 더 효율적으로 사용할 수 있습니다.

방법을 알아보겠습니다.

조이로 돌아가겠습니다.

호세님, 감사합니다.

캐스케이드에 대해 알아볼 예정이지만, 몇 가지 방법을 보여드리기 전에, 또는 이 내용을 자세히 살펴보기 전에 한 걸음 물러서서 다양한 모델의 조정을 통해 도움을 받을 수 있는 다른 방법을 보여드리겠습니다.

따라서 조정을 사용하면 차단되지 않을 수 있습니다.

따라서 제공업체가 다운되거나, API 비율 제한에 도달하거나, 이안이 말한 것처럼 비행기나 기차에 타고 있는 경우에도 대체 모델을 설정하여 온라인이든 로컬이든 어떤 상황에서도 계속 작업할 수 있습니다.

오케스트레이션을 통해 할 수 있는 또 다른 일은 더 나은 대답을 얻는 것입니다.

예를 들어 소형 모델이 자체적으로 작동하다가 약간의 지원이 필요할 때마다 어드바이저를 호출하여 도움을 받을 수 있습니다.

또한 다양한 유형의 모델 또는 여러 모델이 모두 한 번에 동일한 작업을 실행하는 위원회를 설정한 다음 다양한 대답과 각 모델의 가중치 및 편향이 결과에 미친 영향을 평가할 수 있습니다.

별도의 모델을 테스트로 사용할 수도 있습니다.

동료 검토와 같은 것이죠.

이것을 통해 확인할 수 있습니다.

물론 마지막으로, 조정을 사용하면 이러한 캐스케이드와 같은 기능을 통해 비용 효율성을 높일 수 있습니다.

기본적으로 수동으로 설정할 수 있으므로 계획용 모델, 실행용 모델, 테스트용 모델을 각각 다르게 설정할 수 있습니다.

클라우드에서 수행하거나 LiteLLM 프록시를 설정하여 로컬에서 수행하는 등 여러 가지 방법이 있습니다.

또는 분류기를 사용하여 요청에 따라 적절한 유형의 모델로 자동으로 라우팅할 수도 있습니다. 이는 이안이 언급한 프록시 아이디어이지만 자동입니다.

그럼 호세가 발표 초반에 던졌던 질문으로 돌아가 마무리하겠습니다. 소형 모델과 프런티어 모델의 품질과 정확성에는 어떤 차이가 있을까요?

컴퓨터 공학의 많은 것들이 그렇듯, 답은 상황에 따라 다릅니다.

하지만 이 부분은 여러분이 설계할 수 있는 부분이라는 점을 다시 한번 말씀드리고 싶습니다.

이는 설정 방식과 구성요소를 활용하는 방식에 따라 달라질 수 있습니다.

첫 번째는 적절한 도구를 선택하는 것입니다.

도구에는 여러 유형이 있습니다.

알아가고 탐색하는 거죠.

그런 다음 어떤 직업에 적합한지, 어떤 직업을 가질 수 있는지 알아봅니다.

두 번째는 모델이 작업을 수행하기 위해 가져오는 범위를 조정하는 것입니다.

예를 들어 작업에 대한 지침, 작업에 적합한 컨텍스트만 제공하는 것, 자체 작업을 확인하는 방법 등이 있습니다.

그런 다음 모델만 따로 테스트하는 것이 아니라 전체 설정을 테스트해야 합니다. 이렇게 하면 결과가 달라질 수 있으며, 다른 요소 구성으로 설정하면 얻는 결과가 조정될 수 있기 때문입니다.

결국에는 자체 평가를 설정하거나 만들어야 합니다.

마지막으로 자전거와 로켓을 조율하여 둘 중 하나를 선택할 필요 없이 효과적으로 지출할 수 있습니다.

하지만 가장 중요한 것은 계속해서 탐색하고, 계속해서 구축하고, 계속해서 즐길 수 있다는 것입니다.

Android Bench를 통해 모델 후보 목록을 설정하고 결과를 확인하거나, Android 스튜디오에서 Gemma 4를 시작하여 오늘 바로 시작할 수 있습니다.

감사합니다.