모델과 실행 도구

“사내 문서를 잘 답하는 한국어 모델을 골라 달라”는 요청을 바로 family 검색어로 바꾸면 후보가 끝없이 늘어납니다. 먼저 사용자가 넣는 자료, 기대하는 결과, 허용할 수 없는 오류와 사람이 확인할 지점을 적습니다. 문서 Q&A라면 질문을 vector로 만드는 embedding, 관련 문서를 찾는 검색기, 후보 순서를 고치는 reranker, 근거로 문장을 쓰는 generative model이 이어집니다. 표가 이미지라면 OCR 또는 Vision stage가 앞에 추가됩니다. 이 stage들은 서로 다른 model과 runtime으로 운영할 수 있으며 한 stage의 실패를 전체 LLM 능력 부족으로 부르면 원인을 찾을 수 없습니다.

각 역할에 output contract를 둡니다. 생성 모델은 정답·근거 인용·JSON 형식·모르면 보류하는 행동, embedding은 정답 문서가 top-k에 들어오는 recall, reranker는 정답 문서의 순위와 추가 지연, OCR은 필드·문자·숫자 정확도, Speech-to-Text는 단어 오류율과 고유명사 정확도가 핵심입니다. 같은 “정확도 90%”라는 열로 합치면 분모와 실패 의미가 다른 지표를 거짓으로 비교하게 됩니다. 역할별 지표의 계산식, 판정자와 최소 표본을 catalog schema에 함께 둡니다.

후보를 보기 전에 정상·경계·실패 예시를 만듭니다. 생성에는 흔한 질문뿐 아니라 근거가 없는 질문, 상충 문서, 날짜·금액과 구조화 출력이 포함됩니다. 검색에는 짧은 제목, 긴 표, 동의어와 정답이 없는 질문을 넣습니다. Vision에는 흐린 사진, 회전, 작은 한글과 표 셀 병합을 넣고 음성에는 배경 소음과 사내 약어를 넣습니다. 실제 사용자가 겪는 빈도와 피해를 반영한 gold set이 없으면 공개 benchmark와 데모의 인상만 남습니다.

한 모델이 text와 image를 모두 받거나 여러 언어를 지원한다고 적혀 있어도 역할별 pass를 자동으로 공유하지 않습니다. 이미지 입력 capability는 한국어 영수증의 숫자 field 정확도를, 긴 context capability는 마지막 쪽 조항을 인용하는 능력을 보증하지 않습니다. 반대로 작은 전문 reranker나 OCR이 큰 생성 모델보다 해당 stage에서 더 정확하고 빠를 수 있습니다. 최종 system은 각 stage의 통과 결과와 연결되며, 교체할 때도 해당 역할의 동일 workload만 먼저 회귀할 수 있어야 합니다.

왜 이런가

입출력과 오류 비용이 다른 기능을 나누어야 필요한 모델만 찾고 실패한 stage만 교체할 수 있기 때문입니다.

언제 문제가 되는가

모든 기능을 하나의 인기 순위로 고르면 검색 recall 저하를 생성 모델 문제로 오판하고 더 큰 모델을 사도 오류가 남습니다.

초보자가 자주 하는 오해

Multimodal 또는 multilingual 표시는 모든 이미지·언어·업무에서 같은 품질을 보증하는 인증 마크가 아닙니다.

직접 확인하는 방법

내 업무 흐름을 stage로 그리고 각 stage의 입력, 출력, gold answer, 필수 지표와 사람 승인 지점을 한 줄씩 적으십시오.

Hub에는 공식 제작자와 이름이 비슷한 community upload, merge, adapter와 변환본이 함께 나타납니다. 검색 결과의 다운로드 수나 이름만으로 원본을 고르지 않습니다. 제작자의 공식 사이트·GitHub repository·model card가 가리키는 organization과 repository인지 교차 확인합니다. Meta의 Llama model repository처럼 release별 model card와 license가 어디에 있는지, Google의 Gemma 공식 문서처럼 model family의 변형이 어디에 설명되는지 먼저 확인합니다. 공식 링크가 없는 재업로드는 출처를 모르는 별도 후보로 취급합니다.

Catalog의 식별자는 표시 이름이 아니라 organization/repository, exact commit revision, 다운로드한 file name·byte와 cryptographic hash입니다. Branch나 `main`, `latest` 같은 움직이는 참조는 검토 뒤 내용이 바뀔 수 있으므로 평가 시점의 commit을 고정합니다. 다운로드 날짜도 남기되 날짜만으로 revision을 대신하지 않습니다. 같은 model ID를 다시 받아 hash가 다르면 이전 승인 결과를 그대로 붙이지 않고 변경된 file과 card·terms를 diff합니다.

Weight 외에도 config, tokenizer, chat template, processor와 special token file을 한 묶음으로 봅니다. 새로운 weight에 이전 tokenizer를 섞거나 instruct variant에 다른 family의 role template을 쓰면 생성 종료, system 역할과 품질이 달라질 수 있습니다. 모델 호출 직전에 렌더링된 prompt와 processor output을 공식 예제와 대조하고, manifest에 각 component의 source revision과 hash를 둡니다. 단순히 repository 전체를 복사했다는 기록보다 실제 배포에 필요한 file allowlist가 더 검토하기 쉽습니다.

재현성을 확인하려면 다른 담당자가 catalog 행만으로 같은 artifact를 다시 받아야 합니다. Offline cache가 있다면 원격 source와 local object hash의 관계를 남기고, 접근 승인이 필요한 gated model은 누가 어떤 계정·terms version으로 받았는지 기록합니다. 삭제된 repository나 만료된 권한 때문에 다시 받을 수 없다면 승인 artifact를 허용된 내부 registry에 보존하고 retention·접근 정책을 둡니다. 출처가 사라져도 무엇을 평가했는지는 증명할 수 있어야 합니다.

왜 이런가

이름이 같은 upload와 움직이는 tag가 다른 파일을 가리킬 수 있어 결과의 원인과 보안 상태를 재현하려면 불변 식별자가 필요합니다.

언제 문제가 되는가

Repository 이름만 남기면 update 뒤 품질이 바뀌었을 때 모델, tokenizer, template 중 무엇이 달라졌는지 알 수 없습니다.

초보자가 자주 하는 오해

다운로드 수가 많거나 공식 family 이름을 포함한 community repository가 제작자의 원본이라는 뜻은 아닙니다.

직접 확인하는 방법

공식 문서에서 repository로 이동해 organization, commit, 파일 목록·byte와 hash를 기록하고 다른 환경에서 같은 hash를 다시 받으십시오.

같은 family 안에서도 base, pretrained, instruction-tuned, coding, safety, vision 변형은 목적과 입력 형식이 다릅니다. Base model은 다음 token 학습의 출발점이고 chat·instruct model은 특정 instruction tuning과 template을 전제로 할 수 있습니다. 이름의 suffix를 일반 상식으로 해석하지 않고 제작자가 정의한 intended use, architecture와 예제 입력을 확인합니다. Repository card가 family 전체 설명인지 exact checkpoint 설명인지도 구분해 다른 크기의 조건을 복사하지 않습니다.

Parameter 수, artifact byte와 실행 memory를 같은 열로 쓰지 않습니다. Dense model과 Mixture-of-Experts에서는 total과 token당 activated parameter가 다를 수 있고 vision encoder·embedding 같은 component가 이름 숫자에 포함되는 방식도 다릅니다. Config의 layer·hidden size·attention 구조와 file 목록을 확인하고 precision별 실제 byte, load·prefill·decode peak를 기록합니다. “30B-A3B” 같은 이름을 3B file 또는 30B dense compute로 단정하지 않고 공식 정의와 runtime log를 연결합니다.

Context window와 modality는 architecture capability의 조건입니다. 예를 들어 한 family 안에서도 크기에 따라 공식 context나 image input 지원이 다를 수 있으므로 exact variant card를 읽습니다. 최대 context 숫자는 모든 위치의 정보 recall, 내 GPU에서의 동시성·지연과 품질을 보증하지 않습니다. 최소·대표·최장 문서에서 시작·중간·끝 근거를 물어 truncation과 lost-in-the-middle을 확인하고, Vision은 해상도·이미지 수와 processor 설정까지 고정합니다.

Limitations와 risk 절은 성능 표보다 뒤로 미루지 않습니다. 학습 data 개요, 지원 언어, factuality·bias·safety와 평가하지 않은 domain을 내 사용 조건에 mapping합니다. Card에 한국어나 의료·법률 같은 domain 증거가 없으면 지원된다고 추정하지 않고 로컬 평가와 전문가 검토가 필요한 gap으로 기록합니다. “권장하지 않음” 또는 사람 감독 조건이 있다면 앱 권한과 승인 flow에 반영하며, 문서가 비어 있는 것도 통과가 아니라 미확인 상태입니다.

왜 이런가

Family 내부 변형마다 입력, template, context와 평가 범위가 달라 정확한 checkpoint 조건을 알아야 올바른 후보 비교가 가능합니다.

언제 문제가 되는가

다른 크기나 base variant의 설명을 복사하면 지원하지 않는 image·context를 기대하거나 잘못된 template로 품질을 망칠 수 있습니다.

초보자가 자주 하는 오해

Model card의 최대 context와 공개 benchmark 점수는 내 언어·문서·장비에서의 품질과 속도를 보증하지 않습니다.

직접 확인하는 방법

Exact checkpoint card와 config에서 variant, modality, context, language, limitation을 뽑고 내 요구사항 각 행에 직접 근거 또는 gap을 연결하십시오.

Hugging Face의 원본 weight를 llama.cpp용 GGUF, MLX 형식이나 runtime별 quant로 바꾸면 새로운 artifact가 됩니다. Source model ID 하나만 적고 `model-q4.gguf`를 저장하면 어떤 revision, quant method와 tool version이 사용됐는지 알 수 없습니다. Build manifest에는 source file hash, converter·quantizer commit, command와 option, calibration data의 식별자, output file·byte·hash를 둡니다. Container image와 build architecture도 결과에 영향을 주므로 가능하면 재실행 가능한 recipe로 보존합니다.

