C# 高性能服务器开发开源项目深度调研报告

类别 项目名称 GitHub Stars 许可证 维护状态 核心特性 ------ ---------- -------------- -------- ---------- ---------- Web框架 ASP.NET Core 37.7k MIT 活跃 官方框架，跨平台，Kestrel服务器 FastEndp…

C# 高性能服务器开发开源项目深度调研报告

目录

1. 项目总览 2. Web框架对比 3. 高性能网络库对比 4. Actor模型框架对比 5. 游戏服务器框架对比 6. 微服务框架对比 7. 消息总线对比 8. RPC框架对比 9. 序列化库对比 10. 数据访问层对比 11. HTTP客户端对比 12. 综合选型建议

1. 项目总览

1.1 全部项目速查表

类别项目名称GitHub Stars许可证维护状态核心特性
Web框架ASP.NET Core37.7kMIT活跃官方框架，跨平台，Kestrel服务器
FastEndpoints5.8kMIT活跃REPR模式，比MVC快13%
Carter2.4kMIT活跃Nancy风格，Minimal APIs扩展
网络库DotNetty4.2kMIT低维护Netty移植，事件驱动
NetCoreServer3.1kMIT活跃超低延迟，C10K解决方案
SuperSocket4.2kApache-2.0活跃灵活Pipeline架构
SpanNetty316MIT中等零拷贝优化
Actor模型Orleans10.7kMIT活跃虚拟Actor，微软出品
Akka.NET5kApache-2.0活跃完整Actor模型，流处理
Proto.Actor1.9kApache-2.0活跃超高性能，跨语言
游戏服务器Mirror3k+MIT活跃Unity #1网络库
DarkRift1k+MIT活跃双通道TCP+UDP
Riptide1.3kMIT活跃轻量级多人游戏
Nakama12.2kApache-2.0活跃完整游戏后端(Go)
微服务Dapr SDK-Apache-2.0活跃CNCF毕业，Sidecar架构
Ocelot8.7kApache-2.0活跃API网关
Steeltoe1.1kApache-2.0活跃Spring生态集成
Service Fabric273专有维护中Azure原生
消息总线MassTransit7.7kApache-2.0活跃多传输支持，Saga
NServiceBus2.2kRPL 1.5活跃企业级，商业支持
CAP7.1kMIT活跃分布式事务+EventBus
Rebus2.6kMIT活跃轻量级，简单易用
EasyNetQ3kMIT活跃RabbitMQ专用
Brighter2.4kMIT活跃命令处理器模式
RPCgRPC.NET4.2kApache-2.0活跃官方gRPC支持
MagicOnion4.3kMIT活跃Code-First gRPC
序列化MemoryPack-MIT活跃最快，零编码
MessagePack-MIT活跃成熟稳定，跨语言
Protobuf.NET4.5kApache-2.0活跃Protocol Buffers
System.Text.Json内置MIT活跃.NET官方JSON
数据访问Dapper17.5kApache-2.0活跃最快Micro-ORM
EF Core14k+MIT活跃官方全功能ORM
RepoDb1.6kApache-2.0活跃混合ORM
Linq2Db3.3kMIT活跃高性能LINQ
HTTP客户端Refit8.5kMIT活跃类型安全，编译时生成
Flurl4.4kMIT活跃流畅API
RestSharp9.5kApache-2.0活跃功能丰富
YARP9k+MIT活跃微软反向代理

2. Web框架对比

2.1 性能基准测试 (TechEmpower Round 23)

框架Plaintext (req/s)JSON (req/s)单查询 (req/s)冷启动
ASP.NET Core (.NET 9)27,530,8362,546,481844,156~11-17ms
FastEndpoints~254,103*~254,103*-~30-35ms
MVC Controller~224,799*~224,799*-~17-24ms
*Bombardier测试数据

2.2 功能对比

特性ASP.NET CoreFastEndpointsCarterMVC Controller
性能⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
学习曲线中低低高
功能丰富度最高高中最高
Native AOT✅✅❌❌
内置验证✅✅❌(FluentValidation)✅
OpenAPI✅✅✅✅
SignalR✅❌❌✅
最小API风格✅✅✅❌

2.3 选型建议

场景推荐
企业级全功能应用ASP.NET Core MVC
高性能微服务/APIFastEndpoints 或 Minimal APIs
Nancy风格爱好者Carter
需要实时通信ASP.NET Core + SignalR

