企业官网建设流程全解析

Google doesn‘t need the LLM crown

过去一年里，围绕 Google 和 LLM 的讨论几乎集中在一个问题上：Gemini 到底能不能在基准测试里超过 GPT 和 Claude？每次新版本发布，社交媒体上都会有一轮“谁才是第一”的对比，然后很快被下一轮实测截图盖过去。如果你也一直在追这类榜单，可能忽略了一个更真实的问题：Google 真正的竞争力，从来不是某个单项模型跑分最高，而是它手里那套别人复制不走的系统——从 Android、Chrome、Google Play、搜索，到 TPU、Gemini API、AI Edge Gallery、MediaPipe 和 Android Studio 的完整链路。

这篇文章不讨论“谁家模型刷榜更强”，而是从工程落地的角度拆开看：Google 为什么不需要拿 LLM 王冠，它的生态里有哪些开发者能直接使用的资源，以及当你把 LLM 接到真实业务时，会遇到哪些和 Google 相关的实际问题，比如账号区域限制、ComfyUI 与 LLM 的部署关系、应用编排框架、精度选型、知识库方案，还有 Android 上常见的签名坑。

如果你正在做 LLM 应用选型、考虑把 Gemini 或本地模型接入现有系统，或者在纠结“我的显卡能不能跑这个模型”，这篇文章值得读完。

1. 先把问题拆开：Google 到底在争什么

先说结论：Google 在 LLM 竞争里采取的是一条“系统性整合”路线，而不是“单项冠军”路线。

原因是结构性的。Google 不需要靠一个模型拿第一来建立壁垒，因为它的分发渠道已经覆盖了绝大多数用户的日常路径。搜索是入口，Android 是移动端入口，Chrome 是桌面端入口，YouTube 是视频内容入口，Google Play 是应用分发入口。任何一个新模型能力，只要接入这些入口，就能立刻触达数十亿用户，而不需要用户额外安装一个聊天 App。

这对开发者的意义很直接。你不需要先“成为 Gemini 的忠实用户”才能用上它的能力，你只要在现有产品里调用 API，或者在自己的 Android 应用里集成端侧模型，模型能力就自然落到业务里了。Google 的竞争重心，从“跑分第一”转向“让开发者更容易把模型用起来”。

从公开信息可以看到，Google 的模型布局是两条线并行：

• 云端大模型：Gemini 系列，通过 Google AI Studio、Gemini API 提供访问，并且持续压低价格、扩大免费额度。
• 端侧小模型：Gemma、MediaPipe 任务库、AI Edge Gallery 里的优化模型，目标是跑在手机和本地设备上，减少对云端的依赖。

这两条线合在一起，才是 Google 真正的 LLM 战略。它既不完全押注“最大最强”，也不只做“轻量端侧”，而是用一套工具链把不同规模的模型塞进不同的设备场景里。

2. Google 的 LLM 布局全景

把 Google 的 LLM 相关能力按“开发资源”视角整理一下，你就能看清它到底提供了哪些可用的技术环节：

从这个表能看出一个核心区别：OpenAI 的护城河主要在 API 和产品体验，Anthropic 的护城河在模型能力和 Claude 的编程场景，而 Google 的护城河是“从芯片到分发”的全链路。哪怕 Gemini 在某个榜单上不是第一，它在 Android 手机、Chrome 浏览器、搜索和 Workspace 里的存在感，依然是大多数普通用户最先接触到的 LLM 入口。

3. 为什么说 Google 不需要“LLM 王冠”

很多人批评 Google 在 AI 发布节奏上“迟到”：ChatGPT 出来很久之后，Google 才匆忙推出 Bard，后来改名 Gemini。但从商业和技术战略的角度看，这种批评忽略了一个事实：Google 在 LLM 上押注的不是一个单点，而是整个生态的整合深度。

先看分发。OpenAI 要让用户使用 ChatGPT，需要用户主动访问 chat.openai.com 或安装 App。Google 不用，Android 全球设备数量超过 30 亿，Chrome 的用户基数同样巨大。只要模型能力被嵌入系统级入口——搜索、浏览器、助手、输入法——用户不离开原有习惯就能用到 LLM。这个分发效率，是任何独立模型公司都很难直接复制的。