Community가 만든 quantized file은 편리하지만 provenance gap을 별도 평가해야 합니다. Card에 source revision과 변환 command가 있는지, tokenizer와 template가 원본과 일치하는지, 여러 split file이 완전한지 확인합니다. 같은 Q4 표기도 method·group·mixed precision에 따라 quality와 kernel 지원이 다를 수 있습니다. File 이름의 quant label을 성능·품질 보증으로 쓰지 않고 실제 metadata와 변환 기록을 읽습니다.

Artifact security는 악성 code만의 문제가 아닙니다. Pickle 기반 file은 역직렬화 시 code execution 위험이 있고, custom modeling code나 `trust_remote_code`는 repository code를 실행합니다. Safetensors 사용 여부, 필요한 file type allowlist, malware·secret scan과 dependency 검토를 수행합니다. 공식 organization의 file도 최소 권한과 격리 환경에서 받아 hash를 검증하며, browser에서 본 card와 실행 node가 받은 object가 같은지 확인합니다.

계보의 마지막에는 평가와 rollback이 붙습니다. 어떤 artifact가 어느 runtime·driver에서 역할별 평가를 통과했는지, 실패한 input과 log, 이전 승인 artifact의 hash를 연결합니다. 새 quant가 더 작아도 숫자 추출·한국어 하위 품질이나 tool format이 떨어지면 hold입니다. 원본에서 다시 변환하거나 이전 artifact로 되돌린 뒤 같은 실패 입력이 회복돼야 원인을 quant change로 좁힐 수 있습니다.

왜 이런가

변환·양자화는 byte와 계산·오차를 바꾸므로 원본과 다른 독립 artifact이며 품질·보안·호환성 증거가 필요합니다.

언제 문제가 되는가

Source revision과 recipe가 없으면 더 작은 file의 품질 회귀를 재현하거나 안전하게 다시 만들 수 없습니다.

초보자가 자주 하는 오해

Family와 Q4 이름이 같으면 제작자·변환 방법에 관계없이 bit 단위까지 같은 모델인 것은 아닙니다.

직접 확인하는 방법

Source hash에서 tool·command·calibration을 거쳐 output hash까지 chain을 만들고 격리된 clean build에서 동일 결과를 재생성하십시오.

Open-weight는 보통 학습된 weight에 접근할 수 있다는 배포 사실을 나타냅니다. 이것만으로 training data, source code와 학습 recipe가 모두 공개됐거나 표준적인 open-source software license가 적용된다고 결론 내릴 수 없습니다. Catalog에는 weight access, model license, code license, data·recipe 공개 범위를 분리된 열로 둡니다. “오픈 모델”이라는 marketing 표현 대신 어떤 파일을 받을 수 있고 무엇을 할 권리가 있는지 구체적인 문장으로 바꿉니다.

Exact release의 license file과 acceptable use policy를 읽습니다. 상업 이용, 재배포, derivative work, attribution·notice, 월간 사용자나 조직 규모 조건, 금지 domain과 지역 조건이 내 배포 방식에 적용되는지 검토합니다. Hub의 license metadata tag는 검색을 돕지만 원문과 부속 policy를 대신하지 않습니다. URL, file hash 또는 revision, 검토 날짜와 담당자를 남기고 해석이 중요한 곳은 조직의 법률 검토에 연결합니다.

Adapter 학습, merge, quantization과 API 제공도 질문이 다릅니다. Base model과 dataset·code license의 의무가 충돌하지 않는지, 변환 artifact를 고객에게 전달할 수 있는지, attribution과 card·notice를 어떻게 제공할지 정합니다. File을 배포하지 않고 server API로만 제공한다고 해서 prohibited use, privacy와 output 책임이 자동으로 사라지지 않습니다. 내부 pilot과 외부 product의 사용 조건을 같은 승인으로 묶지 않습니다.

License가 불명확하면 benchmark가 높아도 기술 승인과 별도로 hold입니다. 담당자가 추측으로 빈칸을 “허용”으로 채우지 않고 확인 질문, 필요한 자문과 대체 후보를 기록합니다. Model release가 바뀌면 weight diff뿐 아니라 terms와 policy diff를 다시 봅니다. 이전 version의 검토 결과는 조건이 같은 범위에서만 재사용하고, 새 의무가 있으면 배포 notice·접근 통제와 catalog 상태를 함께 갱신합니다.

왜 이런가

기술적으로 실행 가능한 모델도 사용·재배포 조건이 업무와 맞지 않으면 합법적이고 지속 가능한 후보가 아니기 때문입니다.

언제 문제가 되는가

짧은 license tag만 보고 승인하면 외부 배포·파생 artifact 또는 사용 규모 조건을 뒤늦게 발견해 제품을 철회할 수 있습니다.

초보자가 자주 하는 오해

Weight를 무료로 내려받을 수 있다는 사실은 제한 없는 상업 이용과 재배포 권리를 뜻하지 않습니다.

직접 확인하는 방법

Exact revision의 license·policy에서 내 사용, 수정, 배포와 금지 조건을 표로 만들고 담당 검토자의 날짜·결론을 증빙에 연결하십시오.

Compatibility 행에는 model architecture와 artifact format, hardware, 운영체제·architecture, driver, runtime·backend version을 함께 둡니다. GGUF가 llama.cpp에서 load된 사실은 같은 file이 vLLM·MLX에서 지원된다는 뜻이 아니고, Hugging Face repository가 있다는 사실도 특정 GPU quant kernel을 보증하지 않습니다. Runtime의 official supported model·feature 문서와 release note를 확인하고 exact combination을 고정합니다. 지원표에 없는 조합은 “아마 됨” 대신 실험 상태로 분리합니다.

Chat template, tokenizer와 processor는 기능 호환성의 일부입니다. Instruct model이 기대하는 role·special token, Vision의 image processor, embedding의 pooling·normalization과 reranker의 입력 쌍 형식을 공식 example과 대조합니다. 한 prompt가 출력됐다는 사실보다 system role, stop token, tool schema와 structured output이 실제 적용됐는지 시험합니다. Wrapper가 알 수 없는 option을 조용히 무시하는 경우를 찾기 위해 의도적으로 잘못된 값과 경계 입력도 실행합니다.

Startup log와 profiler에서 실제 execution path를 확인합니다. 모든 layer 또는 operator가 예상 GPU·NPU에 배치됐는지, CPU fallback과 host-device transfer가 얼마나 생겼는지, context·batch가 늘 때 compile graph가 바뀌는지 기록합니다. 장치 utilization 하나만 높다고 전체 graph 가속으로 판단하지 않습니다. Load·prefill·decode, embedding·reranking 단계별 latency와 peak VRAM·RAM을 나누면 host tokenizer, transfer, unsupported kernel과 queue 병목을 구별할 수 있습니다.

작은 성공 기준선부터 확장합니다. 짧은 text·동시성 1·기본 precision으로 정확한 output을 확인한 뒤 긴 context, image, tool, batch와 동시성을 하나씩 늘립니다. 실패하면 model·runtime·driver·template를 동시에 바꾸지 않고 마지막 변경을 되돌려 같은 input의 회복을 확인합니다. 최종 catalog에는 지원 기능뿐 아니라 미지원·제약, 대체 path와 해당 version에서 재현한 command·log를 남깁니다.

왜 이런가

같은 artifact도 runtime·backend와 template 지원에 따라 실행 장치, 기능·속도와 결과가 달라지기 때문입니다.

언제 문제가 되는가

Load 성공만 기록하면 실제 운영에서 tool 형식이 무시되거나 CPU fallback 때문에 p95가 급증하는 문제를 놓칩니다.

초보자가 자주 하는 오해

Model card의 architecture 지원은 모든 quant, hardware, OS와 serving 기능을 자동으로 포함하지 않습니다.

직접 확인하는 방법

Exact stack을 manifest로 고정하고 짧은 기준선에서 장치 배치·output을 확인한 뒤 기능과 부하를 한 항목씩 확대하십시오.

평가 세트는 운영 분포와 실패 피해를 대표해야 합니다. 생성 Q&A에는 승인 문서에서 정답과 근거 문단을 정하고, 답이 없는 질문은 “근거 없음”으로 처리하는 정답을 둡니다. 숫자·날짜, 상충 문서, 긴 표와 prompt injection을 포함해 단순한 상식 질문에 치우치지 않습니다. Coding은 compile·test와 금지 API, Vision·OCR은 field별 ground truth, 음성은 사람 검수 transcript를 사용하며 개인정보는 허용된 절차로 비식별화합니다.

지표는 역할과 사용자의 실패 경험을 반영합니다. 생성은 정답·근거 충실도, citation 존재, schema 준수와 안전 거절을 분리하고 embedding은 recall@k, reranker는 MRR·nDCG와 추가 p95를 봅니다. OCR은 전체 문자 정확도만으로 금액·계좌 필드 오류를 숨기지 않고 중요 field exact match를 둡니다. STT도 평균 단어 오류 외에 제품명·숫자 하위 집합을 별도 gate로 둡니다.

Baseline과 candidate는 같은 model input, prompt·template, output limit, sampling, evaluation code와 runtime 조건에서 비교합니다. 후보의 필수 template 차이는 기록하되 공통 업무 입력과 판정 기준은 유지합니다. 최소 3회 반복으로 stochastic output과 시스템 변동을 보고, 자동 judge를 쓰면 사람 gold와의 일치도·편향을 먼저 검증합니다. 결과를 본 뒤 합격선을 낮추지 않고 사전 threshold와 변경 이력을 보존합니다.

