Ollama v0.40.12, 프롬프트 속도와 소형 이미지 세부 정보 개선 겨냥

Ollama가 로컬 모델 성능, 이미지 처리, 기반 소프트웨어 의존성을 겨냥한 네 가지 변경 사항을 담은 Ollama v0.40.12 릴리스 후보를 공개했다. 이 구분은 중요하다. 프롬프트 처리 개선과 생성 개선은 서로 다른 변경에서 비롯되며, 각기 다른 한계를 갖기 때문이다.

핵심은 모델을 지원하는 것과 모델을 제대로 실행하는 것 사이의 간극이다. 모델이 성공적으로 로드되더라도 문서를 비효율적으로 처리하거나 유용한 이미지 세부 정보를 잃을 수 있다. 이번 릴리스는 새로운 모델 제품군을 발표하기보다 이러한 간극의 구체적 사례를 다룬다.

비교 범위는 Ollama 자체를 넘어선다. Apple의 머신러닝 배열 프레임워크인 MLX는 기반 연산을 중심으로 개발하는 연구자에게 더 직접적인 개발 경로를 제공한다. Ollama의 역할은 이러한 기능을 모델 런타임, 즉 모델을 실행하는 소프트웨어에 통합하는 것이다. 애플리케이션 개발자에게는 이 통합이 어떤 업스트림 개선 사항이 실제 워크로드까지 도달하는지를 결정한다.

Ollama v0.40.12가 실제로 바꾸는 점

이번 업데이트는 특정 목적의 런타임 업데이트이며, 공개된 아티팩트는 여전히 릴리스 후보 상태다.

릴리스 후보는 표시 제목이 v0.40.12로 되어 있지만 태그는 v0.40.12-rc0다. GitHub는 이를 사전 릴리스로 표시하며 날짜는 2026년 10월 27일이다. 비교 기준은 v0.40.11이다.

표시 제목만으로 안정 버전이 출시됐다고 판단할 수는 없으므로 이러한 명명 차이에 주의할 필요가 있다. 업그레이드를 검토하는 독자는 공개된 후보 버전과 이후의 안정 아티팩트를 구분해야 한다. 이 빌드에 관한 결과에는 전체 태그를 유지해야 한다.

나열된 변경 사항은 소형 Gemma 4 이미지 처리, MLX 의존성 업데이트, DFlash2 지원, llama.cpp 의존성 업데이트를 포괄한다. 네 항목 모두 기여자 dhiltgen의 공으로 표기돼 있다. 이를 종합하면 하나의 범용 가속 기능이 아니라 여러 실행 경로 전반의 유지보수를 설명한다.

이 범위는 릴리스가 서로 다른 그룹에 각기 다른 이유로 관련된다는 뜻이다. 영향을 받는 이미지 모델을 사용하는 개발자에게는 정확성 문제가 있다. 프롬프트 처리를 기다려 온 개발자에게는 응답성 문제가 있다. 지원되는 생성 가속을 시험하는 개발자에게는 또 다른 성능 문제가 있다.

발표를 해석할 때 이 질문들은 분리해 두어야 한다. 문서 처리가 빨라졌다고 해서 답변 생성까지 자동으로 빨라지는 것은 아니다. 이미지 세부 정보를 보존한다고 해서 모든 시각 작업에서 정확도가 높아졌다는 뜻도 아니다. 의존성을 업데이트했다고 해서 지원되는 모든 기기에서의 이점이 명시되는 것도 아니다.

따라서 유용한 관점은 워크로드별 관점이다. 어떤 연산이 바뀌었고, 어떤 모델이 이를 사용하며, 애플리케이션의 어느 부분이 그 연산에 의존하는가? 모든 변경 로그 항목을 전반적으로 더 빨라진 로컬 AI의 증거로 취급하는 것보다 이 질문들이 더 실행 가능한 해석을 낳는다.

문서 어시스턴트에서는 답변이 나타나기 전 단계의 개선이 가장 중요할 수 있다. 스크린샷 어시스턴트에서는 입력에서 보존된 정보가 핵심일 수 있다. 더 긴 응답을 생성하는 애플리케이션에서는 생성 경로를 더 면밀히 살펴볼 필요가 있을 수 있다.

이는 보고된 고객 배포 사례가 아니라 분석적 예시다. 동일한 인터페이스를 사용하는 애플리케이션이라도 같은 릴리스가 서로 다르게 중요할 수 있는 이유를 보여 준다. 눈에 보이는 제품은 익숙한 상태로 남아 있어도 그 아래에서 수행되는 작업은 바뀔 수 있다.