再看基础设施。训练和推理大模型的成本里，很大一部分来自 GPU 的采购和算力消耗。Google 自己就有 TPU，从公开资料看，TPU 在大规模推理场景中的成本控制有明显优势。对于需要高频调用模型的业务，长期成本是决定性因素，而 Google 可以把模型服务的价格压到很低，吸引更多开发者把数据量大的任务放进来。

然后是端侧能力。OpenAI 目前的重心在云端模型，而 Google 一直在推 MediaPipe、AI Edge Gallery、Gemma 这类端侧方案。端侧推理的价值在于：低延迟、离线可用、数据不出设备。对很多企业应用来说，数据隐私是硬性要求，不能把用户数据传到云端。这时候 Google 提供的端侧模型工具链，就变成了一个务实的选择。

最后是产品整合。Gemini 不只是聊天机器人，它可以出现在搜索里回答复杂问题，可以在 Gmail 里总结邮件，可以在 Docs 里辅助写作，可以在 Android 上读取屏幕内容执行操作。这种系统级整合是 Google 独有优势。单个模型跑分高不等于产品体验好，真正影响用户感知的是模型能力到底嵌进了多少个日用场景。

所以“Google 不需要 LLM 王冠”的判断，核心依据是：Google 的竞争目标不是成为某个榜单的第一名，而是让 LLM 成为所有人无感使用的基础能力。对开发者来说，这种战略背后的资源才是最值得关心的：免费模型额度、端侧 SDK、低延迟推理、跨端部署能力。

4. 开发者视角：Google 的 LLM 落地通道

对开发者来说，Google 的 LLM 资源主要可以从四个方向实际落进项目里。

4.1 云端 API：快速验证，优先接入

如果业务需要多轮对话、内容生成、图片理解、代码生成，最省力的方式是用 Gemini API。它适合在原型阶段快速验证产品逻辑，不需要前期投入推理硬件。从公开信息看，Google AI Studio 提供了较多免费试用额度，适合个人开发者和小团队做实验。

需要关注的限制是账号区域和订阅方案。部分模型能力并不是所有区域都默认开放，有些方式需要确认账号所属区域是否支持订阅；即使账号创建成功，如果系统判定账号异常，也可能无法订阅 Google AI 方案。这提醒我们：如果你打算做一个依赖 Google 云端模型的服务，要提前确认网络环境、账号区域和企业许可条款，而不是等上线以后才发现调用被限制。

4.2 端侧与移动端：AI Edge Gallery + MediaPipe

如果你做的是 Android 应用，Google 提供了完整的端侧模型集成链路。AI Edge Gallery 里可以找到针对移动设备优化的模型，MediaPipe 负责图像、音频、手势等任务的本地推理，Gemma 模型可以在设备端跑文本生成。这套方案的优势是不需要把用户数据上传到云端，适合处理敏感信息或需要离线运行的场景。

实际集成时，建议先用官方示例工程跑通最小流程，再替换成自己的模型和业务逻辑。端侧模型的推理速度受设备性能影响很大，需要在真机上测试，而不是只在模拟器上验证。

4.3 浏览器与桌面端：Chrome 是最大的 AI 落地入口

Chrome 的全球用户量，决定了浏览器本身就是一个巨大的 LLM 分发场景。对 Web 开发者来说，这意味着两件事：一是可以考虑基于浏览器构建 AI 功能，比如调用扩展能力、本地小模型、或者连接 WebGPU 做端侧推理；二是要注意 Chrome 的落盘策略、缓存管理、内核规则等底层行为，避免用户侧存储异常。

热搜里经常看到“Chrome 数据强制放在 C 盘”“浏览器添加新内核规则怎么设置”这类问题，本质上都是桌面端工程化问题。如果产品面向普通用户，需要提前设计好数据目录、缓存清理规则和内核兼容策略，否则用户会因为这些基础问题流失。

4.4 应用分发：Google Play 的签名与发布机制

做 Android 应用绕不开 Google Play 发布，而这里有一个常见坑：本地自签名与 Google Play 二次签名不一致。发布到 Google Play 后，应用会由 Google 重新签名，如果 SDK 或服务依赖对签名校验敏感，就会出现运行异常。

