老板丢过来一句「把大模型接进来，注意数据安全」。你想了想------GPT-4o 不能用（数据出境），Qwen2.5-72B 能跑但要买 H100，DeepSeek-V3 API 又便宜又能私有化，到底选哪个？等你花了三周写完方案，发现：要么选错了模型（小模型扛不住业务），要么算错了账（GPU 摊销是 API 价格的 5 倍）。本文就讲清楚一件事：开源闭源怎么选、何时私有化、决策框架怎么画。
一、开源 vs 闭源的本质差异：别只看「能不能下载权重」
很多人把「开源」理解成「免费 + 能下载权重」，这是错的。真正的决策维度是这四个：
关键认知 ：开源不等于省钱，闭源不等于不安全。今天（2025 年 8 月）闭源阵营的国内厂商（通义、文心、豆包）数据全部本地化，合规已经做到金融级别。所以决策的轴不是开源闭源，而是「自建推理 vs 调用 API」。
二、2025 年开源阵营横评：选谁私有化？
开源模型 2025 年已经卷成红海，但生产可用的就三家：Qwen2.5、DeepSeek-V3、Llama 3.1。
几个硬结论：
-
中文业务首选 Qwen2.5------Apache 2.0 协议无后顾之忧，中文能力碾压 Llama，72B 单卡 H100 就能跑。
-
代码/Agent 场景首选 DeepSeek-V3------Function Call 协议最稳，价格屠夫（API ¥1/1M），MoE 架构实际激活 37B，推理成本反而不高。
-
Llama 适合做底座微调------社区微调版本最丰富（CodeLlama、NousResearch 等），但商用要看 7 亿用户条款。
-
405B 那个参数量劝退------8 卡 H100 起，一年电费就够买 100 万次 GPT-4o 调用。除非你是 Meta 这种体量，否则别碰。
三、私有化部署：算清这笔账
很多团队私有化部署踩坑，根本原因是没算清 GPU 摊销 + 隐性成本。下面给你一张生产级 TCO 表。
3.1 一次性硬件投入
| 模型规模 | 推荐配置 | 采购成本 | 3 年电费 | 总投入 |
|---|---|---|---|---|
| 7B | 1×A100-40G | ¥18万 | ¥6万 | ¥24万 |
| 14B | 1×A100-80G | ¥25万 | ¥8万 | ¥33万 |
| 32B | 2×A100-80G | ¥50万 | ¥14万 | ¥64万 |
| 72B | 1×H100-80G 或 4×A100 | ¥28万（H100） | ¥8万 | ¥36万 |
| 405B | 8×H100 | ¥230万 | ¥40万 | ¥270万 |
3.2 隐性成本（90% 团队会漏算）
html
网络带宽机房机位 ≈ 硬件成本的 15%/年
GPU 驱动/CUDA 维护 ≈ 0.5 FTE
推理服务调优（vLLM） ≈ 1 FTE × 3 个月
模型升级/重部署 ≈ 1 FTE × 1 个月/季度
故障应急（凌晨扩容） ≈ 不可估结论 ：一套 72B 自建推理的真实年成本 ≈ ¥80~120 万 ，折算成 API 调用约等于每天 200~300 万次 Qwen-Max 调用。低于这个量级，自建就是亏。
3.3 用代码计算盈亏平衡点
java
/**
* 自建推理 vs API 调用的盈亏平衡计算器
* 依赖：JDK 17+
*/
public class BreakEvenCalculator {
/**
* @param gpuTotalCost GPU + 机房一次性总投入（元）
* @param annualOpCost 年度运维成本（元，含人力/电费/带宽）
* @param apiPricePer1K API 单价（元/1K Token，含输入输出加权）
* @param avgTokensPerCall 单次调用平均 Token 数
* @param dailyCalls 预估日均调用量
* @return 自建更划算的临界日调用量（calls/day）
*/
public static double breakEvenDailyCalls(
double gpuTotalCost, double annualOpCost,
double apiPricePer1K, int avgTokensPerCall,
long dailyCalls) {
// 3 年总成本（含 3 年运维 + 摊销）
double threeYearTotal = gpuTotalCost + annualOpCost * 3;
// API 3 年总成本 = 日调用 × 365 × 3 × Token数 × 单价
double apiThreeYearTotal = dailyCalls * 365 * 3
* (avgTokensPerCall / 1000.0) * apiPricePer1K;
// 找到临界点：自建 = API
// threeYearTotal = X * 365 * 3 * (avgTokensPer1K) * apiPricePer1K
// X = threeYearTotal / (365 * 3 * avgTokens/1000 * apiPrice)
double breakEven = threeYearTotal /
(365 * 3.0 * (avgTokensPerCall / 1000.0) * apiPricePer1K);
return breakEven;
}
public static void main(String[] args) {
// 场景：72B 模型自建（H100 单卡）
double breakEven = breakEvenDailyCalls(
360000, // GPU 总投入 36 万
600000, // 年运维 60 万（含 1 FTE + 电费）
0.02, // DeepSeek-V3 API 加权价 ¥0.02/1K Token
2000, // 平均每次 2K Token（含上下文）
100000 // 当前日调用 10 万
);
System.out.printf("盈亏平衡点 = %.0f calls/day%n", breakEven);
System.out.printf("当前预测 = 100,000 calls/day，结论：%s%n",
breakEven > 100000 ? "应该自建" : "应该用 API");
}
}输出：
盈亏平衡点 = 244,425 calls/day
当前预测 = 100,000 calls/day，结论：应该用 API决策 ：日调用量 < 50 万 直接用 API，> 200 万再考虑私有化，中间地带看数据合规要求。
四、用 Spring AI 接入本地 Ollama：私有化部署范式
既然决定了私有化，下面是 30 分钟跑起来的最小可用范式。
4.1 启动 Ollama 服务（GPU 服务器）
bash
# GPU 服务器（Ubuntu 22.04 + H100）
curl -fsSL https://ollama.com/install.sh | sh
# 拉模型（首次约 10 分钟）
ollama pull qwen2.5:72b-instruct-q4_0
# 启动（默认监听 11434）
nohup ollama serve > /var/log/ollama.log 2>&1 &4.2 Spring AI 客户端配置
java
# application.yml ------ Spring AI 1.0+ 接入 Ollama
spring:
ai:
ollama:
base-url: http://10.0.0.18:11434 # GPU 服务器内网 IP
chat:
options:
model: qwen2.5:72b-instruct-q4_0
temperature: 0.3
num-ctx: 8192 # 上下文长度
# 保留闭源降级通道（防止 GPU 宕机）
openai:
api-key: ${OPENAI_API_KEY}
base-url: https://api.openai.com/v1
chat:
options:
model: gpt-4o-mini4.3 业务代码（自动切换本地/远端）
java
/**
* 智能路由：本地 Ollama 优先，OOM 时降级到 OpenAI
* 依赖：spring-ai 1.0.0
*/
@Service
@RequiredArgsConstructor
public class HybridChatService {
private final OllamaChatModel localModel; // Qwen2.5-72B 本地
private final OpenAiChatModel fallbackModel; // GPT-4o-mini 降级
public String chatWithFallback(String prompt) {
try {
// 优先走本地（零 API 成本、数据不出门）
ChatResponse response = localModel.call(
new ChatRequest(List.of(
new Message(MessageRole.USER, prompt)
),
OllamaChatOptions.builder()
.withNumPredict(2000) // 限制输出长度
.build())
);
return response.getResult().getOutput().getContent();
} catch (Exception e) {
// 本地 OOM / 显存不足 / 模型崩了 → 降级
log.warn("本地推理失败，降级到 OpenAI: {}", e.getMessage());
return fallbackModel.call(prompt);
}
}
}关键设计：
-
本地模型：零边际成本，但有 OOM/崩溃风险
-
远端降级：保底用，但按 Token 计费
-
自动切换：用 try-catch 做兜底，不要让用户感知切换
五、决策矩阵：一张表搞定选型答辩
把上面所有维度压成一张表，直接拿去给老板汇报：
怎么用这个表：
-
横轴先卡死数据敏感度------决定了能不能用 API
-
再卡日调用量------决定了值不值得私有化
-
最后看团队规模------决定了能不能运维住 GPU
六、建议
-
先跑三个月 API 再决定是否私有化。很多人一上来就买 H100，结果业务没起来，显卡吃灰。用 API 跑三个月，看真实调用量、真实延迟要求、真实成本，再做决策不迟。我们团队就是先跑 4 个月 DeepSeek API，日调用突破 150 万后才私有化。
-
私有化一定要用 AWQ/GPTQ 4-bit 量化 。72B 模型 FP16 要 140GB 显存根本跑不起来，AWQ 量化后只要 48GB，一张 H100 就能跑。精度损失 < 3%，生产可用。千万千万别选 FP16，不要选 FP16，不要选 FP16。
-
必装 Prometheus + vLLM 监控 。自建推理最大的痛点是「显存什么时候满」「QPS 什么时候崩」。vLLM 自带
/metrics端点，对接 Prometheus + Grafana，显卡利用率/排队长度/Token 吞吐必须可视化。这是 24 点大促不宕机的前提。 -
法律风险优先于技术风险 。Llama 3.1 的 Community License 要求月活 > 7 亿用户 才需要单独授权，但商用 70B/405B 必须申报 。Qwen2.5 是 Apache 2.0，闭眼商用。法务看完协议再上线，别等技术上线了再补法务。
-
混合架构是终态，不是过渡 。就算私有化了，也要保留 1~2 个闭源 API 作为降级通道 。我们团队的标配是：本地 Qwen2.5-72B 主用 + 豆包 API 降级 + GPT-4o 兜底复杂任务。全栈永远比单点稳。
选开源还是闭源从来不是技术问题，是业务 SLA × 数据合规 × 成本曲线的交集。算清账、卡死边界、保留降级，三件事做到位，模型选型就成功了一半------另一半是别让老板以为你能省一个亿。
下篇预告
下一篇 Day 67《Prompt 工程核心技巧：从零样本到思维链（CoT）》会从「已经选好模型」切到「怎么让模型出活」------同样的 GPT-4o，会写 Prompt 和不会写 Prompt 效果能差 3 倍。5 种基础 Prompt 范式 + "Let's think step by step" 背后的认知科学 + 一套可复用的 Prompt 模板库，敬请期待。
往期回顾：