选框架先核对六项
框架选型最常见的问题是跳过核对直接上手，跑了半程才发现权重格式不支持或多卡方案不成熟。把判断收敛到六项：模型架构、量化格式、硬件后端、并发与延迟目标、运维成熟度、团队熟悉度。六项里任一项不合格，就要在测试环境先验证通过再推进，而不是指望上线后调通。
六项核对清单
- 模型架构：是否支持目标模型的注意力变体、专家混合结构与多模态输入
- 量化格式：权重是哪种量化，引擎能否直接加载，质量损失是否可接受
- 硬件后端：单卡还是多卡、是否需要张量并行、卡型架构是否在支持列表内
- 目标指标：平均延迟与尾延迟要求、峰值并发量级、上下文长度分布
- 运维能力：日志、指标、健康检查与升级路径是否齐全，出故障能否观测
- 团队熟悉度：现有脚本、镜像与经验能否复用，学习成本是否可承受
核对表与后果
| 核对项 | 判断依据 | 不合格的后果 |
|---|---|---|
| 架构支持 | 官方支持列表与实测加载 | 加载失败或输出质量异常 |
| 量化匹配 | 引擎支持的量化内核清单 | 权重无法加载，需要重新转换 |
| 硬件后端 | 算力是否在构建目标内 | 内核不可用，运行时报错 |
| 并发目标 | 压测下的排队与尾延迟 | 上线后高峰期不可用 |
| 运维配套 | 指标与日志是否覆盖容量与错误 | 故障时无法定位，只能重启 |
| 团队栈 | 现有部署与监控能否沿用 | 运维成本翻倍，故障处置变慢 |
快速验证流程
快速验证流程
# 1) 单请求质量：确认输出正常、模板正确
curl http://127.0.0.1:8000/v1/chat/completions -H 'Content-Type: application/json' \
-d '{"model":"<模型名>","messages":[{"role":"user","content":"ping"}]}'
# 2) 并发压测：用框架自带或独立压测工具，按目标并发梯度逐级加压
# 3) 观察首 token 延迟、吞吐与显存曲线，达标后再定版本跳过并发压测直接上线是常见事故来源：单请求正常不代表并发下稳定，容量问题通常在流量上涨时集中暴露。
只验证小模型就下单：不同规模与不同上下文长度下的显存与调度行为差异很大，验证要覆盖目标规模。