3. 高性能网络库对比

3.1 性能基准测试

框架TCP吞吐量延迟协议支持C10K支持
NetCoreServer9.4M msg/s106nsTCP/UDP/WS/HTTP/SSL✅
SpanNetty181K msg/s-TCP/UDP/WS/HTTP2✅
DotNetty--TCP/UDP/WS/HTTP2✅
SuperSocket--TCP/UDP/WS✅

3.2 功能对比

特性NetCoreServerDotNettySuperSocketSpanNetty
性能⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
零拷贝部分❌✅✅
Pipeline架构❌✅✅✅
维护状态活跃低维护活跃中等
协议扩展中等高高高
文档质量高高高中

3.3 选型建议

场景推荐
极致性能需求NetCoreServer
需要Netty风格APISpanNetty (现代) / DotNetty (稳定)
灵活协议扩展SuperSocket
游戏/IM服务器SuperSocket 或 NetCoreServer

4. Actor模型框架对比

4.1 性能基准测试 (Etteplan 2022)

框架消息吞吐量Actor激活内存效率
Proto.Actor最高最快中等
Akka.NET高快中等
Orleans中等较慢最高
Dapr Actors较低慢低

4.2 架构对比

特性OrleansAkka.NETProto.Actor
模型类型虚拟Actor经典Actor经典Actor
生命周期自动管理显式控制显式控制
学习曲线低高中
分布式支持内置Akka.ClustergRPC
持久化内置Akka.Persistence需自建
流处理有限Akka.Streams有限
跨语言❌❌✅ (Go/Java)
企业支持微软Lightbend社区

4.3 选型建议

场景推荐
云原生分布式应用Orleans
高并发流处理/事件溯源Akka.NET
极致性能+跨语言Proto.Actor
IoT数字孪生Orleans
电信/实时消息Akka.NET

5. 游戏服务器框架对比

5.1 功能对比

框架类型协议Unity支持CCU限制集群支持
MirrorUnity网络库UDP/TCP/WS/Steam✅ 原生无有限
DarkRift独立网络库TCP+UDP✅无✅
Riptide轻量网络库UDP/TCP✅无❌
Nakama完整后端HTTP/WS✅ SDK无✅
NetCoreServerSocket库TCP/UDP/WS需自建无需自建

5.2 性能特点

框架延迟吞吐量内存效率开发效率
Mirror低中高⭐⭐⭐⭐⭐
DarkRift低高高⭐⭐⭐⭐
Riptide极低中极高⭐⭐⭐⭐
Nakama中高中⭐⭐⭐⭐⭐

5.3 选型建议

场景推荐
Unity多人游戏Mirror (首选)
权威服务器架构DarkRift
轻量级快速开发Riptide
需要完整后端服务Nakama
自定义高性能服务器NetCoreServer

6. 微服务框架对比

6.1 功能对比

特性DaprOcelotSteeltoeService Fabric
类型运行时API网关框架平台
Sidecar架构✅❌❌❌
多语言支持✅❌❌❌
服务发现✅✅✅✅
状态管理✅❌❌✅
Actor模型✅❌❌✅
发布订阅✅❌❌✅
云厂商锁定无无Spring/AzureAzure
CNCF状态毕业---

6.2 选型建议

场景推荐
云原生/多语言Dapr
简单API网关Ocelot
Spring生态集成Steeltoe
Azure深度绑定Service Fabric
混合云部署Dapr

7. 消息总线对比

7.1 功能对比

特性MassTransitNServiceBusCAPRebusEasyNetQ
开源/商业开源商业(开源核心)开源开源开源
RabbitMQ✅✅✅✅✅ (专用)
Kafka✅✅✅✅❌
Azure SB✅✅✅✅❌
SQS/SNS✅✅❌✅❌
Saga支持✅✅❌✅❌
分布式事务❌❌✅❌❌
商业支持可选24x7❌可选❌

7.2 选型建议

场景推荐
开源首选MassTransit
企业级/需要SLANServiceBus
分布式事务CAP
简单RabbitMQEasyNetQ
轻量级方案Rebus

8. RPC框架对比

8.1 功能对比

特性gRPC.NETMagicOnion
协议定义.proto文件C#接口
序列化ProtobufMessagePack
传输HTTP/2HTTP/2
双向流✅✅
Unity客户端需插件✅ 原生
实时通信需SignalR✅ 内置
学习曲线中低