업데이트는 애플리케이션 유지보수 담당자에게 기존 가정을 재검토하도록 요구하기도 한다. 이전 비교는 지속적인 모델 한계가 아니라 과거 실행 경로를 반영했을 수 있다. 반대로 새로운 벤치마크가 다른 비교 없이 프로덕션 워크로드의 증거를 지워서는 안 된다.

이것이 이번과 같은 유지보수 릴리스의 실질적 의미다. 모델 품질과 배포 적합성에 대한 더 광범위한 주장은 미해결로 남겨 둔 채, 기존 동작을 재평가할 구체적인 이유를 만든다.

작은 이미지는 로딩과 인식 사이의 간극을 드러낸다

이미지 변경은 모델이 답변을 생성하기 전에 발생하는 정보 손실을 다룬다.

소형 비전 수정은 이미지를 모델 입력으로 변환하는 구성 요소인 Gemma 4의 소형 비전 타워와 관련이 있다. 풀 리퀘스트에 따르면 동적 크기 조정은 가장 작은 이미지 그리드를 의도한 70토큰 예산보다 낮게 반올림할 수 있었다.

여기서 토큰은 모델 처리를 위해 이미지 정보를 표현하는 단위다. 이 변경은 소형 타워의 그리드를 위쪽으로 반올림하되, 다음으로 지원되는 예산을 상한으로 둔다. 유지보수 담당자는 명시적 예산과 더 큰 통합형 타워의 기존 크기 조정은 변하지 않는다고 밝혔다.

이는 유용한 함의를 지닌 제한적인 수정이다. 입력이 준비 과정에서 세부 정보를 잃으면 이후의 추론이 빠진 정보를 안정적으로 복구할 수 없다. 성능이 뛰어난 모델이라도 런타임이 전달하는 정보에 의존한다.

상태 레이블이 포함된 작은 스크린샷에 관해 질문하는 애플리케이션을 생각해 보자. 준비 과정에서 관련 세부 정보가 제거된다면 질문의 표현을 바꿔도 근본 문제는 해결되지 않을 수 있다. 애플리케이션은 해석이 이뤄질 때까지 시각적 근거가 유지되도록 해야 한다.

이 시나리오는 이미지 처리가 성능 논의에 포함되는 이유를 설명한다. 사용자는 시스템이 입력을 정확하게 읽는지까지 포함해 완료된 작업을 평가한다. 빠르게 도착하지만 관련 레이블을 놓치는 응답은 추가 작업을 만든다.

다만 이 수정이 소형 모델이 이제 모든 작은 이미지를 정확하게 처리한다는 주장으로 확대돼서는 안 된다. 출처는 크기 조정 동작과 제한된 수정을 식별한다. 스크린샷, 스캔 문서, 다이어그램, 사진 전반에 대한 일반적 결과를 입증하지는 않는다.

이미지 크기만으로도 난이도를 완전하게 설명할 수는 없다. 눈에 띄는 기호가 있는 작은 그림은 빽빽한 텍스트가 있는 그림과 다른 과제를 제시한다. 평가는 실제 애플리케이션이 추출할 것으로 기대하는 정보를 반영해야 한다.

가장 명확한 비교는 빌드 전반에서 원본 이미지와 질문을 보존하는 방식이다. 평가 중 이미지를 다르게 리사이즈하면 변경된 답변에 대한 또 다른 설명이 추가된다. 목표는 검토 중인 런타임 동작을 분리하는 것이다.

유지보수 담당자에게 이는 실패를 조사하는 방식도 바꾼다. 잘못된 시각 답변이 반드시 모델의 학습된 능력에서 비롯되는 것은 아니다. 입력 준비는 또 하나의 그럴듯한 계층이며, 이 패치는 구체적인 사례를 제공한다.

이는 이전의 부정적 결과를 해석하는 방식도 바꾼다. 영향을 받은 구성에서 유용한 정보가 버려졌다면 이전 테스트는 수정 후 해당 구성이 제공할 수 있는 성능을 과소평가했을 수 있다. 이러한 가능성은 과거 결과를 무효라고 다시 쓰는 것이 아니라 재테스트할 근거가 된다.

더 넓은 교훈은 모델 비교의 경계에 관한 것이다. 모델 이름만으로는 평가 중인 전체 시스템을 설명할 수 없다. 이미지 준비, 실행 소프트웨어, 애플리케이션 동작은 모두 사용자에게 전달되는 답변을 결정하는 데 기여한다.

