开源模型与本地推理部署

• 理解开源模型选型的多维考量
• 理解许可证、显存、质量、生态的权衡
• 能建立选型评估

选型维度：许可证——审查各模型的商用许可（DeepSeek 宽松、Qwen Apache 2.0、Llama 有 Meta 商用条款含用户规模限制），决定能否商用及规模上限；显存预算——模型参数量 × 精度（FP16/INT8/INT4）决定单卡/多卡需求，大模型需多卡（TP/PP）或量化；输出质量与运行成本——各模型在推理/代码/中文/多模态上的质量差异，结合吞吐（token/s）与每 token 成本评估；生态工具链——是否支持 vLLM/SGLang、OpenAI 兼容接口、Function Calling、结构化输出、第三方库集成；运维门槛——显存、并发、扩展、监控、升级的复杂度。方法：按"许可证合规 + 显存匹配 + 质量/成本评估 + 生态适配 + 运维能力"综合打分，结合业务对数据驻留、性能、成本的要求选型。

开源模型选型不是"哪个最强"，而是"许可证合规 + 显存可行 + 质量成本达标 + 生态可用 + 运维得起"的综合权衡。每个维度都要按业务实际排查。

• 理解 TCO 的构成（固定 + 可变）
• 理解自建 vs API 的盈亏平衡
• 能建立对比模型

TCO 构成：商业 API 成本 = 每 token 单价 × 用量（可变，无固定）；自建成本 = 硬件（GPU/服务器）一次性 + 电费/折旧/运维（人力）/带宽 + 停机扩容等（固定为主 + 部分可变）。对比模型：计算自建的"固定成本 + 单位可变成本"与 API 的"单位可变成本"，在"单位成本 = 总成本 / 总 token 量"上找盈亏平衡点——流量越大，自建的固定成本分摊越薄，单位成本越低，越划算；流量小，自建固定成本高，API 划算。经验：高稳定、大体量、长期（如持续高 QPS、大规模批处理）自建划算；低流量、波动大、起步期 API 划算。还要考虑：GPU 利用率（自建要跑满才划算）、数据驻留合规（有时必须自建）。核心是"按总成本 / 总 token 量找盈亏平衡点，高流量且稳定自建划算，低流量 API 划算"。

自建是"高固定成本 + 低单位成本"，API 是"零固定 + 高单位成本"。流量越大自建优势越明显，但需考虑 GPU 利用率与合规，不能只看单价。

• 理解 Ollama/llama.cpp 的适用场景
• 理解生产化的差距
• 能判断迁移时机

定位：Ollama/llama.cpp 适合开发与原型验证、单机/边缘/个人场景——开箱即用、模型管理简单、支持量化（GGUF）、低显存环境可用，用于快速验证模型效果与本地调试。生产化差距：一是并发与吞吐——Ollama 简单但并发吞吐、批处理、队列管理弱于 vLLM/SGLang 等生产推理框架；二是高可用与扩展——原生不提供多实例、负载均衡、自动扩缩容；三是可观测性——TTFT/TPOT/GPU 指标、监控告警不完整；四是治理——版本管理、灰度、权限、审计弱；五是稳定性——长稳运行、故障恢复、资源隔离不足。迁移：从 Ollama 完成的原型到生产，通常要迁移到 vLLM/SGLang/TGI 等生产框架，或在 Ollama 基础上补全网关、监控、HA。核心是"Ollama 适合开发/边缘，生产化需补并发、HA、可观测、治理能力或迁移到生产框架"。

Ollama 的价值是"快速上手"，差距在"生产级吞吐、HA、可观测、治理"。理解差距才能判断何时该迁移到生产框架，避免把开发工具当生产用。

• 理解常见许可证的差异
• 理解商用限制条款
• 能设计许可证审查流程

常见许可证：Apache 2.0——宽松，允许商用、修改、分发（需保留声明）；MIT——极宽松，几乎无限制；Llama 使用条款——Meta 自定义，允许商用但有限制（如月活超 7 亿用户需申请许可，且禁止用于特定用途）。审查要点：一是商用许可——是否允许商用、有无规模上限（如 Meta 用户规模条款）、有无用途限制；二是分发/修改——是否允许再分发、是否要求衍生作品开源、是否保留署名；三是专利/商标——有无专利授权、商标使用限制；四是训练数据——是否允许用输出训练其他模型（部分条款禁止）；五是合规——是否符合当地监管（数据、出口）。流程：建立"许可证清单"逐条核对，高风险条款（商用限制、用途限制）需法务确认，并引入"许可证合规门禁"（发布前校验）。核心是"逐条审查商用许可、规模上限、用途限制、分发与训练条款，并设合规门禁"。