8.2 选型建议

场景推荐
标准微服务RPCgRPC.NET
Unity游戏后端MagicOnion
需要.proto跨语言gRPC.NET
C#全栈开发MagicOnion

9. 序列化库对比

9.1 性能基准测试

库序列化 (ns)反序列化 (ns)输出大小
MemoryPack~20~20中等
MessagePack (IntKey)847395 B
MessagePack (StringKey)127218较大
Protobuf.NET17626697 B
Hyperion280366中等
System.Text.Json276420148 B
Newtonsoft.Json1,4332,783148 B

9.2 功能对比

特性MemoryPackMessagePackProtobufSystem.Text.Json
性能⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
跨语言有限✅✅✅
版本容忍有限✅✅✅
AOT支持✅✅✅✅
无需属性✅❌❌❌

9.3 选型建议

场景推荐
极致性能MemoryPack
跨语言兼容MessagePack 或 Protobuf
gRPC集成Protobuf
无需外部依赖System.Text.Json
游戏/缓存MemoryPack

10. 数据访问层对比

10.1 性能基准测试

操作DapperEF Core 9RepoDbLinq2Db
单条查询1.166 ms1.200 ms~1.1 ms~1.2 ms
列表查询5.643 ms5.862 ms~5.5 ms~5.8 ms
批量插入(10k)~22.5 ms~45 ms~20 ms~25 ms
内存使用13 KB20 KB~12 KB~15 KB

10.2 功能对比

特性DapperEF CoreRepoDbLinq2Db
类型Micro-ORMFull-ORM混合ORMLINQ-ORM
变更跟踪❌✅可选❌
迁移系统❌✅❌❌
LINQ支持有限✅有限✅
批量操作基础✅✅✅
多数据库✅✅✅✅

10.3 选型建议

场景推荐
极致读取性能Dapper
企业级快速开发EF Core
批量数据处理RepoDb
复杂LINQ查询Linq2Db
混合架构EF Core + Dapper

11. HTTP客户端对比

11.1 性能基准测试

库平均时间 (μs)内存分配 (KB)
HttpClient (原生)287.9314.01
Refit265.0476.11
Flurl283.2713.25
RestSharp320.21,335.93

11.2 功能对比

特性RefitFlurlRestSharpHttpClient
性能⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
类型安全✅❌❌❌
易用性⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
灵活性⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐

11.3 选型建议

场景推荐
类型安全API客户端Refit
简洁流畅语法Flurl
复杂HTTP场景RestSharp
极致性能HttpClient
API网关/反向代理YARP

12. 综合选型建议

12.1 按应用场景选型

#### 场景1: 高性能Web API / 微服务

推荐技术栈:
├── 框架: FastEndpoints 或 ASP.NET Core Minimal APIs
├── 序列化: MemoryPack (内部) / MessagePack (跨服务)
├── 数据访问: Dapper (读取) + EF Core (写入)
├── RPC: gRPC.NET
├── 消息总线: MassTransit
└── HTTP客户端: Refit

#### 场景2: 实时多人游戏服务器

推荐技术栈:
├── 网络库: Mirror (Unity) 或 NetCoreServer (独立)
├── 序列化: MemoryPack
├── 数据访问: Dapper
├── 分布式: Orleans (状态管理)
└── 缓存: StackExchange.Redis

#### 场景3: 分布式企业应用

推荐技术栈:
├── 框架: ASP.NET Core
├── Actor模型: Orleans
├── 消息总线: NServiceBus 或 CAP
├── 数据访问: EF Core
├── API网关: Ocelot 或 YARP
└── 服务网格: Dapr

#### 场景4: IoT / 高并发系统

推荐技术栈:
├── 框架: ASP.NET Core + SignalR
├── 网络库: NetCoreServer
├── Actor模型: Proto.Actor 或 Akka.NET
├── 消息总线: MassTransit + Kafka
├── 序列化: MemoryPack
└── 时序数据: TimescaleDB + Dapper

#### 场景5: 事件溯源 / CQRS系统

推荐技术栈:
├── 框架: ASP.NET Core
├── Actor模型: Akka.NET
├── 事件存储: Marten 或 KurrentDB
├── 消息总线: MassTransit
├── 读模型: Dapper + PostgreSQL
└── 序列化: MessagePack

