🧠 图解记忆： 先按硬件缩小候选，再按模型和后端支持筛选，最后用真实负载与运维门槛定案。

💡 答案要点

常见候选及其主要取向（功能以目标版本为准）：

候选	主要取向	先确认什么
vLLM / SGLang	数据中心 GPU 服务、批调度与 KV Cache 优化	模型与硬件后端、分布式、结构化输出
TensorRT-LLM	NVIDIA 平台深度优化	模型支持、构建/编译流程和运维复杂度
TGI / llama.cpp / Ollama	服务化生态或本地易用性	并发、后端、模型格式和监控能力
MLX	Apple Silicon 训练与推理生态	模型转换、统一内存和所需算子
MLC LLM / ONNX Runtime 等	移动端、浏览器或跨平台部署	目标设备后端、包体、功耗和算子覆盖
厂商 NPU 工具链	特定加速卡部署	官方适配矩阵、量化、分布式与维护责任

---

端侧选型：

• Apple Silicon 可比较 MLX、llama.cpp 和基于它们封装的本地工具；统一内存容量、内存带宽和模型量化通常比产品标签更关键。
• iOS、Android 和 Web 可比较 MLC LLM、llama.cpp、Core ML、ONNX Runtime 或平台原生工具链；同时评估包体、首启、峰值内存、功耗和热降频。
• 离线运行有助于数据不出端，但不自动等于隐私合规；仍需处理日志、模型供应链、权限、加密和更新策略。

---

特定数据中心加速卡：

不要从框架国别或一次 benchmark 推断性能。先用官方兼容矩阵确认目标模型、算子、精度、张量/流水线并行和监控支持，再比较框架社区版本与硬件厂商工具链。跨硬件性能数字只有在模型、质量、功耗和 SLO 对齐时才可比较。

---

按硬件和部署形态筛选候选：

场景① Mac（Apple Silicon）
  → 候选：MLX、llama.cpp、Ollama 等
  → 比较模型格式、量化、内存峰值和生成速度

场景② Windows (AI PC/游戏本/RTX显卡)
  → 本地开发测试：Ollama/LM Studio（GGUF格式，下载即跑）
  → 服务部署：根据 NVIDIA 后端、模型支持和并发需求比较候选

场景③ Linux云服务器集群 (NVIDIA A100/H100/B200)
  → 常规服务：比较 vLLM、SGLang、TGI 等
  → 深度优化：评估 TensorRT-LLM 等硬件相关方案

场景④ 国产算力 (昇腾/燧原等)
  → 从厂商支持矩阵、社区后端和目标模型适配中筛选
  → 在实际卡型上做质量、性能与稳定性回归

---

**基准报告必须附带的条件：**模型与 revision、精度/量化、GPU 型号和数量、软件版本、输入/输出长度分布、并发/到达率、预热、SLO 以及统计口径。否则 TTFT、吞吐和显存数字不能用于选型。

---

三大常见误区

误区①："某个框架在所有负载下都最快"
  → 真相：模型、版本、硬件、精度、长度分布和 SLO 都会改变结论
  → 用真实流量回放比较，不引用脱离条件的榜单

误区②："Ollama太简单，不适合生产"
  → 真相：易用性不等于不可生产，但需验证并发、隔离、升级、监控和故障恢复
  → 不要靠产品标签判断，按 SLO 和运维需求判断

误区③："国产框架性能肯定不如国外"
  → 真相：跨硬件、跨模型的单个数字不可直接比较
  → 有特定算力要求时，先确认算子/模型支持，再在目标硬件上压测

---

面试话术：

"推理框架选型先受硬件和模型兼容性约束，再比较负载特征与运维要求。Mac 可评估 MLX、llama.cpp 或 Ollama；移动端可评估 MLC、llama.cpp、Core ML/NNAPI 等路径；数据中心则按目标 GPU/NPU 的算子和分布式支持筛选。候选确定后，用相同模型、精度和流量回放比较质量、TTFT、TPOT、吞吐、显存、故障恢复和总成本。"

---