전체 평균이 통과해도 중요한 하위 집합이 실패하면 hold입니다. 한국어 숫자 추출 70%를 영어 일반 질문 99%가 덮게 두지 않습니다. 실패 input, 실제 output, expected answer, 판정 이유와 model·artifact hash를 보존하고 root cause를 model, prompt·template, retrieval, quant 또는 runtime으로 분류합니다. 한 항목을 고쳐 동일 실패 세트와 전체 회귀를 다시 실행해야 국소 개선이 다른 품질을 망치지 않았음을 알 수 있습니다.

왜 이런가

업무별 오류와 피해가 공개 benchmark 평균에 드러나지 않으므로 실제 사용 분포와 중요한 하위 집합이 승인 근거가 되어야 합니다.

언제 문제가 되는가

전체 평균만 보면 빈 근거·숫자·한국어처럼 필수 사례의 심각한 회귀가 쉬운 문제 다수에 가려질 수 있습니다.

초보자가 자주 하는 오해

더 큰 model이나 공개 순위 1위가 내 prompt·언어·quant에서도 같은 순위를 유지하는 것은 아닙니다.

직접 확인하는 방법

역할별 정상·경계·실패 gold set과 사전 threshold를 고정하고 baseline·candidate의 실패 행까지 그대로 비교하십시오.

성능 manifest에는 exact model revision·artifact, tokenizer·template, quant, runtime·driver, input·output token, sampling, batch·concurrency와 hardware power 조건을 둡니다. Cold download·load·compile, warm Time To First Token, prefill·decode token/s와 end-to-end latency를 분리합니다. 평균 하나 대신 p50·p95·maximum과 error rate를 기록하고 최소 3회 반복합니다. 사용자 요청 분포가 짧고 긴 문서를 섞는다면 그 비율과 queue까지 부하에 포함합니다.

Memory는 file byte가 아니라 단계별 peak입니다. Weight, KV cache 또는 embedding batch, runtime workspace, host RAM·VRAM과 안전 여유를 기록합니다. Context·image 수와 동시성을 목표까지 단계적으로 늘려 OOM·fragmentation·swap을 찾습니다. 더 작은 quant가 memory를 줄여도 kernel 미지원이나 품질 저하로 p95·오류가 악화될 수 있으므로 capacity, execution path와 quality를 같은 후보 행에서 보되 각각 독립 threshold로 판정합니다.

비용은 장비 가격만이 아니라 전력·storage·network, 운영 인력과 장애 시간을 포함합니다. 필수 품질·p95·memory·availability를 통과하지 못한 후보가 저렴하다는 이유로 종합 점수에서 살아남게 하지 않습니다. 통과 후보끼리 요청당 비용, 목표 부하의 headroom과 유지보수 난이도를 비교합니다. 가격·cloud rate는 날짜와 지역이 변하므로 공식 catalog 본문에 영구 순위를 박지 않고 시점이 있는 별도 산출물로 관리합니다.

승격 전 canary와 rollback을 실제로 실행합니다. 이전 artifact·runtime·config를 접근 가능한 registry에 보존하고 새 후보에서 실패한 동일 input을 이전 backend로 보내 회복되는지 확인합니다. Rollback time, cache·index compatibility와 담당자를 runbook에 둡니다. 전체 전환 후에도 quality·p95·error와 drift를 관측하며 threshold를 넘으면 자동으로 위험한 action을 계속하지 않고 traffic을 제한하거나 이전 후보로 되돌립니다.

왜 이런가

사용 가능한 모델은 정답뿐 아니라 목표 부하에서 안정적으로 응답하고 장애 때 정해진 시간 안에 복구되어야 하기 때문입니다.

언제 문제가 되는가

한 번의 warm token/s와 file 크기만 보면 cold start, p95 queue, 최대 context OOM과 장시간 장애를 배포 뒤에 발견합니다.

초보자가 자주 하는 오해

품질 1위 후보가 목표 hardware에서 가장 빠르거나 가장 낮은 운영 비용을 자동으로 갖는 것은 아닙니다.

직접 확인하는 방법

동일 manifest의 반복 부하에서 품질·p95·peak·오류를 통과시키고 이전 artifact로 같은 실패 input이 회복되는 시간을 재십시오.

Catalog schema에는 역할, official source·revision, artifact provenance, license 결론, runtime stack, 평가 세트 version, quality·p95·memory 결과와 owner를 둡니다. 상태는 탐색 중, 기술 검토, license hold, 평가 hold, canary, approved, retired처럼 근거가 있는 단계로 구분합니다. 빈칸을 통과로 해석하지 않고 누락된 model card·license·runtime 또는 평가가 무엇인지 evidence gap을 적습니다. 한 화면에서 현재 추천과 그 추천이 유효한 조건을 함께 볼 수 있어야 합니다.

각 행에는 마지막 검토일과 재검토 trigger가 필요합니다. Official repository·license 변경, 새 model revision, 변환 도구·runtime·driver update, hardware 교체, prompt·retrieval 변경과 업무 데이터 drift가 trigger입니다. 날짜가 지났다는 이유만으로 자동 실패시키기보다 변화 가능성과 업무 위험에 따라 주기를 정합니다. 보안 공지나 license 변경처럼 영향이 큰 사건은 정기 검토를 기다리지 않고 관련 artifact를 즉시 hold할 수 있어야 합니다.

새 release가 나오면 이전 행을 덮어쓰지 않습니다. 새 source revision과 artifact hash를 새 행 또는 version으로 만들고 동일 gold set·부하를 실행해 diff를 남깁니다. 실패 결과와 retired 이유도 삭제하지 않아야 같은 후보를 반복 검토하거나 과거 의사결정을 잃지 않습니다. 평가 세트가 바뀌면 과거 점수와 새 점수를 직접 순위로 섞지 않고 dataset version과 rubric change를 표시합니다.

최종 승인에는 책임 분리가 필요합니다. 기술 담당자는 provenance·runtime과 measurement를, 업무 담당자는 gold answer와 실패 비용을, 보안·법률 담당자는 file·code와 terms를 검토합니다. 승인자가 실험 수행자와 같더라도 독립 검토 check를 남기고, browser checkbox나 screenshot만을 실제 evidence로 삼지 않습니다. 다른 담당자가 source, manifest, raw result와 rollback log로 같은 결론을 재현할 수 있을 때 catalog는 개인 추천 메모가 아니라 운영 자산이 됩니다.

왜 이런가

모델, license, runtime과 업무 데이터가 계속 변하므로 승인 조건과 책임·재검토 시점이 없으면 추천이 빠르게 낡기 때문입니다.

언제 문제가 되는가

기존 행을 latest 결과로 덮으면 어떤 artifact가 실제 배포됐고 왜 retired됐는지 알 수 없어 회귀와 감사에 대응하지 못합니다.

초보자가 자주 하는 오해

한 번 통과한 모델이 모든 새 revision·runtime과 바뀐 업무에서 영구 승인되는 것은 아닙니다.

직접 확인하는 방법

행 하나를 골라 owner, source·artifact hash, license, raw 평가, 승인 조건, trigger와 rollback 증거를 제3자가 따라갈 수 있는지 확인하십시오.

사용자는 모델 이름 하나를 선택했다고 느끼지만 실제 응답에는 여러 층이 관여합니다. Repository에서 받은 weight·config·tokenizer와 processor가 artifact 층이고, chat template가 role과 special token을 model input으로 바꿉니다. Runtime은 이를 load해 scheduler로 요청을 묶고 backend kernel을 CPU·GPU 같은 device에서 실행합니다. Server mode라면 API parser, streaming, queue와 metric도 추가됩니다. 같은 model weight도 어느 층이 달라졌는지에 따라 품질·memory와 latency가 변합니다.

Ollama, llama.cpp, MLX LM, Transformers와 vLLM을 한 줄의 “빠른 순서”로 정렬하면 이 층을 잃습니다. Ollama는 model 관리와 local API 경험, llama.cpp는 GGUF와 다양한 backend의 직접 제어, MLX LM은 Apple silicon 경로, Transformers는 Python·PyTorch의 폭넓은 model·training 제어, vLLM은 online serving을 중심으로 설계 범위가 다릅니다. 한 목적에서 편한 선택이 다른 목적의 필수 기능을 갖췄다는 뜻은 아닙니다.

장애도 층별 증거로 나눕니다. Role이 뒤섞이면 rendered chat template, load 실패면 architecture·file와 runtime support, 느린 응답이면 queue·device placement·kernel과 transfer, 형식 누락이면 API parameter·sampling·model output을 먼저 봅니다. “같은 모델인데 답이 다르다”는 말만 남기면 artifact, template와 scheduler 중 무엇이 달라졌는지 알 수 없습니다. Request ID와 manifest로 input에서 response까지 연결합니다.

Runtime 변경은 software deployment입니다. Binary·container digest, package·driver와 build flag, model·artifact hash, config와 API contract를 versioned artifact로 관리합니다. Notebook에서 설치한 latest package나 desktop 자동 update를 production과 같은 상태로 가정하지 않습니다. 이전 image·config와 artifact를 보존하고, 같은 실패 input이 이전 stack에서 회복되는지 시험할 수 있어야 새 runtime의 개선과 회귀를 설명할 수 있습니다.

왜 이런가

응답을 만드는 여러 층을 나눠야 모델 능력 문제와 template·runtime·backend·API 문제를 올바르게 진단할 수 있기 때문입니다.

언제 문제가 되는가

Model 이름만 기록하면 runtime update 뒤 품질·latency 회귀가 어느 artifact·설정·device path에서 생겼는지 재현할 수 없습니다.

초보자가 자주 하는 오해

같은 weight file을 사용하면 모든 runtime에서 prompt, memory 사용·성능과 API 결과가 자동으로 같아지는 것은 아닙니다.

직접 확인하는 방법

현재 요청 하나의 artifact, tokenizer·template, runtime·scheduler, backend·device와 API response를 version·log로 차례로 적으십시오.