开源不等于免费商用。Apache/MIT 宽松，Llama 有规模与用途限制。审查要把"商用上限、用途限制、分发、训练"逐条核对，配合法务与门禁。

• 理解各框架的吞吐特性
• 理解显存占用差异
• 能按场景选框架

vLLM——高性能生产框架，核心是 PagedAttention（KV Cache 分页管理）与 continuous batching，吞吐高、显存利用率高，适合高并发在线服务；SGLang——类似 vLLM 但支持 RadixAttention（前缀 KV 复用，对共享前缀/多轮性能外，结构化输出优化好），吞吐高，适合前缀复用多的场景；llama.cpp——轻量、单机/边缘友好，GGUF 量化、CPU/low 显存可跑，但吞吐与并发生产级能力弱于 vLLM/SGLang。差异总结：vLLM/SGLang 面向高吞吐生产（GPU、continuous batching、显存优化），llama.cpp 面向轻量/边缘/低显存。选择：高并发在线服务用 vLLM/SGLang；前缀复用多/结构化输出多用 SGLang；边缘/个人/低显存用 llama.cpp。核心是"按吞吐需求与显存预算选框架，生产高并发用 vLLM/SGLang，边缘轻量用 llama.cpp"。

框架差异的核心是"吞吐优化机制"与"显存策略"。vLLM 的 PagedAttention、SGLang 的 RadixAttention、llama.cpp 的 GGUF 轻量，分别对应不同场景。

• 理解离线分发流程
• 理解完整性校验
• 能设计私有 registry 部署

流程：一是获取——在能联网的环境用 Hugging Face 镜像（hf-mirror）或官方源下载模型权重与 tokenizer；二是完整性校验——对模型文件计算 sha256 并与官方公布值比对，必要时用签名验证链，防止被篡改/损坏；三是私有 registry——把校验通过的模型文件上传到内网私有 registry（如 Hugging Face 企业版、OSS、自建模型仓库），记录版本与校验值；四是隔离网络部署——推理服务从内网 registry 拉取模型，不依赖外网；五是版本管理——registry 记录模型版本、tokenizer、框架版本，支持回滚与审计。核心是"外网取 -> 校验 -> 入私有 registry -> 内网拉取，全程版本管理 + 完整性保证"。

离线部署的关键是"一次获取、校验、入私有仓库、内网分发"。完整性校验（sha256/签名）防篡改，私有 registry 保版本与可追溯。

• 理解显存与吞吐的推算
• 理解并发与卡数关系
• 能设计弹性扩容

显存推算：权重显存 = 参数量 × 精度字节（如 70B FP16 ≈ 140GB）+ KV Cache 显存（≈ 并发 × 上下文长度 × 每 token 的 KV 大小）+ 激活/临时显存。卡数推算：先算单卡吞吐（token/s，与并发/批大小相关），再按"目标 QPS × 每请求 token 数"算总吞吐，除以单卡吞吐得卡数；并发要求与卡数、连续分批相关。公式：所需显存 ≈ 模型显存 + KV 显存 + 余量；所需卡数 = max(显存需求 / 单卡显存, 吞吐需求 / 单卡吞吐)。弹性扩容：按 GPU 利用率/队列深度/延迟指标作为扩缩容信号，用 K8s + 自动扩缩容（HPA 按 util 或自定义指标），扩容时预热模型（加载权重），缩容时排空流量。核心是"显存按权重+KV+余量算，卡数按吞吐需求算，弹性按利用率/队列/延迟信号自动扩缩容"。

容量规划要"显存（能否放得下）+ 吞吐（是否够快）"双约束。弹性扩容用"利用率/队列深度/延迟"做信号，并处理模型加载预热与排空。

• 理解量化精度与显存/吞吐的关系
• 理解量化误差与质量
• 理解长上下文误差放大

精度影响：FP16 全精度，显存高、质量最好；INT8 显存减半、质量损失小；INT4 显存最低、吞吐高但质量损失更大。AWQ/GPTQ 是逐层/敏感度感知的量化方法（离线校准，尽量保护重要权重），质量优于简单 INT4；GGUF 是 llama.cpp 的量化格式（含多种精度），适合边缘/低显存。权衡：量化越低显存越小、吞吐越高，但质量下降，且"量化误差在长上下文下放大"——长序列时 KV Cache 与激活累积误差，导致输出质量更快劣化、幻觉/退化增加。策略：对质量敏感任务用高精度（FP16/INT8），对长上下文任务谨慎用 INT4；对显存受限场景用 AWQ/GPTQ 等感知量化而非裸量化。核心是"量化权衡显存/吞吐/质量，长上下文下误差放大，需按任务与上下文长度选精度"。