Ollama MLX 성능은 답변 생성 전에 개선된다

프롬프트 속도 변경은 요청을 읽는 과정을 가속하지만, 유지보수 담당자는 디코딩 속도가 변하지 않았다고 명시적으로 보고한다.

프롬프트 처리 업데이트는 MLX와 그 C 언어 인터페이스인 MLX-C를 업데이트한다. 이는 모델 입력의 이동 창으로 관련 어텐션 연산을 제한하는 네이티브 슬라이딩 윈도우 어텐션을 사용한다.

유지보수 담당자는 Apple M5 Max에서 프리필 개선을 보고했다. 프리필은 새 출력을 생성하기 전에 입력을 처리하는 단계다. 2,048토큰 프롬프트에서 보고된 처리량은 Gemma가 9.2%, Flint가 14.5%, Laguna가 24.1% 증가했다.

6,144토큰 프롬프트에서 해당 보고 수치는 각각 7.5%, 14.3%, 27.0%다. 이는 지정된 모델 구성에 대한 유지보수 담당자의 측정값이다. 풀 리퀘스트는 출력 생성 속도인 디코딩 속도는 변하지 않는다고 명시한다.

이 단서는 Ollama MLX 성능 주장 범위를 규정한다. 긴 문서를 읽어 주기를 기다리는 사용자는 긴 답변을 기다리는 사용자와 다른 병목을 겪는다. 전자를 개선했다고 해서 후자가 개선됐다는 근거는 되지 않는다.

이는 특히 상당한 보조 자료를 포함하면서 짧은 응답을 요청하는 경우에 관련이 있다. 이러한 가상 워크로드에서 입력 처리는 경험의 의미 있는 부분일 수 있다. 이후 출력이 같은 속도로 도착하더라도 준비가 빨라지면 중요할 수 있다.

반대 상황에서는 다른 해석이 필요하다. 짧은 요청과 광범위한 생성 출력을 가진 애플리케이션은 프롬프트 처리에 상대적으로 적은 시간을 쓸 수 있다. 전체 경험을 프리필 처리량만으로 예측해서는 안 된다.

이 비율은 대기 시간의 보편적 감소가 아니라 처리량을 설명하기도 한다. 엔드투엔드 지연 시간, 즉 전체 요청에 걸린 시간에는 측정된 처리 단계 외의 요소도 포함된다. 로딩, 애플리케이션 오버헤드, 기타 작업은 직접적인 환산을 복잡하게 만든다.

이 구분은 익숙한 보도 오류를 막는다. 즉, 한 구성 요소의 개선을 완료된 작업에서 동일한 개선이 일어난 것처럼 제시하는 오류다. 벤치마크는 구성 요소를 정확히 설명할 수 있지만 애플리케이션 결과는 열어 둔다.

이번 릴리스는 개발자에게 긴 입력 워크로드를 조사할 더 구체적인 이유를 제공한다. 그렇다고 측정 전부터 자신의 애플리케이션이 빨라졌다고 결론 내리도록 요구하지는 않는다. 이는 서로 다른 증거 기준이다.

문서 컨텍스트를 구성하는 팀에게는 평가 설계 측면에서도 의미가 확장된다. 이전에 계산한 작업을 재사용하는 캐시된 입력은 새 입력과 구분해야 한다. 그렇지 않으면 반복 요청이 업데이트가 영향을 주는 처리 작업을 가릴 수 있다.

따라서 신뢰할 수 있는 애플리케이션 비교는 사용자가 제출한 내용과 시스템이 재사용한 내용을 설명해야 한다. 이 구분이 없으면 겉보기에 작은 차이가 개선을 숨길 수 있고, 겉보기에 큰 차이에는 다른 원인이 있을 수 있다.

Ollama MLX 성능은 정밀한 엔지니어링 주장으로 볼 때 가장 유용하다. 영향을 받은 단계, 모델 구성, 하드웨어, 입력 길이는 독자에게 시험할 대상을 제공한다. 이러한 경계를 제거하면 주장은 더 넓어지지만 정보 가치는 낮아진다.

Ollama DFlash2 지원은 다른 병목을 겨냥한다

DFlash2는 답변 생성과 관련되므로, 그 결과는 프롬프트 처리 개선과 분리해서 봐야 한다.

DFlash2 구현은 제안된 출력을 대상 모델이 확인하는 추측 생성 방식을 추가한다. 유지보수 담당자는 연속된 선택을 앞선 선택에 조건화하는 후보 선택기를 설명한다.