개인 terminal 대화는 설치와 model 교체, 한 요청의 TTFT·decode와 privacy가 중요합니다. 연구·학습은 Python model object, processor, gradient·checkpoint와 custom code가 필요합니다. Desktop application은 localhost API의 startup·streaming과 idle memory가 중요하고 팀 service는 authentication, queue·rate limit, p95·availability와 rolling update를 요구합니다. 이 네 workload를 모두 “로컬 LLM 실행”으로 부르면 candidate의 장점과 결함이 평균에 섞입니다.

Manifest에는 exact model·revision·artifact hash, tokenizer·template, input·output token, batch·동시성, sampling과 hardware를 둡니다. 정상·경계·실패 input도 고정합니다. 짧은 대화, 긴 문서, 빈 근거, 취소, 잘못된 schema와 동시에 긴·짧은 요청이 섞이는 경우를 포함합니다. 개인 demo는 동시성 1이고 짧은 prompt인 반면 production traffic은 queue와 KV cache가 누적되므로 같은 한 번의 token/s로 비교할 수 없습니다.

필수 기능을 endpoint 이름이 아니라 client behavior로 표현합니다. Streaming chunk 순서, usage field, structured output schema, tool call argument, embedding dimension, image input와 error status를 실제 request·expected response로 둡니다. “OpenAI-compatible”은 유용한 출발점이지만 runtime·version마다 지원 endpoint와 parameter가 달라질 수 있습니다. Client가 의존하는 contract를 자동 시험하고 지원하지 않는 기능은 명시적 hold로 남깁니다.

비기능 요구도 사전에 정합니다. 품질·형식 최소값, p95 TTFT·전체 latency, throughput, peak memory, error rate와 recovery time을 후보 결과를 보기 전에 고정합니다. LAN·internet exposure, 인증과 prompt log privacy, offline requirement·model download 경로를 적습니다. 필수 조건을 통과하지 못한 runtime을 설치가 쉽거나 평균 속도가 높다는 이유로 종합 점수에서 승인하지 않습니다.

왜 이런가

Runtime의 설계 목표가 다르므로 내 workload와 client contract를 고정해야 비교 결과가 실제 사용에 적용됩니다.

언제 문제가 되는가

한 사용자 demo로 team service를 승인하면 queue·p95, 인증·취소와 overload를 실제 배포 후 처음 발견합니다.

초보자가 자주 하는 오해

API가 비슷하거나 localhost에서 응답했다는 사실은 production feature·보안·가용성 계약을 모두 충족한다는 뜻이 아닙니다.

직접 확인하는 방법

사용자·요청 분포, exact 기능, 품질·p95·memory·보안·복구 threshold를 표로 만들고 후보를 보기 전에 승인하십시오.

Runtime은 모든 model file을 교환 가능하게 읽지 않습니다. llama.cpp는 GGUF를 중심으로 하고 MLX LM은 MLX-compatible artifact를 사용하며 Transformers와 vLLM은 지원되는 Hugging Face model·quant 경로를 따릅니다. Ollama package도 실제 base artifact와 template·parameter를 포함합니다. Family 이름이 같아도 precision, tensor layout·metadata와 processor file이 다르면 load path·kernel과 품질이 달라집니다. 후보 표에는 확장자뿐 아니라 source revision과 actual byte·hash를 둡니다.

변환은 새 artifact를 만드는 작업입니다. Safetensors 원본을 GGUF·MLX 또는 runtime-specific quant로 바꿨다면 converter·quantizer version, command·option, calibration과 source·output hash를 연결합니다. Community 변환본은 원본과 recipe가 명확한지 확인합니다. 더 작은 file이 load된다는 사실을 동일 quality나 지원 feature로 해석하지 않고, 원본 baseline과 같은 gold set·runtime log를 다시 실행합니다.

Tokenizer, chat template와 processor가 weight와 짝을 이루는지 확인합니다. Instruct model의 role·BOS/EOS·stop, Vision의 image processor, embedding의 pooling·normalization이 달라지면 같은 화면 문장도 model input과 output이 달라집니다. Runtime이 repository template를 자동 선택한다고 가정하지 않고 model 호출 직전 token·rendered prompt를 저장합니다. Template override를 썼다면 source·이유와 회귀 결과를 manifest에 둡니다.

Custom code와 file security도 runtime 선택에 포함됩니다. Transformers의 remote code, pickle 계열 artifact와 설치 script는 execution boundary를 넓힙니다. 필요한 code를 review하고 virtual environment·container와 최소 권한을 사용하며 허용 file만 offline registry에 보존합니다. Runtime이 remote repository를 자동 update·download하는지 확인하고 production에서는 immutable revision·cache와 network policy로 예상하지 못한 artifact 변경을 막습니다.

왜 이런가

Artifact와 입력 처리 component가 runtime별로 다르면 동일 family라도 실제 계산 graph와 prompt·품질이 달라지기 때문입니다.

언제 문제가 되는가

Weight만 고정하고 tokenizer·template·processor를 섞으면 role·종료·Vision·embedding 결과가 조용히 바뀔 수 있습니다.

초보자가 자주 하는 오해

Model 이름과 quant label이 같으면 GGUF·MLX·Transformers artifact가 bit 단위로 동일하고 모든 runtime에 호환되는 것은 아닙니다.

직접 확인하는 방법

Source→변환 artifact hash와 tokenizer·template·processor revision을 기록하고 runtime 직전 rendered input을 baseline과 대조하십시오.

Ollama 공식 API는 설치 뒤 기본 localhost 주소에서 generate·chat·embed 같은 model 상호작용을 제공합니다. 개인 실험과 desktop app 연결을 빠르게 만들 수 있지만 단순함이 실행 조건을 없애는 것은 아닙니다. Model name·tag, digest와 details, Ollama release, Modelfile의 FROM·TEMPLATE·PARAMETER·SYSTEM과 API request를 보존합니다. `latest` tag만 기록하면 이후 pull에서 다른 artifact를 받아 결과를 재현하지 못할 수 있습니다.

Context 설정은 model architecture maximum과 현재 runtime allocation을 구분합니다. Ollama 공식 문서는 context 증가가 memory 요구를 늘리며 `ollama ps`에서 PROCESSOR와 CONTEXT로 allocated length와 offloading을 확인하도록 안내합니다. 짧은 prompt에서 실행됐다는 이유로 목표 context·동시성도 GPU에서 처리된다고 보지 않습니다. 최장 input에서 system RAM·VRAM peak, processor split, TTFT와 decode를 기록합니다.

Local과 cloud data path를 명확히 합니다. 같은 API 형태가 있어도 localhost model과 remote cloud model은 입력이 이동하는 경계가 다릅니다. App 설정, model URI와 network log로 실제 endpoint를 확인하고 민감 data 정책에 맞춥니다. LAN에서 사용하려고 listen address를 바꾸면 localhost-only 위험 모델이 달라지므로 인증 proxy, TLS, rate limit와 client별 접근을 새 배포로 검토합니다.

Ollama 후보는 실제 client contract와 실패 복구로 승인합니다. Streaming, structured output·tool·Vision·embedding 중 필요한 기능, invalid request·timeout과 model load 중 behavior를 시험합니다. Update 뒤 template·context·backend가 바뀌는지 동일 gold set과 p95를 회귀합니다. 이전 Ollama version·model digest·Modelfile로 돌아가 같은 실패 input이 회복되는지를 확인한 뒤 desktop 또는 team 사용 범위를 정합니다.

왜 이런가

간편한 추상화 아래 artifact·template·context·offload와 endpoint가 결과를 결정하므로 실제 상태를 기록해야 합니다.

언제 문제가 되는가

Tag와 “응답 성공”만 남기면 update 뒤 다른 model·context 또는 CPU offload로 품질·p95가 바뀐 원인을 찾지 못합니다.

초보자가 자주 하는 오해

Ollama가 localhost에서 쉽게 실행된다는 사실은 자동으로 100% GPU, 최대 context·production 보안과 원본 license를 보증하지 않습니다.

직접 확인하는 방법

Exact digest·Modelfile, API request와 `ollama ps`의 PROCESSOR·CONTEXT를 저장하고 최장 workload의 품질·peak·p95를 반복하십시오.

llama.cpp 공식 repository는 GGUF와 CPU, Metal, CUDA·HIP, Vulkan 등 여러 backend, CPU+GPU hybrid inference를 제공합니다. 이 목록은 모든 model architecture·quant·operator와 endpoint가 모든 backend에서 같은 수준으로 지원된다는 보증이 아닙니다. Repository commit, compiler와 build flag, binary·container digest, backend와 runtime log를 고정합니다. Prebuilt binary를 쓸 때도 release asset과 hash·CPU instruction set을 확인합니다.

GGUF metadata에서 architecture, quant, tokenizer와 template를 확인하고 model·mmproj file hash를 기록합니다. Source model에서 직접 변환했다면 recipe를 보존합니다. `-hf` 같은 편의 download는 exact repository·quant 선택과 cache object를 확인해 움직이는 default에 의존하지 않습니다. llama.cpp-compatible community artifact가 official model producer의 원본이라는 뜻은 아니며 license와 provenance는 별도 gate입니다.

Offload는 layer 수 하나로 끝나지 않습니다. Startup log에서 어느 tensor·operator가 CPU·GPU에 배치됐는지, host-device transfer, system RAM·VRAM peak와 context·batch별 변화를 확인합니다. VRAM보다 큰 model을 hybrid로 실행할 수 있어도 link와 CPU bandwidth 때문에 TTFT·decode·p95가 목표를 넘을 수 있습니다. Full GPU와 hybrid, CPU baseline을 같은 workload에서 비교하고 예상하지 않은 fallback을 숨기지 않습니다.