量化是"显存/吞吐 vs 质量"的权衡。感知量化（AWQ/GPTQ）优于裸 INT4，但长上下文会累积误差。选择要结合任务质量敏感度与上下文长度。

• 理解 TTFT/TPOT 等指标
• 理解测量与优化
• 理解并发与 GPU 利用率

指标：TTFT（Time To First Token）——从请求到首 token 的延迟，受 prefill 与排队影响；TPOT（Time Per Output Token）——每个输出 token 的平均生成时间，受 decode 与批大小影响；总延迟 ≈ TTFT + TPOT × 输出长度。测量：在服务端按请求记录 TTFT/TPOT/总延迟，分位数（p50/p95/p99）统计。优化：TTFT 通过减少 prefill 长度（上下文压缩/缓存）、提高算力、减少排队优化；TPOT 通过提升 decode 吞吐（continuous batching、增大批大小、优化 kernel）优化。并发与 GPU 利用率：并发过低 GPU 利用率低（浪费）；并发过高则排队/显存溢出导致延迟恶化。理想是"利用率高且延迟可接受"的平衡点——用 continuous batching 让 GPU 在并发下保持高利用率，同时通过并发上限保护延迟。核心是"TTFT 管 prefill、TPOT 管 decode，用分位数监控，并找并发与 GPU 利用率的平衡点"。

TTFT 与 TPOT 是独立指标，分别对应 prefill 与 decode。优化方向不同。并发与利用率是"越高越好但有限制"，需找平衡点并保护延迟。

• 理解 TP/DP/PP 的原理与适用
• 理解推理场景的取舍
• 能设计并行策略

张量并行（TP）：把单层权重切到多卡，单 batch 用多卡算，适合"单模型放不下一张卡"（大模型），但卡间通信开销大，TP 规模受限于通信带宽；数据并行（DP）：每卡一个完整模型副本，不同请求分到不同卡，适合"单卡放得下、吞吐不足"的场景，扩展性好但显存冗余。推理取舍：若模型单卡放不下用 TP（多卡协同算一个请求）；若能放下但要提升吞吐用 DP（多副本并行处理请求）。流水线并行（PP）：把模型按层切段分到多卡，每卡算一段，吞吐较 TP 低但通信省，适合"模型极大且 TP 显存/通信受限"（如百亿以上、TP 卡数超带宽限制）时引入，配合 TP 使用（TP+PP 组合）。核心是"放不下用 TP，吞吐不够用 DP，模型极大且 TP 受限用 PP，按显存与吞吐需求组合"。

TP 解决"放不下"，DP 解决"不够快"，PP 解决"TP 卡数/带宽受限"。推理场景通常先判断单卡能否放下，再决定 TP 或 DP，超大模型组合 TP+PP。

• 理解本地治理的实现方式
• 理解与云端 moderation 的差异
• 能设计本地治理链路

本地实现：输入侧——敏感词/关键词过滤、Prompt 注入/越狱检测（规则 + 模型分类）、输入脱敏；输出侧——内容安全过滤（用本地分类模型/规则做 moderation）、敏感词拦截、输出校验、拒答。与云端 API 差异：云端 API 的 moderation 是 Provider 内置的（如 OpenAI 的 moderation 接口一步接入），本地部署则需自建或集成开源 moderation 模型（如 LlamaGuard、审核模型），且完全掌控数据不出域；云端治理依赖 Provider 的模型与策略（不可定制、更新由 Provider 控制），本地治理可定制规则、可自主更新、可离线运行，但需自建与维护。差异核心：云端"内置、省事、不可定制"，本地"自建、可控、可定制、数据本地"。核心是"本地用词表+规则+本地审核模型做输入输出治理，可控可定制但需自建，云端内置但不可定制"。

治理链路在本地是"自建组合"：输入过滤 + 越狱检测 + 输出审核 + 拒答。与云端差异在"可控性"与"维护责任"——本地自建可控但需维护，云端内置省事但不可定制。

• 理解端侧与云侧差异
• 理解延迟、隐私、成本权衡
• 能设计分流策略