구현 노트에 따르면 세션은 라운드당 7개 토큰을 초안으로 만들고 기존 롤백 메커니즘을 통해 검증한다. 기여자는 검증이 대상 출력 분포를 보존한다고 말한다. 이는 여기에서 제시된 독립적 검증이 아니라 구현 주장이다.

풀 리퀘스트는 DFlash2를 여러 미래 토큰을 제안하는 메커니즘인 내장형 다중 토큰 예측 헤드와 비교한다. 나열된 저정밀 구성으로 qwen3.8:27b를 사용할 경우, 유지보수 담당자는 M5 Max, M5 Pro, M2 Ultra 시스템 전반에서 생성 성능 향상을 보고한다.

M5 Max에서 더 짧은 테스트 프롬프트를 사용했을 때 보고된 생성 처리량은 초당 57.0토큰에서 71.0토큰으로 상승합니다. 이 비교는 이전 릴리스와 후보 버전을 측정한 것이 아니라 동일한 빌드 내에서 이루어졌습니다.

마지막 구분은 중요합니다. 이 결과는 하나의 빌드 안에서 생성 방식을 비교한 것입니다. 이전 릴리스에서 전환하는 모든 사용자가 측정 가능한 업그레이드 성능 향상을 얻는다는 식으로 보도해서는 안 됩니다.

따라서 Ollama DFlash2 지원은 포괄적인 속도 보장을 제공하기보다 또 하나의 평가 경로를 추가합니다. 지원되는 구성에서는 동작을 비교할 기회가 생깁니다. 그러나 모든 애플리케이션에 어떤 생성 방식이 최상의 결과를 낼지 알려주지는 않습니다.

추론적 생성에서의 일반적인 절충점은 분명합니다. 제안된 토큰 중 충분한 수가 유용해야 이를 생성하고 검증하는 작업이 정당화됩니다. 제안 단계만 평가하면 검증 비용을 놓치게 됩니다.

애플리케이션 개발자에게는 내부적으로 몇 개의 후보 토큰이 제안되었는지보다 완성된 출력이 더 중요합니다. 적극적으로 초안을 생성하는 방식도 승인된 출력을 효율적으로 만들어야 합니다. 중요한 결과는 애플리케이션의 실제 조건에서 유용한 생성이 이루어지는지입니다.

출력 동작은 속도와 함께 면밀히 살펴봐야 합니다. 구조화된 응답을 사용하는 팀은 애플리케이션이 여전히 예상한 형식을 받는지 확인해야 합니다. 사실성 있는 답변을 평가하는 팀은 다른 실행 경로를 도입할 때 기존의 정확성 검증을 유지해야 합니다.

이는 평가 우선순위일 뿐, 이 구현이 형식이나 품질 문제를 일으킨다는 증거는 아닙니다. 소스는 동작을 유지하기 위한 안전장치를 설명합니다. 자체 요구사항이 계속 충족되는지는 독립적인 애플리케이션 테스트를 통해 팀이 판단해야 합니다.

지원과 기본 동작 사이에도 보도상 구분이 있습니다. 기능을 발표하는 릴리스 노트만으로는 설치된 모든 모델이 이를 사용한다는 사실이 확립되지 않습니다. 독자는 관찰된 결과의 실제 구성 환경을 파악해야 합니다.

이 점은 이 기능을 릴리스의 나머지 부분과 연결합니다. 런타임 개선은 호환성과 통합에 관한 일련의 결정을 거쳐야 유용해집니다. 사용자는 답변을 보지만, 어떤 변경 사항이 기여했는지는 선택된 모델과 실행 방식이 결정합니다.

긴 답변을 생성하는 워크로드에서는 생성 메커니즘 자체를 별도로 주목할 필요가 있습니다. 보고된 성능 향상과 무관한 프롬프트 처리 비율을 결합하면 근거 없는 추정치가 만들어집니다. 각 개선 사항은 애플리케이션 수준의 결론을 뒷받침하기 전에 이에 맞는 워크로드가 필요합니다.

의존성 업데이트가 비교의 근거를 유지한다

더 새로운 의존성은 기반이 변경되었음을 보여주지만, 보편적인 성능 결과를 입증하지는 않습니다.

llama.cpp 업데이트는 Ollama의 의존성을 빌드 b11845에서 b11901로 옮깁니다. llama.cpp는 학습된 모델을 실행해 출력을 생성하는 추론 엔진 소프트웨어입니다. 이 풀 리퀘스트는 10월 26일에 병합되었습니다.