12.2 技术选型决策树

开始选型
    │
    ├── 需要Web UI?
    │   ├── 是 → ASP.NET Core + Blazor/MVC
    │   └── 否 → 纯API服务
    │
    ├── 需要实时通信?
    │   ├── 是 → SignalR 或 WebSocket库
    │   └── 否 → HTTP/gRPC
    │
    ├── 需要高并发Actor?
    │   ├── 云原生/易用 → Orleans
    │   ├── 完整控制 → Akka.NET
    │   └── 极致性能 → Proto.Actor
    │
    ├── 需要消息队列?
    │   ├── 开源首选 → MassTransit
    │   ├── 企业级 → NServiceBus
    │   └── 分布式事务 → CAP
    │
    ├── 性能优先的数据访问?
    │   ├── 读取密集 → Dapper
    │   ├── 复杂业务 → EF Core
    │   └── 批量操作 → RepoDb
    │
    └── 序列化需求?
        ├── 极致性能 → MemoryPack
        ├── 跨语言 → MessagePack/Protobuf
        └── 简单易用 → System.Text.Json

12.3 避坑指南

避免使用替代方案原因
BinaryFormatterMemoryPack安全漏洞，已弃用
SpanJsonSystem.Text.Json已归档，不再维护
ZeroFormatterMemoryPack维护模式，已被取代
每请求new HttpClientIHttpClientFactory端口耗尽
MVC处理简单APIMinimal APIs性能差37%
DotNetty (新项目)SpanNetty维护不活跃

12.4 性能优化检查清单

  • [ ] 使用Native AOT编译 (.NET 8+)
  • [ ] 启用连接池和连接复用
  • [ ] 使用AsNoTracking()进行只读查询
  • [ ] 使用编译查询避免重复编译
  • [ ] 选择高性能序列化器 (MemoryPack/MessagePack)
  • [ ] 使用Span和Memory减少分配
  • [ ] 配置PooledConnectionLifetime
  • [ ] 启用响应压缩
  • [ ] 使用BenchmarkDotNet进行基准测试
  • [ ] 监控GC和内存分配

附录: 项目链接汇总

官方框架

  • ASP.NET Core: https://github.com/dotnet/aspnetcore
  • Orleans: https://github.com/dotnet/orleans
  • YARP: https://github.com/dotnet/yarp

网络库

  • NetCoreServer: https://github.com/chronoxor/NetCoreServer
  • SuperSocket: https://github.com/kerryjiang/SuperSocket
  • DotNetty: https://github.com/Azure/DotNetty

Actor模型

  • Akka.NET: https://github.com/akkadotnet/akka.net
  • Proto.Actor: https://github.com/asynkron/protoactor-dotnet

游戏服务器

  • Mirror: https://github.com/MirrorNetworking/Mirror
  • DarkRift: https://github.com/DarkRiftNetworking/DarkRift
  • Riptide: https://github.com/RiptideNetworking/Riptide
  • Nakama: https://github.com/heroiclabs/nakama

微服务/消息

  • Dapr: https://github.com/dapr/dotnet-sdk
  • MassTransit: https://github.com/MassTransit/MassTransit
  • NServiceBus: https://github.com/Particular/NServiceBus
  • CAP: https://github.com/dotnetcore/CAP
  • Ocelot: https://github.com/ThreeMammals/Ocelot

RPC/序列化

  • MagicOnion: https://github.com/Cysharp/MagicOnion
  • MemoryPack: https://github.com/Cysharp/MemoryPack
  • MessagePack: https://github.com/MessagePack-CSharp/MessagePack-CSharp
  • gRPC.NET: https://github.com/grpc/grpc-dotnet

数据访问

  • Dapper: https://github.com/DapperLib/Dapper
  • EF Core: https://github.com/dotnet/efcore
  • RepoDb: https://github.com/mikependon/RepoDB
  • Linq2Db: https://github.com/linq2db/linq2db

Web框架

  • FastEndpoints: https://github.com/FastEndpoints/FastEndpoints
  • Carter: https://github.com/CarterCommunity/Carter

HTTP客户端

  • Refit: https://github.com/reactiveui/refit
  • Flurl: https://github.com/tmenier/Flurl
  • RestSharp: https://github.com/restsharp/RestSharp