端侧/边缘：延迟低（本地响应）、隐私好（数据不出设备）、无网络依赖，但模型能力弱、受设备算力限制、成本体现在设备端；云侧：模型强、能力全、集中运维，但延迟高（网络）、隐私风险（数据上云）、按 token 计费。分流策略：按任务——低延迟敏感（实时交互、语音）用端侧，高能力需求（复杂推理、多模态）用云侧；按隐私——敏感数据（本地处理）用端侧，低敏感用云侧；按成本——高频小任务端侧省 token，低频复杂任务云侧。权衡：延迟与隐私优先端侧，能力与成本弹性优先云侧；混合架构——端侧做预处理/轻任务，云侧做复杂任务，按需路由。核心是"按任务/隐私/成本分流，端侧保延迟隐私、云侧保能力，用混合架构权衡"。

端侧 vs 云侧是"能力 vs 延迟/隐私/成本"的权衡。分流按任务特征匹配，混合架构让端侧做轻快的、云侧做强力的，兼顾三方面。

• 理解混合架构的价值
• 理解敏感数据与云端模型的协同
• 能设计脱敏与分流

混合架构：把"本地敏感数据"与"云端强模型"结合——本地处理敏感数据（脱敏、特征提取、本地推理），需要强能力时把脱敏后的结果发送云端，而不是把原始敏感数据上传。做法：一是本地脱敏——敏感数据（PII、隐私）在本地做脱敏/抽象（掩码、匿名化、特征化），只上传脱敏版本；二是本地预处理——本地小模型做意图识别、摘要、抽取，把"结构化、脱敏、精简"的结果发云端强模型做复杂推理；三是云端强模型——对脱敏后的间接信息做高质量生成/推理；四是本地兜底——云端不可用时本地模型降级；五是结果回填——云端结果与本地脱敏后的映射回填。核心是"敏感数据本地脱敏/预处理，云端强模型只接触脱敏结果，兼顾隐私与能力"。

混合架构解决"要强能力又要保隐私"。关键是把敏感数据拦在本地，只在脱敏/预处理后把间接信息发云端。隐私与能力的平衡靠"脱敏后再上云"。

• 理解常驻 vs 按需加载的差异
• 理解延迟、显存碎片、命中率
• 能设计加载策略

常驻（多模型常驻显存）：多个模型同时加载在显存，切换零延迟、请求直接命中，但显存占用高、只能放得下少量模型、模型间显存碎片多；按需加载（冷热加载）：用到才加载进显存，用后可卸载，显存节省、可容纳更多模型，但加载有延迟（冷启动），且加载/卸载频繁易产生显存碎片与命中率下降。取舍：对高频热模型常驻（低延迟、高命中），对低频冷模型按需加载（省显存）；混合策略——设"热模型池"常驻 + 冷模型按需加载，用"加载队列 + 淘汰策略"管理；用显存碎片整理/预加载缓解。核心是"热模型常驻保延迟命中、冷模型按需省显存，混合池 + 淘汰策略，并处理显存碎片"。

常驻 vs 按需是"显存 vs 延迟/命中"的权衡。常驻保延迟但耗显存，按需省显存但有冷启动。热冷池混合是常用解法。

• 理解 OpenAI 兼容接口
• 理解无感切换的设计
• 能设计兼容层

设计：本地推理服务暴露 OpenAI 兼容接口（/v1/chat/completions、/v1/embeddings 等），请求/响应格式与 OpenAI API 一致，应用无需改代码即可在本地与云端间切换。要素：一是协议兼容——请求体、响应体、流式格式、错误码对齐 OpenAI 规范；二是模型名映射——应用用"别名"（如 local-model），兼容层映射到本地模型；三是能力协商——通过能力矩阵声明本地模型支持的能力（工具、结构化输出、流式），应用据此降级；四是统一入口——网关暴露统一接口，路由到本地或云端，切换只改路由配置。无感切换：应用只面向统一接口，本地/云端是实现细节，切换不触发应用修改。核心是"兼容层暴露 OpenAI 兼容接口 + 模型别名映射 + 能力协商 + 统一网关路由"。

无感切换的关键是"协议统一 + 路由抽象"。OpenAI 兼容接口让应用单一依赖，别名与能力协商处理差异，网关路由实现本地/云端切换。

• 理解开源模型能力差异
• 理解对功能设计的影响
• 能设计适配

影响：开源模型上下文长度差异大（小模型可能只有几千 token，大模型可达 128K+），工具调用能力差异也大（部分开源模型原生支持 Function Calling 且稳定，部分较弱或需特定格式）。对功能设计的影响：一是上下文长度——决定能承载多大的系统指令 + 历史 + RAG，短窗口模型需更激进地压缩/截断/检索，功能设计要受"上下文预算"约束；二是工具调用——原生支持好的模型可做复杂工具编排，弱的模型需降级为"文本约定格式 + 解析"或用 constrained decoding，功能设计要兼容工具不稳定；三是能力校验——上线前用评估集验证模型的实际上下文利用与工具成功率，按能力设计功能。核心是"按模型实际上下文窗口与工具调用能力设计功能，能力弱则降级（压缩/文本工具协议）"。

