Llama Open-weight Model-family Operating Profile

Llamaを法人運用する際は、「Llama」というブランド名、特定世代のweight、第三者がhostするLlama API、self-host runtime、fine-tune/quantized derivativeを同一の製品面として扱わない。Llamaは公開weightへアクセスできるmodel familyだが、Llama 4はApache/MIT系の一般的なOSS licenseではなくLlama 4 Community LicenseとAcceptable Use Policyが適用される。deployment ownerはexact model/revision、license、runtime、data path、safety controlを固定して運用する必要がある。

Metaの公式Llama 4 model cardは、Llama 4 ScoutとLlama 4 Maverickを別artifactとして示す。Scoutは17B activated / 109B total、16 experts、10M context、Maverickは17B activated / 400B total、128 experts、1M contextで、いずれもtext/image inputを扱うnative multimodal MoEである。したがって同じ「Llama 4」でもarchitecture、resource requirement、context上限、配布artifactは一致しない。

台帳には family / variant / base-or-instruct / exact repository / revision-or-commit / weight hash / tokenizer / chat template / precision-or-quantization / runtime を保存する。「Llama 4を利用」の一行だけでは再現性・license・capacity・評価条件を確定できない。

公式model cardはLlama 4をstatic model trained on an offline datasetとし、knowledge cutoffをAugust 2024とする。一方、第三者hosted serviceは独自のserving stack、system layer、safety filter、alias、更新周期を持ち得るため、static weightであることをservice全体のimmutabilityへ外挿しない。

Llama 4 Community License Agreementはuse、reproduction、distribution、modification等の権利を付与する一方、再配布時のlicense同梱、Built with Llama表示、Notice保持等の条件を持つ。Llama Materialsまたはそのoutput/resultを用いて別AI modelを作成・改善し、それを配布する場合の命名条件も規定する。

さらにrelease時点の前月に7億MAUを超える製品・サービスを提供するlicenseeには追加commercial termがある。したがってweightをdownloadできることを「用途制限のないOSS」と表現しない。利用主体、配布形態、MAU条件、Acceptable Use Policyをlicense reviewの入力にする。

licenseとuse policyは世代・artifact単位で確認する。Llama 3.xの条件をLlama 4へ、Llama 4の条件を将来世代へ横滑りさせない。exact artifactに付随するLICENSE/USE_POLICYを保存し、更新時に再確認する。

open weightを自社環境へ配置すると、hosted API providerが担うserving、capacity、patch、request filtering、logging、rollback等をdeployment ownerが担う。最低限、runtime/container digest、accelerator、parallelism、KV cache、quantization、tokenizer/chat template、generation defaults、tool parser、network egress、observabilityをversioned deployment manifestへ固定する。

Meta公式model cardのcontext lengthはartifact capabilityの上限情報であり、自社workloadでその長さまで品質が一定である保証ではない。long-context retrieval、instruction retention、latency、memory、throughputを自社golden setで測る。特にScoutの10M contextを「10M tokensで業務精度保証」と解釈しない。

公式model cardはimage understandingについて5 input imagesまでtestしたと明記し、それを超える利用では追加testing/tuningをdeployment側へ求めている。multimodal上限も単なるmodel-card数値ではなく、自社の画像枚数・解像度・prompt構成でfixture化する。

cloud/API vendorがLlamaをhostしている場合、Metaのweight identityだけでservice behaviorを決めない。vendor側のquantization、serving stack、system prompt、safety filter、tool protocol、context/output cap、region、retention、SLA、rate limit、model aliasが追加されるため、MODEL_ARTIFACT と HOSTING_SERVICE を別IDで管理する。

同じLlama variantを複数providerで使ってもbehavioral equivalenceを仮定しない。providerごとにrequest/response schema、structured output、tool calling、streaming、latency、cost、data governanceをcontract testする。providerがexact upstream revisionを開示しない場合はUNKNOWNとして保持する。

fine-tune、LoRA merge、distillation、quantization、conversionは新しいdeployment artifactとして扱う。親weight名だけを残さず、derivative hash、recipe、training data provenance、license/attribution、evaluation resultを紐付ける。

Metaの公式model cardはquantized checkpointを提供する一方、掲載benchmark/evaluationはbf16 modelで実施したと明記している。したがって公開benchmarkをquantized deploymentへそのまま移植しない。BF16/FP8/INT8/INT4等を変更した場合は、reasoning、multilingual、vision、structured output、tool selectionを含む主要golden setを再実行する。