llama-server를 사용하면 API, parallel decoding·continuous batching과 metric 등 운영 기능을 별도 검증합니다. Listen address, authentication·request limit, context sharing과 slot·queue behavior, health·readiness를 확인합니다. CLI 한 사용자 success를 server multi-user 승인으로 옮기지 않고 concurrency 단계별 p95·error와 cancellation을 측정합니다. Update 전 previous binary·preset·GGUF로 rollback해 동일 failure request를 복구합니다.

왜 이런가

llama.cpp는 build·backend·offload와 option의 자유도가 높아 exact 조합을 기록하지 않으면 지원·성능 결과를 재현할 수 없기 때문입니다.

언제 문제가 되는가

GGUF load와 GPU activity만 보면 일부 operator의 CPU fallback, hybrid transfer와 server queue로 인한 p95 병목을 놓칩니다.

초보자가 자주 하는 오해

지원 backend 목록은 모든 model·quant·feature가 그 장치에서 완전히 가속되고 production-ready라는 뜻이 아닙니다.

직접 확인하는 방법

Commit·build flag·binary hash, GGUF metadata·hash와 startup placement를 저장하고 CLI·server workload를 각각 반복 측정하십시오.

MLX LM 공식 repository는 Apple silicon에서 MLX로 text generation, quantization과 LoRA·QLoRA fine-tuning을 수행하는 package입니다. NVIDIA CUDA용 명령과 kernel을 이름만 바꿔 적용하지 않습니다. Exact Mac chip·memory·OS, Python·MLX·MLX LM version, source model과 MLX artifact hash를 기록합니다. Community 변환본은 source revision·quant recipe와 tokenizer·template를 확인하고 원본 baseline과 품질을 비교합니다.

Unified memory는 큰 pool 접근을 편리하게 하지만 OS, application, weight·KV·activation과 workspace가 같은 capacity·bandwidth를 공유합니다. Generate·batch와 fine-tuning의 단계별 peak를 측정하고 memory pressure·swap, Metal execution과 thermal을 확인합니다. 한 prompt generation 성공을 큰 batch·긴 context 또는 LoRA job 완료로 확장하지 않습니다. 같은 Mac에서 llama.cpp Metal과 비교할 때 artifact·prompt 차이를 통제합니다.

MLX LM의 command별 목적을 분리합니다. Chat REPL은 session context와 개인 상호작용, generate는 재현 가능한 prompt 실행, batch는 throughput, fine-tune은 dataset·checkpoint·validation이 핵심입니다. Sampling·seed·template, batch·sequence와 checkpoint recipe를 고정합니다. Training candidate는 inference 품질뿐 아니라 job time, activation peak·disk, resume와 adapter rollback을 별도로 시험합니다.

공식 MLX LM server 문서는 basic security checks만 구현하므로 production에는 권장하지 않는다고 명시합니다. 개발용 localhost API를 편리하게 쓸 수 있지만 LAN·internet에 그대로 공개하지 않습니다. Production 요구가 있으면 authentication·TLS·request limit·observability를 제공하는 별도 supported path를 선택하거나 proxy와 threat model을 검증합니다. “OpenAI 유사” endpoint success를 가용성·보안 승인으로 바꾸지 않습니다.

왜 이런가

MLX LM의 장점은 Apple silicon과 MLX workflow에 묶여 있고 generation·training·server의 운영 조건이 서로 다르기 때문입니다.

언제 문제가 되는가

Mac에서 한 번 생성한 결과로 batch·LoRA와 외부 API를 승인하면 memory pressure, job 장애와 인증 부족을 배포 후 발견합니다.

초보자가 자주 하는 오해

Unified memory가 충분하거나 MLX LM server가 실행되면 모든 CUDA workflow와 production security가 자동으로 제공되는 것은 아닙니다.

직접 확인하는 방법

Exact Mac·MLX artifact·version에서 generation·batch·training을 분리 측정하고 server는 공식 제한과 실제 network·security 경계를 확인하십시오.

Transformers는 다양한 Hugging Face model·tokenizer·processor를 Python·PyTorch에서 다루고 generation·evaluation·training code와 연결하는 데 유연합니다. 이 유연성을 “모든 hardware에서 자동 최적화”로 읽지 않습니다. 공식 설치 문서의 지원 Python·PyTorch 조건, GPU driver와 device 확인을 exact version으로 맞추고 virtual environment·lockfile과 package hash를 보존합니다. Source install과 stable release 결과를 섞지 않습니다.

`from_pretrained`는 repository와 local cache를 연결합니다. Production에서는 exact revision, allowlisted file과 local cache object를 고정하고 offline mode·network policy를 확인합니다. Main branch update가 자동으로 배포 artifact를 바꾸지 않게 합니다. Tokenizer·processor와 config revision을 weight에 맞추고, `trust_remote_code`와 pickle·custom extension은 source review·sandbox와 최소 권한을 거칩니다.

Transformers를 baseline으로 쓰면 원본 precision·architecture와 model output을 세밀하게 관찰할 수 있습니다. Rendered template, token ID, dtype·device map, layer placement와 generation config를 저장합니다. Runtime candidate의 GGUF·MLX·vLLM 결과가 다르면 같은 source·prompt에서 Transformers baseline과 비교해 artifact quant, template와 scheduler 효과를 분리합니다. 다만 baseline 자체도 driver·kernel과 sampling에 따라 달라져 version을 고정해야 합니다.

Python notebook이나 pipeline은 production service가 아닙니다. Multi-user API가 필요하면 queue, async cancellation, authentication·rate limit, health·metric과 process isolation을 제공하는 serving layer를 선택합니다. Research code를 web port에 직접 bind하지 않습니다. Training·evaluation과 serving environment를 분리하되 model·tokenizer·gold set contract를 공유하고, update가 downstream runtime에 미치는 회귀를 자동으로 확인합니다.

왜 이런가

Transformers는 폭넓은 model control을 제공하는 만큼 environment·remote artifact와 device mapping이 결과와 보안에 직접 영향을 주기 때문입니다.

언제 문제가 되는가

Unpinned package·main revision과 remote code를 notebook에서 바로 실행하면 재현 불가, supply-chain 위험과 device fallback을 놓칠 수 있습니다.

초보자가 자주 하는 오해

Transformers pipeline이 한 번 실행되면 해당 script가 곧 multi-user production server이거나 가장 최적화된 runtime이라는 뜻은 아닙니다.

직접 확인하는 방법

Environment lock, exact model·processor revision과 device map·rendered prompt를 저장하고 offline clean environment에서 baseline을 재실행하십시오.

vLLM 공식 문서는 GPU·CPU·TPU installation, supported model과 online serving·pooling·quant·observability 기능을 폭넓게 제공합니다. 그러나 latest 문서의 기능을 내가 배포한 이전 version으로 소급하지 않습니다. Container digest, vLLM·PyTorch·driver, GPU·topology, model·quant artifact와 attention backend를 exact support page에 대조합니다. Nightly·source build와 stable image의 위험·rollback을 구분합니다.

OpenAI-compatible server는 client migration에 유용하지만 실제 endpoint contract를 확인해야 합니다. Chat·responses, streaming chunk, structured output, tool call·reasoning parser, embedding과 usage·error field 중 앱이 쓰는 요청을 고정합니다. Model별 chat template와 parser support가 필요할 수 있고 option이 version별로 달라질 수 있습니다. 예상과 다른 field를 조용히 무시하는지 invalid·boundary request로 시험합니다.

Serving 성능은 scheduler가 여러 sequence를 묶는 상황에서 측정합니다. Concurrency 1, 대표·목표·overload 단계와 실제 input·output length 분포로 request throughput, queue time, TTFT, inter-token latency, p50·p95·p99, peak memory와 error를 봅니다. Continuous batching이 총 token/s를 높여도 긴 request가 짧은 request p95를 악화시키거나 KV cache가 admission을 막을 수 있습니다. Cancellation·timeout 뒤 resource 회수도 확인합니다.

Production에는 authentication, rate limit·quota, load 중 readiness, metric·log privacy와 rolling restart가 필요합니다. OOM·worker crash와 model load failure에서 server가 어떤 status를 내고 request를 재시도해도 안전한지 시험합니다. Distributed execution은 topology·communication과 node failure를 새 변수로 추가합니다. Canary에서 quality·schema·p95·error를 관측하고 previous image·artifact로 traffic을 되돌리는 시간을 측정합니다.

왜 이런가

vLLM의 가치는 동시 request scheduling과 serving 기능에서 나타나므로 실제 client·부하와 운영 실패를 재현해야 선택 근거가 됩니다.

언제 문제가 되는가

Single prompt token/s만 보면 queue·tail latency, unsupported parser·endpoint와 OOM 뒤 worker·request 복구를 놓칩니다.

초보자가 자주 하는 오해

OpenAI-compatible과 high-throughput이라는 설명은 모든 model·quant·client parameter와 production 보안을 자동 보증하지 않습니다.

직접 확인하는 방법

Exact image·support matrix에서 client contract test와 concurrency 단계별 quality·p95·peak·error, canary·rollback을 실행하십시오.

공정 비교를 위해 source model·artifact, tokenizer·template, prompt·output·sampling, context·batch·concurrency와 hardware를 고정합니다. Runtime마다 지원 artifact가 달라 같은 quant를 못 쓰면 source revision과 변환 recipe, byte·quality 차이를 공개하고 공통 Transformers 또는 기존 runtime baseline을 유지합니다. 후보가 가장 잘 나오는 설정만 보여 주지 않고 공통 설정과 tuning 차이를 함께 기록합니다. 최소 3회 반복해 cold·warm과 변동을 분리합니다.

측정표에는 download·load·compile, warm TTFT, prefill·decode, end-to-end와 queue time, request·token throughput을 둡니다. Peak VRAM·RAM, CPU/GPU placement와 transfer, utilization·power·temperature, error·cancel을 연결합니다. 평균 하나 대신 p50·p95·p99와 입력 길이·동시성별 분포를 봅니다. 같은 candidate의 업무 품질·근거·schema와 안전 거절이 사전 threshold를 통과해야 성능 결과를 승인합니다.

