购买硬件前，我如何选择开源模型
当隐私是固定的但几乎其他一切都存在不确定性时，选择本地模型的实用方法
梯形图转SCL | AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo
我正在为机密业务数据规划一个本地 AI 推理系统。主要工作负载将结合文档和音频：转录音频、总结内容、提取信息，并最终使原始材料更易于搜索和使用。
隐私要求使决策的一部分变得简单。数据需要留在经过批准的私有环境中。我更喜欢从运行在我们控制的硬件上的模型开始，但这并不是唯一可能的边界。托管模型服务，如 Azure OpenAI 或 Vertex AI 上的 Gemini，可以成为受控的备选方案。托管 GPU 平台，如 Modal，也可以帮助我在拥有硬件之前测试开源模型。
我的第一反应是问在硬件预算内我能运行多大的模型。我能运行一个 700 亿参数的模型吗？大型专家混合模型呢？如果一些作业可以隔夜运行，也许我可以接受较慢的推理速度来换取更强大的模型。
我现在认为这可能从不同的角度来看。适合内存的最大模型可能仍然不适合这项工作。处理长文档可能需要太长时间，为我需要的上下文留下的内存太少，或者一次只能支持一个请求。较小的模型可能已经满足质量要求，同时给我更好的延迟和更多长输入的空间。在另一个项目中，上下文长度可能比响应速度更重要。在另一个项目中，五秒钟的延迟可能使应用程序无法使用。
在购买硬件之前，我需要找出哪些权衡对这个用例很重要。这意味着首先要收集关于工作的证据，并将硬件购买视为模型评估的结果，而不是其起点。
1、隐私只回答一个问题
说模型必须在本地运行并不能告诉我需要哪个模型。它甚至不能告诉我是否需要一个模型。
音频工作负载使这一点变得明显。我可以使用直接接受音频的模型，或者我可以使用专用的语音识别模型，然后将转录文本传递给语言模型。第二种设计可能更容易在本地运行和评估，因为转录和语言任务有不同的失败模式。
文档创造了类似的选择。有些可能已经包含干净的文本。其他的可能需要在语言模型看到它们之前进行光学字符识别或视觉模型处理。长文档可以完整传递、分成几部分或通过检索处理。
所以第一个选择实际上是一个管道决策：
- 需要发生哪些任务？
- 哪些任务属于专门的模型？
- 哪些任务需要通用语言模型？
- 哪些步骤必须交互式发生，哪些可以批量运行？
- 我可以预期每种任务有多少？
对于我的系统，我预计最初只有少数内部用户，一些文档和音频作业可以隔夜运行。这使得原始交互速度对这些作业不太重要。它不会使性能变得无关紧要。隔夜进程仍然需要足够的吞吐量才能在早晨之前完成，而交互式问题对相同文档的延迟要求则不同。
工作负载至少有两种操作模式。将它们视为一个平均请求将隐藏我需要选择硬件的信息。
2、云端不是唯一的备选方案
一旦我允许经过批准的云边界进入比较，我就需要精确地说明我在购买什么。可用的服务分为两个非常不同的类别。
托管模型服务通过其企业云让我访问提供商的模型。Azure OpenAI 和 Vertex AI 上的 Gemini 符合这一点。我不管理权重或推理运行时。我选择模型、区域、容量选项、网络、身份和数据控制，然后提供商操作模型。
托管 GPU 平台为我提供运行开源模型的计算。Modal 符合这一点。我仍然选择权重、精度、推理运行时、容器和扩展规则。平台接管大部分 GPU 配置和调度。
这种差异改变了每个选项如何适应这个项目。
3、Azure OpenAI 作为受控的质量备选方案
Azure 允许客户在 Microsoft Foundry 内部署 OpenAI 模型。根据微软的数据隐私文档，这些部署的提示、完成、嵌入和训练数据对 OpenAI 或其他客户不可用。微软在 Azure 中托管模型，该服务不会将请求发送到 OpenAI 运营的服务，如 ChatGPT 或 OpenAI API。
这与将机密数据发送到普通公共端点不同，但与在硬件上运行我控制的模型也不同。微软仍然在 Azure 内运营该服务并处理请求。一些有状态功能将数据存储在客户的 Foundry 资源中，部署类型决定推理可以在哪里发生，滥用监控可能影响标记内容的处理方式。
"专用"一词也需要谨慎。Azure 预配置吞吐量为部署保留模型处理能力。它比标准共享容量提供更可预测的吞吐量，但不应描述为拥有私有物理服务器。专用端点、托管标识、基于角色的访问和区域处理可以收紧边界。它们不会将其转变为本地推理。
如果最佳本地配置错过重要的质量阈值，或者使用量增长超过机器容量，我可以使用此选项。它既是备选模型，也是备选操作环境。
4、Vertex AI 的 Gemini 作为另一个托管模型选项
Google 通过 Vertex AI 上的 Gemini 提供类似的企业模式。我会比较该服务，而不是消费者 Gemini 应用程序，因为相关的边界是具有相关标识、网络、区域、计费和治理控制的 Google Cloud 项目。
Google 的云服务特定条款规定，未经客户许可或指示，Google 不会使用客户数据来训练或微调其 AI 模型。这些条款还描述了列出的 AI 服务的数据位置控制，以及限制在客户帐户之外存储提示和生成输出。Private Service Connect 和 VPC 服务控制可以限制访问路径并降低数据离开批准边界的风险。Google 还为需要预留、可预测容量的工作负载提供预配置吞吐量。
权衡与 Azure 类似。我获得了对强大托管模型、弹性和企业控制的访问权限。我放弃了对权重和运行时的控制，接受云提供商的处理，并承担该提供商的帐户结构、权限、配额、区域、模型生命周期和定价。
Azure 和 Vertex 是同一类别中的替代方案，而不是一个提供商普遍更安全的证明。正确的选择取决于组织已经批准的云边界、其数据和身份所在的位置、合同内容、哪个模型通过评估以及团队准备承担多少新的平台管理工作。
5、Modal 作为本地部署的桥梁
Modal 解决了不同的问题。它为代码和容器提供托管计算，包括 GPU 工作负载。我可以使用 vLLM 等推理引擎运行开源模型，选择 GPU 类型，并测量我可能稍后在本地使用的相同精度和上下文设置。其 LLM 推理指南将吞吐量、延迟、冷启动和长上下文提示处理视为独立的性能问题。其自动扩展控制可以将容器扩展到零，或者在延迟重要时保持容量 warm。
这使得 Modal 在硬件购买之前特别有用。我可以租用多个 GPU 配置，使用公共或合成评估数据，并收集测量结果，而不是估计特定开源模型是否适合并在昂贵的 GPU 上运行良好。因为我测试的是开源模型和运行时，而不是专有替代品，所以结果与计划的本地系统更相关。
Modal 不提供与 Azure OpenAI 或 Vertex AI 上的 Gemini 相同的抽象。我仍然负责模型许可证、权重、容器、运行时设置、API 和大部分推理行为。冷启动对于大型图像和模型权重可能很显著，而保持容器 warm 需要花钱。Modal 提供区域选择，并在其安全和数据处理承诺中记录通过其推理端点发送的请求和响应有效载荷的零数据保留。这些请求仍然通过 Modal 的基础设施，机密工作负载需要审查服务边界、合同、存储、日志、访问和适用的合规范围。它是托管云计算，不是拥有的硬件，默认情况下不是专用的物理租户。
对我来说，Modal 首先是一个实验性桥梁。它可以在购买硬件之前减少不确定性。如果组织批准，它稍后可以成为突发或批量选项，但这是一个单独的决定。
6、管理工作是决策的一部分
云消除了一些基础设施工作，但引入了不同的工作。这项工作应该与每秒令牌数或模型质量一样参与比较。
对于 Azure，我可能需要理解订阅、资源组、Foundry 资源、Microsoft Entra 标识、角色分配、配额、部署类型、专用端点、成本控制、日志以及它们之间的关系。Google Cloud 有自己的学习曲线版本：组织、项目、计费帐户、IAM 和服务帐户、区域、配额、VPC 服务控制、Private Service Connect、日志记录和模型版本。Modal 的初始表面较小，但我仍然需要管理工作空间、标识、密钥、映像、卷、区域、扩展设置、支出限制和审计要求。
这并不意味着超大规模者自动是错误的选择。现有的技能和基础设施可以使其中一个更容易。已经在 Azure 中运营的团队可能更喜欢 Azure OpenAI，因为其标识、网络、计费和审计实践是熟悉的。对于围绕 Google Cloud 构建的组织也是如此。
在我的情况下，我已经从事 Azure 管理，所以这本身可能有用，但我仍然需要诚实地记录它。它既是项目成本，也是我可能想要进一步发展的技能。如果我将这两个目标混合在一起，我可能会使 Azure 看起来比推理系统实际更简单或更便宜。
我可以使运营成本可衡量：
- 创建第一个安全、可重现部署的时间。
- 某人必须理解的资源、权限和服务数量。
- 另一个操作员重现或恢复它所需的时间。
- 访问审查、升级、配额请求、监控和成本控制的持续时间。
- 对提供商特定 API、网络或身份配置的依赖。
对于这个项目，我会这样排列选项：
- 使用公共、合成或去标识数据筛选开源模型。
- 使用现有的、借用的或临时的 GPU 容量（如果批准，包括 Modal）来测试实际的开源模型和运行时。
- 如果本地配置满足质量、上下文、吞吐量和操作阈值，则购买自有硬件。
- 仅当本地配置错过真实需求或需求超过机器时，才将 Azure OpenAI 或 Vertex AI 上的 Gemini 作为受控备选方案。
- 在每个合格选项中使用相同的评估案例和阈值，并单独记录管理工作量。
这是我目前的想法：目标仍然是在购买硬件之前选择一个开源模型。Modal 可以改善该购买的证据。Azure 和 Vertex 可以显示托管专有模型是否创造了有意义的能力增益，并在确实如此时提供逃生路线。它们都不应仅仅因为云服务更容易在演示中启动而进入设计。
7、模型只是配置的一部分
模型比较通常将模型名称放在行中，基准分数放在列中。这对于探索很有用，但它忽略了本地系统性能的许多决定因素。
我需要评估的单位是整个配置：
模型 + 精度 + 推理运行时 + 执行环境 + 操作负担 + 工作负载
执行环境可以是自有硬件或经过批准的托管部署。当我更改量化、服务运行时、上下文长度、批量大小或硬件后端时，相同的模型可能表现不同。在托管 GPU 上以全精度运行良好的模型在量化后可能损失足够的质量而无法完成我的提取任务。另一个可能保持其质量，但在我想要使用的运行时中运行不佳。
这也改变了"最佳模型"的含义。我寻找的不是最高的通用基准分数。我寻找的是一个满足所需质量阈值，然后为我提供上下文、速度、内存和操作复杂度之间可接受平衡的配置。
8、从描述工作开始
在创建模型候选名单之前，我想根据系统实际接收的输入编写一个小需求表。
其中一些是硬约束。阻止预期商业使用的许可证会淘汰模型。超出批准隐私边界或缺少所需输入模式的模型或托管部署也是如此。
其他要求是阈值。也许模型必须在至少定义百分比的评估案例中正确提取所有必填字段。也许一批录音必须在固定窗口内完成。一旦配置满足这些阈值，更多的模型容量可能没有实际价值。
阈值很重要，因为没有它们，每个比较都会偏向"更多"。更多参数。更多内存。更多 GPU。更多金钱。
9、任务质量优先于通用智能
公共排行榜通常将多种能力组合成一个分数。这是理解该领域的一种合理方式，但它不能告诉我模型是否能可靠地从我的文档中提取信息或在长转录中保留重要细节。
对于这个项目，我关心更窄的问题：
- 摘要是否保留了源事实？
- 模型是否遗漏了重要信息？
- 它是否每次都能返回有效的结构化数据？
- 它是否区分缺失信息和负面信息？
- 它能否指回支持答案的段落？
- 在重复运行中它有多一致？
最后一个问题很容易被忽视。一个产生一次优秀结果但在接下来的两次尝试中失败的模型在自动化管道中很难信任。跨重复的可靠性可能比稍高的平均分数更有用。
这也是较小模型可能获胜的地方。如果集中的提取任务有明确的指令和受约束的输出，较小模型可能已经跨过质量阈值。只有当其改进改变了应用程序的结果时，较大的模型才能赢得其额外的硬件。
10、宣传的上下文窗口不是可用的上下文窗口
上下文长度对于长文档和转录都很重要。根据模型卡中的上下文数字筛选候选者并称此要求已解决很容易。
该数字只是模型可以接受的最大输入。它很少说明模型如何很好地使用该输入中的信息。
RULER 长上下文研究在随着上下文增长而变得更难的任务上测试模型。许多模型在达到其宣传的最大值之前就损失了大量准确性。该论文是一个有用的警告：接受长提示并很好地推理它是分开的能力。
长上下文也改变了硬件计算。键值缓存随序列增长，并可能占用大部分可用内存。Hugging Face 的缓存文档描述了直接权衡：缓存卸载和量化可以节省内存，但可能以速度为代价。
对于这个项目，我需要测试文档和转录长度的分布，而不仅仅是最长可能的情况。我还需要将完整上下文处理与分段、检索或分层摘要等替代方案进行比较。
具有较小上下文窗口和良好检索管道的模型可能在质量、速度或两者上击败长上下文模型。我不会从模型卡中知道这一点。
11、延迟有多个时钟
"每秒令牌数"很有用，但它不能描述完整的用户体验或完整的批处理作业。
对于交互式工作，我关心第一个令牌的时间。对于长生成，令牌之间的时间很重要。对于文档分析，提示处理可能占主导地位，因为模型必须在生成任何内容之前读取数千个输入令牌。在并发使用下，排队会改变所有这些数字。
vLLM 等服务工具分别跟踪这些：第一个令牌的时间、每个输出令牌的时间、端到端请求延迟、请求数量以及提示和生成令牌分布。其指标文档是本地性能测试应该记录的内容的有用列表。
我计划系统中的两种模式需要不同的测量：
音频增加了另一个阶段。如果转录是瓶颈，快速语言模型帮助不大。我需要计时整个管道，而不仅仅是最终模型调用。但是，对于我的用例，我没有这个问题。我可以使用批处理或离线转录，所以这部分目前不是瓶颈。
12、量化属于评估
硬件决策可能取决于量化。较低的精度可以使模型适合更少的内存，并可能使以前不现实的候选者成为可能。
它还创建了需要自己质量和性能结果的新模型配置。
Hugging Face 的推理内存和速度指南指出，量化以准确性换取内存节省，在某些情况下还以推理时间为代价。这种权衡可能因方法和硬件而异。"模型在四位下工作"因此是经验声明，而不是规范。
我想比较至少可能改变购买决策的精度。如果激进量化的大型模型表现不如压缩较少的小型模型，则较小的模型是更容易拥有的系统。如果较大的模型保持有意义的质量优势，则额外的内存可能是合理的。
运行时支持属于同一测试。llama.cpp 等工具支持许多量化级别和硬件后端，包括 CUDA 和 Apple Metal。这种广度很有用，但每个目标配置仍然需要在接近计划机器的硬件上进行测量。
13、公共基准创建候选名单
我不想测试每个开源模型。公共基准站点可以将字段减少到可管理的集合。
Artificial Analysis 在这里很有用，因为它让我比较通用智能、特定能力评估、长上下文行为、输出速度和开放权重的可用性。它还区分权重可用但商业使用受限的模型。
我将使用这些结果创建一个包含大约三到五个模型系列的候选名单。我还将阅读每个模型卡和许可证，检查运行时支持，并寻找接近文档分析、指令遵循、忠实度和语音的评估。
速度数据有一个重要的限制。Artificial Analysis 报告第一方 API 性能或当第一方端点不存在时托管提供商的中位数。这些结果描述了托管推理。它们不能预测模型在我可能购买的工作站上的运行情况。
这就是我希望公共基准发挥的作用：决定测试什么的地图，而不是购买机器的证据。
14、从真实工作负载构建小型评估
本地评估一开始不需要数百个案例。我宁愿有一小组精心选择的具有已知预期结果的案例。
对于文档，我想要典型输入、长输入、困难格式、缺失信息、冲突段落以及需要精确提取和摘要的任务。对于音频，我想要反映系统将接收的条件的录音，包括影响转录的更困难的案例。我可以使用公共、合成或去标识材料进行早期测试，这样真实机密数据永远不会离开所需的边界。
每个案例都需要一个评分方法。有些输出可以自动比较，例如有效的 JSON、必填字段或转录错误。其他需要用于事实准确性、完整性、无支持主张和有用性的评分标准。高风险案例即使在部署后也可能需要人工审查，因此评估应衡量模型是否认识到它缺乏足够的证据。
我还想要重复运行。一次通过隐藏了不稳定性。
第一个评估矩阵可以记录：
这与我为跨本地和云模型路由任务而开发的能力图密切相关。区别在于生命周期中的点。路由器使用证据为每个请求选择部署。在这里，我需要在本地部署存在之前获得证据，因为它将指导硬件购买。
15、分阶段减少候选者
测试每个模型、精度、运行时和硬件组合将产生太多实验。我计划分阶段缩小选项。
阶段 1：质量筛选
在代表性评估集上运行候选名单。如果托管端点使用相同的开源模型且仅接收公共或合成数据，则可以帮助进行早期筛选。如果数据边界已获批准，Azure OpenAI 和 Vertex AI 上的 Gemini 也可以作为不同的托管候选者进行评估。此阶段会淘汰无论硬件如何都错过任务质量或上下文要求的模型。
阶段 2：配置筛选
使用我可以实际部署的量化和运行时测试剩余的本地模型。临时、借用或租用的硬件可以在永久购买之前填补空白。Modal 在这里很有用，因为它可以在多种 GPU 类型上测试开源堆栈。如果 Azure 或 Vertex 仍在比较中，请将其区域、部署或容量选项以及治理设置记录为配置的一部分。此阶段衡量质量损失、内存使用、单请求性能和操作工作量。
阶段 3：工作负载测试
使用预期的上下文分布和请求模式运行决赛选手。这是我测量并发交互请求、完整隔夜批处理、峰值内存和随时间推移故障的地方。
随着变得更加现实，该过程变得越来越昂贵，但每个阶段的候选者越来越少。
16、寻找决策前沿，而不是一个赢家
我不指望一个配置在每个指标上都领先。
有些选项仍然很容易淘汰。如果一个配置比另一个更慢、使用更多内存并产生更差的结果，它就没有理由保留。在消除这些被支配的选项后，剩下的配置之间的比较更有用。
一个可能提供最佳任务质量但需要更多硬件。另一个可能稍微不那么准确但足够快用于交互式使用。第三个可能适合隔夜批处理，因为它可以高效地处理许多文档。
然后决策变得可见。我可以选择满足每个硬性要求的最简单配置，或者为两种类型的工作保留两个模型。较大的模型可能仍然会获胜，但它会获胜是因为评估发现了有用的能力差异，而不是因为其参数数量感觉更安全。
17、使不确定的部分可逆
没有评估会消除所有不确定性。输入量可能会增长。用户可能会带来更长的文档。量化模型可能会在第一组测试集中缺失的案例类型上失败。更好的开源模型可能在我购买机器后六个月出现。
我仍然可以减少错误的成本。
硬件也可以保留选项。内存余量可能比购买当今可用的最大计算更有价值。标准接口可能比围绕一个模型架构调整整个应用程序更重要。模块化管道让我可以单独替换转录、检索或生成。
这就是妥协变得可管理的地方。我不需要知道每个未来的需求。我需要知道哪些假设是昂贵的可逆的，并首先保护它们。
18、最后，我想要批准购买之前的内容
在选择硬件之前，我想要一个简短的决策记录，包含：
- 任务和批准的隐私边界，包括云推理仍然合格时的确切提供商、服务、区域、存储、网络和监控条件。
- 工作负载分布，包括上下文长度和批量大小。
- 最低质量和性能阈值。
- 用于创建候选名单的公共证据。
- 本地评估集和评分方法。
- 每个模型、量化、运行时和测试机器的结果。
- 每个合格环境所需的设置、学习和持续管理。
- 所选配置中接受的妥协。
- 如果质量、上下文或用法与假设不同，则备选方案。
此列表不是为了证明所选模型将保持最佳。模型变化太快，而硬件可能使用多年。相反，这是为了回答一个更有用的问题：根据我今天对工作的了解，此购买是否有证据支持，如果我的假设错误，改变方向有多困难？
这就是我对此项目（和我的客户）想要的标准。我的初始偏好仍然是运行在我们控制的硬件上的开源模型。Modal 可以帮助我在承诺机器之前测试该选择。Azure OpenAI 和 Vertex AI 上的 Gemini 使偏好不那么脆弱：如果本地推理不能满足真实需求，我有受控的托管路径可以评估，而不是悄悄降低质量标准。
我不需要在购买硬件之前获得确定性。我需要足够的证据表明决策是合理的，并且足够的可逆性，使妥协不会成为永久约束。
原文链接：How I'm Choosing an Open Model Before Buying the Hardware
汇智网翻译整理，转载请标明出处