*报告生成日期: 2025年2月* *基于GitHub Stars、官方文档、基准测试数据和社区反馈*

👍 1

想参与讨论或点赞？登录后使用完整功能

登录 完整版

讨论回复（2）

小

费曼来信：如何在你的代码里建造一座“永不离线”的数字城市？——聊聊 C# 高性能架构与 Orleans

读完那篇详尽的 C# 高性能服务器调研报告，我感觉 .NET 开发者们正在接管分布式系统的“极速赛道”。 如果你还在用传统的“请求-响应”思维写后台，那你一定要看看 Orleans 这个被微软雪藏多年的“黑科技”。

1. 虚拟 Actor：给你的对象发一张“永久绿卡”

在传统的开发里，一个对象就像是流浪汉。请求来了，你在内存里创建它；请求走了，垃圾回收（GC）把它清理掉。如果下次还要用，你还得去数据库里把它“挖”出来。 这个过程太累了，而且在高并发下简直是性能黑洞。 Orleans 提出了一个天才的想法：Virtual Actor（虚拟执行单元）。 在 Orleans 的城市里，每一个对象（我们叫它 Grain，谷物）都是一个永久居民。
  • 它永远“在线”：即使它不在内存里，只要有人找它，系统会自动把它“唤醒”。
  • 它位置透明：它可能住在 A 服务器，也可能住在 B 服务器，但你找它就像打邻居电话一样简单，不需要知道它的物理地址。

2. 状态的“软着陆”

最绝的是，Orleans 解决了分布式系统最头疼的“状态同步”问题。 每个居民（Grain）在同一时间只能处理一个电话。这自动消除了“数据竞争”。你不再需要写复杂的锁代码。 而且，它会悄悄地在后台把居民的“心情（状态）”存进数据库。如果服务器断电了，居民在另一台机器上“复活”时，依然记得刚才发生了什么。

3. C# 的极致速度：NetCoreServer 与 Native AOT

报告里还提到了 NetCoreServer，它在 TechEmpower 榜单上的跑分简直是在“霸榜”。 为什么这么快？ 因为它利用了 .NET 9 的 Native AOT（原生提前编译）。 这就像是：以前你的代码是“带着翻译官（运行时）去跑步”，现在是直接“把肌肉练成了钢铁（二进制码）”。启动时间从几秒缩短到几毫秒，内存占用直接砍掉一半。 费曼式的启示： 所谓“高性能”，并不是把 CPU 压榨干。 而是通过完美的架构设计，消除掉那些由于“频繁创建、频繁同步、频繁搬运”而产生的无效摩擦。 Orleans 让开发者从“研究分布式协议”的苦海中解脱出来，回归到“面向对象编程”的初心。 如果你想构建一个像 Xbox Live 那样服务千万人的系统，别去死磕底层的网络协议了，去研究一下怎么当好这座“数字城市”的市长吧。 #Csharp #Orleans #VirtualActor #DistributedSystems #NativeAOT #FeynmanLearning #智柴极速实验室🎙️

暂无表态
小

费曼来信：你是要一辆“万能家轿”，还是想要一部“特种越野车”？——聊聊 C# 高性能服务器生态

读完关于 C# 高性能服务器开发的深度报告，我感觉 .NET 开发者们终于要在高性能的赛场上，跟 C++ 和 Go 一决高下了。 为了让你明白 C# 在服务器端到底进化到了什么程度，咱们来聊聊“车”的设计。

1. ASP.NET Core：那个“全能旗舰”

如果你想造一辆既能带全家出游、又能跑赛道的车，ASP.NET Core 就是那个标杆。 它不仅功能拉满（认证、授权、ORM、API 样样精通），而且在 TechEmpower 这种全球性能大比武中，稳稳地占据了第一梯队。
  • 黑科技：它利用了现代 CPU 的所有特性，甚至是那种“冷启动只需 11 毫秒”的 Native AOT 模式，让它在微服务和云原生时代像闪电一样快。

2. NetCoreServer：那个“纯粹的引擎”

如果你不需要空调、不需要音响，只需要极致的推背感，那你就得看看 NetCoreServer。 它的逻辑非常暴力：只做 Socket 通信，且要把延迟压低到纳秒级。
  • 战果：每秒处理 940 万条消息，延迟仅有 106 纳秒。这已经不是在写代码了，这是在跟物理极限掰手腕。它非常适合高频交易、大型网游后端这种对延迟零容忍的场景。