실패하면 가장 작은 성공 상태로 돌아갑니다. 짧은 text·동시성 1·기본 precision에서 exact output과 device path를 확인하고 context, batch·concurrency, Vision·tool·schema를 하나씩 추가합니다. Startup·rendered prompt·operator·memory·queue·network 중 증상과 함께 변한 첫 증거를 고릅니다. Model·quant·runtime·driver를 동시에 바꿔 우연히 성공한 조합은 root cause와 재현 recipe가 없으므로 hold입니다.

승격 전 previous runtime image·binary, config·API contract와 artifact를 복원합니다. 새 candidate의 failure input을 이전 backend로 보내 품질·형식·p95가 회복되는지, traffic switch와 cache·in-flight request가 안전한지 시험합니다. Canary 후 전체 전환하고 version·driver·model·업무 변화에 regression trigger를 둡니다. 최종 결론은 브랜드 순위가 아니라 exact workload·stack·날짜의 pass·hold와 limitation입니다.

왜 이런가

Runtime 차이와 artifact·설정 차이를 분리하고 실제 장애에서 복구할 수 있어야 성능 개선이 운영 가치로 이어지기 때문입니다.

언제 문제가 되는가

여러 변수를 동시에 바꾸고 성공값만 남기면 회귀 원인을 찾지 못하고 이전 service로 안전하게 돌아갈 수도 없습니다.

초보자가 자주 하는 오해

한 번의 가장 높은 token/s나 model load 성공이 품질·p95·memory·오류와 production readiness를 대표하지 않습니다.

직접 확인하는 방법

동일 manifest의 정상·경계·실패를 반복하고 작은 기준선 복구, canary와 previous stack rollback을 같은 input으로 재현하십시오.

Localhost에만 bind된 개인 API는 같은 host의 process가 주된 접근자이지만 LAN·internet에 공개하면 신뢰하지 않는 client와 network가 생깁니다. Listen address와 firewall만 바꾸는 것은 기능 변경이 아니라 보안 경계 확대입니다. 누가 어떤 model·document와 tool을 사용할 수 있는지, input·output이 어디를 지나고 저장되는지 data-flow를 그립니다. Ollama·llama-server·MLX server·vLLM의 기본 bind·authentication과 proxy 구성은 exact release 문서와 실제 socket에서 확인합니다.

인증과 권한을 구분합니다. API key가 유효해도 해당 사용자가 특정 model, adapter·RAG 문서와 tool에 접근할 권리가 있는지 server에서 검사해야 합니다. Browser client에 master key를 넣지 않고 짧은 수명·최소 권한 credential과 TLS를 사용합니다. Model 이름을 숨기거나 URL을 어렵게 만드는 것은 접근 통제가 아닙니다. Admin endpoint, model pull·delete와 file tool은 일반 inference route보다 좁은 network·role에 둡니다.

Request 자원을 제한합니다. Input context, output token, image size·개수, batch·동시성, queue·timeout과 사용자별 quota가 없으면 몇 개의 긴 요청이 KV cache·memory를 소진할 수 있습니다. Cancellation 뒤 slot·memory가 회수되는지, overload에 명확한 status를 내고 무한 retry를 유발하지 않는지 시험합니다. Rate limit은 평균 요청 수뿐 아니라 token·memory 비용과 high-priority traffic을 반영합니다.

Log와 metric에는 prompt·document·tool argument, model·adapter와 user identity가 포함될 수 있습니다. 원문 수집을 최소화하고 secret·개인정보를 redact하며 접근·retention과 incident 절차를 둡니다. Debug mode를 production에 상시 켜지 않고 trace sample도 data policy를 따릅니다. Threat model, authentication proxy와 limit을 통과해도 runtime 자체의 vulnerability·dependency update와 rollback을 별도 관리합니다.

왜 이런가

Network 공개는 접근 주체와 공격 표면·resource 경쟁을 바꾸므로 개인 실행의 성공 기준으로 안전을 판단할 수 없기 때문입니다.

언제 문제가 되는가

Bind 주소만 바꾸면 무인증 model·관리 endpoint, 긴 request OOM과 prompt·document log 유출을 동시에 만들 수 있습니다.

초보자가 자주 하는 오해

로컬 model을 사용한다는 사실은 API가 LAN에 공개돼도 data가 안전하고 사용자별 권한이 자동 격리된다는 뜻이 아닙니다.

직접 확인하는 방법

실제 listen socket·proxy·firewall, 사용자별 권한, token·queue limit과 redacted log를 승인 계정·비승인 계정·overload request로 시험하십시오.

Registry 행에는 목적, owner, runtime·binary/container digest, model artifact·template, hardware·driver, client contract와 quality·p95·memory threshold를 둡니다. 개발·canary·production 환경과 traffic 비율, 마지막 평가와 rollback 대상도 연결합니다. “현재 vLLM 사용” 같은 한 줄은 어느 version·model과 설정이 실제 사용자에게 응답하는지 보여 주지 못합니다. Deployment inventory와 metric label이 같은 immutable ID를 사용해야 incident에서 영향을 좁힐 수 있습니다.

관측은 사용자의 request path를 설명해야 합니다. Request rate·queue depth, TTFT·inter-token·end-to-end p50·p95·p99, token throughput, error·cancel과 VRAM·RAM·device placement를 연결합니다. Model quality와 schema failure는 infrastructure metric과 별도 sample로 측정하되 privacy를 지킵니다. Alert threshold는 단순 CPU utilization보다 사전 service level과 error budget에 맞추고, queue 상승·OOM에는 concurrency 제한·작은 model·rollback runbook을 연결합니다.

비용은 runtime license 가격만이 아니라 GPU·CPU 시간, idle·load memory, power·storage·network와 운영 인력을 포함합니다. Single-user에서는 setup·update 시간이, team service에서는 요청당 cost와 spare·availability가 중요합니다. 필수 quality·p95·security를 통과한 후보끼리 비용을 비교하고 실패한 후보가 저렴하다는 이유로 승인하지 않습니다. 측정 날짜·traffic·hardware를 붙여 workload 변화 뒤 다시 계산합니다.

Upgrade는 기존 행을 덮는 작업이 아니라 새 candidate입니다. Release·driver·model·template 또는 feature flag가 바뀌면 official support와 vulnerability notice를 확인하고 동일 회귀·load·failure를 실행해 canary합니다. Retirement 전 client와 artifact dependency, cache·adapter와 rollback retention을 확인하고 traffic 0·접근 차단 뒤 evidence를 보존합니다. 이전 runtime을 너무 일찍 삭제해 canary 실패 시 돌아갈 길을 잃지 않습니다.

왜 이런가

Runtime과 배포 조건은 계속 변하므로 현재 stack·threshold·owner와 재검토 trigger가 없으면 승인 결과가 빠르게 낡기 때문입니다.

언제 문제가 되는가

Latest update로 기존 행을 덮고 이전 image를 지우면 품질·p95 회귀의 범위와 원인을 추적하거나 rollback할 수 없습니다.

초보자가 자주 하는 오해

한 번 production을 통과한 runtime이 모든 새 version·driver·model과 traffic 분포에서 영구 승인되는 것은 아닙니다.

직접 확인하는 방법

Production request ID에서 immutable runtime·model stack과 metric·owner·rollback을 추적하고 update·retirement 절차를 canary failure로 연습하십시오.

학습이 끝나면 weight file 하나가 생긴다고 생각하기 쉽지만 production이 실행하는 것은 여러 artifact의 결합입니다. PEFT adapter는 base weight가 없고 adapter config·exact base가 필요합니다. Merged model은 base와 update를 합친 full weight이고, GGUF는 architecture·tokenizer metadata와 inference tensor를 담습니다. Ollama package는 FROM source·ADAPTER·TEMPLATE·SYSTEM·PARAMETER를 다시 조립합니다. 어느 node를 배포하는지에 따라 runtime·storage·license·rollback이 달라집니다.

Graph의 시작점에는 exact base weight·config·tokenizer·chat template, adapter·dataset/training run이 있습니다. Merge edge는 base+adapter를 merged safetensors로, converter edge는 이를 high-precision GGUF로, quantizer는 Q4·Q5 candidate로 바꿉니다. Package edge는 chosen source와 runtime config를 manifest/blob로 만듭니다. Edge마다 tool commit·dependency, parameter·environment, input/output SHA-256과 raw log·evaluation을 기록합니다.

이 graph가 없으면 model-final.gguf에서 오류가 났을 때 어느 base·adapter·template·quant recipe가 원인인지 알 수 없습니다. Community file 이름이 같은 source model을 적어도 실제 revision·conversion이 다를 수 있습니다. Approved registry는 node digest와 parent digest를 immutable하게 두고 dev·staging·production alias만 검토된 digest로 이동합니다. 동일한 이름에 byte를 덮어쓰지 않습니다.

Artifact owner는 각 node의 intended use·retention·access와 재검토 trigger를 정합니다. Base license·acceptable use, fine-tuning data rights, merge·quant·redistribution 조건과 model card limitation을 연결합니다. 변환 tool이 성공했거나 LICENSE text를 포함했다는 사실은 실제 사용 권리를 승인하지 않습니다. 품질·security·license decision과 build provenance를 독립 evidence로 유지합니다.

왜 이런가

배포 behavior는 weight뿐 아니라 base·tokenizer/template·quant·runtime setting의 결합이며 오류 복구는 이 dependency를 역추적해야 하기 때문입니다.

언제 문제가 되는가

최종 파일만 남기면 source·tool·license와 어느 previous 조합으로 돌아갈지 알 수 없어 재현·incident 대응이 불가능합니다.

초보자가 자주 하는 오해

Adapter, merged safetensors, GGUF와 Ollama package는 확장자만 다른 동일 byte·동일 behavior가 아닙니다.

직접 확인하는 방법

