GLM-Image企业案例：基于.NET的批量图像生成服务平台

1. 引言

想象一下，一家电商公司每天需要为上千个商品生成主图、详情页配图和社交媒体海报。传统做法是设计师一张张做，耗时费力不说，风格还很难统一。或者一家内容创作机构，每周要产出几百张配图，团队加班加点也赶不上进度。

这就是很多企业面临的真实困境——图像内容的生产效率，成了业务增长的瓶颈。人工设计成本高、周期长，外包又难以保证质量和风格一致性。直到我们接触到一个客户，他们正被这个问题困扰着。

这家公司主要做跨境电商，每天要处理几百个新品上架。每个商品需要至少5张不同尺寸、不同风格的图片：主图、场景图、细节图、营销海报、社交媒体配图。团队3个设计师，每天最多能做50套图，新品积压成了常态。

后来他们找到了我们，问能不能用AI解决这个问题。我们调研了一圈，最后选择了GLM-Image，用.NET技术栈搭建了一套批量图像生成服务平台。结果呢？原来需要一周才能完成的图片任务，现在几个小时就搞定了。

这篇文章，我就来分享这个项目的完整落地过程，从技术选型到架构设计，再到实际效果，希望能给有类似需求的企业一些参考。

2. 为什么选择GLM-Image和.NET

2.1 GLM-Image的优势

当时我们评估了好几个图像生成模型，最终选择GLM-Image，主要是看中了它的几个特点。

首先是文字渲染能力特别强。做电商图最怕什么？怕文字生成得歪歪扭扭，怕中文字符显示不全。GLM-Image在文字渲染上表现很稳定，特别是中文，基本不会出现乱码或者错位的情况。这对我们做商品标签、价格标签、促销文案特别重要。

其次是知识密集型场景处理得好。比如生成电子产品图，它能把产品的细节、结构表现得比较准确，不会出现“手机有八个摄像头”这种离谱的错误。对于服装类商品，也能理解不同款式的特点，生成符合描述的图像。

还有一个很重要的点是，GLM-Image支持比较灵活的尺寸和风格控制。我们可以根据不同的平台要求，生成不同尺寸的图片，还能统一风格，让所有商品图看起来像是一个系列。

2.2 .NET技术栈的考量

为什么用.NET？这跟我们的技术背景和客户需求都有关系。

客户现有的系统大部分都是基于.NET开发的，有成熟的运维团队，用.NET可以无缝集成，减少学习成本。而且.NET Core的性能表现一直不错，特别是处理高并发请求的时候，内存管理和线程调度都比较高效。

我们之前用Python做过类似的项目，发现当并发量上去之后，内存占用是个问题。.NET在这方面控制得更好，特别是长时间运行的服务，稳定性更高。

还有一个实际考虑是部署环境。客户的生产环境是Windows Server，用.NET部署起来最方便，不需要额外的容器化改造。虽然我们也考虑了Docker，但考虑到团队熟悉程度，还是选择了最直接的部署方式。

3. 系统架构设计

3.1 整体架构

整个平台的设计思路很简单：把复杂的AI调用封装成简单的服务接口，让业务系统能够像调用普通API一样使用图像生成能力。

我们采用了典型的分层架构，从下往上分别是：

• 数据层：负责存储任务信息、图片元数据、生成记录
• 服务层：核心的业务逻辑，包括任务调度、参数处理、模型调用
• 接口层：对外提供RESTful API，支持各种客户端调用
• 管理后台：用于监控任务状态、配置参数、查看生成结果

最核心的是服务层，这里我们设计了一个任务队列系统。所有生成请求都先进入队列，然后由工作进程按顺序处理。这样做的好处是能控制并发量，避免一下子把模型服务打垮。

3.2 关键技术组件

在.NET技术栈的选择上，我们用了几个比较成熟的框架。

ASP.NET Core做Web API，这是.NET生态里最成熟的Web框架，性能好，生态丰富。我们用它的最小API模式，代码写起来很简洁。

对于任务队列，我们一开始考虑用Hangfire，但后来发现需求没那么复杂，就自己实现了一个简单的内存队列加后台服务。用BackgroundService配合Channel，实现起来也不麻烦。

数据库用了SQL Server，主要是客户那边已经有现成的集群，运维团队比较熟悉。其实用PostgreSQL或者MySQL也行，看团队的技术栈。