开源模型能力参差，功能设计不能假设"都支持长上下文 + 稳定工具调用"。要按实际能力做降级设计，并评估验证。

• 理解 Chat Template 的作用
• 理解格式差异
• 能设计适配

Chat Template 决定模型如何把多轮消息序列化为模型输入的 token 格式（如 ChatML 用 <|im_start|>/<|im_end|> 标记角色，或 Llama 用 [INST] 标记）。不同模型/系列的 Chat Template 不同，用错会导致模型不理解角色、输出错乱、质量下降。适配：一是按模型选择正确 template——从模型配置（tokenizer_config.json 的 chat_template）读取，或按模型系列选择；二是不要在应用层手拼格式——用 tokenizer 的 apply_chat_template，避免硬编码；三是多轮消息按 ChatML 顺序（system/user/assistant/tool）序列化；四是验证——用契约测试确认模板拼接后模型能正确理解角色。核心是"用模型自带的 chat_template 序列化多轮消息，避免手拼格式，按模型适配"。

Chat Template 是"把消息变 token 格式"的模型专属规则，用错会破坏指令理解。正确做法是调用 tokenizer 的模板，而非手写，并做契约验证。

• 理解版本管理的组成
• 理解版本锁定
• 能设计回归测试

版本管理组成：模型权重（版本号 + 权重文件）、分词器（tokenizer 版本，与权重配套）、推理框架（vLLM/SGLang 等版本，升级可能改变行为）。纳入版本管理：把三者作为"模型版本"整体锁定——记录权重、分词器、框架的版本组合，作为可复现的"模型版本"；用模型仓库/registry 管理权重与分词器版本，框架版本在部署配置中锁定。回归测试：每次升级任一组件（权重/分词器/框架）时，用同一评估集跑回归，对比输出质量、延迟、行为（工具调用、结构化输出），识别漂移；用契约测试锁定输出格式。核心是"权重+分词器+框架作为整体版本锁定，任一升级都跑同一评估集回归"。

模型版本是"权重+分词器+框架"的组合，三者任一变化都会改变行为。整体锁定 + 同评估集回归，才能保证可复现与可追溯。

• 理解本地推理指标采集
• 理解可观测性
• 能设计升级回归

指标采集：TTFT/TPOT/总延迟——服务端按请求记录，分位数统计；GPU 利用率——从推理框架/GPU 指标（nvidia-smi/Prometheus）采集利用率、显存、功耗；队列深度——推理框架的排队请求数；错误率——按错误类型（超时、OOM、解析失败）统计。用 Prometheus + Grafana 汇聚，按模型/租户聚合。升级回归：模型权重或推理框架升级时，用固定评估集跑质量回归（准确率、幻觉率、指令遵循、工具成功率），对比升级前后；同时对比延迟/吞吐指标（TTFT/TPOT 是否退化）；用契约测试锁定输出格式；灰度+回滚——升级先灰度，指标/质量达标才全量。核心是"采集 TTFT/TPOT/GPU 利用率/队列深度/错误率，升级用同评估集做质量+性能回归并灰度回滚"。

本地推理可观测性要"质量 + 性能"双维度。TTFT/TPOT/GPU 利用率/队列深度管性能，评估集回归管质量。升级必须双回归 + 灰度。

• 理解 continuous batching
• 理解在线/离线资源差异
• 能设计资源分配

continuous batching（连续批处理）：不断把新到达的请求动态加入正在进行的批次，不同请求处于不同生成阶段，GPU 并行处理多个请求的 decode，避免"等整个批次完成"的空闲，显著提升吞吐与 GPU 利用率，是生产推理框架（vLLM/SGLang）的核心。在线流式 vs 离线批量资源配置差异：在线流式——延迟敏感（TTFT/TPOT 要低），需预留足够的并发/算力、控制批大小与排队，资源按"峰值延迟预算"配置，通常低批高并发；离线批量——延迟不敏感，追求吞吐与成本，可大 batch、持续运行、可排队，资源按"最大化吞吐"配置，可离线分片跑、可复用低峰算力。核心是"continuous batching 动态合并请求提升吞吐；在线流式按延迟预算配资源，离线批量按吞吐最大化配资源"。

continuous batching 是吞吐提升的关键机制。在线流式与离线批量的资源差异在"延迟 vs 吞吐"优先级：在线保延迟、离线保吞吐，配置策略不同。