如何在不自建服务栈的前提下将开源模型投入生产环境
文章解析在生产环境中运行开源大模型的关键工程权衡：部署模式选择、容量与性能协同设计、服务栈责任边界划分，以及加速器特性（如AMD MI300X高内存）对吞吐量、延迟与成本的实际影响，并以AT&T和GLM-5.3 Flash为例说明落地实践。
生产环境推理要求技术团队将模型、部署方式和基础设施作为一个整体来考虑——而无需对整个服务栈承担全部责任。
在生产环境中运行开源模型，意味着将模型选择、部署方式、容量、加速器以及服务栈所有权视为一个统一的工程问题。团队需要围绕内存需求、预期负载、延迟和吞吐量目标，以及自身准备管理的运维边界进行设计。
对技术团队而言，这意味着需回答四个问题。
1. 哪种部署模型最适配该工作负载？
按令牌计费的推理适用于需要灵活消耗、且无需专用基础设施的工作负载。其他工作负载则可能从专用容量中获益，例如当持续性需求、可预测的延迟与吞吐量、GPU可用性，或特定开源模型与加速器配置成为优先考量因素时。
这为需要专用GPU容量、并希望对模型与基础设施配置拥有更大控制权，但又不愿自行构建和运维完整服务栈的团队创造了中间路径。 Microsoft Foundry 中的托管计算（Managed Compute）即为此类需求提供了一种解决方案。
2. 如何围绕容量、延迟和吞吐量进行设计？
一旦工作负载运行在专用基础设施上，容量与性能便成为可调控的工程变量。团队需预估负载、配置容量，并选择一个能在延迟与吞吐量之间取得平衡的运行点。交互式应用可能优先考虑响应时间，而批处理或高吞吐量工作负载则可能以吞吐量为优化目标。当GPU容量分配给客户而非共享时，团队便能更清晰地依据这些变量开展设计。
经济性模型也随之改变。团队不再仅将推理视为按令牌计费的消耗成本，还需考虑已配置GPU容量及其使用效率。GPU小时成本、利用率、吞吐量及完成的工作量，共同决定了每个令牌或每次推理请求的有效成本。
3. 您希望自主管理服务栈的哪一部分？
借助 Foundry中的托管计算，客户保留直接影响工作负载的决策权，而微软则负责管理大部分服务环境。
您的团队控制 | 微软管理大部分服务环境 |
模型与加速器选择 | 运行时与容器环境 |
已配置容量 | 基础设施调优与优化 |
延迟与吞吐量之间的运行点 | 软件与运行时更新 |
容量伸缩 | 漏洞修复与安全补丁 |
这种从客户自管基础设施向平台托管的转变，意味着平台团队可在不维护底层每一层的前提下，继续掌控影响工作负载性能与经济性的关键变量。
由于托管计算是Foundry的一部分，开发者还可继续跨部署类型使用熟悉的一致性推理API、认证机制、网络配置、SDK及可观测性工具。
4. 该工作负载需要何种加速器特性？
内存容量决定了模型能否适配特定配置，以及所需GPU数量：更多内存意味着可在更少GPU上运行更大模型，从而为批处理等技术预留余量；而内存带宽则影响数据在加速器内部传输的效率。这些特性与服务配置共同决定了并发能力、吞吐量、延迟及工作负载的经济性。
AMD Instinct™ MI300X GPU即为一例：作为Foundry托管计算中的高内存选项，每块GPU提供192 GB HBM3高带宽内存及最高5.3 TB/s内存带宽，八GPU平台总内存达1.5 TB。该容量使更大模型可在更少GPU上运行，为批处理及长上下文推理提供更多余量——在此类场景中，模型权重与键值（KV）缓存需竞争内存资源。
但硬件仅是方程的一部分。AMD的ROCm生态系统为AMD Instinct提供了开放的软件与优化层，广泛支持开源模型及开源AI框架。仅靠该软件所能实现的规模提升，在 AMD Performance Labs测试中即有体现：在8× AMD Instinct MI355X平台上，ROCm 10的全栈软件优化相较ROCm 7.0基线，在GLM-5、Kimi-K2.5及DeepSeek-R1-0528模型上平均提升了3.3倍的推理吞吐量。在托管计算中，平台方负责持续优化，而非将此职责转嫁给客户。
GLM 5.3 Flash展示了这些特性如何转化为实际部署选择。该3200亿参数模型每令牌激活180亿参数，针对AMD Instinct MI300X优化了三种配置，均配备512K上下文窗口。四GPU配置面向紧凑型聊天、编程及智能体工作负载；而两种八GPU配置则分别采用张量并行（TP）、数据并行（DP）与专家并行（EP），以分别优先保障并发能力与首令牌延迟，或为长上下文工作负载预留更多内存余量。
相同原则亦可见于生产级规模部署。 AT&T在多个开源模型及GPU架构上采用了Foundry中的托管计算，共部署约530块GPU，其中包括约430块AMD Instinct MI300X GPU。仅Phi-4模型每月即处理超7000亿个令牌，用于数据准备与合成数据生成。
配置选择同样至关重要。在针对GLM 5.3 Flash的对话式工作负载测试中，八GPU TP4 + DP2 + EP配置相较四GPU配置实现了约1.8倍的输出吞吐量，同时将平均首令牌延迟降低逾一半。其他工作负载增益较小，进一步印证了团队需针对自身工作负载逐项基准测试各配置，而非仅依据GPU型号的宣传参数做决策。
加速器基准测试结果对于判断某配置是否适配生产应用意义有限。团队需获取工作负载层级的实测指标：
模型运行所需GPU数量？
在既定运行点下可达成的延迟与吞吐量？
在维持目标性能前提下可支持的并发用户数或请求数？
已配置容量的利用效率如何？
GPU小时消耗如何折算为每个令牌或每单位工作的有效成本？
生产始于模型选型终结之处
在生产环境中运行开源模型，意味着需将部署模型、容量、管理边界、加速器及基准测试方法与工作负载精准匹配。
对于需要专用基础设施的工作负载，核心决策在于：团队需在不掌控服务栈每一层的前提下，对模型、加速器、容量及性能保有多大的控制权。Foundry中的托管计算为此类权衡提供了一种可行方案，其中 AMD Instinct MI300X GPU凭借其大内存容量，支持在更少GPU上运行大型开源模型。
JOTO 企业落地观察
- 对企业部署而言，微软Foundry托管计算模式表明：企业可在保留模型选型、加速器配置与容量伸缩控制权的同时，将基础设施调优、安全补丁、运行时更新等底层运维交由平台方，显著降低AI工程团队的SRE负担，尤其适用于缺乏全栈AI运维能力的中大型企业。
- 对智能体工程而言，文中强调需按工作负载类型（如紧凑型聊天vs长上下文推理）逐项基准测试TP/DP/EP并行策略，而非依赖GPU参数宣传；这提示智能体开发者必须在真实业务请求流下验证首令牌延迟、并发承载与KV缓存余量，否则易因内存竞争导致响应抖动或OOM故障。
- 对FDE落地而言，AT&T部署530块GPU（含430块MI300X）支撑Phi-4每月7000亿令牌处理的事实说明：开源模型规模化落地已进入‘算力即服务’阶段；企业FDE路径不再局限于模型微调或应用层开发，更需建立GPU小时成本、令牌有效成本、利用率三者联动的财务计量体系。
立即咨询 JOTO
JOTO 提供覆盖企业智能体规划与搭建、AI 平台私有化部署、RAG 知识工程、AI 安全治理、FDE 驻场共创及持续运营优化的全周期 AI 落地服务，帮助企业把验证中的 AI 能力转化为安全、可控、可持续迭代的生产力。 联系 JOTO 获取 AI 落地咨询
想把这些做法用到你的业务里?
留下你的场景和痛点,我们帮你判断从哪一步开始。
联系我们