图片存储这块，我们用了Azure Blob Storage。一方面是因为客户的其他业务也在用Azure，另一方面是Blob Storage的CDN集成比较方便，生成完的图片可以直接通过CDN分发。

4. 核心实现细节

4.1 任务调度系统

任务调度是整个平台的核心，我们设计了一个相对简单的状态机模型。

每个生成任务有这么几个状态：等待中、处理中、成功、失败、取消。任务进来后先进入等待队列，工作进程从队列里取任务，更新状态为处理中，然后开始调用GLM-Image API。

这里有个细节，我们设置了重试机制。如果一次调用失败了，会根据错误类型决定是否重试。比如网络超时会重试3次，但如果是参数错误就直接失败，重试也没用。

代码实现大概长这样：

public class ImageGenerationService : BackgroundService
{
    private readonly Channel<GenerationTask> _taskQueue;
    private readonly IGLMImageClient _glmClient;
    private readonly ILogger<ImageGenerationService> _logger;
    
    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        await foreach (var task in _taskQueue.Reader.ReadAllAsync(stoppingToken))
        {
            try
            {
                await ProcessTaskAsync(task, stoppingToken);
            }
            catch (Exception ex)
            {
                _logger.LogError(ex, "处理任务失败: {TaskId}", task.Id);
                await UpdateTaskStatusAsync(task.Id, TaskStatus.Failed, ex.Message);
            }
        }
    }
    
    private async Task ProcessTaskAsync(GenerationTask task, CancellationToken ct)
    {
        // 更新状态为处理中
        await UpdateTaskStatusAsync(task.Id, TaskStatus.Processing);
        
        // 调用GLM-Image API
        var result = await _glmClient.GenerateImageAsync(
            task.Prompt,
            task.Parameters,
            ct);
            
        // 保存生成的图片
        var imageUrl = await SaveImageAsync(result.ImageData);
        
        // 更新任务结果
        await CompleteTaskAsync(task.Id, imageUrl);
    }
}

4.2 GLM-Image API封装

调用GLM-Image API的部分，我们封装了一个专门的客户端类。这样做的目的是把AI服务的细节隐藏起来，业务代码只需要关心生成什么图片，不用管怎么调API。

封装的时候主要处理了几个问题：

第一是超时控制。图像生成比较耗时，我们设置了合理的超时时间，避免请求卡住。第二是错误处理，把API返回的各种错误转换成业务能理解的异常。第三是参数验证，确保传给API的参数都是合法的。

public class GLMImageClient : IGLMImageClient
{
    private readonly HttpClient _httpClient;
    private readonly ILogger<GLMImageClient> _logger;
    
    public async Task<ImageGenerationResult> GenerateImageAsync(
        string prompt, 
        GenerationParameters parameters,
        CancellationToken cancellationToken = default)
    {
        // 构建请求
        var request = new
        {
            model = "glm-image",
            prompt = prompt,
            size = parameters.Size,
            style = parameters.Style,
            quality = parameters.Quality,
            num_images = parameters.NumberOfImages
        };
        
        // 发送请求
        var response = await _httpClient.PostAsJsonAsync(
            "/v1/images/generations",
            request,
            cancellationToken);
            
        if (!response.IsSuccessStatusCode)
        {
            var errorContent = await response.Content.ReadAsStringAsync(cancellationToken);
            _logger.LogError("GLM-Image API调用失败: {StatusCode}, {Error}", 
                response.StatusCode, errorContent);
            throw new GLMImageException($"API调用失败: {response.StatusCode}");
        }
        
        // 解析响应
        var result = await response.Content.ReadFromJsonAsync<GLMImageResponse>(
            cancellationToken: cancellationToken);
            
        return new ImageGenerationResult
        {
            ImageData = Convert.FromBase64String(result.Data.Image),
            Format = result.Data.Format,
            Size = result.Data.Size
        };
    }
}

4.3 批量处理优化

批量处理是提升效率的关键。我们不是一张一张地生成，而是把相似的任务打包处理。

比如同一个商品的不同尺寸图片，描述词都差不多，只是尺寸参数不同。我们可以一次生成多张，减少API调用次数。或者同一个营销活动的多张海报，风格一致，只是文案不同，也可以批量处理。