排查思路是：确认是否开启了 Play App Signing，获取官方签名证书的 SHA-1 和 SHA-256，并在开发者后台或后端校验逻辑中使用 Play 提供的签名信息，而不是本地 keystore 的信息。涉及登录、支付、地图等依赖签名鉴权的服务时，这个点尤其容易踩坑。

5. 本地部署与 LLM 编排：真实工程问题

在 LLM 应用开发里，讨论最多的不是模型本身，而是怎么把模型接进现有系统。热搜词里“ComfyUI 与 LLM 必须在同一台电脑上么”“LLM 应用为什么需要编排框架”“Spring AI + MCP + RAG + Agent”这些问题，恰好是工程落地的核心。

5.1 ComfyUI 与 LLM 是否必须同机

ComfyUI 本质上是图像生成的工作流工具，用来跑 SD 类模型，而 LLM 是语言模型。它们是不是必须部署在同一台电脑上？答案是不需要。

ComfyUI 负责图像生成，LLM 负责文本理解、提示词扩写、结果总结，两者通常是不同的模型、不同的推理服务。实践中常用的做法是：

• ComfyUI 跑在 GPU 机器上，LLM 跑在另一台机器或云端。
• LLM 通过 HTTP API 生成提示词，然后发送给 ComfyUI 工作流中的节点。
• 多机部署时，ComfyUI 的extra_model_paths.yaml可以配置外部模型路径，方便别的机器通过网络访问模型文件或输出目录。

如果你的 ComfyUI 只是本地调试，不需要联网，那它可以独立跑；如果你想把 LLM 的文本生成能力和图像工作流串联，就需要一个中间层做请求转发和结果解析，最常见的是在 ComfyUI 工作流里加一个 API 调用节点，或者用外部 Python 脚本通过 ComfyUI 的 HTTP 接口提交任务。

5.2 为什么 LLM 应用需要编排框架

直接调 API 和用编排框架之间的差别，在简单 demo 里看不出来，一旦进入真实业务，问题就来了：你需要控制多轮对话的记忆，需要接入外部工具查询数据，需要把多个模型串成一条 pipeline，需要处理重试、超时、并发和日志。

编排框架的价值在于把这些通用能力标准化。比如 Spring AI + MCP + RAG + Agent 的组合，是目前 Java 生态里比较常见的架构：Spring AI 负责模型调用抽象，MCP 负责连接外部工具和数据源，RAG 负责从知识库检索上下文，Agent 负责任务拆解和决策。这套组合的好处是，即使底层模型换了，上层业务代码也不用大改，只要替换 Spring AI 的模型配置。

对团队来说，这比“每个人写一套自己的调用代码”要可控得多。

5.3 FP16、FP32、BF16 到底选哪个

部署 LLM 时，精度选择直接影响显存占用和推理质量。FP32 精度最高，但显存占用大，实际推理很少用；FP16 是很多 GPU 推理的默认选择，质量损耗小，但数值范围有限；BF16 的指数范围和 FP32 一致，更适合大模型训练和推理，显存占用比 FP16 稍高一点，但在部分硬件上数值更稳定。

实际选型思路是：

• 优先看硬件支持：NVIDIA 的 GPU 对 FP16 支持很成熟，部分新版显卡对 BF16 支持更好。
• 看显存上限：同样是 7B 模型，FP16 和 BF16 的显存占用不同，具体要以模型和框架的 profiling 结果为准。
• 不要只看跑分：精度越低速度越快，但长文本生成质量可能下降，要在速度和效果之间做测试。

如果你只是本地跑一个 7B/14B 模型，建议先试 FP16，显存吃紧再换 INT8/INT4 量化方案。

6. LLM wiki 与个人知识库：RAG 的实际落点

Google 战略之外，LLM 落地最直接的一个场景是个人知识库。热搜里反复出现的 “Andrej Karpathy 提出的 LLM wiki 范式”“Obsidian + LLM wiki 搭建个人知识库”，反映的是同一类需求：把散落的笔记、文档、浏览器书签变成可以被模型检索的结构化知识库。

6.1 什么是 LLM wiki 范式

简单的说，LLM wiki 不是让模型“记住”所有知识，而是把知识组织成模型可以高效检索的形态：短小的知识条目、明确的标题层级、块级引用、双向链接，再加上语义向量索引。检索时用嵌入模型做相似度匹配，把相关片段交给 LLM 生成回答。这样既避免了长上下文带来的成本激增，也让回答更容易溯源。