Production digest에서 parent를 따라 exact base·adapter·template·converter·quant·package와 각 평가 report까지 도달하는지 확인하십시오.

Hub 공식 download 안내는 기본 main latest 대신 branch·tag·full commit hash revision을 지정할 수 있고 full-length commit hash를 요구합니다. Release input은 repository ID·type, full commit과 허용 file list로 고정합니다. Version-aware cache path가 반환되지만 cache file을 직접 수정하지 않고 read-only input처럼 다룹니다. Snapshot의 config·tokenizer·weight·model card와 code file inventory를 기록합니다.

SHA-256은 file byte가 manifest의 byte와 같은지 확인합니다. Download 전후·registry upload·node pull과 load 직전에 계산해 partial transfer·corruption·tampering을 찾습니다. 그러나 공격자가 file과 manifest hash를 함께 바꾸면 hash만으로 신뢰를 판단할 수 없습니다. Approved channel, signature·attestation verification과 reviewer policy가 source manifest를 믿을 근거를 보완합니다.

SLSA provenance의 목적은 artifact가 어떻게 만들어졌는지 설명해 consumer가 expected build인지 확인하고 필요하면 rebuild하도록 돕는 것입니다. BuildDefinition의 build type·external parameter·resolved dependency와 RunDetails의 builder·invocation을 model 변환 record에 적용합니다. Converter command, base·adapter digest, quant type·imatrix와 output subject digest가 연결돼야 reviewer가 hidden input을 찾을 수 있습니다.

Provenance가 있다고 build가 안전하거나 model이 정확하다는 뜻은 아닙니다. Builder identity·isolation, parameter completeness와 attestation signature policy를 검증해야 하며 local 수동 run은 재현 한계를 공개합니다. Quality evaluation·license review·malware scan은 별도 gate입니다. Registry UI는 digest·parent·builder·review status와 evidence를 한 화면에 보여 주되 하나의 green badge로 모든 의미를 합치지 않습니다.

왜 이런가

같은 이름을 가진 artifact가 바뀔 수 있고 byte 동일성만으로 생성 과정·승인 주체를 알 수 없기 때문입니다.

언제 문제가 되는가

latest tag와 filename만 배포하면 재시작 때 다른 byte를 받고, hash만 있으면 그 hash가 승인된 build에서 왔는지 증명하지 못합니다.

초보자가 자주 하는 오해

SHA-256 digest가 맞다는 것은 file이 안전·정확·합법하다는 뜻이 아니라 expected byte와 동일하다는 뜻입니다.

직접 확인하는 방법

Full source commit, file digest, signed/approved provenance의 input·builder·parameter와 independent quality·license decision을 각각 확인하십시오.

Pickle은 Python object graph를 복원하는 과정에서 import와 callable 실행이 가능해 arbitrary code execution 위험이 있습니다. Hub pickle security 문서는 scanner가 import를 추출하고 suspicious 항목을 표시하지만 100% foolproof가 아니라고 경고합니다. .bin·.pt·.pth·.pkl처럼 pickle 기반일 수 있는 unknown file은 production identity로 승인하지 않고, 꼭 필요한 legacy conversion은 network·credential 없는 격리 sandbox와 disposable user에서만 수행합니다.

Safetensors 공식 문서는 pickle과 대비해 tensor를 안전하게 저장하는 simple format으로 설명합니다. Code object를 deserialize하지 않는 장점이 있지만 tensor value가 NaN이거나 expected shape와 다르고 file size가 resource를 고갈시킬 수 있습니다. Header size·metadata, key allowlist, dtype·shape·tensor count와 total bytes를 load 전에 검사하고 parser·framework version과 device memory limit을 고정합니다.

Format sniffing은 extension이 아니라 actual magic/header와 parser로 합니다. Safetensors directory에도 config·tokenizer·custom modeling code와 pickle file이 함께 있을 수 있으므로 repository inventory를 검사합니다. trust_remote_code와 executable script는 default deny로 두고 architecture 지원을 official code·version에서 확인합니다. Unexpected file·symbolic link·path traversal과 archive extraction은 quarantine에서 차단합니다.

안전한 load 뒤에도 model behavior evaluation이 필요합니다. Weight backdoor·data leakage와 malicious tokenizer는 tensor format이 막지 못합니다. Golden input, critical·safety·resource set과 provenance·license를 확인합니다. Quarantine→verified input→candidate registry→approved release의 state transition을 기록하고 format scanner 실패 또는 unreviewed dependency가 있으면 자동으로 hold합니다.

왜 이런가

Weight file load는 production process 권한과 큰 memory를 사용하며 unsafe deserialization·resource abuse와 behavior risk가 서로 다른 층에 있기 때문입니다.

언제 문제가 되는가

백신·Hub scanner green만 믿고 pickle을 load하거나 safetensors 이름만 보고 companion code·shape·behavior를 생략하면 보안과 품질 결함이 남습니다.

초보자가 자주 하는 오해

Safetensors는 trusted model 인증서가 아니라 pickle code execution surface를 줄이도록 설계된 tensor data format입니다.

직접 확인하는 방법

Unknown pickle default deny, safetensors header/key/shape/dtype/size 검사, repository inventory와 sandboxed fresh load·behavior evaluation을 확인하십시오.

PEFT checkpoint 공식 문서는 adapter_model.safetensors와 adapter_config.json, README model card를 설명하고 adapter state_dict에 base parameter가 없다고 명시합니다. Adapter config의 base_model_name_or_path와 revision, peft_type·target_modules·rank·alpha·modules_to_save를 training run manifest와 대조합니다. Mutable base name이나 null revision은 exact weight hash로 보완하고 checkpoint key·shape가 actual target report와 맞는지 확인합니다.

Tokenizer·chat template와 special token은 adapter behavior의 dependency입니다. Training에서 vocabulary resize·new embedding 또는 lm_head를 학습했다면 tokenizer files와 modules_to_save weight가 포함돼야 합니다. Raw messages를 same template로 render한 golden token ID와 serving output을 비교합니다. Adapter만 복사하고 tokenizer를 base latest로 바꾸면 load가 돼도 role·target behavior가 깨질 수 있습니다.

Fresh process에서 exact base를 immutable cache/registry에서 load하고 adapter key·missing/unexpected key와 dtype를 검사합니다. Base-only, adapter enabled·disabled와 training reference의 golden logits·generation을 비교합니다. Multiple adapter runtime은 adapter name이 checkpoint identity가 아님을 이해하고 request마다 resolved adapter digest를 log합니다. Worker cache에서 old adapter가 남는지 hot-swap·restart도 시험합니다.

Ollama official import 문서도 ADAPTER의 FROM은 fine-tuning에 사용한 same base여야 하며 그렇지 않으면 erratic result가 날 수 있다고 설명합니다. Supported architecture·adapter format과 quant compatibility를 exact Ollama version에서 확인합니다. Adapter source가 QLoRA라고 해서 모든 runtime import가 지원되는 것은 아니므로 high-precision merge 또는 별도 conversion 후보를 official path·evaluation으로 승인합니다.

왜 이런가

Adapter update의 tensor 위치와 learned behavior는 exact base structure·token sequence에 종속되며 file alone에는 base가 없기 때문입니다.

언제 문제가 되는가

이름이 비슷한 base·latest tokenizer에 붙이면 shape error 또는 조용한 quality drift가 생기고 original training state로 복구할 수 없습니다.

초보자가 자주 하는 오해

adapter_config에 base name이 있거나 load가 성공했다는 사실은 exact revision·template compatibility와 품질 동일성을 보장하지 않습니다.

직접 확인하는 방법

Training base·tokenizer/template digest, adapter config/key와 fresh base-only·enabled·disabled output, runtime resolved digest를 대조하십시오.

PEFT checkpoint 문서는 merge_and_unload로 full model을 저장할 수 있지만 PEFT-specific method, unmerge·multiple adapter·disable 기능을 잃고 모든 method·quant setting이 merge를 지원하지 않는다고 설명합니다. Merge input은 exact high-precision base와 adapter digest이며 device·dtype·merge tool commit을 기록합니다. Already quantized base에 무리하게 merge하거나 community merged file을 parent가 없는 source로 승인하지 않습니다.

Merge 전에 dynamic adapter reference를 freeze합니다. Same base·adapter, tokenizer/template·decoding과 frozen task·critical·general set의 raw output·logit을 보존합니다. Merge output에서는 tensor key·shape·dtype, missing/unexpected, NaN/Inf와 file shard index를 검사하고 SHA-256을 계산합니다. Fresh process에서 full model로 load해 reference와 허용 logit/output difference를 평가합니다.

Merged model은 base weight 전체를 포함하므로 adapter만 배포할 때와 storage·access·redistribution가 달라집니다. Base license, adapter data·license와 derivative distribution 조건을 실제 사용·region·commercial plan에 맞춰 검토합니다. Model card에는 parent digests, merge recipe, evaluation·limitation과 dynamic adapter source를 기록합니다. README metadata가 legal approval을 대신하지 않습니다.

Rollback용 original base·adapter bundle을 보존하고 merge output을 덮어쓰지 않습니다. Merge bug가 발견되면 candidate alias를 내리고 dynamic previous path로 회복한 뒤 exact failure input을 재시험합니다. 다음 GGUF converter는 approved merged digest만 받도록 policy를 두어 rejected merge가 downstream quant·package로 확산되지 않게 합니다.

왜 이런가

Merge는 parameter byte와 runtime 기능, 배포 권리를 바꾸며 뒤의 모든 conversion source가 되므로 독립 release 경계가 필요하기 때문입니다.

언제 문제가 되는가

Merge 성공만 보고 source를 삭제하면 품질 drift·license 문제에서 dynamic reference를 비교하거나 unmerge·재build할 수 없습니다.

초보자가 자주 하는 오해

Merge는 adapter file을 압축하는 작업이나 모든 PEFT method에서 완전히 reversible한 metadata 변경이 아닙니다.