这里我们实现了一个任务分组策略。系统会自动识别可以合并的任务，把它们打包成一个批次。批次处理完成后，再拆分成单个任务结果返回给客户端。

public class BatchProcessor
{
    public List<GenerationBatch> GroupTasks(List<GenerationTask> tasks)
    {
        var batches = new List<GenerationBatch>();
        
        // 按业务类型分组
        var groupedByBusiness = tasks.GroupBy(t => t.BusinessType);
        
        foreach (var group in groupedByBusiness)
        {
            // 每个业务类型内，再按风格和尺寸分组
            var subGroups = group.GroupBy(t => new 
            { 
                t.Parameters.Style,
                t.Parameters.Size 
            });
            
            foreach (var subGroup in subGroups)
            {
                // 如果数量少，直接单独处理
                if (subGroup.Count() <= 3)
                {
                    batches.AddRange(subGroup.Select(t => 
                        new GenerationBatch { Tasks = new[] { t } }));
                    continue;
                }
                
                // 数量多，打包成批次
                var batchSize = CalculateOptimalBatchSize(subGroup.Count());
                var chunkedTasks = subGroup.Chunk(batchSize);
                
                foreach (var chunk in chunkedTasks)
                {
                    batches.Add(new GenerationBatch { Tasks = chunk.ToArray() });
                }
            }
        }
        
        return batches;
    }
}

5. 实际应用场景

5.1 电商商品图批量生成

这是我们客户最主要的使用场景。他们有一个商品信息管理系统，里面存着所有商品的标题、描述、属性等信息。

我们接入了这个系统，当有新商品上架时，自动触发图片生成流程。系统会根据商品类目选择不同的模板和风格。

比如服装类商品，会生成模特展示图、平铺图、细节图。电子产品会生成场景使用图、功能特写图、尺寸对比图。

这里有个小技巧，我们不是简单地把商品描述扔给模型，而是会先加工一下。系统里预置了很多提示词模板，根据商品类目选择合适的模板，然后把商品信息填充进去。

public class PromptBuilder
{
    public string BuildProductPrompt(Product product, ImageTemplate template)
    {
        var prompt = template.BasePrompt;
        
        // 替换变量
        prompt = prompt.Replace("{{product_name}}", product.Name);
        prompt = prompt.Replace("{{product_description}}", product.Description);
        prompt = prompt.Replace("{{product_features}}", 
            string.Join(", ", product.Features));
        
        // 添加风格指令
        if (!string.IsNullOrEmpty(template.Style))
        {
            prompt += $", {template.Style} style";
        }
        
        // 添加质量要求
        prompt += ", high quality, detailed, professional photography";
        
        return prompt;
    }
}

5.2 营销素材自动化生产

除了商品图，客户还需要大量的营销素材。比如节日促销海报、社交媒体配图、邮件营销图片等。

这些素材的特点是时效性强，需求量大。以前都是提前很久开始准备，现在可以按需生成。

我们设计了一个素材库系统，里面存着各种模板。运营人员只需要选择模板，输入文案，系统就能在几分钟内生成几十张不同尺寸、不同风格的图片。

比如双十一活动，需要生成一批促销海报。运营在后台选择“双十一促销模板”，输入活动主题、促销信息、时间等，系统就能批量生成横版、竖版、方形等各种尺寸的图片，适配网站、APP、微信、微博等不同渠道。

5.3 个性化内容创作

还有一个比较有意思的应用是个性化内容创作。客户做的是跨境电商，需要针对不同地区的用户生成本地化的内容。

比如同一款产品，在欧美市场可能强调科技感、设计感，在东南亚市场可能强调性价比、实用性。系统可以根据用户的地理位置、浏览历史等信息，生成个性化的产品介绍图。

我们接入了用户行为分析系统，根据用户的偏好调整生成策略。喜欢简约风格的，就生成干净清爽的图片；喜欢详细说明的，就生成带有很多标注和说明的图片。

6. 效果与收益

6.1 效率提升

这个项目上线后，效果比我们预期的还要好。

最直接的变化是图片生产效率。原来3个设计师每天最多做50套图，现在系统一天能生成500套，而且是不间断工作。遇到大促期间，峰值能达到每天2000套。