6.2 用 Obsidian + LLM wiki 搭建的最小方案

核心组件包括：

• Obsidian：负责知识管理，markdown 文件存本地，便于版本管理和同步。
• LLM API：负责理解问题和生成回答，可以接 Gemini API，也可以接本地模型。
• 向量数据库：负责存储笔记的向量和元数据，比如 Chroma、Qdrant、pgvector 等。

搭建流程大致是：

1. 把笔记按主题拆成独立 md 文件，保留标题和标签。
2. 用脚本扫描目录，调用嵌入模型生成向量，写入向量数据库。
3. 收到用户提问后，先向量检索 TopK 相关片段。
4. 把检索结果和问题一起拼成提示词，交给 LLM 生成回答。
5. 回答中要求模型保留引用来源，方便回溯。

这套流程不绑定 Google，但如果你用 Gemini API 做生成端，配合免费额度跑个人知识库，成本压力会比较小。

7. Google 生态接入的常见坑

从实际开发经验看，接入 Google 生态时，最容易出问题的集中在四个方向：

这些坑很多不是模型本身的问题，而是工程部署与平台机制导致的。提前在架构设计阶段就把它们考虑进去，比上线后救火省事得多。

8. 给开发者和团队的建议

如果你看完这篇文章，准备做 LLM 应用，我的建议是分四步走：

第一步，不要先追跑分。先确认业务场景里到底需要多大参数量的模型。如果只是文本分类、信息抽取，7B 量级的模型可能就够用了；需要复杂推理和长文档生成时，再考虑云端大模型。模型选型应该跟着场景走，而不是跟着榜单走。

第二步，围绕现有系统做集成，而不是从零搭建。Java 团队可以看 Spring AI + MCP，Python 团队可以看 LangChain / LlamaIndex。关键是把模型调用抽象出来，避免业务代码和模型供应商深度耦合，否则以后换模型成本很高。

第三步，优先设计可观测性。LLM 应用和传统接口最不一样的地方是输出不稳定。上线前要给每次推理加日志，记录输入、输出、token 消耗、耗时；批量任务要加重试和超时；面向外部用户的场景，还要对输出内容做安全过滤和人工抽检。

第四步，合规和授权一定要前置。如果你处理的是用户上传的图片、语音、文档，或者在采集素材声音、肖像，必须明确获得授权，并在后台记录授权来源。涉及版权素材的内容，不要直接对公众或商业渠道发布。生成内容的风险边界，建议在技术方案评审阶段就由法务和产品共同划定。

从更宏观的角度看，Google 不需要“LLM 王冠”这件事，对开发者的启示是：选技术平台，要看生态完整性，而不只是单项指标。模型会迭代，榜单会变化，但分发渠道、开发工具链、端侧能力、成本结构这些底座，才是长期决定你产品能不能跑起来的因素。

9. 总结与下一步

回到标题：Google 不需要 LLM 王冠。不是因为 Gemini 不够强，而是因为 Google 的 LLM 战略早就超出了“单模型跑分”这个维度。从 TPU 到 Gemini API，从 AI Edge Gallery 到 MediaPipe，从 Chrome 到 Google Play，它提供的是一整套可以让模型能力触达最终用户的系统和工具。

对开发者来说，这篇文章最值得记住的几点：

• 做产品选型时，先把业务场景和算力成本算清楚，再决定用云端大模型还是端侧小模型。
• 接入 Google 生态，优先检查区域、账号、签名这些平台级限制，它们比模型效果更容易成为上线阻塞项。
• ComfyUI、LLM、RAG、Agent 之间是服务依赖关系，不一定要部署在同一台机器上，关键是设计好接口和中间层。
• 个人知识库是 LLM 落地最容易见效的方向，Obsidian + LLM wiki + 嵌入模型这套组合，值得亲手跑一遍。

下一步建议你选一个最小的场景动手：比如先跑通一个 Gemini API 的对话接口，或者用本地模型加向量库搭一个笔记检索 demo。先把链路走通，再逐步加复杂功能，避免一开始就追求完整架构而卡在环境问题上。