공개된 풀 리퀘스트는 그에 상응하는 애플리케이션 벤치마크를 제시하지 않은 채 업스트림 비교를 연결합니다. 이는 버전 변경 사실을 보도하는 근거가 됩니다. 그러나 해당 경로를 사용하는 모든 워크로드에 특정한 속도 또는 품질 향상을 부여할 근거는 되지 않습니다.

이는 의존성 업데이트를 과도하게 해석하기 쉽기 때문에 중요합니다. 더 새로운 빌드 번호는 소프트웨어 계보를 설명합니다. 특정 애플리케이션에서 어떤 작업이 바뀌었는지, 또는 기존 병목 지점이 이동했는지는 알려주지 않습니다.

프레임워크를 직접 사용하는 방식과의 비교는 Ollama의 위치를 분명히 하는 데 도움이 됩니다. MLX framework는 개발자에게 프로그래밍 인터페이스와 머신러닝 작업을 직접 제공합니다. Ollama는 기본 기능을 모델 실행 환경에 통합합니다.

이 접근 방식들은 책임 수준이 다르면서도 겹치는 요구를 충족합니다. 프레임워크 작업을 직접 수행하는 연구자는 구현 선택지를 면밀히 살필 수 있습니다. 통합 런타임을 사용하는 애플리케이션 팀은 런타임이 지원하는 실행 경로에 의존합니다.

어느 접근 방식도 정의상 모든 비교에서 우위에 있지는 않습니다. 직접 접근은 제어력을 제공하는 반면, 통합은 지원되는 모델을 운영하는 데 필요한 작업을 줄일 수 있습니다. 공정한 평가는 애플리케이션 팀이 어떤 책임을 직접 맡고 싶은지 물어야 합니다.

이 후보 버전은 업스트림과 다운스트림 결과가 구분되어야 하는 이유도 보여줍니다. 프레임워크 기능은 애플리케이션이 혜택을 얻기 전에 적절한 통합이 필요합니다. 반대로 모델 자체가 바뀌지 않았다면 통합 개선을 새 모델의 공으로 돌려서는 안 됩니다.

이 구분은 경쟁 관련 주장에도 영향을 줍니다. 하나의 모델, 기기, 실행 경로에서 나온 결과만으로 Ollama가 일반적으로 대체 런타임보다 빠르다는 사실이 확립되지는 않습니다. 이는 그 시스템의 경계를 포함한 테스트 시스템의 결과를 보여줄 뿐입니다.

현재 이용 가능한 증거는 주로 프로젝트 유지관리자가 제공합니다. 이는 변경 사항의 존재와 보고된 측정값을 뒷받침합니다. 그러나 배포 옵션 전반의 프로덕션 도입, 안정성 또는 우수성에 관한 독립적 합의를 제공하지는 않습니다.

그 증거를 의미 있게 만들기 위해 공개적 논쟁을 억지로 만들어낼 필요는 없습니다. 미해결 문제는 실용적입니다. 유지관리자의 측정 범위를 벗어난 애플리케이션에서도 이 변경 사항이 유용한 성과를 내는지 여부입니다. 만들어낸 지지자나 비판자 없이도 이 질문은 충분히 중요합니다.

기업 구매자에게는 증거 품질에 대한 적절한 검증 압력이 필요합니다. 광범위한 로컬 AI 시연은 의도한 작업과 일치하는 결과보다 덜 유용합니다. 조달 결정에서는 모델, 하드웨어, 워크로드 및 운영 요구사항이 맞물려야 합니다.

개발자는 비교의 배경 맥락을 유지하는 것도 도움이 됩니다. 평가를 문서화하는 팀은 검색 가능한 지식 베이스를 사용해 구성 및 예시와 함께 발견 사항을 보존할 수 있습니다. 유용한 기록에는 가장 빠른 실행 결과뿐 아니라 실패와 한계도 포함됩니다.

이 후보 버전의 중요성을 보여줄 세 가지 신호

다음으로 의미 있는 증거는 순서대로 릴리스 진행 상황, 재현 가능한 시간 측정, 검증된 작업 동작입니다.

먼저 공개된 후보 버전에 어떤 일이 일어나는지 살펴봐야 합니다. 안정 버전 아티팩트, 후속 후보 버전 또는 수정 릴리스는 더 폭넓게 채택할 수 있는 소프트웨어를 분명히 해줄 것입니다. 이런 이벤트가 애플리케이션 품질을 자동으로 입증하지는 않지만, 릴리스 상태에 관한 질문의 일부는 해소할 것입니다.

