构建智能安防监控平台:wvp-GB28181-pro全栈部署与最佳实践指南
一、技术架构与核心价值解析
1.1 平台架构设计与技术选型
wvp-GB28181-pro作为一款遵循国家标准GB/T 28181的开源视频监控平台,采用分层微服务架构设计,实现了设备接入、媒体处理、数据存储和应用展示的全流程解决方案。平台基于Java Spring Boot框架开发,核心技术栈包括:
- 接入层:支持GB28181、RTSP等多种协议的设备接入与协议转换
- 服务层:基于微服务架构的设备管理、媒体流处理、告警联动等核心业务功能
- 存储层:整合本地存储与云存储方案,支持视频流实时存储与历史回放
- 应用层:提供Web管理界面和RESTful API接口,支持二次开发与系统集成
系统采用消息队列和事件驱动架构实现模块间解耦,通过Redis缓存提升系统响应速度,确保在高并发场景下的稳定性与可扩展性。
1.2 核心功能模块解析
平台主要由五大核心组件构成,各组件协同工作实现完整的视频监控功能:
| 组件名称 | 核心功能 | 技术实现 | 性能指标 |
|---|---|---|---|
| SIP服务器 | 设备注册、认证与信令交互 | 基于JAIN-SIP协议栈 | 支持1000+设备并发注册 |
| 媒体服务器 | 音视频流转发、转码与分发 | 基于ZLMediaKit | 单节点支持200+路1080P并发流 |
| Web管理系统 | 设备管理、实时监控、录像回放 | Vue+Element UI | 支持16/32/64画面分割监控 |
| 关系型数据库 | 设备信息、配置参数存储 | MySQL/PostgreSQL | 支持百万级设备记录管理 |
| 缓存服务 | 会话管理、临时状态存储 | Redis | 平均响应时间<10ms |
1.3 适用场景分析
wvp-GB28181-pro平台凭借其灵活的架构设计和丰富的功能特性,可广泛应用于以下场景:
- 城市安防监控:支持大规模设备接入与集中管理,适用于智慧城市、平安城市建设
- 企业园区监控:提供分区管理、权限控制和智能告警,满足企业安全管理需求
- 交通枢纽监控:支持移动设备接入与轨迹追踪,适用于机场、车站等交通场景
- 教育医疗监控:提供隐私保护与权限细分,满足校园、医院等特殊场所需求
- 多级级联部署:支持市-区-街道多级平台级联,实现资源共享与集中管控
二、环境部署与基础配置实践
2.1 部署环境准备与兼容性测试
成功部署wvp-GB28181-pro平台需要满足以下软硬件环境要求:
硬件环境建议配置:
| 组件 | 最低配置 | 推荐配置 | 配置依据 |
|---|---|---|---|
| CPU | 四核2.0GHz | 八核2.8GHz | 媒体处理需要较高的CPU性能,转码功能尤其消耗资源 |
| 内存 | 8GB | 16GB | 并发视频流处理和缓存需要足够内存支持 |
| 硬盘 | 100GB SSD | 500GB SSD | 系统和缓存需要快速读写,视频存储建议单独配置存储阵列 |
| 网络 | 千兆网卡 | 万兆网卡 | 多路视频流传输带宽需求,每路1080P/25fps视频流约占用4-8Mbps |
软件环境依赖:
- JDK 1.8+(推荐OpenJDK 11)
- MySQL 5.7+ 或 PostgreSQL 9.6+
- Redis 4.0+
- Docker 19.03+ 和 Docker Compose 1.25+
- Nginx 1.16+(用于Web服务和反向代理)
[!NOTE] 平台在Linux系统(CentOS 7/8、Ubuntu 18.04/20.04)上表现最佳,Windows系统仅推荐用于开发测试环境,生产环境建议采用Linux服务器以获得更好的性能和稳定性。
2.2 项目获取与Docker快速部署
通过以下步骤可快速获取并部署wvp-GB28181-pro平台:
# 获取项目代码
git clone https://gitcode.com/GitHub_Trending/wv/wvp-GB28181-pro
cd wvp-GB28181-pro
# 进入Docker部署目录
cd docker
# 根据实际环境修改配置文件(可选但推荐)
# vim wvp/wvp/application.yml
# 启动服务
docker-compose up -d
# 检查服务状态
docker-compose ps
[!WARNING] 首次部署前请确保Docker服务已启动,且关键端口(18080、5060、1506等)未被占用。生产环境必须修改默认密码和敏感配置,建议通过环境变量注入敏感信息而非直接修改配置文件。
服务启动后,可通过访问http://服务器IP:18080打开Web管理界面,默认管理员账号为admin,密码为admin123。首次登录后请立即修改密码以保障系统安全。
2.3 数据库与缓存服务配置
数据库和缓存服务是平台稳定运行的核心支撑,以下是关键配置示例:
数据库配置(application.yml):
spring:
datasource:
url: jdbc:mysql://mysql:3306/wvp?useUnicode=true&characterEncoding=UTF-8&serverTimezone=Asia/Shanghai
username: root
password: SecurePassword123! # 生产环境必须修改此密码
driver-class-name: com.mysql.cj.jdbc.Driver
hikari:
maximum-pool-size: 20 # 连接池大小,根据并发量调整
minimum-idle: 5
idle-timeout: 300000
connection-timeout: 20000
Redis缓存配置(application.yml):
redis:
host: redis
port: 6379
password: RedisPassword456! # 如配置了Redis密码
database: 0
timeout: 2000ms
lettuce:
pool:
max-active: 16 # 最大连接数
max-idle: 8 # 最大空闲连接
min-idle: 4 # 最小空闲连接
max-wait: -1ms # 连接等待时间
[!NOTE] 数据库连接URL中的serverTimezone参数需与服务器时区保持一致,避免时间同步问题。Redis的max-active参数建议根据并发用户数和设备数量进行调整,一般每100路设备需要2-4个连接。
2.4 常见部署问题与解决方案
| 问题现象 | 可能原因 | 解决方案 |
|---|---|---|
| Docker容器启动后立即退出 | 配置文件错误或端口冲突 | 查看容器日志:docker logs 容器ID,检查端口占用情况 |
| 数据库连接失败 | 数据库服务未启动或连接参数错误 | 检查MySQL服务状态,验证用户名密码和数据库是否存在 |
| Web界面无法访问 | Nginx配置错误或端口映射问题 | 检查Nginx配置和Docker端口映射,验证防火墙规则 |
| 服务启动缓慢 | JVM内存配置不足 | 调整JVM参数,增加堆内存大小 |
| 容器间网络不通 | Docker网络配置问题 | 检查Docker网络是否创建,容器是否加入正确网络 |
三、核心功能配置与设备接入指南
3.1 国标服务端参数配置
作为GB28181协议的服务端,平台需要正确配置SIP相关参数以实现设备接入。以下是关键参数说明及配置界面:
图:国标服务端配置界面,标注了关键参数位置
核心参数配置示例:
sip:
# 服务端IP,必填,建议使用服务器内网IP
server-ip: 192.168.1.242
# 服务端端口,默认5060
server-port: 5060
# SIP域,通常为10位数字
domain: 6662000000
# 设备注册密码,建议包含大小写字母、数字和特殊符号
password: YourSecurePassword123!
# 心跳周期(秒)
heartbeat-interval: 60
# 最大心跳超时次数
max-heartbeat-timeout: 3
# 媒体传输模式,UDP/TCP
transport: UDP
# 信令超时时间(秒)
timeout: 30
[!WARNING] SIP服务器IP必须是设备可访问的地址,如部署在NAT环境下需配置端口映射并使用公网IP。注册密码应定期更换,且长度不应少于8位,包含多种字符类型。
3.2 设备接入流程与管理
设备接入平台需完成参数配置、注册验证和状态监控三个主要步骤:
设备端配置要点:
- 设备国标编码:需唯一,建议遵循GB/T 28181标准编码规则
- SIP服务器信息:填写平台IP、端口、域和认证密码
- 网络传输模式:局域网环境优先UDP,广域网建议使用TCP
- 心跳参数:与平台保持一致,通常为60秒
平台端设备添加流程:
- 登录Web管理界面,进入"设备管理"->"国标设备"页面
- 点击"添加设备"按钮,填写设备基本信息
- 设备国标编码:与设备端配置一致
- 设备名称:便于识别的名称
- 所属区域:选择设备所在的行政区划
- 传输协议:与设备端保持一致
- 点击"保存"完成添加,设备将自动尝试注册
- 在设备列表中查看设备在线状态,验证设备是否注册成功
图:设备列表界面,显示已接入设备状态和基本信息
3.3 通道管理与分组策略
为实现大规模设备的有效管理,平台提供了灵活的通道分类管理功能:
图:通道分类管理界面,支持按行政区划和业务分组管理设备
通道分组策略:
- 行政区划分组:按照省、市、区/县、街道等行政级别组织设备
- 业务类型分组:根据监控场景(如交通、安防、消防)进行分类
- 设备类型分组:按设备功能(如球机、枪机、NVR)进行管理
- 重要程度分组:根据监控重要性设置优先级
通道管理操作:
- 批量操作:支持批量修改、批量删除、批量启停
- 通道状态监控:实时显示在线状态、码流信息、存储状态
- 录像配置:为单个或多个通道配置录像计划
- 权限控制:为不同用户分配不同通道的查看和控制权限
3.4 设备接入常见问题
| 问题现象 | 可能原因 | 解决方案 |
|---|---|---|
| 设备注册失败 | 网络不通或SIP参数错误 | 检查网络连通性,核对SIP服务器IP、端口和密码 |
| 设备在线但无视频流 | 媒体端口被防火墙拦截 | 检查媒体端口范围(默认30000-30500)是否开放 |
| 视频画面卡顿 | 网络带宽不足或设备码率过高 | 降低视频码率或优化网络,广域网建议启用TCP传输 |
| 设备频繁离线 | 心跳参数设置不当或网络不稳定 | 调整心跳周期和超时次数,检查网络质量 |
| 通道列表不显示 | 设备未正确上报通道信息 | 手动触发设备目录查询,检查设备通道配置 |
四、高级应用场景与配置实例
4.1 平台级联部署方案
平台级联功能允许构建多级监控中心网络,适用于市-区-街道等层级化管理需求。级联部署通过GB28181协议实现上下级平台间的通信,实现资源共享和集中管理。
图:国标级联管理界面,显示上下级平台连接状态
级联部署配置要点:
- 上级平台信息配置:
cascade:
上级平台:
# 是否启用级联
enable: true
# 上级SIP服务器IP
sip-server-ip: 192.168.1.250
# 上级SIP服务器端口
sip-server-port: 5060
# 上级SIP域
domain: 6662000000
# 本地设备编号
device-id: 34020000002000000001
# 认证密码
password: CascadePassword123!
# 注册周期(秒)
register-interval: 3600
# 心跳周期(秒)
heartbeat-interval: 60
-
资源共享策略:
- 选择需要向上级平台共享的设备和通道
- 设置共享权限(查看、控制、录像回放等)
- 配置带宽限制和优先级
-
级联权限控制:
- 限制上级平台对本级资源的操作权限
- 设置操作日志记录和审计机制
- 配置级联中断时的本地处理策略
[!NOTE] 级联部署时,上下级平台的SIP域和设备编号应遵循统一规划,避免冲突。建议使用独立的网络带宽保障级联通信的稳定性。
4.2 移动视频监控优化配置
针对车载监控、移动执法等通过公网访问的场景,平台提供了专门的优化配置:
图:级联参数配置界面,标注了SIP服务器信息和认证参数
移动监控优化配置:
network:
# 传输模式,移动网络建议使用TCP
transport: TCP
# 超时设置
timeout:
connect: 10 # 连接超时(秒)
read: 30 # 读取超时(秒)
write: 10 # 写入超时(秒)
# 码率自适应配置
adaptive-bitrate:
enable: true
min-bitrate: 512 # 最低码率(kbps)
max-bitrate: 4096 # 最高码率(kbps)
adjust-interval: 5 # 调整间隔(秒)
# 流量控制
traffic-control:
enable: true
max-daily-traffic: 10240 # 每日最大流量(MB)
alert-threshold: 80 # 告警阈值(百分比)
移动场景优化策略:
- 网络传输优化:启用TCP传输模式,配置合适的超时重传参数
- 视频码率自适应:根据网络状况动态调整视频码率
- 流量控制策略:设置流量上限和告警机制,避免超额费用
- 本地缓存策略:配置网络中断时的本地录像缓存,网络恢复后自动上传
4.3 录像存储与回放配置
平台提供灵活的录像存储策略,支持计划录像、移动侦测录像和手动录像等多种模式:
录像计划配置示例:
record:
# 录像存储路径
storage-path: /data/record
# 录像保留天数
keep-days: 30
# 存储策略,local-本地存储,cloud-云存储,both-双存储
storage-strategy: both
# 计划录像配置
plan:
- device-id: 34020000001310000001
channels: [1,2,3] # 通道列表
time-ranges:
- start: "00:00"
end: "24:00"
week-days: [1,2,3,4,5,6,0] # 全部星期
- device-id: 34020000001310000002
channels: [1]
time-ranges:
- start: "08:00"
end: "18:00"
week-days: [1,2,3,4,5] # 工作日
录像回放功能:
- 支持按设备、通道、时间精确查询录像文件
- 提供常规回放、倍速回放、拖拽定位等操作
- 支持录像文件下载和剪辑
- 支持多通道同步回放,便于事件关联分析
[!WARNING] 录像存储需要大量磁盘空间,建议单独配置存储服务器或使用云存储服务。对于重要录像,建议启用双存储策略(本地+云存储)以提高数据安全性。
4.4 高级场景配置常见问题
| 问题现象 | 可能原因 | 解决方案 |
|---|---|---|
| 级联平台无法连接 | 网络不通或认证失败 | 检查网络连通性和级联密码,确认端口映射正确 |
| 移动监控画面卡顿 | 网络带宽不足 | 降低视频码率,启用码率自适应功能 |
| 录像文件丢失 | 存储配置错误或磁盘空间不足 | 检查存储路径权限和磁盘空间,查看录像服务日志 |
| 级联资源不同步 | 目录同步配置错误 | 手动触发目录同步,检查同步策略配置 |
| 回放视频花屏 | 视频文件损坏或编解码问题 | 检查存储介质,更新编解码库 |
五、系统优化与运维管理
5.1 性能优化策略
为确保平台在高并发场景下的稳定运行,需要从多个层面进行性能优化:
JVM优化:
编辑run.sh文件调整JVM参数:
# JVM参数优化
JAVA_OPTS="-server -Xms8g -Xmx8g -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m \
-XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:ParallelGCThreads=4 \
-XX:ConcGCThreads=2 -XX:InitiatingHeapOccupancyPercent=70 \
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/wvp/heapdump.hprof"
[!NOTE] Xms和Xmx建议设置为相同值避免内存波动,大小通常为物理内存的50%-70%。G1GC适合多CPU环境,能有效控制GC停顿时间,建议在生产环境使用。
数据库优化:
MySQL配置优化建议:
[mysqld]
# 连接数设置
max_connections = 500
max_user_connections = 450
# 缓存设置
key_buffer_size = 256M
query_cache_size = 64M
innodb_buffer_pool_size = 2G
# 日志设置
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 2
# 线程设置
thread_cache_size = 50
table_open_cache = 1024
网络优化:
Linux系统网络参数优化:
# 编辑sysctl配置
sudo vim /etc/sysctl.conf
# 添加以下配置
net.core.somaxconn = 1024
net.ipv4.tcp_max_tw_buckets = 5000
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 1200
net.ipv4.ip_local_port_range = 1024 65000
# 应用配置
sudo sysctl -p
5.2 监控与告警配置
建立完善的监控体系是保障系统稳定运行的关键:
关键监控指标:
| 指标类别 | 具体指标 | 合理范围 | 告警阈值 |
|---|---|---|---|
| 系统资源 | CPU使用率 | 30%-70% | >85% |
| 系统资源 | 内存使用率 | 40%-80% | >90% |
| 系统资源 | 磁盘使用率 | <70% | >85% |
| 网络指标 | 带宽使用率 | <60% | >80% |
| 应用指标 | 响应时间 | <500ms | >1000ms |
| 应用指标 | 错误率 | <0.1% | >1% |
| 媒体指标 | 视频卡顿率 | <1% | >5% |
| 媒体指标 | 丢包率 | <0.5% | >2% |
告警配置示例:
monitor:
alert:
# CPU使用率告警
cpu-usage:
enable: true
threshold: 85
interval: 60 # 检查间隔(秒)
notify: [email, sms]
# 内存使用率告警
memory-usage:
enable: true
threshold: 90
interval: 60
notify: [email, sms]
# 设备离线告警
device-offline:
enable: true
duration: 300 # 持续离线时间(秒)
notify: [email, sms, webhook]
# 录像异常告警
record-error:
enable: true
notify: [email, sms, webhook]
5.3 备份与恢复策略
制定完善的备份策略是保障系统数据安全的重要措施:
配置文件备份:
# 创建备份目录
mkdir -p /backup/wvp-config
# 备份配置文件
cp docker/wvp/wvp/application.yml /backup/wvp-config/application-$(date +%Y%m%d).yml
cp docker/docker-compose.yml /backup/wvp-config/docker-compose-$(date +%Y%m%d).yml
数据库备份:
# 创建数据库备份脚本
cat > /backup/wvp-mysql-backup.sh << 'EOF'
#!/bin/bash
BACKUP_DIR="/backup/mysql"
DATE=$(date +%Y%m%d_%H%M%S)
mkdir -p $BACKUP_DIR
# 使用docker exec执行mysqldump
docker exec wvp-mysql mysqldump -u root -p"$DB_PASSWORD" wvp > $BACKUP_DIR/wvp_backup_$DATE.sql
# 压缩备份文件
gzip $BACKUP_DIR/wvp_backup_$DATE.sql
# 删除7天前的备份
find $BACKUP_DIR -name "wvp_backup_*.sql.gz" -mtime +7 -delete
EOF
# 添加执行权限
chmod +x /backup/wvp-mysql-backup.sh
# 添加到crontab,每天凌晨3点执行
echo "0 3 * * * /backup/wvp-mysql-backup.sh" >> /etc/crontab
[!WARNING] 备份文件应存储在与服务器不同的物理位置,避免单点故障导致数据丢失。建议定期测试恢复流程以确保备份有效性,至少每季度进行一次恢复测试。
5.4 运维管理常见问题
| 问题现象 | 可能原因 | 解决方案 |
|---|---|---|
| 系统运行缓慢 | 资源不足或存在性能瓶颈 | 检查系统资源使用情况,优化配置或升级硬件 |
| 数据库连接耗尽 | 连接池配置不当或存在连接泄漏 | 调整连接池参数,检查应用是否正确释放连接 |
| 媒体服务器崩溃 | 内存溢出或转码资源不足 | 调整JVM参数,降低转码分辨率或关闭非必要转码 |
| 日志文件过大 | 日志级别设置不当 | 调整日志级别,配置日志轮转策略 |
| 备份失败 | 磁盘空间不足或权限问题 | 检查磁盘空间和备份目录权限 |
六、常见错误码解析与故障排查
6.1 核心错误码解析
平台运行过程中可能会遇到各种错误,以下是常见错误码的含义及解决方法:
| 错误码 | 含义 | 可能原因 | 解决方案 |
|---|---|---|---|
| 401 | 未授权 | 用户名或密码错误 | 检查用户名密码,通过管理员重置密码 |
| 403 | 禁止访问 | 权限不足或IP限制 | 检查用户权限配置,确认是否在IP白名单内 |
| 500 | 服务器内部错误 | 配置错误或代码异常 | 查看应用日志,检查配置文件正确性 |
| 1001 | 设备未注册 | 设备未注册或注册超时 | 检查设备网络和GB28181配置,重启设备 |
| 1002 | 视频流获取失败 | 设备离线或通道不存在 | 检查设备状态,确认通道号是否正确 |
| 1003 | 录像文件不存在 | 录像计划未配置或存储故障 | 检查录像计划,确认存储路径可写 |
| 2001 | SIP注册失败 | 网络不通或SIP参数错误 | 检查网络连通性,核对SIP服务器参数 |
| 2002 | 心跳超时 | 网络不稳定或设备故障 | 检查网络质量,确认设备是否正常运行 |
| 3001 | 转码失败 | CPU资源不足或转码参数错误 | 检查系统资源,调整转码参数或关闭转码 |
| 3002 | 存储已满 | 磁盘空间不足 | 清理过期录像,扩展存储空间 |
6.2 故障排查方法论
系统故障排查应遵循以下流程:
- 问题定位:明确故障现象,确定影响范围和严重程度
- 日志收集:收集相关组件日志,重点关注错误信息
- 数据分析:分析日志和监控数据,寻找异常指标
- 假设验证:提出可能原因并进行针对性测试
- 解决方案:实施解决方案并验证效果
- 预防措施:制定预防类似问题的措施,完善监控告警
常用故障排查命令:
# 查看应用日志
docker logs -f wvp
# 查看媒体服务器日志
docker logs -f zlm
# 检查网络连通性
telnet 设备IP 5060
# 查看端口占用情况
netstat -tulpn | grep 5060
# 检查系统资源
top -b -n 1 | grep java
# 查看数据库连接情况
docker exec -it wvp-mysql mysql -u root -p -e "show processlist;"
6.3 典型故障案例分析
案例一:设备注册失败
现象:设备显示未注册,平台日志出现"SIP注册失败"错误
排查步骤:
- 检查设备网络连接:
ping 设备IP - 检查SIP端口连通性:
telnet 设备IP 5060 - 查看平台SIP服务状态:
docker logs wvp | grep SIP - 核对设备端和平台端的SIP参数是否一致
- 检查防火墙规则:
iptables -L | grep 5060
解决方案:
- 确保设备与平台网络连通
- 核对SIP服务器IP、端口、域和密码参数
- 开放防火墙5060端口和媒体端口范围
案例二:视频流卡顿
现象:实时监控画面频繁卡顿,偶尔出现花屏
排查步骤:
- 检查系统资源:
top查看CPU和内存使用率 - 检查网络状况:
iftop查看带宽使用情况 - 查看媒体服务器日志:
docker logs zlm | grep error - 检查设备码流参数:是否超过网络承载能力
- 测试网络延迟和丢包率:
ping和traceroute
解决方案:
- 降低视频码率或分辨率
- 优化网络,减少网络延迟和丢包
- 调整JVM参数,增加媒体服务器资源
- 对高码率设备启用转码功能
附录:技术术语对照表
| 术语 | 全称 | 解释 |
|---|---|---|
| GB28181 | 国家标准GB/T 28181 | 中国安防视频监控系统的国家标准,规定了设备接入、控制、媒体传输等协议 |
| SIP | Session Initiation Protocol | 会话初始协议,GB28181基于SIP协议进行设备注册和信令交互 |
| RTP | Real-time Transport Protocol | 实时传输协议,用于音视频数据的实时传输 |
| RTSP | Real Time Streaming Protocol | 实时流传输协议,用于控制媒体流的播放、暂停、快进等操作 |
| ONVIF | Open Network Video Interface Forum | 开放网络视频接口论坛,制定了网络视频设备的接口标准 |
| H.264/H.265 | 视频编码标准 | 常用的视频压缩编码标准,H.265相比H.264有更高的压缩率 |
| PS | Program Stream | 节目流,一种视频封装格式,GB28181中常用的媒体流格式 |
| RTP over TCP | RTP over TCP | 通过TCP协议传输RTP流,相比UDP更可靠但延迟略高 |
| 级联 | Cascade | 多个监控平台之间的层级连接,实现资源共享和集中管理 |
| PTZ控制 | Pan-Tilt-Zoom Control | 对具有云台功能的摄像机进行方向和焦距控制 |
atomcodeClaude Code 的开源替代方案。连接任意大模型,编辑代码,运行命令,自动验证 — 全自动执行。用 Rust 构建,极致性能。 | An open-source alternative to Claude Code. Connect any LLM, edit code, run commands, and verify changes — autonomously. Built in Rust for speed. Get StartedRust060
Kimi-K2.6Kimi K2.6 是一款开源的原生多模态智能体模型,在长程编码、编码驱动设计、主动自主执行以及群体任务编排等实用能力方面实现了显著提升。Python00- QQwen3.5-397B-A17BQwen3.5 实现了重大飞跃,整合了多模态学习、架构效率、强化学习规模以及全球可访问性等方面的突破性进展,旨在为开发者和企业赋予前所未有的能力与效率。Jinja00
MiniMax-M2.7MiniMax-M2.7 是我们首个深度参与自身进化过程的模型。M2.7 具备构建复杂智能体应用框架的能力,能够借助智能体团队、复杂技能以及动态工具搜索,完成高度精细的生产力任务。Python00
GLM-5.1GLM-5.1是智谱迄今最智能的旗舰模型,也是目前全球最强的开源模型。GLM-5.1大大提高了代码能力,在完成长程任务方面提升尤为显著。和此前分钟级交互的模型不同,它能够在一次任务中独立、持续工作超过8小时,期间自主规划、执行、自我进化,最终交付完整的工程级成果。Jinja00
Hy3-previewHy3 preview 是由腾讯混元团队研发的2950亿参数混合专家(Mixture-of-Experts, MoE)模型,包含210亿激活参数和38亿MTP层参数。Hy3 preview是在我们重构的基础设施上训练的首款模型,也是目前发布的性能最强的模型。该模型在复杂推理、指令遵循、上下文学习、代码生成及智能体任务等方面均实现了显著提升。Python00