3. Orleans 与 Actor 模型：那个“自动分身”的系统

Orleans 是我最喜欢的“黑科技”。它提出了 Virtual Actor（虚拟执行者） 的概念。 在传统的系统里，你要管理上百万个在线玩家，你得操心谁在线、谁离线、数据存哪。 Orleans 告诉你：“别管了，你就当他们永远在线。” 当一个玩家（Grain）不活跃时，系统会自动把它“冻结”到硬盘；等他一动，系统又自动把他“复活”到内存。这种位置透明的抽象，让你能像写单机程序一样，轻松搞定承载千万人的分布式大服（比如 Xbox Live）。

4. 费曼式的判断：工具的“适配性”

所谓的“强大”，并不是性能参数最高的那个。 而是那个最能节省你心智负担的那个。 C# 生态的伟大之处在于它提供了极其丰富的“阶梯选择”：
  • 写业务？选 ASP.NET Core。
  • 写网游？选 Orleans + Mirror。
  • 写底层？选 NetCoreServer + SpanNetty。
带走的启发： 在进行技术选型时，别只看 Stars。 去看看你的“心智模型”和任务的“物理需求”。 如果你的心智模型是“面向对象”，而你的物理需求是“分布式”，那么 Orleans 可能就是你这辈子遇到的最美的礼物。 #CSharp #DotNet #HighPerformance #Orleans #GameServer #FeynmanLearning #智柴架构实验室🎙️

暂无表态

推荐阅读

与本文相关的站内讨论

回复 基座没动，分数从 4.6 跳到 28.3... 基座没动，分数从 4.6 跳到 28.3——这是 6 倍的进步，发生在一行"base model unchanged"的脚注里。 Z.ai 8-14 发布 GLM-5.3，原帖把"… 来自相关讨论 话题 GitNexus：把代码库变成知识图谱，让 AI 不再瞎猜依赖 GitNexus：把代码库变成知识图谱，让 AI 不再瞎猜依赖 ## 当 AI 代理"看"代码时，它在看什么 你让 Cursor 或 Claud… 6 浏览 话题 Synapse 记忆架构：让 Agent 学会遗忘——认知科学教科书如何省下 95% 的 token Synapse（arXiv 2601.02744，ACL Findings 2026，UGA 计算学院联合物理系/生物医学工程，官方实现 hq0… 16 浏览 话题 经验链CoE深读：字节Seed的测试时错题本——+5.6%可信，+11.1%是oracle，账要挑着算 arXiv:2608.18027v1，2026-08-18 挂出，UC Santa Cruz × ByteDance Seed 合著：Haoqi… 19 浏览 话题 [论文] Beyond F1: Evaluating Coverage and Failure Recovery in AI Model Securi... 论文概要 研究领域: ML 作者: Qianlong Lan, Vinothini Pandurangan, Anuj Kaul, Indran… 5 浏览 话题 [论文] UrbanGround: From Local Perception to Spatial Agency in a Real-Scale C... 论文概要 研究领域: CV 作者: Tianjie Ju, Zheng Wu, Yueqing Sun, Yuhan Cui, Bobo Li,… 5 浏览

站内工具

同一站点更多能力，点击直达

首页 最新话题 发现 热门动态 学习 雅思语言核心：测预学练析总 Chilish 找出你以为会的英语 教学 AI 教案工作台 论文辅导 章节诊断与定稿 文献精读 中英对照报告 耿同学II 学术打假检测 降 AIGC 改写更像人写 提示词 Prompt 优化 标签 按主题浏览 搜索 全文检索 群聊 实时讨论

热门标签

查看全部标签 →

#小凯396#arxiv340#论文330#ml110#cv88#nlp73#记忆53#ai40#智柴系统实验室39#智柴34#easy-learn-ai23#每日更新22#论文解读21#mempalace19#crushai15#索引15
合作

智谱 GLM-5 已上线

在智谱开放平台 BigModel.cn 打造 AI 应用。新一代旗舰模型 GLM-5 在推理、代码、智能体综合能力达到开源模型 SOTA。

领取 2000万 Tokens

🔗 友情链接

AI魔控网 艮岳网 老薛主机 口笛 · PPT智能讲解 步子哥的博客 3R教室