가장 유용한 진행 과정은 태그와 변경 사항의 명확한 연결을 유지하는 방식일 것입니다. 그러면 개발자는 이후 결과가 이 후보 버전과 관련 있는지, 수정된 빌드와 관련 있는지 파악할 수 있습니다. 이러한 연속성이 없으면 논의 과정에서 서로 다른 소프트웨어의 발견 사항이 동일한 축약 버전명 아래 섞일 수 있습니다.

후속 수정이 여기서 설명한 작업을 자동으로 무효화하지는 않습니다. 그 의미는 영향을 받은 동작에 따라 달라집니다. 독자는 보고된 문제, 그 범위, 그리고 자신이 사용하는 구성 사이에 구체적인 관계가 있는지 살펴봐야 합니다.

둘째, 입력 처리와 출력 생성을 분리한 재현 가능한 애플리케이션 시간 측정을 지켜봐야 합니다. 이를 통해 보고된 구성 요소 개선이 원래 측정 조건 밖에서도 유지되는지 확인할 수 있습니다. 결과에는 실제 모델 구성과 하드웨어가 명시되어야 합니다.

일치하는 워크로드에서 나온 증거는 관련 변경 사항을 채택해야 한다는 근거를 강화할 것입니다. 종단 간 이점이 거의 없음을 보여주는 비교는 구성 요소 벤치마크와 반드시 모순되지 않으면서도 그 근거를 좁힐 수 있습니다. 애플리케이션이 단지 다른 곳에서 시간을 쓰고 있을 수 있습니다.

시간 측정 보고서는 새 입력과 재사용 입력을 모두 설명할 때 더 유익해집니다. 또한 이미 로드된 모델과 모델을 로드해야 하는 요청을 구분해야 합니다. 이 조건들은 일상적인 사용에 관한 서로 다른 질문에 답합니다.

셋째, 이미지 처리와 가속 생성에 대한 작업 수준의 검증을 지켜봐야 합니다. 이미지 수정에는 유지된 시각 정보를 검증하는 예시가 필요합니다. 생성 경로에는 특히 애플리케이션이 예측 가능한 구조에 의존하는 경우 시간 측정과 함께 출력 검증이 필요합니다.

유용한 보고서에는 원본 입력, 예상 동작, 그리고 비교된 각 구성의 결과가 포함됩니다. 그러면 다른 사람도 단순히 답변이 더 좋아 보였다는 주장에 의존하지 않고 그 주장을 검토할 수 있습니다.

이미지 작업의 경우 쉬운 예시에서의 정답은 까다로운 입력에 대한 제한적인 증거만 제공합니다. 생성 작업의 경우 빠른 응답은 애플리케이션 호환성에 대한 제한적인 증거만 제공합니다. 각 결과의 강도는 실제로 무엇을 테스트했는지에 달려 있습니다.

이 신호들은 하나의 점수로 축소하지 않고 함께 읽어야 합니다. 릴리스 진행 상황은 아티팩트에 관한 것입니다. 시간 측정은 실행에 관한 것입니다. 작업 검증은 애플리케이션이 유용한 작업을 올바르게 완료하는지에 관한 것입니다.

향후 몇 달 동안 가장 가치 있는 후속 결과는 이러한 계층을 연결하는 것이 될 것입니다. 특정 릴리스 및 대표적인 작업과 연결된 재현 가능한 결과는 실질적 근거를 강화할 것입니다. 뒷받침되지 않는 일반화는 주목을 끌 수는 있어도 배포 문제를 해결하지는 못합니다.

Ollama v0.40.12를 평가하는 독자라면 이미 자신에게 중요한 워크로드부터 시작하십시오. 빌드를 비교하기 전에 입력, 모델 구성, 예상 출력을 보존하십시오. 요청 처리에 소요된 시간과 답변 생성에 소요된 시간을 따로 기록하십시오. 이미지가 중요하다면 원본 파일을 보관하고 애플리케이션에 필요한 세부 사항을 확인하십시오. 가속 생성이 중요하다면 속도와 함께 완성된 응답을 점검하십시오. 나중의 비교가 해석 가능하도록 결과와 함께 후보 버전의 전체 태그를 보관하십시오. 그런 다음 구체적인 결과를 중심으로 업그레이드 결정을 내리십시오. 변경된 실행 경로가 애플리케이션이 실제로 마주하는 조건에서 사용자가 실제로 수행하는 작업을 개선했습니까?