직접 확인하는 방법

Pinned base+adapter reference와 merged fresh load의 tensor·logit·업무·critical·license를 비교하고 original bundle rollback을 시험하십시오.

GGUF 명세는 magic/version header, key-value metadata, tensor info와 aligned tensor data 구조를 정의합니다. general.architecture·quantization_version·alignment와 model name·version·basename 같은 standardized key가 있습니다. Official info/parser로 header·tensor count·offset·type와 required architecture keys를 검사합니다. Unknown key가 있다고 모두 reject하지 않되 required 값 누락·unsupported version과 invalid offset은 hold합니다.

Pinned llama.cpp converter commit과 Python dependency로 approved safetensors/config/tokenizer digest를 high-precision GGUF로 만듭니다. Command·environment·stdout/stderr, shard·special vocabulary 처리와 output hash를 build provenance에 둡니다. Custom architecture warning, missing pretokenizer·chat template와 tensor mapping mismatch를 무시하지 않습니다. Source file을 직접 수정하거나 converter output을 manual hex patch하지 않습니다.

Conversion reference는 가능한 BF16/F16 GGUF입니다. Source Transformers/PEFT merged model과 GGUF high-precision을 same rendered token·decoding에서 비교해 vocabulary·rope·architecture mapping, logits와 frozen task·critical output을 검증합니다. 이 단계에서 실패하면 quant type을 바꾸지 말고 converter·metadata·source 원인을 고칩니다. Conversion을 통과한 digest만 quantizer input이 됩니다.

GGUF에 template metadata가 있어도 target runtime이 어떤 precedence와 fallback을 쓰는지 확인합니다. Runtime command·context·sampling와 backend commit을 고정하고 actual prompt dump 또는 token ID를 reference와 비교합니다. Vision·embedding·MoE 등 companion file·architecture-specific metadata가 필요한 경우 parent graph에 포함합니다. File load와 한 prompt success는 full feature compatibility가 아닙니다.

왜 이런가

Converter가 tensor·tokenizer·architecture metadata를 잘못 mapping하면 quantization 전부터 behavior가 달라지고 이후 모든 후보에 결함이 복제되기 때문입니다.

언제 문제가 되는가

Q4 결과만 source와 비교하면 conversion mapping 오류와 quantization loss를 분리하지 못해 잘못된 knob를 조정합니다.

초보자가 자주 하는 오해

.gguf extension과 runtime load 성공은 source architecture·tokenizer/template·tensor가 정확히 보존됐다는 증거가 아닙니다.

직접 확인하는 방법

High-precision GGUF의 header·metadata·tensor inventory와 source 대비 golden token·logit·업무 평가를 먼저 통과시키십시오.

llama.cpp quantize 공식 문서는 high-quality GGUF input을 llama-quantize로 Q4_K_M 같은 output으로 만들고 quantization이 size·inference speed를 바꾸지만 accuracy loss를 도입할 수 있다고 설명합니다. Tool commit, input digest, quant type, thread·imatrix digest, include/exclude·tensor override와 output hash를 기록합니다. Community filename의 Q4_K_M 문자열만으로 source precision·recipe와 tool version을 추측하지 않습니다.

이미 quantized tensor를 다시 quantize하면 16/32-bit source에서 직접 만들 때보다 품질이 크게 낮을 수 있다는 공식 warning이 있습니다. Parent graph가 high-precision source까지 이어지지 않거나 `--allow-requantize`가 사용됐다면 명시적 exception review가 필요합니다. 이전 Q5에서 Q4를 만들지 않고 approved F16/BF16 GGUF에서 Q4·Q5를 각각 독립 생성합니다.

Evaluation은 file parse·model load, golden token/template, task·critical·general·long context와 resource로 나눕니다. High-precision reference와 같은 prompt·decoding·runtime에서 raw output을 비교하고 allowed quality drop, minimum schema·critical과 memory saving을 결과 전에 정합니다. Target hardware에서 peak memory, first token·prompt processing·generation rate, p50·p95와 warm/cold를 반복합니다.

가장 작은 후보가 아니라 모든 must-pass gate를 통과하며 운영 목표를 만족하는 artifact를 선택합니다. Q4가 memory는 줄지만 critical JSON을 실패하고 Q5가 memory·p95와 quality를 모두 통과하면 Q5가 승인 candidate입니다. Imatrix를 쓰면 representative source·rights·hash와 leakage를 기록합니다. Quantizer 또는 runtime 변경 시 같은 frozen set을 재평가합니다.

왜 이런가

Quantization은 irreversible precision 변경이며 source·recipe와 tensor별 설정이 품질·memory·kernel behavior를 바꾸기 때문입니다.

언제 문제가 되는가

Filename과 size만 보면 requantized artifact나 다른 imatrix·converter를 같은 Q4로 오인하고 critical 회귀를 배포합니다.

초보자가 자주 하는 오해

같은 Q4_K_M 이름이면 모든 model·tool version에서 같은 byte·품질·속도가 나오는 것이 아닙니다.

직접 확인하는 방법

Approved high-precision parent, pinned quant command와 output digest, reference 대비 업무·critical·memory·p95를 target hardware에서 확인하십시오.

Ollama Modelfile reference는 FROM을 required base instruction으로 정의하고 supported safetensors directory나 GGUF file을 지정할 수 있으며 ADAPTER, TEMPLATE, SYSTEM, PARAMETER와 LICENSE를 제공합니다. Import 문서는 safetensors·GGUF adapter가 fine-tuning에 사용한 same base를 FROM으로 써야 한다고 경고합니다. Ollama version별 supported architecture와 quant·adapter path를 release 전에 확인합니다.

TEMPLATE은 role·content를 actual control token으로 serialize하고 stop parameter는 generation termination을 바꿉니다. Training/reference의 golden conversations를 Ollama prompt와 token dump로 비교합니다. SYSTEM·MESSAGE를 새로 넣으면 behavior가 달라지므로 convenience metadata가 아니라 별도 prompt candidate로 평가합니다. num_ctx, temperature·top_k 등 default와 request override policy를 manifest에 고정합니다.

LICENSE instruction은 사용된 model의 license text를 package에 담는 기능이지 lawyer·owner review를 대신하지 않습니다. Base·adapter·dataset·merge·quant와 model card의 intended/out-of-scope use를 release decision에 연결합니다. Public push는 별도 external publication 권한이 필요한 state change이며 local package 검증만으로 자동 수행하지 않습니다.

Create 후 actual Modelfile·manifest와 blob digest를 export해 intended source digest·template·parameter와 대조합니다. Clean host에서 build·pull·run을 반복하고 package name/tag가 아니라 resolved digest를 log합니다. Registry alias가 candidate digest를 가리키더라도 worker cache가 old blob을 쓰는지 restart·eviction과 same failure input으로 확인합니다.

왜 이런가

Ollama package는 weight와 prompt serialization·generation default를 결합하므로 upstream GGUF만 통과해도 최종 behavior가 달라질 수 있기 때문입니다.

언제 문제가 되는가

Create success와 package name만 보면 wrong base adapter, template·stop mismatch와 mutable tag drift를 production에서 발견합니다.

초보자가 자주 하는 오해

Modelfile LICENSE나 SYSTEM 한 줄은 실제 재배포 권리·quality 승인 또는 training template와의 동일성을 자동 만들지 않습니다.

직접 확인하는 방법

Resolved FROM/ADAPTER digest, golden TEMPLATE·stop·parameter, license decision과 clean build·actual worker digest를 확인하십시오.

Registry state는 quarantine, verified-input, candidate, approved, revoked처럼 구분합니다. Candidate record에는 digest·size·format, parent graph, build provenance, file inventory·scanner, license decision, evaluation·limitation, owner·review date와 supported runtime을 둡니다. Artifact upload가 끝났다고 approved alias를 자동 이동하지 않습니다. 모든 independent gate와 승인자가 확인한 뒤 atomic promotion하고 audit log를 남깁니다.

Offline release set에서 base/dynamic adapter, merged, high-precision GGUF, quant와 package를 같은 template·decoding·runtime으로 비교합니다. Format·identity, task·critical·general, p95·memory와 fresh load를 edge마다 통과합니다. Build를 최소 여러 번 재생해 expected deterministic digest 또는 허용된 metadata difference를 설명합니다. Corrupt download·digest mismatch와 missing tokenizer를 negative test로 둡니다.

Limited canary는 actual production endpoint가 expected blob·template·parameter를 쓰는지, schema·critical incident, human correction·p95·memory와 load error를 관측합니다. Canary traffic·time만 채우지 않고 사전 stop condition을 적용합니다. Unexpected digest·license expiry, source revocation, runtime CVE·model defect와 template change를 재검토 trigger로 등록합니다.

Rollback은 alias 한 줄이 아니라 previous compatible base/adapter 또는 merged·GGUF, tokenizer/template, Modelfile parameter와 runtime config·cache를 복구하는 procedure입니다. Candidate failure input과 정상 regression set이 target recovery time 안에 회복되는지 최소 여러 번 시험합니다. Revoked digest가 worker·cache·download mirror에 남지 않았는지 inventory하고 incident root cause·영향 downstream node·재build 결정을 evidence에 남깁니다.

왜 이런가

Artifact 결함은 registry·cache·worker에 퍼지며 단일 file 교체로 compatible behavior가 회복되지 않을 수 있기 때문입니다.

언제 문제가 되는가

Previous GGUF만 보관하고 template·runtime·adapter graph를 잃으면 rollback 뒤에도 같은 오류가 남거나 새로운 incompatibility가 생깁니다.

초보자가 자주 하는 오해

Immutable registry와 canary가 있으면 quality·license review나 실제 rollback drill 없이 자동으로 안전한 release가 되는 것은 아닙니다.

직접 확인하는 방법

Approved record의 모든 gate, actual worker digest와 previous full graph rollback에서 failure·normal set과 recovery time을 반복 확인하십시오.