中文优化：榜单分数不如你的“语感”测试
Llama 4的原生中文能力还是短板。社区里跑得最快的是“Linly-Llama-4-70B”和“OpenChinese-Llama-4”。Linly由香港中文大学团队主导，用约200B高质量中文语料做了全参数继续预训练；OpenChinese走轻量化SFT路线，目标是快速提升对话流畅度。
我们测试发现，Linly在古文翻译、长文档摘要上确实强，但客服对话、电商描述等口语化场景，有时会输出过度书面化的表达。OpenChinese口语更自然，但处理超过2万字长上下文时，中间段落的信息召回率会下降。
选哪个？ 法律文书、学术论文处理，优先考虑Linly；做客服、内容营销，OpenChinese的SFT版本可能更省事。务必用你自己的业务数据做小范围测试，公开榜单（如MMLU、C-Eval）测不出你的业务“语感”。
端侧部署：别被70B忽悠，7B才是实战区
另一大类分支目标明确：把Llama 4塞进手机、工控机甚至汽车座舱。活跃的如“Llama-4-Mobile-7B”、“EdgeLlama-4-8B”，普遍采用“蒸馏+量化+稀疏化”的组合拳。
以Llama-4-Mobile-7B为例，它先从70B蒸馏出7B基座，用AWQ量化到4bit，在骁龙8 Gen 4芯片上实现了每秒15-18 tokens的生成速度，已能支撑实时对话。
但有个坑：量化损失不均匀。我们实测，在数学推理和代码生成上，4bit版本比FP16原版性能衰减约35-40%；在角色扮演、故事续写等创意任务上，衰减不到15%。如果你做逻辑密集型任务（如财务分析），端侧Llama 4可能达不到生产要求。
硬参考： 目前在主流安卓旗舰（如小米15 Ultra、vivo X200 Pro）上能跑顺的，基本都是7B-8B的4bit版本。更大尺寸或更激进的2bit量化，目前更适合做Demo。
安全对齐：Meta不管的，社区在“补课”
Llama 4基座许可证宽松，企业自由度高，但安全责任也甩给了使用者。社区分支“SafeLlama-4”和“Constitutional-Llama-4”就在做对齐增强。
SafeLlama-4做法直接：在RLHF阶段加入更多中文敏感话题（如医疗建议、金融预测）的拒绝指令训练，内部安全测试集的拒绝率从原版的62%提升到89%。但副作用是“过于谨慎”，连一些正常商业咨询也可能拒绝。
Constitutional-Llama-4更复杂，尝试实现类似Claude 4.0白皮书中的“系统级对齐”，通过构建可动态调整的宪法原则来约束模型。理论上更灵活，但部署调优门槛高，目前主要是大型企业在内部试验。
合规提示： 如果产品面向欧盟市场，选分支前务必核对它是否满足《AI法案》8月2日生效的高风险条款。国内《AI应用伦理安全指引1.0》也已落地，模型选型必须把可审计、可干预作为硬指标。
选型之前，先问这五个问题
- 我的核心场景，需要多强的中文“语感”？ 去看分支的微调数据说明书，而不是宣传语。
- 我最终要在什么硬件上跑？ 如果是手机/边缘设备，立刻放弃70B幻想，直奔7B的量化分支，并在你的目标芯片上实测 tokens/s。
- 我的行业有什么数据合规红线？ 医疗、金融、教育，必须考虑带有安全增强的分支，哪怕性能打点折扣。
- 这个分支的社区还活着吗？ 看GitHub的最近提交时间和Issue回复情况。一个超过三周没更新的分支，基本可以判死刑。
- 我有没有能力自己做二次校准？ 没有的话，优先选择那些提供了详细适配指南和验证数据集的分支，而不是性能指标最炫的那个。
一个务实的选择策略是：在Linly和OpenChinese中根据语感选基座，在EdgeLlama和MobileLlama中根据芯片选量化方案，最后叠加SafeLlama的安全层做微调。 别指望一个分支解决所有问题，组合才是常态。
选错分支的隐性成本，可能比你想的高
分支选型失误的代价，不只是性能不达标。我们访谈的一个电商团队，最初为了追求“最强中文能力”，选了一个需要8张A100才能跑的70B分支做商品描述生成。结果，每月仅GPU租金就超过3万元，生成速度慢（12秒/条），还得额外花钱用另一个快速模型做初筛。
后来他们换成了一个8B的量化中文分支，部署在2张国产推理卡上，成本降到每月8000元以内，速度提升到2秒/条。总拥有成本（TCO）直接打了三折。
另一个隐藏大坑是数据合规。 一个团队使用了某个声称“完全合规”的社区分支，上线后被审计发现，其训练数据中混入了未授权的版权内容，被迫下架整改，损失远超技术成本。所以，务必确认分支提供方公开了数据来源构成。
显性的模型调用费只是冰山一角，数据维护、合规审核、流程改造才是大头。选分支，就是选未来的总账单。
社区给了选择，也给了责任
Llama 4的爆发式分叉，是开源生态活力的证明。它给了开发者前所未有的选择权，但也将选型的技术判断和责任，实实在在压在了每个开发团队肩上。
没有“最好”的分支，只有“最合适”的组合。明确你的业务场景、硬件约束和合规底线，然后像调试代码一样，去实测、去组合、去迭代。