Acceptable Use Policyは用途制限を規定するが、policy文書の存在はself-host deployment時のenforcementを意味しない。self-hostではinput/output moderation、authorization、rate limit、abuse monitoring、incident responseを自社systemとして実装する必要がある。

model cardの安全評価はrelease判断の一次資料だが、自社prompt、fine-tune、tool access、retrieval corpus、locale、user populationに対する安全性保証ではない。tool-enabled agentに組み込む場合はmodel outputをuntrusted proposalとして扱い、side effect前にpermission、argument validation、policy check、readbackを置く。

self-hostはinference inputをMeta-hosted inferenceへ送信せずに構成できるが、「Llamaだから完全offline」とは限らない。weight/model hub取得、container registry、package manager、telemetry、remote logging、monitoring、external tools、vector store等のegressをinventory化する。

第三者hosted Llamaでは、そのhosting providerの契約・DPA・region・retention・subprocessorがdata boundaryを決める。Metaのmodel licenseとhosting providerのdata-processing termsを混同しない。

• model family/variantとhosting surfaceを別IDで登録する。
• exact weight repository/revision/hashと、そのartifactのLICENSE/USE_POLICYを保存する。
• tokenizer、chat template、runtime/container、hardware、precision/quantizationをdeployment manifestへ固定する。
• derivativeは親artifactとは別artifact IDにし、recipe/hash/evaluationを残す。
• context上限を品質保証にせず、実利用長でlong-context fixtureを実行する。
• multimodal、tool use、structured output等はruntime/providerごとにcontract testする。
• license reviewではdistribution、MAU threshold、attribution、acceptable-use条件を確認する。
• self-host safety controlとthird-party hosted service controlを別々に監査する。
• model/runtime更新時はquality、safety、latency、capacity、costを再評価しrollback可能にする。
• model card benchmarkを自社acceptance evidenceへ直接転用せず、自社golden setを保持する。

「open weight」は「OSI準拠open source」「用途制限なし」「Metaのサービスを利用しない」「安全機構込み」を意味しない。Llama 4は独自Community LicenseとAcceptable Use Policyを持つ。

同じLlama 4 familyでもScoutとMaverickはtotal parameter、expert構成、context上限が異なる。family名だけでcapacity planningや品質比較を行えない。

公開benchmark、安全評価、最大contextは特定条件の測定であり、自社のruntime、quantization、prompt、language、tool、traffic条件での性能を保証しない。特に公式model cardのbenchmarkはbf16評価であり、量子化checkpointの同等性を直接証明しない。

• 自組織・配布形態に対するLlama 4 license条項の具体的法的適用。
• 将来のLlama generationでのlicense/use-policy変更。
• third-party hosted Llamaが用いるexact upstream weight revisionと独自post-training/quantization。
• self-host runtimeごとのmultimodal/tool/structured-output互換差。
• Scout 10M contextでの業務別retrieval/instruction-retention degradation。
• derivative modelのlicense attributionと再配布条件の個別適用。
• model hub/container/telemetryを含む実deploymentの完全なegress boundary。

「Llamaはオープンソースなので自由に使える」「Llama 4なら10M context」「self-hostすれば自動的にデータは外へ出ない」と一般化しない。

「Llamaは公開weightを利用できるmodel familyで、世代・variantごとにartifact、capability、license/use policyが異なる。2026年10月20日時点のLlama 4ではScoutとMaverickを区別し、Llama 4 Community LicenseとAcceptable Use Policyをexact artifactに対して確認し、self-host/third-party hostごとにruntime・data boundary・safety controlを別管理する」と記述する。

• Meta, meta-llama/llama-models, Llama 4 Model Card, accessed 2026-10-20: https://github.com/meta-llama/llama-models/blob/main/models/llama4/MODEL_CARD.md
• Meta, Llama 4 Community License Agreement, effective 2025-04-05, accessed 2026-10-20: https://github.com/meta-llama/llama-models/blob/main/models/llama4/LICENSE
• Meta, Llama 4 Scout official model repository/model card, accessed 2026-10-20: https://huggingface.co/meta-llama/Llama-4-Scout-17B-16E-Instruct
• Hugging Face Transformers, Llama 4 integration documentation, accessed 2026-10-20: https://github.com/huggingface/transformers/blob/main/docs/source/en/model_doc/llama4.md

EA-1213はLlama model assetのweight/revision/license/deployment/evaluationを扱う。LlamaIndex等のapplication framework、llama.cpp等のgeneric runtime、provider横断routing、一般的open-weight governanceは別EAの共通論点である。