时间成本也大幅降低。原来一个商品从文案到出图，平均需要2-3天，现在缩短到2-3小时。紧急需求甚至能做到半小时内出图。

人力成本方面，虽然系统不能完全替代设计师，但把设计师从重复劳动中解放出来了。他们现在主要做创意设计、模板优化、质量审核这些更有价值的工作。

6.2 质量与一致性

很多人担心AI生成的质量不如人工，其实在我们的场景里，质量反而更稳定了。

人工设计会有状态波动，不同设计师水平也不一样。AI生成虽然每张图都有细微差别，但整体质量在一个比较稳定的水平线上。

风格一致性是另一个优势。我们通过模板和参数控制，能保证同一个活动、同一个品牌的所有图片风格统一。这在品牌营销中特别重要。

6.3 成本分析

从成本角度算一笔账。

原来客户每年在图片设计上的投入，包括人力成本和外包费用，大概在200万左右。系统开发加一年的运维成本，大概50万。API调用费用，按现在的使用量算，一年大概30万。

总成本80万，比原来节省了120万。这还没算效率提升带来的业务增长收益。

而且这个成本结构很有意思。固定成本（开发和运维）是一次性的，可变成本（API调用）跟业务量正相关。业务量越大，单张图的成本越低。

7. 遇到的挑战与解决方案

7.1 技术挑战

做这个项目的过程中，我们也遇到了不少问题。

第一个问题是API的稳定性。虽然GLM-Image的整体表现不错，但偶尔会有响应慢或者失败的情况。我们的解决方案是多级重试和降级处理。

如果主要服务不可用，会自动切换到备用服务。如果所有服务都不可用，就把任务挂起，等恢复后再处理。我们还设置了监控告警，一旦失败率超过阈值就立即通知运维。

第二个问题是生成结果的不确定性。AI生成毕竟有随机性，有时候出来的图跟预期差别比较大。我们通过几个方法来控制：

一是优化提示词模板，写得越详细、越具体，结果越可控。二是设置参数约束，比如尺寸、比例、风格这些硬性要求。三是加入人工审核环节，对重要图片进行人工把关。

7.2 业务适配

技术问题好解决，业务适配反而更麻烦。

最大的挑战是改变工作流程。原来设计师主导的流程，要变成系统主导的流程，很多人不适应。我们花了很长时间做培训，设计新的协作方式。

另一个挑战是质量标准的统一。原来每个人对“好图”的标准不一样，现在要用系统来生成，就必须把标准量化。我们跟客户一起制定了详细的质量评估标准，包括构图、色彩、清晰度、符合度等多个维度。

7.3 性能优化

随着使用量的增加，性能问题也逐渐显现。

最明显的是内存占用。.NET应用本身还好，但图片处理比较耗内存。我们做了几处优化：一是及时释放不再使用的图片数据，二是调整GC策略，三是增加了内存监控和自动重启机制。

另一个是数据库压力。任务记录、图片元数据这些数据量增长很快。我们做了分表分库，把历史数据归档到冷存储，只保留最近三个月的数据在热库中。

8. 总结与展望

回过头来看这个项目，我觉得最大的价值不是技术多先进，而是真正解决了业务问题。客户从“图片不够用”到“图片用不完”，这个转变对业务的影响是实实在在的。

技术层面，.NET和GLM-Image的组合证明是可行的。.NET的稳定性和性能足够支撑企业级应用，GLM-Image的图像生成能力也能满足大部分商业需求。特别是文字渲染和中文支持，比一些国外模型要好用得多。

未来我们计划在几个方向继续优化：

一个是提示词优化。现在还是靠人工写模板，后面想用AI来优化提示词，根据生成结果自动调整提示词，让效果越来越好。

另一个是多模型支持。GLM-Image虽然不错，但有些场景可能需要其他模型。我们正在设计一个模型路由层，可以根据任务类型自动选择最合适的模型。

还有一个是工作流集成。现在主要是图片生成，后面想把修图、排版、审核这些环节也自动化，形成完整的图片生产流水线。

如果你也在考虑用AI来提升图像内容的生产效率，我的建议是先从一个小场景开始试。不用一开始就做很复杂的系统，先解决一个具体问题，验证效果，再逐步扩展。技术选型上，选团队熟悉的、生态成熟的，这样落地会快很多。

---

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。